CN110032508B - 功能驱动程序测试方法、装置、终端设备及存储介质 - Google Patents

Abstract

本申请适用于程序测试技术领域，提供了一种功能驱动程序测试方法、终端设备及存储介质，其中，功能驱动程序测试方法包括：监听功能驱动程序的输入输出请求包；当根据预设的过滤控制条件丢弃输入输出请求包时，触发收发重试流程；判断是否收到功能驱动程序重发的各个输入输出请求包；当未收到所述功能驱动程序重发的任一输入输出请求包时，判定收发重试流程在过滤控制条件下未通过测试。本申请实施例提供的功能驱动程序测试方法，通过过滤控制条件能够主动并可控地丢弃功能驱动程序的输入输出请求包，从而实现触发功能驱动程序中重试流程的外部条件，解决了现有技术不能主动触发收发重试流程的问题。

Description

功能驱动程序测试方法、装置、终端设备及存储介质

技术领域

本申请属于程序测试技术领域，尤其涉及一种功能驱动程序测试方法、终端设备及存储介质。

背景技术

功能驱动程序是一个设备(例如POS机)的主要驱动程序，简称驱动或驱动程序。它提供对一个设备进行读写访问的操作接口，用于设备与操作系统中现成的、特定的总线驱动程序进行交互。数据传输通常是功能驱动程序的核心事务，数据传输的可靠性是功能驱动程序的重要指标。功能驱动程序一般通过重试流程来保证数据传输的可靠性，重试流程包括发送重试流程和接收重试流程，简称收发重试流程。常规的对功能驱动程序中的收发重试流程进行测试的方法，主要依靠长时间大数据量收发交互测试来验证，或者是采用多台设备在多种不同的环境下进行收发交互测试来验证。

收发重试流程需要在接收或发送出现超时或错误的特殊情景下才被触发，而该情景在常规环境下出现的几率通常极低，因此，上述两种常规的测试方法具有明显的被动性，且测试工作量巨大、测试效率较低，不易发现收发重试流程中隐藏的问题，从而造成测试遗漏。

发明内容

有鉴于此，本申请实施例提供了一种功能驱动程序测试方法、终端设备及存储介质，以解决现有技术不能主动触发收发重试流程的问题。

根据第一方面，本申请实施例提供了一种功能驱动程序测试方法，包括：监听功能驱动程序的输入输出请求包；当根据预设的过滤控制条件丢弃所述输入输出请求包时，触发收发重试流程；判断是否收到所述功能驱动程序重发的各个输入输出请求包，所述功能驱动程序重发的各个输入输出请求包分别与丢弃的各个输入输出请求包对应；当未收到所述功能驱动程序重发的任一输入输出请求包时，判定所述收发重试流程在所述过滤控制条件下未通过测试。

本申请实施例提供的功能驱动程序测试方法，通过过滤控制条件能够主动并可控地丢弃功能驱动程序的输入输出请求包，从而实现触发功能驱动程序中重试流程的外部条件，解决了现有技术不能主动触发收发重试流程的问题。由于本申请实施例提供的功能驱动程序测试方法能够以设定的任意概率来模拟和复现实际运行环境中出现概率极低的传输不稳定问题，从而可以快速和准确地检测出功能驱动程序的重试流程中深入隐藏的缺陷，进而能以更高的效率来保障功能驱动程序及其收发重试流程的可靠性。

结合第一方面，在第一方面第一实施方式中，所述功能驱动程序测试方法还包括：当收到所述功能驱动程序重发的各个输入输出请求包时，判定所述收发重试流程在所述过滤控制条件下通过测试。

本申请实施例提供的功能驱动程序测试方法，通过预设的过滤控制条件主动丢弃功能驱动程序的某些输入输出请求包，从而造成触发重试流程的外部条件，并在触发收发重试流程且成功接收到所有被丢弃的输入输出请求包后，判定该收发重试流程通过本次测试，能够在每次丢弃输入输出请求包后得到确定的测试结果，从而使得针对功能驱动程序收发重试流程的每次测试均有据可循。

结合第一方面第一实施方式，在第一方面第二实施方式中，所述功能驱动程序测试方法还包括：更换所述过滤控制条件；重复执行所述监听功能驱动程序的输入输出请求包；当根据预设的过滤控制条件丢弃所述输入输出请求包时，触发收发重试流程，判断是否收到所述功能驱动程序重发的各个输入输出请求包；所述功能驱动程序重发的各个输入输出请求包分别与丢弃的各个输入输出请求包对应的步骤，直至判定所述收发重试流程在所述过滤控制条件下未通过测试，或者，直至遍历所有的过滤控制条件。

