软件中的缺陷（Defect或Bug）是软件开发过程中的”副产品”。缺陷的定义可以很广泛，在软件使用过程中所出现的任何一个可疑问题，或者导致软件不能符合设计要求或满足消费者需要的问题都可以是Bug。
每一个软件组织都知道必须妥善处理软件中的缺陷。这是关系到软件组织生存、发展的质量根本。可遗憾的是，并非所有的软件组织都知道如何有效地管理自己软件中的缺陷。 如果没有建立有效的缺陷跟踪管理流程，将可能导致如下的问题：
- 没有人记录自己发现的缺陷。
- 无法保证测试人员提交的缺陷报告符合规范要求。
- 测试人员发现的缺陷可能被开发人员忽略或遗忘。
- 没有人知道在新的软件版本里，究竟纠正了哪些缺陷，还有哪些缺陷未被纠正。
- 导致项目的交货期变得非常不可预测。
- 地域分散的开发团队， 通过email和文档交流，缺陷状态混乱，相关人员无法及时获得有关的变更信息。
- 无法对缺陷进行统计分析，查找原因并制定相应的预防改善措施。
URTracker在缺陷跟踪方面相对于其他软件的优势
- 可以对不同的项目定义不同的人员分组、事务字段和bug处理流程。当某个项目需要客户参与时，您可以创建“客户”组；当需要合作伙伴参与时，可以创建“合作伙伴”组；当市场人员需要参与时，可以创建“市场人员”组。
- 以“流转”的方式处理和更新Bug，而不是仅仅通过“编辑”操作(有权限的人都可以进行编辑，而只有bug的当前处理人才能将bug流转到下一个状态和待办人)。
- 在流转的过程中控制bug描述字段的填写和更新。如：在测试人员提交bug的时候，并不需要填写“优先级”“故 障原因”“解决方案”等信息。因为测试人员本身无法确定这些信息，这些信息应该由项目经理在分配bug时填写。您可以通过对字段或步骤进行简单的设置即可 实现这样的需求。
- 支持多种类型的系统预定义字段和用户自定义字段，支持丰富的输入输出控制特性。
- 控制每个工作组人员的权限。比如：
- 客户或合作伙伴所在的工作组，可以不允许其查看不是自己提交的bug；
- 只有项目经理所在的组成员可以删除某个bug，或者将bug重分配给另外一个开发人员处理；
- 可以对每个字段进行读写权限的控制。比如：对开发人员完成工作情况进行打分的字段，可以对测试人员隐藏。
- 可以将bug提交给一个组，组中有条件处理bug的人领取bug。
- 可以设置“协同处理人”，协同处理人不能更改bug的状态，但可以提交处理信息。比如，当某个bug需要多个开发人员修复时，可以指定一个主要处理人和多个协作人共同处理。
- 同时支持自动和手动通知。自动通知可以设定在某些步骤自动通知创建人、待办人、相关人员、某些组的所有成员或者某些指定的人。手动通知则允许bug的操作人根据需要选择将通知发送给哪些人。可以设置一部分自动通知，另一部分人允许操作人手工选择。
- 自动获取并记录“BUG提交人”、“BUG提交时间”、“BUG分派时间”、“BUG修复人”、“BUG修复时间”、“回归测试人”、“回归测试时间”、“回归次数”等数据，方便导出后进行统计、报表和归档；
- 根据设定的规则，对符合条件的BUG自动进行到期或超时提醒，自动对BUG进行升级处理；
一般的缺陷跟踪流程
根据项目和团队规模的大小，通常需要不同的缺陷跟踪流程与之适应，从而达到最好的效率和质量控制效果。
对于大部分的产品开发团队而言，可以参考如下的缺陷跟踪流程：
常用的bug跟踪流程(点击查看大图)
使用URTracker实现缺陷跟踪流程
使用URTracker创建一个项目后，经过简单的设置即可实现上述流程。 下面是流程的简单演示：
(1) 测试小组人员提交BUG给项目经理（状态：待分配）
测试人员或用户提交新的bug，以及BUG提交后的页面(点击查看大图)
(2) 项目经理根据BUG的详细情况确定处理方案
- 一般情况下，将BUG分配给某个开发人员处理。这种情况下，项目经理需要输入bug原因分析、解决方案、计划完成时间、要求完成版本等信息。（状态：待解决）
- 对于经确认不是BUG、已有雷同的BUG记录等情况，可以取消，并返回给测试小组确认可以取消（状态：待取消）
- 无法重现或其他不适合立即处理的BUG，可以延后处理，并返回给测试小组（状态：延后）
项目经理分配或取消bug(点击查看大图)
(3) 开发人员接收到“待解决”的BUG后，根据项目经理提供的解决方案进行处理；
- 如果开发人员无法解决问题，可以“退回”到“待分配”状态，由项目经理决定下一步的措施
- 处理完毕后，提交给测试小组进行回归测试（状态：待回归）
开发人员回退bug(点击查看大图) 
需要长时间处理时，开发人员可以通过处理bug提交缺陷的修复进展(点击查看大图) 
开发人员修复完成后，提交给测试人员进行回归测试(点击查看大图)
(4) 测试小组回归测试时，根据回归测试的结果，可以执行如下的步骤：
- 如果回归通过，则关闭BUG（状态：已关闭）
- 如果回归不通过，则退回给处理该BUG的开发人员（状态：待解决）
根据回归测试结果关闭bug或退回给开发(点击查看大图)
(5) 测试小组接到项目经理提交的“待取消”的BUG时，应根据该BUG的严重性及对相关系统的影响，判断该BUG是否可以取消，进行以下操作：
- 如果确定可以取消时，则关闭BUG（状态：已关闭）
- 如果确定不可以取消时，则重新提交给项目经理进行重新分配（状态：待分配）
(6) 测试人员接到项目经理提交的“延后”的BUG时，须在必要时提交给项目经理重新进行BUG分配；（状态：待分配）
(7) 如果已关闭的BUG，再次出现时，可以“重打开”BUG，再次提交给相关人员处理。（状态：重打开）
参考文档
本文中缺陷跟踪流程的配置和实现方法，请参见《使用URTracker构造自动化的bug跟踪流程》文档。
0 条评论。