我将您的要点总结如下：

1. 报告的错误按严重程度排列优先级。所有被认为“必须修复才能发布”的错误都会被修复和验证。所有其他错误都重新排列优先级并安排在未来的版本中。
2. 创建了最终的候选发布版本，并且所有被认为非常必要的测试用例都已执行并验证为通过。如果在此过程中发现任何错误，则必须重复以确保“干净”的候选版本。
3. 针对最终测试验证期间发现的所有“新”错误执行风险评估。根据风险和严重性对错误进行优先级排序和评估，然后返回到第 1 项。

在一个理想的世界里，当你开始释放时间时，1 和 2 应该是“干净的”，你没有什么可担心的。但这不一定是一个理想的世界，因此需要采用迭代方法来确保，如果在最终运行中发现某些关键问题，您有一个可以返回的地方，以便重新开始并重试，而无需重新做宇宙。

“最佳实践”项目退出标准 - 将使企业能够主观决定是否发货。

这是我所经历的退出标准中有用的项目

--“开放”状态下没有错误 - 即未分类、未审查、未区别（如果是候选人）或未验证（修复后）

-- 已确定测试执行的候选人。原因我说候选人通常不可能在每个候选人构建上执行所有测试。因此团队需要聚在一起，分析更改/修复的风险（自上次运行以来）并就他们的测试活动列表达成一致将被执行。一旦同意与项目所有者（和其他相关利益相关者）一起发布，他们知道并根据计划测试的内容和不测试的内容调整他们的期望，为什么？

--执行以上测试

-- 测试结果公布、分析和分类

-- 任何结果（来自 4 个）修复/重新测试活动已完成

-- 发布的相关文档——发行说明、已知问题、EULA、法律等

- 企业对相关软件版本的任何其他明确和隐含的期望（atrefacts）......

那个声音差不多。不过几个问题：

• “不会修复”是指“不会在此版本中修复”吗？
• “所有测试用例”——如果某些测试用例没有运行会发生什么，例如由于测试设备损坏。在我工作的地方，我们会审查所涉及的风险，并决定行动方案。
• “单一候选版本”——如果添加了小修复会发生什么？你重新运行所有的测试用例吗？如果更改不是主要的，我们倾向于合并多个版本（我知道......这是有风险的）
• “审查了所有测试失败并达成了可接受失败的协议” - 如果仍在调查失败会发生什么？在极少数情况下，我们的错误会持续数周或数月。在这种情况下，可以将已知问题添加到发行说明中。