WLAN自动化测试平台的设计及实现 - 全文

　　目前WLAN就是这样一种成熟和商用的无线上网解决方案。WLAN业务在美国和欧洲已有越来越广泛的应用。由于中国商用WLAN发展的相对比较慢，对WLAN测试的需求没有像传统的GSM /GPRS/CDMA网络测试需求那样旺盛，国内的同类测试软件比较少，但是随着网络的日益普及，WLAN的测试就凸显重要。

　　1 WLAN测试及其自动化

　　1.1 WLAN测试的内容

　　WLAN测试的主要内容涉及无线网卡的功能测试和性能测试。而无线网卡的功能测试包括IEEE 802.11协议规定的各种网络模式下、各种加密方式下的加网、扫描以及QoS、WMM等测试;性能测试是指在各种加密方式下、各个信道的WLAN的吞吐率测试。目前WLAN的网络模式有a，b，e，g，n等以及他们的混合模式，加密方式可分为wep，wpa-psk(ccmp)，wpa2-psk(ccmp)，wpa-psk(tkip)，wpa2-psk(tkip)，wpa-psk(ccmp/tkip)，wapi-psk等多种加密方式，鉴权方式也分为open system，shared key，wpa-psk，wpa2-psk，wapi-psk，wapi-certificate等，而密钥类型和长度也可以分为很多种，将上述条件组合，测试用例数量是非常大的。

　　而在规定的测试周期内，要进行多轮的回归测试，一方面由于测试内容繁多，很难在较短的时间内去考虑更深层次的测试，另一方面，多轮的回归测试导致测试人员疲劳，很难保证每轮测试的细致性。

　　因此一款能将测试人员从重复、繁琐的测试中解放出来的WLAN自动化测试工具就显得非常重要。

　　1.2 传统的WLAN测试方法

　　图1为人工测试WLAN的示意图。图中AP端是指无线接入点所在的端，通过手工的Web界面配置来组建我们所需的网络;STA端是指无线网卡所在的端。从图中我们可以看出，测试人员需要分别配置AP端和STA端。而STA端的配置根据操作系统的不同、网卡的不同而不同。按照这种方法，测试1.1节介绍的WLAN测试的内容，需要很高的人力成本。

　　2 WLAN自动化测试平台总体框架及实现

　　测试平台的设备部署情况如图2所示。整个测试平台由控制台、网卡终端群、AP终端群以及Packets服务器四部分组成。

　　

　　2.1 总体框架

　　控制台为测试平台的核心部分，主要负责终端设备的远程控制、测试任务的配置以及分发、测试结果的收集与显示等工作。控制台通过有线网络与AP终端群、网卡终端群进行控制流的交互，为了有效隔离无线通信链路与有线链路的数据流，控制台可采用双网卡模式或者VLAN技术进行子网的划分，确保网卡终端群与AP终端群的有线链路隔离。

　　当测试对象为网卡时，AP终端群作为测试支持设备工作，此时采用固件升级为DD-WRT的AP设备，接收来自控制台的配置命令来组建不同类型的网络，以配合网卡终端群完成如加网、漫游、速率等功能的测试。

　　作为待测试对象时，网卡终端群通过接收来自控制台的命令执行相应的测试脚本，完成BSS以及IBSS网络功能的检测。作为支持设备时，网卡终端群则充当验证AP设备功能的角色。

　　Linux认证服务器采用OpenSSL技术提供应用层的认证，为网卡设备加入lli企业级模式提供认证服务。

　　Packets服务器主要有两个作用：第一，作为基本的抓包工具，对测试过程中空中特定的包进行捕获和解析，用以配合功能测试中对测试结果的分析。第二，该服务器充当灰盒级测试功能的主体，通过对底层驱动的修改以及对包的捕获、过滤、修改、转发等完成各种极限或特定场景的模拟测试。

　　在实际过程中，网卡设备工作的环境可以各不相同，如部分终端为Linux环境，部分终端为Windows环境，通过控制台进行分发不同的测试脚本即可屏蔽测试设备终端的环境差异。

　　2.2 控制流程

　　根据测试平台总体框架，可以将软件框架分为四个模块;测试用例管理模块、平台通信管理模块、测试过程管理模块、测试结果管理模块，如图3所示。

　　

　　测试用例管理模块负责测试用例的抽取、脚本参数的配置等功能。当配置完成后，通过通信管理模块将测试脚本以及参数分发给测试平台中的各个终端设备，接下来，由测试过程管理模块负责完成整个测试执行工作，同时记录测试执行的结果以及日志等信息，最后由测试结果管理模块对测试结果进行提取与分析，形成最终的测试报告。

