初探前端质量保障体系

2022-07-16

字数统计: 8.1k | 阅读时长≈ 27 分钟

前言

本文是我在字节内部一次面向质量大部门的分享，来源于深圳 2022 QECon，用大部门的门票，故听完大会需要对组织有回馈。

当时我对阿里健康前端质量保障的课题非常好奇，觉得阿里多多少少应该有些前端质量保障的黑科技，带着这样的疑问去听，听完之后却是不一样的认识。其实前端质量保障也没有什么黑科技，在质量保障的思路和理念上，和其他端是一脉相承的，差异点不过是某些质量保障技术概念在前端落地的技术形式而已。

在这样的理解下，分享单点的前端质量保障黑科技就显得只见树木不见森林，在做了更多外部资料整理后便有了这次分享，受众是一线 QA。

全文图片非常多，以 Github 为图床，没梯子可能会加载不出来，建议在 PC 上阅读。

一、What - 什么是前端

Front End Development: The part of a website that the user interacts with directly is termed the front end. It is also referred to as the ‘client side’ of the application. **It includes everything that users experience directly: text colors and styles, images, graphs and tables, buttons, colors, and navigation menu.**Responsiveness and performance are two main objectives of the Front End.

—— 摘自：Frontend vs Backend

在2010年及更早，大家习惯于将前端定义为浏览器 Web 端，也就是针对浏览器开发出来并运行在浏览器上的代码。

后来随着移动端的爆发以及前端技术栈得不断进化，狭义的 Web 端已经不再是前端唯一的定义，并逐渐泛化为“大前端”，如 PC、Android、iOS、Watch、VR 等的可视化均有所涵盖，技术栈角度上最接近用户的可视化层均可以从某种意义上定义为大前端。

大前端的重点就是跨平台技术，特点是一次开发同时适用于所有平台，目的最大化降低多端可视化适配的成本，解放人力物力。

抽象的前端发展史：从静态走向动态 -> 从后端走向前端 -> 从前端走向全端。

注：本文提及所有 PDF 均可从网上获取，这里帮大家一并整理到 github.io 的文件夹下，在这里下载。

二、Why - 为什么要重视前端质量

为什么要追求质量？
细化到前端领域，为什么其质量依然重要？

2.1 质量决定产品命运

质量固然是很重要的

质量好，会给产品带来增长
质量差，会导致用户流失，最终产品发展受限

摘自：美团-大前端质量保障体系概览-张杰.pdf

2.2 前端在产品的应用

前端应用在产品业务中的方方面面，其对业务的贡献不言而喻

本来下面会贴十多张字节跳动 app 上的前端业务图示，但为避免涉敏，删减剩一个例子。

2.3 前端线上故障及影响

下面通过几个单点事故来感受前端线上故障（事故）对业务的影响面，可大可小，需要重视。

2.4 前端会变得越来越重要

当下的前端确实重要，那未来的前端呢？

内部看，不太严谨地统计 Fatal 事故数，前端对业务的影响的确在最近几年有所增长，侧面印证前端在业务中的影响越来越大。

年份	2016年	2017年	2018年	2019年	2020年	2021年	2022年7月
含”前端”关键字的事故数	3	15	47	94	136	124	49

外部看，从实际工作生活观察，很多技术变革都伴随着用户交互体验的变革（如跨平台、元宇宙、低代码），不可否认大前端越来越火热。

百度指数【前端】，直接结论是前端在当下比过去受到更多关注，由于大前端分化出很多子方向，各有各的叫法，在这个指数上较难印证整体趋势。

综上，随着时间发展，前端在业务中的地位会越发凸显，其质量对产品的影响就越来越大，前端质量保障要求也会越来越高，需要大家更多的关注和重视。

三、How - 前端质量保障体系化建设

3.0 前端质量保障策略推演

有通用框架（方法论），再套到前端里头，前端里通用的&差异的

通用质量保障框架 -> 通用质量策略

关键问题：什么是质量？如何做保障？

质量：产品的品质与口碑，要求做到全流程风险防控（防控 = 发生前的防范 + 发生中/后的控制 + 发生后的复盘改进）
保障：提质与提效，在给定的约束下寻找最优解
1. 业务不同发展阶段，对质量的关注度不一样，质量痛点和关键风险也不一样，要有的放矢
  
  反例：一顿操作猛如虎，一看战绩零杠五
