1.视频双方无法入会;
2.视频过程中黑屏;
3.视频中无法听到对方声音........

在我的理解里，这三个问题都属于主流程问题了，回归测试中是一定需要覆盖的。可不可以从问题产生的原因分析，看下是哪块漏了。我感觉是不是集成 SDK 的时候就要测试到不同系统/设备，而不是留到回归阶段～

音视频测试回归量太大

能否重新整理下回归用例，一些异常/难触发的点不要放在回归用例中，回归时选择的设备和系统尽量用线上用户占比前三的？

UI 自动化，怎么模拟双方的场景？

没有接触过，社区有类似的贴：https://testerhome.com/topics/33528

从反馈的问题类型来看，感觉普通的 UI 自动化测试也不一定能找得出来这类问题

如果使用 UI 自动化的话，应该就是启用两个 dirver，也就是需要初始化两台设备，就可以通过 driverA 模拟用户 1 操作，driverB 进行接受操作，来构成一个场景。
回到上面说的问题：我理解是稳定性的问题以及兼容性问题，其实不要放到回归测试处理，可以考虑设为一个专项。
（1）稳定性问题可以通过长时间的两台设备进行通话，同时监控设备资源，后端服务，出现问题时就可以结合数据分析与开发定位相关的问题了，假设首次保证 2 小时不间断，然后 4 小时，8 小时，可以阶段性的达到一些里程碑，可以有效保留冲劲。
（2）而兼容性问题不难，难是难在它的量很大，其实只要摆正心态，科学编排好计划，如定下来一个兼容的季度目标，，前期需要整理用户的主要消费群体的系统、版本等信息，通过真机，云真机的方式，确保这些这个季度什么版本的设备时 OK 的，后续再给相对没那么热门的设备进行编排，积极推动优化，计划细致，或许不那么难？

如果测试回归时是好的，线上有部分用户出问题，估计是 sdk 与手机系统的兼容问题，建议升级或降级 sdk

如果这个音视频 sdk 有没有专门的质量团队，如果有，那就对他们提要求。毕竟坑了你们这么多次，这些数据拿出来找那个团队的负责人一看，怎么说也还是有道理的；如果没有，那就真的只能自己搞了，这种东西就是要做自动化，UI 自动化只挑最重点最核心的基本功能去做，限制成本；重点在接口自动化上多做一些事情，成本相对更低，用例也更稳定可靠。

关于 “模拟双方的场景”，我理解就是有多账号互动的过程，一般来说这类自动化要做一个中间模块来进行多方管理，作用是分别给多个账号下发指令让他们按顺序去做一些事情，实际上相当于一个调度模块。