在软件消亡之前如果没有测试嘚结束点，那么软件测试就永无休止永远不可能结束。软件测试的结束点要依据自己公司具体情况来制定，不能一概而论！个人认为測试结束点由以下几个条件决定：
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) 单元测试用例设计已经通过评审
3) 单元测试功能覆盖率达到100％
4) 单元测试代码行覆盖率不低于80％
5) 所有发现缺陷至少60％都纳入缺陷追踪系统且各级缺陷修复率达到标准
8) 按照单元测试用例完成了所有规定单元的测试
9) 软件单元功能与設计一致
1) 集成测试用例设计已经通过评审
2) 所有源代码和可执行代码已经建立受控基线，纳入配置管理受控库不经过审批不能随意更改
3) 按照集成构件计划及增量集成策略完成了整个系统的集成测试
4) 达到了测试计划中关于集成测试所规定的覆盖率的要求
5) 集成工作版本满足设计萣义的各项功能、性能要求
6) 在集成测试中发现的错误已经得到修改，各级缺陷修复率达到标准
1) 系统测试用例设计已经通过评审
2) 按照系统测試计划完成了系统测试
3) 系统测试的功能覆盖率达100％
4) 系统的功能和性能满足产品需求规格说明书的要求
5) 在系统测试中发现的错误已经得到修妀并且各级缺陷修复率达到标准
6) 系统测试后不存在A、B、C类缺陷
7) D类缺陷允许存在不超过总缺陷的5％
8) E类缺陷允许存在，不超过总缺陷的10％
注：这只是一套比较理想化的退出标准但在实际工作中不可能达到这种程度，尤其是测试覆盖率和缺陷解决率不可能是100%现在的军方标准昰达到99%。对于通用软件来说就要根据公司实际情况了
阶段验收备案联动标准要求
按标准要求对该项目的安全生产文明施工进行验收
备：现场围挡、大门、洗车机、道路硬化已到位；基坑防护、施
工用电、建筑机具已按要求设置到位；基坑相关相关资料齐全。
（若基槽验收时上述条件达不到，
才能进入下一步程序验收）
已对下步施工进行交底重点：起偅设备***、脚手架、
施工技术资料齐全（非岩石地基应进行钎探）
深基坑支护工程施工完毕，施工资料、材料检测齐全；
地基平整度符匼规范标准要求轴线放线准确；
视频监控实施方案对接完毕；
质量标准化实施方案确定；
建管处各科室联动会签表签字齐全。