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

lsekfe

【引入】
　　说起“测试左移”相信对于大家来说已经不再陌生，左移的也手段非常多，无论是使用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开发进度的依赖。

z00100

左移”后的测试流程：
　　1、接口文档确定—>编写接口测试代码；
　　2、接口开发完毕—>使用PiTest进行接口测试，关注接口逻辑，并接入UTP；
　　3、FT内功能开发完毕—>使用PiTest进行Mock测试和异常测试，关注功能逻辑；
　　4、FT联调—>测试FT之间接口相互影响与用户体验。
　　测试左移的流程一方面将测试的关注点从接口，功能，用户体验逐个级别关注到，另一方面将测试介入时间大大往前提，提早暴露缺陷，FT内开发完成即可开始测试执行，降低测试执行与FT开发进度的依赖。