单元测试退出标准

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允许存在

系统测试退出标准：www.lemonban.com柠檬班软件测试

1) 系统测试用例设计已经通过评审

2) 按照系统测试计划完成了系统测试

3) 系统测试的功能覆盖率达100％

4) 系统的功能和性能满足产品需求规格说明书的要求

5) 在系统测试中发现的错误已经得到修改并且各级缺陷修复率达到标准

6) 系统测试后不存在A、B、C类缺陷

7) D类缺陷允许存在，不超过总缺陷的5％

8) E类缺陷允许存在，不超过总缺陷的10％

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

严格来说 是 BUG数量曲线已经平滑。。

但是实际工作中，由于迭代开发，BUG的数量不会很平滑，所以需要人为的制定上线标准。。

比如 1轮测试 分为 测试用例执行 自由测试 各组交叉测试 ，这样产生出来的BUG已经全部修改完，并且已经验证过，再进行1轮和之前1样的测试，完成后，再验证BUG，然后回归测试之前的严重BUG，没问题的话，可以认为阶段测试结束

没有绝对的答案，只有相对的答案，最重要的是要根据实际情况来。
1.全部测试用例回归测试都执行完成。
2.未修改bug都被确认或置为应有状态。暂缓修改的问题都有的详尽的解释。
3.测试报告编写完成。
4.测试收尾工作结束。
5.测试总结完成。
6.项目处于试运行或上线阶段。继续关注产品试运行出现的问题，并及时录入bug管理系统。
7.测试活动没有尽头，只有相对完成。

bug尽可能的减少，没有影响主要功能的正常运行

所有影响用户体验的bug已经尽可能的修复，没有影响主要功能的正常运行

错误强度曲线下降到预定的水平

严格上来说，就是要把存在的bug给解决，从而达到合理上线的要求

十个原则确定软件测试结束的标准

1．基于“测试阶段”的原则：

每个软件的测试一般都要经过单元测试、集成测试、系统测试这几个阶段，我们可以分别对单元测试、集成测试和系统测试制定详细的测试结束点。每个测试阶段符合结束标准后，再进行后面一个阶段的测试。举个例子来说：单元测试，我们要求测试结束点必须满足“核心代码100％经过Code Review”、“功能覆盖率达到100％”、“代码行覆盖率不低于80％”、“不存在A、B类缺陷”、“所有发现缺陷至少60％都纳入缺陷追踪系统且各级缺陷修复率达到标准”等等标准。集成测试和系统测试的结束点都制定相关的结束标准，当然也是如此。

2．基于“测试用例”的原则：

测试设计人员设计测试用例，并请项目组成员参与评审，测试用例一旦评审通过，后面测试时，就可以作为测试结束的一个参考标准。比如说在测试过程中，如果发现测试用例通过率太低，可以拒绝继续测试，待开发人员修复后再继续。在功能测试用例通过率达到100%，非功能性测试用例达到95%以上，允许正常结束测试。但是使用该原则作为测试结束点时，把握好测试用例的质量，非常关键。

3．基于“缺陷收敛趋势”的原则：

软件测试的生命周期中随着测试时间的推移，测试发现的缺陷图线，首先成逐渐上升趋势，然后测试到一定阶段，缺陷又成下降趋势，直到发现的缺陷几乎为零或者很难发现缺陷为止。我们可以通过缺陷的趋势图线的走向，来定测试是否可以结束，这也是一个判定标准。

4．基于“缺陷修复率”的原则：

软件缺陷在测试生命周期中我们分成几个严重等级，它们分别是：严重错误、主要错误、次要错误、一般错误、较小错误和测试建议6种。那我们在确定测试结束点时，严重错误和主要错误的缺陷修复率必须达到100%，不允许存在功能性的错误；次要错误和一般错误的缺陷修复率必须达到85%以上，允许存在少量功能缺陷，后面版本解决；对于较小错误的缺陷修复率最好达到60%~70%以上。对于测试建议的问题，可以暂时不用修改。