本申请实施例提供的功能驱动程序测试方法，由于能够根据需要自由设定并更换过滤控制条件，从而使测试过程可以以任意概率来模拟和复现实际运行环境中出现概率极低的传输不稳定问题，进而实现对功能驱动程序收发重试流程全面深入地测试。由于只有在遍历所有的过滤控制条件，且收发重试流程均通过各个过滤控制条件下的测试时，才会判定该收发重试流程通过全部测试，使得对收发重试流程测试的可靠性能够得到有效保证。

结合第一方面第二实施方式，在第一方面第三实施方式中，所述监听功能驱动程序的输入输出请求包包括：获取所述输入输出请求包的输入输出控制码和数据传输功能码；根据所述输入输出控制码和所述数据传输功能码，识别所述输入输出请求包中的目标输入输出请求包。

本申请实施例提供的功能驱动程序测试方法，通过各个输入输出请求包的输入输出控制码和数据传输功能码，能够识别由待检测的功能驱动程序发出的各个输入输出请求包，即识别目标输入输出请求包。由于不同传输功能所对应的输入输出控制码和数据传输功能码均是唯一的，且相互不同，因此，输入输出控制码和数据传输功能码是与数据传输功能一一对应的，而每个功能驱动程序均具有唯一的数据传输功能，从而使得通过输入输出控制码和数据传输功能码能够识别出与功能驱动程序对应的目标输入输出请求包。

结合第一方面第三实施方式，在第一方面第四实施方式中，所述过滤控制条件包括过滤模式、过滤计数周期、过滤起始计数和连续过滤数；根据预设的过滤控制条件丢弃所述输入输出请求包的过程包括：获取所述目标输入输出请求包对应的序号；所述序号为所述目标输入输出请求包在对应的过滤计数周期内的序号；当所述序号大于或等于所述过滤起始计数，且所述序号小于所述过滤起始计数与所述连续过滤数之和时，丢弃所述目标输入输出请求包。

本申请实施例提供的功能驱动程序测试方法，通过过滤起始计数和连续过滤数，筛选目标输入输出请求包在对应的过滤计数周期内的序号，并将筛选出的序号对应的目标输入输出请求包丢弃，从而实现针对输入输出请求包的主动丢弃。由于用户可以根据实际检测需要自由设置过滤计数周期、过滤起始计数和连续过滤数，从而实行以任意概率来模拟和复现实际运行环境中出现概率极低的传输不稳定问题。此外，在本申请实施例提供的功能驱动程序测试方法中，由于在过滤控制条件中设置了过滤模式，使用户可以根据检测需要自由设定过滤模式，例如不过滤、固定过滤或随机过滤，从而实现在多种不同模式下针对收发重试流程的可靠性测试。

结合第一方面第四实施方式，在第一方面第五实施方式中，在所述丢弃所述目标输入输出请求包的步骤之后，所述根据预设的过滤控制条件丢弃所述输入输出请求包的过程还包括：通过预设的取消历程处理丢弃的所述目标输入输出请求包。

本申请实施例提供的功能驱动程序测试方法，通过取消历程处理丢弃的目标输入输出请求包，能够避免功能驱动程序发生死锁进而使测试无法继续。

结合第一方面或第一方面第一至第五中的任一实施方式，在第一方面第六实施方式中，所述功能驱动程序测试方法还包括：构建过滤驱动程序；所述过滤驱动程序用于监听所述功能驱动程序的输入输出请求包，以及用于根据预设的过滤控制条件丢弃所述输入输出请求包。

本申请实施例提供的功能驱动程序测试方法，通过过滤驱动程序对待测试的功能驱动程序进行监听，并主动丢弃该功能驱动程序的某些输入输出请求包，从而实现触发功能驱动程序中收发重试流程的外部条件。用户通过设置过滤驱动程序对应的过滤控制条件，能够对输入输出请求包进行可控地丢弃。

根据第二方面，本申请实施例提供了一种功能驱动程序测试装置，包括：监听单元，用于监听功能驱动程序的输入输出请求包；收发重试触发单元，当根据预设的过滤控制条件丢弃所述输入输出请求包时，用于触发收发重试流程，判断是否收到所述功能驱动程序重发的各个输入输出请求包，所述功能驱动程序重发的各个输入输出请求包分别与丢弃的各个输入输出请求包对应；判断单元，当未收到所述功能驱动程序重发的任一输入输出请求包时，用于判定所述收发重试流程在所述过滤控制条件下未通过测试。

