场景实练｜直播课程怎么测？

作为一个底层基础设置质量保障人员，更多的是和底层服务打交道，端上的这类场景接触偏少，最近刚好有这样一个机会去支援了下这个迭代。在支援过程中，发现需求虽小，需要关注的点却不少呢，请听我细细道来，与此同时，你也可以自己先思下，如果是你，你拿到这个需求后，会关注哪些方面呢？

背景是某学习平台需要通过直播将政策知识更多的传播给不同的用户，现在因为支持新特性A，需要重新打包安装验证，此时你来支援这个需求，你会从那几个方面去考虑呢？

我说下的我的做法：先明特性，再三步走。
这里说的 【明特性】 是第一时间需要明确区分出，直播客户端这类的测试和过往的web 系统测试是有差异的，因为直播客户端对硬件资源的依赖会很重，是否会阻塞业务流程及影响直播稳定性，这个要有警觉，不然很容易出现客户事故。而后续的三步走是在第一步认识的基础上，补齐当前的信息，以便于后续我们可以更好的验证。这里的三步走分别是：知过去、明现状、预未来。

先来看看第一步：知过去。意味着我们需要了解当前系统这块支持的能力边界有哪些？每一种的效果都是怎样？这样后续在验证的时候有一个对标物，能很容易对焦大家的认知，减少后续的沟通成本。

第二步明现状是要清晰知道当前的处理方式的影响面，包括：客户群体、业务功能、是否涉及历史数据及是否影响了已有功能及对不同安装端的影响等，判断回归范围。

第三步是在前两步获取的信息基础上，按照真实的业务场景去测验，比如主播 A 在直播，游客 B 去观看，看是否有影响及整个回归的过程是否可通过其他手段覆盖，提高验证效率。

再具象化一些，验证点如下：
1、客户端界面样式，这个对用户是最直观的体现，是否有错乱/重叠等
2、客户端基础功能回归验证
3、客户端的兼容性验证，比如 mac、windows不同系统，及不同的声卡，摄像头及其外接等场景，或者声卡驱动升级，系统升级之类对它的影响
4、结合业务做相关的流程验证，比如一场直播 A 在直播且未暂停/退出的情况主播 B 是不能访问的

另外，在对外提供的客户端包的时候，相关错误日志收集尽量具备，因为客户的电脑没办法穷举，有些问题遇到后，可直接根据日志去协助排查定位，能更快速响应及解决。

以上是我最近的想法，共勉。