bug规范

引自　原文

 

以前对新员工写的一份BUG提交规范，可以写的比较随意化，口头语太多，我们用的缺陷管理工具是JIRA。


1，BUG全部提交到http://XXX.XXX.XXX.XXXBUG论坛上

2，创建的问题的时候，“概要”--用简单明了的语句说明白你这个BUG，就相当与BUG的中心语句

3，BUG优先级分为4种情况
   致命问题：系统任何一个主要功能完全丧失、用户数据受到破坏、系统崩溃、悬挂、死机，或者危及人身安全
   严重问题： 系统的主要功能部分丧失、数据不能保存，系统的次要功能完全丧失，系统所提供的功能或服务受到明显的影响
   一般问题：  系统的次要功能没有完全实现，但不影响用户的正常使用。
   建议性问题：不影响功能的、有关易用性的、文字、操作可以提出一些建议的问题

4，然后选择你提交的BUG所以那个模块,并选择提交问题时测试程序的影响版本

5，选择这个BUG所属模块是属于那个开发人员 ，并把问题指派给他

6，环境：填写你当时出这个BUG的现场环境，如：操作系统是winxp,测试的终截者是那天的版本等（这个根据实况进行填写，可写也可不写）

7，另外可以通过上传截图或附件，可以进行简单明了的说明BUG存在，也可做为BUG证据

8，最重要的在填写描述: 最好是把BUG产生的步骤一步一步写清楚，可以用以下方法写（如果一句话就可以说明的BUG，就不必要分步骤了）
     1，。。。
     2，。。。
     3，。。。
     4，。。。
    写清楚，然后写出测试出的结果和你期望的结果，如：
    测试结果：。。。。。
    期望结果：。。。。。

9，BUG验证/关闭问题说明：
   当BUG由open变为FIXed，你就应该进行回归测试，如果回归测试后该问题被解决，则你就closed该BUG，并在注释中填写如下信息：
            验证通过：是
            验证日期：。。。
            验证版本：。。。
   如果回归测试验证不通过，则Reopend该BUG，并在注释中填写你验证的版本

10，关于研发人员解决问题
    研发人员解决BUG写的注释一定要有以下几点：
      1，说清楚BUG产生的原因
      2，写出BUG产生的文件
      3，修改后该文件的版本号
  如果研发解决问题的注释上只写“已解决”这样的话，就一定要叫他们加上上面的信息

   可能这个要根据不同的公司进行修改，我们分配问题就是直接分给相关开发人员，而不用通过经理再去分配任务。

 

 

这个所谓的BUG提交规范并不规范。存在以下问题。
1、BUG的优先级说明不是这样的，你可以去看下JIRA的说明。如果功能没实现，根本就进不了测试阶段，或者说该未实现的功能模块不应该被测试。
2、测试人员不应该把BUG直接提交给开发人员，而是要提交给项目经理或测试经理，特别是跟需求有关，如需求设计不清晰而测试人员认为是BUG的问题，有可能开发人员不认为是BUG。总之，BUG不应该直接从测试到开发；
3、验证BUG并不是回归测试，请去查下什么是回归测试；
4、执行测试需要有测试用例，那发现了BUG应该标注在哪个测试用例发现BUG，需要写上测试用例编号；
5、JIRA是可以设置BUG修改期限的，也应该根据BUG优先级填写；
6、上传的图片应该是局部的截图，这样容易定位BUG。
7、BUG的生命周期还可能产生其它状态，没有说明

简单罗列下，不是随便写点东西就能成为规范的。

 

谢谢莫冲的精彩建议，可能是因为每个公司不一样吧，我是按照公司情况写的一份东西，可能对其他公司并不适合。这里对你提的几点说下吧。
1、BUG优先级是我自己在JIRA进行制定的，并没有用JIRA默认的
2、第二点是要根据不同公司情况进行制定的，并不如你说的一定要给项目经理，因为一个小公司根本就不可能走那么多的流程出来，我们公司最求的目标，就是快速发现问题，开始反应给开发人员，然后快速进行回归验证。至于你说的开发人员不承认，这要看什么情况，一般有很大争议的话会让项目经理进行决定。
3、回归测试的概念我不想和你争，不同的人有不同的看法，概念是死的，要做活他才是最好
4、第四点说的非常好，可惜不适合我们公司，只能说我们公司在测试方面可能还不是很规范
5、JIRA的修改期限和期望修改的版本，这个实施起来都很规范，主要还是没有走你说的第二点流程。
6、这点就不说了
7、BUG的生命周期确实有很多状态，包括New、Open、Reopen、Fixed、Closed及Rejected等

真的非常感谢莫冲，从你的评论看的出你做测试肯定很多年了，希望你多多指点。

 

由此看出我提交的bug还有地方需要修正：

1、没有提及bug的严重程度；

2、缺少bug的生命周期状态；

3、测试步骤中添加上测试结果和预期结果；

4、bug关闭时，添加信息： 验证通过：是； 验证日期：。。。；验证版本：。。。

5、对于已解决的bug，研发人员需要做得： 1，说清楚BUG产生的原因； 2，写出BUG产生的文件；3，修改后该文件的版本号；

6、bug针对的测试用例编号；