Question

bug管理工具在项目中的作用

Answer 1

1缺陷管理工具缺失对项目的影响在实际工作实践过程中，没有软件缺陷管理工具的帮助，就可能会出现如下一系列的影响:(1)软件测试人员将Bug已经提交给了开发人员，但是开发人员可能没有一个很清晰的界面来接收到测试人员提交的Bug信息。　　(2)有一些Bug可能是测试人员进行回归测试中测试出的问题，但是不能和第一次测试出此类型的情况进行关联，所引起的结果为不能进行有效的回归测试。　　(3)测试样例的版本控制难以做到，不能很清晰地看出Bug所处的状态，是Bug被关闭了还是被延期了。　　(4)当运用Word或者Excel作为缺陷管理工具时，可能会给Bug各类指标数的统计(特别是以图表形式统计)带来问题，很难看出一个Bug对应的测试需求。　　(5)假如出现一些不可重现的Bug按照规定也需要进行记录，这些不可重现的Bug在整个项目中的状态难以定义。(不能算作已经解决的Bug，同时Bug由于不能重现使得开发人员修复起来有困难)软件测试的主要目的在于发现软件存在的问题(Bug)。如何处理测试中发现的错误，将直接影响到测试的效果。只有正确、迅速、准确地处理这些错误，才能消除软件错误，保证要发布的软件符合需求设计的目标。而有以上5点的存在，会使Bug的处理效率和Bug处理的验证会有偏差，对项目是否成功还是比较显著的。　　2软件错误的状态以及软件错误管理流程对于软件各项错误的状态，软件业巨头微软公司对于软件错误的状态有如下5种:New:代表此Bug由测试人员发现并且进行提交。　　Open:Bug被正式确认并且分发给开发人员。　　Fixed:开发人员完成Bug漏洞修复并且提交给测试人员进行验证测试。　　Decline:开发人员拒绝修改错误(代表Bug开发人员和测试人员对需求等非程序方面有歧义需要额外沟通)。　　Deferred:Bug在本版本的程序中暂缓修复，在下一个版本中修复。(一般是Bug严重等级比较低的项目)Closed:测试人员最终验证通过，此Bug被最终修复，并由测试人员关闭此Bug。　　一般是由测试人员新建Bug记录后，Bug记录被正式派分到开发人员处，若开发人员对此Bug有歧义就可以拒绝这条Bug的修改并且与测试人员讨论这条Bug的有效性。若此Bug的确需要修正，则由开发人员进行修正后置软件的错误问题状态为解决。　　当测试人员接到相关通知后，测试人员接到相关通知后进行回归测试后若没有问题，则可以关闭这条Bug记录。