软件测试准则-明明白白结束之六脉神剑
测试的结束标准有很多，我认为主要有以下六条 一、基于测试计划单元测试首先要满足项目的进程，整个测试进度受开发计划与测试计划的影响。因此，单元测试计划是我们结束的一个标准。但由于执行力度的不同，以及中间的各种变数，因此计划的结束时间只能作为一个依据，为了保证单元测试的实际时间与计划时间匹配，需要做到以下几点：
单元测试计划的颗粒度要够细，根据内容可区分需求验证计划、功能验证计划、性能验证计划、公共项目测试计划；根据时间可以建立月计划、周计划、甚至日计划等
计划并不是一个表格，它需要和测试人员共同沟通并达成一致，一个盲目下达的计划很容易产生执行偏差以及人员的逆反心理。
每步计划的执行反馈要明确到人、事。测试结果不能仅仅是报告上的一个“通过”， 它需要形成书面报告或者口头报告。
测试计划必须基于整体测试策略以及测试方案，并将计划、策略、方案传达给所有测试人员，使大家有着相同的测试目标。
二、基于测试用例
单元测试阶段，测试人员往往通过测试用例来执行测试，用例的质量与执行情况便决定了单元测试的质量。当测试用例全部测试完毕并通过时，表明单元测试结束，但为了更好的保证质量，我们需要从以下情况把握：
用例的设计必须基于测试计划、测试策略和测试方案，过细与过粗的方案都会影响测试的质量以及测试的周期。
用例必须区分重要、一般、次要，保证重要用例100%执行完成。
用例的执行进度需要在计划中体现，且不能只是单纯百分比的体现。
用例必须要评审。
三、基于测试内容
单元测试需要测试很多内容，比如需求条目、功能验证、公共项目验证、性能验证、产品组合、加密等等，我们需要保证每项测试内容全部验证通过。比如：
需求条目完全验证通过。
功能验证可基于用例、特性、场景、节点等多种维度展开，保证功能覆盖率达到100%
公共项目验证达到100%
性能测试条目全部验证通过。
四、基于代码
目前我们是基于黑盒测试，虽然对代码关注不够，但通过开发部的协助，代码的测试也有几个标准可作为单元测试结束的依据
核心代码必须经过开发人员及开发经理的代码检查与代码走查。
代码的语句及分支的覆盖率达到70%或者更多。
代码的缺陷发现率，比如千行代码至少发现2个BUG。
五、基于缺陷
测试人员发现的BUG往往通过CQ或者其他缺陷系统展现，这些BUG也能成为我们单元测试的结束标准，比如有以下几点：
所有缺陷必须全部关闭或者遗留。
BUG的发现趋势成正常下降趋势
一二类BUG数量极少，且在很长时间内不产生一类BUG。
另外还有很多缺陷度量的方法，也可借鉴使用。
六、基于测试报告
测试报告是测试结果的体现，因此测试报告的全部完成也是我们单元测试结束的一个标准，常见的报告一般有以下：
基于需求条目的需求验证报告
开发部的代码检查及走查报告
测试用例的执行报告。
性能测试报告等
代码覆盖率报告等
测试风险报告
测试人员、测试经理、部门经理的测试报告等
达到上面这些标准后，可进入集成测试阶段。但结果仅是过程的体现，没有过程便没有结果。因此我们还是需要步步为营，稳扎稳打，保证每道工序做到最好。
页:
[1]
