【软件测试】软件测试生命周期

软件测试生命周期

生命周期：需求分析—>测试计划—>测试设计、测试开发—>测试执行—>测试评估
需求分析：测试需求范围
制定测试计划：时间表（什么人、什么时间、做什么事？）软件类、工具类的资料、风险
测试设计：测试开发、测试用例的编写
测试执行：执行测试用例、缺陷管理
测试评估：编写测试报告（核心：测试结论、缺陷分析)

描述缺陷的要素：

版本、环境、步骤、描述、预期结果、实际结果、附件

描述Bug（案例）

编号：regdit_001
标题：邮箱注册提交报500错误
环境：win10+IE11
步骤：
　　　1.进入163首页
　　　2.点击“注册免费邮箱”
　　　3.输入页面上的所有信息（罗列出来）
　　　4.点击“已发送短信，立即注册”
实际结果：
　　　页面报500错误
预期结果：
　　　页面提示“发送成功”

缺陷的级别

崩溃、严重、一般、次要

bug的生命周期（从open到closed）

缺陷的状态：

• New:新发现的Bug，未经评审决定是否指派给开发人员进行修改。
• Open：确认是Bug，并且认为需要进行修改，指派给相应的开发人员。
• Fixed:开发人员进行修改后标识成修改状态，有待测试人员的回归测试验证。
• Rejected：如果认为不是Bug，则拒绝修改。
• Delay:如果认为暂时不需要修改或暂时不能修改，则延后修改。
• Closed：修改状态的Bug经测试人员的回归测斌验证通过，则关闭Bug。
• Reopen：如果经验证Bug仍然存在，则需要重新打开Bug，开发人员重新修改。

说明：

1. new状态到open转态是测试人员操作
2. Fixed状态是开发人员操作
3. Closed状态是缺陷验证通过
4. reopen状态是测试人员重新验证bug发现仍然存在

缺陷流程图：

说明：

• 无效的bug：1）open->closed
  　　　　　 ２）open-rejected-closed

如何发现更多的bug？

1. 软件测试同样存在二八原则
   　80%的故障集中于20%的模块，如果某部分问题较多，加强测试深度和广度
2. 开发人员也存在二八原则
3. 多进行逆向思维和发散性的思维
4. 不要局限于用例和需求文档
5. 尽早介入项目, 不要等到开发的差不多了再介入项目