CN103019939A - 一种测试驱动程序的方法及系统 - Google Patents

Abstract

本发明公开了一种测试驱动程序的方法及系统，包括：向驱动程序发送测试参数；接收驱动程序根据测试参数发送的命令帧；向驱动程序发送预设响应帧，预设响应帧对应有期望输出，期望输出为在驱动程序正确的情况下处理完预设响应帧后输出的结果；获取驱动程序根据预设响应帧所输出的实际输出；当实际输出符合期望输出时，则输出驱动程序正确；当实际输出不符合期望输出时，则输出驱动程序错误。本发明可以通过预设响应帧来模拟硬件无法实现的场景，从而可以全面的对驱动程序进行测试，排除了测试过程操作硬件带来的局限，减少人工输入测试参数及比对测试结果的工作量，因此，本发明提供的方案可以全面的测试驱动程序，并提高测试精度和测试效率。

Description

一种测试驱动程序的方法及系统

技术领域

本发明涉及程序测试领域，更具体的说，涉及测试驱动程序的方法及系统。

背景技术

驱动程序，是上位机（PC端）实现的程序，以一定的通讯协议发送命令给下位机（嵌入式系统或单片机，下位机处理的程序下文称作硬件程序），达到控制硬件输出的目的。驱动程序一般以接口（函数）的方式提供给上层用户调用。

驱动程序测试，主要是测试上位机（PC端）程序控制硬件设备的功能性，是否能为上层用户提供功能正确、性能优越的控制程序。

现在的驱动程序测试的一般方法是：

步骤一，测试的输入：接口的输入参数，硬件的（初始或执行中）状态；

步骤二，检查是否符合期望输出结果：接口的输出参数和返回值，硬件的最终状态，硬件的表现（动作、输出等等）。

例如，测试打印机在正常状态下的打印功能，需要如下步骤：

步骤一，传入接口输入参数：打印字符串“abcd”；设置硬件状态的输入：纸源充足，设备正常。

步骤二，检查是否与期望输出一致，硬件输出：输出一张纸，“abcd”在页面首行打印，接口参数内容输出：本次接口调用成功，没有故障信息。

请参见图1所示，图1所示的为一般的驱动程序测试系统及其数据流，包括如下步骤：

1、上层理解的指令下发给驱动程序；

2、驱动程序将上层理解的指令翻译打包成硬件程序理解的指令，并按协议规定的握手方式下发各硬件程序；

3、硬件的初始或执行中的状态会影响到硬件程序处理指令的结果；

4、硬件程序处理指令，完成控制硬件的目的，硬件最终通过一定的状态、动作和输出表现；

5、硬件的输出信息（硬件实时状态和实际执行结果）反馈给硬件程序；

6、硬件程序根据硬件的反馈信息和内部执行过程产生的信息，生成指令的执行结果，已协规定的数据帧格式和握手方式回传给驱动程序；

7、驱动程序按相同的握手方式接收硬件程序返回的命令响应数据帧，按照协议解析成上层理解的响应信息，最终以接口输出参数和返回值的形式输出。

在对现有技术的研究和实践过程中，本发明的发明人发现现有技术存在以下问题：

从输入和期望输出内容分析，测试人员重点关注的地方集中在接口和硬件表现，而在输入和输出之间，数据流是经过复杂的转换的，一般测试并不能全面覆盖这个过程的，此时在输入和期望输出之间产生了一个大黑盒，中间数据流的各个处理流程是否正确，只通过接口和硬件的输出检查是不能准确测试的，在实际测试过程中，遍历所有输入和输出情况的效率是很低的，而且硬件内部状态的不确定性导致测试人员无法遍历所有硬件状态的输入。

因此，提出一种的测试精度高，测试效率高，测试全面的驱动程序的方法和测试系统是非常必要的。

发明内容

有鉴于此，本发明的设计目的在于，提供一种测试驱动程序的方法及系统，以全面的测试驱动程序，并提高测试精度和测试效率。

本发明实施例是这样实现的：

一种测试驱动程序的方法，包括：

向所述驱动程序发送测试参数；

