西电捷通：高效测试，从160小时中突围

在测试工作中，为确保最终交付物质量，有时难免会遇到一些特殊的测试场景，比如160小时的测试总时长。在这样超常规的测试场景中，如果继续使用常规的测试方法，结果只会费时费力，导致测试效率下降。那么，如何通过巧用高效测试工具，从160小时突围，实现高效测试？笔者通过针对西电捷通产品的一个测试实例，来阐述我们对于此类问题的思考和解决之道。也当作抛砖引玉，借此与业内同行探讨、切磋。

还原“随机数”采集测试场景

先来简单介绍一下某款检测平台产品的随机数采集测试场景，如图1所示： 该测试场景的测试目的是验证检测平台的随机数采集能力。终端设备A向检测平台发送随机数，检测平台则负责采集40个随机数文件，每个文件为128KB。终端设备产生的随机数是封装在实际报文中发送给检测平台的，通常情况下，采集一个随机数文件需要2小时，这时候终端设备A的随机数采集时间则为80小时。

然而，一旦有两款终端设备A、B均需要分别进行随机数采集，那么测试总时长将达到160小时，这意味着在接近7天的时间里，整个测试系统将全部用于随机数采集测试，而其它任何测试项目将无法进行。这时候，如果仍然采用常规方法测试，那么结果一定是令人崩溃的。

图1 随机数采集测试场景

测试速度慢的瓶颈在哪里

如何从160小时中突围，缩短测试时间，提高测试效率，我们必须找到真正的测试瓶颈所在。在随机数采集测试场景中，测试瓶颈主要有两种可能：可能一是终端设备发送随机数速率太慢，慢在数据源头；可能二是检测平台处理随机数的速度太慢，慢在数据处理端。不过，我们还需要做进一步确认。

终端设备发送随机数速率默认3600秒/包，但是可以进行速率配置。让我们试着将终端设备发送随机数速率配置为极限速率6秒/包。在这样的发送速率下，采集一个128KB大小的随机数文件需要2小时，随机数采集测试时间大大缩短。显然，终端设备发送随机数速率已经达到极限，那么检测平台处理随机数的速度是否也已经到达了极限。

其实，关于这个问题，验证的方法很简单，那就是让终端设备A和B同时向检测平台发送随机数，这就相当于终端设备的发送速率提高了2倍。这时检测平台采集一个128KB大小的随机数文件则由2小时缩短为1小时，由此证明检测平台的处理能力目前并不存在瓶颈，真正的瓶颈是终端设备发送随机数速率太慢。

如何从160小时中突围

找到了测试速度慢的真正瓶颈之后，也就找到了提高测试效率的途径。在本案例中，关键是要想办法提高发送随机数的速率。前面已经说过，终端设备的发送速率已经达到极限了，不能再提高了，只能“另辟蹊径”，想别的办法。

笔者以前研发出身，开发过电信级的IP电话网关，对网络编程比较熟悉，很自然的就想到开发一款发包测试工具来解决这个问题。考虑到通用性，这款发包测试工具最好可以发送任意类型的数据包。常规的开发思路是对所有数据类型都做编解码，也就是要认识所有协议，开发工作量相当大，而且拓展性差，有了新的协议就需要添加相应的编解码。经过深入评估，决定不做编解码，核心设计思想是只做数据包类型管理。数据包类型的产生方法是通过第三方抓包软件，将需要发送的数据包（如本测试场景中的随机数包）导入到测试工具中。同时也可以对已有数据包类型进行编辑，产生新的数据包类型。选择数据包类型，设置发送速率，然后添加到发送列表中，就可以向待测设备发送数据。

软件设计思路考虑清楚了，正式开工。还有不到一周的时间就要开始测试了，必须争分夺秒，赶在测试前利用业余时间开发出这款发包测试工具。经过数个昼夜的开发调试，终于胜利完工。测试配置见图2，配置随机数消息的发送速率为10ms/包，这时候检测平台1分钟就可以采集一个128KB大小的随机数文件，测试总时间由160小时骤降到80分钟，测试效率提高了120倍，高效完成测试任务。

图2 发包测试工具测试配置图

结语

面对费时费力的测试场景，要想提高测试效率，首先要分析清楚测试的真正瓶颈所在，然后有的放矢，针对性地找到解决方案。另外，对于一个测试团队来说，结合产品特点，精心打造辅助测试工具，也是实施高效测试的一个必不可少的手段。