TA的每日心情 | 无聊 4 天前 |
---|
签到天数: 1050 天 连续签到: 1 天 [LV.10]测试总司令
|
四、 用例精简效果粗略验证
这里只提到粗略验证,是因为我们认为用例精简有效果验证有两种方式:功能点检查和全量覆盖率结果,功能点的完善性可以通过内部和外部评审实现,但比较耗时,也可以通过标注新旧用例之间的对应关系来确保精简后用例覆盖的功能点不遗漏。
全量覆盖率验证,主要是使用同一个版本测试包对精简前后用例进行覆盖率测试。目前覆盖率测试有行覆盖、方法覆盖、块覆盖,行覆盖率相对方法覆盖精度比较高,虽然不能百分之百的精确,但已经可以作为基础的衡量标准,因此我们抽取了部分精简后的用例进行覆盖率测试。
五、 精准测试方案和实践
上面提到用例精简是精准测试的基础之一,因此在用例精简之后我们也做了精准测
试的实践。
精准测试的本质是,代码有变更时用更少的用例去覆盖变更涉及的功能点,以达到提高测试效率的目的。
代码变更到用例挑选,这就很自然地引出一个问题,那就是代码变更时如何快速找到相应的测试用例,目前解决这问题的思路有两种,一种是通过阅读代码从而梳理出软件架构,这种方式的输出是代码文件和功能逻辑的对应关系,当代码有变更时找到对应功能逻辑从而挑选出需要执行的用例,这种思路是一次投入长期收益,但比较耗时,而且要求测试同学的代码功底比较强,同时需要开发同学的帮忙;另一种是执行某个功能模块用例集时输出代码日志,从代码日志里面也可以找到功能模块的对应关系,这种方案对测试同学的代码能力要求不高,比较适合外包同学的执行,但也比较耗时,同时需要不停维护对应关系库。
同时,版本间的变更识别也有两种思路,一种是成都同学的查看SVN日志,再从日志详细代码中识别出变更逻辑,找到对应用例;还有一种是通过SVN diff,直接从版本间的SVN diff来获取代码变更;这两种方法的思路是想通的,都是利用SVN来找到版本间的差异,但是相比SVN日志,SVN diff结果没有那么直观,只看到差异部分,而且差异部分不一定能够看到前后代码,只有零散的增删改,没有整体概念,这是因为SVN diff结果只会对有增删改的代码往前追溯7行,比如以下变更代码就很难看出是在哪个功能点有变更:
我们的方案和以上两种思路不完全相同,但也采用SVN diff作为技术基础,需要对SVN diff结果再做处理,我们采用类似迭代的思路去逐步求精,也就是开始选择用例时是根据经验尽可能找到对应的用例集,在执行结束时根据此轮覆盖率情况再决定是否需要再挑选更小的用例集。这思路相比预先阅读全部代码和通过日志方案更敏捷,也无需对软件代码细节非常了解,如果结合开发同学的讲解,效率会更高,对架构理解更深。
在给出具体的实践之前,也插播下精准测试的背景:作为测试人员,在版本提测时你是否也会经常收到开发这样的信息,那就是开发人员说某个功能没什么大改动,简单过下就好了,但是就这么一句话测试人员可能就要忙半天了,具体改啥了?“简单过下”到什么程度?这些都是头痛的问题,比如广告拦截在手机管家5.1版本中有变更,开发的提测建议如下:
广告拦截除了第一点有涉及之外,其他变更内容都浓缩在第四点里面,对这样的一句话你放心吗?作为测试人员怀疑精神是要有的,因此我们要想既保证质量又不做无用功就得考虑精准测试了。
我们做了个比较粗糙展示系统,这系统可以实践我们“迭代的思路去逐步求精”想法:
1、 分析版本间变更内容
变更内容的基础是SVN diff,但是因为SVN diff原始结果不直观,因此我们需要对结果再进行解析处理,处理后可以在源码中用不同颜色标明变更内容,而不是直接的SVN diff结果。
初次结果报告覆盖率基本上为0:
2、 根据源码中的变更,判断大概变更涉及模块,挑选出此轮用例。
根据代码变更内容(快速的办法是找开发同学一起过下变更内容),我们可以得知5.1和5.0版本之间广告拦截主要有以下功能点变更:
1)监测到系统通知栏新消息
2)调用临时root失败
3)卸载安装包时清除通知栏消息;
4)启动通知栏监控;
5)获取广告行为表
6)修改广告软件配置
7)广告详情页面展示
8)广告页面刷新
由此可以看到通过查看变更代码可以了解到需要覆盖的测试点
3、 执行此轮用例,利用覆盖率执行结果ec文件再次生成用例执行覆盖情况。
4、 根据此轮用例执行覆盖率情况,再决定是否需要做下一轮的用例挑选。
根据以上粗略挑选用例,发现覆盖率仍比较偏低,因此通过查看具体代码再增加测试用例覆盖,逐步提高覆盖率:
5、 最终完成变更的覆盖,实现精准测试的目的。
最终逐步挑选出约50条用例覆这两个版本间的实际代码变更,不再盲目测试。由于变更代码中有大概10%的保护代码,因此90%的行覆盖率已经比较理想了。同时,由于测试人员逐步分析变更代码,也使得大家对广告拦截的代码逻辑更清晰,增加了发布质量的信心。
|
|