更好的格式排版请看飞书文档：https://ladingkanxue.feishu.cn/docx/AJUmdAwPUohnWJxV0H3cLJd1njh

---

🔹 期刊内容 🔹

①【变更管控】阿里 - 支付宝统一运营变更核心

源链接：https://mp.weixin.qq.com/s/tcMaqp3TAo1nse5UtIjv4A

小编：支付宝的统一运营变更做得相对体系（文章也写得比较抽象，需要斟酌话术），也沉淀出完整的工程能力和平台，整体会显得比较重，思路上值得借鉴。

质量问题
在数字化转型的过程，业务由粗放式运营演进为精细化运营，支付宝域内逐渐演进出 P2C、P2B、B2C 等各大运营体系。业务的发展也带来了运营平台数量的激增，截止当前，支撑各大运营体系的后台数量已达到 50+，并且为了支撑运营活动快速迭代，各平台采用配置化架构，通过配置免开发的方式供业务小二直接使用。
配置化架构带来高效和便利的同时，也带来技术风险敞口扩大，原因有 3 点：

1. 传统代码实现需求有完善的研发与质量保障流程，配置化架构的每次操作，没有技术专职投入保障，无法通过 code review，以及线下/线上的测试回归保证正确性；
2. 配置化平台大多是面向小二内部的产品， 区别于对外部客户的系统，本身产品设计上并没有很高要求，稳定性成熟度低，三板斧机制偏弱；
3. 配置平台的使用对象是内部运营小二，大多数用户不具备技术风险保障的意识和专业性，且很多新用户不清楚平台的各种概念及规则。

方案介绍
宏观上看，先做变更分层，分为 SaaS 变更、PaaS 变更、IaaS 变更。其中 PaaS 和 Iaas 比较稳定，源自固定平台，变更语义明确，可以通过中心化的标准方案解决；而 SaaS 变更来自不同业务线，需要交有业务线去沉淀。
风险分类上，业务风险上浮，通用风险下沉。通用风险由统一的中台来处理，opscloud 作为风险防御平台对外提供通用防御能力，解决通用基础风险，不同的运营平台中接入 opscloud 来集中防控运营变更风险。
基于 opscloud 这个阵地，下沉五大标准能力：事前的变更分析、规则检查、业务验收；事中的变更推进；事后的问题发现。
同时以开放集成的方式，吸收业务特色的能力到配置防御流程中，解决业务个性化风险。

这里涉及的关键技术下面展开介绍。

数据引擎
将数据语义化分解，转化成可表达、可比较、可配置的规则结构，“数据” 锁描述的类型可以是 DB、GROOVY、HTTP、tr、ODPS(阿里数仓解决方案) 等不同来源的数据，在选择具体的某个节点下的数据，平台可以自动将数据切割为 KV 数据对呈现，提供一些基本的逻辑运算（如是否包含、是否数组包含、正则、数组相等、数据类型等）和诸如 $.comparePositionCrowdCheck[*].failedCnt 等参数化规则来表达防御配置。
数据引擎的作用是将上述处理能力封装并产品化提供，业务方部署场景模型及检测规则全流程，都可以采用配置化的方式，提升业务方部署效能，0 代码编写成本的规则部署能力，重点解决配置的业务语义识别和静态数据检测的问题。

功能验收
数据引擎赋能下，可以将规则可视化出来，从而从配置数据层面保障正确性。
对于部分通过具体数据无法直接判断正确性的场景，如

• 跳转到 appid 为 123456789 的 app
• 打开图片 image%2Fresize%2Cm_fill%2C***_48%2Fformat%2Cpng 等抽象不直观的数据，还需要在移动端上去渲染验收，以明确这些数据在可视化层面是否符合预期（是不是真的跳到那个 app，是不是真的打开了那一张我们想要的图片）。