5．基于“验收测试”的原则：

很多公司都是做项目软件，如果这种要确定测试结束点，最好测试到一定阶段，达到或接近测试部门指定的标准后，就递交用户做验收测试。如果通过用户的测试验收，就可以立即终止测试部门的测试；如果客户验收测试时，发现了部分缺陷，就可以针对性的修改缺陷后，验证通过后递交客户，相应测试也可以结束。

6．基于“覆盖率”的原则：

对于测试“覆盖率”的原则，个人觉的只要测试用例的“覆盖率”覆盖了客户提出全部的软件需求，包括行业隐性需求、功能需求和性能需求等等，只要测试用例执行的覆盖率达到100%，基本上测试就可以结束。如“单元测试中语句覆盖率最低不能小于80%”、“测试用例执行覆盖率应达到100%”和“测试需求覆盖率应达到100%”都可以作为结束确定点。如果你不放心，非得要看看测试用例的执行效果，检查是否有用例被漏执行的情况，可以对常用的功能进行“抽样测试 ”和“随机测试”。对于覆盖率在单元测试、集成测试和系统测试，每个阶段都不能忽略。

7．基于“项目计划”的原则：

大多数情况下，每个项目从开始就要编写开发和测试的Schedule，相应的在测试计划中也会对应每个里程碑，对测试进度和测试结束点做一个限制，一般来说都要和项目组成员（开发，管理，测试，市场，销售人员）达成共识，团队集体同意后制定一个标准结束点。如果项目的某个环节延迟了，测试时间就相应缩短。大多数情况下是所有规定的测试内容和回归测试都已经运行完成，就可以作为一个结束点。很多不规范的软件公司，都是把项目计划作为一个测试结束点，但是如果把它作为一个结束点，测试风险较大，软件质量很难得到保证。

8．基于“缺陷度量”的原则：

这个原则也许大家用的不是很多，了解比较少。我们可以对已经发现的缺陷，运用常用的缺陷分析技术和缺陷分析工具，用图表统计出来，方便查阅，分时间段对缺陷进行度量。我记得以前zhuzx在这个论坛上提出过缺陷分析技术这个问题，我不再重复讲述。我们也可以把 “测试期缺陷密度”和 “运行期缺陷密度”作为一个结束点。当然，最合适的测试结束的准则应该是“缺陷数控制在一个可以接受的范围内”。比如说：一万行代码最多允许存在多少个什么严重等级的错误，这样比较好量化，比较好实施，成为测试缺陷度量的主流。

9．基于“质量成本”的原则：

一个软件往往要从“质量/成本/进度”三方面取得平衡后就停止。至于这三方面哪一项占主要地位,就要看是什么软件了。比如说是：人命关天的航天航空软件, 那还是质量重要些,就算多花点钱、推迟一下进度，也要测试能保证较高质量以后才能终止测试，发布版本。如果是一般的常用软件，由于利益和市场的原因，哪怕有bug，也必须得先推出产品，没办法呀。一般来说，最主要的参考依据是：“把找到缺陷耗费的代价和这个缺陷可能导致的损失做一个均衡”。具体操作的时候，可以根据公司实际情况来定义什么样的情况下算是“测试花费的代价最划算、最合理”，同时保证公司利益最大化。如果找到bug的成本比，用户发现bug 的成本还高，也可以终止测试。

10．基于“测试行业经验”的原则：

很多情况下，测试行业的一些经验，也可以为我们的测试提供借鉴。比如说测试人员对行业业务的熟悉程度，测试人员的工作能力，测试的工作效率等等都会影响到整个测试计划的执行。如果一个测试团队中，每个人都没有项目行业经验数据积累，拿到一个新的项目，自然是一头雾水，不知道从何处开始，测试质量自然不会很高。因此通过测试者的经验，对确认测试执行和结束点也会起到关键性的作用。

单元测试退出标准

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%。对于通用软件来说就要根据公司实际情况了。