2. 人力是资源约束条件，做到有效的资源利用
  
  反例：一个人身兼N职，不停被打断难以聚焦，结果啥工作都做不好

更具体的，里面有什么要素？

通用质量保障框架

前端质量保障体系推演

引子

SRE has found that roughly 70% of outages are due to changes in a live system.（outage 代表“电力或服务停止供应期”，这里引申为故障）

—— 摘自：https://sre.google/sre-book/introduction/

70%的故障可能都是由变更引起的，这也说明其实你不做变更，基本上是不太会发生故障的。毕竟像以前发生的支付宝电缆被挖断，腾讯天津机房爆炸这类事情是极少的（外部灾害），大多数情况还是因为变更造成了故障。然而快速变更适配用户诉求是互联网的重要特性，所以我们会发现，要让系统稳定、持续地运行，提升系统对外质量，只要能把控变更这个口子，就能降低非常多故障。

思路启发

没有变更，就基本不会有故障 →→ 面向变更 ≈ 面向风险、面向故障；核心是做好变更管控，关注每个变更及其上下游
从「变更」的生命周期做质量保障体系建设 →→ 三个环节：变更前、变更中、变更后

关键问题：如何基于通用质量保障框架，推演适配到前端的质量保障建设？（方法论的实践）

套用通用质量保障框架，做建设推演

通用归通用，那质量策略中，前端相较于服务端、移动端，差异点可能在哪里？

一份粗糙的各端对比

按照上面的推演，简单总结一下全流程的质量策略。

全流程质量保障策略观感

3.1 变更前 - 交付不 delay，严重问题不逃逸

变更前的质量保障主要从两个维度切入，分别是流程和质检。通过两者的结合，可以有效避免低级风险的引入或外漏（如发布前未经测试、发布时无小流量观察），达到风险收口的效果。

流程规范

没有约束的自由是危险的

典型问题

基本功能都没实现好，主流程跑不起来，阻塞测试导致提测打回，一天过去了
这是一个小问题，判断语句漏了个条件，本地改完直接上线
线上灰度/小流量发布 10% 观察了一天都没问题，直接放满 100%
这个需求很常见，虽然公司提供了可靠的标准公共库，但还是想造个轮子过一把技术瘾
需求提测后，一些不太了解的专项问题不知如何评估和测试

常见解法

特别的，变更前（发布前）涉及的几个关键风险： 1. 高危低频操作要小心 —— 多演练 2. 高危高频操作要标准化 —— 平台标准化 3. 高危人肉操作要严控 —— SOP、指导手册

截图摘自：阿里-安全生产实践介绍-王建.pdf

实践建议

标准流程的实施，最好依托于构建发布流水线平台来实施，才能摆脱对“人的意识”的依赖
标准流程实施过程时，针对不同环节做不同的约束与卡点，重点关注流程管控率
流程规范不仅仅局限在变更前，变更中、变更后同样有配套的流程规范，如变更中的止损 SOP，变更后的线上反馈处理等。只要哪里有人肉操作衍生的风险，都可以基于成本考虑追加流程规范

自动化测试

自动化测试只是整个质量保障体系中的一部分，通过单一自动化环节难以做到 100% 的问题兜底，一定要明确自动化测试的价值主要是提前拦截致命风险，而不是拦截所有风险

典型问题

前端变更很频繁，很多需求是 RD 自测的，质量比较虚，但是 QA 确实顾不过来
跟进的前端需求每改一点地方，都要手工跑一次用例，效率低容易遗漏
除了前端常规功能之外，不了解还有什么地方需要专项测试
多种浏览器，需要 Mac、Windows 电脑换着测，好麻烦而且浪费机器
有些改动发到线上可能发生一些用户不感知的小问题，我们能否发现

常见解法

流量回放

价值
- 作为有限数量的手工用例弥补 —— 前端变更频繁，需要大量自动化兜底
- 降低 UI 自动化的编写与维护的成本 —— 由于接口数据导致用例稳定性差
- 线下复现线上问题，从而协助定位归因，或验证修复有效性
方案
- 用户操作录制：基于埋点上报或事件监听，将用户在前端上的具体操作步骤录制下来
- 接口数据录制：基于后端流量采集和数据清洗，实现数据 Mock
- 内容管理：平台化管理、封装录制用例
补充：一般与图像断言技术结合，以实现录制、回放、断言的全自动化闭环

