软件测试—基础篇
软件测试的生命周期
在不同的开发阶段，测试人员应该做什么：
- 需求阶段：分析需求，得到测试需求
- 计划阶段：根据需求编写测试计划
- 设计阶段：搭建测试用例的框架
- 编码阶段：完善、细化测试用例的同时也是对需求的测试
- 测试阶段：按照测试用例执行，执行率达100%，可按优先级分先后执行，但最终全都要执行。自由测试，探索测试。编写测试报告时要对缺陷进行分析。缺陷分析的目的：1. 定位问题 2.对类似缺陷有一定参考
- 运行维护：参与项目的实施，在试运行阶段收集bug并反馈
如何描述bug
团队精神
合格的bug描述应包括以下几部分：
- 发现问题的版本
- 问题出现的环境：浏览器版本，客户机操作系统等
- 错误出现的步骤：描述问题重现的最短步骤
- 预期行为的描述：描述期望结果，用户需求，最好写上需求来源。
- 错误行为的描述：描述错误现象，日志或截图
- 不要将多个bug混杂在一起：不同代码段产生的bug最好不要一块提交，难以定位
- 其他：故障分类，如功能故障，界面故障，兼容性故障；还有优先级分类等。
标准的bug描述如下图：
定义bug的级别
各个公司对bug的定义不太一样，
- Blocker（崩溃）：主要功能丧失，基本模块缺失等。如系统崩溃，数据库缺失等问题，这种较少见，一旦出现立即中止测试。
- Cirtical（严重）：功能与需求严重不符，一级功能菜单缺失但不影响其他功能测试，在不影响其他功能测试的情况下可以继续进行测试
- Major（一般）：功能未完全实现但不影响使用
- Minor（次要）：界面、性能缺陷，建议类问题，不影响操作功能的执行，可以优化性能的方案。
bug的生命周期
从new到closed的所有状态
不同公司，不同工具对bug生命周期的定义不太相同
以下为bug状态转换图：
七种状态：
- new：新发现的bug，决定是否交给开发人员去修改
- open：确认是bug，并认定要修改，分配给特定的开发人员修改
- fixed：开发人员修改后标记成修改状态，等测试并进行人员进行回归测试
- rejected：若认为不是bug，则拒绝修改
- delay：无关紧要的bug延迟修改
- closed：修改状态的bug在测试人员回归测试验证通过之后，关闭该bug
- reopen：经验证bug未修复，要重新打开，开发人员重新修改
如何开始第一次测试
与测试组长确认工作内容：
测试计划？测试内容？测试案例多少？安排几天执行？
测试的执行和bug管理
测试执行过程：
- 打开待测系统
- 执行测试用例
- 发现bug（复现并记录复现步骤）
- 记录bug
- 沟通bug
- 验证以前提交的bug
- 完成测试
- 撰写测试报告
如何发现更多的bug：
- 软件测试存在二八原则，80%的故障存在20%的模块，对问题出现多的模块，加强测试深度和广度
- 开发人员也存在二八原则，80%的bug由20%的开发人员产出，加强容易出bug的开发人员开发模块的测试深度和广度
- 多进行逆向思维和开发性思维
- 不局限于测试用例和需求文档
- 早早介入项目，提前了解项目的开发流程和核心思想
处理人际关系
完成一个项目时，开发人员与测试人员难免产生冲突，具体产生冲突的原因可能有：对一个bug的判定、bug级别的确定、立即修改还是延迟修改等，这些问题都有可能使开发和测试人员之间发生争执。
遇到争执不要怕，记住批判性思维：清楚–准确、切题–深刻，有意义，有逻辑性–公正、全面。
当发生争执时，作为一个测试人员，首先要做好以下几点：
- 先检查自己是否将bug描述清楚
- 站在用户角度思考，这样的bug会不会对用户造成影响，有没有完全满足用户需求
- bug的定级要有根有据，最好站在用户角度上考虑定位级别
- 最关键的还是要提升自身技能和业务水平，在提出bug的同时，还要提出解决bug的思路
- 避免与开发人员争吵