根据第三方面，本申请实施例提供了一种终端设备，包括存储器、处理器以及存储在所述存储器中并可在所述处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现如第一方面或第一方面任一实施方式所述方法的步骤。

根据第四方面，本申请实施例的提供一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，所述计算机程序被处理器执行时实现如第一方面或第一方面任一实施方式所述方法的步骤。

附图说明

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

图1是操作系统中分层驱动框架的结构示意图；

图2是本申请实施例提供的功能驱动程序测试方法的一个具体示例的实现流程示意图；

图3是本申请实施例提供的功能驱动程序测试方法的另一个具体示例的实现流程示意图；

图4是本申请实施例提供的功能驱动程序测试装置的一个具体示例的结构示意图；

图5是本申请实施例提供的终端设备的一个具体示例的结构示意图。

具体实施方式

以下描述中，为了说明而不是为了限定，提出了诸如特定系统结构、技术之类的具体细节，以便透彻理解本申请实施例。然而，本领域的技术人员应当清楚，在没有这些具体细节的其它实施例中也可以实现本申请。在其它情况中，省略对众所周知的系统、装置、电路以及方法的详细说明，以免不必要的细节妨碍本申请的描述。

为了说明本申请所述的技术方案，下面通过具体实施例来进行说明。

普通的操作系统，例如Windows操作系统中，驱动程序包括功能驱动程序、过滤驱动程序和总线驱动程序三种，大多采用如图1所示的分层驱动框架。其中，总线驱动程序一般由操作系统提供；功能驱动程序一般由设备供应商提供，其可靠性需要进行充分测试。过滤驱动程序可以修改已有驱动的功能，例如修改输入和输出请求，也可以对数据进行过滤加密。过滤驱动程序通常也由设备供应商提供。一般，将介于FDO(Functional DeviceObject功能设备对象，简称FDO，对应功能驱动程序)与PDO(Physical Device Object物理设备对象，简称PDO，处于堆栈最底层，对应总线驱动程序)之间的过滤驱动程序称为下层过滤驱动程序，而将附加在FDO(处于堆栈中间层)上面的称为上层过滤驱动程序。在FDO的上面和下面还会有一些过滤器设备对象(filter device object过滤器设备对象，简称FiDO)，将位于FDO上面的过滤器设备对象称为上层过滤器，将位于FDO下面(但仍在PDO之上)的过滤器设备对象称为下层过滤器。

外部设备与操作系统之间的数据传输，例如POS机与Windows系统之间的交易数据传输，一般通过I/O请求包(I/O Request Packets I/O请求包，简称IRP)进行。IRP是一个具有不完全文档说明的结构，由I/O管理器进行分配，用于在驱动程序之间传递特有的数据。在驱动程序分层时，I/O管理器会将涉及的各个驱动程序注册到一个链中，通过向链接起来的驱动程序发出I/O请求，可以创建一个IRP并将其传递给链中所有的驱动程序。链中最顶端的驱动程序最先接收IRP，链中最后一个驱动程序负责与硬件通信。I/O管理器准确知道链中驱动程序的数目。在驱动程序中，数据传输往往是最核心的事务，包括数据接收与数据发送，驱动程序一般需要通过重试流程来保证数据收发的可靠性。

常规的对功能驱动程序中的收发重试流程进行测试的方法，主要依靠长时间大数据量收发交互测试来验证，例如通过收发交互测试程序使待检测的功能驱动程序收发大量的IRP。收发重试流程需要在接收或发送出现超时或错误的特殊情景下才被触发，而该情景在常规环境下出现的几率通常极低。本申请实施例通过下层过滤驱动程序监听功能驱动程序下发的IRP，当发现是数据传输事务对应的类型且满足指定的控制条件时，将该IRP丢弃而不向更下层驱动转发；否则，就将所监听的IRP向更下层驱动转发。当功能驱动程序发出的IRP被丢弃而得不到正确响应时，其收发重试流程将被触发。由于丢弃IRP的动作是主动且受控的，故收发重试流程的触发也是主动且受控的。

在一些实施例中，如图2所示，过滤驱动程序可以通过以下几个步骤，实现对功能驱动程序中收发重试流程的测试：

