CN104850499A - 基带软件的自动化测试方法及装置 - Google Patents

Abstract

本发明提供了一种基带软件的自动化测试方法及装置，采用接收用户选择的被测试模块及各模块对应的测试用例；根据测试用例的函数名和/或函数参数，生成测试指示数据；向监测模块发送测试指示数据，以便监测模块将其对测试指示数据进行解析得到的数据内容发送给被测试模块以及根据接收的被测试模块反馈的执行对应的测试用例后的执行结果生成字符串；接收监测模块发送的具有第一固定格式的字符串，根据具有第一固定格式的字符串，判断测试用例是否通过，其能够自动执行试用例，省时省力，能够适应较多种的软件环境并且能够方便的添加和删除测试模块以及各个测试模块的测试用例，无需更改较多代码，简化了测试的操作步骤，提高了测试效率。

Description

基带软件的自动化测试方法及装置

技术领域

本发明涉及计算机软件测试领域，具体而言，涉及基带软件的自动化测试方法及装置。

背景技术

近几年来，随着计算机技术的提高，使得软件行业对软件的质量要求也越来越高，即达到了一个新的标准，这一新的标准的实施使得对软件测试更加重视，即通过对软件的测试找出软件的问题所在，并对所在的问题进行不断修复和完善，以得到高质量的软件。

传统的软件测试，即人工对软件进行测试，但是人工测试存在费时费力且效率低下，并且人工测试易产生主观错误等缺陷。为了解决传统的软件测试的上述缺陷，相关技术提供了自动化软件测试技术，自动化软件测试技术能够通过自动化测试工具或其他手段，按照软件测试工程时的预订计划对待测模块进行自动测试，其能够减轻人工测试的劳动量，减少人为错误的发生，从而达到提高软件质量的目的。

其中，自动化测试具有很多优点，比如它可以很大的节省人力，节省时间，特别是对于产品型的软件，每发布一个新版本，其大部分功能和上一个版本相似，这样自动化测试就极大的解放了人力；自动化测试能够完全自动的运行，可以在晚上和周末执行测试，这样就节省了时间；同时自动化测试能够完成人工不易控制的工作，比如采集CPU占有率信息等。

具体的，相关技术提供了一种自动化软件测试技术，使用当前市面上使用较多的自动化测试工具，如QTP(quicktest Professional，软件功能自动测试工具)，WinRunner(企业级的功能测试工具)、QA Run(应用的功能测试工具)以及Test Partner等，来执行重复的手动测试，用以检测应用程序是否能够达到预期的功能及正常运行。这些自动化测试工具结合预订计划基本上都实现了自动化测试，达到了省时、省力、效率高以及方便灵活的优点；但是，这些自动化测试工具也存在着一定的局限性和缺点，例如它们适用于特定的软件环境，工具脚本维护起来比较麻烦，例如，QTP对环境要求很高，使用QTP时，需要把实时监控软件和杀毒软件关闭；WinRunner使用的脚本主要是基于类C的TSL,在学习上会有一定难度；TestPantner收费昂贵等。

为了解决当前市面上使用较多的自动化测试工具的上述问题，相关技术还提供了另一种自动化软件测试技术，即使用实时操作系统预设操作系统自身带有自动化测试环境BSP VTS(boardsupport package validation test suite)板级支持包测试工具)来执行重复的手动测试，用以检测应用程序是否能够达到预期的功能及正常运行。但是，VTS的测试方式自身存在着诸多缺点，比如，测试代码的实现比较复杂、需要更改多处的代码才能完成代码移植、测试用例的添加或者测试用例删除过程比较繁琐。

发明人在研究中发现，现有技术中的两种自动化测试技术均存在相应的问题(如适用的软件环境单一和测试过程中的操作复杂繁琐)，针对上述存在的问题，目前尚未提出有效的解决方案。

发明内容

本发明的目的在于提供基带软件的自动化测试方法及装置，能够适应较多种的软件环境，简化了测试的操作步骤，提高了测试效率。

第一方面，本发明实施例提供了一种基带软件的自动化测试方法，包括：

接收用户选择的被测试模块及各模块对应的测试用例；

根据测试用例的函数名和/或函数参数，生成测试指示数据；

向监测模块发送测试指示数据，以便监测模块将其对测试指示数据进行解析得到的数据内容发送给被测试模块以及根据接收的被测试模块反馈的执行对应的测试用例后的执行结果生成具有第一固定格式的字符串；

接收监测模块发送的具有第一固定格式的字符串，字符串携带有标识测试用例的执行是否成功的数据值；

根据具有第一固定格式的字符串，判断测试用例是否通过。

结合第一方面，本发明实施例提供了第一方面的第一种可能的实施方式，其中，所述基带软件的自动化测试方法还包括：

获取发送测试指示数据到接收该测试指示数据对应的反馈字符串时所用的测试时间；

在检测到测试时间小于或等于第一预设时间时，判定测试用例执行正常，并根据具有第一固定格式的字符串判断测试用例是否通过；以及，

在检测到测试时间大于第一预设时间时，判定测试用例执行异常，并向监测模块发送下一个测试指示数据。

结合第一方面，本发明实施例提供了第一方面的第二种可能的实施方式，其中，向监测模块发送测试指示数据，包括：

向监测模块发送询问被测试模块是否正常启动的请求命令；

在接收到监测模块发送的携带被测试模块正常启动的反馈信息时，向监测模块发送测试指示数据。

结合第一方面的第一种可能的实施方式或者第一方面的第二种可能的实施方式，本发明实施例提供了第一方面的第三种可能的实施方式，其中，根据具有第一固定格式的字符串，判断测试用例是否通过，包括：

在字符串中查找第一预设标识字段，获取第一预设标识字段上的第一数据值；

判断第一数据值与第一预设数据值是否相匹配；

