大家好，我是语雀 QA 会能。
很高兴，有机会跟大家聊一下语雀的质量体系和自动化技术。
下面会分几个部分给大家介绍，让大家可以了解到语雀质量体系的全貌。
首先，简单分析一下语雀，相信很多朋友对语雀都是不陌生的。
「语雀」是蚂蚁集团旗下的文档与知识库工具，源自蚂蚁集团和阿里巴巴内部文档协同需求，2018年1月8日正式对外提供服务，现已服务于数十万企业组织和数百万个人用户。再从研发角度看，语雀是一个大型 全栈 多端 应用，包括了 web 端、移动端、桌面端。
语雀的研发基于 One CodeBase ** 模式（类似 google 的项目研发，所有相关工程都在一个大的 git 仓库）。
另外还依赖研发管控、任务跟踪、代码服务、构建流水线等平台。
语雀的迭代发布比较快，在工程上，技术团队对持续交付的稳定性和效率有着很高的要求 **。然而我们的 QA 就只有我和另外一个同学确知，测试开发比接近（1:20)，在这样的情况下如何做好质量保障工作就成了一个大问题, 下面来说说我们的解法。
我们的解法是 “教练模式”。
什么是教练模式? 简单的说 QA 同学就相当于教练，通过各种质量保障机制规范和提升开发同学的质量意识，提供完备的质量服务提升研发效能，从而提升语雀产品的质量。
另外，我们希望通过工程化的方式使质量成果可沉淀，可长期持续，这也是语雀质量技术从起步到发展的的初衷。
再来看看我们的质量工程的顶层架构，框图中最底层是我们依赖的基础平台 (例如研发管控、任务跟踪、代码服务、构建流水线平台等) 。
再是质量基建，服务于语雀质量的各种能力，包括语雀质量的技术基础 和 “看不见质量”，偏软性但又极其重要的，质量意识和工程文化。
技术基础像 skytest 支撑工具、Lark-Reliable 测试报告和覆盖率持久化查看、Macaca 套件提供了 UIA 技术支持，在后面的会有详细的介绍。
质量能力，就是语雀实际解决的问题和质量成果了，相关领域包括持续集成、缺陷收敛、线上巡检、UI 自动化建设，长效机制建设和研发提效，后面也会详细介绍。
每个质量团队或多或少都会有质量支撑工具或服务，以解决团队内的质量问题，接下来介绍 SkeyTest 和 Reliable。
大多质量团队都会有一些核心的测试支撑工具，我见过比较多的是 web 服务的形式提供的，比如 xx 测试服务，xx 测试平台，这就要求团队内需要有全栈开发的同学，并且对这样服务的开发维护投入还是比较大的。
SkyTest 就是语雀的主要质量支撑工具，它承载了语雀质量技术沉淀，就好比 QA 同学的 “百宝箱”，里面有各式各样趁手的测试工具，为语雀质量能力建设奠定了技术基础。
SkyTest 以 npm 工具模块的形式存在，可以直接通过 cli 的方式使用，或者以 node 模块集成，集成便捷，比较轻量，适合 QA 工具的研发。维护成本相对 web 应用要轻量很多。
LarkReliable 作为质量数据持久化&洞察服务，和 SkyTest 搭配，能够满足大部分测试能力的实现。目前在语雀除了集团内其他平台提供的专项能力外，团队内的质量能力实现都是能够 Hold 住的。
基于开源的 Macaca Reliable 套件实现，如果所在团队正好缺少类似的工具服务，完全可以基于开源的 Relibale 套件，快速实现团队内的测试报告持久化和数据洞察的服务能力。
通过建立机制 形成长效收敛的质量闭环，其实我们最初的想法很简单就是想办法通过自动化 QA 同学的工作流，让质量同学能空出手来做更有长期作用的质量工程建设。过程中逐渐沉淀了一个个机制，通过高度自动化，提升效能。
在质量体系建设初期做好机制闭环，带来的长期收益是非常可观的，推荐优先切入建设。
迭代有序化，有点像项目经理，在语雀日常迭代管理、发布执行都归 QA 同学。
两个 QA 同学轮流按周迭代值班，保障发布质量，做好 UIA 回归卡点、发布执行和 hotfix 复盘。最初我们的发布节奏是 一周两次，频繁的发布使得发布质量不可控，产生较多 hotfix，所以在保证足够敏捷的同时，我们将服务端发布节奏控制在一周一发。可能对很多业务团队来说，一周一发也是很高的频率了，大部分产品的迭代周期一般都是半个月或一个月发布。
但是，如何在高频发布下保障交付质量？关键还是需要持续集成能力和自动化能力，相信通过后续的介绍，会有答案。
相信大家都有看到过，在缺陷池里摆烂的缺陷吧，（大多是一些重要不紧急的缺陷，推不动解决）是不是很揪心，有强迫症的同学们可能会受不了。
其实通知类的功能不难实现，语雀做的其实相当于做好 “快递的最后 1 公里”，将缺陷管理平台中的缺陷统计分析后自动化播报到研发群中（其实是对缺陷管理平台能力的扩展）。
我们建立了日报 / 周报 机制，有效促进收敛，清理缺陷历史债， 最终保持人均一个。慢慢形成了团队内的习惯和心智: “缺陷进池，一定会被解决。” 做到有始有终，从恶性循环变成良性循环。
缺陷的另一个重要来源: 线上异常和缺陷
针对这部分缺陷，我们通过不间断获取、分析线上日志的方式，及时发现线上发生的缺陷，并自动化录入到对应的缺陷管理项目中，我们对日志内容进行规则自动分析并按照主站、移动端、桌面端归一分类指派给对应的负责人修复，整体效率和信息及时性在潜移默化中得到很大提升。
增量覆盖率卡点的意义，相信不用多说。当新代码无单测合入就会导致整体覆盖率越来越低，会加剧代码腐化。
因此，我们在 PR 环节加入了增量代码检测能力，为评审人和开发同学提供直观的覆盖率报告，同时也希望能激励大家能够及时补充单测用例；（也是扩展了代码管理平台的能力）实现分析: 每次单元测试执行后生成的覆盖率信息和 PR 的 diff 信息通过计算获取增量的覆盖率信息，最后通过
macaca-istanbul工具 生成覆盖率报告（支持颜色渲染和缩略图）。
语雀团队很注重测试覆盖率，一直以来保持在比较高的覆盖率水平，项目覆盖率的跟踪这块原来也都有，但是年久失修一些项目的覆盖率数据没有及时更新和维护。
我们通过搜集、合并分散在各 CI 任务中的项目覆盖率数据，然后每周通过钉钉进行覆盖率播报，有效恢复了各项目的覆盖率跟踪，实现了覆盖率的长期统计跟踪机制。实现分析: 收集 CI 中运行的单测任务覆盖率信息 -> 测试结束时合并相应的覆盖率数据上传到 Reliable，并按周进行覆盖率数据的播报。
先说说为什么做这个事，过去，语雀会有遇到因为低版本或不支持的浏览器造成的线上不可用问题，经常也会收到用户类似的反馈，很影响用户体验。web 应用其实都会有类似的问题，从根本上杜绝是我们的目标。
我们针对低版本内核不兼容、白屏的死角问题，进行监控和不支持引导。同时建设了浏览器版本分布情况的准确的感知能力。我们的目标是做到三个一定：
- 一定没有不明确的浏览器版本
- 明确的浏览器版本一定可用
- 主流的浏览器一定支持自动化回归
语雀日常 CI 任务经常因为一些问题不通过，非常影响研发效率。其中有工具的问题、有用例本身设计不稳定（比如缺少 mock、时序调用错乱、断言粒度不合理等）。
为了促进大家日常及时解决不稳定问题，及时通知反馈问题的指派人，我们实现了 CI 问题的自动化跟踪机制。
- 自动化发现问题（日志、缺陷池、覆盖率数据、CI 报错等等）
- 自动化指派跟踪 （项目缺陷管理平台）
- 及时消息通知（钉钉机器人）
通过高度的自动化，使收敛变得自然，研发变得高效。
没有持续集成的时候是怎样的:
开发合并了 PR 之后，需要人工及时部署更新，然后反馈给开发同学，让开发同学去验证，虽然只是些点击和通知操作，但环节之间都是割裂的需要人工执行，打断工作节奏不说，费心费力。并且自动化的功能性集成测试也是缺失的。为了解决这些问题，我们重点建设了稳健的 CICD，从代码合并开始，到后面的部署、自动化测试回归一气呵成，敏捷理念中的持续集成是实际在做的，让持续测试成为了我们的基本规约。
通过日常迭代分支的 PR 合并，触发对应的 CI 流水线任务，完成持续部署和持续测试。
会有详尽的通知，比如直接给到迭代验证地址链接，直接能看到已部署的 PR 信息，看到持续测试的报告链接等等，尽可能为研发同学带来便利，提升研发体验和效率。
4.2. 桌面端 CICD
不仅仅是主站，我们桌面端和移动端的开发同学也能享受到尊贵的 CICD 服务。
桌面端实际上是一款桌面应用客户端软件，桌面端的持续测试和持续部署是通过办公网的一台 macmini 实现测试回归环境，在构建平台触发构建后会异步通知 macmini 进行自动化集成测试和报告的发送。
移动端的持续集成通过构建平台打包后 使用 蚂蚁云测平台（提供移动端真机测试服务）触发执行 UI 自动化测试任务，在执行完毕之后也会发送相关报告到钉钉群中。
CI 慢、不稳定的问题一直以来是语雀团队的痛点问题，极其影响研发效率。
我们从各个细节优化了整体 ci 的效率和稳定性。
- 通过 Docker 技术做镜像级别的缓存，解决 clone 环节慢，git 拉取不稳定的问题。
- 通过 自研 job_keeper 工具实现不稳定任务自动重试。
- 通过 shell 脚本异常捕获和处理，提升脚本稳定性。
- 通过 拆分 CI 任务，降低整体耗时峰值。
从各个细节优化，使 CI 缩短了执行时间，提高了成功率, 减少了人工重试负担。
优化后，正常 15 分钟以内可以完成一轮全量回归。
完善的 CICD 能力，使得在语雀做研发是一件很幸福的事。极大提升了研发同学们的工作体验和效率。
测试金字塔: 相信有同学见过，这种下宽上窄的三角形结构，代表在各层自动化的建议投入分配比例。
语雀的单测是开发同学们自己负责的，QA 同学负责 UI 自动化测试部分的测试。在我加入语雀之前，语雀在 UIA 领域就有比较多的实践，UI 自动化是我们一直坚持的质量保障手段。相信也有很多质量团队尝试过 UI 自动化，但很少能有坚持持续做的，原因有很多，比如下面的一些因素:
- UIA 的实践曲线很陡，技术门槛比较高，在技术选型和工程化实践阶段就放弃了。
- 需要有一定的用例量和成熟的工程实践，才能发挥效果，短期 ROI 很低，团队没有持续投入的动力。
- 用例的维护成本高，UI 一旦发生较大变化，就需要更新用例，如果实践经验不足会导致不可持续。
其实语雀质量作为 “过来人”，也是遇到过同样的困难，语雀的 UIA 成功和团队前期摸索的持续投入有很大的关系。
目前进入了收益期，通过 UIA 目前已发现的关键问题已达到 70+，相当于避免了多次 hotfix，有效避免了大量线上缺陷的发生。
UIA 的一些优势:
- 自动化测试可以代替大量的手工机械重复性操作，可以省下大量时间专注于设计测试用例。
- 研发提效自动化测试可以大幅度提升回归测试的效率，非常适合敏捷开发。
- 支撑稳定性测试和巡检 使得 7*24 小时核心功能稳定性测试、自动巡检成为可能。
Macaca 是一套面向用户端软件的测试解决方案，提供了自动化驱动，环境配套，周边工具，集成方案，旨在解决终端上的测试、自动化、性能等方面的问题。
我们的自动化能力就是基于 Macaca 扩展实现的。Macaca 是设计典型的 C/S 架构，提供了标准化的驱动层，消除了各技术平台测试技术栈的差异。用户侧的 API 设计只需要遵从 W3C webdriver 标准 就可以轻松实现多技术栈接入，驱动各类浏览器/设备的自动化测试执行。
我们的 UIA 覆盖了 Web 端 Chrome/Firefox/Safari/Edge 多种主流浏览器，全量 UIA 回归任务基本能够在 30 分钟内完成
积累用例总数 2k+ 500 余条用例涵盖了已有业务核心链路和功能，自动化率达到了 51%
多端回归我们是通过封装macaca-playwright驱动实现的，playwright 是微软开源的驱动框架，提供了比较全面、强大的 web UI 测试能力。
通过研究和实践系统自动化能力，将系统操作能力封装为
macaca-macos驱动。
使我们的自动化技术从基于浏览器跨度到基于操作系统层面，实现了桌面端 UIA 技术框架升级。
结合自研的AppTester桌面端应用测试框架，支撑了语雀桌面端的 UI 自动化测试。
移动端的 UIA，我们采用了 内部云测平台 (提供真机测试服务) 的方案，搭配我们自研的 macaca app inspector（元素拾取工具）、 Macaca Reporter 测试报告 和 Reliable 报告持久化服务，实现了完整的移动端自动化测试方案。
样例报告:
5.5. UIA 白屏巡检
UI 自动化的另一个应用场景就是巡检。监测线上出现导致不可用的稳定性故障，及早发现，及时告警、止损
当然我们运维同学也是配了很多监控报警的，线上的白屏巡检是一种补充保障手段。
实现原理:
通过对线上静态页面和预期页面进行像素级对比，发现线上页面有较大出入时，及时告警。
目前每 10 分钟会不间断执行一次，实现 10 分钟内的白屏发现和告警。
随着 UIA 用例数量的增加，用例维护成本成为不可忽略的负担。我们尝试通过 UI 录制器减轻维护工作。
团队自研的 macaca-recorder 工具基于插件化设计，通过录制的方式生成测试脚本。一个关键特点是支持模板开发，可以定制化录制所需的 UIA 脚本，这样无论封装或者使用什么样的测试框架，都可以灵活支持。
通过这样的一个个方案的切实落地，实践之前提到的"教练模式"。实现了业务质量和质量工程齐头并进，让语雀的质量迈入了一个新的台阶, 这里可以用一个工业革命的比喻让大家更好地理解。
从刀耕火种的农耕社会 -> 初步探索工业化 -> 全面工业化（质量 3.0）
至此语雀的质量体系和自动化能力介绍完了。这是两位 QA 同学会能和确知的语雀数字花园，欢迎一起交流，互相学习。
确知：https://www.yuque.com/jodeee
会能：https://www.yuque.com/huineng
还没有使用过语雀的朋友，也欢迎尝试使用我们的产品。
转发自原文链接：https://www.yuque.com/antfe/featured/ogh09airm80p1igb
