本文是我在公司内部一次面向质量大部门的分享，来源于深圳 2022 QECon，用大部门的门票，故听完大会需要对组织有回馈。
当时我对阿里健康前端质量保障的课题非常好奇，觉得阿里多多少少应该有些前端质量保障的黑科技，带着这样的疑问去听，听完之后却是不一样的认识。其实前端质量保障也没有什么黑科技，在质量保障的思路和理念上，和其他端是一脉相承的，差异点不过是某些质量保障技术概念在前端落地的技术形式而已。
在这样的理解下，分享单点的前端质量保障黑科技就显得只见树木不见森林，在做了更多外部资料整理后便有了这次分享，受众是一线 QA。
全文图片非常多，以 Github 为图床，没梯子可能会加载不出来，建议在 PC 上阅读。
由于 Testerhome 排版所限，文章又太长在 Testerhome 网页上编辑很慢，故将就着排版，后文图片也不贴了（凡是 {% asset_img xxx %} 格式都是图片），感兴趣的同学可在 我的个人博客上 细览。
注：本文提及所有 PDF 均可从网上获取，这里帮大家一并整理到 github.io 的文件夹下，在 这里 下载。
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
前端应用在产品业务中的方方面面，其对业务的贡献不言而喻
使用 Android 手机 “显示布局边界” 功能即可了解到一个 app 中哪些是原生实现模块，哪些是前端实现的模块。
下面通过几个单点事故来感受前端线上故障（事故）对业务的影响面，可大可小，需要重视。
当下的前端确实重要，那未来的前端呢？
从实际工作生活观察，很多技术变革都伴随着用户交互体验的变革（如跨平台、元宇宙、低代码），不可否认大前端越来越火热。
百度指数【前端】，直接结论是前端在当下比过去受到更多关注，由于大前端分化出很多子方向，各有各的叫法，在这个指数上较难印证整体趋势。
综上，随着时间发展，前端在业务中的地位会越发凸显，其质量对产品的影响就越来越大，前端质量保障要求也会越来越高，需要大家更多的关注和重视。
有通用框架（方法论），再套到前端里头，前端里通用的&差异的
关键问题：什么是质量？如何做保障？
质量：产品的品质与口碑，要求做到全流程风险防控（防控 = 发生前的防范 + 发生中/后的控制 + 发生后的复盘改进）
保障：提质与提效，在给定的约束下寻找最优解
更具体的，里面有什么要素？
 |
 |
|---|
通用质量保障框架，引用了公司前辈的图
引子
SRE has found that roughly 70% of outages are due to changes in a live system.（outage 代表 “电力或服务停止供应期”，这里引申为故障）—— 摘自：https://sre.google/sre-book/introduction/
70% 的故障可能都是由变更引起的，这也说明其实你不做变更，基本上是不太会发生故障的。毕竟像以前发生的支付宝电缆被挖断，腾讯天津机房爆炸这类事情是极少的（外部灾害），大多数情况还是因为变更造成了故障。然而快速变更适配用户诉求是互联网的重要特性，所以我们会发现，要让系统稳定、持续地运行，提升系统对外质量，只要能把控变更这个口子，就能降低非常多故障。
思路启发
没有变更，就基本不会有故障 →→ 面向变更 ≈ 面向风险、面向故障；核心是做好变更管控，关注每个变更及其上下游
从「变更」的生命周期做质量保障体系建设 →→ 三个环节：变更前、变更中、变更后
关键问题：如何基于通用质量保障框架，推演适配到前端的质量保障建设？（方法论的实践）
|
 |
