移动测试开发 移动广告 SDK 测试思路

opentest-oper@360.cn · 2022年03月31日 · 最后由 罗汉 回复于 2022年07月09日 · 27268 次阅读
本帖已被设为精华帖!

一、什么是移动广告 SDK

移动广告 SDK 是嵌入到宿主 APP 中的一个 jar 或 aar 包,其提供了一系列 API 供开发者调用。这些 API 可以进行广告请求、广告打点等行为,可以对广告进行渲染。开发者只需要关注自身 App 的开发,广告逻辑全部交给广告 SDK 实现。广告 SDK 和应用之间关系是什么呢?以公司内部广告 SDK 为例,如下图所示,应用 APP 通过调用广告 SDK 接口,进行广告的展示等操作。

二、广告 SDK 测试对象有哪些

广告 SDK 是为第三方开发者提供的软件开发工具包,包括接入文档、SDK 接口、以及 Sample 等。因此测试的主要内容有:

1. 接入文档:

SDK 面向的是开发者,正确引导开发者接入 SDK 是必要的。

2. SDK 接口:

SDK 的核心内容,也是主要测试对象。

3. SDK 日志:

对开发者来说,SDK 接口里面的具体实现是透明的,当上层调用时遇到问题,只能依赖 SDK 打印的日志来定位分析。所以 SDK 日志是否完备,是否有助于解决问题,对应用开发者、测试人员和 SDK 提供方来说都很重要。

4. Sample:

Sample 是 SDK 提供方用来示例如何调用接口实现具体的功能,也可以作为开发者直观感受 SDK 接入效果。

三、广告 SDK 接口测试类型有哪些

广告 SDK 根据需求和开发平台不同,可能需要选择不同的测试类型对 SDK 接口进行测试,常用的测试类型有:

1. 功能测试:

需保证 SDK 接口功能正确性和完备性,包括场景覆盖和接口参数覆盖等。主要测试在不同场景下功能逻辑是否按照预期实现,返回开发者是否有回调且顺序是否正确。

2. 兼容性测试:

确保 SDK 兼容特定的设备平台,并与其他软件兼容,没有内存泄漏和闪退崩溃现象。
兼容测试的工作量通常是比较大的,可根据产品需求和市场现状对需要适配的设备机型做分析,覆盖的机型、系统版本、分辨率等进行优先覆盖排序。
SDK 兼容性测试还需要考虑媒体是否对 support.V4/V7 包、Android x、versioncode 最低和最高版本等支持。

3. 网络相关测试:

在不同网络环境和类型下,SDK 接口都能较好的处理。在涉及到下载和视频广告时,弱网通常通过 Fiddler/Charles 工具模拟;网络切换、sim 卡欠费等情况也是关注重点。

4. 安全性测试:

随着国家对隐私数据保护,访问权限的控制,用户服务鉴权等越来越严格,安全测试也是重要部分,例如移除 imsi 和 android ID 等字段,增加下载类广告隐私信息协议等。SDK 接口的安全性也如此,发版前需提交到安全部门进行安全审核。

5. 稳定性测试:

确保场景在一定压力下,持续运行一定时间,有无异常。广告 SDK 在信息流场景中,保证广告展示和点击时设备资源有无异常,正在通过 Maxim 进行测试。

6. 性能测试:

保证 SDK 接口满足特定的性能需求,比如资源占用、移动设备耗电量等。在广告 SDK 开屏广告请求时长过长时会导致应用启动慢或者卡顿,所以测试时需要考虑这个场景性能。

四、SDK 功能测试

上述诸多测试类型中,功能测试先行。在进行广告 SDK 测试前,需要全面的了解测试对象的细节:

  1. 了解业务流程,结合 API 接口文档和开发指南,理顺接口的使用场景和调用关系;
  2. 了解 SDK 协议,理解协议中字段的意义;
  3. 了解各接口或协议返回码,分析对应的场景;
  4. 了解开发实现细节,可以绘制成图,便于测试分析和分层验证。

对广告 SDK 进行测试,可以采用的分层测试方式由上至下依次有:基于 Demo ->基于 SDK 接口调用 ->基于代码。

1. 基于 Demo

广告 SDK 提测时,通过 Demo 模拟开发者接入,并覆盖对应的接口和业务场景。测试同学根据 Demo 界面上广告类型很容易 mock 出自己想要的测试广告,这种方案优点是上手快且较常用;缺点是对业务场景类型覆盖有限,发现问题时需首先判断是否是 Demo 问题,为满足上述需要,需投入较大精力开发维护 Demo。此方案适用于手工或者 UI 层自动化测试。

2. 基于 Demo 的 UI 打点自动化测试

根据广告 SDK 的特性,有大量重复工作在于打点数据校验,并且 SDK 与服务端交互的协议稳定。同时有多个 SDK 业务,从自身业务出发,形成 SDK 自动化测试解决方案,结构图如下:

基于以上方案,大大节省了打点数据校验工作的人力和时间。

3. 基于 SDK 接口调用

随着第三方 SDK 迭代频繁,面临着回归工作量大,不同媒体的定制需求,根据以上问题探索出 SDK 接口自动化测试方法。
①. 首先将待测 SDK 集成到 demo 中,其内置一个 HttpServer
②. demo 启动时反射扫描待测 SDK 的类
③. 发送 HTTP 请求到 demo 的 server 中,server 反射调用 SDK 对应的接口
④. 然后通过自动化方式测试在各种参数组合覆盖下接口的返回值做断言以判断健壮性。以下是结构图:

基于接口调用自动化测试,在测试效率和人力的收益很大。

4. 基于代码

业务压力增加导致已没有充足的人力对每次的大小提测都进行全量回归;其次应对不同的接入媒体而分为好多渠道包,各个渠道包间的代码相似度很大,如果选择性测试,就需要测试人员对测试代码进行准确性的把握。基于上述原因,我们在业务中边摸索边实践边丰富,便有了精准测试平台。平台分为以下几个端:
①. server 端:核心功能是实时计算以及数据整理
②. plugin 端:核心功能是原始数据收集以及非实时计算,主要用于流水线中
③. cli-server 端:核心功能是原始数据采集,主要用于 java 开发的 aspring 服务
④. cli-android 端:核心功能是原始数据采集,主要用于 java 开发的 android 应用
方案图如下:

业务中应用 50+ 个版本中,在用例反推和提高开发质量等方面有重要价值。

本文主要介绍了广告 SDK 测试的一些思路,希望能给大家提供一些参考。如果您有关于 SDK 的其他测试方法,欢迎共同交流。

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

可以可以 我们也有埋点自动化 互相交流交流

kingTester 回复

不完全是点点点啊,比如打点自动化那块确实是可以提效的。

mark 一下,sdk 测试

同行,同方向😁

好像也没写出啥,SDK 的内部逻辑是不透明的,也就是说只能点点点

Taoism 回复

感谢指正。用不透明或者黑盒更好些。

对开发者来说,SDK 接口里面的具体实现是透明的

应该是 不透明 的

mark 一下,可以借鉴。

49875183 将本帖设为了精华贴 04月02日 10:38
需要 登录 后方可回复, 如果你还没有账号请点击这里 注册