继续探索持续集成（30）

草帽路飞UU

5.5  测试平台化



　　DevOps加速了端到端的交付速度，这推动了持续测试的发展。如果要推行持续测试，那么自动化测试会是必要的技术方案之一，但是自动化测试对测试人员、团队技术成熟度都有着非常高的要求。测试

平台化就是解决自动化测试技术门槛和推动持续测试之间的矛盾的利器。

　　在DevOps流水线过程中，测试开发工程师的工作是从接口自动化测试开始的。测试开发工程师通过编写接口自动化测试代码、设计接口自动化测试设计并上传到代码仓库，通过DevOps流水线调用接口

测试脚本而完成接口测试。接口自动化测试所用到的测试框架一般是团队按照自己的技术栈、技术基础封装的。接口自动化测试通过的规范要由测试开发工程师和研发工程师共同制定，在通过接口自动化测试

后，就进入界面自动化测试阶段，也就是UI自动化测试阶段。

　　UI自动化测试阶段由测试开发工程师主导，通过编写基于验收业务逻辑场景的UI自动化测试脚本并设计测试数据，完成UI自动化测试从而实现ATDD。UI自动化测试最好也可以通过DevOps流水线驱动，

这里如果测试Web服务，可以在Linux服务器上使用无头浏览器（headless browser）完成，浏览器兼容性可以通过SeleniumGrid组件设置。

　　对于App，需要通过模拟器或者真机完成测试。如果兼容性也是项目关注的一个重点，那么推荐使用STF手机终端管理平台，完成兼容性自动化测试。类似于接口测试，这里也要定义UI自动化测试的通过

标准，以及满足兼容性的标准。

　　上述流程全部完成后，制品不应直接提交到生产环境。完成探索测试阶段，再次确认业务流正确并且交互过程符合易用性要求后，才会完成质量门禁，进入持续部署流程。

　　上述流程已经把自动化测试发挥到了极致，在真实工程的交付过程中，绝大部分IT交付团队无法达到如此成熟的程度，具体原因如下。

　　工期紧张，交付压力过大，开发工程师不会在代码评审、单元测试上花费太多时间，从整个团队的角色成本上看，开发工程师的平均成本远远高于测试工程师的平均成本，团队会让成本更高的开发工程师

从事创造性的工程任务，质量保证内容交给测试工程师，在后续阶段进行弥补。

　　测试工程师的技术水平普遍较低，让测试工程师写代码是一件很难的事情。虽然测试工程师入门时具备差不多的编程基础，但是随着时间的推移，测试工程师写代码的技能已经弱化。

　　这些因素阻碍了测试自动化技术体系的落地。

　　在当今的工程效能之下，DevOps不断地加快端到端的交付速度，交付的加速与上述半自动化的测试过程，乃至全手工化的质量保障环境形成了鲜明的对比。

　　为了高效地构建高质量的软件，团队不得不在交付流程中不断地执行自动化测试脚本和手工测试，这说明质量保障是制约快速交付的问题之一。因此，持续测试应运而生。持续测试是一个过程，它将自动

化测试技术作为软件交付流水线中内嵌的一部分，以尽快发布软件、持续反馈技术风险为主要目的。

　　持续测试的出现适应了DevOps的要求，但是测试工程师的技术水平及自动化测试本身的一些技术壁垒让持续测试成为很多团队难以跨越的鸿沟。测试平台化刚好可以解决该问题，帮助团队跨过这个鸿

沟，迈入高效团队的阵营。

　　在绝大分团队中，有负责工具组的团队，团队成员会为整个持续测试提供测试工具从而实现测试平台化。如果团队中没有专门负责测试平台的人，那么在代码扫描部分可以使用SonarQube，在接口自动

化测试平台部分可以使用Yapi，单元测试和UI自动化部分目前没有成熟的开源解决方案，使用SonarQube代码扫描平台、Yapi接口测试平台至少能够满足测试平台化的基础需求。

　　测试平台化的优越性如下。

　　将自动化测试门槛降到足够低，低到只要有测试基础的测试工程师就可以完成自动化测试。

　　统一技术。推行测试平台化不再需要兼顾各种技术栈，只需要按照自己设计测试平台的技术栈在团队内进行提升就可以。

　　降低高级测试技能的学习成本。对于测试行业中的高级测试类型（如性能测试），通过测试平台化降低学习成本，让所有人都可以完成。