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打开:

如果只关注某个模块的覆盖,比如kernelprotocol模块,可以直接跑两个模块的覆盖率:

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。
©著作权归作者所有,转载或内容合作请联系作者
平台声明:文章内容(如有图片或视频亦包括在内)由作者上传并发布,文章内容仅代表作者本人观点,简书系信息发布平台,仅提供信息存储服务。

推荐阅读更多精彩内容