接收所述驱动程序根据所述测试参数发送的命令帧；

向所述驱动程序发送预设响应帧，所述预设响应帧对应有期望输出，所述期望输出为在所述驱动程序正确的情况下处理完所述预设响应帧后输出的结果；

获取所述驱动程序根据所述预设响应帧所输出的实际输出；

当所述实际输出符合所述期望输出时，则输出所述驱动程序正确；

当所述实际输出不符合所述期望输出时，则输出所述驱动程序错误。

优选地，当所述预设响应帧的内容为设备状态异常时，则所述期望输出具体为输出所述设备状态异常。

优选地，当所述预设响应帧的内容为设备状态正常时，则所述期望输出具体为输出所述设备状态正常。

优选地，当所述预设响应帧的格式错误时，则所述期望输出具体为输出所述预设响应帧的格式出现错误。

优选地，当所述预设响应帧的格式正确时，则所述期望输出具体为输出所述预设响应帧的格式正确。

优选地，当所述预设响应帧的握手协议时序错误时，则所述期望输出具体为输出所述预设响应帧的握手协议时序出现错误。

优选地，当所述预设响应帧的握手协议时序正确时，则所述期望输出具体为输出所述预设响应帧的握手协议时序正确。

一种测试系统，包括：

第一发送模块，用于向所述驱动程序发送测试参数；

接收模块，用于接收所述驱动程序根据所述测试参数发送的命令帧；

第二发送模块，用于向所述驱动程序发送预设响应帧，所述预设响应帧对应有期望输出，所述期望输出为在所述驱动程序正确的情况下处理完所述预设响应帧后输出的结果；

获取模块，用于获取所述驱动程序根据所述预设响应帧所输出的实际输出；

判断模块，用于判断所述实际输出是否符合所述期望输出；

输出模块，用于当所述实际输出符合所述期望输出时，则输出所述驱动程序正确；当所述实际输出不符合所述期望输出时，则输出所述驱动程序错误。

与现有技术相比，本实施例提供的技术方案具有以下优点和特点：

在本发明提供的方案中，通过预设响应帧来模拟硬件输出的真实响应帧，可以模拟硬件将常规或异常的预设响应帧反馈给驱动程序，而且可以通过预设响应帧来模拟硬件无法实现的场景，从而可以全面的对驱动程序进行测试，排除了测试过程操作硬件带来的局限，减少人工输入测试参数及比对测试结果的工作量，因此，本发明提供的方案可以全面的测试驱动程序，并提高测试精度和测试效率。

附图说明

为了更清楚地说明本发明或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1为本发明所提供的现有驱动程序测试系统及其数据流程图；

图2为本发明所提供的一种测试驱动程序的方法的流程图；

图3为本发明所提供的另一种测试驱动程序的方法的流程图；

图4为本发明所提供的一种测试系统的模块图；

图5为本发明所提供的又一种测试驱动程序的方法的流程图；

图6为本发明所提供的正常的握手时序示意图；

图7为本发明所提供的异常的握手时序示意图；

图8为本发明所提供的又一种测试驱动程序的方法的流程图；

图9为本发明所提供的命令帧或响应帧的协议格式示意图。

图10为本发明所提供的另一种测试系统的模块图。

具体实施方式

下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

本发明实施例提供了一种测试驱动程序的方法，以全面的测试驱动程序，并提高测试精度和测试效率。由于上述测试驱动程序的方法的具体实现存在多种方式，下面通过具体实施例进行详细说明：

实施例一

请参见图2所示，图2所示的为一种测试驱动程序的方法，应用于测试系统，包括：

步骤S21、向所述驱动程序发送测试参数；

其中，本实施例中提到的测试系统为用于模拟真实硬件的虚拟系统，属于测试软件，下面的实施例会对该测试系统做详细说明。

测试系统可以预先将所有的测试参数存放在数据库或表格中，例如Excel表格中。在测试系统发送测试参数时，需要从数据库或表格中按照存储的顺序来读取测试参数，然后测试系统再向驱动程序发送刚刚读取到的测试参数。

步骤S22、接收所述驱动程序根据所述测试参数发送的命令帧；

