Macaca 语雀质量体系与自动化

骁睿 · 2023年01月13日 · 最后由 imjie007 回复于 2023年01月19日 · 8244 次阅读
本帖已被设为精华帖!

1. 整体介绍

大家好,我是语雀 QA 会能。
很高兴,有机会跟大家聊一下语雀的质量体系和自动化技术。
下面会分几个部分给大家介绍,让大家可以了解到语雀质量体系的全貌。


1.1. 语雀产品特点&研发特点

首先,简单分析一下语雀,相信很多朋友对语雀都是不陌生的。
「语雀」是蚂蚁集团旗下的文档与知识库工具,源自蚂蚁集团和阿里巴巴内部文档协同需求,2018年1月8日正式对外提供服务,现已服务于数十万企业组织和数百万个人用户。

再从研发角度看,语雀是一个大型 全栈 多端 应用,包括了 web 端、移动端、桌面端。
语雀的研发基于 One CodeBase ** 模式(类似 google 的项目研发,所有相关工程都在一个大的 git 仓库)。
另外还依赖研发管控、任务跟踪、代码服务、构建流水线等平台。
语雀的迭代发布比较快,在工程上,
技术团队对持续交付的稳定性和效率有着很高的要求 **。

然而我们的 QA 就只有我和另外一个同学确知,测试开发比接近(1:20),在这样的情况下如何做好质量保障工作就成了一个大问题, 下面来说说我们的解法。

1.2. 语雀技术的:教练模式

我们的解法是 “教练模式”。
什么是教练模式? 简单的说 QA 同学就相当于教练,通过各种质量保障机制规范和提升开发同学的质量意识,提供完备的质量服务提升研发效能,从而提升语雀产品的质量。
另外,我们希望通过工程化的方式使质量成果可沉淀,可长期持续,这也是语雀质量技术从起步到发展的的初衷。

1.3. 质量架构

再来看看我们的质量工程的顶层架构,框图中最底层是我们依赖的基础平台 (例如研发管控、任务跟踪、代码服务、构建流水线平台等) 。
再是质量基建,服务于语雀质量的各种能力,包括语雀质量的技术基础 和 “看不见质量”,偏软性但又极其重要的,质量意识和工程文化。
技术基础像 skytest 支撑工具、Lark-Reliable 测试报告和覆盖率持久化查看、Macaca 套件提供了 UIA 技术支持,在后面的会有详细的介绍。
质量能力,就是语雀实际解决的问题和质量成果了,相关领域包括持续集成、缺陷收敛、线上巡检、UI 自动化建设,长效机制建设和研发提效,后面也会详细介绍。


2. 质量支撑工具

每个质量团队或多或少都会有质量支撑工具或服务,以解决团队内的质量问题,接下来介绍 SkeyTest 和 Reliable。


2.1. SkyTest

大多质量团队都会有一些核心的测试支撑工具,我见过比较多的是 web 服务的形式提供的,比如 xx 测试服务,xx 测试平台,这就要求团队内需要有全栈开发的同学,并且对这样服务的开发维护投入还是比较大的。

SkyTest 就是语雀的主要质量支撑工具,它承载了语雀质量技术沉淀,就好比 QA 同学的 “百宝箱”,里面有各式各样趁手的测试工具,为语雀质量能力建设奠定了技术基础。

SkyTest 以 npm 工具模块的形式存在,可以直接通过 cli 的方式使用,或者以 node 模块集成,集成便捷,比较轻量,适合 QA 工具的研发。维护成本相对 web 应用要轻量很多。


2.2. Reliable

LarkReliable 作为质量数据持久化&洞察服务,和 SkyTest 搭配,能够满足大部分测试能力的实现。目前在语雀除了集团内其他平台提供的专项能力外,团队内的质量能力实现都是能够 Hold 住的。

基于开源的 Macaca Reliable 套件实现,如果所在团队正好缺少类似的工具服务,完全可以基于开源的 Relibale 套件,快速实现团队内的测试报告持久化和数据洞察的服务能力。

  • 测试、覆盖率报告查看
  • 覆盖率洞察


