我对评估错误跟踪器感兴趣，但我想要备份并找出哪些标准在错误软件中最重要。到目前为止，我所想到的事情包括：
稳定性
成本
有什么想法吗？
答案 0 :(得分：11)
易于使用
在我看来，这应该是您要评估的功能列表的顶部。您希望内部开发人员和测试人员能够将他们在软件中注意到的所有内容并将其插入到工具中，即使他们当前正在处理其他事情。为此，该工具必须非常易于使用，以至于不会影响您的数据。最糟糕的错误是那些你不了解的错误。
在屏幕上有15个以上字段的工具，为了能够提交问题，需要10个以上的字段，不是这样的系统。有了这样一个系统，你就可以从测试人员那里得到关于这些小东西的便条。
答案 1 :(得分：3)
在评估BugTracker X时，BugTracker X的开发人员使用哪个bugtracker？
答案 2 :(得分：1)
答案 3 :(得分：1)
关于这个确切的问题有a recent thread on Hacker News。那里有很多好东西！
答案 4 :(得分：1)
API。强制性的。
您必须能够从现场运行的应用程序中捕获并自动将错误提交到您的错误跟踪器中。
答案 5 :(得分：1)
（复制/粘贴“Lasse V. Karlsen”的回答）
您希望内部开发人员和测试人员能够将他们在软件中注意到的任何事物并将其插入到工具中，即使他们目前正在处理其他事情。为此，该工具必须非常易于使用，以至于不会影响您的数据。最糟糕的错误是那些你不了解的错误。
（复制/粘贴结束）
即使是优秀的，尽职尽责的测试人员，如果他们专注于测试组件A但碰巧偶然发现组件B中的错误，如果错误跟踪器中存在大量摩擦，则可能实际上不会输入该错误。摩擦意味着必需的领域。并不是说测试者是坏人还是懒人 - 这只是人类思维的运作方式。我们专注。我们在gorilla suit中没有看到这个人。
Joel / FogBugz哲学中没有必要的领域是正确的（也是我自己的BugTracker.NET的哲学）。您几乎总是可以在以后收集详细信息 - 操作系统，版本，浏览器等等。
另外，如果您的应用有GUI，请查看“Bug Shooting”。您希望让测试人员尽可能轻松地截取屏幕截图并将其放入错误跟踪器中，这对于它来说是一个很好的工具。选择适用于Bug Shooting的追踪器或拥有自己专用的屏幕截图工具。
答案 6 :(得分：0)
分布。我的版本控制系统是分布式的，为什么我的bugtracker不应该？如果我修复了火车上的错误，为什么我能够制作修复但不能记录呢？
答案 7 :(得分：0)
可能是其他人提到的一切，加上我的一些人
如果你有长期的大项目，单独的测试团队将进行功能测试，你应该考虑其他一些事项：
- 可以将错误链接到测试用例（更准确地说是给定的运行）吗？
- 缺陷跟踪系统可以与测试管理系统交换数据吗？
- 它能生成（有用的）报告吗？
- 可以通过发布将错误分组吗？