孙勇男：实时视频 SDK 黑盒测试架构丨Dev for Dev 专栏

Posted 2022-06-08 声网

Dev for Dev 专栏全称为 Developer for Developer，该专栏是声网与 RTC 开发者社区共同发起的开发者互动创新实践活动。透过工程师视角的技术分享、交流碰撞、项目共建等多种形式，汇聚开发者的力量，挖掘和传递最具价值的技术内容和项目，全面释放技术的创造力。

本文为专栏系列内容，作者为声网音视频实验室工程师孙勇男。

什么是测试自动化框架

测试自动化框架是为自动化测试用例或者脚本提供执行环境而搭建的基础设施。自动化测试框架为用户提供了各种好处，可帮助他们有效地开发、执行和报告自动化测试用例。自动化测试框架更像是专门为自动化测试而创建的一套系统。用一种非常简单的语言，也可以说框架是各种编码标准、测试过程、工作实践、项目层次结构、模块化、报告机制、测试数据注入等支持自动化测试的功能的极大融合。

自动化测试框架的类型

现在我们对自动化框架有了基本的了解，让我们看一下现在流行的各种类型的测试自动化框架。这些框架可能基于对不同关键因素（例如驱动类型、可重用性、易于维护等）进行自动化的支持而彼此不同。

● 基于模块的自动化测试框架

● 仓库架构自动化测试框架

● 数据驱动自动化测试框架

● 关键字驱动自动化测试框架

● 黑盒混合自动化测试框架

● 行为驱动自动化测试框架

为什么选用黑盒混合自动化测试框架测试 SDK

所谓黑盒，即提供给业务测试人员无需考虑程序内部结构和内部特性的情况下，在程序接口输入测试的参数并选择输出项，通过程序内部混合测试框架得到相应的结果，使用者只需关心输入与输出。

场景设计初衷

“自动化是为了更好的解放双手，追求更高的效率”

与互联网软件(app、web)的测试有所不同的是，简单来说实时视频SDK测试几乎不需要点点点，基本是通过自研自动化工具完成端与端间经过自定义网络损伤后的视频通信，并采集端上 SDK log 作为测试产出数据，客观测试数据即客观测试结果。围绕并以此通过结合实际业务需求，去离"Code based automation"，根据业务测试以平台化、模块化来提供解决方案，从而提供更多的测试维度、减少重复体力劳动和效率瓶颈问题。

01 解决方案架构简述

基础建设方案

● 采用 CI 集群+测试工具及自动化测试框架 +数据平台化

支撑 daily、发版测试、开发自测的测试工作

● 具体模块功能简述

落地机房实景

● 多套测试节点支撑整个视频客观发版业务线

02 基于自动化测试维度的思考简述

逐步完善自动化闭环

通常我们在做自动化测试过程中通常先完成“执行测试”这一步骤，然而这只是相对自动化的一部分，我个人理解的自动化闭环优点不局限于"输入便捷性灵、测试覆盖性全、测试避障性强、输出聚合性高"，更多的站在整个链路逐步突破测试精准性和效率瓶颈。

下面是我们在测试避障性和输出聚合性模块中的举例:

举例1 时段网络波动影响

在生活中使用聊天软件视频时，往往会因为网络突发波动造成突然的卡顿或者或者画面模糊，波动幅度和时间都具有不确定性，对于实时视频 SDK 的测试也会遇到这样的问题，虽然我们尽力保证网络环境的稳定，但是在长时间的测试过程中也经常会遇到诸如此类问题，影响我们的测试数据。

如何在测试过程中降低因网络波动造成的数据误差？

● 利用漏斗式重跑筛选方式，简要结构如图所示

即循环求值保证在设定误差内有效降低因为网络波动影响 SDK 版本测试数据。

举例2 版本数据波动影响力采据

在完成自动化测试后对于测试版本间或者与 release 版本各项体验指标数据上，一般是通过报告间数字的差异，但随着体验指标的增加，往往我们更迫切需要多个版本精确到端到端上某个指标上的差异性感知质量可视化。

● 后台管理系统-客观报告模块

支持多版本报告对比的case、devices、体验指标等求值动态视图

目前这种客观报告的视图形式虽然暂时满足了我们对自动化报告指标数据上的取证对比需求，但是在数据的梳理和合成功能还需要更加切入业务的理解。

03 总结

相对不同业务的框架并没有什么官方的标准，而是紧贴实际业务需求，搭配适用性高的主流框架或者自研框架集成到整个测试架构来提供解决方案。操作者可能为开发可能为测试，大家技术线有所不同，作为相对"黑盒"使用者暂不需要知道他的原理构造，仅需清楚了解能为自己在最短时间解决工作上的问题即是黑盒测试框架的价值。