1. 场景管理：提供录制回放和智能遍历能力，支持用户编写自动化用例完成定制化的验收
2. 原子能力：将常用的验收操作步骤封装成 api，如图像能力解决端显内容的识别与断言、mock 产品化能力解决配置数据依赖通路问题等，降低使用成本，提升复用度
3. 业务场境通路：这是重点内容，针对不同业务场景链路，配置数据的渲染会存在限制，如 UG 活动需要在指定机型、地域、时间等多因素同时满足的情况下才打开入口，现实中非常难以自动验收，需要人工配置成吨白名单。这里通过沉淀多类型的 mock 和 skip 能力，实现提前验收，包括：
4. 访问限制：时间、空间、员工体系的限制可以被 mock。如活动红包发放时间为一个月后、只有北京市可完成、限定企业员工可访问，通过流量染色和参数篡改，模拟生效条件从而实现端上的透出，解决配置内容透出对时间、空间、人员等依赖
5. 概率限制：将概率性透出变为 100% 透出。如五福刮刮卡中某个指定奖品验收，通过服务端 mock 产品化将业务配置模型直接组装转换为前端渲染模型，呈现用户，解决概率限制
6. 任务限制：依赖前置任务完成才可触发透出的场景。如支付后推荐、扫码乘车后的激励等，有些复杂小众的线上线下场景完成成本大，则通过集成不同业务的场景化 mock 能力解决

沉淀通用处理原子能力，如 注入、mock、智能遍历等，解决业务通用的验收基建问题，对不同业务线个性化的问题，通过开放集成引入业务域特色解决方案。
以真机/模拟器渲染为底座，为用户封装供给原子化操作能力，如 mock、多版本/设备管理、OCR、黑白屏检测等原子能力，并为了适配业务玩法对服务端的依赖，通过注入能力的产品化，解决了部分业务配置对时间、空间、概率、人群等条件的限制，更加便于业务专注在验收的产品功能逻辑层。
小编理解：就是业务线自发做了很多业务特性的 mock 能力，最后由平台统一有机地集成在一起，一方面可以 Web 一键配置使用，另一方面也能打通云真机上的自动化任务，实现自动验收自动断言

业务预演
前面提及了两部分，分别是：

1. 静态规则检测，从配置数据层面保障正确性
2. 功能验收，从端产品功能层面保障正确性 以上两部分有一个很明显的局限，就是传统的单样本、单流量下验证通过，不能代表具备大流量属性的人群、活动、玩法、中奖概率、区域分布就没有配置问题，所以需要具备业务语言能力来提前看到配置真实生效时的数据分布。 小编理解：静态规则检测&功能验收，更多是服务于调试验证，但是真枪实战还是要看大规模的线上演练 联动蚂蚁技术风险团队的流量海关、仿真团队，共建业务预演能力。

1. 预演样本采集：为业务预演提供匹配的用户流量，做法上根据历史用户流量提前打好标签，在预演需要的时候就可以按照标签直接筛选出期望命中&期望不命中的流量
2. 预演执行引擎：创建预演任务，通过触发预演任务执行，捞取对应的流量样本进行分发触发不同业务接口进行预演，支持流程编排以满足不同业务预演需求（部分任务需要依赖其他前置任务预演结果）
3. 业务回放链路：在近几年蚂蚁仿真环境大修的背景下，业务仿真升级仿真环境方案，减小业务链路的改造成本。在重点解决仿真底盘稳定性（可用率、容量）基础上，在实际落地过程中，遇到了如 TPP 非标应用仿真通路、策略模型线上加载、业务缓存刷新等问题，通过配置化 mock 等方式解决，可参考这里（小编：看不懂原文在说什么）
4. 预演指标分析：通过对业务预演日志采集、通用人群分层数据分析，产出对应的活动预演结果报表数据，提供给运营进行业务确认。通过配置化指标能力，供给不同业务的接入，自定义规则开放能力，一次预演结果如右图