在检测到第一数据值与第一预设数据值相匹配时，判定测试用例执行成功；以及，

在检测到第一数据值与第一预设数据值不匹配时，判定测试用例执行失败。

结合第一方面的第三种可能的实施方式，本发明实施例提供了第一方面的第四种可能的实施方式，其中，所述基带软件的自动化测试方法还包括：

每隔第二预设时间接收监测模块发送的具有第二预设格式的心跳包；其中，第二预设格式与第一预设格式不同；

在心跳包中查找第二预设标识字段，获取第二预设标识字段上的第二数据值；

判断第二数据值与第二预设数据值是否相匹配；

在检测到第二数据值与第二预设数据值相匹配时，向监测模块发送测试指示数据；以及，

在检测到第二数据值与第二预设数据值不匹配时，停止测试。

结合第一方面的第四种可能的实施方式，本发明实施例提供了第一方面的第五种可能的实施方式，其中，所述基带软件的自动化测试方法还包括：

实时显示测试过程中用户选择的所有测试用例的测试进度以及已完成测试的所述测试用例所占的比例；

分别统计当前已完成测试的测试成功的测试用例数量、测试失败的测试用例数量以及测试异常的测试用例数量，并根据统计结果分别计算测试成功、测试失败以及测试异常的测试用例数量所占据的比例；

实时显示测试成功、测试失败以及测试异常的测试用例数量所占据的比例。

结合第一方面的第五种可能的实施方式，本发明实施例提供了第一方面的第六种可能的实施方式，其中，所述基带软件的自动化测试方法还包括：

将接收的监测模块发送的被测试模块执行测试用例时的运行日志进行记录和保存。

第二方面，本发明实施例还提供了一种基带软件的自动化测试方法，包括：

接收测试工具发送的测试指示数据，测试指示数据包括测试用例的函数名和/或函数参数；

对接收的测试指示数据进行解析，得到数据内容；

将解析得到的数据内容发送给被测试模块；

接收被测试模块反馈的执行对应的测试用例后的执行结果；

根据测试用例的执行结果生成具有第一固定格式的字符串，字符串携带有标识测试用例执行是否成功的数据值；

向测试工具发送具有第一固定格式的字符串，以便测试工具根据数据值判断测试用例是否通过。

第三方面，本发明实施例还提供了一种基带软件的自动化测试装置，包括：

第一接收单元，用于接收用户选择的被测试模块及各模块对应的测试用例；

测试指示数据生成单元，用于根据第一接收单元接收的测试用例的函数名和/或函数参数，生成测试指示数据；

第一发送单元，用于向监测模块发送生成单元生成的测试指示数据，以便监测模块将其对测试指示数据进行解析得到的数据内容发送给被测试模块以及根据接收的被测试模块反馈的执行对应的测试用例后的执行结果生成具有第一固定格式的字符串；

第二接收单元，用于接收监测模块发送的具有第一固定格式的字符串，字符串携带有标识测试用例的执行是否成功的数据值；

判断单元，用于根据第二接收单元的具有第一固定格式的字符串，判断测试用例是否通过。

第四方面，本发明实施例还提供了一种基带软件的自动化测试装置，包括：

第五接收单元，用于接收测试工具发送的测试指示数据，测试指示数据包括测试用例的函数名和/或函数参数；

解析单元，用于对接收单元接收的测试指示数据进行解析，得到数据内容；

数据内容发送单元，用于将解析单元解析得到的数据内容发送给被测试模块；

第六接收单元，用于接收被测试模块反馈的执行对应的测试用例后的执行结果；

字符串生成单元，用于根据第六接收单元接收的测试用例的执行结果生成具有第一固定格式的字符串，字符串携带有标识测试用例执行是否成功的数据值；

字符串发送单元，用于向测试工具发送字符串生成单元生成的具有第一固定格式的字符串，以便测试工具根据数据值判断测试用例是否通过。

本发明实施例提供的基带软件的自动化测试方法及装置，采用接收用户选择的被测试模块及各模块对应的测试用例；根据测试用例的函数名和/或函数参数，生成测试指示数据；向监测模块发送测试指示数据，并接收监测模块发送的具有第一固定格式的字符串，字符串携带有标识测试用例的执行是否成功的数据值；根据具有第一固定格式的字符串，判断测试用例是否通过，与现有技术中的两种自动化测试技术均存在相应的问题(如适用的软件环境单一和测试过程中的操作复杂繁琐)相比，其能够带来以下有益效果：

1、测试用例能够自动执行，省时省力；

2、能够适应较多种的软件环境；

3、能够方便的添加和删除测试模块以及各个测试模块的测试用例，无需更改较多代码，简化了测试的操作步骤，提高了测试效率。

为使本发明的上述目的、特征和优点能更明显易懂，下文特举较佳实施例，并配合所附附图，作详细说明如下。

附图说明

为了更清楚地说明本发明实施例的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，应当理解，以下附图仅示出了本发明的某些实施例，因此不应被看作是对范围的限定，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他相关的附图。

图1示出了本发明实施例所提供的一种基带软件的自动化测试方法的流程图；

图2示出了本发明实施例所提供的另一种基带软件的自动化测试方法的流程图；

图3示出了本发明实施例所提供的另一种基带软件的自动化测试方法的流程图；

图4示出了本发明实施例所提供的另一种基带软件的自动化测试方法的流程图；

图5示出了本发明实施例所提供的另一种基带软件的自动化测试方法的流程图；

图6示出了本发明实施例所提供的一种基带软件的自动化测试装置的结构示意图；

图7示出了本发明实施例所提供的另一种基带软件的自动化测试装置的结构示意图；

图8示出了本发明实施例所提供的一种基带软件的自动化测试装置中第一发送单元和第一判断单元的结构示意图；

