专栏文章 质量专栏 “他山之石” - 第一期

王稀饭 · 2023年05月05日 · 最后由 王稀饭 回复于 2023年05月08日 · 10883 次阅读

更好的格式排版请看飞书文档:https://ladingkanxue.feishu.cn/docx/DiLidZhRko0SmKxrPRhc6BPvnNe
第一期比较仓促,故内容上还有不少问题,未来慢慢打磨迭代~


🔹 期刊内容 🔹

①【UI 自动化】美团-App 页面视图可测性改造实践
源链接:https://mp.weixin.qq.com/s/YcvFSs-97SpMKjlpj9Dzqg
质量问题
美团 App 呈现千人千面,存在多种不同页面样式,假若需求要在 1 天内完成开发、测试、上线,则会面临很大跳转,需要重度依赖自动化测试快速验收,但是 Android App 页面使用大量 Drawable 对象来绘制页面信息,内部基于 Appium 的自动化方案无法定位元素,导致难以拿到自动化收益。

方案介绍
实现 SDK 接入到 App 来监听布局信息,将信息做解析与 json 结构化,通过 HTTP 发送到跑在自动化脚本的 Client 上。

  • 问题一:为什么 Drawable 对象无法获取元素信息? 通过源码了解到 Drawable 没有实现 AccessibilityEventSource 接口的某个方法,导致视图信息没有保存到 AccessibilityNodeInfo 对象中;而 Appium 使用的 findElement 方法定位元素,最终是使用 PartialMatch.accept 来获取 AccessibilityNodeInfo 对象的信息,两者冲突。
  • 问题二:如何获取 Drawable 对象的视图信息? 先排除三种方案:
    • 修改 Appium 的定位方式使得 Drawable 可以被识别,但是需要兼容所有 Android 系统,影响范围过大;
    • 使用 View 替代 Drawable 使得可被 Appium 识别,相当于放弃动态布局卡片使用 Drawable 绘制的性能优势,业务有损;
    • 图像识别定位,图像中包含多行文本,很大程度上影响准确性;

最后选择通过内部 SDK 和外部 Client 做 HTTP 通信的方式,用 SDK 监听获取布局信息做解析与结构化外传,最终传递给自动化脚本。

②【性能压测】哔哩哔哩 - 直播间场景下 App 客户端长链消息业务性能测试实践
源链接:https://mp.weixin.qq.com/s/w2JwT1_fcFxTacGy152TuQ
质量问题
B 站直播业务飞速发展,从 LOL S 赛到跨晚直播、传统节目拜年纪,高流量直播互动节目对直播间看端性能和质量提出了更高要求。直播间会并存弹幕、进场提醒、全屏礼物动画、连击礼物等,如果终端性能跟不上,丰富的玩法和特效反而会拉低用户体验,营收效果也会打折扣。针对上述实时互动能力的质量保障,有以下难点:

  1. 场景构造链路太长,耗时耗力:测试各类广播在直播间效果以往的手段需要多端配合且依赖账户数据,以触发 “大航海特效” 为例:先使用推流工具开播,终端 A 登录账号进入直播间送出礼物,终端 B 进入直播间,A、B 分别收到主客态广播,最终触发礼物特效;
  2. 异常数据构造能力缺失:广播内容完全由服务端下发,无法模拟接口各个字段的异常情况,广播容错测试完全空白;
  3. 性能测试效率低下:广播测试从传统的端到端功能维度去测试,性能不能解耦开来关注,缺乏对端的消费能力、性能、体验的针对性测试,都需要投入大量人力进行手工回归,卡顿、闪退、发热等体验问题频发;
  4. 测试资产(各类测试资源与配置)复用困难:直播的广播消息类型经过数年迭代,有超过 100+ 消息类型,测试资产积累靠文档相传;

方案介绍
实现了一套面向终端消费场景的直播间广播压测工具链,并平台化为 “广播压测平台”,大幅提升直播间整体质量与专项测试效率,并沉淀下来直播间复杂广播场景下性能测试的最佳实践。方案主体如下:

