万物皆可 pipeline，流程自动化解放生产力。在 DevOps 的 pipeline 中，我们发现测试环节也需要一套流水线化的能力，来保证研发流程的大批 pipeline 稳定高品质交付。

下面介绍下 DevOps 中如何构建高水平全面的测试能力。

文化、流程、组织结构、技术发生变革，对测试提出新要求

· DevOps 文化对测试带来的新要求（文化）

为适应市场的快速变化，要求企业的产品快速迭代，柔性应对用户需求，滋生了 DevOps。

《持续交付 2.0》中，作者将 DevOps 简化概括为 2 个环：价值探索和快速验证。

价值探索是快速发现和识别外部客户的真实需求，为其创造价值点。"快速验证环"要求企业在找到业务问题制定业务目标后，快速实现和落地价值点。

测试属于"快速验证环"，过程中要求开发/测试/运维的角色紧密配合，高效高质地落地验证新特性。

· 在 DevOps 中构建测试工作的难点（流程）

在 DevOps 趋势下，测试部门从原先的大量集中测试，变成了高频快速测试。

原先大部分企业采用纯手工测试的方式，从根本上无法适应 DevOps 的高频快节奏需求。滋生了对自动化测试的诉求。

· 头部企业测试部门的现状（组织架构）

· 人力外包比重高：

金融/通信/航空等大型企业的外包人力与正式人力之比，往往超过 5:1，人员流动性高，素质参差不齐。对工具和系统的稳定性和使用门槛提出要求。

· 从集中到分散又回归集中：

企业初期业务较为单一，测试需求归拢到统一的测试部门。

随着企业业务的扩充，为了快速满足各个业务的测试诉求，将测试人员直接放到各个业务组，实现业务内快速开发测试发布。

业务量更加庞大后，避免分散研发使各个业务组重复陷入低级别的研发活动，产生技术竖井，为实现技术资产的继承积累，研发流程从分散开发趋向于基于中心化的基础设施开展，也就是现在常说的"中台"概念。测试工作也因此产生变化。除了测试各个业务的具体功能本身，也需要对基础设施本身的质量，以及各模块专项能力做统一的测试，确保整体的健康度维持在一个可控的标准。因此，又产生了集中化的测试需求。

文化、流程、组织架构，以及新技术（容器技术等）多重力量，助推测试的敏捷化。

基于 DevOps 对测试提出的新要求，市面上也越来越多自动化测试的工具，开发者面对大量工具系统，往往需要经验和时间成本去筛选：

问题一：在哪些环节加入测试？各个环节适用什么类型的测试来保障该环节质量？

问题二：在人员结构和组织架构等约束条件下，各环节选取什么样的测试方法和工具？

下面咱们一一来分析这些问题。

问题一、测试可以渗透到哪些环节

在 DevOps 文化中，强调打破不同职能之间的隔阂，对于测试部门而言，意味着测试活动的"左移"和"右移"，从需求分析到产品上线，各个环节把控质量。在一些偏研发和偏运维的环节，测试人员可以帮助建立整套质量评体系和工具组，来保障上下游的整体质量。

例如在开发编码环节，主要是单元测试和 code review。对于大部分企业而言，这个工作主要是研发人员在做。测试需要做的事，推动这个环节的质量意识，帮助开发同学搞定单元测试和 code review 的工具和结果记录，做到有迹可循。

测试时间提前：测试不再等开发结束后再测试，而是将测试时间穿插在开发阶段，减少测试时段的长度

单元测试提前：开发每完成一个模块的编码，先对本模块进行单元测试，业务逻辑比较清楚，不需要重新回顾，效率较高

单元测试有据可依：测试在开发进行单元测试前提供每个模块的用例设计，供开发参考，使得单元测试更全面

单元测试 review:每个模块单元测试完成后，测试进行单元测试 review，使得单元测试更全面，代码质量更高；同时发现代码或单元测试的问题开发及时修改，不需要打包，缩短提测试时间

开发与测试密切合作：每一模块都需要开发和测试密切合作、共同完成，测试和开发的合作更加密切，开发的测试水平提升更快，测试阅读代码的能力也会进步很快

测试工作量和测试周期减少：由于单元测试很充分，所以每个 job 的测试可以省去，只做集成 | 联调测试，大大减少了测试工作量和测试时间，从而缩短整个项目周期

问题二、在人员结构和组织架构等约束条件下，各环节选取什么样的测试方法和工具？

· 测试管理

管理工具的目标是提升效率和协同性。市面上已经有非常多成熟的管理工具。如果是业务比较复杂的超巨企业，测试部门更关注的是对于不同测试管理系统的适配性。

举两个例子，以下两张图，分别是技术积累做的非常不错的两家企业测试部门的流程，差异比较明显。

这种实际环境下，对测试管理平台灵活性的要求就很高。

· 工作流程灵活可配置

· 可集成现有管理系统

· 过程/结果的可视化

目前我们平台支持按工作流来组织测试计划，并分配任务，项目进度、人力分配可视化跟踪。

测试本身也是一条流水线，支持用户向右无线扩展测试环节；每个测试环节支持向下无线扩展"测试任务项。

同时，平台支持 jira/tapd 等管理系统的集成，需求和缺陷打通。脚本方面支持打通 git 和 svn，直接同步脚本到 WeTest 测试平台。

· UI 测试

UI 测试是门槛最低，最常见的一种测试类型。一般在功能验收，以及专项测试阶段比较常用。UI 测试有 web 端和移动端。web 端的测试主要以 selenium 框架为主。市面上也有比较通用的录制回放工具。移动端的 UI 自动化测试由于设备型号多而杂，给测试部门带来更大的挑战，近几年出现的移动端测试框架也越来越多。

之前提到组织架构里外包比重较高，因此，UI 自动化测试工具的使用门槛一定要低。业界有较多的脚本录制回放工具。在实际操作过程中，往往会发现这些工具有以下弱点

· 元素识别困难

金融行业的乱序密码盘和防截图安全控制，把很多用例挡在门外。实际上大多数乱序密码盘的问题都是可解决的。

· 脚本回放成功率低

鲁棒性低：顺序流的脚本，回放时只要有 1 个步骤未按预置流程走下去，就会卡住，后面的脚本就白搞了。

适配性低：录制的脚本在不同的设备上，由于分辨率和尺寸的不同，导致无法回放。这就对工具的识别方式提出了更高的要求，不能是简单的坐标识别。

· 易用性差，影响效率

很多脚本录制工具为了提升识别效率，采用图像 + 控件双重识别。图像识别过程往往需要用户框选出需要识别的区域。大大降低了录制脚本的效率。也提升了工具使用的门槛。我们期望一种无感知的录制工具。用户在手工测试过程中顺便把脚本录制了。

这些点，我们自研的小工具 UITrace 都解决了。目前这款工具也是 WeTest 用于交付兼容测试任务的主要工具。

除工具问题外，由于移动端 UI 测试涉及到大量设备的运维管理，在稳定运营的基础上，有效降低运维成本，提升运维效率，是进行日常 UI 测试的前提。对于硬件的运维，WeTest 在管理上万台设备的过程中，总结出 43 条运维规则，自动识别和秒速处理"开发者模式误触关闭""内存占满""熄屏锁屏"等问题。保证机房 7x24 小时稳定运行，实现 1 个运维人员可管理上千台设备的效果。