软件缺陷管理
上一篇 / 下一篇 2008-09-25 08:48:07 / 个人分类：BUG管理
软件测试的主要目的在于发现软件中存在的Bug，如何处理测试中发现的BUG将直接影响到测试的效果。在实际软件测试过程中，对于每个Bug都要经过测试、确认、修复、验证等的管理过程，这是软件测试的重要环节。
Bug跟踪管理系统:
为了正确跟踪每个软件Bug的处理过程，通常将软件测试发现的每个Bug作为一条条记录输入制定的Bug跟踪管理系统。
目前已有的缺陷跟踪管理软件包括Compuware公司的TrackRecord软件（商业软件）、Mozilla公司的Buzilla软件（免费软件），以及国内的微创公司的BMS软件，这些软件在功能上各有特点，可以根据实际情况选用。当然，也可以自己开发缺陷跟踪软件，例如基于Notes或是ClearQuest开发缺陷跟踪管理软件。
作为一个缺陷跟踪管理系统，需要正确设计每个Bug的包含信息的字段内容和记录Bug的处理信息的全部内容。字段内容可能包括测试软件名称，测试版本号，测试人名称，测试事件，测试软件和硬件配置环境，发现软件Bug的类型，Bug的严重等级，详细步骤，必要的附图，测试注释。处理信息包括处理者姓名，处理时间，处理步骤，Bug记录的当前状态。
正确的数据库权限管理是Bug跟踪管理系统的重要考虑要素，一般要保证对于添加的Bug不能从数据库中删除。
缺陷的状态定义:
新缺陷(New)：测试中新发现的软件缺陷或称为缺陷的初始状态；
打开(Open)：被确认并分配给相关开发人员处理；
修正(Fixed)：开发人员修改完毕，等待测试人员验证；
关闭(Closed)：Bug已被修复；
重复打开(Reopen):开发人员修改bug后,bug没有成功被修复的置为Reopen.
拒绝(Rejected):开发人员认为不是程序问题,拒绝修改缺陷；
延期(Postpone):不在当前版本修复的Bug，下一版修复;
遗留(Left):由于时间或成本,开发人员没有修复的bug.
丢弃(Abandon):确认不是bug或重复提出的bug置为Abandon.
Bug管理的一般流程:
测试人员提交新的Bug入库，Bug状态为New。
高级测试人员验证Bug，如果确认是Bug，分配给相应的开发人员，设置状态为Open。如果不是Bug，则拒绝，设置为Rejected状态。
开发人员查询状态为Open的Bug，如果不是Bug，则置状态为Rejected；如果是Bug则修复并置状态为Fixed。不能解决的Bug，要留下文字说明及保持Bug为Open状态。
对于不能解决和延期解决的Bug，不能由开发人员自己决定，一般要通过某种会议（评审会）通过才能认可,由于时间,成本或修改风险过大等原因,一些bug不再进行修改,置为Left。
测试人员查询状态为Fixed的Bug，然后验证Bug是否已解决，如解决置Bug的状态为Closed，如没有解决置状态为Reopen。
软件Bug流程管理要点:
为了保证Bug的正确性，需要有丰富测试经验的测试人员验证发现的Bug是否是真正的Bug，书写的测试步骤是否准确，可否重复。
每次对Bug的处理都要保留处理信息，包括处理姓名，时间，处理方法，处理意见，Bug状态。
拒绝或延期Bug不能由程序员单方面决定，应该由项目经理，测试经理和开发经理共同决定。
Bug修复后必须由报告Bug的测试人员验证后，确认已经修复，才能关闭Bug。
加强测试人员与程序员的交流，对于某些不能重现的Bug，可以请测试人员补充详细的测试步骤和方法，以及必要的测试用例。
相关阅读:
- 谁来决定BUG的优先级 (雪儿, 2007-7-20)
- Bug管理的一般流程 (happybaby2000, 2007-10-10)
TAG: BUG管理
标题搜索
日历
|
|||||||||
| 日 | 一 | 二 | 三 | 四 | 五 | 六 | |||
| 1 | |||||||||
| 2 | 3 | 4 | 5 | 6 | 7 | 8 | |||
| 9 | 10 | 11 | 12 | 13 | 14 | 15 | |||
| 16 | 17 | 18 | 19 | 20 | 21 | 22 | |||
| 23 | 24 | 25 | 26 | 27 | 28 | 29 | |||
| 30 | |||||||||
我的存档
数据统计
- 访问量: 52860
- 日志数: 28
- 建立时间: 2007-06-02
- 更新时间: 2008-12-18
