【 测试左移专栏 】PiTest 测试左移 :谈手机管家测试左移实践

【引入】

说起“测试左移”相信对于大家来说已经不再陌生,左移的也手段非常多,无论是使用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或者KEY_INTERNAL_STORAGE_DANGER(存储容量提醒阈值)为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每日监控

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

想知道更多测试相关干货 请关注我们的微信公众号——腾讯移动品质中心TMQ:

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

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

编辑于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏云计算

从开发者的角度比较IAAS与PAAS

在我之前的文章中,讨论了云计算背后的基本概念,包括其定义,特性和各种服务模型。在本文中,我将更加详细地讨论服务模型,特别是从开发者的角度来比较IAAS和PAAS...

2286
来自专栏blackpiglet

R 语言实战第一,二章 R 语言版

这次的作业主要是以对一个非常简单的数据分析问题进行实践的形式呈现出来,对于《R语言实战》第一二章的内容已经体现在了对问题的解析的过程中,所以就不再将学习的过程贴...

492
来自专栏架构师之路

feed留,单聊群聊,系统通知,状态同步,到底是推还是拉?

可以理解为一个发布订阅业务,典型业务是微博(朋友圈)。你关注了姚晨的微博,姚晨发布了消息,你的主页能看到她最新发布的消息,这个场景是推送,还是拉取呢?

1013
来自专栏HaHack

基于 Cocos 的高性能跨平台开发方案

2018 年 6 月 GMTC 全球移动技术大会在北京举办,大会旨在通过聚焦前沿技术与实践经验帮助参会者了解移动开发、前端领域最新的技术趋势与最佳实践。

692
来自专栏腾讯云技术沙龙

小白也能玩转Kubernetes 你与大神只差这几步

6月30日,腾讯云联合InfoQ举办的云+社区技术沙龙,以Kubernetes 上云一键部署、云上大规模计算平台构建、CIS底层技术实现、Tencent Hub...

59517
来自专栏维恩的派VNPIE

vn.py发布v1.8 - WebTrader

基于Web前端的量化交易应用WebTrader终于开发完成,之前实在是跳票许久。在此首先要感谢下负责开发Web前端的社区成员cccbbbaaab(这名字,怎么说...

3485
来自专栏杨建荣的学习笔记

物化视图自动刷新的碰壁(r7笔记第61天)

今天和开发的同事讨论一个问题,他们说source 1的环境中存在一个表,现在希望目标环境target 1和target 2中都需要用到这部分的数据。 ? 对...

3474
来自专栏程序人生

从 gitlab 事件中吸取的教训

题注:这是一篇去年的文章,今早看到 gitlab 运维人员愚蠢地 rm -rf, 心有戚戚焉,故而重发这篇文章,供大家参考。 ---- 这两天不是很太平,程序圆...

34510
来自专栏安智客

Android8.0中对指纹的新要求

Android O版本对指纹有啥特别要求? 我们前面也介绍过《Android O新特性之Treble介绍》,在Android O以及以后的版本当中,Androi...

2496
来自专栏开源项目

世界杯阵型之争的背后,国产开源项目百花争艳 | 码云周刊第 77 期

1413

扫码关注云+社区