|---|
套用通用质量保障框架，做建设推演
通用归通用，那质量策略中，前端相较于服务端、移动端，差异点可能在哪里？
一份粗糙的各端对比
按照上面的推演，简单总结一下全流程的质量策略。
全流程质量保障策略观感
变更前的质量保障主要从两个维度切入，分别是 流程 和 质检。通过两者的结合，可以有效避免低级风险的引入或外漏（如发布前未经测试、发布时无小流量观察），达到风险收口的效果。
没有约束的自由是危险的
典型问题
基本功能都没实现好，主流程跑不起来，阻塞测试导致提测打回，一天过去了
这是一个小问题，判断语句漏了个条件，本地改完直接上线
线上灰度/小流量发布 10% 观察了一天都没问题，直接放满 100%
这个需求很常见，虽然公司提供了可靠的标准公共库，但还是想造个轮子过一把技术瘾
需求提测后，一些不太了解的专项问题不知如何评估和测试
常见解法
{% asset_img 流程规范脑图.png 500 500 "流程规范脑图" %}
| 特别的，变更前（发布前）涉及的几个关键风险： 1. 高危低频操作要小心 —— 多演练 2. 高危高频操作要标准化 —— 平台标准化 3. 高危人肉操作要严控 —— SOP、指导手册 |
{% asset_img 阿里安全生产.png 600 500 "风险原则" %} |
|---|
截图摘自：阿里 - 安全生产实践介绍 - 王建.pdf
实践建议
标准流程的实施，最好依托于构建发布流水线平台来实施，才能摆脱对 “人的意识” 的依赖
标准流程实施过程时，针对不同环节做不同的约束与卡点，重点关注流程管控率
流程规范不仅仅局限在变更前，变更中、变更后同样有配套的流程规范，如变更中的止损 SOP，变更后的线上反馈处理等。只要哪里有人肉操作衍生的风险，都可以基于成本考虑追加流程规范
自动化测试只是整个质量保障体系中的一部分，通过单一自动化环节难以做到 100% 的问题兜底，一定要明确自动化测试的价值主要是提前拦截致命风险，而不是拦截所有风险
典型问题
前端变更很频繁，很多需求是 RD 自测的，质量比较虚，但是 QA 确实顾不过来
跟进的前端需求每改一点地方，都要手工跑一次用例，效率低容易遗漏
除了前端常规功能之外，不了解还有什么地方需要专项测试
多种浏览器，需要 Mac、Windows 电脑换着测，好麻烦而且浪费机器
有些改动发到线上可能发生一些用户不感知的小问题，我们能否发现
常见解法
{% asset_img 自动化测试脑图.png 500 500 "自动化测试脑图" %}
流量回放
价值
方案
补充：一般与图像断言技术结合，以实现录制、回放、断言的全自动化闭环
| {% asset_img 流量回放_1-1.png 500 500 "流量回放_1-1" %} | {% asset_img 流量回放_1-2.png 500 500 "流量回放_1-2" %} | {% asset_img 流量回放_1-3.png 500 500 "流量回放_1-3" %} |
|---|
摘自：阿里 - 前端安全生产在 ICBU 的探索与落地 - 陈波.pdf
| {% asset_img 流量回放_2-1.png 500 500 "流量回放_2-1" %} | {% asset_img 流量回放_2-2.png 500 500 "流量回放_2-2" %} | {% asset_img 流量回放_2-3.png 500 500 "流量回放_2-3" %} |
|---|
摘自：贝壳 - 监控进阶前端操作完美回放 - 陈辰.pdf
| {% asset_img 流量回放_3-1.png 500 500 "流量回放_3-1" %} | {% asset_img 流量回放_3-2.png 500 500 "流量回放_3-2" %} | {% asset_img 流量回放_3-3.png 500 500 "流量回放_3-3" %} |
|---|
摘自：字节跳动 - 前端流量回放在企业应用的落地 - 高亚.pdf【建议看，比较清晰】
精准测试（一个很广泛的概念）
价值
方案
补充
{% asset_img 精准测试_1-1.png 500 500 "精准测试_1-1" %}
摘自：阿里健康 - 前端质量保障体系化演进之路 - 张航.pdf
| {% asset_img 精准测试_2-1.png 500 500 "精准测试_2-1" %} | {% asset_img 精准测试_2-2.png 500 500 "精准测试_2-2" %} | {% asset_img 精准测试_2-3.png 500 500 "精准测试_2-3" %} | {% asset_img 精准测试_2-4.png 500 500 "精准测试_2-4" %} |
|---|
摘自：百度 - 基于精准测试及图像技术的前端质量保证实践 - 刘道伟.pdf
遍历测试
价值
方案
{% asset_img 自动遍历脑图.png 500 400 "自动遍历脑图" %}
图像断言
价值（对比传统的 DOM 断言能力，如 Selenium）：
方案
| {% asset_img 图像断言_1-1.png 500 500 "图像断言_1-1" %} | {% asset_img 图像断言_1-2.png 500 500 "图像断言_1-2" %} | {% asset_img 图像断言_1-3.png 500 500 "图像断言_1-3" %} | {% asset_img 图像断言_1-4.png 500 500 "图像断言_1-4" %} |
|---|
摘自：百度 - 通用视觉 UI Diff 校验技术及实践 - 尹飞.pdf【建议看，细节多】
| {% asset_img 图像断言_2-1.png 500 500 "图像断言_2-1" %} | {% asset_img 图像断言_2-2.png 500 500 "图像断言_2-2" %} | {% asset_img 图像断言_2-3.png 500 500 "图像断言_2-3" %} | {% asset_img 图像断言_2-4.png 500 500 "图像断言_2-4" %} |
|---|
摘自：百度 - 基于精准测试及图像技术的前端质量保证实践 - 刘道伟.pdf【建议看，细节多】
关于前端自动化的其他参考资料：
| {% asset_img 其他自动化_1-1.png 500 500 "其他自动化_1-1" %} | {% asset_img 其他自动化_1-2.png 500 500 "其他自动化_1-2" %} |
|---|
摘自：阿里健康 - 前端质量保障体系化演进之路 - 张航.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 在看问题时刚好漏了它
这个问题提出来了，但不知道要谁来消费解决，无人认领
版本灰度数据比以往差，质量不好，但没被留意就继续增发灰度了
缺陷在发布前都消费完了，但是有些没提成权限的问题没有被关注到
常见解法
{% asset_img 质量门禁脑图.png 500 400 "质量门禁脑图" %}
各环节的准入与准出
价值
方案
问题自动流转
有生产链路就有相应的消费链路，广义消费链路包含监控、运维等针对问题所做的一系列活动，狭义指线下问题的流转消费流程。
这里的 “问题自动流转”，本身不依托质量门禁，它是一个持续运转的机制，是提升研发效能的方式。问题可以是广义的质量问题，也可以是狭义的缺陷，范畴可灵活定义。
价值
方案
| {% asset_img 问题自动流转_1-1.png 500 500 "问题自动流转_1-1" %} | {% asset_img 问题自动流转_1-2.png 500 500 "问题自动流转_1-2" %} |
|---|
摘自：阿里健康 - 前端质量保障体系化演进之路 - 张航.pdf
实践建议
质量门禁是贯彻问题消费的重要环节，应该优先建设，否则线下问题暴露得再多，不消费也白搭
质量门禁可针对不同类型问题（功能、性能、稳定性、兼容性等），按需实施不同严格程度的卡口
最简单的实践方式，是梳理一个卡口 checklist 的 Excel 文档，在封板与发版的时间节点上人工检查
相比于「变更前」，「变更中」意味着变更已经被发布到线上，线上用户开始接触变更。站在风险外漏角度，问题已经开始发生了，质量保障工作可以围绕着「如何更快发现问题」和「如何更快消除问题影响」来开展。
监控报警不仅仅是 RD 的工作，也是 QA 的工作。
典型问题
线上问题都上热搜了，我们才知道原来有这么个问题
线上出问题，但是不知道问题是什么，信息太少
线上用户反馈过来，没有标准处理流程，全屏个人经验对接
监控群里天天发报警消息，好像不处理也没事，久而久之没人管
报警过来了，但是报警携带的信息太少，不知道是什么问题，还要搞一顿很重复的排查定位
常见解法
{% asset_img 监控报警脑图.png 500 400 "监控报警脑图" %}
线上巡检
质量问题不一定都能被用户直接感知到，有些问题悄悄发生，当影响累积一定时长后，开始劣化并被大家感知到
价值
方案
其他参考
| {% asset_img 线上巡检_1-1.png 500 500 "线上巡检_1-1" %} | {% asset_img 线上巡检_1-2.png 500 500 "线上巡检_1-2" %} | {% asset_img 线上巡检_1-3.png 500 500 "线上巡检_1-3" %} | {% asset_img 线上巡检_1-4.png 500 500 "线上巡检_1-4" %} |
|---|
摘自：群核科技 - 多维度巡检在线上稳定性保障的实践 - 邹海滨.pdf【建议看，细节多】
| {% asset_img 线上巡检_2-1.png 500 500 "线上巡检_2-1" %} | {% asset_img 线上巡检_2-2.png 500 500 "线上巡检_2-2" %} |
|---|
摘自：阿里健康 - 前端质量保障体系化演进之路 - 张航.pdf
监控与报警
价值（QA 视角，考虑如何设计与实施监控报警）
方案（Grafana 等平台）
反馈处理
监控可能存在数据稀释的问题，个例问题较难识别，用户反馈作为补充渠道。
用户反馈在监控分层体系中，是最贴近用户的质量监控方式，是发现线上问题的必要来源渠道，反映业务功能、性能、稳定性、兼容性等多个线上质量核心指标。
价值
方案
| {% asset_img 反馈处理_1-1.png 500 500 "反馈处理_1-1" %} | {% asset_img 反馈处理_1-2.png 500 500 "反馈处理_1-2" %} | {% asset_img 反馈处理_1-3.png 500 500 "反馈处理_1-3" %} | {% asset_img 反馈处理_1-4.png 500 500 "反馈处理_1-4" %} | {% asset_img 反馈处理_1-5.png 500 500 "反馈处理_1-5" %} |
|---|
摘自：如何打造智能化的舆情监控平台 - 网易云音乐 - 蒋超.pptx【建议看，细节多】
实践建议
监控建设，实际开展的时候容易演变为 “先污染后治理”。早期的野蛮生长，使得后面不得回过头来重新打理。建议在监控建设开始时就考虑监控追加和清理的机制与规范
监控报警是相互以依赖的，监控是状态的反馈，报警是通知，更是要采取具体行动的信
处理用户线上反馈不但只是运营同学的工作，QA 往往需要参与其中协助复现/定位/解决问题，应该尽快明确标准流程，提高反馈流转效率，以免不可控的人力消耗。另外，线上用户反馈处理比较适合使用技术手段来提升整体处理效率
监控报警的实施也需要 “监控报警”
变更完成并不意味着尘埃落定，回顾整个变更过程中发生的 “意外”，能让我们有进一步的成长，从质量保障体系来说，没有后续的运营，那就是脱节和自嗨。
无论是正向体系化建设还是反向查漏补缺，线下的一系列质量建设需要经过验证来证明效果，这样在面对 未知/过往 大小故障的时候，损失会越来越小
典型问题
我们分析了很多问题，搞了好多建设，下一次同样的问题还是发生了
我们分析了很多问题，搞了好多建设，下一次问题来了还是没处理好
常见解法
{% asset_img 故障演练脑图.png 500 400 "故障演练脑图" %}
故障演练
故障演练不局限于服务端，移动端、前端都是可以落地这个理念。
价值
方案
| {% asset_img 故障演练_1-1.png 500 500 "故障演练_1-1" %} | {% asset_img 故障演练_1-2.png 500 500 "故障演练_1-2" %} | {% asset_img 故障演练_1-3.png 500 500 "故障演练_1-3" %} | {% asset_img 故障演练_1-4.png 500 500 "故障演练_1-4" %} |
|---|
摘自：阿里 - 前端安全生产的探索与实践 - 朱亚东.pdf
| {% asset_img 故障演练_2-1.png 500 500 "故障演练_2-1" %} | {% asset_img 故障演练_2-2.png 500 500 "故障演练_2-2" %} | {% asset_img 故障演练_2-3.png 500 500 "故障演练_2-3" %} |
|---|
| {% asset_img 故障演练_2-4.png 500 500 "故障演练_2-4" %} | {% asset_img 故障演练_2-5.png 500 500 "故障演练_2-5" %} | {% asset_img 故障演练_2-6.png 500 500 "故障演练_2-6" %} |
|---|
摘自：酷家乐 - 故障演练平台在酷家乐的演进历程 - 乐冉.pdf
| {% asset_img 故障演练_3-1.png 500 500 "故障演练_3-1" %} | {% asset_img 故障演练_3-2.png 500 500 "故障演练_3-2" %} | {% asset_img 故障演练_3-3.png 500 500 "故障演练_3-3" %} | {% asset_img 故障演练_3-4.png 500 500 "故障演练_3-4" %} |
|---|
摘自：阿里 - 前端故障演练的探索与实践 - 辰啸.pdf，演讲视频 B 站能搜到
实践建议
故障演练有明确目的，它既是暴露建设短板的手段，也是质量建设的验证手段（变更管控、服务设计、服务依赖、监控报警、运维操作）
不要忽略人员在面对故障时的心智意识
无跟踪无效率，无反馈无成长，无量化无质量
典型问题
过程数据不清楚，无法评估 “测试设计与执行” 本身的质量，被别人质疑
做了一堆事情，但是不知道对线上质量有无实际贡献
不知道有什么套路可以让大家对质量关注起来
常见解法
{% asset_img 度量运营脑图.png 500 400 "度量运营脑图" %}
质量度量
价值
建议
质量运营
质量运营在实操过程中经常退化为摆数据说数据，而事实上最重要的是要基于数据进行分析，帮助相关方做改进，同时跟进反馈改进的效果。看数据大家都会，实际做改进才是主要。
价值
建议
P-制定改进计划
质量痛点驱动：痛点来源于日常研发过程，通过问题分析制定落地改进方案，利用度量做效果评估
质量目标驱动：有一个既定的目标值，从上往下进行目标拆解，转化为各项度量指标目标值，针对这些下层指标做可落地的改进方案设计与实施
D-实施落地计划
日常运营：通过明确可执行的机制，日常滚动运营
短期突击：成立小的专项组，针对问题做短期内的专项改进，适合解决短平快的问题（如某个模块的 UI 自动化用例补充）
长期攻坚：成立大的专项组，针对问题做中长期体系化的专项改进（如体系化的监控报警治理）
C-复盘和反馈：形式上如各种书面总结报告、复盘总结会议，起到了承前启后的作用 —— 回顾计划与实施过程，评估落地效果，明确后续改进
A-改进和推广：基于前面的步骤，判断是否有效果，如果有效，则继续进一步做更深入的事项，如果无效则考虑做调整
一些手法：
培训宣贯
红黑榜
评分排名
……
回顾全文，行文思路如下，读者可以按照这个思路重新回顾一下前面多而杂的内容，具体内容细节可以在 这里下载：
阐述前端定义，以及解释前端质量的重要性
基于通用质量保障框架，推演前端质量保障体系
结合前端的差异与特色，阐述 变更前、变更中、变更后 三个环节所涉及的不同事项和一些实践建议
