| 编辑推荐: |
本文主要介绍了DevOps中如何构建高水平全面的测试能力。
本文来自于博客园，由火龙果软件Linda编辑推荐。 |
|
万物皆可pipeline，流程自动化解放生产力。在DevOps的pipeline中，我们发现测试环节也需要一套流水线化的能力，来保证研发流程的大批pipeline稳定高品质交付。
下面介绍下DevOps中如何构建高水平全面的测试能力。
1. 文化、流程、组织结构、技术发生变革，对测试提出新要求
· 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个运维人员可管理上千台设备的效果。
· 接口测试
接口测试是一项性价比很高的测试活动，接口相较于UI，变化不大，较为稳定。接口测试主要关注以下几点。能把这些点都做足，基本上可以cover90%以上的需求。
· 适配性：支持的协议/报文格式范围更全面（例如近几年兴起的dubbo/grpc/trpc，以及经典的http/https，WeTest平台均可支持）
· 兼顾易用性和管理能力：既要像postman一样实时调试，又可以支持用例管理，测试任务，报告管理的管理功能，便于复用和进行历史追溯。目前WeTest平台可以满足需求
· mock能力：可按需求定制mock规则
· 自动生成用例组织测试的能力：提供了fuzz 安全测试：支持随机填充、SQL注入、XSS攻击、OS命令注入等攻击模拟脚本的自动生成和执行。
· 预处理脚本coding能力：灵活地进行逻辑控制
· 上下游链路整合：支持链路性的接口测试，而不仅仅测试单个接口。前序接口输出作为后续接口参数输入
· 压力测试
若出现服务器宕机，业务会陷入瘫痪；若延迟较高，用户感受也会受明显影响，造成口碑下滑。服务器压力测试，主要关注以下几点：
· 并发量：并发量大且稳定是基础要素，是做压力测试的前提条件。目前WeTest并发量可达百万级别。
· 模拟真实场景：WeTest支持通过接口传参构建上下文链路场景，模拟真实环境下的各个接口并发量。
· 兼容各类脚本：jmeter/fiddle等主流脚本框架
· 支持coding模式，多种协议和语言，便于灵活地构建测试场景。
· 监控维度科学、全面：覆盖TPS、响应时间、收发包量等种基础性能指标及进程级服务器等14项数据，见下方WeTest压测报告截图。
· 其他
除了解决上述工具和系统的问题，我们在流水线上要有设置质量红线的意识
质量红线不仅被用来保证转测/发布的质量，还被用来保证Git工作流的代码质量。避免低质量代码进入进入下一个环节，浪费下游测试资源，举例如下
腾讯WeTest平台服务于质量领域超过10年，拥有丰富的多行业（包括金融、游戏等）测试经验。2019年正式推出私有化部署解决方案，致力于服务对私密性、安全性有更高要求的企业，帮助企业打造属于自己的质量中台。
|