3. 建立机制

通过建立机制 形成长效收敛的质量闭环,其实我们最初的想法很简单就是想办法通过自动化 QA 同学的工作流,让质量同学能空出手来做更有长期作用的质量工程建设。过程中逐渐沉淀了一个个机制,通过高度自动化,提升效能。
在质量体系建设初期做好机制闭环,带来的长期收益是非常可观的,推荐优先切入建设。


3.1. 周迭代值班

迭代有序化,有点像项目经理,在语雀日常迭代管理、发布执行都归 QA 同学。
两个 QA 同学轮流按周迭代值班,保障发布质量,做好 UIA 回归卡点、发布执行和 hotfix 复盘。

最初我们的发布节奏是 一周两次,频繁的发布使得发布质量不可控,产生较多 hotfix,所以在保证足够敏捷的同时,我们将服务端发布节奏控制在一周一发。可能对很多业务团队来说,一周一发也是很高的频率了,大部分产品的迭代周期一般都是半个月或一个月发布。

但是,如何在高频发布下保障交付质量?关键还是需要持续集成能力和自动化能力,相信通过后续的介绍,会有答案。

3.2. 缺陷收敛

线下缺陷播报

相信大家都有看到过,在缺陷池里摆烂的缺陷吧,(大多是一些重要不紧急的缺陷,推不动解决)是不是很揪心,有强迫症的同学们可能会受不了。

其实通知类的功能不难实现,语雀做的其实相当于做好 “快递的最后 1 公里”,将缺陷管理平台中的缺陷统计分析后自动化播报到研发群中(其实是对缺陷管理平台能力的扩展)。

我们建立了日报 / 周报 机制,有效促进收敛,清理缺陷历史债, 最终保持人均一个。慢慢形成了团队内的习惯和心智: “缺陷进池,一定会被解决。” 做到有始有终,从恶性循环变成良性循环。



线上日志缺陷治理

缺陷的另一个重要来源: 线上异常和缺陷
针对这部分缺陷,我们通过不间断获取、分析线上日志的方式,及时发现线上发生的缺陷,并自动化录入到对应的缺陷管理项目中,我们对日志内容进行规则自动分析并按照主站、移动端、桌面端归一分类指派给对应的负责人修复,整体效率和信息及时性在潜移默化中得到很大提升。


3.3. 覆盖率治理

增量覆盖率 PR 合并卡点

增量覆盖率卡点的意义,相信不用多说。当新代码无单测合入就会导致整体覆盖率越来越低,会加剧代码腐化。
因此,我们在 PR 环节加入了增量代码检测能力,为评审人和开发同学提供直观的覆盖率报告,同时也希望能激励大家能够及时补充单测用例;(也是扩展了代码管理平台的能力)

实现分析: 每次单元测试执行后生成的覆盖率信息和 PR 的 diff 信息通过计算获取增量的覆盖率信息,最后通过macaca-istanbul工具 生成覆盖率报告(支持颜色渲染和缩略图)。


全量覆盖率 - 项目覆盖率治理

语雀团队很注重测试覆盖率,一直以来保持在比较高的覆盖率水平,项目覆盖率的跟踪这块原来也都有,但是年久失修一些项目的覆盖率数据没有及时更新和维护。
我们通过搜集、合并分散在各 CI 任务中的项目覆盖率数据,然后每周通过钉钉进行覆盖率播报,有效恢复了各项目的覆盖率跟踪,实现了覆盖率的长期统计跟踪机制。

实现分析: 收集 CI 中运行的单测任务覆盖率信息 -> 测试结束时合并相应的覆盖率数据上传到 Reliable,并按周进行覆盖率数据的播报。


3.4. 线上不可用治理

先说说为什么做这个事,过去,语雀会有遇到因为低版本或不支持的浏览器造成的线上不可用问题,经常也会收到用户类似的反馈,很影响用户体验。web 应用其实都会有类似的问题,从根本上杜绝是我们的目标。

