问题标签 [bug-tracking]

什么是解析带有错误描述的电子邮件的最佳方法。一位客户最近决定，如果用户能够向已知邮箱发送电子邮件并且错误将在错误跟踪器中注册（不完全关闭），这将是一件好事。

问题是错误描述有很多字段，如日期、时间、描述、评论、丢失、附件等。依靠用户使用某些特定的邮件格式并不是最明智的做法。

问题是如何解析电子邮件以获取所有需要的信息。格式不应该太严格，但足以猜测哪些字段是什么意思。我也有兴趣听到正确和最简单的解决方案。

PS 实际上这个功能是银行要求的。他们有一个公共邮箱，客户可以在其中发送发现的问题。问题是在银行员工真正看到之前从这些信件中获取尽可能多的信息。

我们的团队目前正在审查我们的工具集，并在源代码控制和项目管理软件之外寻找新的缺陷/问题跟踪软件。

对于问题跟踪，我们查看了 bugzilla、fogbugz、bugtracker.net、sourcegear fortres 和 bugnet。

我对我们提出的清单不满意，所以我很想知道其他人正在使用什么。

我们正在寻找用于安全的 Active Directory 集成，虽然我们会满足于 Windows 应用程序，但 Web 界面可能是首选，Visual Studio 集成也是一个奖励。我们需要确定缺陷的优先​​级，标记发现缺陷的版本，标记修复缺陷的版本，并希望能够围绕每个问题/缺陷进行讨论。我们还希望将项目分类为缺陷、增强请求等，并记录缺陷的解决方法。

非常相似的问题：

https://stackoverflow.com/questions/101774/what-is-your-bug-task-tracking-tool

我们现在在您的开发过程中遇到的问题是，有几个人没有让团队更具跨职能。

因此，有时这些人可能会成为项目某些部分的瓶颈。他们不喜欢将Wiki用于共享知识问题，他们不会在问题跟踪系统中为他们的工单发布足够的评论。

由于这个问题，我们的管理层有时不能解雇一些开发人员（即使他们非常想要），因为没有他我们会花很多时间来了解他做了什么。

我认为，仅通过code-review无法解决此问题，因为有时无法注意到，没有为票证生成足够的文档，直到您遇到问题。

在我们的情况下不能应用结对编程，因为团队是分布式的。

我们在会议上讨论了很多这个问题，但它似乎更像是概念问题。我们能改变这个人的态度吗？如何解决这个问题？

格式化错误报告有多重要？它应该包含什么？

我通常在错误报告中看到以下部分：

• 重现步骤
• 我所看到的
• 我必须看到的
• 解释

格式化错误报告的最佳解决方案是什么以及它应该包含什么？

我想了解事件周期。我有一个带有网格和文本框的表单。它有一个网格，绑定到 DataTable，文本框也绑定到同一个表。我正在尝试调试某些东西，并且需要知道如何识别表单中触发的所有事件，以查看可以为我解决问题的方法。

无论如何，除非我明确地对表单上的每个类进行子类化，并将每个事件覆盖/附加到我自己的事件处理程序，否则我如何获取/侦听在某个操作期间触发的所有事件......例如更改“已选择” DataGridView 中的道路。它显然更新了自己的“CurrentRow”......我需要知道什么/如何强制重新加载 SAME CurrentRow。

原因：在表单级别“编辑模式”期间，我更改了另一个“文本框”控件中的内容，并拒绝更改，我需要它来模拟当前“记录”被重新加载以恢复其原始值。

在我目前的公司中，测试和开发团队之间对于错误的严重程度并不清楚吗？有一些争论来回减少或增加严重性。我们目前不知道有任何文件规定了规则。测试人员根据他的直觉提出错误并分配优先级。开发人员会根据他的负载或其他因素请求更改。

错误的严重性/优先级如何分类？是否有任何标准可以指导如何根据客户需求、时间线和其他因素确定软件缺陷优先级？