业务预演总结起来是在配置上线前，通过模拟用户触发参与，下钻分析用户参与后的业务结果数据及提供效果预览，帮助业务在不消耗预算及用户无感知的情况下，发现此类配置的风险，从 “上线前活动效果预估、活动设计错误拦截、配置内容错误拦截” 三个维度，规避活动风险引发的线上故障、大额资损风险、活动效果不及预期的情况。
小编理解：这里的业务预演，大概理解为在用户无感知的情况下完成了一次活动的参与，但是在真实用户的手机上活动是不透出不渲染的，所以用户才会无感知；
这里预演的意义，一方面是通过历史活动中已经沉淀下来的用户标签，去快速筛选到符合预演条件的用户，而不需要真正对线上全流量的用户做一次实时判断筛选下发，节省成本（下发配置也是消耗 cdn 带宽成本）；另一方面可以在用户手机上探测有无不符预期的地方，比如运营配置了某张图片，通过预演发现这张图片因格式不正确导致端上渲染报错，就能提前拦截问题

风险机器人
这一部分相对简单，本质上就是将配置带来的质量风险，通过运营人员可以理解的业务语义输出出来，简单来说就是将最终的结果用运营同学能理解的语言输出。一方面是将技术风险做产品化的表达，做好人机交互；另一方面是风险结果输出到不同的运营平台前端，以便加审批/阻断发布流程，或让业务自定义后续处理流程。

智能推导
沉淀了一段时间的风险场景和防御用例后，系统也积累了相当量的配置运行数据。风险规则是基于业务专家经验人工输出的，出现一些局限性：

1. 业务部门经常是横向推进专项，角色上区分专项 owner 和 业务参与方，如果专项 owner 新增了配置规则但是没同步到业务参与方，就会出现业务参与方漏配规则，出现风险
2. 规则配置人可能存在知识盲区，导致对风险的理解不全面，从而出现规则漏配的问题 解决方案是，先将复杂的数据拆解为一些基本元数据，再去聚类历史变更数据特征，总结出正则特征以及置信度，从而产出训练模型。最终实现自动生产规则，提供完整的拦截反馈原因。

小编理解：靠人配存在漏配的可能，通过算法总结配置规律，自动地去配置规则（但会不会存在配置过拟合的问题？）

②【精准测试】飞书多维表格-Web 精准测试的研究与业务实践

为避免涉敏，本文章内容不在这里做分享，感兴趣的同学建议考虑一下飞书的 QA 岗位 😁，至少深圳、广州、北京都有~

③【服务压测】B 站压测系列-B 站压测实践之压测平台的演进

源链接：
B 站压测实践之压测平台的演进：https://mp.weixin.qq.com/s/-8flTCyNFDKrnnlHYaVAgw
B 站在全链路压测上的实践：https://mp.weixin.qq.com/s/ScFa571lSemNmoVk25GJjg
bilibili 全链路压测改造之全链自动化测试实践：https://mp.weixin.qq.com/s/9SGqpVO-5knO1COcoZK5Pg

小编：B 站压测实践从原始的手工执行不同团队各自为战，逐渐演化出第一代与第二代的平台化；文章重点介绍 B 站第二代压测平台的各种技术思想，包括压测容器、压测引擎、压测策略、数据隔离等方面展开。
压测平台演进

• 手工阶段：各个团队内部使用脚本 + 开源压测工具实现压测目标，存在单节点难实现高并发的问题，分布式压测门槛高，人力成本和资源成本高
• 平台 1.0：通过可视化平台将用户的测试配置转化为 Jmeter 脚本，压测引擎结合云原生 Pod 容器来控制并发，但因为使用 Jmeter 引入了诸多瓶颈和限制，如 Jmeter 压测配置不合理导致浪费、Jmeter 配置扩展性差等问题
• 平台 2.0：推翻重来，主要有几个方面的考虑
  • 使用云原生技术，在统一资源规格的 Pod 里运行发压客户端作为一个节点，节点所发的压力经过调试，避免用户不知道节点的发压性能拐点而出现的少发浪费资源或多发超载运行

