|
无 bug 不软件，你懂的。所有人都有他们邪恶的一面，所有的开发者都会在项目中犯错，即使是精心打造的程序也会掉链子。初看上去，记录和处理软件产生的错误信息是很容易的任务。但随着一个又一个版本的出现，已知的错误可能变多也可能变少。“送走旧的错误，又迎来了新的错误”——这是关于开发者的一个老笑话。为了控制错误，一个绝妙的产品横空出世，人们称它为缺陷跟踪系统。
缺陷跟踪系统是帮助程序员、测试员、项目经理搜集和控制软件中发现的错误（缺陷），并对消除这些错误的过程进行监控的一套软件。换句话说，缺陷跟踪系统有助于跟踪和组织缺陷。
| 名称 |
特色 |
费用 |
被Ubertesters支持 |
| Bugzilla |
-
耗时追踪
-
私人附件和评论
-
灵活的报告和图表
-
增加自定义字段和工作流
-
查看所有特色。
|
免费 |
是 |
| JIRA |
|
每月 $10 起 |
是 |
| Mantis |
-
耗时追踪
-
问题变更历史
-
与源代码管理集成
-
支持多个项目
-
浏览 BugTracker
|
免费 |
是 |
| Redmine |
-
耗时追踪
-
具备甘特图的项目管理
-
LDAP 认证
-
项目维基
-
查看所有特色
|
免费 |
是
|
锦上添花的是，正如Ubertesters 拥有易用的 bug tracker中所述，你不仅可以将所有报告集中到一个地方，还能在你的 Ubertesters 账号中直接管理它们。
有一点要记住的是，那些在很长一段时间里都存在的缺陷是最恼人的。注重既快速又频繁的发布使你在开发者和测试者之间建立起紧密的反馈关系，帮你避免缺陷队列里留存大量尚未处理的缺陷报告。当你在制作一份关于某个缺陷的报告时，你需要将完整的信息都包含在你的缺陷报告中。你会遇到出现误解的情况，也会遇到重要信息缺失的情况。在这些情况下，开发者和测试者之间的沟通就变得很有必要。为了避免这种事情，要团结所有团队成员，在面向反馈的文化气氛中工作。讨论缺陷并将其推进到下一阶段是个漫长的过程。你最好逐一对待它们。你的每个缺陷都要关联两个专业人员，可以称他们为问题发现者（测试者）和问题解决者（开发者）。无论有多少开发者和测试者在做你的项目，你只需要两种不同角色和功能的专业人员，他们要对解决已有问题负责。针对缺陷报告里的现有缺陷，避免表达你个人观点的评论。取而代之的是电子邮件或图表工具。你的缺陷报告里只能包含用于监测和修复缺陷的有关内容。当你遇到有必要对bug的状态进行讨论的情况时，如下的几个问题将帮助你做出正确的决定: 谁应该为发出指令 (或者报告bug) 负责, 谁负责接收结论 (当前问题的解决方案)? 对于‘关闭了的bug’, 其意义总是由解决了该问题的开发者所关闭的bug. 确保负责关闭一个bug的人和报告该它的人是同一个人，因为只有这个人才能对方案是否足够解决这个问题负责.尝试只使用两种状态标识bug: 打开的bug和关闭的bug.避免在bug的不同的状态上浪费你的时间，而是专注于问题的可能的解决方案.
|