图9示出了本发明实施例所提供的另一种基带软件的自动化测试装置的结构示意图；

图10示出了本发明实施例所提供的另一种基带软件的自动化测试装置的结构示意图。

主要标号说明：

11、第一接收单元；12、测试指示数据生成单元；13、第一发送单元；14、第二接收单元；15、第一判断单元；16、获取单元；17、判定单元；18、第三接收单元；19、查找单元；20、第二判断单元；21、第二发送单元；22、停止测试单元；23、第一显示单元；24、统计单元；25、计算单元；26、第二显示单元；27、第四接收单元；28、记录保存单元；31、第五接收单元；32、解析单元；33、数据内容发送单元；34、第六接收单元；35、字符串生成单元；36、字符串发送单元；131、第一发送子单元；132、第二发送子单元；151、查找子单元；152、获取子单元；153、判断子单元；154、判定子单元；

具体实施方式

下面将结合本发明实施例中附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。通常在此处附图中描述和示出的本发明实施例的组件可以以各种不同的配置来布置和设计。因此，以下对在附图中提供的本发明的实施例的详细描述并非旨在限制要求保护的本发明的范围，而是仅仅表示本发明的选定实施例。基于本发明的实施例，本领域技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例，都属于本发明保护的范围。

为了便于对本发明的理解，首先对本发明提供的基带软件的自动化测试系统进行简要说明，其中，基带软件的自动化测试系统也可以称为带软件的自动化测试平台，该自动化测试系统实现了驱动程序的测试自动化；其中，驱动程序可以是嵌入式操作系统预设操作系统(也可以称为实时操作系统)上的外设程序，可以是Linux操作系统上的外设程序，也可以是操作系统上Android外设程序等；本实施例中，对驱动程序所使用的操作系统不做具体限制。

本实施例中的基带软件的自动化测试系统优选应用在卫星移动通信领域中；其中，基带软件为卫星移动通信中基带软件系统平台中的基带软件。另外，基带软件本身可以是被测试模块，其也可以预先存储在被测试模块中；相对应的，自动化测试系统可以直接对被测试的基带软件进行测试，也可以对被存储有基带软件的被测试模块进行测试。

本系统中主要包括三个重要部分，一是安装在PC(personal computer，个人计算机)侧的自动化测试工具；二是位于单板侧的预设操作系统中的监测模块(如shell任务)，其用于监听串口以及调用被测试模块所需的测试用例，其中，被测试模块即是预设操作系统上的外设驱动程序，本发明主要是对该被测试模块进行测试；三是PC端测试工具和单板侧的预设操作系统的通信协议。

综合系统的三个重要部分，本系统具有以下的特点：

1、测试用例能够自动执行，省时省力；

2、能够方便的添加和删除测试模块；

3、能够方便的添加和删除各个模块的测试用例；

4、能够灵活的控制测试流程，包括测试的开始，暂停，恢复等；

5、能够实时显示测试进度，通过进度条显示测试进展；

6、测试完成后，能够统计出测试用例成功、失败和skip个数(在计算机编程中为移位命令和放弃跳过的字符)，即测试用例异常的个数，计算出测试用例的成功率；

7、对于没有通过的测试用例，把测试用例的函数名称显示出来；

8、每个测试用例执行时间可以灵活调整；

9、测试用例通过脚本添加，用例名称和参数通过修改脚本的方式灵活改变；

10、充分利用预设操作系统中的监测模块对串口中的字符串进行解析；

11、预设操作系统上实现了应答包，当PC侧测试工具发送检查预设操作系统是否准备完成的命令时，应答包做出应答，测试可以开始进行；

12、预设操作系统实现心跳包，每隔一段时间，操作系统会向测试工具发送操作系统运行正常的消息，保证测试正常执行。

参考图1，本发明提供了一种基带软件的自动化测试方法，所述方法涉及测试工具侧，所述方法包括：

101、接收用户选择的被测试模块及各模块对应的测试用例。

具体的，测试工具是一个可视化的界面。在测试工具的开始菜单中选择导入选项，将写好的测试脚本导入，测试脚本导入之后，测试工具的最左侧一栏中将显示被测试模块和各个被测试模块对应的测试用例；此时，用户可以点击被测试的模块和对应的测试用例；其中，用户点击的即选中的被测试的模块和对应的测试用例，其在后续步骤中将被测试；没有被选中的模块和对应的测试用例不会被测试。

102、根据测试用例的函数名和/或函数参数，生成测试指示数据。

在用户选择了被测试的模块和对应的测试用例后，测试工具即获取用户选择的每一个测试用例的函数名和/或函数参数，然后将测试模块，该测试模块对应的测试用例的函数名，和该函数名对应的函数参数关联起来，并生成测试指示数据，并发送至监测模块，以便监测模块接收稿测试指示数据并进行解析。

103、向监测模块发送测试指示数据，以便监测模块将其对测试指示数据进行解析得到的数据内容发送给被测试模块以及根据接收的被测试模块反馈的执行对应的测试用例后的执行结果生成具有第一固定格式的字符串。

具体的，测试工具的功能包括字符串的发送，该测试工具先把PC侧的某个空闲串口打开，通过打开的该串口，向预设操作系统中的监测模块发送字符串。

具体的，测试工具发送的字符串至少包括测试用例的函数名，还可以包括测试用例函数参数；对于测试用例的函数名可以明确测试用例的，可只发送测试用例的函数名；对于测试用例的函数名仍然不能明确具体的测试用例的，可以发送测试用例函数名和测试用例函数参数；其中，测试用例函数参数又可以包括多个不同的参数；具体的，函数名和参数之间用空格隔开，函数参数与参数之间用逗号隔开，最后一个参数后不添加任何字符。