在过去的 15 个月里，我一直在使用 JIRA，现在我发现自己在一个使用 Trac 的项目中。如何仅通过 Trac 中的票号查找票？我习惯于在 JIRA 的右上角输入票值，然后它会找到一张票。我在 Trac 中尝试过同样的事情，但没有那么幸运。

我的团队正在寻求将我们的许多工具（SCM、错误跟踪、构建、测试）迁移到 TFS。我们正在考虑分阶段移动每个系统。例如，首先移动源代码控制，然后是错误/功能跟踪等……

由于我们必须选择一个流程模板来使用源代码控制（或 TFS 中的任何东西），我们对决策的锁定程度如何？我希望避免以后必须创建另一个项目（或者这不像我想象的那么糟糕？）。

我知道我理论上可以在事后自定义流程模板配置的所有内容（对吗？），但这在实践中有多可行？

以下是我对事情发生的看法：

1. 我们迁移我们的源代码。我们选择微软的 CMMI 模板。
2. 我们创建了一个新的工作项（或签到说明），它是我们遗留错误跟踪系统的简单链接。
3. 我们工作一段时间。
4. 我们等到有权力（我们是一家规模相当大的软件公司）制定新的 TFS 开发工作流程。这可能是新工作项的简单集合或配置各种东西的全新模板。
5. 我们尝试在不丢失历史记录的情况下将我们的 TFS 项目迁移到这个新系统。

我们是否会后悔我们没有等到所有这些决定都完成后才使用 TFS？

我今天搜索了一整天，发现了无数（嗯，好吧——几十个）Bug Tracker，有些是免费的，有些是托管的，有些非常昂贵。我很快意识到我没有时间花时间评估它们（特别是因为它们中的许多似乎有很多我们永远不会使用的特性）。

这是我的适度要求列表（至少我认为它们是适度的）：

1. 低成本（或免费）：假设拥有 100 美元 +/- 或每月 10 美元 +/- 托管
2. 基于 PHP/MySql（如果我们要拥有）- 托管，一切都很好
3. 易于安装（FTP，然后设置数据库，然后编辑 config.php 之类的东西）
4. 请只是基础知识（基本提交/更新/提交错误）
5. 体面的归档/关键字标记/搜索机制

其他任何东西（如维基、电子邮件、论坛、图表等——不需要）。我们已经有一个帮助台系统（HelpSpot），所以也不需要那个。

我想我可以自己写一个快速的，或者只是在我们的内部 Wiki 上创建页面，但是在错误跟踪世界中不存在这种轻量级的东西吗？如果你们中的任何人有好的建议，我不介意评估接近上述要求的 3 或 4 个。

非常感谢 -

添加

前几个建议是针对 FogBugz 和 Bugzilla 的。我看了两者，虽然它们都非常好（尤其是 FogBugz），但它们的功能太多了，无法满足我们的需求。我正在寻找的（如果存在的话）是更基本的东西。谢谢~

我在 IT/开发部门，通知代码更改的唯一方法是向小组 (development@company.com) 发送电子邮件。所以我们有很多电子邮件。

我想设置电子邮件组，以便发送到该组的所有电子邮件都存储在一个地方。我们使用 Exchange，所以我想将它们自动存储在 Exchange 在线文件夹中。遗憾的是，有人告诉我那些交换文件夹不再是最新版本的 Exchange。

我的第二个选择是一个内部博客，比如 Wordpress，所有的电子邮件都被发布、标记和访问以供搜索。

• 有没有人用博客软件记录群组邮件？
• 您还使用了哪些其他方法来记录这些电子邮件？

请注意：我正在建立一个错误跟踪器，但我相信需要很长时间才能激励开发人员使用它。同时，我需要这种其他方法。

更新

请注意：

• 我们没有源代码控制（也没有机会做到这一点）
• 我们没有错误/问题跟踪，但我希望在今年年底之前有一个。
• 我工作的人太习惯于通过电子邮件通知他们所做的更改。将这些电子邮件存储在一个地方以进行搜索将是理想的选择。