测试人员对bug（缺陷）的描述及管理

测试人员对bug（缺陷）的描述规则及管理

一、 Bug的基本概念
bug是计算机领域专业术语，bug原意是“臭虫”或是“缺陷、损坏”的意思，现在用来指代计算机上存在的漏洞或是未被发现的问题及缺陷。

二、Bug（缺陷）的生命周期

三、描述bug（缺陷）的准则

1. Bug的描述有三个要素：位置、操作、现象，书写时必须严格遵守。
2. Bug记录是测试人员工作的基本内容，也是测试和开发交流的基础，确保了Bug描述的有效性，即可提高Bug的修改速度，也可提高Bug的修改质量。
3. 测试人员应比开发人员细心，不可以在bug描述过程中还给描述本身带来bug。
4. 描述bug相关准则如下：
   （1）描述要准确，清晰
   （2）提供最少的重现问题的步骤。
   （3）不要把不相关的多个操作写在一个步骤里。
   （4）所写的步骤要和你所操作的步骤严格一致。
   （5）如果对于不能重复的Bug，请注明当时的运行的状态及可能导致的原因。
   （6）项目相关人员按照描述的bug产生过程便可重现bug。
   （7）除必要的描述步骤外，需要填写bug管理工具中提交缺陷时各个选项，以帮助研发人员分析问题，也方便日后bug的查询。

四、描述bug的格式
（1）概 述：用一句话简要描述Bug的现象。需要包括bug所在的模块及出错点
前置条件：产生bug需要的前提（必要时填写）。
（2）步 骤：使用数字编号的形式，相对详细阐述出现Bug的操作步骤，需保证使用这样的叙述其他人便可重现bug，必要时需要描述bug产生的前提和条件。
（3）预 期：填写上述操作过程应该输出的正确结果。
（4）结 果：用文字准确描述出Bug引起的结果及现象，必要时需要有图形附件用拷屏方式将错误信息添加进来。
（5）结果分析：bug修改完毕后，简要描述此Bug产生的原因。

五、bug（缺陷）等级的划分
——立即：
1.不解决无法继续进行测试的问题；

——紧急：
1.严重影响程序流程的进行；
2. 有明确时间要求的bug；

——高：
1.可重现的死机问题；
2.造成数据库不稳定的错误；
3.列在说明中的需求未在最终系统中实现；
4.业务流程不正确；

——普通：
功能的实现有问题：
1）如在系统实现的界面上，一些可接受输入的控件点击后无作用；
2）对用户的使用有操作顺序上的限制；
3）虽然正确性不受影响，但系统性能和响应时间受到影响；
4）系统刷新错误；
5）产生错误结果，如非预期结果错误等；

——低：
没有特别损害的输出；
或者使系统使用起来不太方便的功能不能另人满意或操作烦琐的错误。如：
（1）系统的提示语不明确，不简明；
（2）滚动条无效；
（3）可编辑区和不可编辑区不明显；
（4）光标跳转设置不好，鼠标（光标）定位错误；
（5）界面不一致，或界面不正确；

六、bug（缺陷）状态的定义
——新建：新发现的bug
——已指派：项目负责人已指派给自己或者某研发人员修改
——已修改： 研发人员修改bug后提交给测试人员时需要置为已修改状态
——不修改： 研发人员认为目前各种情况局限造成无法修改的情况。
——验证不通过： 测试人员对bug进行回归测试时发现问题仍然存在。
——不是问题：测试人员操作失误导致或者对系统理解不清导致被认为是bug的情况
——已关闭：不是问题或者验证通过的bug可置为已通过的状态

七、遗留问题的确认
项目测试结束后，遗留问题的来源包括以下几项：
（1）尚未修改的bug。
（2）验证不通过，尚未关闭的bug。
（3）研发人员确认不修改的bug。
（4）研发人员认为不是问题，但是测试人员仍然认为是问题的bug。

八、测试人员需要注意的问题
1.测试过程中缺陷的管理必须严格按照缺陷管理软件中现有的流程方式，测试工程师需要对自己发现的bug负责到底。
2. 研发人员已经置成已修改状态，但认为修改结果无法接受并经协商仍然如此的bug不可以关闭，需要作为遗留问题处理。