尽管错误跟踪器可以拥有大量功能，但我觉得这有点矫枉过正，并且正在考虑推出我自己的解决方案。话虽如此，我不想删除任何可能在现有解决方案中经常使用的核心功能。
到目前为止我能想到的那些： - 创建错误 - 分配错误 - 关闭错误 - 向错误添加描述
谢谢！
Rahul Malik
问问题
3164 次
13 回答
6
- 开发者和用户之间的交流。
- 用户能够分配某些信息，例如严重性（该错误与它们的相关程度）。
- 开发人员能够覆盖该优先级，并在可能的情况下给出理由。
- 能够将任务分配给开发人员。
- 能够在错误、增强和功能请求之间进行排序。增强和功能请求之间的区别非常微妙但非常重要。
- 能够附加文件（例如屏幕截图）
- 能够拥有自定义字段（例如能够选择哪个操作系统、哪个服务包级别、应用程序版本等）。
- 能够拥有自定义用户配置文件，这些配置文件还提供有关其硬件的详细信息。能够拥有用户的电话号码（如果他们在您的 LAN 上）也很好，这样您就可以在需要时提出问题。
- 隐私。某些项目，例如安全漏洞或处理财务信息的信息，需要保密。甚至 OSS 也会时不时地这样做，直到他们可以准备好补丁。每个人都有自己的规则。
- 能够显示修订之间的更改，以便您可以通过电子邮件发送更改日志，以便用户知道您有什么和没有做什么。
- 提醒哪些项目未完成并分配给您/根本未分配。
我能想到的就这些了……
于 2008-12-28T03:56:36.000 回答
4
一个很好的搜索引擎。
令人惊讶的是，有多少花费数千美元的错误跟踪产品会出现这种可怕的错误。
如果没有真正体面的搜索，您的错误跟踪更像是一个“错误记录” - 记录并忘记 - 几乎没有用的系统。
于 2008-12-28T05:37:19.400 回答
3
- 创建一个错误
- 关闭一个错误
这足以关闭“错误”实体的生命周期。它是否足以满足您的目的是另一回事。
看看Mantis的特性，选择你需要的特性，计算你编写它们需要多长时间，然后把时间花在更有用的东西上，除非你绝对必须自己创建。;-)
于 2008-12-28T04:36:19.947 回答
2
对于大多数系统，例如错误跟踪系统，通常不是数据的创建或编辑使系统有用。这一切都归结为您可以轻松地浏览信息以在收集数据的基础上“增加价值”。
想想将使用系统的人、程序员、经理等。对于每一组人，什么样的信息会让他们值得一遍又一遍地回到系统中。如何让他们更容易获得这些信息？
收集信息很容易，增加价值是困难的部分。
保罗。
于 2008-12-28T03:38:05.897 回答
1
错误跟踪器只不过是需要完成的事情的列表。
它可以像软件目录中的文本文件一样简单，也可以是拥有数百名用户的成熟错误跟踪器。
从您需要处理的内容开始，然后根据需要进行扩展。
于 2008-12-28T03:36:55.150 回答
1
使用 Jira，您将得到妥善处理。
于 2008-12-28T03:37:43.870 回答
1
以下是一些重要的功能：
- 为错误分配优先级（例如关键、主要、中等、次要、琐碎）
- 将错误分配给将要修复的特定版本
- 观察者功能（因此您可以在状态更改时收到电子邮件）
- 工作流程（即谁在处理它，状态是什么）
于 2008-12-28T04:37:05.577 回答
1
FWIW：当我们推出自己的请求跟踪系统时，我们围绕 procmail 和我们现有的内部 Web 身份验证系统构建了它，因为我们希望它使用起来非常不显眼：我们只是向开发人员发送电子邮件（如果需要，使用组别名) 并在主题中添加“[t]”以打开工单。收件人会收到一封修改后的电子邮件，其中包含原始请求以及指向显示票证的网页的附加链接，并允许他们通过单击鼠标将其关闭。所以最常见的任务是通过电子邮件客户端执行的（打开、请求更多信息、回复……），尽管也有一个简单的网络界面用于搜索等。
只花了几个小时就写完了，在 7 年左右的时间里收到了 34000 多张请求票，我想声称它只有基本的核心功能是可以的：
- 创建票证（通过带有标记主题的电子邮件）
- 关闭工单（单击电子邮件中的链接，然后单击“完成”）
- 所有通信都通过电子邮件进行，而不是通过网络界面（！）
- 原始电子邮件（开张票）的收件人或发件人会收到有关已关闭票证的通知（“主题：<旧主题> 已由 <某人> 关闭”+ 正文中的票证链接，对于大多数人来说足够的信息，因此他们不必去查看是哪个票证/错误等）
- 一个简单的网页界面提供了一个搜索自己/打开/发送/团队票的功能
更大的开发团队/更密集的软件开发可能需要的显着缺失功能：
- 门票的灵活状态（dupe、wontfix、reopened 等）
- 优先事项
- 明确地重新分配票证（在我们的开发团队中，电子邮件只会发给不得不这样做的倒霉蛋）
- 向未发送给所有人的工单添加评论
- 将错误分配给特定版本的软件
YMMV，但到目前为止，它对我们来说非常有效，无论是对于错误还是对于发送者想要跟踪的简单请求。
于 2008-12-28T04:52:17.247 回答
1
分类、优先级和标准化。
以及一种简单的查询方法，以便您可以从上述三个方面的辛勤工作中获得回报。
另外，确保你所做的一切都是可扩展的！我们总是决定在项目期间根据需要/触发添加/编辑我们的错误模板。
那里有很多很棒的解决方案，您可能不需要自己动手。但无论哪种方式，您都必须做出相同的决定。我们使用允许我们推出自己的模板的解决方案，因此在每个项目开始时，我们都会重新讨论相同的讨论。
于 2008-12-28T05:36:11.480 回答
0
定义错误。
考虑到这一点很可能会让您意识到您将花费大量时间“自己动手”。
于 2008-12-28T03:35:03.003 回答
0
这可能有点超出您的想法，但对我来说，与源代码控制集成是必须的。能够查看与错误/问题相关的版本之间的差异非常方便。
于 2008-12-28T03:37:13.200 回答
0
请请不要花太多时间“自己动手”。您最好将时间花在研究和学习使用真正的跟踪系统上。
有些要看
Trac、Bugzilla 和 FogBugz。最后一个为小型（一两个人商店？）公司提供免费托管解决方案。
SO有很多关于这个话题的话题。
尽量不要自己滚动，除非它只是一个 word 文档或电子表格。任何时候你自己做都是浪费。
编辑
既然你不会被劝阻，那么我可能会添加一些其他人没有提到的东西。
您需要报告功能 - 用户需要能够运行查询，并且他们应该能够选择他们想要“查看”的字段。
缺陷的工作流程/生命周期也是一个很好的特性。（基本上是缺陷将经历的状态的状态机。）事实上，这是一个有用的练习，可让您定义所有用例和功能。鉴于你在上大学，并没有从 CS 专业开始，我怀疑你自己会想出很多。花一些时间浏览现有产品的功能列表和演示。
能够将电子邮件发送给各个相关方。
匿名用户能够看到他们输入的特定缺陷
不同的访问级别和权限（管理员、经理、开发人员、测试人员、最终用户）
于 2008-12-28T04:32:15.740 回答
0
我们的错误跟踪系统是我的公司和我们的客户之间的两个重要链接之一（“实时”产品评论，鼓励现有客户提出改进建议，用户界面调整是另一个）。
错误跟踪系统首先必须鼓励与您的客户进行可跟踪的“对话”。它必须回答“您是否解决了我一直遇到的问题（广义定义）？”这个问题。
它必须具有（无特定顺序）：
- 问题或功能请求的简短描述（标题）
- 扩展描述的空间
- 附加文件/图像的能力（截图）
- 优先考虑错误/功能的能力
- 将条目分类为错误、功能、查询等的能力。
- 将错误/功能分配到区域（UI、数据库、文档等）的能力
- 将错误/功能分配给产品的能力（我们跟踪五个产品的错误）
- 将错误/功能分配给版本的能力（“将在 5.1 版中修复”）
- 将错误/功能分配给人员（开发人员/作家）的能力
- 将错误/功能分配给客户（记者）的能力
- 重新分配给其他人（开发人员）的能力
- 解决错误/功能的能力（将它们标记为已完成并准备好进行测试）
- 标记解决状态的能力（已修复、无法修复、无法重现等）
- 关闭错误/功能的能力（在解决和测试后将它们从列表中删除）
- 重新打开错误/功能的能力（如果测试失败，则恢复为“打开”）
- 通知客户错误已解决的能力（例如通过电子邮件）
- 每一步的日期和时间戳（打开、解决、关闭、重新打开）
- 报告开放错误数量的能力！（我们离发布还有多远？）
- 显示错误报告与解决方案的能力
- 按日期、优先级、产品、人员等搜索错误/功能的能力。
- 列出和排序错误以便于扫描的能力！
这些是我们通常在系统中使用的东西 (FogBugz)。虽然这可能看起来很长，但我们确实使用了我在此处列出的所有功能！
于 2008-12-28T05:20:14.723 回答