敏捷交付中的自动化测试

提到敏捷交付，我们总会说到持续集成，持续交付，持续发布，即频繁地交付产品特性。而我们都知道 要实现真正的持续交付，必然少不了两个关键要素：

• 持续集成工具
• 自动化测试，自动化的产品质量反馈机制

一、自动化测试不只自动化工具

根据我个人的项目经验，试着画了下面这个图来表达这三者的关系。

在提及自动化测试的时候，很多人会把工具的使用等同于自动化测试。自动化测试应该是一个策略性的系统工程，不只有自动化工具。像我们的产品一样，不仅要有技术语言，还要有产品架构设计。

自动化测试除了工具框架，还需要考虑：项目的技术栈，产品架构，开发流程，基础设施，可靠的测试数据，稳定干净的测试环境，如何呈现测试报告，如何工程化测试配置，测试套件等等。

有了自动化测试还不够，我们的目的是在持续交付的过程中实现快速频繁的质量反馈，我们需要持续不断地测试（Continous Testing)。实现持续测试，不仅需要团队从文化上去支持，真正做到全员对测试和质量负责，创建Devops文化氛围，打通开发-测试-运维的壁垒；还需团队从技术上去储备知识，比如云平台、虚拟化技术，容器及相应的编排技术，甚至网络知识等等。

从定义可以总结出自动化测试的两个特点：

• 自动化测试本身也是软件
• 自动化测试基于预期结果进行断言

测试，质量评估的重要手段之一，而自动化测试只是测试的一种具体实现方式而已。它能释放QA的双手和一部分大脑（这部分大脑，即know knowns），将对已知特性和既定逻辑流程的检测交由计算机来完成。而QA去做更多需要思辨能力，分析判断能力的事情。例如，通过向团队提问，来澄清需求的unknowns；通过探索产品去拓宽对产品的knowns；抑或运用经验帮助团队走出Unknown Unknowns 带来的迷局。

从这个定义可以看出，持续测试的目的即在软件交付的流水线中执行自动化测试以提供对产品质量的反馈。

• automated tests 而不是automated test，一个产品只有一种，或者某一层级上的自动化测试是无法达到整体质量评估的，持续测试需要不同类型的自动化测试在交付的不同阶段为产品的不同层级提供反馈。
• delivery pipeline，immediate feedback，自动化测试一定是和交付流水线交合集成的，至少是同频运行的，不是孤立的，只有这样才能就团队每一次的新变更对产品质量的影响做出快速而及时的反馈。
• business risks，持续测试广义上来说包含交付中的所有质量反馈行为，既要测试左移，质量内建，也要测试右移，实现产品质量主动监控，不然无法识别业务风险。

二、测试工具的选择

测试工具的选择需要考虑项目的技术栈，也需要考虑QA自身的技术能力。

不管多火的工具，如果不能兼容项目的技术栈和基础设施，那都无处发挥其优势，流行的不一定是适合项目的。

这两年Cypress真的很火，去年在项目上做UI自动化测试的时候，出于好奇也想实践一把。实践出真知，Cypress本身可以通过环境变量和plugin配置代理，但是不支持socks5的代理（客观现状是项目所有资产，包括测试环境都是通过socks5的代理连接），线上环境无法访问。当时还试过将socks5的代理转换成http代理，但因为Cypress本身是多线程的，而socks5只能截获第一个进程的网络通信， 即使能连通应用本身，Cypress也无法将测试过程可视化的优势发挥出来。人无完人，工具也一样，只有适合你的才是好的。

• 支持不同的helper: WebDriver, Puppeteer, Protractor, Nightmare, Testcafe， 我在项目上选用的是Puppeteer。
• 支持web也支持mobile，当时项目上的第一个产品是有手机端版本的， 这也是选择这个工具的一个考虑。
• 封装良好的页面元素操作方法，拿来即用，对于不擅长编码的我来说，非常友好。
• 因为项目产品是和矿场上爆破紧密相关的，很多产品都有矿场地图展示和设备可视化，CodeceptJS 提供了现成的codeceptjs-resemblehelper以实现视觉上的回归测试。
• 最近发现它还支持API测试，包括REST和GraphQL的， 但是这部分特性尚未实践。

由于团队有完全的自由来选择技术栈，在做第三个产品的时候， 我们的开发小哥哥就已经不满足于只写REST API了，第三个产品开始引入GraphQL。在以前的项目上用过REST Assured 做API测试，觉得也是好用的，但当时并没有选用REST Assured, 因为在那时，刚好发现一枚ThouhgtWorks开发自己做的API功能测试工具 Pandaria。

三、选择合适的时候做自动化

选择合适的时候做自动化, 避免不必要的浪费。

在项目做第一个规范安全流程的产品时，MVP1(Minimum Viable Product) 一完成，该产品的接口自动化测试和端到端自动化测试便实现了，并集成到了产品CI/ CD 流水线上。后来由于客户方硬件集成的问题，该产品基于MVP1进行了一次演进，从产品直接融入并规范安全流程换成了‘曲线救国’地强化安全流程，页面和接口设计也有较大变动。由于产品流程设计上的变动导致之前的接口测试和端到端的自动化测试全部都失效，需要重新编写和维护。

我们选择自动化一定是要考虑项目是否存在客观的现实需求，在动手实施具体的自动化测试之前，一定要对自动化测试的投入产出比做一次客观理性地评估。

