Bug管理的流程和几个重点

软件测试的主要目的在于发现软件存在的错误(Bug)，对于如何处理测试中发现的错误， 将直接影响到测试的效果。只有正确、迅速、准确地处理这些错误，才能消除软件错误，保证 要发布的软件符合需求设计的目标。在实际软件测试过程中，对于每个Bug都要经过测试、确 认、修复、验证等的管理过程，这是软件测试的重要环节。

 

错误跟踪管理系统
　　为了正确跟踪每个软件错误的处理过程，通常将软件测试发现的每个错误作为一条条记录 输入制定的错误跟踪管理系统。
　　目前已有的缺陷跟踪管理软件包括Compuware公司的TrackRecord软件（商业软件）、 Mozilla公司的Buzilla软件（免费软件），以及国内的微创公司的BMS软件，这些软件在功能 上各有特点，可以根据实际情况选用。当然，也可以自己开发缺陷跟踪软件，例如基于Notes 或是ClearQuese开发缺陷跟踪管理软件。
　　作为一个缺陷跟踪管理系统，需要正确设计每个错误的包含信息的字段内容和记录错误的处理信息的全部内容。字段内容可能包括测试软件名称，测试版本号，测试人名称，测试事件，测试软件和硬件配置环境，发现软件错误的类型，错误的严重等级，详细步骤，必要的附图，测试注释。处理信息包括处理者姓名，处理时间，处理步骤，错误记录的当前状态。
　　正确的数据库权限管理是错误跟踪管理系统的重要考虑要素，一般要保证对于添加的错误 不能从数据库中删除。

 

软件错误的状态
 第一种

　　新信息(New)：测试中新报告的软件缺陷；
　　打开(Open)：被确认并分配给相关开发人员处理；
　　修正(Fixed)：开发人员已完成修正，等待测试人员验证；
　　拒绝(Declined)：拒绝修改缺陷；
　　延期(Deferred)：不在当前版本修复的错误，下一版修复
　　关闭(Closed)：错误已被修复；

另一种

       新信息(New)：测试中新报告的软件缺陷；
　　打开(Open)：被确认并分配给相关开发人员处理；

      处理完毕提交（Resolve）

 

一个Bug有7种解法：
By Design - 就是这么设计的，无效的Bug
Duplicate - 这个问题别人已经发现了，重复的Bug
External - 是个外部因素(比如浏览器、操作系统、其他第3方软件)造成的问题
Fixed - 问题被修理掉了。Tester要尽可能找到这种Bug
Not Repro - 无法复现你这个问题，无效的Bug
Postponed - 是个问题，但是目前不必修理了，推迟到以后再解
Won't Fix - 是个问题，但是不值得修理了，不管它吧

Activate(激活) 或REOPEN(重新打开)

如果Tester不同意该Bug的解法，则可激活之。该Bug会自动被指派给当初解决(Resolve) 的同事，当然你在激活的时候应该写上为什么你这么做，让别人明白你激活它是由道理的。

      关闭(Closed)：错误已被修复；

 

Bug管理的一般流程
　　测试人员提交新的Bug入库，错误状态为New。
　　高级测试人员验证错误，如果确认是错误，分配给相应的开发人员，设置状态为Open。如果不是错误，则拒绝，设置为Declined状态。
　　开发人员查询状态为Open的Bug，如果不是错误，则置状态为Declined；如果是Bug则修复 并置状态为Fixed。不能解决的Bug，要留下文字说明及保持Bug为Open状态。
　　对于不能解决和延期解决的Bug，不能由开发人员自己决定，一般要通过某种会议（评审 会）通过才能认可。
　　测试人员查询状态为Fixed的Bug，然后验证Bug是否已解决，如解决置Bug的状态为 Closed，如没有解决置状态为Reopen。

 

流程虽然简单，但是在实际使用中还是发现一些问题：
1.bug信息不全：
   有的信息，比如项目，模块，指定处理人（也就是指派给谁处理）等，这些信息会用来作统计分析，哪个项目，哪个模块，谁的bug多，谁发现的bug多，谁改的bug多等，根据这些信息可以大致看出一个人的工作量和工作质量。所以不要嫌麻烦，把bug的信息写全些。
2.所提供的信息不准确：
有的bug描述一带而过，表述含糊不清，只是说出现了错误，但是错误的现象是什么，提示信息是什么，怎么操作才出现的，都不清楚，这样的bug交给开发人员，只会给开发人员增加负担，因为他自己还要再作测试，以发现更多的信息，去排除bug，或者他会到测试那边其讨论，询问详情，有时要多次反馈才能确定到底是什么问题。
3.开发人员关闭bug： 
只有bug的提交人（也就是发现人）才能去关闭该bug，开发人员只能使用两个状态：“处理中”和“已修正”
4.bug的可重现性：
  这个重要的属性是在bug管理软件中无法体现和度量的， 这个任务主要都在测试这边，如果你发现了一个bug，赶紧把开发人员叫过来，人家来了，你要给他看看这个bug，可是却怎么也不出现了，连自己都不知道这个bug是怎样操作后才出现的。这样不能重现的bug几乎就不能算作bug，也是最让人头疼的问题。那么作为测试人员，你的任务就是要尽可能的找到bug出现的规律，尝试各种可能，即使不能重现，起码也要让开发人员知道你已经作了哪些尝试，而他不必再去走弯路。

 

软件错误流程管理要点

　　为了保证错误的正确性，需要有丰富测试经验的测试人员验证发现的错误是否是真正的错误，书写的测试步骤是否准确，可以重复。
　　每次对错误的处理都要保留处理信息，包括处理姓名，时间，处理方法，处理意见，Bug 状态。
　　拒绝或延期错误不能由程序员单方面决定，应该由项目经理，测试经理和设计经理共同决定。
　　错误修复后必须由报告错误的测试人员验证后，确认已经修复，才能关闭错误。
　　加强测试人员与程序员的交流，对于某些不能重复的错误，可以请测试人员补充详细的测 试步骤和方法，以及必要的测试用例。