PiTest测试左移——谈手机管家测试左移实践

2017-08-01   出处:腾讯移动品质中心TMQ  作/译者: 陈诚  


引入

说起“测试左移”相信对于大家来说已经不再陌生,左移的也手段非常多。无论是使用NLP来做需求分析,还是使用ACC来做测试建模,目的都是希望将隐藏的缺陷提早暴露。

今天我们从“测试执行”的角度来谈左移,将测试的执行尽可能的左移,在执行阶段提早发现代码缺陷。


现状和问题


1、手机管家研发模式和测试流程

手机管家现行研发模式为FT模式,即每个FT作为独立的功能模块研发团队,这种研发模式就要求测试人员先要测试FT内部功能(增量测试),再来测试FT之间有交互的功能(FT集成测试),但是很多功能是FT之间相互耦合相互交织的,在增量阶段是没有办法测试的。

2、大版本的测试难点

小版本的迭代通常修改小功能,局部UI,测试这一部分内容可以在开发完毕进行,不必牵扯到其他FT,测试时间和风险可以很好评估。相对于小版本,产品的大版本通常UI会发生很大的变化,各个FT之间接口也会有增加和删除。由于每个FT开发测试进度不同,所以依赖其他FT的数据或接口的模块在自己的功能测试中是不可测的,例如FT内UI展示的数据源来自于询问其他FT,得到不同数据呈现不同UI;再如FT内逻辑依赖其他FT发出请求,收到不同请求,触发不同的业务表现。

为了解决上述因FT开发进度不一致而引起的FT间强依赖模块测试滞后问题,我们引入了PiTest测试左移方法。


测试方案


1、测试框架



PiTest是一个插件,和管家业务插件无异,其中主要部分自动化测试框架,该框架继承了TestNG测试框架,在此基础上集成了管家测试通用的工具,结果报告,和用户接口等。

测试框架:包括基于TestNG实现测试基础框架,通用工具包括数据库DAO,SP服务,日志存储等。

测试控制:通过用例的组合,结果报告的选择,达到定制化的测试流程的目的。

用户接口:UI界面用于本地测试,命令行界面用户自动化测试调用。

另一方面,很多时候需要非自动化的测试场景用于本地验证,PiTest成为一个天然的测试代码管理插件,避免测试代码和开发代码的混合存放,起到开发代码测试代码解耦的作用。

2、测试思路

从数据的获取方式不同将FT之间通信分为两类:主动询问和被动接受。

(1)主动询问:在特定场景需要其他FT模块的数据源时,主动询问该模块是否有数据可提供。得到数据后自身做出相应逻辑判断和UI更新。

测试办法

将业务插件请求其他FT插件改为请求PiTest插件,并给予对应的数据返回。



(2)被动接受:收到其他FT模块发送的事件或消息,做出相应的逻辑处理和UI变化。如同之做Mock测试的方法,模拟不同FT发送过来的数据,不同点在于旧版本的Mock测试是为了解决环境构造复杂,没有真正把测试过程进行左移,执行阶段也是在FT联调后。方案如图:



3、左移方案

旧测试流程:FT内开发完毕—>FT联调—>测试。

之前的FT接口测试执行是在FT联调之后,从各个FT业务层UI层出发。优点在于经过联调后的代码质量更高,缺点是测试执行较晚,且单纯从UI上测试功能很难保证接口的正确性。

“左移”后的测试流程:

(1)接口文档确定—>编写接口测试代码;

(2)接口开发完毕—>使用PiTest进行接口测试,关注接口逻辑,并接入UTP;

(3)FT内功能开发完毕—>使用PiTest进行Mock测试和异常测试,关注功能逻辑;

(4)FT联调—>测试FT之间接口相互影响与用户体验。

测试左移的流程一方面将测试的关注点从接口,功能,用户体验逐个级别关注到,另一方面将测试介入时间大大往前提,提早暴露缺陷,FT内开发完成即可开始测试执行,降低测试执行与FT开发进度的依赖。


测试案例


1、手机管家主界面

业务介绍:

手机管家7.0新版的主界面的“四大金刚”,高级工具和管家推荐都是来源器其他FT的数据,当主界面接口开发完毕后,其他FT并没有同步开发完成。如何使用PiTest达到即刻测试达到测试左移,我们以“四大金刚”为例来说明。




业务逻辑:

先来理清楚四大金刚业务逻辑:通过分析代码可以知道,四大金刚每一个入口都分别向不同的插件获取当前的状态,四个插件返回当前状态的ID,主界面再根据ID和插件来源查询配置文件,找到应该展示的文案更新当前UI。如下图右边部分:



可是,主界面开发完成了,其他四个插件并没有同时开发完成,按照以往的版本测试经验,我们需要等到所有接入业务开发完成后,从业务插件检查真实手机环境来测试主界面UI,所以,一方面是测试时间滞后,另一方面模拟场景复杂多变。

测试方法:

采用上图左边的方法,我们将接入主界面的插件改为PiTest测试插件,从插件设置需要展示的状态,当主界面询问时即可返回预先设置的ID,达到测试主界面UI展示的目的。




测试收益:

(1)将测试执行大大往前提,提现左移的价值;

(2)需要展示的UI文案有52种类,通过手动填写ID即可模拟,无需构造真实场景,省时省力;

