软件测试输入准则,软件测试准则-明明白白结束之六脉神剑

单元测试的结束并非单纯基于时间,而是涉及多个标准,包括测试计划的详细与执行、测试用例的质量与执行情况、测试内容的全面验证、代码质量评估、缺陷管理和测试报告的完成。确保每个方面都达到要求,如100%需求验证、高代码覆盖率、缺陷有效管理等,才能进入集成测试阶段。
摘要由CSDN通过智能技术生成

原标题:软件测试准则-明明白白结束之六脉神剑

85fafe552c34cee4bc5561a93d993eca.png

测试的结束标准有很多,我认为主要有以下六条

一、基于测试计划

单元测试首先要满足项目的进程,整个测试进度受开发计划与测试计划的影响。因此,单元测试计划是我们结束的一个标准。但由于执行力度的不同,以及中间的各种变数,因此计划的结束时间只能作为一个依据,为了保证单元测试的实际时间与计划时间匹配,需要做到以下几点:

单元测试计划的颗粒度要够细,根据内容可区分需求验证计划、功能验证计划、性能验证计划、公共项目测试计划;根据时间可以建立月计划、周计划、甚至日计划等

计划并不是一个表格,它需要和测试人员共同沟通并达成一致,一个盲目下达的计划很容易产生执行偏差以及人员的逆反心理。

每步计划的执行反馈要明确到人、事。测试结果不能仅仅是报告上的一个“通过”, 它需要形成书面报告或者口头报告。

测试计划必须基于整体测试策略以及测试方案,并将计划、策略、方案传达给所有测试人员,使大家有着相同的测试目标。

二、基于测试用例

单元测试阶段,测试人员往往通过测试用例来执行测试,用例的质量与执行情况便决定了单元测试的质量。当测试用例全部测试完毕并通过时,表明单元测试结束,但为了更好的保证质量,我们需要从以下情况把握:

用例的设计必须基于测试计划、测试策略和测试方案,过细与过粗的方案都会影响测试的质量以及测试的周期。

用例必须区分重要、一般、次要,保证重要用例100%执行完成。

用例的执行进度需要在计划中体现,且不能只是单纯百分比的体现。

用例必须要评审。

三、基于测试内容

单元测试需要测试很多内容,比如需求条目、功能验证、公共项目验证、性能验证、产品组合、加密等等,我们需要保证每项测试内容全部验证通过。比如:

需求条目完全验证通过。

功能验证可基于用例、特性、场景、节点等多种维度展开,保证功能覆盖率达到100%

公共项目验证达到100%

性能测试条目全部验证通过。

四、基于代码

目前我们是基于黑盒测试,虽然对代码关注不够,但通过开发部的协助,代码的测试也有几个标准可作为单元测试结束的依据

核心代码必须经过开发人员及开发经理的代码检查与代码走查。

代码的语句及分支的覆盖率达到70%或者更多。

代码的缺陷发现率,比如千行代码至少发现2个BUG。

五、基于缺陷

测试人员发现的BUG往往通过CQ或者其他缺陷系统展现,这些BUG也能成为我们单元测试的结束标准,比如有以下几点:

所有缺陷必须全部关闭或者遗留。

BUG的发现趋势成正常下降趋势

一二类BUG数量极少,且在很长时间内不产生一类BUG。

另外还有很多缺陷度量的方法,也可借鉴使用。

六、基于测试报告

测试报告是测试结果的体现,因此测试报告的全部完成也是我们单元测试结束的一个标准,常见的报告一般有以下:

基于需求条目的需求验证报告

开发部的代码检查及走查报告

测试用例的执行报告。

性能测试报告等

代码覆盖率报告等

测试风险报告

测试人员、测试经理、部门经理的测试报告等

达到上面这些标准后,可进入集成测试阶段。但结果仅是过程的体现,没有过程便没有结果。因此我们还是需要步步为营,稳扎稳打,保证每道工序做到最好。返回搜狐,查看更多

责任编辑:

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值