DevOps中的测试实践

2020-12-15  腾讯质量测试 


万物皆可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工作流的代码质量。避免低质量代码进入进入下一个环节,浪费下游测试资源,举例如下



微信MR过程触发WeTest门禁



腾讯WeTest平台服务于质量领域超过10年,拥有丰富的多行业(包括金融、游戏等)测试经验。2019年正式推出私有化部署解决方案,致力于服务对私密性、安全性有更高要求的企业,帮助企业打造属于自己的质量中台。



欢迎访问页面,查看解决方案介绍:https://wetest.qq.com/solution/private?from=others_content_private


105°|1055 人阅读|0 条评论
登录 后发表评论