(3)提前发现UI展示错误。

最后,由于四大金刚接口两个简单,只有两个参数,我们认为覆盖了已知的52种场景就能保证接口质量,所以没有做专门的接口测试。

同样,主界面管家推荐测试方法类似,不再赘述。

2、手机管家桌面浮窗

业务介绍:

手机管家桌面浮窗被动接受管家各个插件发送的消息,并展示在小浮窗和大浮窗上,点击跳转到对应插件。



测试方法:

手机管家7.0中定义了新的浮窗事件接口,按照左移思路,我们在接口文档确定后开始了测试代码编写,接口开发完成后接入测试。

这种测试方法在之前文章有介绍过,但是这里要强调的重点有两个:

(1)由于接口复杂,参数10个,所以专门针对接口做了测试;



(2)接口质量保证后,通过Mock做了功能测试,且都在其他FT接入前完成。 

测试收益:

在测试执行左移的前提下,发现bug 9个,占桌面浮窗bug总个数的39%(9/23)。


同样,泰山FT权限引导模块采用同样的测试方法,在提测前发现bug个数11个。


3、手机管家垃圾清理

业务介绍:

清理加速模块涉及到4个插件,包括垃圾清理,进程管理等,当首页询问清理加速模块的展示wording时,清理插件会向各个插件获取手机状态,包括内存信息、手机空间信息、微信垃圾、日常垃圾、是否已清理和是否冻结等状态,之后根据优先级给出展示wordingID。首先UI在其他FT,没有测试的界面,其次是8种手机异常情况模拟困难。

业务逻辑:

通过获取主界面状态接口的处理逻辑为,垃圾清理收到首页发来的请求后,会依次向其他三个具体功能业务插件发送请求,当收到的状态满足展示条件时,便立刻向首页返回结果。

测试方法:

为了在FT联调前就发现内部逻辑问题,即将测试执行左移到没有UI开发完成前,我们使用Pitest来对FT内逻辑进行测试,也能够解决模拟场景麻烦的问题。使用这种的方法,我们通过直接修改其他插件的数据,为其构造合适的入参,比如构造wxRubbishSIze为600M或者存储容量提醒阈值为10G,则可以预期PiSpaceManager会向主页面返回的tempId和mainparam,此时将返回结果和预期值比较则可以得到测试结果。

测试收益:

(1)采用这种左移的方法后可以快速测试该用例中涉及的4个插件间通信接口,在提测前快速判断提测质量,使测试执行更加敏捷。

(2)可以解放大量手工测试资源,避免构造场景浪费的时间。

4、手机管家提醒助手

业务介绍:

在手管7.0版本中,提醒助手模块有8个对外接口,涉及多FT数据交互。如何在FT间联调之前验证我们对外提供的接口是正确可用的?接口通信数据交互有哪些可以挖的测试点?沸点在这里分享7.0实践的两个案例。

业务逻辑:

这里举推荐引导功能的例子,下图是简化后的业务实现逻辑,简单讲就是“各业务插件给提醒助手传数据,提醒助手存数据库,然后大浮窗来要数据的时候给它”。可见,这个功能涉及至少三个插件模块,按照传统的手工测试方法,需要三个FT联调通过才能测试,或者开发制造假数据但不方便覆盖所有场景。




测试方法:

在3个FT联调前,为了尽早介入测试执行,在FT内该模块开发完成,我们把这个模块拆分成两个点来验证。

从各业务插件拿到的数据存储数据库是否正确。PiTest测试流程如下:



提醒助手本地数据库构造各种数据,验证传给大浮窗的数据加工结果是否正确。PiTest测试流程如下:




测试收益:

(1)7.0提醒助手模块PiTest用例16条,在提测前发现有效bug4个,且完全代替这部分逻辑的手工测试;

(2)复现手工难以重现bug1个并回归通过;

(3)通过左移发现的bug在开发联调之前即可回归通过;

(4)Bug修复及回归测试时间缩短:开发直接在测试PC上定位并修改代码后回归验证,几分钟即可fix;

(5)跨FT测试边界可较明显区分开。


总结


1、测试左移的收益

(1)测试执行左移:手机管家7.0种对7个模块(主界面四大金刚、管家推荐、桌面浮窗、提醒助手、权限管理、wifi管理,垃圾清理)进行了测试左移试点,在提测前进行了接口测试,联调前进行功能模块测试,将联调提测后的工作了左移到提测前。

(2)提前发现缺陷:7个模块在提测前通过PiTest框架执行了235条用例共提前发现bug数34个。

2、接入UTP(腾讯MIG自动化测试平台)每日监控

将左移测试用例加入到UTP平台的PiTest自动化测试项目中,作为主线集成测质量报告输出,用于评价主线集成质量。另一方面每日构建包执行自动化测试,可以发现开发提交代码引起的bug,不必到提测才发现,甚至可以发现因测试遗漏而导致的线上缺陷


欢迎给测试窝投稿或参与内容翻译工作,请邮件至editors@testwo.com。也欢迎大家通过新浪微博(@测试窝)或微信公众号(测试窝)关注我们,并与我们的编辑和其他窝友交流。
133°|1339 人阅读|0 条评论

登录 后发表评论