0

我最近花了很多时间阅读有关调试的信息。不断引用的方面之一不仅仅是错误跟踪系统，而是错误解决过程。我读到有人写下对问题的看法（有效或无效），测试将确定给定的修复方法是否有效，等等。

所以我在想，“嘿，这是个好主意”

我现在使用 Mantis，它似乎没有这种能力（没有滥用它的领域）。Mantis 非常适合作为错误记录器。但我认为，我正在寻找界面更复杂的东西。

例子

假设我的错误是“裤子掉了”。然后我想将此信息记录为...

“裤子掉了，2009年2月32日25点61分，我走进房间，裤子掉了！”

开发商一...

假设1：裤子太大。

测试一：系上腰带。

可能的解决方案 1：购买皮带。

结果 = ?? 结果 ？？？

测试2：穿上你妹妹的裤子。

可能的解决方案 2：在她上学的时候偷走她的房间并拿走她所有的裤子！

结果 = ??，日期/时间 = ???

开发商 2...

假设 2：你的裤子上有洞。

测试1：照亮他们。

可能的解决方案：购买新裤子。

结果 = ???，日期/时间 = ???

现在，这是一个愚蠢的例子。但我认为拥有作为软件工具会很棒。是否存在，如果存在，它叫什么？

4

3 回答 3

2

相信我：你真的不想维护你的错误，这就是为什么你找不到“错误维护系统”:-)

抱歉……忍不住了。关于您问题的实际内容：我个人只是在票的评论历史记录中跟踪所有这些信息。大多数情况下，我使用trac是因为它的简单性，但也可以在需要时链接到源代码（至少在文件级别，我希望它能够识别代码，以便您可以指向 AST）。

于 2009-03-22T23:24:13.253 回答
0

您可以使用Testopia，它是Bugzilla的扩展。当然，这也意味着您需要使用 Bugzilla。

取自 Testopia 网站：

Testopia 是 Bugzilla 的测试用例管理扩展。它旨在成为跟踪测试用例的通用工具，允许测试组织将错误报告与其测试用例运行结果集成。尽管它在设计时考虑了软件测试，但它可用于跟踪工程过程中几乎所有内容的测试。

于 2009-03-23T00:09:36.670 回答
0

我们也使用 Mantis，就像 Peter Becker 所描述的那样，我们使用注释来描述关于 bug 的工作。这通常是有效的，因为大多数错误没有这么长的历史。

如果一个 bug 的工作变得如此复杂以至于需要自己的会议和会议记录，我们通常会在我们的主要工作计划系统中创建一个任务并在那里进行讨论（来自 Mantis 的链接）。这至少对我们有用。

无论如何，我会警惕试图明确支持特定工作流程的系统，因为这些系统也会将您锁定在他们期望的工作流程中。在寻找错误的过程中，工作流程可能因错误而异...

最后，请注意，Mantis 还允许您编辑您的评论。因此，您可以更改旧注释以避免混淆错误报告。

于 2009-03-23T00:11:56.180 回答