这个问题在每一本测试书上都有提到，光拿出来列也没多大意思，就归纳一下吧：
1。 组织级的强制退出：
- 项目中止，通常是项目出现了严重的问题或人力不可抗拒因素
- 经费用尽，通常是项目经费没有得到很好的控制，弹尽粮绝，这种情况现在比较少见
- 超过期限，这时最常见的，特别是在传统的瀑布模式下，开发一再延期，导致测试时间不足，只好强行中止，听天由命了
2。达到了功能质量指标。要把所有的质量指标罗列起来太困难了，摆几种常见的退出指标：
- 测试用例覆盖度
- 测试用例的执行率
- 测试平台的覆盖率，像语言阿，操作系统，硬件种类阿等等。这对于一些特殊的测试如配置测试，本地化/国际化测试是至关重要的
- 严重缺陷的修复率
- 未修复缺陷是否被记录了
- *新开缺陷的速度
- *修复缺陷的速度
- 回归测试是否被很好地执行了
- 回归测试的缺陷发现率。（这经常被人忽视，由修复缺陷代码引入新缺陷是测试风险的重要来源）
- *未修复缺陷总数的变化趋势，通常只有快速收敛时才认为是结束测试的好时机
- 文档完备率，决定不修复的问题一定要在发布文档里注明
打星号的三个指标形成的三条曲线通常对于测试来说是最重要的参考依据
3。达到了非功能指标
- 性能指标 （展开来太复杂了）
- 可用性指标（虽说是指标，却很少有硬指标）
- 兼容性指标，特别是对于多组件的应用，对于不同版本的各个组件间的兼容性，有时连开发人员都搞不清楚
- 安全性指标， 及其重要
末了，忍不住又要扯一下敏捷开发。迭代式的开发过程会获得不同的缺陷曲线。似乎找不到哪本书或者文章很好地讨论这个问题。从个人经验来说在客户演示来临前上述的三条关键曲线都会达到一个高峰。而每个迭代的退出时间也通常在演示前不久。还有一个重要的退出条件就是单元测试必须达到很高的覆盖率。因为在敏捷开发中软件的质量很大程度上要依赖于单元测试的质量。而从整个项目生命周期来说缺陷的曲线是呈波浪形的。敏捷开发还有一个特殊的地方。在很多敏捷开发的案例里，并不强求最后所有的需求都要被提交。一些很低优先级但成本很高的功能可能会被取消。所以最后退出的条件可能更灵活更经验化。