以前写的一份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，修改后该文件的版本号
  如果研发解决问题的注释上只写“已解决”这样的话，就一定要叫他们加上上面的信息

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