步骤S101：监听功能驱动程序的输入输出请求包。在一具体实施方式中，如图3所示，可以通过以下几个子步骤实现步骤S101的过程：

步骤S1011：获取输入输出请求包的输入输出控制码和数据传输功能码。由于不同传输功能所对应的输入输出控制码和数据传输功能码均是唯一的，且相互不同，因此，输入输出控制码和数据传输功能码是与数据传输功能一一对应的。

步骤S1012：根据输入输出控制码和数据传输功能码，识别输入输出请求包中的目标输入输出请求包。由于每个功能驱动程序均具有唯一的数据传输功能，即每个功能驱动程序对应唯一的输入输出控制码以及唯一的数据传输功能码，通过各个输入输出请求包的输入输出控制码和数据传输功能码，能够识别由待检测的功能驱动程序收发的各个输入输出请求包，即识别目标输入输出请求包。

步骤S102：根据预设的过滤控制条件，判断是否丢弃输入输出请求包。当根据预设的过滤控制条件丢弃输入输出请求包时，执行步骤S103；当根据预设的过滤控制条件不丢弃输入输出请求包时，转发输入输出请求包。

步骤S103：根据预设的过滤控制条件丢弃输入输出请求包。在一具体实施方式中，过滤控制条件可以包括过滤模式、过滤计数周期、过滤起始计数和连续过滤数。其中，过滤模式用于指示过滤驱动程序对相应目标IRP进行过滤的方式，可以包括不过滤、固定丢弃和随机丢弃等三种方式。其中，不过滤是指原样转发所监听的任何IRP包，不作额外处理；固定丢弃是指将每N个输出或输入IRP中固定序号开始的一个或连续几个丢弃，而其它IRP原封不动地转发；随机丢弃是指将每N个输入或输出IRP中随机序号开始的一个或连续几个丢弃，而将其它IRP原封不动地转发。过滤计数周期用于将过滤驱动程序所监听的输入或输出IRP进行分段，以便后续操作分别对每一段输入或输出IRP中的某些IRP进行丢弃处理，具体的，过滤计数周期指过每段连续的输入或输出IRP的数量。过滤起始计数指每个过滤计数周期中首个需被丢弃的IRP的序号。连续过滤数指在每个过滤计数周期中，从首个被丢弃的IRP开始，被连续丢弃的IRP的数量。

对应上述过滤控制条件的内容，在一具体实施方式中，如图3所示，过滤驱动程序可以通过一下几个子步骤实现步骤S103的过程：

步骤S1031：获取目标输入输出请求包对应的序号。具体的，该序号为目标输入输出请求包在对应的过滤计数周期内的序号。

步骤S1032：判断序号是否大于或等于过滤起始计数。当序号大于或等于过滤起始计数时，执行步骤S1033；当序号小于过滤起始计数时，转发对应的目标输入输出请求包。

步骤S1033：判断序号是否小于过滤起始计数与连续过滤数之和。当序号小于过滤起始计数与连续过滤数之和时，执行步骤S1034；当序号大于或等于过滤起始计数与连续过滤数之和时，转发对应的目标输入输出请求包。

步骤S1034：丢弃目标输入输出请求包。通过对符合过滤控制条件的目标输入输出请求包进行丢弃处理，模式实现了功能驱动程序的通信故障，实现了触发功能驱动程序中收发重试流程的外部条件。

可选的，在步骤S1034丢弃目标输入输出请求包之后，如图3所示，还可以增设以下步骤：

步骤S1035：通过预设的取消历程处理丢弃的目标输入输出请求包。输出过滤控制处理过程中的取消例程与输入过滤控制处理过程中的取消例程可以分别单独实现两个不同名称的取消例程，也可以合并实现为同一名称的一个统一例程。本申请实施例提供的功能驱动程序测试方法，通过取消历程处理丢弃的目标输入输出请求包，能够避免功能驱动程序发生死锁进而使测试无法继续。

步骤S104：触发收发重试流程。在预设的过滤控制条件下，当符合条件的IRP包被丢弃后，由于功能驱动程序得不到正确响应，会触发收发重试流程。由于过滤控制条件的多样性，收发重试流程可单次触发，或连续触发。

步骤S105：判断是否收到功能驱动程序重发的各个输入输出请求包。当未收到功能驱动程序重发的任一输入输出请求包时，执行步骤S106；当收到功能驱动程序重发的各个输入输出请求包时，执行步骤S107。在实际应用中，功能驱动程序重发的各个输入输出请求包分别与丢弃的各个输入输出请求包对应。