• 自研发压引擎取代 Jmeter，额外支持动态线程池功能，运行时可动态增减并发数，且可以监控实例资源自适应调整实例并发数配置，成为智能分布式发压引擎
  

• 发压客户端定义 3 种状态，空闲状态、加减压状态、稳定状态；主循环器会按照下图对应的方式来逐步增加压力直至达到压力的目标阈值，以支持不同的压测策略（如 QPS 模式、指定并发数模式）
  

• 压测场景支持单接口不同传参值压测、多接口组合压测、线上流量录制处理后的回放。流量录制回放方面，为了适配不同技术栈（Java、Golang...），采用跨语言通用的非代码侵入式微服务流量录制方法。

  • 流量监听伴生服务：通过旁路方式监听微服务的入口端以及所有出口端（tshark），使得主服务无感知；通过心跳实现状态上报以及命令下发
  • 流量收集：Kafka 集群接收伴生容器发过来的流量数据，Logstash 服务消费并写入 ElasticSeach 作为索引查询展示
  • 管理平台：心跳收集&配置同步、应用接入&规则配置、流量查询展示
  • 数据隔离，包括线上生成一批压测账号实现账号隔离，基于 header 中的压测标记做流量区分的影子库隔离等。

④【测试策略】阿里 - 测试环境不稳定&复杂的必然性及其对策

源链接：https://mp.weixin.qq.com/s/CEKX8NTN9UQdUm3rDdHnQQ

小编：这是一篇比较深刻的短文，作者的观点是测试环境不稳定的根源在于测试环境里面存在不稳定的代码，以及测试环境不稳定带来的影响小从而出现关注度低，最后作者给出了解决测试环境不稳定的两个思路，分别是兜底稳定的主干环境复用&基于 Mesh 的环境隔离。
质量问题
今天我们研发同学的心智是：当一个同学在测试遇到错误的时候，他的第一反应是 “一定是环境问题”。也就是说，他的第一反应是 “别人的问题”，只有当 “别人的问题” 都排出后他才会认真的去看是不是他自己的问题（包括项目的问题）。来探讨两个问题：

1. 为什么测试环境的不稳定是必然的，怎么让它尽量稳定一点？
2. 为什么测试环境比生产环境更复杂，怎么让它尽量简单一点？

观点解析
测试环境不稳定，是必然的。
有的人说线下的容量没有线上大，有的人说线下没有真实用户，有的人说线下缺少生产的真实数据，等等，各种答案都有。在作者看来，首先测试环境和生产环境，它们是两个不同的场景。对于生产环境，准确与稳定性最重要；对于测试环境，隔离、低成本和稳定的依赖最重要。
大家经常吐槽测试环境不稳定，不稳定的原因不外乎如下：

• 测试环境都是过保的机器而且超卖了（虚拟化后的硬件资源超卖），为了节省成本
• 生产有的配置，在测试环境没有，导致启动失败了
• 监控、告警等能力在测试环境没有配套，问题发现不及时
• 投入不够，不重视，对问题的响应不及时，流程机制等没建立起来 作者认为这些都不是本质问题，即便狠狠的砸钱、砸人，即使机器不用过保机、硬件不超卖、工具建设好把配置监控自愈等和生产环境保持对齐、问题响应机制建立起来，测试环境也还是会不稳定的。因为测试环境不稳定的根源在于：
  1. 测试环境里面有不稳定的代码
  2. 测试环境不稳定带来的影响小

测试环境比生产环境更复杂
生产环境只有一套，链路和应用间的调用关系比较清晰，服务也相对比较稳定，但在测试环境中，因为涉及到多方并行研发，服务间的依赖会变得很复杂，如 A 强依赖于 B，B 变更之后还要保证不影响 A。随着分布式系统的演进，微服务的数量也呈指数级增长，整个系统的复杂度也会随之升级，即使单个微服务很简单，但是交互建立起的系统将成为复杂性的瓶颈。下图举例：

