去年底做了一个Android应用的项目,代码总计2万多行,测试周期4个月,项目虽小,但涉及到手机终端适配、网络环境兼容等多个方面。项目阶段一结束后,我们简单总结了一下测试方法有效性的问题。发出来与大家共享。
这个Android应用的主要功能很简单,附加功能较多,基本都属于锦上添花类。测试的实际情况如下:
1、资源投入:持续时长4个月,人力6人+,测试机型30款+
2、测试执行:23轮功能测试,7轮系统测试,8轮健全测试,3轮机型兼容测试,3轮性能测试,1轮MTBF测试,1轮PD/UI验证测试。
但是这其中有很多不足之处,较明显的如下:
1、前期功能测试和健全测试一天一轮,频度太快且测试费时,效果不好。
2、初期的测试用例设计全面,但未精确定义编写粒度,描述过程过细,后期因需求变更导致维护成本较高。
3、因项目流程和过程控制影响,无法明确划分测试阶段,且初期没有找到最佳敏捷测试方法,测试流程冗余僵化,导致大量重复性的工作,灵活性偏低。
在测试进程中我们已发现测试策略的问题,并及时调整,在阶段二开始使用新策略——使用两阶段测试模型:
1、阶段一<自由测试>:按照探索性测试(Exploratory Testing)模式,布置有针对性有重点的自由测试,以“把软件使用坏掉”为目的,尽可能多发现bug。
2、阶段二<覆盖测试>:执行各项测试用例,以“全面测试”为目的
具体的时间安排如下:
1、先期产品开发阶段,即Alpha release之前,做功能测试、健全测试、缺陷验证+自由测试。
2、项目中期,Alpha ~ Beta之间,执行全面的系统测试、兼容性测试、性能测试,并开展自动化脚本开发、环境搭建等工作。
3、Beta release之后,在产品发布前的2~3周,就开始确定稳定版本Release Candidate,在此版本基础上做最后一轮全面测试、重点子模块的健全测试、缺陷主导的ET等,完成最终报告并交由项目组领导、QA审核发布。
本次测试有效性总结我们引入了两个质量来衡量:软件质量指标和测试过程质量指标。
软件质量指标包括:
(一)需求功能点覆盖率:
计算测试用例总数之和除以与之一一对应的功能点数之和,主要查看是否有功能点遗漏测试的情况。用例覆盖需求矩阵,一个需求对应多个功能点。
需求覆盖率=∑测试用例数(个)/∑功能点(个)=1055/147=7.18
(二)用例执行覆盖率:
计算测试用例执行总数除以与之一一对应的测试数之和,主要查看是否有测试用例执行遗漏或有效的情况。
用例执行覆盖率=∑执行的测试用例个数(个)/∑测试用例个数(个)*100%
功能测试276条,系统测试779条,用例执行覆盖率达到99%。