拉丁看雪用户2447
质量专栏“他山之石” - 第一期
输入“/”快速插入内容
质量专栏“他山之石” - 第一期
质量专栏“他山之石” - 第一期
用户2447用户24472023年5月27日修改
🔹 期刊内容 🔹
①【UI自动化】美团-App页面视图可测性改造实践
质量问题
美团 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客户端长链消息业务性能测试实践
质量问题
B 站直播业务飞速发展，从 LOL S赛到跨晚直播、传统节目拜年纪，高流量直播互动节目对直播间看端性能和质量提出了更高要求。直播间会并存弹幕、进场提醒、全屏礼物动画、连击礼物等，如果终端性能跟不上，丰富的玩法和特效反而会拉低用户体验，营收效果也会打折扣。针对上述实时互动能力的质量保障，有以下难点：
1.
场景构造链路太长，耗时耗力：测试各类广播在直播间效果以往的手段需要多端配合且依赖账户数据，以触发“大航海特效”为例：先使用推流工具开播，终端 A 登录账号进入直播间送出礼物，终端 B 进入直播间，A、B 分别收到主客态广播，最终触发礼物特效；
2.
异常数据构造能力缺失：广播内容完全由服务端下发，无法模拟接口各个字段的异常情况，广播容错测试完全空白；
3.
性能测试效率低下：广播测试从传统的端到端功能维度去测试，性能不能解耦开来关注，缺乏对端的消费能力、性能、体验的针对性测试，都需要投入大量人力进行手工回归，卡顿、闪退、发热等体验问题频发；
4.
测试资产（各类测试资源与配置）复用困难：直播的广播消息类型经过数年迭代，有超过 100+ 消息类型，测试资产积累靠文档相传；
方案介绍
实现了一套面向终端消费场景的直播间广播压测工具链，并平台化为“广播压测平台”，大幅提升直播间整体质量与专项测试效率，并沉淀下来直播间复杂广播场景下性能测试的最佳实践。方案主体如下：
广播压测系统架构图
1.
广播消息元数据收集：通过对 broadcast-proxy 广播日志的全采样，经过处理归档为有序的广播回放文件，可以通过平台手动改变广播体中部分字段内容方便构造异常数据，提供自定义标签管理。
2.
压测任务配置及场景编排：直播间压测根据需求可自由配置不同广播组合及 QPS。平时测试需求会形成一个个的单元测试场景的配置，支持将单元测试场景组合在一起形成一个测试任务。