1．原则上来讲，我们更希望一种规范化开发的体系来规正这个命题，不需要为此伤脑筋。但在里程碑或计划的截止时间点能结束测试对大多数的软件项目仅仅是一种期望，而不是既定的现实。理想的情况下，我们可以严格执行计划，然后在计划要求的deadline或者里程碑点上提交交付件，以确认该里程碑是否达到要求，是否可以进行下一阶段的工作——但正如前提所言，这个仅仅是理想情况

　　2．现在让我们现实一点。我们为什么会有这样的问题（一个软件如何确定测试结束点）？往往就是因为我们不知道何时可以结束一个软件的测试。不管教科书上如何说明一个软件只要还在生命周期内，就无法结束测试，但现实要求我们在某一个时间点上，结束对软件某一阶段的测试。那么，这个问题实际上就已经转化为确定该阶段测试的结束点的方法了。这个方法可能是一种规范，一套流程，一些交付件，一些评审，一些由统计学原理得出的收敛曲线或者仅仅只是一些确认而已。而个人认为，无论这个方法是何种形式的，其基本的要求就是能达成一种协议，确认该协议生效——那么这个阶段的测试就结束了，至于这个点在什么时间，我想就是完成所有要求的这些确认的时间而已。

　　在软件消亡之前，如果没有测试的结束点，那么软件测试就永无休止，永远不可能结束。软件测试的结束点，要依据自己公司具体情况来制定，不能一概而论！个人认为测试结束点由以下几个条件决定：：

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

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

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

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

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

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