广播压测系统架构图

  1. 广播消息元数据收集:通过对 broadcast-proxy 广播日志的全采样,经过处理归档为有序的广播回放文件,可以通过平台手动改变广播体中部分字段内容方便构造异常数据,提供自定义标签管理。

  2. 压测任务配置及场景编排:直播间压测根据需求可自由配置不同广播组合及 QPS。平时测试需求会形成一个个的单元测试场景的配置,支持将单元测试场景组合在一起形成一个测试任务。

  3. 发压服务:当前的实现方案比较粗糙,一个定时 loop 负责压测线程分配,压测线程会从 loop 中获取压测命令,通过调用 broadcast-proxy 服务实现实际发压。

  4. 性能数据收集与报告:使用 perfdog 手机端上的性能数据,通过 perfdog 的 report 接口协议,将性能数据上传做可视化分析,与多个版本的性能基线做对比.

压测实操

  1. 制定压测目标:预估业务场景的压力流量,一方面以高于预估压力的情况下持续播放 2 小时无崩溃闪退卡死为目标,另一方面按照常规压力、1.5 倍、2.5 倍、极限压力等不同梯度做多场景组合。
  2. 制定分级测试策略:按活跃用户机型市占率,做机型性能的分级。
  3. 根据保障场景配置压测数据:如拜年纪是高弹幕互动场景,不是高消费活动,业务也会要求屏蔽引流类型的特殊广播消息,故弹幕用例配置的 QPS 要更高。
  4. 性能报告分析:数据分析,定位排查问题,修复&验证。

③【风险评估】百度 - 质量评估模型助力风险决策水平提升
源链接:https://mp.weixin.qq.com/s/7yAL9Uw6JJJPQmFSki54Vg
质量问题
你在测试过程中是否也发现了以下问题?

  • 不是所有的项目都有风险,80% 以上的项目无任何的关联 bug 和线上问题
  • 不是所有的测试任务都能够揭错,无效的质量行为(有 bug 发现的质量行为/所有质量行为)占比非常高
  • 测试人员也有误判的可能,漏测一直存在 针对这些现象,我们需要判断哪些项目需要介入测试、测试到什么程度能够交付,目前这部分的判断主要依赖人工,而人员能力是参差不齐的,完全基于人工经验去评估,会存在判断盲区,造成漏测。

方案介绍
整体方案是构建质量评估系统,机器自动决策,自动流转流程,核心由风险识别、风险控制和风险决策 3 部分组成,具体如下:

  • 风险识别:识别动、静态风险点,包括人员,项目,代码变更和影响范围的风险
    1. 采集 5 个维度共 50+ 维特征(commitid、pipelineid、jobid 等)
    2. 通过提测单 + 需求卡片 id+ 自动化流水线 id 建立该维度血缘关系,可以获取卡片对应维度的特征数据,便于后续做控制和决策
    3. 支持业务自定义特征和数据的快速检索
  • 风险控制:针对识别的风险,推荐测试活动、测试用例,自动构造测试输入进行测试控制
    1. 首先识别所有风险
    2. 然后针对于变更,比如影响接口、影响场景有针对性的测试,能够覆盖变更用例做定制执行,如果有覆盖不到的,甚至可以推荐一些自动生成用例执行
    3. 测试执行后,进行充分度评估,包括:一次测试输入的测试参数组合是否充分?执行的覆盖情况是否充分?输出、断言、error 类型是否充分?从而更加全面的评估测试充分度。如果不充分,可以给出是哪一块不充分,需要提升,进而补充相应测试
  • 风险决策:针对风险控制后的风险遗留概率和风险发生可能造成的影响,给出测试建议,风险等级和决策结论,就可以根据决策结论和建议做相应的辅助/自动化操作
    1. 风险发生概率评估

一个测试任务,是否有风险以及风险发生概率的大小本质上是一个二分类算法,通过模型从历史数据自动学习经验,预测未来,模型输入的特征是风险引入跟风险移除的各种维度的特征灌给模型去学习,模型效果评估

  1. 风险决策给出评估结论