监测模块在接收到测试指示数据时，对该测试指示数据进行解析，得到数据内容(具体包括测试用例函数名和/或测试用例函数参数)，然后将解析得到的数据内容发送给被测试模块，以使得被测试模块根据该数据内容从其自身所在的预设操作系统中调用数据内容对应的测试用例，并执行该调用的测试用例，并将执行结果反馈给监测模块；此时，监测模块则可以根据上述执行结果生成具有第一固定格式的字符串并反馈给测试工具。

104、接收监测模块发送的具有第一固定格式的字符串，字符串携带有标识测试用例的执行是否成功的数据值。

具体的，监测模块在监测到被测试模块执行其调用的测试用例完成后，根据执行结果生成具有第一固定格式的字符串，并将该字符串发送至测试工具；该字符串中携带有表示测试用例是否通过的字段。

105、根据具有第一固定格式的字符串，判断测试用例是否通过。

本实施例中，测试工具接收到该具有第一固定格式的字符串，获取该字符串中的数据值，并判断该数据值是否与预设数据值相匹配，若匹配，则判定测试用例测试通过；若不匹配，则判定测试用例未通过。

为了更好的判断测试用例是否执行通过，本实施例中的步骤105优选采用下列方法实现，包括：

在字符串中查找第一预设标识字段，获取第一预设标识字段上的第一数据值，并判断第一数据值与第一预设数据值是否相匹配；

在检测到第一数据值与第一预设数据值相匹配时，判定测试用例执行成功；以及，在检测到第一数据值与第一预设数据值不匹配时，判定测试用例执行失败。

具体的，该测试工具的功能还包括判断测试用例是否通过，单板侧的监测模块获取到被测试模块(即驱动程序)执行测试用例的执行结果之后，通过串口将表示测试用例是否成功的字符串发给PC侧的测试工具；其中，监测模块发送的测试用例的执行结果采用与测试工具约定好的格式；而测试工具在接收到字符串后，根据双方约定的规则查找到表示测试用例是否通过的字段，并根据该字段中的内容作出判断；例如该字段中的数据值为零的话，表示测试用例通过，如果该字段中的值为非零，表示测试用例执行失败。

具体的，监测模块发送第一固定格式的字符串与测试工具解析该第一固定格式的字符串之间约定的通信协议即测试工具和预设操作系统(或者说监测模块)之间的第二个协议，具体如下：

为了让PC侧的测试工具能够判断出测试用例是否执行成功，我们在实现测试用例时，在测试用例返回之前，向串口发送表示用例执行是否成功的字符串，该字符串为固定格式，该格式为双方约定的规则。例如，将字符串的某领域设置为零表示用例执行成功，设置为非零表示用例执行失败。

测试工具发送完测试用例的字符串之后，等待预设操作系统返回用例执行结果，接收到结果后对测试结果进行分析，并将分析结果结果在测试工具的界面上显示出来，之后测试工具接着向串口发送下一个测试用例。

另外，现有技术中的VTS自动化测试过程较难控制，且测试用例的选择很不方便，并且一旦将测试用例加入VTS环境，该测试用例必须执行；此外，在VTS环境下，一旦有测试用例出现异常，例如测试用例被阻塞无法返回，将导致后续的测试用例均不能够执行，进而导致整个测试过程失败。

为了解决上述问题，如图2所示，本发明提供的基带软件的自动化测试方法还包括：

201、获取发送测试指示数据到接收该测试指示数据对应的反馈字符串时所用的测试时间。

202、判断测试时间是否与第一预设时间相匹配，在检测到测试时间小于或等于第一预设时间时，执行步骤203；否则执行步骤204。

203、判定测试用例执行正常，并根据具有第一固定格式的字符串判断测试用例是否通过。

204、判定测试用例执行异常，并继续向监测模块发送下一个测试指示数据。

具体的，通过该方法可以保证整个测试过程顺利进行，避免了由于当前测试用例执行异常(如测试用例被阻塞)而导致后续的测试无法测试的问题。

进一步的，如图3所示，步骤103中具体包括：

1031、向监测模块发送询问被测试模块是否正常启动的请求命令。

1032、在接收到监测模块发送的携带被测试模块正常启动的反馈信息时，向监测模块发送测试指示数据。

具体的，测试工具和预设操作系统(或者说监测模块)制定了多种通信协议，其中，第一个协议，包括预设操作系统测试环境是否准备完备的协议。协议实现如下，单板侧的预设操作系统启动正常后，会执行一个接收PC侧测试工具命令的任务(即监测模块执行该任务)，该任务处于阻塞状态，一直在等待测试工具发出询问系统是否正常启动的命令，一旦该任务接收到命令，系统会向测试工具发送系统已经正常启动的回复，测试工具在接收到该回复后，开始向预设操作系统发送测试指示数据。

如图4所示，为了保证测试的正常运行，本发明提供的基带软件的自动化测试方法还包括：

301、每隔第二预设时间接收监测模块发送的具有第二预设格式的心跳包；其中，第二预设格式与第一预设格式不同。

302、在心跳包中查找第二预设标识字段。

303、获取第二预设标识字段上的第二数据值。

304、判断第二数据值与第二预设数据值是否相匹配，在检测到第二数据值与第二预设数据值相匹配时，执行步骤305；否则，执行步骤306；

305、在检测到第二数据值与第二预设数据值相匹配时，向监测模块发送测试指示数据。

306、在检测到第二数据值与第二预设数据值不匹配时，停止测试。

具体的，该方法即测试工具和预设操作系统(或者说监测模块)制定的第三个协议，即为了保证在测试期间，被测试的预设操作系统一直处于正常运行状态，该预设操作系统实现了心跳包功能；具体的，监测模块每隔一段时间(即第二预设时间)，按照双方越好的固定格式向测试工具发送字符串，表示系统运行正常，测试工具接收到该字符串后，获知系统运行正常，可以正常下发测试用例，否则，测试工具停止测试。

