都能测试完其实问题都不算太大，对整体项目质量都有一个预期了。

比较可怕的是都测不完就让上。一般根据实际情况调整测试策略，实在来不及就基于风险做测试。

真到了这种地步强行上线，直接发邮件整个项目通报就好，把锅甩好就行

只要老板说没问题，发布，遗留多少 bug 都行。老板都说可以了，你还非要给老板上一课吗

说说我这边的做法。国内项目研发都是业务为先，一般情况下，到了快要发布的时间节点（半天前），如果还有遗留问题，就会跟项目经理、业务方同步现在的情况。哪些问题需要一定修复，修的话有没延期风险，不修的话会有什么风险，大家对齐了之后，再决定发不发布。

在我们单位，如果到达规定上线时间仍有 bug 未解决，需要测试团队评估 bug 影响范围，并和项目经理沟通未解决 bug 是否可以延期处理。如果项目组同意 bug 可以延期处理，就可以上线了，若不同意，则推动开发修改，延期上线。

更新内容没有太严重的 BUG 就先上线，持续观察线上情况（冒烟必定确认各个基础功能没有问题）

有一个 DI 值计算公式，一个致命的 bug 算 10 分，一个严重的 bug 算 3 分，一个中等 bug 算 1 分，一个一般的 bug 算 0.5 分。倘若遗留 bug 得分超过 10 分则不允许发布。这是定性的要求，日常工作中不一定要按照这个标准去执行，发不发布还不是领导决定。

Bug1 级，2 级要全部关闭，3 级 Bug 只能留下多少，这是正常情况下，如果项目比较赶，那就只有项目组评估风险再决定发布还是延期。

在现在敏捷发布的环境下，无 1 级、2 级 bug 都可以吧，其他的转给产品 ，在后续发布迭代打上补丁

用例执行率 100%，轻微、一般 bug 遗留率不超过用例的 15%

单元测试退出标准

1) 单元测试用例设计已经通过评审
2) 核心代码 100％ 经过 Code Review
3) 单元测试功能覆盖率达到 100％
4) 单元测试代码行覆盖率不低于 80％
5) 所有发现缺陷至少 60％都纳入缺陷追踪系统且各级缺陷修复率达到标准
6) 不存在 A、B 类缺陷
7) C、D、E 类缺陷允许存在
8) 按照单元测试用例完成了所有规定单元的测试
9) 软件单元功能与设计一致

集成测试退出标准

1) 集成测试用例设计已经通过评审
2) 所有源代码和可执行代码已经建立受控基线，纳入配置管理受控库，不经过审批不能随意更改
3) 按照集成构件计划及增量集成策略完成了整个系统的集成测试
4) 达到了测试计划中关于集成测试所规定的覆盖率的要求
5) 集成工作版本满足设计定义的各项功能、性能要求
6) 在集成测试中发现的错误已经得到修改，各级缺陷修复率达到标准
7) A、B 类 BUG 不能存在
8) C、D 类 BUG 允许存在,但不能超过单元测试总 BUG 的 50％。
9) E 类 BUG 允许存在

系统测试退出标准

1) 系统测试用例设计已经通过评审
2) 按照系统测试计划完成了系统测试
3) 系统测试的功能覆盖率达 100％
4) 系统的功能和性能满足产品需求规格说明书的要求
5) 在系统测试中发现的错误已经得到修改并且各级缺陷修复率达到标准
6) 系统测试后不存在 A、B、C 类缺陷
7) D 类缺陷允许存在，不超过总缺陷的 5％
8) E 类缺陷允许存在，不超过总缺陷的 10％

注：这只是一套比较理想化的退出标准，但在实际工作中不可能达到这种程度，尤其是测试覆盖率和缺陷解决率不可能是 100%。现在的军方标准是达到 99%。对于通用软件来说就要根据公司实际情况。

发布标准跟产品的定位是有关系的，没有绝对的标准，只有相对的标准，产品快速迭代市场扩展期与用户稳定期的质量保障使命是不一样的，自然标准肯定也不一样，总之质量保障的使命还是要围绕公司产品定位来开展标准的制定

每个项目都会有质量目标吧，目标没完成，除了老板开口能发布，项目经理也不敢吧