一种Wi-Fi模块自动测试方法及测试系统与流程

本发明涉及一种wi-fi模块自动测试方法及测试系统。

背景技术：

wi-fi模块又名串口wi-fi模块，属于物联网传输层，功能是将串口或ttl电平转为符合wi-fi无线网络通信标准的嵌入式模块。wi-fi模块是实现无线智能家居、m2m等物联网应用的重要组成部分。在wi-fi模块的可靠性测试中，目前采用的是人工测试，一般要通过测试人员通过手机上的app来对待测模块进行控制，从而进行所有功能性的验证。在测试过程中，经常需要进行多次重复性联网、复位等测试，人工测试耗时久，且人工在长时间重复性测试中容易出现懈怠和疲倦，容易导致测试结果偏差或不准确。

技术实现要素：

本发明的目的是为了解决上述问题，本申请提供一种无需人工干预的wi-fi模块自动测试方法及测试系统。

本发明为实现上述功能，所采用的技术方案是提供一种wi-fi模块自动测试系统，其特征在于，包括：测试服务器,所述测试服务器为安装了appium框架的电脑；至少一台手持移动设备；局域网设备及待测模块，

所述测试服务器根据测试脚本向所述手持移动设备发送控制指令，所述手持移动设备根据收到的所述控制指令，模拟人工操作自动发出具体操作指令，所述手持移动设备和所述待测模块通过局域网设备进行通信，所述待测模块接收所述手持移动设备发出的具体操作指令，执行相关操作进行测试。

进一步的，所述系统还包括ttl转usb模块，所述待测试模块通过ttl转usb模块接入到所述测试服务器。

进一步的，所述系统还包括设置在所述测试服务器中的抓取模块，所述抓取模块从所述待测模块抓取其log信息。

进一步的，当所述待测模块接入所述测试服务器后，所述待测模块处于侦听状态，所述手持移动设备收到所述控制指令后，首先向所述局域网设备发送配网请求，所述局域网设备转发所述配网请求，处于侦听状态的所述待测模块，接收到所述局域网设备下发的所述配网请求时，解密其中所携带的配网信息，自动联网。

进一步的，所述测试服务器安装有测试环境和依赖包，在运行所述测试脚本时，所述appium框架自动将测试代码逻辑转化成adb指令作为所述控制指令发送给所述手持移动设备。

本发明还提供一种wi-fi模块自动测试方法，其特征在于，包括以下步骤：

步骤a测试准备工作，所述测试准备工作包括将待测模块接入测试服务器，编写测试脚本；

步骤b测试服务器运行所述测试脚本，生成控制指令，并将所述控制指令发送给手持移动设备；

步骤d所述手持移动设备根据收到的所述控制指令，模拟人工操作形成具体操作指令，并通过所处局域网内的局域网设备向所述待测模块发送所述具体操作指令，所述局域网设备转发所述具体操作指令到所述待测模块，所述待测模块执行相关操作进行测试；

步骤e输出测试结果。

进一步的，所述步骤b和所述步骤d之间还包括步骤c，所述步骤c包括，所述手持移动设备在收到的所述控制指令时，先向所述局域网设备发送配网请求，所述局域网设备转发所述配网请求，所述待测模块在接入所述测试服务器后处于侦听状态，处于侦听状态的所述待测模块接收到所述局域网设备下发的所述配网请求时，解密其中所携带的配网信息，自动联网。

进一步的，所述步骤a还包括在所述测试服务器上搭建测试环境和安装依赖包。

进一步的，所述步骤a还包括获取测试应用程序中的界面元素，编写所述测试脚本。

进一步的，所述步骤e中所述测试服务器读取所述手持移动设备的执行结果和/或所述测试服务器读取所述待测模块的log信息作为测试结果。

进一步的，所述步骤e之前还包括判断步骤，所述判断步骤判断测试中是否出错，如出错则自动停止执行指令，保存错误信息，通过人工再次启动后再次执行步骤b；如未出错则执行步骤e。

进一步的，所述测试服务器为安装了appium框架的电脑，步骤b中测试服务器运行所述测试脚本，具体为所述appium框架自动将测试代码逻辑转化成adb指令，所述adb指令为所述控制指令。

在本发明所提供的wi-fi模块自动测试方法及测试系统中appium框架自动将测试代码逻辑转化成adb指令控制测试手机，可实现无需人工干预自动配网、自动复位，出错自动停止并提取错误信息等功能，节约手工测试的人力和时间成本。