其中，驱动程序在接收到测试参数后，需要对测试参数进行分析，驱动程序根据测试参数来向测试系统发送命令帧。

步骤S23、向所述驱动程序发送预设响应帧，所述预设响应帧对应有期望输出，所述期望输出为在所述驱动程序正确的情况下处理完所述预设响应帧后输出的结果；

其中，预设响应帧是为测试系统模拟真实硬件所发出响应帧，而且，甚至可以完全模拟实际硬件设备无法通过手工模拟的情况。期望输出是在驱动程序正确的情况下处理完预设响应帧后输出的结果，所以期望输出可以理解为如果驱动程序是正确无误的，那么在驱动程序收到预设响应帧后，应该输出的结果，所以期望输出是一个理想状态下驱动程序输出的结果。那么预设响应帧与期望输出是相对应的关系。

对于需要测试驱动程序的不同方面，那么测试系统也会对预设响应帧做对应的调整。例如，对于测试驱动程序分析硬件响应帧内容的准确性方面，可以将预设响应帧的内容设置为设备状态异常或正常，那么期望输出的内容就为设备状态异常或正常，从而通过对比期望输出和实际输出的结果，就可判断出驱动程序是否能够识别出设备状态的异常或正常。对于测试通讯链路层的握手协议时序的准确性，可以将预设响应帧的内容设置为握手协议时序，那么期望输出的内容就为握手协议时序正确或错误，从而通过对比期望输出和实际输出的结果，就可判断出驱动程序是否能够识别出握手协议时序的正确或错误。对于测试响应帧格式解析的准确性，可以将预设响应帧设置为数据帧格式正确或错误，那么期望输出的内容就为数据帧格式正确或错误，从而通过对比期望输出和实际输出的结果，就可判断出驱动程序是否能够识别出数据帧格式的准确性。下文将会通过具体的实例进行说明。

步骤S24、获取所述驱动程序根据所述预设响应帧所输出的实际输出；

其中，实际输出为驱动程序在接收了预设响应帧后真实输出的结果，这个实际输出与期望输出可能相同，也可能不同。

步骤S25、当所述实际输出符合所述期望输出时，则输出所述驱动程序正确；

其中，期望输出为驱动程序在理想状态下的输出结果，而且在设计驱动程序的时候，就是希望驱动程序能够在接收预设响应帧的情况下来输出期望输出，所以如果实际输出的结果与期望输出相符合时，则可以说明驱动程序是正确的。

步骤S26、当所述实际输出不符合所述期望输出时，则输出所述驱动程序错误。

其中，基于步骤S25中的理由，如果实际输出不符合期望输出，那么说明驱动程序是错误的。

在图2所示的实施例中，通过预设响应帧来模拟硬件输出的真实响应帧，可以模拟硬件将常规或异常的预设响应帧反馈给驱动程序，而且可以通过预设响应帧来模拟硬件无法实现的场景，从而可以全面的对驱动程序进行测试，排除了测试过程操作硬件带来的局限，减少人工输入测试参数及比对测试结果的工作量，因此，本发明提供的方案可以全面的测试驱动程序，并提高测试精度和测试效率。

实施例二

请参见图3所示，图3所示的为一种测试驱动程序的方法，应用于测试系统，具体用于测试驱动程序的分析硬件响应包内容的准确性。

本实施的测试也可直接通过对硬件测试实现，但是硬件初始或执行中状态的输入，只能通过人工操作外在的硬件实现，而这种人工式的操作是无法覆盖通讯协议中所有指令的响应数据集的内容，所以采用对真实硬件进行测试的效果不佳。

具体的，本实施例提供的测试方法包括以下步骤：

步骤S31、向驱动程序的接口传入测试用例要求的输入参数，执行驱动程序的接口函数。

步骤S32、按照用例的要求，测试人员修改虚拟设备返回给驱动程序的响应包内容。

步骤S33、检查驱动程序的输出结果是否符合用例的期望结果，若是，驱动程序对响应数据的处理是准确按照通信协议和指令集执行的，否则，驱动程序对响应数据的分析存在缺陷。