需要说明的是，此处的心跳包具有第二预设格式，该第二预定格式与第一预定格式不同。另外，此处的第一预设时间是根据预设操作系统自身设置决定的，具体数值可以任意设置，而第一预设时间必须能够保证，在被测试模块执行测试用例正常时，从测试工具发送测试指示数据直至接收到监测模块发送的该测试指示数据对应的字符串的过程正常进行即可，在满足上述条件，第一预设时间同样可以任意设置，并且第二预设时间可以与第一预设时间相同，也可以不同，本实施例中是不同的。

具体的，本实施例中的第二预设时间，即预设操作系统每经过300个tick(即时钟的滴答声)，监测模块向测试工具发送具有第二预设格式的心跳包；其中，一个tick就是一个固定的时间长度；一个tick具体的时间长度，由操作系统的设置决定。tick为预设操作系统的相对时间单位，也被称为系统的时基，来源于定时器的周期性中断(输出脉冲)，一次中断表示一个tick，即一个“时钟滴答”或者时标。一个tick与具体时间的对应关系可在初始化定时器时设定，也就是说，tick所对应的具体时间长度是可以调整的。

一般来说，实时内核都提供相应的调整机制，应用可以根据特定情况改变tick对应的时间长度。例如，可以使系统5毫秒产生一个tick，也可以是10毫秒产生一个tick。tick的大小决定了整个系统的时间粒度。

为了使用户能够更好的了解使用本发明提供自动化测试方法，本发明中的测试工具还能够实时显示测试过程中用户选择的所有测试用例的测试进度以及已完成测试的所述测试用例所占的比例。

并且，PC侧的测试工具还具备统计功能，分别统计当前测试完成后的测试成功的测试用例数量、测试失败的测试用例数量以及测试异常的测试用例数量，并根据统计结果分别计算测试成功、测试失败以及测试异常的测试用例数量所自占据的比例，并实时显示测试成功、测试失败以及测试异常的测试用例数量所占据的比例。

此外，该测试工具还具备记录Log(即日志)的功能，将预设操作系统中被测试模块执行测试用例的运行过程中的Log记录下来，并保存到文件中，这样当测试用例失败时，可以根据该Log查找用例失败的具体地点。

如图5所示，本发明实施例还提供了一种基带软件的自动化测试方法，所述方法涉及监测模块，本实施例中，监测模块包括shell任务和串口，串口用于与测试工具实时通信，而shell任务不断对该串口进行监测，若监测到串口除有测试工具发送的信息(如测试指示数据)，则执行下面的操作步骤：

401、接收测试工具发送的测试指示数据，测试指示数据包括测试用例的函数名和/或函数参数。

402、对接收的测试指示数据进行解析，得到数据内容。

403、将解析得到的所述数据内容发送给被测试模块。

404、接收所述被测试模块反馈的执行对应的所述测试用例后的执行结果。

405、根据测试用例的执行结果生成具有第一固定格式的字符串，字符串携带有标识测试用例执行是否成功的数据值。

406、向测试工具发送具有第一固定格式的字符串，以便测试工具根据数据值判断测试用例是否通过。

具体的，监测模块中充分利用了预设操作系统中的Shell任务。预设操作系统启动后，shell任务已经启动并正常运行，shell任务的主要作用就是监听串口，一旦有数据从串口传输过来，shell任务会收集收到的数据，在接收到字符串结束符‘\n’后，shell任务会对字符串进行解析，解析后，如果发现收到的字符串是系统中的函数，则执行该函数，并把解析得到的参数传递过去。我们的测试系统就充分利用了系统自带的这个shell任务，利用该任务接收测试工具发送过来的函数名和参数，执行该函数。

下面，基于本发明实施例提供的基带软件的自动化测试系统及其测试方法进行简要说明：

本自动化测试系统在具体实施中，最重要的就是PC侧测试工具需要和预设操作系统约定好数据格式，即所谓的协议，这样双方才能够正常通信。协议内容主要包括以下几个方面：

第一，测试工具向系统发送检测命令，查询系统是否准备就绪，该命令格式需要双方约定；系统正常启动，系统向测试工具返回系统准备就绪的信息，这个信息格式也需要约定；

对于这种情况，我们约定如下，测试工具向预设操作系统下发的命令固定为字符串“testPrepareIsReady”，这个字符串在系统中是个函数，实现如下：

对应于该函数，系统中实现了另外一个函数“taskCommHands”，实现如下：

预设操作系统启动最后，会启动任务调用函数taskCommHands，从函数的实现可以看出，启用的任务一直处于PEND态(即悬而未决状态)，直到PC侧的测试工具发送字符串“testPripareIsReady”过来。预设操作系统的shell任务接收到该字符串之后进行解析，得到函数名和函数参数，根据函数名执行函数testPripareIsReady()；该函数会释放信号量g_testSemId，导致被阻塞的任务得到调度，taskCommHands()函数继续执行。

在函数taskCommHands()最后，宏TEST_PROTOCOL_SYSTEM_HANDS会被调用，这个宏就是系统和测试工具协商好的，用来输出系统已经准备就绪的消息，宏定义如下：

#define TEST_PROTOCOL_SYSTEM_HANDSprintf("$ACK\n")

预设操作系统的printf函数实现了将字符串从串口中输出的功能，这样字符串“$ACK|E\n”就被输出到测试工具。

“$ACK\n”即为双方约定好的格式，测试工具在发现第一个字符‘$’后知道该字符串为系统发送的反馈消息，需要自己来解析，接着的字符串“ACK”就是系统准备就绪，测试工具可以下发测试用例；之后的字符‘\n’表示字符串结束。

第二，用来表示系统运行正常的心跳包格式；为了让测试系统正常运行，预设操作系统需要定时向测试工具发送运行正常的消息，测试工具在收到心跳包之后，知道预设操作系统执行正常，测试可以继续执行。