红色这一块是代表伤害事件发生可能性极大,并且任何情况都会出现,需要拦截
针对于会发生少量的伤害事件但是可能性极小的、或者压根就不会发生,但是在极少特定情况下可能会发生,这种就会通过,无人值守直接流转或者由 QA 确认之后再进行流转

④【综合保障】阿里 - 年年玩五福,五福质量保障怎么做
源链接:https://mp.weixin.qq.com/s/k66V0aBKoePs9JEYT6-1Bg
质量问题
当我们聊五福质量,实际在说怎么基于五福质量目标建设一套完备的质量保障体系,建设质量保障体系是为了达成质量既定的目标,所有业务的质量目标都可以用同一句话形容:线上不出问题,同时能提升质量效率,那什么是质量保障体系呢?
质量保障体系,顾名思义,说的是保障质量的一套体系,体系是不同维度组合而成的多维矩阵,质量保障体系是指围绕质量工作展开的多维矩阵,它贯穿研发流程始终,通过方案选型、策略决策、工具支撑、组织协同分工等,把过程中的一系列质量活动系统化、标准化、流程化,嵌入在研发流程中做执行。如果记不住的话,那就记住这个公式:质量保障体系=质量活动 + 工具平台 + 质量流程。
只要是对质量能够起到保障作用的工作事项,都可以认为是一项质量活动。好的质量保障体系一定要追求质量活动的工程化(工具化、平台化),工具平台解决纯人工做不了的,大幅提高执行效率。质量活动伴随贯穿研发流程的,质量活动之间的串联组合就是质量流程。质量流程结合研发流程定义了每个质量活动的时间节点,准入准出,执行标准,以此保证每个质量活动的效果,进而保证整个项目质量结果。质量流程还定义了质量活动的角色分工,开发、测试、产品、业务方都可能是某个质量活动的负责人。

方案介绍

  • 问题一:如何结合五福业务特点制定质量活动
    五福有多少风险,就有多少质量活动。质量活动一般可以从产品玩法、功能模块、技术栈实现、是否新技术应用、风险类型、具体风险,并结合引入环节等维度考虑。共性的可以抽出横向专项,业务特性的可以纵向攻克,如下两图。

  • 问题二:结合五福业务特性识别重复性工作,建设质量工具/平台
    质量目标中除线上不出问题外,还可以识别以往质量活动中重复性高、效率低的痛点,提前谋划建设相应质量工具/平台,提高质量活动执行效率。典型问题如下:

    • 广告素材保障提效——运营浏览验收素材图片 23 年五福无可让步更多的商家参与进来,在往年玩法基础上增加更多福卡广告资源位,广告素材进场数量多、时效性要求高、审核标准严格,纯人肉完成全流程审核工作量巨大。
  • 将素材生产链路统一,将不同来源过来的商业化素材提报链路统一接入到五福后台,由五福后台转换为五福服务端模型,并在五福后台进行管控。

  • 提供一套自动化渲染截图的流程,让审核同学在真机平台上直接看真机图片来完成审核,无需往年手动配置素材、扫码得卡、跳承接页、录屏上传等一系列操作。
    最终,每批次素材的会场验收均在 24h 内完成,运营真正做到只用坐在电脑旁浏览验收图片即可,能力明年还可复用。

    • 优化五福演练方案——演练效率更快点,深度更深点

通用演练流程

演练优化方案

1. 五福演练会引入集团内部用户参与,帮助项目组发现问题。历史上演练有时间段控制,一般是当天几个小时,演练、商业化验收不做白名单隔离,用一份大白名单混在一起,一旦演练时间结束,出于保密考虑会一刀切回收白名单,导致商业化生态验收受影响。23 年考虑白名单隔离,完全做到想验就验。
2. 建设易触达的演练入口来提升参与人数,基于埋点信息建设机型和功能页面覆盖情况的演练仪表盘清扫盲点,并在每一轮演练启动之前都定制好演练重点,引导好参与用户的演练目标。

  • 五福微灰度验证——灰度想验就验
    历史五福灰度只开放给签署过保密协议的项目组成员,非相关的应用会直接关闭灰度引流,这样会阻塞全站的灰度验证。在 SRE 的支持下,通过精细化路由规则实现用户流量的精准识别和路由,使得流量隔离灰度环境可以被动态创建并且不占用灰度渠道,不影响全站应用灰度验证的时间。

    • 问题三:紧贴五福研发模式制定质量流程

