测试结束的标准:
1基于"测试阶段"的原则:
每个软件一般经历单元测试,集成测试,系统测试这几个阶段,分别对单元测试,集成测试,系统测试指定详细的测试结束点.在每个测试阶段符合标准后,再进行后面的阶段测试.
2基于"测试用例"的原则:
测试设计测试用例,请项目组成员进行评审,评审通过,后面的测试过程中,可以作为测试结束的一个参考标准.使用该原则作为测试的结束点,需要保证测试用例的质量.功能测试用例通过率达到100%,非功能测试用例达到95%以上,允许正常结束.
3基于"缺陷收敛趋势"的原则:
软件测试生命周期中随着时间的推移,测试发现的缺陷图线,首先成逐渐上升趋势,然后测试到一定阶段又成下降趋势,直到发现的趋势几乎为零或者很难发现缺陷为止.我们可以通过缺陷图线的走,来确定测试是否可以结束.这也是测试结束的一个标准.
4基于"缺陷修复率"的原则:
软件缺陷在测试生命周期中我们会分为几个严重等级:它们分别为:严重错误,主要错误,次要错误,一遍错误,较小错误和测试建议6个等级.这样我们在确定测试结束时,严重错误和主要错误修复率必须达到100%,不允许存在功能错误;次要错误和一般错误修复率达到85%以上,允许少量功能缺陷,后面版本解决;对于较小错误和测试建议修复率最好达到60%-70%以上,对于测试建议的问题,可以暂时不用修改.
5基于"验收测试"的原则:
很多公司做的项目软件,如果这种测试要确定测试结束点,最好测试到一定阶段,达到或接近测试部门指定的标准后,就递交用户做验收测试.如果通过用户的验收测试,就可以立即终止测试部门的测试;如果客户验收测试时,发现了部分缺陷,就可以针对性的修改缺陷后,验证通过后递交客户,相应测试也就结束.
6基于"覆盖率"的原则:
对于"覆盖率"的原则,需要测试用例的"覆盖率"覆盖了客户的全部的软件需求,其中包含:行业的隐形需求,功能需求,和性能需求等等,只要测试用例的执行覆盖率达到100%,基本上测试就可以结束.如"测试用例执行覆盖率应达到100%","测试需求覆盖率应达到100%"都可以作为测试的结束点.对于覆盖率在单元测试,集成测试和系统测试,每个阶段都不能忽略.如果要查看测试用例的执行效果,检验是否用例是否有漏执行的情况,可以对常用功能进行"抽样测试""和"随机测试"
7基于"项目计划"的原则:
大多数情况下,每个项目从开始就要编写开发和测试的schedule(计划),相应的在测试中也会有相对应的里程碑,对测试进度和结束点做一个限制,一般来说都要和项目组成员(开发,管理,开发,测试,产品,销售)达成共识.团队集体同意后,制定一个标准结束点.如果项目的某个环节延时,测试时间相应的就会缩短.大多数情况下,所有规定的测试内容和回归测试都已经运行完成,就可以作为一个结束点.不规范的软件公司,都会把项目计划作为一个测试的结束点,但是如果把项目计划作为测试结束点,测试风险较大,软件质量很难得到保证.
8基于"缺陷度量"的原则:
本原则用的较少.通过本原则,对已发现的缺陷,运用常用的缺陷分析技术和缺陷分析工具,用图表统计出来,方便查阅,分时间段对缺陷进行度量.可以把"测试期缺陷密度"和"运行期缺陷密度"作为一个结束点.最为合适的测试结束标准是"缺陷数控制在一个可接受的范围内".
9基于"质量成本"的原则:
一个软件往往要从"质量/成本/进度"三方面取得平衡后就停止.至于那一项占项目主要地位,就要看是什么软件.例:人命关天的航天航空软件, 那还是质量重要些,就算多花点钱、推迟一下进度，也要测试能保证较高质量以后才能终止测试，发布版本。如果是一般的常用软件，由于利益和市场的原因，哪怕有bug，也必须得先推出产品，没办法呀。一般来说,最主要的参考依据是"把找到的缺陷耗费的代价和这个缺陷可能导致的损失做一个均衡".。具体操作的时候，可以根据公司实际情况来定义什么样的情况下算是“测试花费的代价最划算、最合理”，同时保证公司利益最大化。如果找到bug的成本比，用户发现bug 的成本还高，也可以终止测试。
10基于"测试行业经验"的原则:
很多情况下，测试行业的一些经验，也可以为我们的测试提供借鉴。比如说测试人员对行业业务的熟悉程度，测试人员的工作能力，测试的工作效率等等都会影响到整个测试计划的执行。如果一个测试团队中，每个人都没有项目行业经验数据积累，拿到一个新的项目，自然是一头雾水，不知道从何处开始，测试质量自然不会很高。因此通过测试者的经验，对确认测试执行和结束点也会起到关键性的作用。