产品缺陷/Bug跟踪

软件中的缺陷(Defect或Bug)是软件开发过程中的”副产品”。缺陷的定义可以很广泛,在软件使用过程中所出现的任何一个可疑问题,或者导致软件不能符合设计要求或满足消费者需要的问题都可以是Bug。

每一个软件组织都知道必须妥善处理软件中的缺陷。这是关系到软件组织生存、发展的质量根本。可遗憾的是,并非所有的软件组织都知道如何有效地管理自己软件中的缺陷。 如果没有建立有效的缺陷跟踪管理流程,将可能导致如下的问题:

  • 没有人记录自己发现的缺陷。
  • 无法保证测试人员提交的缺陷报告符合规范要求。
  • 测试人员发现的缺陷可能被开发人员忽略或遗忘。
  • 没有人知道在新的软件版本里,究竟纠正了哪些缺陷,还有哪些缺陷未被纠正。
  • 导致项目的交货期变得非常不可预测。
  • 地域分散的开发团队, 通过email和文档交流,缺陷状态混乱,相关人员无法及时获得有关的变更信息。
  • 无法对缺陷进行统计分析,查找原因并制定相应的预防改善措施。

URTracker在缺陷跟踪方面相对于其他软件的优势

  1. 可以对不同的项目定义不同的人员分组、事务字段和bug处理流程。当某个项目需要客户参与时,您可以创建“客户”组;当需要合作伙伴参与时,可以创建“合作伙伴”组;当市场人员需要参与时,可以创建“市场人员”组。
  2. 以“流转”的方式处理和更新Bug,而不是仅仅通过“编辑”操作(有权限的人都可以进行编辑,而只有bug的当前处理人才能将bug流转到下一个状态和待办人)。
  3. 在流转的过程中控制bug描述字段的填写和更新。如:在测试人员提交bug的时候,并不需要填写“优先级”“故 障原因”“解决方案”等信息。因为测试人员本身无法确定这些信息,这些信息应该由项目经理在分配bug时填写。您可以通过对字段或步骤进行简单的设置即可 实现这样的需求。
  4. 支持多种类型的系统预定义字段和用户自定义字段,支持丰富的输入输出控制特性。
  5. 控制每个工作组人员的权限。比如:
    • 客户或合作伙伴所在的工作组,可以不允许其查看不是自己提交的bug;
    • 只有项目经理所在的组成员可以删除某个bug,或者将bug重分配给另外一个开发人员处理;
  6. 可以对每个字段进行读写权限的控制。比如:对开发人员完成工作情况进行打分的字段,可以对测试人员隐藏。
  7. 可以将bug提交给一个组,组中有条件处理bug的人领取bug。
  8. 可以设置“协同处理人”,协同处理人不能更改bug的状态,但可以提交处理信息。比如,当某个bug需要多个开发人员修复时,可以指定一个主要处理人和多个协作人共同处理。
  9. 同时支持自动和手动通知。自动通知可以设定在某些步骤自动通知创建人、待办人、相关人员、某些组的所有成员或者某些指定的人。手动通知则允许bug的操作人根据需要选择将通知发送给哪些人。可以设置一部分自动通知,另一部分人允许操作人手工选择。
  10. 自动获取并记录“BUG提交人”、“BUG提交时间”、“BUG分派时间”、“BUG修复人”、“BUG修复时间”、“回归测试人”、“回归测试时间”、“回归次数”等数据,方便导出后进行统计、报表和归档;
  11. 根据设定的规则,对符合条件的BUG自动进行到期或超时提醒,自动对BUG进行升级处理;

一般的缺陷跟踪流程

根据项目和团队规模的大小,通常需要不同的缺陷跟踪流程与之适应,从而达到最好的效率和质量控制效果。

对于大部分的产品开发团队而言,可以参考如下的缺陷跟踪流程:

常用的bug跟踪流程(点击查看大图)

使用URTracker实现缺陷跟踪流程

使用URTracker创建一个项目后,经过简单的设置即可实现上述流程。 下面是流程的简单演示:

(1) 测试小组人员提交BUG给项目经理(状态:待分配)

URTracker 创建bug URTracker bug跟踪 测试人员或用户提交新的bug,以及BUG提交后的页面(点击查看大图)

(2) 项目经理根据BUG的详细情况确定处理方案

  • 一般情况下,将BUG分配给某个开发人员处理。这种情况下,项目经理需要输入bug原因分析、解决方案、计划完成时间、要求完成版本等信息。(状态:待解决)
  • 对于经确认不是BUG、已有雷同的BUG记录等情况,可以取消,并返回给测试小组确认可以取消(状态:待取消)
  • 无法重现或其他不适合立即处理的BUG,可以延后处理,并返回给测试小组(状态:延后)

项目经理分配BUG 项目经理取消bug 项目经理分配或取消bug(点击查看大图)

(3) 开发人员接收到“待解决”的BUG后,根据项目经理提供的解决方案进行处理;

  • 如果开发人员无法解决问题,可以“退回”到“待分配”状态,由项目经理决定下一步的措施
  • 处理完毕后,提交给测试小组进行回归测试(状态:待回归)

开发人员退回bug 开发人员回退bug(点击查看大图) bug停留 需要长时间处理时,开发人员可以通过处理bug提交缺陷的修复进展(点击查看大图) 提交回归测试 提交回归测试后的bug信息页面 开发人员修复完成后,提交给测试人员进行回归测试(点击查看大图)

(4) 测试小组回归测试时,根据回归测试的结果,可以执行如下的步骤:

  • 如果回归通过,则关闭BUG(状态:已关闭)
  • 如果回归不通过,则退回给处理该BUG的开发人员(状态:待解决)

回归测试通过,关闭bug 回归测试失败 根据回归测试结果关闭bug或退回给开发(点击查看大图)

(5) 测试小组接到项目经理提交的“待取消”的BUG时,应根据该BUG的严重性及对相关系统的影响,判断该BUG是否可以取消,进行以下操作:

  • 如果确定可以取消时,则关闭BUG(状态:已关闭)
  • 如果确定不可以取消时,则重新提交给项目经理进行重新分配(状态:待分配)

(6) 测试人员接到项目经理提交的“延后”的BUG时,须在必要时提交给项目经理重新进行BUG分配;(状态:待分配)

(7) 如果已关闭的BUG,再次出现时,可以“重打开”BUG,再次提交给相关人员处理。(状态:重打开)

参考文档

本文中缺陷跟踪流程的配置和实现方法,请参见《使用URTracker构造自动化的bug跟踪流程》文档。

案例文档:URTracker缺陷跟踪系统在大型外包企业中的应用




coded by nessus
发表评论?

0 条评论。

发表评论