目前音视频各端全部是手工测试，人手也不够，每次两个人忙的要死，制定的 OKR 也没有完成，（衰）。也看了网上一些音视频方面的自动化测试方案，但是鄙人不才，仍有些许疑问，不知具体该如何实施，固在此想请教一些具体实战经验，包括音视频功能、性能自动化，大佬们都是怎么做自动化测试的，想学习下。救救孩子吧。（之前有看到一个小伙伴用的 monkeyrunner+ 日志，我去先实践下。）
能不能说下你期望实现的具体功能场景
论坛搜索 "SDK 测试" 一堆大佬的实战经验.
和 RTC SDK 的同学有过一些交流，应该比较接近你说的音视频 SDK，下面观点仅代表我自己的理解。
基本测试 Demo
SDK 最基本的测试方法是写 Demo 调用 SDK 接口去测试，我不清楚楼主提到的【各端全部是手工测试】具体是什么情况，对应的宿主又是啥。
按照我的理解，应该要实现不同端的 Demo，在 Demo 中直接调用 SDK 接口，提供不同的入参以及制造不同的场景，从而实现 SDK 某接口的测试用例。这样算是 SDK 的基本功能测试。
这些测试用例中，有部分是可以轻松自动化的，有部分是可自动化但是需要一些 UI 技术的，有部分是完全无法自动化需要人工操作&断言的，分开来看就好。
性能测试也是差不多，先明确 SDK 接口的性能测试场景，然后围绕 Demo 去实现这个测试场景就是了。
注，SDK 本身也会涉及服务端请求，看你关不关注服务端的质量，关注的话要进一步拓展，上面只说 SDK 客户端。
关于断言
前面说的 Demo 可以理解为测试工具的形态，测试断言是 Demo 里需要重点考虑的一部分。
常见的断言有：接口返回断言、日志断言、数据库断言、埋点数据上报断言、音视频频断言。前四者是明确可以全自动化的，只有音视频断言自动化难度高一些，要引入一些算法来检测音视频质量，如果没有条件那就换人工断言。
完
以上是比较常规的整体建设思路，当然【monkeyrunner + 日志】也算是一种方式，具体看能投入建设的人力和必要性如何。匹配测试人力，能抓到 bug 解决质量问题的建设就是最好的建设。
王稀饭
回复
感谢大佬解答，目前现状是各端针对 SDK 会分别写好一个 Demo，每次提测时，只需要针对 Demo 点点点，但是每次这样耗时耗力，今天看到大佬提供的思路，突然想到可以先对经常回归的一些测试场景做 UI 自动化，然后空闲时再把对 SDK API 进行封装，做成一个测试 Demo，通过服务下发通知，自动跑自动化。
今晚打老虎
回复
听过一些大厂针对 SDK 自动化测试，可以测功能、性能等，不知道如何入手，目前也在调研这方面内容，希望可以有所突破，希望大佬们指点迷经。
小曾同学.com
回复
你可以再详细描述一下你的现状。按照目前我获得的信息，我的更多建议：
信息 1：有了 Demo 后，SDK 接口的测试，转化成面向 Demo 的手工点点点
如果用例明确可以自动化，你可以在启动 Demo 的时候就自动触发这些用例的运行与断言，或者设置一个按钮一键把所有自动化用例运行起来，免去人工点击才触发用例运行，从而提升执行效率。
信息 2：【突然想到可以先对经常回归的一些测试场景做 UI 自动化，然后空闲时再把对 SDK API 进行封装，做成一个测试 Demo，通过服务下发通知，自动跑自动化】
单纯靠这些信息我推断不出来你们现有的 Demo 是什么形态，是不是我理解的类似于 App 的感觉；也不知道你这里说的 UI 自动化，是解决触发 Demo 运行用例的问题呢？还是解决某些测试场景就是要 UI 点击才能完整跑完的问题？如果是前者，看上面我的建议；如果是后者，引入 UI 自动化是可行的，不过经验上稳定性会很低，要谨慎考虑。
我们组用的是 Airtest 写的框架 不过也只是用于日常测试稳定性 音视频的自动化 主要还是声音跟视频，目前我们还是靠人工
看问题，主要是要测什么？功能还是性能或者音视频质量？
对于自动化测试来说，任何场景的代码都是输入和输出，主要是结合场景选好点。