Macaca 语雀质量体系与自动化

骁睿 · 2023年01月13日 · 最后由 大桥 回复于 2023年10月28日 · 62197 次阅读
本帖已被设为精华帖!

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

最佳回复
共收到 34 条回复 时间 点赞
1楼 已删除

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

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

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

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

Jerry li 回复

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

ZYH 回复

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

ZYH 回复

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

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

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

橙子 回复

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

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

ZYH 回复

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

感谢分享

npm i macaca-chrome --save-dev
执行这个命令的时候报错,node 版本是 v16.17.0.,npm 的版本是,操作系统是 win10,笔记本

谢谢回复。我记得大佬就是 macaca 主要的开发贡献者!
我觉得其实看贵团队怎么定位吧,如果只是贵司内部的工具,只需要内部能推广使用,稳定升级维护就可以了,反正是能干活,能产出;如果是要有心在开源这块建立起自己的影响力,就真的要考虑投入多少的人力和热情去推广和适当地支持、解答问题。我前两年自己做了个很简单的框架,在社区分享了。虽然我自己现在看都觉得做得太烂,但是只要有朋友感兴趣愿意试用,遇到的问题我都尽力会去解答。但这个分享,比如 18 楼的朋友专门在这个帖子上面求救问题,这么多天了也没有人回复解答,我个人觉得和我当年遇到的情况是一样的。 所以,膜拜大佬们做的成绩,学习整体的思路和方法, 但也仅限于此,无缘深入去使用这么好的工具了。

学习了,增加了眼界,希望以后能借鉴一部分实践并落地😋

Jerry li 回复

🤝 开源是相互的,评论里不适合提问题和解决问题,不方便通知和沉淀。github issue 是提问题的好地方。

好文学习了

感谢分享
我在看的时候有几个疑问点,看博主能否给解答下哈
1、测试开发比 1:20,具体的统计方式是什么样的?语雀平台在这个过程中大幅减少了哪一部分的时间?
2、在达成测试开发比 1:20 的时候,其他的质量指标情况是什么样的呢?比如项目线上 BUG 率

语雀的性能体验在我用过的笔记里面感觉是挺糟糕的

  1. 统计的是研发团队的总人数,包括各功能模块开发(包括 TL)、2-3 个运维。本质上是减少了大量信息获取、各角色的协作沟通的时间,解放 QA 生产力 同时研发能便捷获取测试反馈无需找 QA 沟通问题细节。
  2. 暂时没有更多数据可以提供,对线上的缺陷是有抑制作用的,但目前仍未达到理想水平。业务质量影响因素是多维的,仅仅靠研发质量体系是不够的,比如产品设计是否合理、性能体验等等,外部质量是我们当前努力的新方向。

确实不够好,我们目前重点就是高品质的产品体验,还需要一段时间的执行落地,有进展会进一步分享~

脚本录制的,App 端也能录制么?还是说只有 Web 端?

我感觉你们这个 QA 基本上是测试技术的保障团队,各种测试任务其实都分解给开发侧了,比如单测、特性合入测试等等。我好像没有看到各种 3 个端的测试场景测试是由谁来保障的?难道是拿外面的测试用户做灰度测试?

轩天 回复

单测这块确实是开发同学自己 cover 的,QA 同学除了维护测试工具还会 cover 3 端的 UI 自动化测试。

多端联合的场景确实是比较少的(由于多端互相影响导致的问题也比较少),比如文档 web 端编辑和移动端同时编辑 和 在 web 端开两个 tab 同时编辑,其实对于服务端的验证其实是一致的
另外 3 端测试涉及多个测试服务的逻辑编排和执行复杂度会很高
从这两方面考虑不会投入过多(如有必要会通过手工验证一下去保障)

至于灰度,我觉得是兜底的保障手段,我们是有内部灰度,外部的灰度肯定也有,常规流程,不至于依赖灰度去佛系发现问题。

31楼 已删除


像你说的教练模式,这种是怎么一步步实现的呢,怎么提高团队的质量意识

雀氏,看不懂怎么用,所以社区基本没活跃度

老哥是哪壶不开提哪壶😀

这是运维的锅吧

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