软件测试：基础篇
本节主要内容
软件测试的生命周期
软件测试的生命周期生命周期
每个测试阶段的分析 编写测试用例的同时也是对需求进行的一个测试。 编写测试报告是为了对缺陷进行分析。
一个合格的 bug 描述应包括哪些部分
应包括以下部分：
如何定义bug的级别
bug的定义每个公司都不一致，在定义级别之前需要查看公司规范。
举例：
最后，测试人员将出现的以上缺陷全部提交到缺陷管理系统上。
bug 的生命周期
即从出现到消亡的过程。 BUG状态转换图
New：新发现的Bug，交给指派的开发人员进行相应的修改。
Open：开发负责人确认是Bug，并且认为需要修改，指派给相应的开发人员。
Fixed：开发人员进行修改后标示成修改状态，有待测试人员的回归测试验证。
Rejected：如果认为不是Bug，则拒绝修改。
Delay：如果认为暂时不需要修改或暂时不能修改，则延后修改。
Closed：修改Bug的状态经测试人员的回归测试通过后，关闭Bug。
Reopen：如果经验证的Bug仍然存在，则需要重新打开Bug，开发人员重新修改。
如何开始第一次测试
准备工作
确认具体的工作内容（向测试组长）
测试执行和BUG管理
开始测试
发现bug
产生争执怎么办
在测试过程中，最常遇到的是和开发人员的PK，
遇到争执时不要怕，做法有：
- 决定如何处理bug。
1. 参加该评审不可或缺的是测试代表、开发代表、产品代表。
测试代表主要从Bug的具体表现、严重程度等方面提供信息，并提出自己对Bug的处理意见。
2. 开发代表开发代表主要从修改缺陷的难度和风险出发，考虑缺陷修改需要付出的代价，以及可能影响的范围、可能引发的风险等，如果决定要修改，还要讨论出修改的初步方案。
3. 产品代表主要从产品的整体计划、用户的要求等方面对缺陷的修改必要性、缺陷修改的时间和版本提出自己的意见。
- 分析缺陷产生的原因，制定出预防的对策。
1
2
3
4
5
6
本文转自：https://blog.csdn.net/bit666888/article/details/81061007