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是否正常。要每次提交都能跑一遍这些功能,证明是