1. 需要将链路上所有的应用都创建一套环境才能将链路跑通，谁能清楚整条链路上的应用？
2. 并行开发使得多个节点同时变更，整条链路上的应用在不停变化，问题排查成本如何？那如果只孤立变更节点，其他节点取稳定状态去部署，维护成本如何？
3. 多套环境，势必会带来并行干扰的问题，如何将请求准确的路由到期望的服务上？
4. 同一套中间件、数据库等基础设施如何软隔离？

对于这种场景，生产环境（灰度、正式）之间首先存在物理隔离，其次是只需要一套环境即可满足，不存在多套相似的环境并行的问题。

让测试环境稳定与简单的方案

• 环境复用
  • 核心思想：需要有一个主干环境，主干环境作为兜底的稳定环境，被大家共享，而变更的应用只需要单独创建项目环境，其余的依赖都复用主干环境。 如交易链路有 100+ 个应用，它的主干环境是全量的，但项目环境只包含这个项目涉及的应用，测试发起的流量会被路由机制从主干环境的应用路由到项目环境的应用，所以只需要部署项目环境即可

• 项目环境 + 主干环境模式（主干环境之上 “挂着” 若干个项目环境）：
  • 主干环境：跑的是和正式环境的版本相同的代码，每次生产环境发布后，主干环境也会同步更新
  • 项目环境：每个项目有自己的项目环境，部署的是项目的分支代码，这个项目上的同学就在这个项目环境里做测试联调（集成）
• 最终，不变的服务或基础设施实现复用，搭建环境无论是从资源成本还是从复杂度上都得到了极大的降低。
  • 环境隔离

• 核心思想：基于 Service Mesh 实现 RPC 服务隔离、消息/配置/缓存中间件隔离、数据库隔离、HTTP 流量隔离

  • Service Mesh 是一组同来处理服务间通讯的网络代理，右图是经典 Sidecar 模式。Sidecar 可以理解为一个网络代理，所有传入和传出服务的网络流量都会流经 Sidecar 代理，因此，Sidecar 能够管理微服务之间的流量，收集数据并实施相关策略。Sidecar 的优点是对应用本身无侵入（只处理流量，不改应用代码），适配不同网络协议，不需要和应用使用相同的编程语言技术栈，升级也不会对应用产生影响
  • 环境稳定性提高

• 核心思想：环境的稳定性对应着如下的金字塔模型，越往下层，稳定性越需要保障

  • 基础服务稳定性：基础服务包括基础设施、中间件和数据库，虽然是测试环境的基础服务，但需要按照生产级的标准进行保障。因为基础服务抖一抖，对于上层服务来说可以说是地震；
  • 主干环境稳定性：确保主干环境稳定，测试出来的问题才有说服力。主干环境的单应用都是好的，链路也都是能跑通的，这时候出现了问题，就应该先怀疑是项目环境的问题，而不是依赖环境的问题；
  • 路由准确性：确保需要隔离的机器上都安装了隔离插件、隔离数据的准确性和同步性，保证服务间的路由不出错，否则隔离的可用和正确性无从谈起。

⑤【综合保障】阿里 - 语雀质量体系与自动化

源链接：https://mp.weixin.qq.com/s/r3Q8Ru2i5zZSm8uLEf8IAA

小编：语雀对外称测试开发比 1:20，整体质量保障工作显得麻雀虽小五脏俱全，从质量内建层面的研发规范，到测试左移的端到端自动化，再到持续集成，最后是相对完整的质量管理体系，适合早期快速发展的业务线作为标的来参考。
质量问题
语雀作为一款在线文档编辑与协同工具，产品和研发特点比较特殊，对应的质量保障体系建设经历了从 “农耕社会” 到 “初步探索工业化”，再到 “全面工业化” 发展的过程，在测试开发比 1:20 的情况下，如何做好质量保障工作，这篇文章给出了比较完整的方案。

