【腾讯TMQ】精准测试之精简用例

作者:马莉

精准测试之精简用例之为什么要精简

1.背景

手机管家目前有6年多的历史了,一直在持续不断的加入新特性,每次发布前除了新增功能之外,旧的核心功能也是发布之前必须确保的。

1、当前用例情况 6年的沉淀,虽然每次版本都会用例存档,但是日积月累下来,出现了以下几个问题:

2、新增功能的用例直接添加上去存档,并不会修改优先级,当前版本新增功能中有些路径的优先级是1,2级,但是站在整个版本上来看或许并不是这么重要。

3、旧功能的修改或删减,对已有功能做出修改或者是废弃,用例也是直接归档,并没有对之前的用例修改或删除,虽然用例后面都有写最后需改的版本,但是因为数量太过庞大,想要找到那个点修改也是力不从心。 鉴于以上两点,用例越来越多:

1.2碰到的问题

由于有这么多的用例,每次FT集成,主线集成,上线前都需要多这么多用例,带来了以下3个思考:

1、旧功能测试的时间过长,性价比不高

这些旧功能不是本次版本的重点,值得花多于新功能的时间执行吗?

2、新人学习成本大

功能用例都是外包执行,外包的流动性非常大,如果是一个新人外包,让他在短短的时间内执行这么多用例,数量大且有很多用例不知道怎么执行,需要咨询的时间,这样算起来在计划内的时间根本执行不完,还需要申请资源支持,可是这么做值得吗?

3、外包工作量化

当面对如此庞大的用例时,新人时期可能会一条一条执行,但是熟悉之后,经验会告诉他哪些可以不执行,那么接口人如果按照量级去分配任务,是否不合理呢?

2.精简的收益与目标

鉴于以上分析,用例精简值得做,且会有很大收益.

2.1预期获得的收益

1、缩短测试时间:

可以减少FT集成,主线集成,上线前的测试时间。

2、减少新人学习成本:

只保留最“精“的用例,去除不必要的用例,划分清晰的模块,利于新人学习和执行。

3、外包工作量化:

做到外包实际做的和接口人预估的符合,不会有太大的水分。

2.2精简的目标

1.集成阶段的用例缩减至少50%,执行时间缩减为0.5d,包括FT集成,主线集成。

2.上线前用例缩减到100以内,执行时间缩减为1h,包括定位问题的时间。

3.解决的思路

知道了精简的必要性之后,思考要怎么去执行,时间+成本最小的做法,我认为如下:

1.充分利用经验,把经验转化为可见的东西,即运用集体智慧

第一轮:人工筛选,由于是要善于利用外包同学的经验

力度:粗,不必要太精细,每个模块的要大胆删除

2.工具辅助:代码覆盖率+知识库

通过工具辅助来补充人工的不足和冗余完善整个模块的知识库,便于后续利用

方法: 经验沉淀+代码覆盖率+知识库

精准测试之精简之执行,收益与维护

1.改造用例

了解实现原理,将用例按照代码实现方式来分类,比如手机管家。

1.1代码实现方式:插件

1.2划分功能用例功能模块

尽量完全独立,与其他功能模块少交互,这样才有利于第三部的划分,有耦合的也没有问题,只是相对应的插件会更多,见第三点

1.3理清功能模块与插件的关系

1、一般一个插件是一个主要的功能模块,这是最理想的状态

2.、事实是,大部分的插件也会遵循一个插件是一个主要的功能模块,但是为了减少代码量或是其他原因,有时候会做一些移动,把某些的代码放到其他名字看上去完全不相关的插件里

3、要做的就是把上述2点,哪个功能模块的实现分别在哪几个插件中的对应关系整理清楚

1.4修改功能用例的模块

按照第三点都把功能用例对应的功能写清楚,基本全部能够直接对应到插件,这样后面的执行有利于筛选

2.分配功能模块的优先级

按照功能的重要性,分配每个功能模块的优先级,功能复杂的模块用时会多些,最后按照优先级以及耗时制定计划。制定计划清晰又有每个阶段应该做什么怎么做,避免浪费时间。