⑤【算法评测】阿里 - 蚂蚁搜推营销评测 - 智能化业务端到端评测平台(EVE)
源链接:https://mp.weixin.qq.com/s/vV9byfKaixTiz1sXf7QZ6g
质量问题
支付宝作为国民级别的 app,其中搜索、推荐、营销、广告等算法业务是十分关键的一环。面对蚂蚁域内算法业务效果风险高、业务对迭代效率要求高、ab 实验的验证效率低且有损、注重产品体验等特点,怎么去建设当前蚂蚁算法业务特点的效果验收能力,保障算法给业务带来的效果是好的?

方案介绍
建立了一套端到端的算法业务效果评估能力:

  • 大数据仿真评测 痛点:数据输入单薄、算法验收滞后、输出结果不明确、评价指标多样
    • 样本流量准备。不仅支持离线清洗的业务 T+1 线上请求,还支持线上实时日志请求的清洗,满足不同时效性要求的回放数据拆求
    • 大数据仿真评测引擎核心。按照业务需求对样本流量分层,将流量发送到业务算法平台,获取业务平台返回的仿真结果
    • 仿真评测指标报告。收集业务算法平台以及下游链路的处理日志,通过实时计算引擎实时产出指标数据。最终就可以用一套通用展现模板输出评估报告
  • 人工评测 痛点:指标表现不一定能代表真实体验、对于相同表现不同用户的主观体验有差异 整体思路:把线上海量的历史流量和通过大数据仿真评测得到的结果数据,转换为可以在端上渲染还原的数据 评测能力:
    • 标注对象 - 产品级别的可视化界面
    • 评估数据来源 - 平台提供可供直接发布任务的基础数据表(线上历史流量或大数据仿真评估结果)
    • 评估数据准备效率 - 产品级待标数据分钟级产出
    • 辅助标注信息 - 时空信息/用户画像/特征/行为数据等
  • 竞品评测 痛点:手动操作多个竞品、问题记录繁琐、数据分析效率低、竞品账号等资源不足 解决方案:
    • 搭建云真机实时渲染待评估的竞品 app,预装 app 和账号登录
    • 具备任务切换时操作自动化或最小人工化(自动完成搜索动作,标注人员只需要关注内容和标注)
    • 设计&配置标准格式的问卷,支持实时现场的截图与任务关联
    • 标注结果自动体系化分析&报表生成
    • 设备动态调度管理,保证稀缺账号机器资源优先供给对应的竞品评估任务

🤔 关于 “他山之石” 💭

  • 我们是谁?
    来自字节内部直播&开放平台的 QA 同学,非常业余的小编。

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

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

  • 频率怎么样?
    对内是两周一期,节假日顺延,每期约 5 篇文章;对外会做一些敏感内容的删减

如果觉得我的文章对您有用,请随意打赏。您的支持将鼓励我继续创作!
共收到 4 条回复 时间 点赞

点赞!这种汇总行业文章的方式很不错,而且汇总过程中的纪要总结,也是对这篇文章消化吸收的过程。

加油!

陈恒捷 回复

嘿嘿,谢谢,其实也是部门内部想要给大家传递知识的,只要没什么敏感的或者内部的内容,都是原文发转发过来 testerhome ~

看完之后感觉他们好厉害啊, 不符合常规的东西自己改造, 能力真强

换个角度想,只有业务有💰,组织有这个需求,就能找到专职干这些的人啦,各司其职。有时候测试同学要兼顾业务测试和测试开发,做得没这么深也是很正常的~

需要 登录 后方可回复, 如果你还没有账号请点击这里 注册