目前，生成流量是很多WebRTC testing工具的开发重点。需要依靠以下两种技术的任意一种来完成。
1. 使用浏览器自动化技术，比如建立在Selenium之上。并依靠浏览器自行处理和管理所有WebRTC流量；
2. 创建合成的、预先编码的流量（或只是回传收到的内容）。这种技术主要用于大规模测试，即需要测试几十万个数据流。这时再使用浏览器的话成本过高，所以采用此种技术。
2. 用户模拟
在生成WebRTC流量过程中，用户行为也是需要考虑的一部分。
很多情况下，WebRTC会话不是对等的：可能有一个用户是发言人，其他用户都是观众。而在其他情况下，可能会有几位发言人，然后会直播给更多观众看。
你使用的工具应该够强大，这样才能处理测试场景中的不同角色。即使在一组对等的WebRTC小组视频通话中，也需要测试屏幕共享，这意味着现在该会话中有发言人这一角色。
赋予角色应不仅只对用户本身可用，用户设备如何表现，以及如何分析数据方面也应该可用。
3. 数据收集
到这一步，我们已经在WebRTC中生成了流量，为各种流指定了角色。现在该来收集数据了。
WebRTC让我们看到更多有用的数据点，如：
- 控制台日志
- WebRTC内部转储
- WebRTC指标
- 设备性能统计
- 屏幕截图
…
你的工具能收集的东西越多，你就越有可能更快找出潜在问题，并进行故障排除。
4. 分析、可视化WebRTC指标
你是否查看过webrtc-internals 转储文件？
该文件是开发人员所设，清除WebRTC bug时的第一道防线。然而，如何阅读该文件是个难题。
确保你使用的工具能够更好地分析和可视化WebRTC的指标。WebRTC testing工具需具备的能力如下：
- 能够收集和可视化webrtc-internals转储数据；
- 能够在没有webtrc-internals（有时不可用）的情况下收集WebRTC指标，并对其进行分析；
- 能够汇总和深入分析用户的海量数据；
- 具备能轻易找出异常值和失败流的机制；
- 定义失败的标准，能够轻松找出测试状态是通过还是失败；
- 具备深入分析能力。从高层次的视图，到捕获结果的微小细节。
掌握的数据越多，你调试和解决问题时就会更如鱼得水。但同时，因为没有测试工具的指导，阅读和分析结果也会更困难。
https://www.youtube.com/embed/_6_InaWc6dc?feature=oembed&enablejsapi=1&origin=https://testrtc.com
5. 维护水平
如前所述，WebRTC是一个飞速发展的项目。它一直在变化。
确保你使用的WebRTC testing工具能得到良好维护，并经常更新和升级。
如今我们使用的这项技术市场关注度高、竞争激烈，所以现在的要求和去年的有很大不同，
谈到WebRTC testing环境必要的维护工作，我们需要考虑以下几点：
- 频繁升级浏览器；
- 浏览器自动化工具升级（应该与浏览器的更新频率保持一致）
- WebRTC的清除、更改和添加操作
WebRTC测试类型
在对WebRTC应用进行测试时，我们需要注意某些特定领域。也就是说我们要考虑在测试计划中包含某些测试类型。以下是几种主要类型：
端对端WebRTC testing
大多数情况下，你不需要测试WebRTC实现本身。这块由浏览器供应商来处理。WebRTC互操作性测试也是他们自己完成的。
如果你使用的是第三方媒体服务器或CPaaS供应商，说不准你会发现，专注于测试这一层很重要。据我观察，不同的供应商或个人对此有不同意见。
你应该做的是确保完成端对端的测试。该测试应体现你的整个应用逻辑。你要重点关注如何验证WebRTC和应用逻辑之间的交点。
P2P测试
如果你的应用程序支持端对端，那就没有媒体服务器需要处理了。这样，一些测试会更容易管理和进行。
需要用P2P来验证的是：
- TURN服务器和信令服务器的大小和压力
- 不同的防火墙配置
- 对于基于网状网络的群组通话场景（若属于你的业务范围），你要花费大量时间来测试、打磨和优化体验。
呼叫中心WebRTC testing
呼叫中心在进行WebRTC testing时要特别小心注意。原因如下：
- 呼叫的一部分在WebRTC里，剩下部分在PSTN或SIP中。
- 由于呼叫中心早已规模运营，只需要验证WebRTC不会把事情搞砸，所以压力测试是重点。对在过程中会把Opus转码为G.711或G.729的开发者来说更是如此。
WebRTC的压力测试
WebRTC测试的一个重要部分是压力测试。该测试是为了找出以下3个问题中任意一个的答案。
1. 服务器能够处理多少负载？该问题主要针对媒体服务器和TURN服务器；
2. 负载平衡器是否能正常运行？按顺序来讲这是第二个问题，因为有许多服务需要在多个媒体服务器上进行负载平衡的处理；
3. 应用程序可以并行处理多个用户/房间/会话吗？需要开发人员检查整个服务
基于你运行服务的方式以及服务规模，会存在上述的一个或多个问题。
WebRTC群组通话测试
供应商用WebRTC完成的大多数服务都是群组通话。无论是视频还是语音通话，其测试都相当具有挑战性。召集足够多的人加入群组通话进行测试，会花费大量时间和同步操作。这之后，再找出、排除问题几乎是不可能的。如果你不了解网络的质量或用户使用了什么设备，就更难了。
在处理WebRTC群组通话时，你需要花大力气优化期望支持的群组规模——无论是10个、49个、100个用户还是更大的群体规模，都是如此。
为实现这一目标，你需要使用具备以下几点的自动化工具：
- 稳定和可预测的设备和运行网络；
- 能在不同条件下进行测试，可由你动态控制的可配置网络；
- 对结果进行详细的可视化分析，以方便你理解测试结果；
- 可以测试来自不同地点的用户
直播测试
就直播来说，发言人较少而观众（即订阅者）较多。许多解决方案的问题在于不提供云端的视频转码。即使提供转码，也需要你验证它是否能被正确使用。
在这种情况下，需要进行以下类型的测试：
- 通过引入较多观众来对媒体服务器进行大规模的压力测试。
- 选择来自各个地方的观众
- 以不同的网络条件配置观众
- 动态地改变一些观众的网络条件
此时你的目的是了解解决方案的整体质量，并验证连接不畅的观众不会影响其他观众的体验。
WebRTC移动设备端测试
WebRTC的移动设备端测试挑战重重。主要问题是缺乏恰到好处的自动化。因为使用基于云的解决方案意味着，移动设备的摄像头拍到的充其量是一个静态的图像，或环境太暗拍不到什么。其实移动设备被放置在数据中心的机架上，就是为了这个目的。
一些测试能够通过自动化实现，但关系到媒体质量的细节，很难用自动化来处理。
以下3方面的测试是你需要注意的：
1. 网络。要了解移动网络和设备会如何影响你的基础设施。这两类测试可以在不使用实际移动设备的情况下进行模拟和自动化。
2. 设备。针对不同的设备和品牌进行测试。使用云端自动化或众包测试都可以。
3. 应用。像其他移动应用程序样，这类也可以使用云自动化测试。
浏览器测试
使用WebRTC的浏览器测试可以手动完成，也可以在本地自动完成。
有4种主流浏览器可供使用——Chrome、Safari、Firefox和Edge。
很多供应商会选择跨浏览器手工测试应用程序，原因有二。一，他们经常改变UI；二，跨浏览器的WebRTC自动化测试较为复杂。目前，testRTC为Chrome和Firefox提供自动测试。主要由于我们一直集中开发基础设施测试。
测试浏览器时的注意事项：
- 每个浏览器都要测试其多个版本，实操中会经常碰到它们。
- 确保在测试版发布之前进行测试，这样才能发现隐藏的问题。
组件测试
WebRTC有许多组件——浏览器、设备、应用服务器、网络服务器、TURN服务器、媒体服务器等。我们甚至还没有列出其他基础设施组件，如数据库和负载平衡器等。
有时，分开测试每个组件是很重要的。对于WebRTC，主要指的是TURN服务器或媒体服务器。
这种情况下，你可能想创建简单的专用网页，用来测试这些组件。这样就不用再过一遍你整个的应用逻辑。
WebRTC测试自动化的优势
测试WebRTC应用程序与测试其他Web应用程序不同。原因如下：
- 与大多数Web应用相比，WebRTC客户端和服务器端都需要相当多的资源
- WebRTC应用对网络条件和可用的设备资源更敏感，更易受影响。
- 大多数WebRTC应用都需要多个设备和浏览器中测试场景的高度同步。
- WebRTC用来说明测试是否成功所需的指标与其他网络应用的不同。
人工测试降低了很多测试的可预测性和可观察性。如果方法正确，使用恰当工具，WebRTC测试的自动化可以大大增强应用程序的稳定性。
设计可扩展的WebRTC测试
在为你的应用程序设计WebRTC扩展测试时，有以下几点注意事项。你需要在开始时就做好准备，否则以后再添加这几项就很难了。
以下是在WebRTC自动化testing中设计扩展的一些最佳实践：
1. 有能力配置模拟用户没有验证码、OTP或2FA的测试账户。这是自动化会面临的挑战。
2. 创建可以根据需要，生成尽可能多预配置的测试账户的脚本。手动操作既耗时又容易出错。
3. 提前做备选计划，以减少UI中达到媒体测试本身所需的步骤数量。在WebRTC的大型压力测试中，调度、填表、以及过多选择和按钮点击都会增加错误信息的数量。
4. 设计你的测试脚本，使其能在2个轴上进行扩展，即参与者的总数量和单个会话中的参与者数量。这将使你的测试更加灵活。
5. 有能力定义不同的每秒通话量（CPS）值。这样你就可以在大型测试调节和把控参与者进入的操作，以适应你的要求。
6. 简易化运行压力测试。若你在短时间内无法准备好开始运行一个大型的压力测试，你需要进行改进。
7. 从测试中收集重要的指标。即那些能够帮助你快速了解结果，并能够轻松地与过去的测试运行进行比较的指标。
认真对待你的WebRTC测试
近年来，WebRTC已经从一项小众技术，发展成为互联网架构和我们通信工具的一个重要部分。如果你正在用WebRTC开发产品，那么最重要的是你在测试时也要重视它。