四、自动化测试和产品代码一样重要

自动化测试和产品代码一样重要，需要全员负责。

虽然敏捷强调质量全员负责，但我所待过的团队，做过的项目，践行得好的很少。幸运的是，现在团队的质量意识都很好。但故事一开始不都是美好的，每个团队都是在 “掉坑-反馈-调整磨合” 的循环里走向成熟的。

在交付一个微服务化的产品时，后端多个API，每个API有相应的API集成测试，产品还有UI测试，同时团队还有额外的3个产品需要维护。每个产品都有自动化测试，前端的后端的。其中一个微服务实现的产品就有四套测试，而且后续还会增加视觉测试。

在刚开始的时候，测试挂了没人去看，也没人去修。由于项目是基于Truck Based Development，为了保证测试的及时性，每天不是在加新用例的路上，就是在修各种测试的路上。UI测试相较于API测试更为脆弱，需要频繁的维护成本，特别是项目基于主干开发的团队。那段时间感觉自己成了automation engineer，对产品新增的功能特性并不是非常清楚，对故事卡的可测性也没及时作出反馈，感觉自动化并未真的达到释放自己精力和时间的初衷。 

如果只是QA一个人来维护管理，那么这个QA一定做不了自动化以外的事情了。ThoughtWorks好多项目都只有一个QA，我们的这个QA是Quality Analyst， 并不是Automation Engineer。敏捷项目之下，QA的首要任务应该是驱动团队各个角色对质量负责。

• 为每套自动化测试编写清晰的README, 保证团队里除你以外其他的小伙伴，也都清楚明白如何运行自动化测试。
• 除了实用的README引导团队如何运行测试，可视化良好的测试报告也非常必要。如下是我们项目上的测试报告：

• 让UI测试更稳定，请求开发把页面的关键组件元素加上ID 属性，用唯一的ID去定位元素就稳定多了。
• 建议每个Dev提交代码前，在本地自行运行测试脚本，保证自动化测试的及时性和正确性，并对新变更提供及时的质量反馈。

除了以上， 项目还需要有高度可视化或者能及时通知测试状态的方式。

项目上用的是Jenkins自带的 Build Monitor View。将对项目pipeline的监控投影到电视上，并配置相应的提示音，能非常及时地让团队知道最新的构建、部署、测试状态。

如下是我们项目上当前的一个流水线dashboard：

这些实践都是对“质量全员负责”最落地的践行。我相信，每个团队是不一样的，但是敏捷QA的主要价值一定是能驱动团队为质量作出改进和贡献。

五、持续测试还需要团队具备DevOps相关技术

持续测试除了自动化测试还需要QA和团队具备Devops相关的技术。

1）测试工具相关的

• 在容器里安装puppeteer之前，需要手动下载Chromium包以及相关的依赖。 
• 在docker里面启动puppeteer，要么配置一个puppeteer的user，要么选择去掉默认的沙盒环境。
• 当时还遇到因为docker默认的64MB内存空间不够，Chrome渲染页面崩溃。

2）测试报告可视化相关的

测试报告对于我们快速定位失败根因有很大的帮助，好的测试报告可以直接揭示问题的根源。在云端运行测试，我们通常希望测试工具能输出可读性强的测试报告以方便非技术人员阅读，也希望测试工具能把运行过程的细节打印在console里，以方便技术人员定位根因。

像前面提到的CodeceptJS它就提供多种不同形态的运行，并且可以运用Mocha生成各种类型的测试报告。目前市面上的测试工具，都会有对第三方库的依赖，特别是前端测试框架和工具，这个对QA或者团队的技术宽度是有一定要求的。

另外Jenkins有非常丰富的插件库，在选择测试工具的时候可以把是否有Jenkins报告可视化支持考虑进去。QA需要对Jenkins和测试工具都相当熟悉，还需要知道如何通过将某一测试工具生成的某种格式的测试报告集成在Jenkins上以方便一键获取测试报告。像cucumber的测试报告插件：

像Allure的测试报告插件：

3）Pipeline as Code

想要集成测试到流水线，不可避免是需要一些DevOps相关知识的。

也许项目的需求是如何通过Jenkinsfile 并行运行各种测试，也许是通过Jenkinsfile传递测试相关参数以为云上运行测试所用，还也许你需要在Jenkinsfile里添加调试信息用以线上调试，等等。

云上运行，我们还要学会如何在一个slave 上优雅地管理运行测试的容器，不出现容器占用，slave内存不足，测试失败之后报告不可得等等问题。

六、最后用个比喻结束这篇文章

会自动化工具算是有了织网的道具，有自动化测试资产算是编出了能捞鱼的网，而持续测试才能真正地实现持续交付，才算是把一张张过滤不同缺陷的网放置于了不断提交变更的交付之流中。

只有网而无法至于河里，或者不知道于何处放置，那就只能站于岸边时时撒网捕鱼，不够及时，也不算释放了捕鱼人（QA和团队)。

我们期望的是，各种不同的网（自动化测试资产），置于不同的河段（软件产品的不同层级：函数级别？组件级别？接口级别？系统级别？），过滤不同的鱼（缺陷），而不管是谁（团队的所有角色）都可以去确认有没有捞着鱼（测试挂了吗？为什么挂？我们对目前的变更有足够的信心吗？），也需要所有人时时确认我们的渔网是不是破了？（测试覆盖率不够？断言不严谨？测试用例过时？）。