【 测试左移专栏 】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：