　　在各个功能模块中，平台通信管理模块是基础，为其他模块提供了控制通路。测试过程管理模块对整个测试过程进行凋控，实现测试过程的自动化，保证过程的顺利完成。

　　3 WLAN自动化测试工具的实际应用

　　本系统控制端运行在Linux操作系统下，采用Glade+Gtk技术完成主控界面的开发。通过主控端分别Telnet到AP端和STA端，并采用Expe ct技术分别完成与AP端和STA端的交互，主控端作为桥梁，进而可以完成AP端与STA端的交互，保证了时间同步性。测试执行完成后，可以在主控端收集、查看测试日志，并生成测试报告。

　　3.1 自动化测试平台的具体实现

　　3.1.1 远程控制

　　(1)AP控制。当网卡作为待测试设备时，需要借助于第三方的AP设备来完成基本功能的测试，而目前市面上的AP设备大都是采用Web界面进行配置，即使提供了Telnet等远程控制服务，由于厂家处于商业层面的考虑，使用者也很难获取其内部的配置接口。

　　在实现的过程中，采用开源的DD-WRT固件来升级测试平台内的AP设备，通过DD-WRT的公共接口命令来实现对AP设备的配置。

　　(2)网卡控制。当AP作为待测试设备时，需要借助于第三方的网卡设备来完成基本的功能测试。对于工作在Linux平台的网卡，由于源代码为开源，实现配置与控制比较容易;对于工作在Windows平台的网卡，可以采用Native Wifi API构建控制台程序，结合XML形式的无线配置文件Wireless Profile进行综合的控制。

　　(3)认证服务器控制。对于lli证书模式的测试，必须采用认证服务器。认证服务器有两种实现方式，一种是采用Windows Server系列所提供的服务构建，另一种是采用Linux平台配置OpenSSL。前者的操作较为复杂，不便于远程控制，因此本系统拟采用后者的方式构建认证服务器。

　　3.1.2 时间同步

　　测试过程中，需要对平台内的不同终端进行配置，如执行联网的测试时，首先要配置AP组建相应的网络，确保成功后再配置网卡进行联网操作。因此在测试过程中，如何界定事件结束的时间是一个关键的问题，需要一种交互式的控制方式以反馈执行的状态或结果。

　　Shell命令可以实现简单的控制流功能，但无法完成需要交互的场合，而Expect可以实现自动与交互式任务进行通信，而无需人为干预，因此在实现时将采用两者相结合的方式来完成不同终端以及同一终端不同测试项之间的同步控制。

　　3.1.3 平台无关性

　　测试平台要同时考虑待测设备工作在Windows以及Linux两种平台环境下的测试，由于两种平台环境本身存在差异，而且即使相同平台环境下也存在不同版本，使得兼容以上所有平台环境存在一定的难度。

　　现在将AP端和STA端的测试脚本及控制操作都放在控制端，做到与待测设备隔离，使控制台完成所有与测试相关的控制、配置任务，而待测终端只进行控制命令的接收和执行，这样就保证了测试平台不依赖于具体的待测设备终端系统。

　　3.1.4 用例脚本化

　　一方面，平台无关性要求将与平台系统环境相关的测试命令进行相应的归类和抽取，另一方面，测试过程中测试终端之间的控制同步对命令的批量处理也有一定的要求。此外，为了提高用例的复用度，将测试用例脚本化是一个必然的要求。

　　3.1.5 包分发与捕获

　　一方面，对于测试过程中特定用例的帧交互过程进行检查，需要对空中包进行捕获与过滤;另一方面，对于灰盒级的测试，需要模拟各种场景，势必要借助于空中包分发装置来完成。

　　3.2 主控端具体实现

　　采用Gtk+Glade完成控制端的主控界面。图4～图6分别为基本配置界面、功能测试控制界面和测试报告的显示界面。从图4可以看出，主控界面主要由基本配置、功能测试、性能测试、稳定性测试、测试结果等几个子项组成。在功能测试控制界面，可以选择单个测试用例的执行，也可以选择部分或者所有测试用例的执行。每完成一个测试用例，在主控界面上会显示测试结果是成功还是失败。选择好需执行的用例，然后点击图5中的“run test”按钮即可。

　　从图6可以看出，通过在主控端查阅测试报告，可以查阅测试用例执行的详细过程。以加网为例，不仅可以查阅所加网络的具体信息，还可以查阅具体执行到了哪一步，这样可以帮助解决定位问题。

　　

　　4 结语

　　本文介绍的WLAN自动化测试平台，采用Linux作为控制端，远程Telnet AP端和STA端，分别通过脚本配置AP端和STA端，并控制他们之间的交互。该平台可以实现自动化配置AP、自动化配置STA、自动执行测试用例、自动搜集测试日志、自动生成测试报告，从而大大节约了人力成本，提高了工作效率。