你如何确保第二次同样的bug不会进入产品？

Question

我理解简短的答案是通过测试，但你仍然如何进行测试？您是否修改了测试用例以将错误包含在运行的其他测试用例中，或者您只是验证错误跟踪系统中从最旧版本到最新版本的所有错误。

感谢您的回答。看起来我的问题不明确。 我知道我们需要编写bug报告，修复bug和＆amp;进行修复验证测试。但是，在下一个版本发布期间，测试阶段应该在下一个版本发布期间，我们确保再次重新运行测试以确保没有新的更改重新引入该错误。是应该进行回归测试还是应该针对该特定项目进行集成测试，还是应该从1.0版开始测试bug跟踪系统中的所有错误？

Answer 1

您创建了一个可以重现问题的自动化测试。然后，您可以解决问题，并确保新测试和所有现有测试仍然通过。

---

这应该是回归测试，并且应尽可能自动化。

Answer 2

当您发现错误时，您需要做的第一件事是进行单元测试以演示错误。你知道什么时候修好它，因为测试通过了。你被保护不会退回，因为那个测试会突然失败。

Answer 3

  

你是什么意思说“你是   免于退化，因为   那个测试会突然失败。“？

“单元测试”的意思是它们将作为编译/检查周期的一部分自动运行：您将在编译之后和检查代码之前运行测试。如果单元测试失败，那么您知道一些你刚写完的代码会重新创建旧的bug。

编辑：

  

你怎么能这么肯定   因为你的单元测试全部通过   你的错误已得到修复。

通常，如果您可以重现错误，可以进行测试以在代码中复制它。最重要的部分是，一旦你编写了一个测试来检查bug的存在，然后如果你运行测试，并且测试失败，那么你重新引入了bug。关于这个主题的一本好书是"Working Effectively with Legacy Code"

  

单个错误是不可能的   跨多个单元测试。

当然它可以跨越多个测试。

我们假设该错误是“无法保存文件”。

让我们假设有几种不同的情况可以导致这种情况：

• 磁盘空间不足，

• 你正在写的文件是 由另一个进程打开并锁定，

• 存在权限问题（如 你无法访问该目录，或 没有写权限），

• 或者存在网络错误 你要保存文件。

理想情况下，您的测试工具（测试集合）将针对每个测试工具进行单独测试。对于某些测试，您可能需要使用称为“模拟对象”的东西（当您还没有为组件编写代码时也可以使用它们。）

Answer 4

1. 获取错误报告
2. 编写测试用例以重现错误报告
3. 修复错误
4. 享受不必再次修复该错误

Answer 5

系统中的“错误”只是某些功能单元无法正常工作。通过创建涵盖功能单元的单元测试，您可以了解该工作单元是否再次出现该错误。现在，如果你编写额外的单元测试来测试在类似情况下可能会失败的其他功能区域，你将获得更多的覆盖。

那说单元测试只是答案的一部分。为这个bug添加一个测试用例也有助于防止它发生，但不幸的是它将在开发生命周期的后期发生并且修复起来更加昂贵。

Answer 6

作为质量保证，您需要预测因某些修复而受到影响的区域。尽管强烈建议在每次冻结后对整个构建进行回归，但Thorougly会测试相同的应用程序。

如果它是一个长期项目并且您有时间，那么自动化测试是一个很好的做法，但是如果项目是在短时间内以敏捷模型开发并且需要更改，那么请使用手动测试试图尽可能地覆盖。

Answer 7

根据您提出的观点，您可以通过不同方式攻击问题。 从开发人员的角度来看，最好是通过适当的单元测试检查1.0（或更早）的所有错误，并让它在CI中运行。当它变得非常麻烦时尝试将它分组，每次构建运行的基本测试，每天一次，每周休息一次（或某事）。

从质量保证/测试的角度来看，它需要更多的努力。

1. 准备回归诉讼申请。主要业务流程/用例，快乐路径。把它作为你的基准。在任何情况下都必须失败的测试集。在发布之前或进行大的更改时，在进行许多更改时，在修改关键部件时始终运行它。付出一些努力使其自动化（这次我不是在讨论单元测试，而是完整的应用程序测试）。
2. 比创建回归测试适合应用领域。比以前的西装更多的测试，但每个回归适合不同的应用领域。更改应用程序的一部分时，请对该部分运行回归。它可以自动化，但很难为经常变化的区域维护测试。
3. 教育您的qa团队在开始处理某些需求/功能的测试时查看bug存储库。如果它们看似相关，他们应检查以前的错误。

请记住，您必须小心使用回归测试，测试自动化以及检查版本1.0中的所有错误。也许应用程序自版本1.0以来发生了很大变化，以至于某些错误不再相关？在根据旧错误构建回归测试时应该考虑到这一点。