步骤S34、配合自动化测试脚本，枚举硬件所有可能返回的响应包，包括正常数据和异常数据，大批量地执行测试用例。

下面通过具体实例来详细的说明图3所示的方案。

请参见图4所示，图4所示的为本实施例提到的测试系统，该测试系统包括待测试驱动程序12、虚拟通信模块13、虚拟硬件程序的软件14和自动化测试脚本11，下文将虚拟硬件程序的软件14统一简称为“虚拟设备”。

在图4所示的方案中，自动化测试脚本，这里选用QTP（Quick TestProfessional）脚本实现，在系统中担任控制输入和评价结果的角色，共承担三个主要任务，传递驱动程序的输入参数，通过虚拟设备确定硬件设备需返回的数据，比对实际输出和期望结果的差异判断用例执行是否通过。

虚拟设备，它是完全独立于驱动程序的另一个进程，必须拥有以下功能，第一，自动接收从驱动程序下发的数据，自动向驱动程序发送数据；第二，用户可通过软件的界面设定返回给驱动程序的数据（任意数据），第三，用户可通过软件的界面设定数据返回的时间间隔。

虚拟通讯模块，它建立起虚拟设备和驱动程序两个进程之间通讯的桥梁，可采用临界区资源访问互斥的方式，实现进程间通讯。

表1

本测试系统运行的测试用例如表1所示，具体的测试过程为：

步骤一，将所有测试用例保存在Excel表格中，如测试Print(char*string)接口。

步骤二，QTP脚本读取表的第一行内容，将输入参数传给驱动程序的接口，执行接口。

步骤三，虚拟设备受到驱动程序的命令后，QTP脚本根据表格中的值控制虚拟设备向驱动程序返回需要的值。

步骤四，接口执行完成后，QTP脚本对比期望结果和实际输出的值，判别该用例是否通过。

步骤五，QTP脚本循环读取Excel表格中的用例，转至步骤一，开始执行下一个用例，直到所有用例执行完毕。

具体的，以表1中测试用例为例，步骤三虚拟设备收到驱动程序的命令帧后，根据用例中要求的值“缺纸传感器=1”，将打印机缺纸的信息以及Print接口执行情况的信息组帧，返回给驱动程序。步骤三可完全模拟实际硬件设备无法通过手工模拟的情况。

实施例三

在实施例二中，虚拟设备只模拟响应包数据域的内容，忽略了握手协议异常情况模拟，虚拟设备与驱动之间的通讯默认在正常情况下的握手过程中进行。实施例二中的虚拟设备无法对驱动程序的握手协议进行测试。所以本实施例在实施例二提出的驱动设备测试系统的基础上，继续提出另一种驱动测试方法，沿用测试系统的四大模块结构：待测试驱动程序，虚拟通信模块软件，虚拟设备，及自动化测试脚本，只是对虚拟设备部分重新设计，令虚拟设备模拟硬件的通讯握手协议层。

请参见图5所示，图5所示的为一种测试驱动程序的方法，应用于测试系统，具体用于测试通讯链路层的握手协议的准确性。本实施例提供的测试方法包括以下步骤：

步骤S41，按测试用例要求，执行驱动程序的接口函数。

步骤S42，虚拟设备收到驱动程序发过来的命令帧后，按测试用例要求，虚拟设备向驱动程序发送应答帧。

步骤S43，观察驱动程序的输出结果。

步骤S44，配合自动化测试脚本批量执行用例，对虚拟设备枚举硬件通讯握手协议层的各种应答时序，测试驱动程序是否完全覆盖对各种正常及异常应答时序的处理。

下面通过具体实例来详细的说明图5所示的方案。

请参见图6和图7所示，图6所示的为正常的握手时序示意图，图7所示的为异常的握手时序示意图。

表2

本测试系统运行的测试用例如表2所示，具体的测试过程为：

步骤一，将所有案例存入表格中，与实施例二不同的是，虚拟设备设置一列的参数变成了各应答包的时序，其中，表中的用例具体为图7中异常时序的用例。

步骤二，QTP脚本读取输入数据，执行接口。

