为什么不建议在同一期/票证中张贴多个缺陷？

我不确定这是否是提出以下概念性问题的地方（肯定不是Stackoverflow）。

我在多项选择题考试（单一答案）中看到了这个问题，类似于ISTQB考试：

为什么不建议在同一期/票证中报告多个缺陷？

一种。为了使报告简洁明了。

b。因为开发人员可能只修复一个错误。

C。因为测试组测试人员是根据发现的错误数量进行评估的。

d。错误管理系统不支持多个错误的此功能。

我唯一的意见是a正确的答案。

b-不能这样，因为fix-feedback-resolved-closed应该避免这种情况。 c-显然是错的。

d -Redmine / Trac插件支持多个字段。

根据答题纸的答案是b。

有人可以解释为什么吗？欢迎对评论提出意见。

试想一下，如果Stack Overflow有一个指导原则：您不问一个问题，而是问一个问题，即在过去两个星期中您遇到的所有问题都在同一个问题中。赞成和反对是什么意思？问题的标题是什么？如何接受最佳答案？如何标记问题？

已完成错误跟踪系统，以...跟踪错误。跟踪错误意味着：

1. 创建一条记录，指出可能存在错误，并提供有关如何重现该错误的信息，

2. 确认确实存在该错误，并且是错误，而不是设计使然，

3. 断言该错误已解决，

4. 确认错误已解决。

在非常简单的模型中，客户将完成1和4，开发人员将完成2和3。

想象以下日志：

• 第一天[客户]在“产品详细信息”窗口中按“删除”按钮时，应用程序挂起。重新启动该应用程序显示该产品未被删除。预期的行为是删除产品。

• 第4天[开发人员] <问题复制>

• 第5天[开发人员] <版本5031中已解决的问题>

• 第12天[客户] <门票关闭：已解决问题>

日志简单明了。您可以轻松地跟踪执行的操作以及何时，哪个修订解决了哪个错误等。例如，如果错误跟踪系统与版本控制集成在一起，则在查看特定修订时，可以检查其中解决了哪些错误。

查找信息很容易。很容易看到它的状态（是否已复制？如果票已关闭，为什么？）。过滤票证很容易（我想显示仅涉及插件UI的票证，因为我只希望开放的，早于一周的票证并由我们的交互设计师分配给我，并且是中或高优先级）。

重新分配票证或最初确定应该由谁负责此错误很容易。

现在想象下面的日志：

• 第1天[客户]当我在“产品详细信息”窗口中按“删除”按钮时，应用程序挂起。另外，左面板的背景色为深蓝色，而应为紫色。我还注意到，“产品详细信息”窗口的文本翻译得不好，德语翻译不正确。是预期的吗？最终翻译何时可用？顺便说一句，您是否收到了我为“发布产品”操作发送的新图标？我在“同步数据”窗口中看不到它。

• 第6天[开发人员]我将颜色更改为紫色。

• 第7天[开发人员]是的，德语翻译不完整是很正常的。

• 第8天[客户]可以。那意大利语呢？Lucia两天前向您发送了XML文件。

• 第9天[开发人员]现在可以了。

• 第10天[客户]可以使用“删除”按钮吗？奇怪，在我的计算机上，它仍然挂起。

• 第11天[开发人员]不，我想说意大利语翻译没问题。

• 第12天[客户]我知道了。谢谢。但是颜色有问题。您已将其更改为深紫色，但应为浅紫色，就像主窗口的顶部面板一样。

• 第13天[开发人员]我更新了图标。

• 第14天[客户]图标？什么图标？

• 第15天[开发人员]您要求我更新的图标。

• 第16天[客户]我从未要求您更新任何图标。

• 第17天[开发人员]当然可以了。看到这张票。您写道应该更新发布产品图标。我做完了

  ⁞

• 第100天[客户]那么，日志中的条目呢？

• 第101天[开发人员]我不知道您在说什么。它甚至不在这张票中，而是在6199中。我已经解决了这个问题。<门票关闭：问题已解决>

• 第102天[客户]很抱歉，重新打开它，但问题仍未解决。我正在谈论日志中的条目：上周我告诉您，当文本包含Unicode字符时，该文本有时无效。你是否记得？<门票重新开放>

• 第103天[开发人员]我依稀记得类似的事情，但是在搜索了该票证的最后三页之后，我找不到任何痕迹。您能再写一个问题吗？

  ⁞

• 460天[开发人员]我花了两个小时来寻找您所说的关于通过网络加密发送的文件的记录。我不确定是否可以找到确切的要求。

• 第460天[客户]你们真的应该更有条理。在过去的两个星期中，我已四次通知您有关此问题的信息。你为什么忘记了一切？

  ⁞

