一般情况下交换机设备的流量按处理方式可分为两类：1、数据报文。此类报文在转发芯片中根据硬件转发表 (MAC 表、路由表、ACL) 的查询结果进行 硬件转发。2、协议报文。此类报文会命中特定 ACL 或者主机路由，报文会被放入特定的 CPU 端口队列，通过转发芯片与 CPU 之间的硬件通道上送 CPU。此类报文常用的有 ARP/STP/LACP/OSPF/ISIS/ICMP/DHCP 等。对 CPU 能够形成压力的就是大量的各种上送 CPU 的协议报文。为防止大量协议报文上送冲击 CPU，交换机/路由器设备对每一种上送 CPU 处理的报文上送速率都进行了限制。
实际使用过程中导致 CPU 利用率升高的场景主要有：1、网管频繁访问端口相关 mib 节点信息,数目越多、访问的节点越多、访问间隔越短，对 cpu 压力越大。2、大规模的路由震荡，导致设备频繁计算路由，占用 CPU 资源。3、STP 状态频繁震荡，设备收到大量 TC 报文后删除 MAC、ARP。4、恶意攻击报文，如 ARP、DHCP、ICMP 等协议报文攻击。5、设备上配置 netstream、sflow 特性，配置端口较多，报文采样率小，采样端口流量大。
所以，如果想在测试过程中给 CPU 加压，可以使用测试仪器模拟上述的场景。之前用的最多的就是通过路由震荡。

webdriver 当时有没有考虑这种移动端测试的场景？

从表面上你看到的是返回的业务结果，其实他覆盖了你的函数流程。
接口测试，你可以用正确的输入 + 正确的结果来验证，也可以用错误的输入和预期的结果去做验证。
意图是覆盖你接口的所有可能的路径和输入输出，保证基本的接口级的功能不出问题。接口级不出基本问题，才能再往上保证场景、应用，越早发现问题修改越小