我们针对低版本内核不兼容、白屏的死角问题,进行监控和不支持引导。同时建设了浏览器版本分布情况的准确的感知能力。我们的目标是做到三个一定:

  1. 一定没有不明确的浏览器版本
  2. 明确的浏览器版本一定可用
  3. 主流的浏览器一定支持自动化回归



3.5. CI 问题跟踪

语雀日常 CI 任务经常因为一些问题不通过,非常影响研发效率。其中有工具的问题、有用例本身设计不稳定(比如缺少 mock、时序调用错乱、断言粒度不合理等)。
为了促进大家日常及时解决不稳定问题,及时通知反馈问题的指派人,我们实现了 CI 问题的自动化跟踪机制。

  • 自动化发现问题(日志、缺陷池、覆盖率数据、CI 报错等等)
  • 自动化指派跟踪 (项目缺陷管理平台)
  • 及时消息通知(钉钉机器人)

通过高度的自动化,使收敛变得自然,研发变得高效。

4. 持续交付

没有持续集成的时候是怎样的:
开发合并了 PR 之后,需要人工及时部署更新,然后反馈给开发同学,让开发同学去验证,虽然只是些点击和通知操作,但环节之间都是割裂的需要人工执行,打断工作节奏不说,费心费力。并且自动化的功能性集成测试也是缺失的。

为了解决这些问题,我们重点建设了稳健的 CICD,从代码合并开始,到后面的部署、自动化测试回归一气呵成,敏捷理念中的持续集成是实际在做的,让持续测试成为了我们的基本规约。


4.1. 主站点

通过日常迭代分支的 PR 合并,触发对应的 CI 流水线任务,完成持续部署和持续测试。
会有详尽的通知,比如直接给到迭代验证地址链接,直接能看到已部署的 PR 信息,看到持续测试的报告链接等等,尽可能为研发同学带来便利,提升研发体验和效率。

4.2. 桌面端 CICD

不仅仅是主站,我们桌面端和移动端的开发同学也能享受到尊贵的 CICD 服务。
桌面端实际上是一款桌面应用客户端软件,桌面端的持续测试和持续部署是通过办公网的一台 macmini 实现测试回归环境,在构建平台触发构建后会异步通知 macmini 进行自动化集成测试和报告的发送。

  • 桌面端


4.3. 移动端 CICD

移动端的持续集成通过构建平台打包后 使用 蚂蚁云测平台(提供移动端真机测试服务)触发执行 UI 自动化测试任务,在执行完毕之后也会发送相关报告到钉钉群中。


4.4. CI 提效

CI 慢、不稳定的问题一直以来是语雀团队的痛点问题,极其影响研发效率。
我们从各个细节优化了整体 ci 的效率和稳定性。

  • 通过 Docker 技术做镜像级别的缓存,解决 clone 环节慢,git 拉取不稳定的问题。
  • 通过 自研 job_keeper 工具实现不稳定任务自动重试。
  • 通过 shell 脚本异常捕获和处理,提升脚本稳定性。
  • 通过 拆分 CI 任务,降低整体耗时峰值。

从各个细节优化,使 CI 缩短了执行时间,提高了成功率, 减少了人工重试负担。
优化后,正常 15 分钟以内可以完成一轮全量回归。

完善的 CICD 能力,使得在语雀做研发是一件很幸福的事。极大提升了研发同学们的工作体验和效率。

5. UI 自动化技术

测试金字塔: 相信有同学见过,这种下宽上窄的三角形结构,代表在各层自动化的建议投入分配比例。
语雀的单测是开发同学们自己负责的,QA 同学负责 UI 自动化测试部分的测试。在我加入语雀之前,语雀在 UIA 领域就有比较多的实践,UI 自动化是我们一直坚持的质量保障手段。