步骤S106：判定收发重试流程在过滤控制条件下未通过测试。在本申请实施例中，通过过滤驱动程序来可控的触发功能驱动程序中的收发重试流程，具体是通过过滤控制条件，可控的丢弃输入输出请求包，从而可控的触发收发重试流程。在过滤驱动程序根据当前的过滤控制条件丢弃对应的某些目标输入输出请求包后，即在每次测试环节中，如果均能够准确无误的接收到丢弃的各个各个输入输出请求包，则可以认为对应的收发重试流程能够在通信故障时可靠地实现数据传输；反之，则可以认为对应的收发重试流程在通信可靠性方面存在缺陷，即收发重试流程未通过测试。

步骤S107：判定收发重试流程在过滤控制条件下通过测试。在过滤驱动程序根据当前的过滤控制条件丢弃对应的某些目标输入输出请求包后，即在每次测试环节中，如果均能够准确无误的接收到丢弃的各个各个输入输出请求包，则可以认为对应的收发重试流程能够在通信故障时可靠地实现数据传输，即该收发重试流程通过本次测试。

为了对功能驱动程序中收发重试流程进行全面、深入的测试，在本申请实施例提供的测试方法中，还可以更换不同的过滤控制条件，从而模拟不同的通信故障情况，以进一步完善对功能驱动程序中收发重试流程的测试。在一具体实施方式中，如图3所示，还可以在步骤S107之后增设以下步骤：

步骤S108：判断是否遍历所有的过滤控制条件。当未遍历所有的过滤控制条件时，执行步骤S109；当遍历所有的过滤控制条件时，判定收发重试流程通过全部测试。

步骤S109：更换过滤控制条件。具体的，在步骤S109更换过滤控制条件之后，可以返回执行步骤S101，从而在更新后的过滤控制条件下，重新对功能驱动程序的收发重试流程进行测试。

在本申请实施例提供的测试方法中，由于只有在遍历所有的过滤控制条件，且收发重试流程均通过各个过滤控制条件下的测试时，才会判定该收发重试流程通过全部测试，使得对重发重试流程测试的可靠性能够得到有效保证。

在本申请实施例提供的功能驱动程序测试方法中，过滤驱动程序及其对应的过滤控制条件是测试的关键。因此，在一些实施方式中，如图3所示，还可以在步骤S101之前增设以下步骤：

步骤S100：构建过滤驱动程序。该过滤驱动程序可以用于监听功能驱动程序的输入输出请求包，并根据预设的过滤控制条件丢弃输入输出请求包。

在实际应用中，可以在设备扩展结构中定义过滤驱动程序及其对应的过滤控制条件所需要的相关变量。通过定义或读取过滤控制条件在系统注册表中的表项值及其对应的变量，能够得到过滤驱动程序及过滤控制条件中的各个变量，以便用于后续的过滤控制处理过程。过滤控制条件可以包括输入过滤控制条件和输出过滤控制条件。其中，输入过滤控制条件包括输入IRP过滤模式、输入过滤计数周期、输入过滤起始计数、输入连续过滤数等；输出过滤控制条件包括输出IRP过滤模式、输出过滤计数周期、输出过滤起始计数、输出连续过滤数等。输入过滤控制条件和输出过滤控制条件的各字段是分别对应和类似的，下面详细叙述各字段的含义和作用。

IRP过滤模式，包括输入IRP过滤模式和输出IRP过滤模式，用于指示过滤驱动程序对相应目标IRP进行过滤的方式，可以包括不过滤、固定丢弃和随机丢弃等三种方式。其中，不过滤是指原样转发所监听的任何IRP包，不作额外处理；固定丢弃是指将每N个输出或输入IRP中固定序号开始的一个或连续几个丢弃，而其它IRP原封不动地转发；随机丢弃是指将每N个输入或输出IRP中随机序号开始的一个或连续几个丢弃，而将其它IRP原封不动地转发。三种方式可以采用任意的可保证各自唯一性的编码值。为了叙述的简洁性，在一具体实施方式中，可以使用以下宏名称来对应定义三种方式：MODE_NONE、MODE_FIXED、MODE_RANDOM。需要说明的是，在本申请实施例中，IRP过滤模式是人为设定的，在初始状态设定该模式值以后，则整个测试过程持续有效使用该值。如果改变过滤模式，则应当在系统注册表中修改其值，再重新加载待测试的功能驱动程序与用于测试的过滤驱动程序。

