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是否正常。要每次提交都能跑一遍这些功能，证明是符合预期的，其实还是很难做到的，对吧？参考SB: Regression。
• 压力测试（Benchmark）：如果想知道某种场景下能支持多少并发，那就需要模拟这个场景，用工具模拟客户端推流和播放，这种就叫压力测试。在性能优化时，也需要做压测，因为所谓性能，是指某个场景下的性能，比如直播的1推5000播放，和监控的5000推流1个随机播放，调用到的函数并不相同，当然性能热点就不同。SRS有流媒体协议的压测工具，参考SB(srs-bench)，嗯这是个好名字，对吧？

得益于pion/webrtc，Go实现了完整的WebRTC协议栈，我们很方便使用pion做回归测试。如下图：

在CircleCI上，可以看到详细的测试过程，如下图：

在CodeCov上，可以看到SRS代码的详细覆盖率，如下图：

如果你是SRS开发者，修改完代码后，也可以手动本机跑UTest，覆盖率，回归测试，下面介绍使用。

Note: 还可以做压力测试，压测工具的使用，参考srs-bench。

Coverage

修改代码后，可以本机快速跑UTest和Coverage，只需要执行几个命令就可以跑起来。

如果是macOS，执行下面的命令：

cd ~/git/srs/trunk &&
./configure --osx --gcov=on --utest=on &&
bash auto/fast.sh

如果是Linux，执行下面的命令：

cd ~/git/srs/trunk &&
./configure --gcov=on --utest=on && 
bash auto/fast.sh

也可以用gcovr生成结果：

cd ~/git/srs/trunk &&
./configure --gcov=on --utest=on && 
make && ./objs/srs_utest &&
gcovr -r src --html --html-details -o ./objs/coverage/srs.html objs/src

如何安装gcovr请参考安装GCOVR。

最终生成文件objs/coverage/srs.html，可以在Chrome打开：

如果只关注某个模块的覆盖，比如kernel和protocol模块，可以直接跑两个模块的覆盖率：

bash auto/fast.sh kernel protocol

下面是手动跑回归测试。

Regression Test

修改代码后，也可以本机跑回归测试。最新的更新请移步SB: Regression。

回归测试需要先启动SRS，支持WebRTC推拉流：

if [[ ! -z $(ifconfig en0 inet| grep 'inet '|awk '{print $2}') ]]; then 
  docker run -p 1935:1935 -p 8080:8080 -p 1985:1985 -p 8000:8000/udp \
      --rm --env CANDIDATE=$(ifconfig en0 inet| grep 'inet '|awk '{print $2}')\
      registry.cn-hangzhou.aliyuncs.com/ossrs/srs:v4.0.76 objs/srs -c conf/rtc.conf
fi

然后运行回归测试用例，如果只跑一次，可以直接运行：

go test ./srs -mod=vendor -v

也可以用make编译出重复使用的二进制：

make test && ./objs/srs_test -test.v

运行结果如下：

$ make test && ./objs/srs_test -test.v
=== RUN   TestRTCServerVersion
--- PASS: TestRTCServerVersion (0.00s)
=== RUN   TestRTCServerPublishPlay
--- PASS: TestRTCServerPublishPlay (1.28s)
PASS

可以给回归测试传参数，这样可以测试不同的序列，比如：

go test ./srs -mod=vendor -v -srs-server=127.0.0.1
# Or
make test && ./objs/srs_test -test.v -srs-server=127.0.0.1

支持的参数如下：

• -srs-server，RTC服务器地址。默认值：127.0.0.1
• -srs-stream，RTC流地址。默认值：/rtc/regression
• -srs-log，是否开启详细日志。默认值：false
• -srs-timeout，每个Case的超时时间，毫秒。默认值：3000，即3秒。
• -srs-play-pli，播放时，PLI的间隔，毫秒。默认值：5000，即5秒。
• -srs-play-ok-packets，播放时，收到多少个包认为是测试通过，默认值：10
• -srs-publish-audio，推流时，使用的音频文件。默认值：avatar.ogg
• -srs-publish-video，推流时，使用的视频文件。默认值：avatar.h264
• -srs-publish-video-fps，推流时，视频文件的FPS。默认值：25

其他不常用参数：

• -srs-https，是否连接HTTPS-API。默认值：false，即连接HTTP-API。