摘自：阿里-前端安全生产在ICBU的探索与落地-陈波.pdf

摘自：贝壳-监控进阶前端操作完美回放-陈辰.pdf

摘自：字节跳动-前端流量回放在企业应用的落地-高亚.pdf【建议看，比较清晰】

精准测试（一个很广泛的概念）

价值
- 改哪里测哪里，降低测试环节消耗时长，提高测试效率
方案
- 变更提取：基于 git diff，提取具体到代码行的前端变更代码
- 影响评估：基于代码关联关系（关联链条：代码行->方法->类->文件），识别变更影响范围
- 测试执行：将影响范围涉及的自动化用例提取出来运行，或基于页面对应 scheme 做定向测试，或推荐手工用例
补充
- 精准测试往往基于代码覆盖率实现，常见如测试覆盖率卡口、用例智能推荐等，参考酷家乐-服务端精准测试实践
- 变更感知可以进一步泛化，比如三方库依赖变更、so 库依赖变更、node 服务依赖变更
- 精准测试不仅仅应用在用例选择与运行上，还可以应用在兼容性测试机型选择等场景

摘自：阿里健康-前端质量保障体系化演进之路-张航.pdf

摘自：百度-基于精准测试及图像技术的前端质量保证实践-刘道伟.pdf

遍历测试

价值
- 替代人工尽可能遍历更多页面，实现更大范围的测试覆盖（辅以其他断言能力）
方案
- 遍历能力：基于可交互组件、基于 DOM 树
- 遍历策略：基于算法，组件/控件/页面权重、黑白名单、异常注入策略

图像断言

价值（对比传统的 DOM 断言能力，如 Selenium）：
- 解决传统基于 DOM 的断言方案召回能力弱 —— 传统断言只有元素存在性和文本正确性校验，无法检测 UI 样式问题
- 传统自动化用例在断言上的编写维护成本高 ——依赖大量元素的校验步骤
- 断言能力更通用 —— 部分场景无法获取 DOM 导致无法断言，如早期 Lynx
方案
- 内容识别：基于算法的元素边缘识别 + OCR 识别，提取有效的内容信息
- 自定义断言区域：自定义页面的检测区域，提升检测准确率，排除检测噪音
- 差异检测：文字、图片、位置的差异检测

摘自：百度-通用视觉UI Diff校验技术及实践-尹飞.pdf【建议看，细节多】

摘自：百度-基于精准测试及图像技术的前端质量保证实践-刘道伟.pdf【建议看，细节多】

关于前端自动化的其他参考资料：

摘自：阿里健康-前端质量保障体系化演进之路-张航.pdf

下面是一些其他资料汇总。

资料类型	资料链接
测试覆盖率	酷家乐-基于 Istanbul 的 JS 覆盖率平台 vivo-前端代码覆盖率平台-宋加超.pdf	Github-istanbul
前端性能	酷家乐-3D 设计工具的前端性能测试	酷家乐-3D云设计工具的前端性能自动化决
前端录制工具	Github-uirecorder
兼容性	F2etest-多浏览器兼容性测试解决方案
其他	酷家乐-大型3D图形渲染质量保障实践-吴鑫璐.pdf 探探-客户端精准测试实践-陈希.pdf 阿里-基于高频动态化场景的移动测试解决方案-龚高.pdf	爱奇艺-基于云IDE的智能化移动端录制回放方案-余华欢.pdf 美团-埋点质量保障体系建设实践-程潇.pdf 百度-度小满金融前端智能测试服务平台落地实践-肖汉.pdf

实践建议

自动化测试只是手段，要关注背后的实际问题和测试目标（功能、性能、稳定性、兼容、安全……）
自动化测试是能力和策略的结合，应用场景 = 测试目标+测试能力+测试策略。质量与效率兼顾，“因地制宜”做出选择，不是所有场景都上一遍自动化兜底，反而降低发布效率，浪费测试资源
按照业务不同发展阶段去考虑不同的自动化能力应用，大体分类是提质与提效，或两者结合。自动化建设早期更关注落地成本，在不清楚能力对业务问题的实际效果时，不适宜将自动化铺开