相信也有很多质量团队尝试过 UI 自动化,但很少能有坚持持续做的,原因有很多,比如下面的一些因素:

  • UIA 的实践曲线很陡,技术门槛比较高,在技术选型和工程化实践阶段就放弃了。
  • 需要有一定的用例量和成熟的工程实践,才能发挥效果,短期 ROI 很低,团队没有持续投入的动力。
  • 用例的维护成本高,UI 一旦发生较大变化,就需要更新用例,如果实践经验不足会导致不可持续。

其实语雀质量作为 “过来人”,也是遇到过同样的困难,语雀的 UIA 成功和团队前期摸索的持续投入有很大的关系。


  • 自动化发现的问题

目前进入了收益期,通过 UIA 目前已发现的关键问题已达到 70+,相当于避免了多次 hotfix,有效避免了大量线上缺陷的发生。
UIA 的一些优势:

  • 自动化测试可以代替大量的手工机械重复性操作,可以省下大量时间专注于设计测试用例。
  • 研发提效自动化测试可以大幅度提升回归测试的效率,非常适合敏捷开发。
  • 支撑稳定性测试和巡检 使得 7*24 小时核心功能稳定性测试、自动巡检成为可能。

5.1. Macaca 套件

Macaca 是一套面向用户端软件的测试解决方案,提供了自动化驱动,环境配套,周边工具,集成方案,旨在解决终端上的测试、自动化、性能等方面的问题。
我们的自动化能力就是基于 Macaca 扩展实现的。

Macaca 是设计典型的 C/S 架构,提供了标准化的驱动层,消除了各技术平台测试技术栈的差异。用户侧的 API 设计只需要遵从 W3C webdriver 标准 就可以轻松实现多技术栈接入,驱动各类浏览器/设备的自动化测试执行。



5.2. 多浏览器

我们的 UIA 覆盖了 Web 端 Chrome/Firefox/Safari/Edge 多种主流浏览器,全量 UIA 回归任务基本能够在 30 分钟内完成
积累用例总数 2k+ 500 余条用例涵盖了已有业务核心链路和功能,自动化率达到了 51%
多端回归我们是通过封装 macaca-playwright 驱动实现的,playwright 是微软开源的驱动框架,提供了比较全面、强大的 web UI 测试能力。



样例报告,过程中提供视频回放,每个细节都可以回溯:


5.3. 桌面端 UIA

通过研究和实践系统自动化能力,将系统操作能力封装为 macaca-macos 驱动。
使我们的自动化技术从基于浏览器跨度到基于操作系统层面,实现了桌面端 UIA 技术框架升级。
结合自研的 AppTester 桌面端应用测试框架,支撑了语雀桌面端的 UI 自动化测试。




桌面端


5.4. 移动端 UIA

移动端的 UIA,我们采用了 内部云测平台 (提供真机测试服务) 的方案,搭配我们自研的 macaca app inspector(元素拾取工具)、 Macaca Reporter 测试报告 和 Reliable 报告持久化服务,实现了完整的移动端自动化测试方案。



样例报告:
mobile.gif

5.5. UIA 白屏巡检

UI 自动化的另一个应用场景就是巡检。监测线上出现导致不可用的稳定性故障,及早发现,及时告警、止损
当然我们运维同学也是配了很多监控报警的,线上的白屏巡检是一种补充保障手段。
实现原理:
通过对线上静态页面和预期页面进行像素级对比,发现线上页面有较大出入时,及时告警。
目前每 10 分钟会不间断执行一次,实现 10 分钟内的白屏发现和告警。

  • web 端巡检

  • 移动端的巡检 > 移动端也有完备的巡检: > 我们通过云测平台设置定时计划实现,目前日常巡检是 iOS 和 Android 端每间隔 4 小时轮换执行一次,每次执行时随机选取一台空闲设备来执行全量的测试用例


5.6. 录制器

随着 UIA 用例数量的增加,用例维护成本成为不可忽略的负担。我们尝试通过 UI 录制器减轻维护工作。
团队自研的 macaca-recorder 工具基于插件化设计,通过录制的方式生成测试脚本。一个关键特点是支持模板开发,可以定制化录制所需的 UIA 脚本,这样无论封装或者使用什么样的测试框架,都可以灵活支持。




