#1 楼
您如何防止错误再次发生？在大多数情况下，此问题的答案是测试用例。现在这个测试用例去哪里了？到现有的测试计划或套件中，最好是自动化的。
修复缺陷
测试修复程序（手动，探索性或自动化）
做个根目录-原因分析
创建测试用例/步骤/计划，以防止根本原因再次发生
执行所有其他测试
发布修复程序
因此，是的，您确实需要测试错误修复程序，肯定是在客户端报告时，因为不同的用户可能报告冲突的错误。这可能会导致两个类似问题之间出现乒乓状态，每次发布时，错误都会返回给另一个客户端。
但是，不，您不应该为每个错误修复程序创建完整的测试计划，只需将测试用例添加到现有计划中即可。如果您没有测试计划或没有合适的时间来开始制定计划，请执行以下操作：）
您可以进行小风险分析，并想知道再次破坏它会带来什么风险。根据此决定，您的团队应投入多少测试工作。
#2 楼
这取决于您公司的首选方法。您应该保留为验证修正而执行的测试用例的记录，但很可能不需要任何形式的测试计划。取决于修复程序的实现方式，尤其是在测试旧代码时，您可能希望执行发现错误的产品的其他测试计划，以确保错误修复不会造成更多问题。
#3 楼
我建议您将新测试添加到回归包中，以确保将来可以使用它们。我假设您将在发布之前进行某种形式的回归，因此在两者之间您将获得更好的覆盖范围和今后的文档资料
#4 楼
这取决于公司的内部政策以及团队的组织方式。通常，如果您是团队中唯一的质量检查人员，则负责计划和执行固定的错误测试。
不管开发人员是否仍在您公司工作，确保您的软件满足客户期望仍然是您公司的工作。
#5 楼
如果每个修补程序都有一个错误，那么我将使用这些错误记录每个修补程序的测试方式以及问题是否得到纠正。正式的测试计划对我来说似乎太过分了。#6 楼
我建议：理想的做法是，我们跨规范编写测试用例
当我们观察到任何错误时，如果它的步骤类似于任何测试用例，那么就可以了[不需要更新测试计划]
但是，如果错误的测试步骤与任何测试用例都不相同，则应在测试计划中添加这些步骤，并且该错误将成为一个测试用例。
在我们的软件领域，团队应保持经常变化[很多时候，不是每次都在任何地方都变化]因此，请保持较少依赖的做法
无论角色如何，都要不断更新团队以观察到错误并在同一页面上测试结果
#7 楼
我不会在主测试计划中添加错误验证，因为这会堆积不必要的测试用例，毕竟，一旦您确认了修复程序，就不再需要检查此特定用例。但是请考虑-
如果适用，将错误的根本原因添加到计划中
在最近的版本中添加一些验证测试，但也要牢记分支和合并策略因为错误可能在将来再次出现