向测试工具发送系统运行正常心跳包的宏定义如下：

#define TEST_PROTOCOL_SYSTEM_PULSEprintf("$ALV\n")

“$ALV\n”即为双方约定好的格式，测试工具在发现第一个字符‘$’后知道该字符串为系统发送的反馈消息，需要自己来解析，接着的字符串“ALV”就是系统运行正常，测试可以正常进行；之后的字符‘\n’表示字符串结束。

另外，系统固定时间向测试工具发送心跳包，表示系统运行正常的函数实现如下，

从函数的实现我们可以看出，每经过300个tick滴答声，系统会向测试工具发送表示系统运行正常的字符串“$ALV\n”。

第三，用来表示测试用例执行是否通过的数据格式；这个数据格式的约定最为重要，我们对这种数据格式约定如下：

#define TEST_PROTOCOL_SYSTEM_ACK(param)\

printf("$TST|％s|0x％x\n",__FUNCTION__,param)

在每个测试用例返回之前，我们都要调用这个宏，表示测试用例是否执行通过。下面我们详细解释下这个宏的含义。

字符串“$TST|％s|0x％x\n”的第一个字符为‘$’，测试工具在发现这个字符后知道该字符串为系统发送的反馈消息，需要自己来解析，后面的字符串”TST”表示这是个用来表示测试用例是否执行通过的协议；接着的字符串“％s”就是测试用例名称，这样在测试用例执行失败的情况下，我们就可以根据这个名称查找到失败的用例了；之后的字符‘0x％x’用来表示测试用例是否通过，我们约定该值为0时，表示测试用例执行通过，该值为非零时，表示测试用例执行失败，字符串中最后的字符’\n’表示字符串结束。

第四，用来表示需要测试工具记录的Log；我们对Log的定义如下：

#define TRACE_ERROR(fmt,args...)\

