更好的格式排版请看飞书文档:https://ladingkanxue.feishu.cn/docx/AJUmdAwPUohnWJxV0H3cLJd1njh
小编:支付宝的统一运营变更做得相对体系(文章也写得比较抽象,需要斟酌话术),也沉淀出完整的工程能力和平台,整体会显得比较重,思路上值得借鉴。
质量问题
在数字化转型的过程,业务由粗放式运营演进为精细化运营,支付宝域内逐渐演进出 P2C、P2B、B2C 等各大运营体系。业务的发展也带来了运营平台数量的激增,截止当前,支撑各大运营体系的后台数量已达到 50+,并且为了支撑运营活动快速迭代,各平台采用配置化架构,通过配置免开发的方式供业务小二直接使用。
配置化架构带来高效和便利的同时,也带来技术风险敞口扩大,原因有 3 点:
方案介绍
宏观上看,先做变更分层,分为 SaaS 变更、PaaS 变更、IaaS 变更。其中 PaaS 和 Iaas 比较稳定,源自固定平台,变更语义明确,可以通过中心化的标准方案解决;而 SaaS 变更来自不同业务线,需要交有业务线去沉淀。
风险分类上,业务风险上浮,通用风险下沉。通用风险由统一的中台来处理,opscloud 作为风险防御平台对外提供通用防御能力,解决通用基础风险,不同的运营平台中接入 opscloud 来集中防控运营变更风险。
基于 opscloud 这个阵地,下沉五大标准能力:事前的变更分析、规则检查、业务验收;事中的变更推进;事后的问题发现。
同时以开放集成的方式,吸收业务特色的能力到配置防御流程中,解决业务个性化风险。
这里涉及的关键技术下面展开介绍。
数据引擎
将数据语义化分解,转化成可表达、可比较、可配置的规则结构,“数据” 锁描述的类型可以是 DB、GROOVY、HTTP、tr、ODPS(阿里数仓解决方案) 等不同来源的数据,在选择具体的某个节点下的数据,平台可以自动将数据切割为 KV 数据对呈现,提供一些基本的逻辑运算(如是否包含、是否数组包含、正则、数组相等、数据类型等)和诸如 $.comparePositionCrowdCheck[*].failedCnt 等参数化规则来表达防御配置。
数据引擎的作用是将上述处理能力封装并产品化提供,业务方部署场景模型及检测规则全流程,都可以采用配置化的方式,提升业务方部署效能,0 代码编写成本的规则部署能力,重点解决配置的业务语义识别和静态数据检测的问题。
功能验收
数据引擎赋能下,可以将规则可视化出来,从而从配置数据层面保障正确性。
对于部分通过具体数据无法直接判断正确性的场景,如
沉淀通用处理原子能力,如 注入、mock、智能遍历等,解决业务通用的验收基建问题,对不同业务线个性化的问题,通过开放集成引入业务域特色解决方案。
以真机/模拟器渲染为底座,为用户封装供给原子化操作能力,如 mock、多版本/设备管理、OCR、黑白屏检测等原子能力,并为了适配业务玩法对服务端的依赖,通过注入能力的产品化,解决了部分业务配置对时间、空间、概率、人群等条件的限制,更加便于业务专注在验收的产品功能逻辑层。
小编理解:就是业务线自发做了很多业务特性的 mock 能力,最后由平台统一有机地集成在一起,一方面可以 Web 一键配置使用,另一方面也能打通云真机上的自动化任务,实现自动验收自动断言
业务预演
前面提及了两部分,分别是:
业务预演总结起来是在配置上线前,通过模拟用户触发参与,下钻分析用户参与后的业务结果数据及提供效果预览,帮助业务在不消耗预算及用户无感知的情况下,发现此类配置的风险,从 “上线前活动效果预估、活动设计错误拦截、配置内容错误拦截” 三个维度,规避活动风险引发的线上故障、大额资损风险、活动效果不及预期的情况。
小编理解:这里的业务预演,大概理解为在用户无感知的情况下完成了一次活动的参与,但是在真实用户的手机上活动是不透出不渲染的,所以用户才会无感知;
这里预演的意义,一方面是通过历史活动中已经沉淀下来的用户标签,去快速筛选到符合预演条件的用户,而不需要真正对线上全流量的用户做一次实时判断筛选下发,节省成本(下发配置也是消耗 cdn 带宽成本);另一方面可以在用户手机上探测有无不符预期的地方,比如运营配置了某张图片,通过预演发现这张图片因格式不正确导致端上渲染报错,就能提前拦截问题
风险机器人
这一部分相对简单,本质上就是将配置带来的质量风险,通过运营人员可以理解的业务语义输出出来,简单来说就是将最终的结果用运营同学能理解的语言输出。一方面是将技术风险做产品化的表达,做好人机交互;另一方面是风险结果输出到不同的运营平台前端,以便加审批/阻断发布流程,或让业务自定义后续处理流程。
智能推导
沉淀了一段时间的风险场景和防御用例后,系统也积累了相当量的配置运行数据。风险规则是基于业务专家经验人工输出的,出现一些局限性:
小编理解:靠人配存在漏配的可能,通过算法总结配置规律,自动地去配置规则(但会不会存在配置过拟合的问题?)
为避免涉敏,本文章内容不在这里做分享,感兴趣的同学建议考虑一下飞书的 QA 岗位 😁,至少深圳、广州、北京都有~
源链接:
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 站第二代压测平台的各种技术思想,包括压测容器、压测引擎、压测策略、数据隔离等方面展开。
压测平台演进
自研发压引擎取代 Jmeter,额外支持动态线程池功能,运行时可动态增减并发数,且可以监控实例资源自适应调整实例并发数配置,成为智能分布式发压引擎
发压客户端定义 3 种状态,空闲状态、加减压状态、稳定状态;主循环器会按照下图对应的方式来逐步增加压力直至达到压力的目标阈值,以支持不同的压测策略(如 QPS 模式、指定并发数模式)
压测场景支持单接口不同传参值压测、多接口组合压测、线上流量录制处理后的回放。流量录制回放方面,为了适配不同技术栈(Java、Golang...),采用跨语言通用的非代码侵入式微服务流量录制方法。
小编:这是一篇比较深刻的短文,作者的观点是测试环境不稳定的根源在于测试环境里面存在不稳定的代码,以及测试环境不稳定带来的影响小从而出现关注度低,最后作者给出了解决测试环境不稳定的两个思路,分别是兜底稳定的主干环境复用&基于 Mesh 的环境隔离。
质量问题
今天我们研发同学的心智是:当一个同学在测试遇到错误的时候,他的第一反应是 “一定是环境问题”。也就是说,他的第一反应是 “别人的问题”,只有当 “别人的问题” 都排出后他才会认真的去看是不是他自己的问题(包括项目的问题)。来探讨两个问题:
观点解析
测试环境不稳定,是必然的。
有的人说线下的容量没有线上大,有的人说线下没有真实用户,有的人说线下缺少生产的真实数据,等等,各种答案都有。在作者看来,首先测试环境和生产环境,它们是两个不同的场景。对于生产环境,准确与稳定性最重要;对于测试环境,隔离、低成本和稳定的依赖最重要。
大家经常吐槽测试环境不稳定,不稳定的原因不外乎如下:
测试环境比生产环境更复杂
生产环境只有一套,链路和应用间的调用关系比较清晰,服务也相对比较稳定,但在测试环境中,因为涉及到多方并行研发,服务间的依赖会变得很复杂,如 A 强依赖于 B,B 变更之后还要保证不影响 A。随着分布式系统的演进,微服务的数量也呈指数级增长,整个系统的复杂度也会随之升级,即使单个微服务很简单,但是交互建立起的系统将成为复杂性的瓶颈。下图举例:
对于这种场景,生产环境(灰度、正式)之间首先存在物理隔离,其次是只需要一套环境即可满足,不存在多套相似的环境并行的问题。
让测试环境稳定与简单的方案
核心思想:基于 Service Mesh 实现 RPC 服务隔离、消息/配置/缓存中间件隔离、数据库隔离、HTTP 流量隔离
核心思想:环境的稳定性对应着如下的金字塔模型,越往下层,稳定性越需要保障
小编:语雀对外称测试开发比 1:20,整体质量保障工作显得麻雀虽小五脏俱全,从质量内建层面的研发规范,到测试左移的端到端自动化,再到持续集成,最后是相对完整的质量管理体系,适合早期快速发展的业务线作为标的来参考。
质量问题
语雀作为一款在线文档编辑与协同工具,产品和研发特点比较特殊,对应的质量保障体系建设经历了从 “农耕社会” 到 “初步探索工业化”,再到 “全面工业化” 发展的过程,在测试开发比 1:20 的情况下,如何做好质量保障工作,这篇文章给出了比较完整的方案。
方案介绍
LarkReliable:作为质量数据持久化&洞察服务,和 SkyTest 搭配,可快速实现团队内的测试报告持久化和数据洞察的服务能力。右图为测试覆盖率报告查看。
长效机制
在质量体系建设初期做好机制闭环,带来的长期收益是非常可观的,推荐优先切入建设。
周迭代值班:迭代有序化,有点像项目经理,在语雀日常迭代管理、发布执行都归 QA 同学。 QA 同学轮流按周迭代值班,保障发布质量,做好 UIA 回归卡点、发布执行和 hotfix 复盘。
线下缺陷播报:将缺陷管理平台中的缺陷统计分析后自动化播报到研发群中(其实是对缺陷管理平台能力的扩展);建立了日报 / 周报 机制,有效促进收敛,清理缺陷历史债。
线上日志缺陷治理:通过不间断获取、分析线上日志的方式,及时发现线上发生的缺陷,并自动化录入到对应的缺陷管理项目中,对日志内容进行规则自动分析并按照主站、移动端、桌面端归一分类指派给对应的负责人修复,整体效率和信息及时性在潜移默化中得到很大提升。
覆盖率治理:PR 环节加入增量覆盖率卡点,为评审人和开发同学提供直观的覆盖率报告,激励研发及时补充单测用;同时历史上覆盖率跟进有丢失的模块的覆盖率数据也通过搜集、合并在一份报告上,实现覆盖率的长期统计跟踪机制。
线上不可用治理:针对低版本浏览器内核不兼容、白屏的死角问题,进行监控和不支持引导;同时建设了浏览器版本分布情况的准确的感知能力,基本目标是:
CI 问题跟踪:实现了 CI 问题的自动化跟踪机制,包括自动化发现问题(日志、缺陷池、覆盖率数据、CI 报错)、自动化指派跟踪(缺陷管理平台)、消息触达(钉钉机器人)。
建立机制持续交付
UI 自动化技术(UIA)
我们是谁?
来自直播&开放平台的 QA 同学,非常业余的小编。
专栏的目的是什么?
QA 之间的质量保障交流可能比较匮乏,我们想激活大家的交流意识。
大家平时埋头苦干,有意愿了解外部质量保障方案却苦恼于没有渠道,我们想给大家一个勉强还行的渠道。
如果哪一天能组织大家一起搞搞线上线下交流,那我们的使命就很圆满。
内容哪里来?
内容来源是大厂微信公众号、行业测试大会 PPT、公司内部其他团队的好方案…… 如果有精力的话还希望卷一下国外大厂的方案以及 Paper。
频率怎么样?
两到三周一期,节假日顺延,每期约 5 篇文章。