步骤三，虚拟设备接收到驱动程序下发的一序列命令帧，QTP脚本按照“虚拟设备设置”的应答帧时序，返回给驱动程序。

步骤四，QTP脚本比较输出和期望结果，判断用例是否执行通过。

步骤五，QTP脚本循环读取Excel表格中的用例，转至步骤一，开始执行下一个用例，直到所有用例执行完毕。

具体的，针对表中的案例，步骤三的执行过程如下，

(1)虚拟设备第一次收到命令包时返回NAK，期望结果是驱动程序重发命令包，如果驱动程序没有缺陷，转至(2)，否则，转至步骤四，

(2)虚拟设备第二次收到命令包仍返回NAK，期望结果是驱动程序重发命令包，如果驱动程序没有缺陷，转至(3)，否则，转至步骤四，

(3)虚拟设备第三次收到命令包时返回ACK，期望结果是驱动程序发送ENQ，如果驱动程序没有缺陷，转至(4)，否则，转至步骤四，

(4)虚拟设备收到ENQ后，返回硬件程序执行结果的响应帧，转至步骤四。

实施例四

在实施例二中，虚拟设备只模拟响应包数据域的内容，忽略了命令包和响应包格式的异常情况模拟，虚拟设备与驱动之间的通讯默认在正常情况下的握手过程中进行。实施例二中的虚拟设备无法对驱动程序的握手协议进行测试。所以本实施例在实施例二提出的驱动设备测试系统的基础上，继续提出另一种驱动测试方法，沿用测试系统的四大模块结构：待测试驱动程序，虚拟通信模块软件，虚拟设备，及自动化测试脚本，只是对虚拟设备部分重新设计，令虚拟设备模拟硬件的通讯握手协议层。

请参见图8所示，图8所示的为一种测试驱动程序的方法，应用于测试系统，具体用于解析硬件返回响应包的准确性。本实施例提供的测试方法包括以下步骤：

步骤S51，按测试用例要求，执行驱动程序的接口函数。

步骤S52，按照握手协议规定的正常时序，虚拟设备向驱动程序返回正常或异常格式的应答帧。

步骤S53，观察驱动程序的输出结果。

步骤S54，配合自动化测试脚本批量执行用例，虚拟设备向驱动程序遍历各种正常或异常格式的应答帧，测试驱动程序对帧格式的解析是否存在缺陷。

下面通过具体实例来详细的说明图8所示的方案。

命令帧或响应帧的协议格式一般如图9，具体地，例如，协议规定，响应帧的格式中数据域的实际长度与数据长度必须保持一致，如果数据域的实际长度与数据长度不一致，驱动需判定该响应帧非法。又例如，响应帧的校验值必须与数据域的内容相符，如果数据帧中的某些字节数据被篡改，导致计算的校验值与保存的校验值不一致，也认为该响应帧非法。

表3

本测试系统运行的测试用例如表3所示，具体的测试过程为：

步骤一，将所有案例存入表格中，“虚拟设备设置”一列的参数变为与帧格式相关的参数值。

步骤二，QTP脚本读取输入数据，执行接口。

步骤三，虚拟设备收到命令帧后，QTP脚本根据“虚拟设备设置”的内容要求，设置虚拟设备的响应帧，并返回给驱动程序。

步骤四，QTP脚本比较输出和期望结果判断用例是否执行通过。

步骤五，QTP脚本循环读取Excel表格中的用例，转至步骤一，开始执行下一个用例，直到所有用例执行完毕。

具体的，针对表3中的案例，步骤三的执行过程如下，

(1)响应帧的数据长度域的值设为10，而数据域的内容只填入“abcd”四个字符，响应帧的其他数据按协议正确设置；

(2)虚拟设备将(1)中自定义的响应帧返回给驱动程序；

(3)进入步骤四。

实施例五

