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

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

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

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

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

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

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

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

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

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

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

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