如何确定一个软件测试项目的终结点

　　如何确定一个软件测试项目的终结点软件测试工具       

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

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

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

　　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%”都可以作为结束确定点。如果你不放心，非得要看看测试用例的执行效果，检查是否有用例被漏执行的情况，可以对常用的功能进行 “抽样测试” 和“随机测试”。对于覆盖率在单元测试、集成测试和系统测试，每个阶段都不能忽略。

原文转自：http://www.ltesting.net