过滤计数周期，指所监听的连续N个输入或输出IRP的N值。为了叙述简洁，以下约定输入过滤计数周期的值为Ni，输出过滤计数周期的值为No,而N则泛指Ni或No。

过滤起始计数，指过滤计数周期中，首个需被丢弃的IRP的序号。在一具体实施方式中，可以约定若过滤计数周期为N，则一个过滤计数周期内，IRP依次排序为0、1、2、…、N-1。

连续过滤数，指从首个被丢弃的IRP开始，被连续丢弃的IRP总包数。

下面以一个具体示例进行说明。假设过滤计数周期为10，连续过滤数为2，过滤起始计数为5，则一个过滤计数周期内的IRP序号依次是0、1、2、3、4、5、6、7、8、9，过滤驱动程序会将5和6两个序号的IRP丢弃，其他IRP放行通过。

在一具体实施方式中，为简洁和清晰起见，可以约定输入IRP过滤模式、输入过滤计数周期、输入过滤起始计数、输入连续过滤数等字段变量的名称依次为iFilterMode、iCountCycle、iStartCount、iDiscardTotal；约定输出IRP过滤模式、输出过滤计数周期、输出过滤起始计数、输出连续过滤数等字段变量的名称依次为oFilterMode、oCountCycle、oStartCount、oDiscardTotal。变量名称也可以采用其它不同的名称。若过滤控制条件的各表项不存在，则在注册表中创建各过滤控制条件的表项，并赋给初值。具体地，过滤计数周期的初值应大于1，典型值为10、100等；连续过滤数的初值为1；过滤模式的初值设为MODE_NONE；过滤起始计数的初值为0。

可选的，还可以在过滤驱动程序及过滤控制条件中定义输入累计变量和输出累计变量，分别用于记录输入方向的目标IRP的总包数和输出方向的目标IRP的总包数，供过滤控制处理过程使用。此外，还可以在过滤驱动程序及过滤控制条件中定义输入丢弃计数变量和输出丢弃计数变量，用于记录每个输入或输出过滤周期内已被丢弃的IRP数，供过滤控制处理过程使用。在监听到每个过滤计数周期内的首包时，可以将相应的丢弃计数值清零。

在构建过滤驱动程序的过程中，还可以定义下层设备指针变量，用于派遣函数中IRP的下发处理。具体的，在过滤驱动程序的AddDevice例程中，创建用于过滤控制的设备对象，并将该设备对象附着于AddDevice例程的传入参数所指明的物理设备上，再将附着调用时所返回的下层设备指针保存到下层设备指针字段中。

派遣函数是windows驱动进行IRP处理的基本框架和标准方式。IRP_MJ_INTERNAL_DEVICE_CONTROL是windows驱动开发工具包中给定的内部设备控制主功能IRP的宏名称。功能驱动程序一般通过IRP_MJ_INTERNAL_DEVICE_CONTROL请求包向总线驱动传递消息。在该派遣函数中，先读取当前栈指针，再从栈指针所指向的当前栈中读取输入输出控制码。当输入输出控制码是与功能驱动所实现的数据传输功能对应的控制码，且数据传输功能码对应于功能驱动所对应的数据传输功能时，则表明所监听的IRP正是待测试的功能驱动数据传输事务所对应的目标IRP。

除上文介绍的构件用于测试的过滤驱动程序及过滤控制条件的过程外，还可以通过其他方式构建过滤驱动程序及过滤控制条件，只要所构建的过滤驱动程序及过滤控制条件能够用于监听功能驱动程序的输入输出请求包，并根据预设的过滤控制条件丢弃输入输出请求包，即可将该过滤驱动程序及过滤控制条件应用于本申请实施例提供的测试方法中。

本申请实施例提供的功能驱动程序测试方法，通过过滤控制条件能够主动并可控地丢弃功能驱动程序的输入输出请求包，从而实现触发功能驱动程序中重试流程的外部条件，解决了现有技术不能主动触发收发重试流程的问题。

应理解，上述实施例中各步骤的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本申请实施例的实施过程构成任何限定。

本申请实施例还提供一种功能驱动程序测试装置，如图4所示，该功能驱动程序测试装置可以包括：监听单元401、收发重试触发单元402和判断单元403。