用例与计划都准备好之后,就可以开始精简之路了。

3.开始精简

精简方法:经验沉淀+代码覆盖率+知识库

采用先减后加,放开胆子去删的思路 覆盖率采用方法覆盖,工具为emma的二次开发工具—代码覆盖率平台

3.11级用例删减

1级用例的删减,采用采供过滤的方式,后面再查缺补漏即可。

1、1级用例中与当前版本不符的用例降级

分析这些用例应该是2级还是3级,确定之后标注好,这里尤其要注意那些历史问题,这一步完全可以让外包同学做,接口人review就好。

2、执行用例,查看代码覆盖率

此时一般都在50%左右,因为主路径基本都已涵盖

需要注意的是,这2步做完还不需要具体去分析没有覆盖到的代码,毕竟1级用例的占比不会太多,为了能够减少工作量,下文会提到什么时候才是合适的时机去分析没有覆盖到的代码。

3.22级用例删减

现在开始进行2级用例的删减,一般来说2级用例是量最大的,1级和3级用例都只占一小部分而已,所以最大的工作量在这里。

1、人工删减

人工删减2级用例要做到大胆的删,原则是只留属于主路径和重要的异常路径,其他全部降为3级

2、执行,查看代码覆盖率

这时代码覆盖率一般都在70%左右,接下来要开始分析代码了。

小tips:我做了8个插件,最后得出我认为最快捷的方式,举例为java代码,分析路径package-class-method。

3.3.1第一步的目标

消除所有0%的package,即每个class的method覆盖不为0,一般最多2次

找出所有0%的package分析,可以自己走读代码,也可以咨询相应对模块的开发,为了省时,我在开始精简代码开始之前已经找过开发负责人,每个插件都有对应的开发负责人接口。

1、查看package下的每个class,分析百分之0的原因,确认这个package的作用,有以下三种操作 a)冗余

b)忽略

例如:数据库升级

覆盖安装及对应的读写数据库

其他完全不相关的插件调用使用的

c)确认遗漏的,补充package和class的知识库,添加模块相应注释

2、根据注释补充用例,并确定优先级

3、执行,检查覆盖率是否还有0%

a)还有为0的要分析为什么之前补充的用例没有覆盖到?

注释有误,修改用例,接着重新执行

模块已废弃不用,路径跑不到,因为历史遗留代码的问题,开发对于代码的反应一般都是害怕错删,标注冗余

这一轮一般做2轮左右就ok了,如果执行的时候大于2轮,那要好好思考下第三点所提到的没覆盖的原因,是否是需要提高注释的质量等。

3.3.2第二步的目标

全部的package覆盖率达到50%以上,即每个class的method覆盖大于等于50%,次数在3次以内

1、package,根据覆盖率分为2类,大于50%,小于50%

1)小于50%的package,按照从小到大的顺序排序划分

再将每个package中的class的method覆盖小于50%的的class按照从小打到的顺序划分

分析class下method覆盖为0的,具体分析方式跟package为0%一致详见3.2.2.1

分析class下method覆盖小于50%的

做完3.2.2.1和3.2.2.2描述的2步,一般覆盖率就达到了80%左右。

3.3.3第三步的目标

每个class的method覆盖于大于等于90%左右,一般要5次左右

这个过程是整个流程中耗时最长,但增加最少的阶段,因为牵扯到细节,所以要耐心,全局查看method覆盖从小到大的class挨个分析。整个过程最好保留基线和已上传的ec,一直更新EC,再查看。

3.3.4第四步的目标

人工审核,查缺补漏

覆盖率只是个数据,并且是辅助工具,如何做到上线前的,主线集成的用例够精简且不会遗漏,精简后还需要再人工审核一遍,我的具体做法是:

1、主路径:

打开app,按照插件来检查每个模块的用例,app中能看到的所有入口必须涵盖在1级用例中。

2、用户常用场景:

将用户常用场景按照模块列出来,对照相对应的用例,1,2级用例必须全部涵盖。

3、运用集体智慧:

