【融云分析】SDK 交付质量保障之自动化测试
自动化测试的意义
很多测试人员说到自动化测试领域，反应就是的接口自动化、Web 自动化、APP 自动化、Selenium、Appium 等等。其实这些都是针对于测试工作，用来解决问题时已经比较成熟的工具或方案，相信随着自动化领域的发展，对应自动化测试工具，方案也会越来越丰富。
相对于手工测试而言，自动化测试本质上还是使用代码或者工具，把复杂的测试工作从手动转化成为机器自动执行。优秀的框架、工具可以借鉴使用，但也不要过于局限于现有工具和框架，而应根据自身产品特性和架构特性，寻找适合当前产品的自动化测试解决方案才是合理的自动化测试。
融云自动化测试实践
以融云的业务为例，在融云实时音视频 SDK 的质量保证上，有大量的测试点需要关注，例如：噪声啸叫抑制、回声消除、清晰度、首帧速度、移动端性能、耗电量、流量控制、延时、丢包等。
除了上述音视频质量检测以外，对于一个 SDK 基础服务来说，还有些需要重点关注的指标就是连通率指标，连通速度指标。而且该指标想达到 99.9% 以上的标准，那么针对每个功能修改，版本发布，测试次数需要数千次数万次的成功连通测试才能验证。
一、保障实时音视频 SDK 质量应具备的条件
音视频 SDK 测试需要测试不同厂商的客户端设备，对 SDK 画面渲染、稳定性、视音频连通等各种表现情况。因此我们还需要在单元测试的基础上，引入移动端，web 端的自动化测试检查客户端的具体表现能力。
1. 测试框架及工具的整合，建立稳定的 UI 自动化测试脚本
Appium & Selenium 作为测试框架，可以支持iOS，Android，Chrome，Firefox 等多种驱动。并且无需对测试应用做任何嵌入式的修改，开源社区也相对活跃，作为UI自动化测试是一个比较好的选择。Python + Pytest 作为快速开发的语言和单元测试框架，可以提升测试脚本整体开发效率。
下面是 Appium & Selenium 基本工作原理：
接触过 UI 自动化的同学，很多都会觉得 UI 自动化测试相对于接口、单元测试来说并不稳，尤其是遇到长时间运行几十个小时、几千上万条用例时，稳定性阻碍使用的一大难题，我们针对一些经常出现的问题进行解决。
- 元素不定期出现变化
对于元素不定期变化的问题，与团队进行沟通协调当然必不可少，也是最容易解决问题的方法，当然还有很多其他方式。
Page Object 设计模式对于 UI 测试来说就是一个不错的选择，Python3 有个升级就是全面 Unicode化，也就是可以使用用中文命名变量，对于页面静态变量这种元素修改、查错来说效率还是可以提高不少。例如：
- 设备断开 & 网络异常
设备断开这个应该是阻断 UI 自动化经常出现的问题了，数据线闪断、客户端服务 Crash、远程连接网络异常等，这时候重连机制就尤为重要了。针对这个问题我们可以给每个用例加增加装饰器函数，如果用例失败并且检测到断开则立即重连；也可以用 Pytest 内置钩子函数使用方法检测断开重连，示例：
- 意外弹窗问题
很多厂商设备在你运行用例的时候，经常会弹出个窗口，这是非常头痛的，但是基本上所有的弹出按钮都是 Android: //android.widget.Button，iOS: //XCUIElementTypeButton 两种类型的 xpath。因此我们只需要在报错时，获取页面上所有这两种类型的文本处理一下即可，尽量不堵塞后续用例的运行。简单示例：
- 良好的测试用例设计
无论是从事何职的测试人员，测试用例设计都应该是关注的重点，一个好的自动化测试用例设计可以发现更多的问题，也可以让用例运行更加稳定。
2. 提供多样丰富的测试数据，不放过每一次问题
在我们运行自动化测试时，检测到崩溃、黑屏、绿屏、花屏等异常错误的时候，需要尽可能地提供详细测试报告数据才能更加准确地定位问题。
- 移动端关键错误截图和日志
自动化测试的报错截图，比较好获取，但是日志内容是客户端查询的关键。ADB 或者 idevicesyslog 等工具虽然可以获取到手机日志，但是在脚本运行过程中，不容易精确定位并截取到到测试用例开始到结束这段时间日志内容。
实际上 Appium 会自带日志缓冲区，在脚本运行的时，Appium 工具会将移动端日志写入日志缓冲区。但是Appium 并没有提供 API 修改缓冲区大小，也无法筛选关键日志，因此我们针对 appium-xcuitest-driver、appium-android-driver、appium-adb 等库进行了符合自己产品需求的修改，可以进行日志过滤筛选，主动触发清理缓冲区，使定位问题更加精确，测试报告更加完善。
- 移动端关键错误网络抓包
遇到错误时，网络交互数据也是检查错误的重要数据，我们需要利用 Wireshark 工具进行抓包截取部分网络抓包数据，针对 iOS 设备可以用 rvictl 命令 生成虚拟网卡，Android 设备则需要使用共享 Wifi 模式。之后利用 Wireshark 的 dumpcap 指定网卡和筛选数据。同日志抓取一样，通过钩子函数我们要在用例开始和结束时精确地定位到错误区间，并将抓包数据添加到测试报告中，提供给相关人员排查依据。
3. 测试任务调度平台
测试平台有主要分发测试任务和运行自动化测试任务两种。我们希望测试人员无需部署任何环境或者进行简单部署，就可以快速接入平台运行自动化测试，查看测试报告。不需要限定固定的移动设备来连接在固定机器上执行自动化测试。
上图我们针对 Android 可以使用 ADB server 服务器。自动化测试测试脚本和 Appium 服务器利用 ADB 传输协议，通过局域网链接子节点 Agent 服务进行测试，这样可以让设备不受限制，连接局域网任意本人或者空闲电脑，运行子节点 Agent 即可立即运行自动化测试，空闲设备利用起来，我们就有了庞大的测试机器群了，使设备即插即用使用率最大化。
但是 iOS 系统特性限制，虽然有 WiFi 共享模式，但使用起来稳定性并不友好。因此需要在 MAC Agent机器上环境部署本地的 Appium 等相关服务，设备直连该机器通过平台执行自动化测试，
二、移动端 IM SDK，要做到接口全覆盖测试
客户端 SDK 是为第三方开发者提供的软件开发工具包，以工具包的形式集成在 App 内，一个 App 内可能包含了多个 SDK 工具包。一个 SDK 对外发布后，我们可以建议开发者如何调用 SDK，但是无法预计开发者怎样调用 SDK 的接口。因此一个稳定的 SDK 工具包就显得尤为重要。
- SDK 接口要做到全字段校验才能保证稳定性。
SDK 测试方法中，单元测试虽然可以更加的高效和稳定，但是单元测试无法轻松地在不同的设备上范围性运行，也无法针对打包集成后 SDK 包的功能进行检测，从而无法检测 SDK 在各大应用设备上的集成表现以及开发者在集成时候所遇到的问题。
- IM SDK 自动化测试解决方案。
做自动化测试，主要解决的问题是：
- 核心通信能力尽可能的脱离 UI 自动化测试，做到快速迭代的能力；
- 可以任意对 SDK 接口字段进行自由组合校验；
- 可以测试覆盖单设备多应用测试场景。
由上图可看出基本结构并不复杂，主要是根据约定 JSON 格式和 Demo 层中的 Server 进行通信，Server Demo 通过反射或者自定义等方式调用 IM SDK 的接口，这样使我们可以对SDK 的接口参数进行自由的组合，从而验证 SDK 在复杂的测试用例中，是否能保证产品质量的稳定性和异常参数回调的友好提示等。
打包后的IM SDK 自动化测试，使移动端 IM SDK 基础服务不再只依赖于 UI 层的 Demo 测试，可测试范围和版本回归效率能提升数十倍。
自动化测试的测试成本&预期收益平衡
软硬件行业自动化趋势在近年来愈发明显，当然自动化测试也随之一步步更加成熟，但是要做自动化测试，肯定要考虑测试成本和预期的收益。
虽然自动化测试可以在任何时候都可以自动运行，看似节省了时间，但是需要考虑到自动化脚本前期开发的时间成本和后期脚本的维护成本，而且自动化效率较为依赖用例设计，自动化测试用例的开发工作量有时会比手工测试的工作量还要大。项目开发周期短、业务新、测试业务主观性很强等类型的产品要慎重考虑。
自动化测试能带来哪些收益也是大家最关心的，自动化测试一个重要的特性就是一致性，它不会随着时间增长出现由于人的疲劳所带来的漏测、漏记，可增加版本发布的信任。由于测试是自动执行的，所以执行过程中极少会出现疏忽错误，当然这也取决于自动化测试脚本的设计质量。
在立项初期如果考虑使用自动化测试，一定要考虑清楚自动化测试目标是什么，用自动化测试来解决什么问题，如果想用自动化测试来节省人力成本显然是不合适的，自动化测试的首要目标应当是如何提高产品的质量。
以上就是融云在自动化测试实践中的一些所感所得，我们将其记录和整理，并与大家分享，也欢迎更多的技术小伙伴与我们一起探讨。
最新活动推荐：
