Bug管理工具对项目实施过程中的实践过程及重要作用

Posted on Posted in 经验分享
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记录。