人的经验转换,一起共同测试的同学聚在一起,按照模块一起review用例,觉得哪里有遗漏,按照经验什么地方经常出问题,是否需要增加用例,PK之后觉得合理的加入。

4、线上缺陷&线上反馈:

版本发布后,根据线上缺陷&线上反馈来检查,是否是测试用例遗漏造成的,分析线上缺陷的根因,根据严重等级和用户反馈数来决定是否要添加用例,以及应该添加到哪个阶段最合适。

4.精简收益

1.用例精简效果,远大于目标

2.测试时间,精简之后的用例,历经2个版本,集成时间在0.5内,上线前时间2h。

5.后期验证与维护

1.维护:

(与当前版本不符的1级用例,即历史某个版本的1级用例,尤其是本次新添加的用例)规避:每次版本结束后归档时,新增内容优先级修改,FT集成,主线集成,上线前的用例明确,不要再留有历史1级用例

2.验证:

主线集成,上线前,灰度,线上bug跟进,看是否有bug是因为精简用例而造成的缺失,分析并查缺补漏,目前已经历了3个大版本,截止目前为止只有灰度期间发现的1个一般问题,补充上线前用例1条。

原创声明,本文系作者授权云+社区-专栏发表,未经许可,不得转载。

如有侵权,请联系 yunjia_community@tencent.com 删除。

编辑于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏zhangdd.com

必看,运维还要懂这么多?

听说你精通运维?Apache、Nginx、tomcat、vmstat、iftop、awk、sed、sar、iostat、LVS、HA-proxy、MHA、Zoo...

542
来自专栏Java架构

干货 | 携程图片服务架构一、服务架构二、 小结

1515
来自专栏北京马哥教育

从小公司,一路跌跌撞撞到腾讯,论高级DBA的自我修养!

专职做 DBA 已经 6 年多的时间了,一路走来,感触非常深。看同行、同事犯了太多的错误,同样我自己也犯了非常多的错误,然而绝大多数的错误其实都是很低级的错误。...

3898
来自专栏企鹅号快讯

谁说 Java 要过时?2017年Java 大事件回顾!

前端教程 关注即可习得新技能 ! 关键时刻,第一时间送达! 在过去的一年中,Java 历经了许多变化。在今年年初,Java EE 处于一个不确定的状态,Java...

1869

有效的云安全警报

警报系统是任何安全程序的首要组成部分。当一些问题出现的时候,警报通常都是最快和最有效的提醒方式,让你能够及时地采取补救措施。但是警报有的时候过于“吵闹”:有时它...

1808
来自专栏码神联盟

高效编程所需要做的那点事

聊聊如果才能高效编程 计划(Plan) 所谓Plan,其实就是对应于编程中的设计阶段,当然,这里的Plan并不像设计那样重量级。它要求我们程序员在正式...

2669
来自专栏陈树义

如何通过组件化提高开发效率?

在软件开发过程中,大到业务模块的划分,小到技术组件的开发,都属于组件化的思考范畴内。很多时候我们到网上搜索「组件化」关键词,都只会看到关于前端组件化的资料,而对...

2754
来自专栏张秀云的专栏

致 DBA:为什么你经常犯错,是因为你做的功课不够

本文就是基于这方面的考虑,根据自己在 DBA 这个职业上走过的弯路,总结一些方法给 DBA 的同行。希望本文能给同行 DBA 或者运维的朋友们带来一些改变,让大...

3240
来自专栏Java架构师学习

七年的资深架构师告诉你成为架构师的知识体系

架构师是一个充满挑战的职业,知识面的宽窄往往决定着一个架构师的架构能力 知识面的宽广对于一名出色的架构师来说是必不可少的技能,也许很多人对架构的理解还停留在设...

3854
来自专栏码代码的陈同学

Mysql插入2.6亿条垃圾数据后会发生什么?

今天下午业务人员发现某功能无响应(该功能一天前上线),技术人员初步诊断后发现是某个DB不太正常,DB为Mysql 5.7.18。

1822

扫码关注云+社区