我最近花了很多时间阅读有关调试的内容。不断引用的一个方面不仅是错误跟踪系统，还包括错误解决过程。我读过关于写下问题的人（这个问题是否有效），测试可以确定修复程序的确定是否有效等等。
所以我在想，“嘿，这是一个好主意”
我现在使用Mantis，它似乎没有这种能力（没有滥用其字段）。 Mantis作为一个bug记录器非常棒。但我认为我正在寻找一些更复杂的界面。
假设我的错误是“裤子脱落”。然后我想将此信息记录为......
“裤子脱落; 2009年2月32日，25：61;当我走进一个房间时，我的裤子掉了下来！”
开发者1 ...
假设1：裤子太大了。
测试1：戴上腰带。
可能的解决方案1：买皮带。
结果= ??结果???
测试2：穿上你妹妹的裤子。
可能的解决方案2：在她上学的时候偷走她的房间并穿上所有的裤子！
结果= ??，日期/时间= ???
开发者2 ...
假设2：你的裤子上有洞。
测试1：照亮它们。
Possibile解决方案：买新裤子。
结果= ???，日期/时间= ???
现在，这是一个愚蠢的例子。但我认为拥有一个软件工具会很棒。 这样的存在，如果存在，它叫什么？
答案 0 :(得分：2)
相信我：你真的不想保持你的错误，这就是你找不到“Bug维护系统”的原因： - ）
对不起......无法抗拒。关于你问题的实际内容：我个人只是跟踪故障单评论历史中的所有信息。大多数情况下，我使用trac是为了它的简单性，但是如果需要的话还可以链接到源代码（至少在文件级别，我希望它能识别代码以便你可以指向AST）。
答案 1 :(得分：0)
您可以使用Testopia，这是Bugzilla的扩展名。当然，这也意味着你需要使用Bugzilla。
取自Testopia网站：
Testopia是Bugzilla的测试用例管理扩展。它旨在成为跟踪测试用例的通用工具，允许测试组织将错误报告与其测试用例运行结果集成。虽然它的设计考虑了软件测试，但它可以用于跟踪工程过程中几乎任何事情的测试。
答案 2 :(得分：0)
我们也使用Mantis，就像Peter Becker所描述的那样，我们使用这些评论来描述bug的工作。这通常有效，因为大多数错误都没有这么长的历史。
如果错误的工作变得如此复杂，需要自己的会议和会议记录，我们通常会在主要的工作计划系统中创建一个任务并在那里进行讨论（从Mantis链接）。这至少对我们有用。
无论如何，我会对尝试明确支持某个工作流程的系统保持警惕，因为这些系统也会将您锁定在他们期望的工作流程中。在bughunting中，工作流程可以从bug到bug变化很大......
最后，请注意Mantis还允许您编辑评论。因此，您可以更改旧的注释，以避免混乱错误报告。