SRS单元测试、覆盖率和自动回归怎么做

SRS支持了单元测试、覆盖率分析、自动回归测试。每次提交，每个PullRequest，每次合并，都会触发测试。

这是这么些年一直想做，却一直没时间做的事，是极其重要的事情。

为什么？我们看WebRTC真正的大佬怎么说：

WebRTC PC 最大的一个挑战就是它包含了太多的能力，
。。。，可以发现对它的覆盖率远远不够，即使我们不要求完整覆盖，
而只考虑 “可接受” 的覆盖率，也非常的困难。
​
我在 RTC 领域中，碰到的最大的挑战之一，就是海量的测试用例。。。
即使要达到 95% 的覆盖也是非常的有挑战的。当然完整的测试非常有帮助，
我们当然也要考虑完整覆盖带来的巨大挑战，真的非常的难。

Bernard Aboba, W3C WebRTC Chair, WebRTC 的现状和未来

目前比较好的开源项目，都会有单元测试和覆盖率，但还比较少有场景化的回归测试，自动回归测试就更少了。RTC由于场景的复杂性，自动回归测试就更加难做了。解释下这几个东西：

• 单元测试（UTest）：白盒测试，测试单元是函数，包括公开函数和私有函数，验证函数的输入和输出。听起来有点傻，这不是自己写代码证明自己的合理性么？能管用吗？如果是认真写的UTest，可以负责任的说，灰常管用；因为函数的输入输出保证，并不仅仅是保障写的时候符合逻辑（又有多少代码真的符合预期？），更重要的是保障后续修改不出错。

• 覆盖率（Coverage）：一般是跑UTest后，看UTest覆盖了多少代码，由于UTest有些逻辑是跑不到的，比如main函数的逻辑，比如网络IO的逻辑（一般UTest要求不依赖系统环境），所以覆盖率不可能达到100%，参考：测试覆盖率，应该多少比较合适？。覆盖率有没有用，可以负责人的说，灰常管用，大部分线上问题都是没有跑到过的路径出现的问题，也就是未覆盖的代码引起的问题。

• 自动回归测试（Regression）：这并没有什么高深的（也有可能是我理解不到位），就是模拟真实场景跑一跑。每次我们改完代码都会把程序跑起来，看看是不是改坏了。问题是在于，如何能把所有功能都跑到，比如直播里面的推流和播放是基本的，还需要加上边缘，考虑录制，还有多种协议，最好是每次提交，都能把这些功能跑一遍。如果是直播和RTC都支持，那就是X2的测试矩阵，比如直播转RTC是否正常。要每次提交都能跑一遍这些功能，证明是符合预期的&