生成WebRTC测试很难，但细节决定成败。testRTC的WebRTC云测试以及验证平台就可轻松完成扩缩。
从简单的1:1，到弄清楚如何优化大型群组视频通话，到给数千名参与者现场直播，测试WebRTC应用挑战重重。我们需要的是操作方便而又功能强大的自动化技术。与其他网络技术不同，WebRTC有三点特性：
1. WebRTC资源独占。这就导致大规模测试时分配资源变得很复杂。
2. WebRTC交互性高。涉及多人的场景需要多人参与，也就是说需要多位测试员来扩缩线上测试。
3. 用公认的web指标决定成功或失败是没有用的。WebRTC有自己的一套测试指标，需要收集和分析。
随着远程通话和协作的需求不断增加，WebRTC的用户也显著激增。从一种小众技术，成长为了如今世界各地许多组织和群体完成任务都必不可少的一项技术。
2015年，testRTC发现了上述需求，投资创建了一项自助服务。主营在class平台上大规模和按需测试WebRTC。
什么是WebRTC测试和WebRTC testing？
WebRTC testing本质上由web和VoIP两部分组成。一方面你需要测试基于web的应用程序。另一方面你还要测试VoIP服务。
Web和VoIP世界相交处融合了两者的优点，衍生出使用testing创新技术的需要。
与所有其他类型的软件testing一样，开发者需要采用手动和自动testing两种方式。
手动testing既灵活又智能，有助于WebRTC应用的增强测试，因为与被测试的自动化服务直接互动的毕竟是人。在手动测试中，使用能轻松收集、分析WebRTC指标的工具很重要。它们可以加快testing过程，使其更加有效。
自动testing助力加快testing过程，以及评估靠手动测试无法实现的场景（例如在一个会话中实例化和验证成百上千个参与者的身份）。如果不使用自动化testing，你只能等你的用户来告诉你你的应用程序有什么问题。
如何测试WebRTC？
你可以以手动或自动化的方式进行WebRTC测试。但两种方法有很多机动部分要加以考虑。
设备资源
测试WebRTC最明显的机动部分是客户端。WebRTC在各种浏览器和设备上运行。基于自己的应用程序，你需要写下你的用户可能会使用的设备组合列表，并集中在这些设备上测试。
确保在每个设备上，都查看你的WebRTC应用在实际生活场景中的CPU和内存消耗。这样你就能明白，你的用户是如何体验服务的了。
例如，若要增加单个小组视频通话的人员数量，进行上述测试就很重要了。因为在许多情况下，这是你扩缩能力的瓶颈所在。即验证你为满足多种不同设备和其可用资源要求，而动态调整应用程序的行为。
服务器端基础设施
很多不同类型的服务器都在使用WebRTC——信令服务器、媒体服务器和STUN/TURN服务器等。
你需要用浸泡测试来检验这些服务器在长期的压力之下会如何运行。确保测试CPS，即测试你的服务每秒钟能处理多少次呼叫。大多数情况下，每秒试图连接1000个用户到你的服务是不可能的。
要找到你基础设施的弱点，可能是CPU利用率，但多数情况下更可能是纯网络流量。也就是某些服务器可以处理的数据包数量。
点击此链接，即可体验压力测试的便捷性。
网络条件
网络并不是静态的。它随时间变化和波动。你的会话开始时可能网络状态很好，但一分钟后，你却看到网络状态退化了。
你需要进行的测试中，有一些就是针对上述问题的。你要弄清楚你的应用程序是否能包容网络的动态属性。测试时你应该检查媒体服务器在遇到低比特率或高丢包的糟糕情况后，多久能恢复到高比特率和高帧率的运行状态。
检查媒体服务器如何应对不同类型的网络。比如有多个用户在不同的网络条件下加入会议时，是否每个用户都能正常运行视频流，或者各用户的服务是否降低到了最低的共同标准。
你的WebRTC应用可能在网络性能好的运行很通畅。但你需要确保的是它在丢包和带宽较低的情况也能良好运行，因为这才是常态。
用户行为
用户行为包括两方面。首先，无论你计划使用多少自动化或多复杂的技术，交互式WebRTC服务对应的用户行为还是十分难以预测。你还是需要真人来测试你的服务。
这就是说，在有些领域，仅靠测试人员是不能满足你的测试要求的。比如说，某场会议有十位用户，每位用户都按照自己的时间安排，随意进入会议。通常不可能同时进入。那么如果会议规模更大，或者你的服务量增长，情况又如何呢？
实际上也有一些时候，多个用户试图同时加入。在同一时间，加入同一个会话，或者同时加入不同的会议。
为此，我们要进行测试和验证。如果100多个浏览器试图在同一时间连接到WebRTC服务，那么原来运行良好的WebRTC服务往往会崩溃。
WebRTC testing工具
在大多数情况下，你会用到多个WebRTC testing工具，这样才能囊括更多必要的测试。
在你决定使用哪种WebRTC testing工具时，需要考虑到工具的以下性能：
1. WebRTC流量生成
首当其冲，WebRTC testing工具应该能够生成WebRTC流量。
但因为WebRTC依赖外部信令协议，有时生成流量会是个难题。
要确保你的测试工具满足以下几点：
- 能够支持用于WebRTC的信令协议
- 生成流量的方式要尽可能接近你应用程序的行为方式。也就是说，你要使用的工具，它应该可以自动生成一个浏览器，而不是生成自己合成、预编码的流量
- 模拟各种网络条件，以便能够正确地测试你的WebRTC媒体服务器和TURN服务器，尽可能地接近现实环境
- 在你终端的测试规模增长时，特别是在你进行规模测试或压力测试时，可以动态增长来满足你的需求
- 同步更新WebRTC实现。每个浏览器版本发布更新时，WebRTC行为也会随之更新，大概一两个月一次。你的WebRTC流量生成工具需要与上述变化保持同步
