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
最终生成文件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。
