【腾讯TMQ】【测试左移专栏】手机管家PiTest测试左移实践
作者：CC
团队：腾讯移动品质中心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或者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，不必到提测才发现，甚至可以发现因测试遗漏而导致的线上缺陷。
原文链接：http://tmq.cs0309.3g.qq.com/2017/05/pitest/
获取更多测试相关干货 请关注我们的微信公众号——腾讯移动品质中心TMQ：
版权所属，禁止转载