附图说明

图1是本发明实施例中测试系统的结构示意图；

图2是本发明实施例中测试方法的基本流程示意图；

图3是本发明实施例中一次具体测试的流程示意图。

具体实施方式

以下结合附图和具体实施例对本发明提出的wi-fi模块自动测试方法及测试系统作进一步详细的说明。

请参考图1，图1所示是本发明提出的wi-fi模块自动测试系统的一个较佳实施例的结构示意图，该检测设备系统包括：测试服务器1、至少一台手持移动设备2、局域网设备3及待测模块4。

其中，测试服务器1为一台安装了appium框架的电脑。测试进行时，测试服务器1运行测试脚本，appium框架自动将测试代码逻辑转化成adb指令作为控制指令发送给手持移动设备2。手持移动设备2可以是手机或平板其上安装有可以控制待测模块的app。手持移动设备2可以是一台设备，也可以同时通过多台设备进行测试，手持移动设备2的数量视实际测试需要而定。手持移动设备2和测试服务器1之间可以通过数据线连接，也可以通过无线连接来传输信息，本申请对此不作限定。

手持移动设备2和待测模块4处于同一个局域网内，他们之间通过局域网设备3实现通信，局域网设备3可以是网关、路由器等设备，也可以是一组网络设备。手持移动设备2根据从测试服务器1处收到的控制指令，模拟人工操作自动发出具体操作指令。原来需要人工要做的一些动作，通过脚本语言实现，控制手机进行自动化的输入、点击等动作，而这些动作后需要待测模块4进行的动作指令即为具体操作指令，如原来需要由人在手机app上点击“开灯”按钮，现在根据测试脚本，测试服务器1向手持移动设备2发送控制指令，手持移动设备2自动打开app模拟点击操作，app则根据原点击后的操作，向待测模块4发出“开灯”指令。待测模块4接收上述手持移动设备2发出的具体操作指令后，执行相关操作，如执行上述“开灯”从而进行测试，记录相关操作结果。

待测模块4接收具体操作指令后，为了了解其后续操作是否符合预期，需要了解其后续动作，在本实施例中是通过测试服务器1来抓取待测模块4在运行中的所有运行log信息。因此，在本实施例中还包括ttl转usb模块（未图示），该模块一端和待测模块连接，另一端插入测试服务器1的usb接口，待测模块4通过ttl转usb模块接入到测试服务器1。在测试服务器1中还需要设置抓取模块（未图示），通过抓取模块来对待测模块4的运行log信息进行抓取。抓取模块可以是硬件模块，也可以是一些软件抓取工具，如securecrt或xshell等这一类记录串口log的工具。

在本实施例中，待测模块4已经和手持移动设备2处于同一个局域网之中了，因此他们之间通过局域网设备3就可以直接进行通信。但是在另外一些测试实例中，待测模块4的配网也是测试的一部分，即在开始相关操作前待测模块4并未接入网络，因此需要在测试之初需先进行配网。配网的具体过程如下，当待测模块4接入测试服务器1后，待测模块4就处于侦听状态，而手持移动设备2收到测试服务器1控制指令后，在发出具体操作指令前，先向局域网设备3发送配网请求，当然配网请求本质上也可以认为是一个具体操作指令，由局域网设备3转发配网请求，在局域网内进行广播，处于侦听状态的待测模块4接收到配网请求后，解密其中所携带的配网信息，自动联网。联网后整个系统的各个模块间的通信连接全部完成。

在上面介绍实施例测试系统的各功能模块时，已经基本说明了相应的测试方式，下面根据图2所示基本流程图，来更为清晰地梳理一下整个wi-fi模块测试流程。本实施例中的wi-fi自动测试方法，包括以下步骤：

步骤a测试准备工作，测试准备工作包括将待测模块4接入测试服务器1，如前所述待测模块4通过ttl转usb模块和测试服务器1建立连接，此后待测模块4进入监听状态等待命令。在首次测试之前测试服务器1还需要先搭建相应的测试环境和安装依赖包。在一些实施例中测试脚本可事先编写，在本实施例中，脚本编写工作是包含在测试准备工作之中的，在安装的程序中有一个脚本程序可以获取应用程序的界面元素，在获取界面元素后，测试人员根据本次测试的具体内容编写基于appium框架的自动化测试脚本。

