软件测试--缺陷

软件测试的生命周期：

需求分析 --> 测试计划 --> 测试设计、测试开发 --> 测试执行 --> 测试评估

软件测试&软件开发生命周期：

1. 需求阶段：测试人员了解需求、对需求进行分解，得出测试需求；

2. 计划阶段：根据需求编写测试计划、测试方案；

3. 设计阶段：包括概要设计和详细设计，测试人员适当的了解设计，对于设计测试用例很有帮助，测试人员搭建测试用例框架，根据需求和设计编写一部分测试用例；

4. 编码阶段：包含V模型中的单元测试和集成测试，白盒测试人员或研发工程师执行单元测试；

5. 测试阶段：根据测试用例和设计执行计划阶段，在执行过程中记录、管理缺陷、测试完成后编写测试报告；

6. 运行维护阶段：对应V模型的验收测试阶段，在运行项目时收集问题并及时反馈给相关负责人。

缺陷：

合格的缺陷描述包含的部分：发现问题的版本、问题出现的环境、错误重现的步骤、预期行为的描述、错误行为的描述、其他（备注、附件、故障分类等）、不要把多个BUG放到一起提交

缺陷产生的原因：

1. 人员之间的沟通交流不够，交流上有误解或者无交流；

2. 需求文档不完善；

3. 需求不断变化；

4. 参与人员的过度自信（模块功能不挑食，多个模块不联调）；

5. 程序设计本省有误；

6. 软件开发工具与系统软硬件的支持等；

缺陷的状态及状态转换图：

缺陷的状态：New、Open、Fixed、Rejected、Delay、Closed、Reopen

● New：新发现的Bug，未经评审决定是否指派给开发人员进行修改。

● Open：确认是Bug，并且认为需要进行修改，指派给相应的开发人员。

● Fixed：开发人员进行修改后标识成修改状态，有待测试人员的回归测试验证。

● Rejected：如果认为不是Bug，则拒绝修改。

● Delay：如果认为暂时不需要修改或暂时不能修改，则延后修改。

● Closed：修改状态的Bug经测试人员的回归测斌验证通过，则关闭Bug。

● Reopen：如果经验证Bug仍然存在，则需要重新打开Bug，开发人员重新修改。

● 无效的bug：open->closed    open-rejected-closed

● 测试负责人，研发经理，项目经理

● 敏捷模式下，测试人员看到bug就直接给开发人员了

● Fixed到Reopen是测试人员操作的

缺陷的级别（严重程度）：崩溃（Blocker）、严重（Critical）、一般（Major）、次要（Minor）四种；

如何发现更多的BUG ？

1. 软件测试同样存在二八原则，80%的故障集中于20%的模块，如果某部分问题较多，加强测试的广度和深度；

2. 开发人员也存在二八原则，80%的故障集中于20%的开发人员，如果某些开发人员的BUG较多，加强该人员开发模块的测试广度和深度；

3. 多进行迹象思维和发散性思维；

4. 不要局限于测试用例和需求文档；

5. 测试人员尽早的介入项目，不要等到开发的差不多了再介入；