一般是先上一些稳定且低使用成本的能力，不追求一步到位的质变，而是看重量变，问题逐个攻破，风险逐点收敛，优先把控线上（右移，从质量问题外掏的最后窗口开始管控）

质量门禁

质量门禁或质量卡点，是 RD 和 QA 同时参与进来一起 review 本次变更发布的重要活动。质量问题尽量线下解决，一旦到了线上解决成本会急剧增加，所以质量门禁在把控变更风险上是不可或缺的

典型问题

没手段和渠道推动日理万机的 RD 投入时间处理问题
这个问题很关键，但是 RD 在看问题时刚好漏了它
这个问题提出来了，但不知道要谁来消费解决，无人认领
版本灰度数据比以往差，质量不好，但没被留意就继续增发灰度了
缺陷在发布前都消费完了，但是有些没提成权限的问题没有被关注到

常见解法

各环节的准入与准出

价值
- 准入：保证流程规范得以落实，提高多方协作效率
- 准出：已知问题尽量线下消费，防止问题外漏导致解决成本剧增，损失扩大
方案
- 数据规则：基于多个平台的数据（需求、代码、测试等维度），根据人工设定的规则和判断阈值，在流水线上实现卡口
- 智能化：此时质量门禁从单一的准入准出实施环节，进化为广义的变更发布风险评估环节
  - 数据：将数据集进一步扩大到更精细的维度（如一个人一天的高危操作次数、服务上下游依赖耦合度、repo 复杂度）
  - 评估：结合算法挖掘特征，做更多维度的风险识别与曝光

问题自动流转

有生产链路就有相应的消费链路，广义消费链路包含监控、运维等针对问题所做的一系列活动，狭义指线下问题的流转消费流程。

这里的“问题自动流转”，本身不依托质量门禁，它是一个持续运转的机制，是提升研发效能的方式。问题可以是广义的质量问题，也可以是狭义的缺陷，范畴可灵活定义。

价值
- 避免问题处理人需要人的评估，不熟悉、经验不足的话容易误判，造成精力浪费
- 问题流转定责（确定处理负责人）的同时，通过提醒机制提高问题消费率和解决率
方案
- 问题过滤：按照人工梳理关键字或其他特征，对无效或无法解决的问题 —— 如系统底层导致的极难定位解决的问题，可以过滤）
- 问题分配：使用 git blame 命令获取问题代码最近修改人并分配，再基于人工定义的规则，结合问题所在的具体文件/文件夹/堆栈特征等，分配给固定 owner
- 问题定级：按照问题的类型，或问题出现的频率等特征，赋予不同的优先级 —— 如启动崩溃，非核心路径必现白屏，则可定义为 P0 问题

摘自：阿里健康-前端质量保障体系化演进之路-张航.pdf

实践建议

质量门禁是贯彻问题消费的重要环节，应该优先建设，否则线下问题暴露得再多，不消费也白搭
质量门禁可针对不同类型问题（功能、性能、稳定性、兼容性等），按需实施不同严格程度的卡口
最简单的实践方式，是梳理一个卡口 checklist 的 Excel 文档，在封板与发版的时间节点上人工检查

3.2 变更中 - 用少量代价暴露未发现的问题

相比于「变更前」，「变更中」意味着变更已经被发布到线上，线上用户开始接触变更。站在风险外漏角度，问题已经开始发生了，质量保障工作可以围绕着「如何更快发现问题」和「如何更快消除问题影响」来开展。

监控报警

监控报警不仅仅是 RD 的工作，也是 QA 的工作。

典型问题

线上问题都上热搜了，我们才知道原来有这么个问题
线上出问题，但是不知道问题是什么，信息太少
线上用户反馈过来，没有标准处理流程，全屏个人经验对接
监控群里天天发报警消息，好像不处理也没事，久而久之没人管
报警过来了，但是报警携带的信息太少，不知道是什么问题，还要搞一顿很重复的排查定位

常见解法

线上巡检

质量问题不一定都能被用户直接感知到，有些问题悄悄发生，当影响累积一定时长后，开始劣化并被大家感知到