步骤b测试服务器1运行测试脚本，生成控制指令，并将所述控制指令发送给手持移动设备2。在介绍系统时表述了测试服务器1已经预先安装了appium框架，在测试进行到步骤b时，测试服务器1启动appium服务并执行测试脚本，appium框架自动将测试代码逻辑转化成adb指令控制连接的手持移动设备2，这里的adb指令即为控制指令。

步骤c手持移动设备2在收到测试服务器1的控制指令后，在待测模块4还没有配网的情况下，先向局域网设备3发送配网请求，经局域网设备3转发后，处于侦听状态的待测模块4接收到配网请求后，解密其中所携带的配网信息，自动联网。步骤c并不是整个流程中的必要过程，在一些测试实例中，待测模块4在测试开始前已经接入了相关网络，在那些情况下，就不必要进行步骤c，可以从步骤b直接进入到步骤d阶段。

步骤d手持移动设备2根据收到的控制指令，模拟人工操作自动运行应用程序上的各项操作，产生具体操作指令。具体操作指令通过所处局域网内的局域网设备3发送给待测模块4，接收到这些具体操作指令后，待测模块执行相关操作进行测试，同时记录运行中的所有log信息。

步骤e输出测试结果，测试结果由测试服务器1读取待测模块4的log信息后获得。在一较佳实施例中，测试结果也可以是测试服务器1从手持移动设备2处读取执行结果。在另一较佳实施例中，测试结果可以是同时读取待测模块4的log信息和手持移动设备2的执行结果后将两者组合起来。

下面我们结合图3中的一个实际测试中的具体流程，来进一步具体说明本申请提出测试方法。

如图所示在测试流程开始之后先进行准备工作101，准备工作101中主要包括各种硬件的准备，然后再进行软件环境的准备，其中分为同时进行的两个步骤，部署测试环境201和搭建测试框架和安装依赖库202，在软硬件都安装完毕之后，待测模块4和手持移动设备2也都接入了测试服务器1。在此次测试中手持移动设备2为手机。此时，测试人员编写测试脚本，在编写测试脚本时需参考手持移动设备2上应用程序的界面元素，脚本代码可以实现自动模拟在界面上进行的各种动作，如“点击”、“滑动”、“字符输入”等，如此在后续测试时，就不需要测试人员手动操作手机即可实现自动测试。在图3中的步骤101、201、202、301均包括在图2中的步骤a中。

在脚本编写完成之后，进入401步骤启动appium服务器，而后进入步骤501执行测试脚本，服务器端appiumserver将测试脚本转化成adb指令。步骤601测试手机接收测试指令并执行，具体就是在测试手机的应用程序界面上根据adb指令，自动执行前述“点击”、“滑动”、“字符输入”等操作，这些操作都会产生针对待测模块4的后续动作。当然，在501和601之间必然会有信息传递动作，不过本流程图主要为了说明测试流程，这种信息传递过程就不在图中特别说明了。在本图中步骤401、501对应步骤b，步骤601对应步骤d，在该测试实例中待测模块4已经接入局域网，因此省略了步骤c。

图2步骤e和图3中的步骤801输出测试结果对应，在图2的基本流程图中，步骤d之后就直接进入了步骤e。而在实际测试中，测试并不总是一帆风顺，其中会有各种问题出现，因此在输出结果801之前还包括判断步骤701，判断执行中是否出错。如出错则自动停止执行指令，进入步骤702保存错误信息，通过人工再次启动返回到步骤501执行测试脚本。如未出错则继续执行步骤801输出测试结果。测试完成后，所有运行的log信息都以文本的形式保存在测试服务器端，并由其输出测试报告。

报告产生后本轮测试结束，此时自动对待测模块进行复位，清空所有用户数据，等待下一次测试，即重新从步骤101开始执行。当然在连续的测试时，准备工作在第二轮中可以简化，像搭建环境、安装软件等工作就不必重复了，脚本是否要重新编写，主要根据测试的需求而定。

上文对本发明优选实施例的描述是为了说明和描述，并非想要把本发明穷尽或局限于所公开的具体形式，显然，可能做出许多修改和变化，这些修改和变化可能对于本领域技术人员来说是显然的，应当包括在由所附权利要求书定义的本发明的范围之内。