我理解它的简短答案是通过测试，但你仍然如何进行测试？您是修改测试用例以将错误包含为要运行的附加测试用例，还是只是验证错误跟踪系统中从最旧版本到最新版本的所有错误。
感谢您的回答。看来我的问题不清楚。我知道我们需要编写错误报告，修复错误并进行测试以进行修复验证。但是，该测试应该在哪个测试阶段进行，以便在下一个版本发布期间，我们肯定会再次重新运行测试，以确保没有新的更改重新引入错误。它应该接受回归测试还是应该接受针对特定项目的集成测试，或者我们应该只测试自 1.0 版以来的错误跟踪系统中的所有错误？
您创建一个重现问题的自动化测试。然后您解决问题，并确保新测试和所有现有测试仍然通过。
这应该是回归测试，并且应该尽可能自动化。
当你发现一个 bug 时，你需要做的第一件事就是做一个单元测试来演示这个 bug。当你修复它时你会知道，因为测试通过了。您可以避免回归它，因为该测试会突然失败。
你说“你被保护免于回归它，因为那个测试会突然失败”是什么意思？
“单元测试”的重点是它们将作为编译/检查周期的一部分自动运行：您将在编译之后和签入代码之前运行测试。如果单元测试失败，那么您知道某些代码你刚刚写的将重新创建旧的错误。
编辑：
你怎么能确定仅仅因为你的单元测试通过了你的所有错误都已得到修复。
通常，如果您可以重现错误，则可以进行测试以在代码中复制它。最重要的部分是一旦您编写了一个测试来检查是否存在错误，然后如果您运行测试，并且测试失败，那么您重新引入了错误。关于这个主题的一本好书是“有效地使用遗留代码”
单个错误不可能跨越多个单元测试。
当然，它可以跨越多个测试。
假设错误是“无法保存文件”。
让我们假设有几种不同的情况会导致这种情况：
磁盘空间不足，
您正在编写的文件已被另一个进程打开并锁定，
存在权限问题（例如您无法访问目录，或者没有写入权限），
或者在您保存文件时出现网络错误。
理想情况下，您的测试工具（一组测试）将为每个测试工具提供单独的测试。对于某些测试，您可能需要使用称为“模拟对象”的东西（当您还没有为组件编写代码时也可以使用它们）。
系统中的“错误”只是某些功能单元不起作用。通过创建涵盖功能单元的单元测试，您可以知道该工作单元的错误是否再次出现。现在，如果您编写额外的单元测试来测试在类似情况下可能会失败的其他功能领域，您将获得更多覆盖。
也就是说，单元测试只是答案的一部分。为这个错误添加一个测试用例也将有助于防止它发生，但不幸的是它会在开发生命周期的后期并且修复成本更高。
作为 QA，您需要预测因某些修复而受到影响的区域。尽管强烈建议在每次冻结后回归整个构建，但对应用程序进行彻底的测试。
如果这是一个长期项目并且您手头有时间，那么自动化测试是一个很好的做法，但是如果项目是在短时间内以敏捷模型开发的并且不断变化的需求，那么通过手动测试来尝试尽可能地覆盖。
根据您从哪个角度提出问题，您可以以不同的方式解决问题。从开发人员的角度来看，最好使用适当的单元测试检查自 1.0（或更早版本）以来的所有错误，并让它即使使用 CI 也能运行。当变得非常麻烦时，尝试将其分组，每次构建都会运行的基本测试，有些是一天一次，一周休息一次（或其他）。
从 QA/测试的角度来看，它需要更多的努力。
请记住，您必须小心回归测试、测试自动化，并希望检查 1.0 版中的所有错误。也许自 1.0 版以来应用程序发生了很大变化，以至于一些错误不再相关？在基于旧错误构建回归测试时应该考虑到这一点。