价值
- 线上巡检不是为了发现更多问题，而是保证业务的正常运作，是一种主动监控方式
方案
- 巡检场景：线上高热用户场景（用户价值）、业务核心场景（业务价值）
- 巡检对象：API、日志、前端页面、业务功能、埋点数据
- 巡检方式：基于 UI 自动化，或基于录制回放
其他参考
- 百度智能小程序巡检调度方案演进之路

摘自：群核科技-多维度巡检在线上稳定性保障的实践-邹海滨.pdf【建议看，细节多】

摘自：阿里健康-前端质量保障体系化演进之路-张航.pdf

酷家乐-网页巡检工具实践

摘自：酷家乐-网页巡检工具实践

监控与报警

价值（QA 视角，考虑如何设计与实施监控报警）
- 线上问题及时感知，暴露风险
- 线上问题定位验证
方案（Grafana 等平台）
- 监控对象：基础设施监控、业务属性监控，度量指标主要是监控覆盖率、监控准确率、监控召回率，最终关注监控发现时长 MTTI（Mean Time To Identify）
- 监控维护：追加增量监控、清理冗余监控的机制和规范
  - 报警发生前：监控覆盖率 -> 监控召回率、监控准确率
  - 报警发生后：报警响应率、报警响应时长、报警处理时长
- 报警响应：报警信息完备性，响应流程自动化，自动降级或熔断，最终关注 MTTR（Mean Time To Resolve）
  - 自动熔断上，前端需要和用户端（如移动端）的监控互相打通，在发布上做好数据关联与回溯才能实现准确的熔断

以下资料是 RD 视角的前端监控建设，供大家开阔思路

把前端监控做到极致-扬森.pdf，把前端监控做到机制 [含分享现场视频]
阿里-大前端时代前端监控的最佳实践-彭伟春.pdf
微医-前端异常监控的黑科技-宋睿.pdf
美团-前端监控的发展_从运维走向运营-林雨.pdf

反馈处理

监控可能存在数据稀释的问题，个例问题较难识别，用户反馈作为补充渠道。

用户反馈在监控分层体系中，是最贴近用户的质量监控方式，是发现线上问题的必要来源渠道，反映业务功能、性能、稳定性、兼容性等多个线上质量核心指标。

价值
- 线上用户反馈
  - 安抚用户情绪，挽留用户
  - 单点反馈难以通过全盘监控发现（如监控会产生大量噪音），通过线上用户反馈来补充
  - 从最贴近用户的角度来发现和解决质量问题，提升产品线上质量和体验
- 舆情监控
  - 线上用户不一定有直接反馈的意愿，可能在其他地方吐槽产品问题，舆情监控是一种补充
  - 在处理效率和人力成本上，比线上用户反馈处理更优
方案
- 反馈收集：确定反馈收集渠道，利用爬虫爬取包含预设关键词的文案
- 反馈过滤与聚类：基于 NLP 分析语义进行无效反馈的过滤，并聚类出 Top 反馈问题
- 反馈推送与触达：基于聚类和关键词的消息订阅&监控报警
- 反馈分析与定位：打通相关平台，关联当时脱敏后的日志、数据等信息
- 反馈跟进与处理：标准的反馈处理与跟进流程，反馈转 Bug 或需求

摘自：如何打造智能化的舆情监控平台-网易云音乐-蒋超.pptx【建议看，细节多】

实践建议

监控建设，实际开展的时候容易演变为“先污染后治理”。早期的野蛮生长，使得后面不得回过头来重新打理。建议在监控建设开始时就考虑监控追加和清理的机制与规范
监控报警是相互以依赖的，监控是状态的反馈，报警是通知，更是要采取具体行动的信
处理用户线上反馈不但只是运营同学的工作，QA 往往需要参与其中协助复现/定位/解决问题，应该尽快明确标准流程，提高反馈流转效率，以免不可控的人力消耗。另外，线上用户反馈处理比较适合使用技术手段来提升整体处理效率
监控报警的实施也需要“监控报警”

3.3 变更后 - 复盘回顾，沉淀机制能力，改进过程

变更完成并不意味着尘埃落定，回顾整个变更过程中发生的“意外”，能让我们有进一步的成长，从质量保障体系来说，没有后续的运营，那就是脱节和自嗨。