其中，监听单元401用于监听功能驱动程序的输入输出请求包；其对应的工作过程可以参见上述方法实施例中步骤S101所述。

当根据预设的过滤控制条件丢弃输入输出请求包时，收发重试触发单元402用于触发收发重试流程并判断是否收到功能驱动程序重发的各个输入输出请求包；其对应的工作过程可以参见上述方法实施例中步骤S102至步骤S104所述。

当未收到功能驱动程序重发的任一输入输出请求包时，判断单元403用于判定收发重试流程在过滤控制条件下未通过测试；对应的工作过程可以参见上述方法实施例中步骤S106所述。

图5是本申请一实施例提供的终端设备的示意图。如图5所示，该实施例的终端设备500包括：处理器501、存储器502以及存储在所述存储器502中并可在所述处理器501上运行的计算机程序503，例如功能驱动程序测试程序。所述处理器501执行所述计算机程序503时实现上述各个功能驱动程序测试方法实施例中的步骤，例如图2或图3所示的各个步骤。或者，所述处理器501执行所述计算机程序503时实现上述各装置实施例中各模块/单元的功能，例如图4所示监听单元401、收发重试触发单元402和判断单元403的功能。

所述计算机程序503可以被分割成一个或多个模块/单元，所述一个或者多个模块/单元被存储在所述存储器502中，并由所述处理器501执行，以完成本申请。所述一个或多个模块/单元可以是能够完成特定功能的一系列计算机程序指令段，该指令段用于描述所述计算机程序503在终端设备500中的执行过程。例如，所述计算机程序503可以被分割成同步模块、汇总模块、获取模块、返回模块(虚拟装置中的模块)。

终端设备500可以是桌上型计算机、笔记本、掌上电脑及云端服务器等计算设备。终端设备可包括，但不仅限于，处理器501、存储器502。本领域技术人员可以理解，图5仅仅是终端设备500的示例，并不构成对终端设备500的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件，例如装置/终端设备还可以包括输入输出设备、网络接入设备、总线等。

