软件测试-BUG篇
软件测试的声明周期
软件测试贯穿软件的整个生命周期
软件测试的生命周期是指测试流程，这个流程是按照一定顺序执行的一系列特定的步骤，去保证产品质量符合需求。在软件测试生命周期流程中，每个活动都按照计划的系统的执行。每个阶段有不同的目标和交付产物
BUG
BUG的概念
一个计算机bug指在计算机程序中存在的一个错误、缺陷、疏忽或者故障，这些bug使程序无法正确的运行。BUG产生于程序的源代码或者程序设计阶段的疏忽或者错误。
- 当且仅当规格说明是存在的并且正确，程序与规格说明之间的不匹配才是错误。
- 当需求规格说明书没有提到的功能，判断标准以最终用户为准：当程序没有实现其最终用户合理预期的功能要求时，就是软件错误
描述bug的要素
描述bug的要素：问题出现的版本，问题出现的环境，问题出现的步骤，预期结果，实际结果
bug 级别
bug的级别一般分为：崩溃、严重、一般、次要
bug的声明周期
- new：新发现的bug，未经评审决定是否指派给开发人员进行修改
- open：确实是bug，并且认为需要进行修改，指派给对应的开发人员
- fixed：开发人员进行修改后标识成修改状态，有待测试人员的回归测试验证
- rejected：如果认为不是bug，则拒绝修改
- delay：如果认为暂时不需要修改或者暂时不能修改，则修后修改
- Closed：修改状态的Bug经测试人员的回归测斌验证通过，则关闭Bug。
- eopen：如果经验证Bug仍然存在，则需要重新打开Bug，开发人员重新修改。
如果和开发产生争执该怎么办
- 先检查自身，是否bug描述的不清楚
对于自己所写的bug描述，应当描述足够清楚，方便开发人员能够迅速定位bug；如果实在难以书面描述清楚，应当在提交完bug之后，尽快找到开发人员，和他口头沟通，描述清楚。 - 站在用户的角度来考虑问题
站在用户的角度考虑，让开发人员认识到bug可能对用户产生的困扰，使开发人员可以更积极的去修改bug - BUG级别定义要有理有据
UG定级时，不仅要参考BUG级别，还要考虑BUG是否会影响到流程，往往用户的BUG级别和我们的是有区别的，需站在用户的角度定考虑定位级别 - 提高自身技术和业务水平，做到不仅能提出问题，最好也能给出解决方案
提高自身的业务和技术水平，不但能提出问题，还能够提出一定的解决问题的思路。这样更让人信服，值得注意的是可以给出解决方案，但是不能喧宾夺主，命令式让开发人员按照自己的想法来修 - bug评审
这是终极方案——无法沟通解决，就摇人
bug评审主要解决两个问题：
1）决定如何处理bug
2）分析缺陷产生的原因，找出预防的对策
bug评审至少需要项目组各个方面的代表参加：
1）测试代表
测试代表主要从Bug的具体表现、严重程度等方面提供信息，并提出自己对Bug的处理意见。需要注
意的是，测试人员不应该一味地要求对Bug进行修改，因为修改可能带来回归的风险，同时带来的是
回归测试的工作量，如果时间比较紧迫，修改后剩余的时间若不足以做一次有效的回归测试，可能不
修改是个明智的选择。
2）开发代表
开发代表主要从修改缺陷的难度和风险出发，考虑缺陷修改需要付出的代价，以及可能影响的范围、
可能引发的风险等，如果决定要修改，还要讨论出修改的初步方案。
3）产品代表
产品代表主要从产品的整体计划、用户的要求等方面对缺陷的修改必要性、缺陷修改的时间和版本提
出自己的意见