54edf00d30ec81a8dd65b125c1cd8998.gif

  • 支持 语雀 Web 端 UI 脚本录制


6. 总结

6.1. 质量 3.0

通过这样的一个个方案的切实落地,实践之前提到的"教练模式"。实现了业务质量和质量工程齐头并进,让语雀的质量迈入了一个新的台阶, 这里可以用一个工业革命的比喻让大家更好地理解。
从刀耕火种的农耕社会 -> 初步探索工业化 -> 全面工业化(质量 3.0)


6.2. 结语

至此语雀的质量体系和自动化能力介绍完了。这是两位 QA 同学会能和确知的语雀数字花园,欢迎一起交流,互相学习。

确知:https://www.yuque.com/jodeee
会能:https://www.yuque.com/huineng

还没有使用过语雀的朋友,也欢迎尝试使用我们的产品。

转发自原文链接:https://www.yuque.com/antfe/featured/ogh09airm80p1igb

最佳回复

会能本能,欢迎一起交流学习 😉

共收到 14 条回复 时间 点赞
1楼 已删除

会能本能,欢迎一起交流学习 😉

1:20 的比例之下可以做到这么完善的质量体系和自动化程度,必须要点赞!

不过感觉这其中也有一部分原因是得益于你们有强有力的各种内部工具 Macaca, 云测试平台等等。普通公司往往在自己寻求这种基础工具或者开发维护上面疲于奔命。

另外说一下 Macaca,15-17 年左右的时候就有看到 Macaca 的开源,当时觉得非常好,也兴致勃勃地把它的自动化部分集成到了我们的测试平台里面;后来发现对应的社区活跃度对比 selenium 和 appium 实在是太低了,而且好多地方需要自己根据 selenium 的实现自己去做对应的开发,后来还是分别替换成了 selenium 和 appium。通过楼主的介绍,可以看到 Macaca 其实一直在维护和扩展,比如 playwright 的支持等。希望对应的开源社区也能尽快丰富,活跃起来吧,给大家多一个选择和思路。

请教下,UIweb 自动化平台,QA 录入的 case 如何调试呢?是在 QA 本地客户端执行的?还是在平台服务器执行的?

恒温 将本帖设为了精华贴 01月15日 13:37

好有内容的文章~~可以做为团队质量体系建设的参考。已收藏,后面会多翻阅。

好帖,多来一些这种分享测试理论方法在业务场景中的实践和成果的文章。
想起前段时间几个测试技术无用的帖子就呵呵。。。过年了心情好,不然高低整两句

Jerry li 回复

相比 Selenium/Appium 这样的商业公司和组织,Macaca 在社区活跃度上确实还不够,还有很大差距。
虽然在国内环境下做开源要难很多,但是持续维护、突破质量技术是会一直努力做的。

ZYH 回复

目前我们的 case 还是工程化的,基于 mocha,通过 CI 调度机器执行(移动端和 web 端),桌面端是通过本地搭建的一套 macmini 机器执行的

ZYH 回复

本地搭建环境,调试 case,调试通过后,放到 UIwdb

看了你们的发版日志,每次都有修复大量的 bug,请问线上产生如此大量的 bug,整个项目组对测试人员的测试质量是否有怀疑?还有如此多的 bug 你们测试有反思过么?

精彩的分享,看完后觉得我也处于农耕社会

感谢分享,很有参考价值。

橙子 回复

确实,目前的质量状况还是不乐观的。不过相较以前已经有一些明显的提升了,至少在研发侧的体感还是比较明显的。
我们目前重点就是高品质的产品体验,还需要一段时间的执行落地,有进展会进一步分享。

请问下,贵公司的 UI 部分的断言,都采取了哪些方式?

ZYH 回复

目前大部分场景都是通过检查元素文案或者属性的方式来断言的,少部分场景会使用 OCR、图像匹配来辅助断言

需要 登录 后方可回复, 如果你还没有账号请点击这里 注册