方案介绍

• 文化思想
  • 教练模式：QA 相当于教练，通过各种质量保障机制规范和提升开发同学的质量意识，提供完备、可持续可沉淀、工程化的质量服务提升研发效能，从而提升产品质量不是通过对人的方式来做质量工作。
• 质量支撑工具
• SkyTest：是一个代码工具箱，以 npm 工具模块的形式存在，可以通过 CLI 的方式使用，或者以 node 模块集成，集成便捷，比较轻量，适合 QA 工具的研发。维护成本相对 Web 应用要轻量很多。

• LarkReliable：作为质量数据持久化&洞察服务，和 SkyTest 搭配，可快速实现团队内的测试报告持久化和数据洞察的服务能力。右图为测试覆盖率报告查看。
  
  

• 长效机制
  在质量体系建设初期做好机制闭环，带来的长期收益是非常可观的，推荐优先切入建设。

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

• 线下缺陷播报：将缺陷管理平台中的缺陷统计分析后自动化播报到研发群中（其实是对缺陷管理平台能力的扩展）；建立了日报 / 周报 机制，有效促进收敛，清理缺陷历史债。

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

• 覆盖率治理：PR 环节加入增量覆盖率卡点，为评审人和开发同学提供直观的覆盖率报告，激励研发及时补充单测用；同时历史上覆盖率跟进有丢失的模块的覆盖率数据也通过搜集、合并在一份报告上，实现覆盖率的长期统计跟踪机制。

• 线上不可用治理：针对低版本浏览器内核不兼容、白屏的死角问题，进行监控和不支持引导；同时建设了浏览器版本分布情况的准确的感知能力，基本目标是：

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

• CI 问题跟踪：实现了 CI 问题的自动化跟踪机制，包括自动化发现问题（日志、缺陷池、覆盖率数据、CI 报错）、自动化指派跟踪（缺陷管理平台）、消息触达（钉钉机器人）。

• 建立机制持续交付

  • 主站点：通过日常迭代分支的 PR 合并，触发对应的 CI 流水线任务，完成持续部署和持续测试
  • 桌面端&移动端 CICD：拓展了 CICD 服务能力，打通自动化和机器人通知
  • CI 提效：通过拆分 CI 任务、做不稳定任务重试等优化整体任务的效率和稳定性

• UI 自动化技术（UIA）

  • Macaca 套件：一套面向用户端软件的测试解决方案，从测试驱动到多端回归通过封装 macaca-playwright 驱动实现（playwright 是微软开源的驱动框架，提供了比较全面、强大的 web UI 测试能力）
  • 多浏览器&桌面端 U2IA&移动端 UIA：基于 Macaca 套件搭建多端自动化测试方案
  • UIA 白屏巡检：通过对线上静态页面和预期页面进行像素级对比，发现线上页面有较大出入时，及时告警
  • 录制器：自研的 macaca-recorder 工具基于插件化设计，通过录制的方式生成测试脚本。支持模板开发，可以定制化录制所需的 UIA 脚本，这样无论封装或者使用什么样的测试框架，都可以灵活支持

---

🤔 关于 “他山之石” 💭

• 我们是谁？
  来自直播&开放平台的 QA 同学，非常业余的小编。

• 专栏的目的是什么？
  QA 之间的质量保障交流可能比较匮乏，我们想激活大家的交流意识。
  大家平时埋头苦干，有意愿了解外部质量保障方案却苦恼于没有渠道，我们想给大家一个勉强还行的渠道。
  如果哪一天能组织大家一起搞搞线上线下交流，那我们的使命就很圆满。

• 内容哪里来？
  内容来源是大厂微信公众号、行业测试大会 PPT、公司内部其他团队的好方案…… 如果有精力的话还希望卷一下国外大厂的方案以及 Paper。

• 频率怎么样？
  两到三周一期，节假日顺延，每期约 5 篇文章。