软件测试:基础篇
本节主要内容
软件测试的生命周期
软件测试的生命周期生命周期
每个测试阶段的分析 编写测试用例的同时也是对需求进行的一个测试。 编写测试报告是为了对缺陷进行分析。
一个合格的 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