研发效能音视频 SDK 如何进行自动化测试

小曾同学.com · 2024年02月01日 · 最后由小曾同学.com 回复于 2024年07月18日 · 6542 次阅读

目前音视频各端全部是手工测试，人手也不够，每次两个人忙的要死，制定的 OKR 也没有完成，（衰）。也看了网上一些音视频方面的自动化测试方案，但是鄙人不才，仍有些许疑问，不知具体该如何实施，固在此想请教一些具体实战经验，包括音视频功能、性能自动化，大佬们都是怎么做自动化测试的，想学习下。救救孩子吧。（之前有看到一个小伙伴用的 monkeyrunner+ 日志，我去先实践下。）

共收到 14 条回复时间点赞

今晚打老虎 #1 · 2024年02月02日

能不能说下你期望实现的具体功能场景

one.way #2 · 2024年02月02日

论坛搜索 "SDK 测试" 一堆大佬的实战经验.

王稀饭 #12 · 2024年02月02日

和 RTC SDK 的同学有过一些交流，应该比较接近你说的音视频 SDK，下面观点仅代表我自己的理解。

基本测试 Demo

SDK 最基本的测试方法是写 Demo 调用 SDK 接口去测试，我不清楚楼主提到的【各端全部是手工测试】具体是什么情况，对应的宿主又是啥。

按照我的理解，应该要实现不同端的 Demo，在 Demo 中直接调用 SDK 接口，提供不同的入参以及制造不同的场景，从而实现 SDK 某接口的测试用例。这样算是 SDK 的基本功能测试。

这些测试用例中，有部分是可以轻松自动化的，有部分是可自动化但是需要一些 UI 技术的，有部分是完全无法自动化需要人工操作&断言的，分开来看就好。

性能测试也是差不多，先明确 SDK 接口的性能测试场景，然后围绕 Demo 去实现这个测试场景就是了。

注，SDK 本身也会涉及服务端请求，看你关不关注服务端的质量，关注的话要进一步拓展，上面只说 SDK 客户端。

关于断言

前面说的 Demo 可以理解为测试工具的形态，测试断言是 Demo 里需要重点考虑的一部分。

常见的断言有：接口返回断言、日志断言、数据库断言、埋点数据上报断言、音视频频断言。前四者是明确可以全自动化的，只有音视频断言自动化难度高一些，要引入一些算法来检测音视频质量，如果没有条件那就换人工断言。

完

以上是比较常规的整体建设思路，当然【monkeyrunner + 日志】也算是一种方式，具体看能投入建设的人力和必要性如何。匹配测试人力，能抓到 bug 解决质量问题的建设就是最好的建设。

小曾同学.com #11 · 2024年02月04日 Author

对

王稀饭回复

感谢大佬解答，目前现状是各端针对 SDK 会分别写好一个 Demo，每次提测时，只需要针对 Demo 点点点，但是每次这样耗时耗力，今天看到大佬提供的思路，突然想到可以先对经常回归的一些测试场景做 UI 自动化，然后空闲时再把对 SDK API 进行封装，做成一个测试 Demo，通过服务下发通知，自动跑自动化。

小曾同学.com #10 · 2024年02月04日 Author

对

one.way 回复

感谢大佬，目前搜了一些，云里雾里的，还需要继续实战

小曾同学.com #9 · 2024年02月04日 Author

对

今晚打老虎回复

听过一些大厂针对 SDK 自动化测试，可以测功能、性能等，不知道如何入手，目前也在调研这方面内容，希望可以有所突破，希望大佬们指点迷经。

王稀饭 #8 · 2024年02月04日

对

小曾同学.com 回复

你可以再详细描述一下你的现状。按照目前我获得的信息，我的更多建议：

信息 1：有了 Demo 后，SDK 接口的测试，转化成面向 Demo 的手工点点点

如果用例明确可以自动化，你可以在启动 Demo 的时候就自动触发这些用例的运行与断言，或者设置一个按钮一键把所有自动化用例运行起来，免去人工点击才触发用例运行，从而提升执行效率。

信息 2：【突然想到可以先对经常回归的一些测试场景做 UI 自动化，然后空闲时再把对 SDK API 进行封装，做成一个测试 Demo，通过服务下发通知，自动跑自动化】

单纯靠这些信息我推断不出来你们现有的 Demo 是什么形态，是不是我理解的类似于 App 的感觉；也不知道你这里说的 UI 自动化，是解决触发 Demo 运行用例的问题呢？还是解决某些测试场景就是要 UI 点击才能完整跑完的问题？如果是前者，看上面我的建议；如果是后者，引入 UI 自动化是可行的，不过经验上稳定性会很低，要谨慎考虑。