故障演练

无论是正向体系化建设还是反向查漏补缺，线下的一系列质量建设需要经过验证来证明效果，这样在面对未知/过往大小故障的时候，损失会越来越小

典型问题

我们分析了很多问题，搞了好多建设，下一次同样的问题还是发生了
我们分析了很多问题，搞了好多建设，下一次问题来了还是没处理好

常见解法

故障演练

故障演练不局限于服务端，移动端、前端都是可以落地这个理念。

价值
- 面对常见故障和过往故障，保障产品不出现严重质量问题
- 面对未知故障，更有底气保障产品不出现严重质量问题
方案
- 单点故障注入能力：CR 注入、日志注入、数据注入、资源劫持注入
- 演练流程标准化：标准的演练流程，多样的演练剧本池，低成本发起演练
- 常态化演练：红蓝攻防机制，多平台联动覆盖故障全生命周期

摘自：阿里-前端安全生产的探索与实践-朱亚东.pdf

摘自：酷家乐-故障演练平台在酷家乐的演进历程-乐冉.pdf

摘自：阿里-前端故障演练的探索与实践-辰啸.pdf，演讲视频B站能搜到

实践建议

故障演练有明确目的，它既是暴露建设短板的手段，也是质量建设的验证手段（变更管控、服务设计、服务依赖、监控报警、运维操作）
不要忽略人员在面对故障时的心智意识

度量运营

无跟踪无效率，无反馈无成长，无量化无质量

典型问题

过程数据不清楚，无法评估“测试设计与执行”本身的质量，被别人质疑
做了一堆事情，但是不知道对线上质量有无实际贡献
不知道有什么套路可以让大家对质量关注起来

常见解法

质量度量

价值
- 使现状有客观的评判，告诉我们现状如何，或者具体问题所在
- 对目标有统一的共识，或者具备统一的评判标准
- 使改进更聚焦和精准，改进动作可以做到有的放矢
建议
- 度量的口径需要得到多方认可，否则无法针对性改善
- 单一或局部指标无法表现全貌，一个事物一般需要多个指标（若只看千行代码 Bug 率，则可以通过刻意稀释代码去让指标变好，然而没有任何意义）
- 做好指标分层分级，结果指标（滞后性指标）作为质量最终结果或业务价值，但周期长粒度粗，而过程指标（引领性指标）具备预见性和可控性，过程指标对结果指标有实际贡献，通过控制过程实现控制结果
- 度量不追求又大又全，讲究上下层指标的逻辑是否完整，讲究数据能否和实际做的事情关联在一起，具备因果关系

质量运营

质量运营在实操过程中经常退化为摆数据说数据，而事实上最重要的是要基于数据进行分析，帮助相关方做改进，同时跟进反馈改进的效果。看数据大家都会，实际做改进才是主要。

价值
- 质量领域中发现问题、拆解问题、解决问题的过程，强调其人为干预动作需要形成 PDCA 循环（Plan、Do、Check、Act），通过数据驱动提升质量、效率、价值等多方面的度量指标，最终实现质量提升
建议
- P-制定改进计划
  - 质量痛点驱动：痛点来源于日常研发过程，通过问题分析制定落地改进方案，利用度量做效果评估
  - 质量目标驱动：有一个既定的目标值，从上往下进行目标拆解，转化为各项度量指标目标值，针对这些下层指标做可落地的改进方案设计与实施
- D-实施落地计划
  - 日常运营：通过明确可执行的机制，日常滚动运营
  - 短期突击：成立小的专项组，针对问题做短期内的专项改进，适合解决短平快的问题（如某个模块的 UI 自动化用例补充）
  - 长期攻坚：成立大的专项组，针对问题做中长期体系化的专项改进（如体系化的监控报警治理）
- C-复盘和反馈：形式上如各种书面总结报告、复盘总结会议，起到了承前启后的作用 —— 回顾计划与实施过程，评估落地效果，明确后续改进
- A-改进和推广：基于前面的步骤，判断是否有效果，如果有效，则继续进一步做更深入的事项，如果无效则考虑做调整
- 一些手法
  - 培训宣贯
  - 红黑榜
  - 评分排名
  - ……