请参见图10所示，图10所示的为一种测试系统2，该测试系统2包括第一发送模块21，用于向所述驱动程序3发送测试参数；接收模块22，用于接收所述驱动程序3根据所述测试参数发送的命令帧；第二发送模块23，用于向所述驱动程序3发送预设响应帧，所述预设响应帧对应有期望输出，所述期望输出为在所述驱动程序3正确的情况下处理完所述预设响应帧后输出的结果；获取模块24，用于获取所述驱动程序3根据所述预设响应帧所输出的实际输出；判断模块25，用于判断所述实际输出是否符合所述期望输出；输出模块26，用于当所述实际输出符合所述期望输出时，则输出所述驱动程序3正确；当所述实际输出不符合所述期望输出时，则输出所述驱动程序3错误。

由于图10所示的实施例中的测试系统2的各个模块的功能与实施例一的方法相对应，所以关于各个模块的具体功能请与实施例一相互参见即可。

综上所述，本发明提出的一种测试驱动程序的方法和测试系统，是通过软件方式模拟硬件的通讯方式、模拟真实硬件无法实现的场景，该系统可模拟硬件返回任意常规或异常的数据，满足了测试有关驱动程序和硬件设备之间通讯的充分性要求，并根据设备驱动程序测试系统三个独立部分的特性，应用相应的测试方法，使测试更全面地覆盖驱动程序代码的关键内容，排除了测试过程操作硬件带来的局限，该系统同时应用自动化测试方法，减少人工输入测试数据及比对测试结果的工作量，极大程度地提升了设备驱动程序测试的充分性和效率。

需要说明的是，图1至图10所示的实施例只是本发明所介绍的优选实施例，本领域技术人员在此基础上，完全可以设计出更多的实施例，因此不在此处赘述。

对这些实施例的多种修改对本领域的专业技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本发明的精神或范围的情况下，在其它实施例中实现。因此，本发明将不会被限制于本文所示的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。

Claims (8)

1.一种测试驱动程序的方法，其特征在于，包括：

向所述驱动程序发送测试参数；

接收所述驱动程序根据所述测试参数发送的命令帧；

向所述驱动程序发送预设响应帧，所述预设响应帧对应有期望输出，所述期望输出为在所述驱动程序正确的情况下处理完所述预设响应帧后输出的结果；

获取所述驱动程序根据所述预设响应帧所输出的实际输出；

当所述实际输出符合所述期望输出时，则输出所述驱动程序正确；

当所述实际输出不符合所述期望输出时，则输出所述驱动程序错误。

2.根据权利要求1所述的测试驱动程序的方法，其特征在于，当所述预设响应帧的内容为设备状态异常时，则所述期望输出具体为输出所述设备状态异常。

3.根据权利要求1所述的测试驱动程序的方法，其特征在于，当所述预设响应帧的内容为设备状态正常时，则所述期望输出具体为输出所述设备状态正常。

4.根据权利要求1所述的测试驱动程序的方法，其特征在于，当所述预设响应帧的格式错误时，则所述期望输出具体为输出所述预设响应帧的格式出现错误。

5.根据权利要求1所述的测试驱动程序的方法，其特征在于，当所述预设响应帧的格式正确时，则所述期望输出具体为输出所述预设响应帧的格式正确。

6.根据权利要求1所述的测试驱动程序的方法，其特征在于，当所述预设响应帧的握手协议时序错误时，则所述期望输出具体为输出所述预设响应帧的握手协议时序出现错误。

7.根据权利要求1所述的测试驱动程序的方法，其特征在于，当所述预设响应帧的握手协议时序正确时，则所述期望输出具体为输出所述预设响应帧的握手协议时序正确。

8.一种测试系统，其特征在于，包括：

第一发送模块，用于向所述驱动程序发送测试参数；

接收模块，用于接收所述驱动程序根据所述测试参数发送的命令帧；

第二发送模块，用于向所述驱动程序发送预设响应帧，所述预设响应帧对应有期望输出，所述期望输出为在所述驱动程序正确的情况下处理完所述预设响应帧后输出的结果；

获取模块，用于获取所述驱动程序根据所述预设响应帧所输出的实际输出；

判断模块，用于判断所述实际输出是否符合所述期望输出；

输出模块，用于当所述实际输出符合所述期望输出时，则输出所述驱动程序正确；当所述实际输出不符合所述期望输出时，则输出所述驱动程序错误。

Images