printf("$LOG|％s|％d|"fmt,__FUNCTION__,__LINE__,##args)

字符串“$LOG|％s|％d|”的第一个字符为‘$’，测试工具在发现这个字符后知道该字符串为系统发送的反馈消息，需要自己来解析，之后的字符串”LOG”表示这个字符串是用来记录Log的，接着的字符串“％s”就是测试用例名称，这样在测试用例执行失败的情况下，我们就可以根据这个Log查找到执行失败的函数了；之后的字符‘％d’用来函数的哪一行执行失败，字符串中最后的字符串”fmt”为程序要自家添加的字符串，用来记录自己希望得到的信息，该字符串的最后之所以没有字符’\n’，是因为大家在写代码时，输出语句有自动加上换行符‘/n’的习惯。

如图6所示，本发明实施例还提供了一种基带软件的自动化测试装置，包括：

第一接收单元11，用于接收用户选择的被测试模块及各模块对应的测试用例；

测试指示数据生成单元12，用于根据第一接收单元11接收的测试用例的函数名和/或函数参数，生成测试指示数据；

第一发送单元13，用于向监测模块发送测试指示数据生成单元12生成的测试指示数据，以便所述监测模块将其对所述测试指示数据进行解析得到的数据内容发送给所述被测试模块以及根据接收的所述被测试模块反馈的执行对应的所述测试用例后的执行结果生成具有第一固定格式的字符串；

第二接收单元14，用于接收监测模块发送的具有第一固定格式的字符串，字符串携带有标识测试用例的执行是否成功的数据值；

第一判断单元15，用于根据第二接收单元14的具有第一固定格式的字符串，判断测试用例是否通过。

进一步的，如图7所示，该基带软件的自动化测试装置还包括：

获取单元16，用于获取发送测试指示数据到接收该测试指示数据对应的反馈字符串时所用的测试时间。

判定单元17，用于在检测到测试时间小于或等于第一预设时间时，判定测试用例执行正常，并根据具有第一固定格式的字符串判断测试用例是否通过。

判定单元17还用于，在检测到测试时间大于第一预设时间时，判定测试用例执行异常，并向监测模块发送下一个测试指示数据。

进一步的，该基带软件的自动化测试装置中，如图8所示，第一发送单元13包括：

第一发送子单元131，用于向监测模块发送询问被测试模块是否正常启动的请求命令；

第二发送子单元132，用于在接收到监测模块发送的携带被测试模块正常启动的反馈信息时，向监测模块发送测试指示数据。

进一步的，如图8所示，该基带软件的自动化测试装置，第一判断单元15包括：

查找子单元151，用于在字符串中查找第一预设标识字段；

获取子单元152，用于获取查找子单元151查找的第一预设标识字段上的第一数据值；

判断子单元153，用于判断获取子单元152获取的第一数据值与第一预设数据值是否相匹配；

判定子单元154，用于在检测到第一数据值与第一预设数据值相匹配时，判定测试用例执行成功；

所述判定子单元154还用于，在检测到第一数据值与第一预设数据值不匹配时，判定测试用例执行失败。

进一步的，如图7所示，该基带软件的自动化测试装置还包括：

第三接收单元18，用于每隔第二预设时间接收监测模块发送的具有第二预设格式的心跳包；其中，第二预设格式与第一预设格式不同；

查找单元19，用于在第三接收单元18接收的心跳包中查找第二预设标识字段，获取第二预设标识字段上的第二数据值；

第二判断单元20，用于判断查找单元19查找的第二数据值与第二预设数据值是否相匹配；

第二发送单元21，用于在检测到第二数据值与第二预设数据值相匹配时，向监测模块发送测试指示数据；

停止测试单元22，用于在检测到第二数据值与第二预设数据值不匹配时，停止测试。

进一步的，如图9所示，该基带软件的自动化测试装置还包括：

第一显示单元23，用于实时显示测试过程中用户选择的所有测试用例的测试进度以及已完成测试的所述测试用例所占的比例；

统计单元24，用于分别统计当前已完成测试的测试成功的测试用例数量、测试失败的测试用例数量以及测试异常的测试用例数量；

计算单元25，用于根据统计单元24的统计结果分别计算测试成功、测试失败以及测试异常的测试用例数量所自占据的比例；

第二显示单元26，用于测试成功、测试失败以及测试异常的测试用例数量所占据的比例。

进一步的，如图9所示，该基带软件的自动化测试装置还包括：

第四接收单元27，用于接收监测模块发送的被测试模块执行测试用例时的运行日志；

记录保存单元28，用于记录并保存第四接收单元27接收的运行日志。

如图10所示，本发明实施例还提供了一种基带软件的自动化测试装置，包括：

第五接收单元31，用于接收测试工具发送的测试指示数据，测试指示数据包括测试用例的函数名和/或函数参数；

解析单元32，用于对接收单元31接收的测试指示数据进行解析，得到数据内容；

数据内容发送单元33，用于将解析单元32解析得到的所述数据内容发送给被测试模块；

第六接收单元34，用于接收所述被测试模块反馈的执行对应的所述测试用例后的执行结果；

字符串生成单元35，用于根据测试用例的执行结果生成具有第一固定格式的字符串，字符串携带有标识测试用例执行是否成功的数据值；

字符串发送单元36，用于向测试工具发送生成单元生成的具有第一固定格式的字符串，以便测试工具根据数据值判断测试用例是否通过。

下面结合本申请的提供的基带软件的自动化测试装置和系统，对本申请的自动化测试方法进行简要说明：

首先使用串口线将单板和PC机连接，连接时确认使用的串口没有被打开，否则PC侧的测试工具在打开串口的时候会遇到打开串口失败的问题。

启动单板，运行在单板上的预设操作系统开始运行，系统启动过程的最后，会启用任务taskTestStart，该任务被启用后处于阻塞状态，等待测试工具发送testPripareIsReady命令。

在PC上打开测试工具，测试工具在打开的过程中会发送testPrepareIsReady命令，此时单板侧的预设操作系统已经启动，系统中处于阻塞状态的任务taskTestStart在接收到testPrepareIsReady的命令后，返回字符串“$ACK\n”，测试工具在接收到这个字符串之后获知系统已经正常启动，可以进行测试了。

点击测试工具的开始键，测试开始执行。测试工具将脚本中设置的字符串通过串口发送给单板上的预设操作系统，预设操作系统中的shell任务在接收到字符串后进行解析，发现字符串是系统中的测试用例时，就执行测试用例，测试用例执行完毕返回之前调用宏TEST_PROTOCOL_SYSTEM_ACK(param)，向测试工具发送测试用例是否执行通过的信息，宏参数param如果为零，表示用例通过，param如果为非零，测试用例失败。

无论用例成功还是失败，测试工具对返回的信息解析完毕记录后，都会继续发送脚本中设置的下一个测试用例，预设操作系统接收下一测试用例并执行，然后再返回用例结果。在执行用例时，如果在设定的时间内用例没有返回系统约定的信息，测试工具认为用例执行失败，继续发送下一用例。

测试进行过程中，预设操作系统每隔一段时间会向测试工具发送表示“运行正常”的消息“$ALV\n”，测试工具接收到该消息后获知系统运行正常，测试可以正常进行，否则测试工具停止测试。

测试完成后，测试工具将测试成功的用例个数，失败的用例个数和没有测试的用例个数统计出来，并计算出各自在总用例中的比例，对于没有通过的用例，测试工具会将用例名记录下来，我们可以根据用例名找到测试失败的用例；同时，测试工具将系统中的Log记录了下来，这样我们不但可以根据Log查找到用例失败的具体位置还可以根据Log查看系统运行的轨迹。

本发明实施例提供的基带软件的自动化测试方法及装置，与现有技术中的两种自动化测试技术均存在相应的问题(如适用的软件环境单一和测试过程中的操作复杂繁琐)相比，其能够带来以下有益效果：

1、测试用例能够自动执行，省时省力；

2、能够适应较多种的软件环境；

3、能够方便的添加和删除测试模块以及各个测试模块的测试用例，无需更改较多代码，简化了测试的操作步骤，提高了测试效率。

4、在检测到发送测试指示数据到接收该测试指示数据对应的反馈字符串时所用的测试时间大于第一预设时间时，判定该测试用例执行异常，此时，跳过该测试用例，继续向监测模块发送下一个测试指示数据，使得整个测试过程顺利进行，避免了由于当前测试用例执行异常而导致后续的测试不能正常进行的问题。

5、能够灵活的控制测试流程，包括测试的开始，暂停和恢复等；

6、能够实时显示测试进度；

7、能够及时统计当前测试完成后的测试用例成功、失败和异常个数，并计算出测试用例的成功率；

8、对于没有通过的测试用例，能够将测试用例的函数名称显示出来；

9、每个测试用例及测试用例的执行时间可以灵活调整；

10、基带软件系统实现心跳包，每隔一段时间，监测模块会向测试工具发送基带软件系统(即被测试模块)运行正常的消息，保证测试的正常执行。

本发明实施例所提供的进行基带软件的自动化测试方法的计算机程序产品，包括存储了程序代码的计算机可读存储介质，所述程序代码包括的指令可用于执行前面方法实施例中所述的方法，具体实现可参见方法实施例，在此不再赘述。

所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统、装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

在本申请所提供的几个实施例中，应该理解到，所揭露的系统、装置和方法，可以通过其它的方式实现。以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，又例如，多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些通信接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本发明各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。

所述功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本发明各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。

以上所述，仅为本发明的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应以所述权利要求的保护范围为准。

Claims (10)

1.一种基带软件的自动化测试方法，其特征在于，包括：

接收用户选择的被测试模块及各模块对应的测试用例；

根据所述测试用例的函数名和/或函数参数，生成测试指示数据；

向监测模块发送所述测试指示数据，以便所述监测模块将其对所述测试指示数据进行解析得到的数据内容发送给所述被测试模块以及根据接收的所述被测试模块反馈的执行对应的所述测试用例后的执行结果生成具有第一固定格式的字符串；

接收监测模块发送的所述具有第一固定格式的字符串，所述字符串携带有标识测试用例的执行是否成功的数据值；

根据具有第一固定格式的所述字符串，判断所述测试用例是否通过。

2.根据权利要求1所述的基带软件的自动化测试方法，所述方法还包括：

获取发送所述测试指示数据到接收该测试指示数据对应的反馈字符串时所用的测试时间；

在检测到所述测试时间小于或等于第一预设时间时，判定所述测试用例执行正常，并根据具有第一固定格式的所述字符串判断所述测试用例是否通过；以及，

在检测到所述测试时间大于所述第一预设时间时，判定所述测试用例执行异常，并向监测模块发送下一个所述测试指示数据。

3.根据权利要求1所述的基带软件的自动化测试方法，其特征在于，所述向监测模块发送所述测试指示数据，包括：

向所述监测模块发送询问所述被测试模块是否正常启动的请求命令；

在接收到所述监测模块发送的携带所述被测试模块正常启动的反馈信息时，向所述监测模块发送所述测试指示数据。

4.根据权利要求2或3所述的基带软件的自动化测试方法，其特征在于，所述根据具有第一固定格式的所述字符串，判断所述测试用例是否通过，包括：

在所述字符串中查找第一预设标识字段，获取所述第一预设标识字段上的第一数据值；

判断所述第一数据值与第一预设数据值是否相匹配；

在检测到所述第一数据值与所述第一预设数据值相匹配时，判定所述测试用例执行成功；以及，

在检测到所述第一数据值与所述第一预设数据值不匹配时，判定所述测试用例执行失败。

5.根据权利要求4所述的基带软件的自动化测试方法，其特征在于，所述方法还包括：

每隔第二预设时间接收所述监测模块发送的具有第二预设格式的心跳包；其中，所述第二预设格式与所述第一预设格式不同；

在所述心跳包中查找第二预设标识字段，获取所述第二预设标识字段上的第二数据值；

判断所述第二数据值与第二预设数据值是否相匹配；

在检测到所述第二数据值与所述第二预设数据值相匹配时，向所述监测模块发送所述测试指示数据；以及，

在检测到所述第二数据值与所述第二预设数据值不匹配时，停止测试。

6.根据权利要求5所述的基带软件的自动化测试方法，其特征在于，所述方法还包括：

实时显示测试过程中用户选择的所有测试用例的测试进度以及已完成测试的所述测试用例所占的比例；

分别统计当前已完成测试的测试成功的测试用例数量、测试失败的测试用例数量以及测试异常的测试用例数量，并根据统计结果分别计算测试成功、测试失败以及测试异常的测试用例数量所占据的比例；

实时显示测试成功、测试失败以及测试异常的测试用例数量所占据的比例。

7.根据权利要求6所述的基带软件的自动化测试方法，其特征在于，所述方法还包括：

将接收的所述监测模块发送的所述被测试模块执行所述测试用例时的运行日志进行记录和保存。

8.一种基带软件的自动化测试方法，其特征在于，包括：

接收测试工具发送的测试指示数据，所述测试指示数据包括测试用例的函数名和/或函数参数；

对接收的所述测试指示数据进行解析，得到数据内容；

将解析得到的所述数据内容发送给被测试模块；

接收所述被测试模块反馈的执行对应的所述测试用例后的执行结果；

根据所述测试用例的执行结果生成具有第一固定格式的字符串，所述字符串携带有标识测试用例执行是否成功的数据值；

向所述测试工具发送具有第一固定格式的所述字符串，以便所述测试工具根据所述数据值判断所述测试用例是否通过。

9.一种基带软件的自动化测试装置，其特征在于，包括：

第一接收单元，用于接收用户选择的被测试模块及各模块对应的测试用例；

测试指示数据生成单元，用于根据所述第一接收单元接收的所述测试用例的函数名和/或函数参数，生成测试指示数据；

第一发送单元，用于向监测模块发送所述生成单元生成的所述测试指示数据，以便所述监测模块将其对所述测试指示数据进行解析得到的数据内容发送给所述被测试模块以及根据接收的所述被测试模块反馈的执行对应的所述测试用例后的执行结果生成具有第一固定格式的字符串；

第二接收单元，用于接收监测模块发送的所述具有第一固定格式的字符串，所述字符串携带有标识测试用例的执行是否成功的数据值；

第一判断单元，用于根据所述第二接收单元的具有第一固定格式的所述字符串，判断所述测试用例是否通过。

10.一种基带软件的自动化测试装置，其特征在于，包括：

第五接收单元，用于接收测试工具发送的测试指示数据，所述测试指示数据包括测试用例的函数名和/或函数参数；

解析单元，用于对所述接收单元接收的所述测试指示数据进行解析，得到数据内容；

数据内容发送单元，用于将所述解析单元解析得到的所述数据内容发送给被测试模块；

第六接收单元，用于接收所述被测试模块反馈的执行对应的所述测试用例后的执行结果；

字符串生成单元，用于根据所述第六接收单元接收的所述测试用例的执行结果生成具有第一固定格式的字符串，所述字符串携带有标识测试用例执行是否成功的数据值；

字符串发送单元，用于向所述测试工具发送所述字符串生成单元生成的具有第一固定格式的所述字符串，以便所述测试工具根据所述数据值判断所述测试用例是否通过。