所称处理器501可以是中央处理单元(Central Processing Unit，CPU)，还可以是其他通用处理器、数字信号处理器(Digital Signal Processor，DSP)、专用集成电路(Application Specific Integrated Circuit，ASIC)、现成可编程门阵列(Field-Programmable Gate Array，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。

所述存储器502可以是装置/终端设备500的内部存储单元，例如终端设备500的硬盘或内存。所述存储器502也可以是所述终端设备500的外部存储设备，例如所述终端设备500上配备的插接式硬盘，智能存储卡(Smart Media Card,SMC)，安全数字(SecureDigital,SD)卡，闪存卡(Flash Card)等。进一步地，所述存储器502还可以既包括所述终端设备500的内部存储单元也包括外部存储设备。所述存储器502用于存储所述计算机程序以及所述终端设备所需的其他程序和数据。所述存储器502还可以用于暂时地存储已经输出或者将要输出的数据。

所属领域的技术人员可以清楚地了解到，为了描述的方便和简洁，仅以上述各功能单元、模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能单元、模块完成，即将所述装置的内部结构划分成不同的功能单元或模块，以完成以上描述的全部或者部分功能。实施例中的各功能单元、模块可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中，上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。另外，各功能单元、模块的具体名称也只是为了便于相互区分，并不用于限制本申请的保护范围。上述系统中单元、模块的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

在上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述或记载的部分，可以参见其它实施例的相关描述。

本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。

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

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

另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

所述集成的模块/单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请实现上述实施例方法中的全部或部分流程，也可以通过计算机程序来指令相关的硬件来完成，所述的计算机程序可存储于一计算机可读存储介质中，该计算机程序在被处理器执行时，可实现上述各个方法实施例的步骤。。其中，所述计算机程序包括计算机程序代码，所述计算机程序代码可以为源代码形式、对象代码形式、可执行文件或某些中间形式等。所述计算机可读介质可以包括：能够携带所述计算机程序代码的任何实体或装置、记录介质、U盘、移动硬盘、磁碟、光盘、计算机存储器、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、电载波信号、电信信号以及软件分发介质等。需要说明的是，所述计算机可读介质包含的内容可以根据司法管辖区内立法和专利实践的要求进行适当的增减，例如在某些司法管辖区，根据立法和专利实践，计算机可读介质不包括电载波信号和电信信号。

以上所述实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的精神和范围，均应包含在本申请的保护范围之内。

Claims (9)

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

监听功能驱动程序的输入输出请求包；

当根据预设的过滤控制条件丢弃所述输入输出请求包时，触发收发重试流程；其中，根据预设的过滤控制条件丢弃所述输入输出请求包的过程包括：获取目标输入输出请求包对应的序号；所述序号为所述目标输入输出请求包在对应的过滤计数周期内的序号；当所述序号大于或等于过滤起始计数，且所述序号小于所述过滤起始计数与连续过滤数之和时，丢弃所述目标输入输出请求包；所述过滤计数周期指过每段连续的输入或输出IRP的数量，所述过滤起始计数指每个过滤计数周期中首个需被丢弃的IRP的序号，连续过滤数指在每个过滤计数周期中，从首个被丢弃的IRP开始，被连续丢弃的IRP的数量；

判断是否收到所述功能驱动程序重发的各个输入输出请求包，所述功能驱动程序重发的各个输入输出请求包分别与丢弃的各个输入输出请求包对应；

当未收到所述功能驱动程序重发的任一输入输出请求包时，判定所述收发重试流程在所述过滤控制条件下未通过测试。

2.如权利要求1所述的功能驱动程序测试方法，其特征在于，所述功能驱动程序测试方法还包括：

当收到所述功能驱动程序重发的各个输入输出请求包时，判定所述收发重试流程在所述过滤控制条件下通过测试。

3.如权利要求2所述的功能驱动程序测试方法，其特征在于，所述功能驱动程序测试方法还包括：

更换所述过滤控制条件；重复执行所述监听功能驱动程序的输入输出请求包，当根据预设的过滤控制条件丢弃所述输入输出请求包时，触发收发重试流程，判断是否收到所述功能驱动程序重发的各个输入输出请求包，所述功能驱动程序重发的各个输入输出请求包分别与丢弃的各个输入输出请求包对应的步骤，直至判定所述收发重试流程在所述过滤控制条件下未通过测试，或者，直至遍历所有的过滤控制条件。

4.如权利要求3所述的功能驱动程序测试方法，其特征在于，所述监听功能驱动程序的输入输出请求包包括：

获取所述输入输出请求包的输入输出控制码和数据传输功能码；

根据所述输入输出控制码和所述数据传输功能码，识别所述输入输出请求包中的目标输入输出请求包。

5.如权利要求1所述的功能驱动程序测试方法，其特征在于，在所述丢弃所述目标输入输出请求包的步骤之后，所述根据预设的过滤控制条件丢弃所述输入输出请求包的过程还包括：

通过预设的取消历程处理丢弃的所述目标输入输出请求包。

6.如权利要求1至5中任一项所述的功能驱动程序测试方法，其特征在于，所述功能驱动程序测试方法还包括：

构建过滤驱动程序；所述过滤驱动程序用于监听所述功能驱动程序的输入输出请求包，以及用于根据预设的过滤控制条件丢弃所述输入输出请求包。

7.一种功能驱动程序测试装置，其特征在于，包括：

监听单元，用于监听功能驱动程序的输入输出请求包；

收发重试触发单元，当根据预设的过滤控制条件丢弃所述输入输出请求包时，用于触发收发重试流程，判断是否收到所述功能驱动程序重发的各个输入输出请求包，所述功能驱动程序重发的各个输入输出请求包分别与丢弃的各个输入输出请求包对应；其中，根据预设的过滤控制条件丢弃所述输入输出请求包的过程包括：获取目标输入输出请求包对应的序号；所述序号为所述目标输入输出请求包在对应的过滤计数周期内的序号；当所述序号大于或等于过滤起始计数，且所述序号小于所述过滤起始计数与连续过滤数之和时，丢弃所述目标输入输出请求包；所述过滤计数周期指过每段连续的输入或输出IRP的数量，所述过滤起始计数指每个过滤计数周期中首个需被丢弃的IRP的序号，连续过滤数指在每个过滤计数周期中，从首个被丢弃的IRP开始，被连续丢弃的IRP的数量；

判断单元，当未收到所述功能驱动程序重发的任一输入输出请求包时，用于判定所述收发重试流程在所述过滤控制条件下未通过测试。

8.一种终端设备，包括存储器、处理器以及存储在所述存储器中并可在所述处理器上运行的计算机程序，其特征在于，所述处理器执行所述计算机程序时实现如权利要求1至6任一项所述方法的步骤。

9.一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现如权利要求1至6任一项所述方法的步骤。

Images