这是什么日志？解决了43次，然后重新打开了43次。这是否意味着开发人员如此愚蠢，以至于他无法在460天内解决同一问题？啊，不，等等，同时将此票分配给了11个开发人员。这是怎么回事？如何搜索特定问题？它实际上是分配给Vanessa的，但此票证中的11个问题中有7个问题也让她的5个同事感到担忧。何时应关闭车票？问题解决一半了吗？也许是十一分之十？

注意：您可能认为这样的日志不存在。相信我，我已经看过不止一次了。

只是对您的陈述发表评论：

不能，因为fix-feedback-resolved-closed应该避免这种情况

假设所有提出的错误将在同一时间被修复。想象一下一个场景，其中针对产品v1发出了票证，但有两个问题：

1. 表单重置按钮实际上是提交表单，而不是清除值
2. 按钮上的字体大小应为115％时为110％。

对于测试人员来说，两者都是正确的，因为它们都是实现的错误。但是，假设产品负责人确定第一个子任务是要发布的阻止程序（即必须在产品上线之前修复它），而第二个任务是次要问题（即可以在v1中修复）。 1版）。

在这种情况下，我们别无选择，只能将＃2分成自己的票证（否则可能会忘记）。如果我们能够做到这一点，则意味着它们可以彼此独立地实现，测试和部署，在这种情况下，从一开始就解决单个问题是有意义的。

范围：

这个答案（和问题）似乎仅适用于代码缺陷的跟踪，在这些缺陷中，源代码未按照规范或程序员的意图执行。

相反，GUI缺陷票证通常包含多个规范，因为每个GUI票证实际上都是“重新设计”（设计缺陷），“修订规范”或“功能请求”（缺少功能）。

缺陷跟踪的一个重要目的是在多个角色（程序员，测试人员，客户和经理）之间进行沟通和协调。

在代码质量具有重要意义的项目中（例如，与用户友好性相比），缺陷跟踪可能包含多个方面，其中之一将侧重于代码缺陷的跟踪，而与增强和客户支持请求的跟踪不同。

代码缺陷跟踪系统的目的是：

• 为了能够独立，明确地跟踪可独立复制的缺陷，并且
• 为每个缺陷的根本原因提供最佳近似（一对一对应）。

在这样做时，它应该最大化以下期望的质量：

• 随着缺陷数量的增加，有效地扩展规模。
• 预防移动目标综合症。

免责声明：此表述来自我的个人经验。对于认证考试目的，可能不足或不正确。

独立而明确的跟踪意味着：

1. 每个有效的缺陷既可以解决或者没有解决，毫不含糊。

   • 原因1：为简化管理，
     • 示例：它允许使用“未解决的票证数量”作为度量标准。
   • 原因2：转换为可行的项目
     • 示例：如果未解决，则责任由分配的程序员负责。如果解决了但未解决，则责任在于分配的测试人员（验证者）。
   • 结果：在这种方法中，部分解决的缺陷应分解为几个相关的缺陷。

2. 应独立跟踪可独立复制的缺陷。

   • “可独立复制”是指它们可以具有不同的状态。一个看起来似乎是固定的，而另一个则保持损坏。
   • 原因：为了最大程度地减少缺陷跟踪和根本原因分析之间的不匹配。
     • 可以追溯到代码缺陷的每个根本原因被认为需要至少一个代码更改。
     • 如果两个缺陷可以独立再现，那么将需要进行多次代码更改。
     • 如果两个缺陷是可独立复制的，则必须都对它们进行测试（验证），因为一项测试的通过并不意味着另一项测试将通过。
   • 例2：如果最初认为两个症状具有相同的根本原因，因此被归类为同一票证，后来又证明它们是可独立再现的，则应将其分为两个票证。

从使用该系统的其他人的角度来看它，几个月后出现。他们在程序中发现错误。他们在Google周围搜寻，发现有一张与他们遇到的问题相符的支持票。嘿，它已关闭！太棒了！它已在最新版本中修复！所以，他们更新了……而这个错误仍然存​​在吗？这些愚蠢的开发者怎么了？！？

没事，实际上。事实证明提交错误报告的人有问题。他们在同一张票中提交了两个错误。一个很容易修复，很快就被修复，而另一个则不然。即使您使用诸如fix-feedback-resolved-closed之类的方法，也仍然不足以了解正在发生的事情，尤其是对于外部观察者而言。

最好给每个错误分配自己的票证，并且如果您有多个相关但显然不同的错误，则大多数错误跟踪系统都具有一项功能，可让您将一个错误链接到另一个错误。（如果没有，则可以将其放入报告中。“另请参见错误＃12345。”）