【软件测试】软件测试生命周期
软件测试生命周期
生命周期：需求分析—>测试计划—>测试设计、测试开发—>测试执行—>测试评估
需求分析：测试需求范围
制定测试计划：时间表（什么人、什么时间、做什么事？）软件类、工具类的资料、风险
测试设计：测试开发、测试用例的编写
测试执行：执行测试用例、缺陷管理
测试评估：编写测试报告（核心：测试结论、缺陷分析)
描述缺陷的要素：
版本、环境、步骤、描述、预期结果、实际结果、附件
描述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，开发人员重新修改。
说明：
- new状态到open转态是测试人员操作
- Fixed状态是开发人员操作
- Closed状态是缺陷验证通过
- reopen状态是测试人员重新验证bug发现仍然存在
缺陷流程图：
说明：
- 无效的bug：1）open->closed
２）open-rejected-closed
如何发现更多的bug？
- 软件测试同样存在二八原则
80%的故障集中于20%的模块，如果某部分问题较多，加强测试深度和广度 - 开发人员也存在二八原则
- 多进行逆向思维和发散性的思维
- 不要局限于用例和需求文档
- 尽早介入项目, 不要等到开发的差不多了再介入项目