[0001] 本申请实施例涉及计算机技术领域，尤其涉及一种测试方法。

[0002] 操作系统是管理和控制计算机硬件与软件资源的计算机程序，是直接运行在“裸机”上的最基本的系统软件，任何其他软件都必须在操作系统的支持下才能运行。系统调用接口是应用程序和系统内核之间的接口，是应用程序和系统内核通信的桥梁。操作系统所提供的系统调用接口具有广义性及操作系统运行时热更新困难等特点。并且，操作系统提供的系统调用接口应在任意调用方式下保证系统安全。所以，操作系统需要一种测试方法对系统调用接口进行广义安全性测试。

[0003] 现有的对操作系统进行上述测试的测试方法包括：测试人员编写测试代码，测试代码通过用户态触发内核态对系统调用接口进行测试，根据在用户态得到的测试反馈，判断所测试操作系统的安全性。但是，这种测试方法，要求测试人员根据不同的操作系统，逐条编写测试系统调用接口的测试指令。所以在实现本申请过程中，发明人发现现有技术中至少存在如下问题：现有操作系统的系统调用接口的测试方法的测试效率低下。

[0021] 为了使本领域的人员更好地理解本申请实施例中的技术方案，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅是本申请实施例一部分实施例，而不是全部的实施例。基于本申请实施例中的实施例，本领域普通技术人员所获得的所有其他实施例，都应当属于本申请实施例保护的范围。

[0022] 下面结合本申请实施例附图1-3,进一步说明本申请实施例具体实现。

[0023] 实施例一

[0024] 参照图1，示出了根据本申请实施例一的一种测试方法的步骤流程图。

[0025] 本实施例的测试方法包括以下步骤：

[0026] 步骤S101，获取待测试的系统调用接口的信息。

[0027] 操作系统内核提供一系列内核函数，通过一组称为系统调用的接口提供给用户，由用户调用使用。系统调用的作用是把应用程序的请求传递给系统内核，然后调用相应的内核函数完成所需的处理，最终将处理结果返回给应用程序。系统调用接口是应用程序和系统内核之间的接口，是应用程序和系统内核通信的桥梁。

[0028] 本实施例中，待测试的系统调用接口的信息包括测试所需的所有必要信息，如，系统调用接口的名称、参数、数量，等等。其中，当待测试的系统调用接口的数量为多个时，可实现一次对多个系统调用接口的测试，节省测试时间，提高测试效率。

[0029] 步骤S102，根据系统调用接口的信息，按照设定的生成规则，生成用于对系统调用接口进行测试的测试模板。

[0030] 其中，测试模板中包含有用于对系统调用接口进行调用测试的测试指令。

[0031] 本实施例中，本领域技术人员可以根据获取的系统调用接口的信息，按照系统调用接口的测试逻辑或测试规则，生成相应的测试模板。测试模板中包括有测试指令，用于对至少一个系统调用接口进行调用测试。

[0032] 例如，根据一个系统调用接口的信息生成单模板，将该系统调用接口的函数带入单模板生成测试模板。基于此规则，我们将每个系统调用接口的函数带入单模板，便可得到多个系统调用接口的测试模板。

[0033] 当然，在其他可行方式中，本领域技术人员也可以采用其他任意适当的生成规则生成测试模板，例如，根据系统调用接口的函数签名，对每个系统调用接口的所有参数的取值进行随机选取，生成参数文件；根据参数文件生成测试指令；然后，根据函数签名排序和测试指令生成测试模板。

[0034] 步骤S103，通过测试服务器将测试模板发送至至少一个待测设备，指示各个待测设备根据测试模板中的测试指令对本地的系统调用接口进行调用测试。

[0035] 本实施例中，测试服务器可以是物理服务器，也可以是虚拟服务器。待测设备可以是任意适当的使用相应操作系统并且具有系统调用接口的电子设备。

[0036] 当待测设备包括多个时，可以使用测试模板同时对多个待测设备进行相同的系统调用接口测试，以实现批量测试。

[0037] 待测设备在接收到测试模板后，即可根据测试模板中的测试指令，对待测设备本地的、测试指令中指示的系统调用接口进行调用测试。

[0038] 通过本实施例，可以直接根据系统调用接口的信息，按照设定的生成规则生成用于对系统调用接口进行测试的测试模板，其中，生成规则可以按照对系统调用接口进行测试的测试逻辑或者规则设定；进一步地，可以将测试模板发送至需要进行测试的待测设备，由待测设备根据测试模板进行系统调用接口的测试。由此，一方面，可以系统地生成待测试的所有系统调用接口的测试指令，无须人工逐条编写指令；另一方面，对于需要测试的多个待测设备，可以使用同一测试模板进行本地的多个系统调用接口的测试，实现了待测设备系统调用接口的批量化测试。从而有效提高了系统调用接口的测试效率。

[0039] 本申请实施例提供的测试方法可以应用于计算机操作系统测试、嵌入式计算机操作系统测试、通用软件测试等。其中，所述操作系统包括但不限于，Windows操作系统、Linux操作系统、Unix操作系统、Android操作系统。

[0040] 实施例二

[0041] 参照图2，示出了根据本申请实施例二的一种测试方法的步骤流程图。

[0042] 本实施例中，以对多个系统调用接口进行测试为例。

[0043] 本实施例的测试方法包括以下步骤：

[0044] 步骤S201，根据待测试的系统调用接口的函数签名，获取系统调用接口的信息。

[0045] 函数签名是一种函数的表达形式，主要由函数的名称和它的每一个形参的类型和种类(如，值、引用或输出)组成，通过函数签名可以获知函数的相关信息，如输入与输出的信息。

[0046] 系统调用接口也具有相应的函数签名，本实施例中，通过函数签名获取系统调用接口的信息，实现简单，大大提高了接口信息的获取效率。

[0047] 例如，Linux操作系统的open系统调用接口的函数签名为：

[0048] Int open(char*[INT],int[INT],mode_t[INT])；

[0049] 其中，open表示系统调用接口的函数名称；char、int、mode_t表示输入参数的类型；[INT]表示输入参数的取值范围，如为Linux操作系统中Libc中的整数取值范围。

[0050] 当然，在其他可行方式中，本领域技术人员也可以采用其他任意适当的方式获得系统调用接口的信息，例如，可以通过记录系统调用接口信息的文件或者第三方提供的系统调用接口数据，等等，获得系统调用接口的信息。

[0051] 步骤S202，为待测试的系统调用接口设置测试顺序。

[0052] 首先需要说明的是，本步骤为可选步骤。在实际的应用中，也可以不设置测试顺序，此种情况下，可以按照测试模板中的系统调用接口的测试指令顺序进行测试，或者，按照随机顺序进行测试，等等。

[0053] 而为系统调用接口设置测试顺序，则可以更好地适应测试场景。例如，网络socket通信会按照预定顺序调用系统调用接口，此种情况下，通过为待测试的系统调用接口设置测试顺序，能更容易定向地发现在相应测试场景下存在的系统调用接口的问题。

[0054] 步骤S203，根据系统调用接口的信息和测试顺序，按照设定的生成规则，生成用于对系统调用接口进行测试的测试模板。

[0055] 本步骤基于前述步骤S202，在生成测试模板时，综合考虑了系统调用接口的信息和测试顺序。但本领域技术人员应当明了的是，在未设置测试顺序的情况下，则可以根据系统调用接口的信息，按照设定的生成规则，生成测试模板。

[0056] 例如，根据系统调用接口的函数签名，获取其参数的种类和参数的取值范围。选取参数的取值范围，结合函数签名生成单模板。将该系统调用接口的函数带入单模板生成测试模板。基于此规则，将每个系统调用接口的函数带入单模板，便可得到多个系统调用接口的测试模板。此外，当有测试顺序时，可以将每个系统调用接口的函数按照测试顺序带入单模板，便可生成具有测试顺序特征的多个系统调用接口的测试模板。

[0057] 以如下系统调用接口为例对测试模板的生成过程进行说明：

[0058] ssize_t write(int fd,const void*buf,size_t count)；

[0059] 其中，write函数名称，用于读取三个固定的参数，即，int类型的fd，void*类型的buf，size_t类型的count，上述所有信息组成了write函数的函数签名。

[0060] 该系统调用接口的语义为：从buf指向的内存地址为起址，读取至多count长度的位，写入fd这个文件描述符所对应的内存空间内。那么，但就使用这一个系统调用接口进行系统调用时，三个参数均存在(1)语义合法，例如fd必须是个正数，(2)语言合法，如int/size_t本身可以是负数，(3)全域，该内存地址内可表示的任意值*，上述三个逐级扩大的范围，分别记为(A)(B)(C)。(需要说明的是，上述语言合法可以不必是全域语言合法。)[0061] 因此，每个参数的所有可能取值均会落在(A)或(B)中，非(A)或(C)中，非(B)三个区间上，至此以write为例可以得到3*3*3种情况，把这样的“选三个中的一个范围任取一个数记为函数X(A，B，C)，实际上任何系统调用的参数或返回值均可这样表示，此时write变为：

[0062] X4 write(X1,X2,X3)；

[0063] 这就是单模板，基于这三个范围可以生成27类输入类型。

[0064] 由于任何系统调用接口对应的函数调用过程均可认为是带条件的函数嵌套，那么一个确定性的代码路径可以表示为：

[0065] Xn＝f1(f2(f3(...,X0)))

[0066] 基于此，将每个系统调用接口对应的函数带入，便可得到多函数的模板，即，多个系统调用接口的测试模板。

[0067] 以上仅为示例性说明，当然，在其他可行方式中，本领域技术人员也可以采用其他任意适当的生成规则生成测试模板，例如，根据系统调用接口的函数签名，对每个系统调用接口的所有参数的取值进行随机选取，生成参数文件；根据参数文件生成测试指令；然后，根据函数签名排序和测试指令生成测试模板。

[0068] 步骤S204，通过测试服务器，使用RPC(Remote Procedure Call，远程过程调用)接口将测试模板发送至至少一个待测设备，指示各个待测设备根据测试模板中的测试指令对本地的系统调用接口进行调用测试。

[0069] 传统方式中，通常选用图形化测试工具进行系统调用接口的测试，但这种图形化测试工具会在图形界面崩溃而操作系统并未崩溃的情况误报为操作系统崩溃，导致测试结果错误。而本实施例中，则采用RPC接口传递测试模板，由此实现通过RPC监控待测设备的测试状态。RPC采用客户机/服务器模式，通过网络从远程计算机程序上请求服务，是一种非图形化工具。因此，采用RPC方式进行系统调用接口的测试，不会受到图形界面崩溃的影响，提高测试的准确性。

[0070] 但不限于上述RPC的方式，在实际应用中，本领域技术人员也可以采用其它非图形化测试工具进行测试，比如通过FTP(File Transfer Protocol文件传输协议)方式等。

[0071] 在一种可行方式中，可以通过测试服务器，使用RPC接口，将用于控制至少一个待测设备进行调用测试的控制指令及所述测试模板发送至所述至少一个待测设备。控制指令指示了具体如何进行系统调用接口的测试，例如，指示待测设备对多个系统调用接口进行并行测试或者串行测试，指示测试时机、具体调用方式，等等，以灵活地适应各种测试需要，提高对测试的可控性。在具体进行测试时，一种可行方式中，可以通过测试服务器，指示各个待测设备根据测试模板中的测试指令，对本地的至少一个系统调用接口进行并行调用测试。也即，对于每个待测设备，其可以根据测试模板，并行地对多个系统调用接口进行测试，以提高待测设备的测试效率，并进一步提高整体测试效率。

[0072] 例如，并行地通过进程、或者线程、或者协程等进行系统调用接口测试。其中，在待测设备的操作系统测试时，进程、线程、协程存在资源隔离和记账方式不同，属于不同的隔离层次。而且，同一测试模板在系统调用接口不同隔离层可能会得到不同的测试结果。在此情况下，将测试模板发送至系统调用接口的进程、线程、协程中测试，可以实现同一测试模板对系统调用接口的不同隔离层次进行测试。从而，有效提高了系统调用接口的测试效率。进一步地，对系统调用接口的进程、线程、协程等，全部进行测试，可以实现系统调用接口不同隔离层次的全面检测，有效提高了系统调用接口的测试精度。

[0073] 通过上述过程，即可实现待测设备中的系统调用接口的测试。为了获得测试执行情况和是否存在异常的系统接口调用的情况，进一步地，还可以执行以下可选步骤S205-S206。

[0074] 步骤S205，通过测试服务器获取调用测试的测试结果。

[0075] 其中，测试结果中包含有用于指示是否成功完成测试的系统调用接口的信息。其中，成功完成测试的系统调用接口表示该系统调用接口对应的测试指令已被测试执行并且正常执行完成的那些接口。若系统调用接口成功完成测试，则表示该系统调用接口可以被正常调用。

[0076] 测试服务器获取测试结果的时机可以由本领域技术人员根据实际需要采用任意适当的设置，例如，可以在测试模板中的所有测试指令均被执行完成后由当前待测设备返回给测试服务器，也可以由待测设备每间隔一设定时间段返回给测试服务器，也可以每测试完一个系统调用接口即返回给测试服务器，还可以在发生测试异常时返回给测试服务器，等等。在采用RPC方式的情况下，测试结果可以通过RPC接口返回给测试服务器。

[0077] 步骤S206，根据测试结果，判断系统调用接口是否成功完成测试；若是，则将与成功完成测试的系统调用接口的信息对应的测试指令标记为安全指令，以指示所述系统调用接口可被正常调用；若否，则获取未成功完成测试的系统调用接口的测试指令，并根据获取的所述测试指令生成重测试模板。

[0078] 其中，本申请实施例不对标记安全指令的具体方式进行限定，例如，可以使用“1”指示当前测试指令为安全指令，使用“0”指示当前测试指示还未收到测试结果，使用“2”指示当前测试指示为异常测试指令，等等。

[0079] 本实施例中，通过对成功完成测试的测试指令进行标记，可以有效地对测试指令进行区分，以快速定位未被测试的测试指令或者发生异常的测试指令，以进行后续处理，提高测试效率。而通过上报未成功完成测试的系统调用接口的信息，则便于系统及时了解测试情况及作出应对，进一步提高了测试效率。

[0080] 需要说明的是，在整个测试过程中，都可以通过测试服务器对所有的待测设备进行心跳探活检测；若心跳探活检测指示被检测的待测设备异常，则获取异常的待测设备中尚未进行成功调用测试的测试指令并上报。其中，尚未进行成功调用测试的测试指令包括尚未执行完成的测试指令和已执行完成但测试结果指示测试失败的测试指令，也即，除成功完成测试的测试指令之外的其它测试指令。通过心跳探活检测，可以及时获取待测设备的运行情况，并对异常情况进行及时处理，保证测试的正常进行。

[0081] 进一步可选地，还可以根据上报的测试指令，生成重测试模板，并通过测试服务器发送给至少一个待测设备，重新进行调用测试。

[0082] 其中，在一种可行方式中，所述生成重测试模板可以包括：按照所述测试模板的格式，将所述测试指令写入新的测试模板中生成重测试模板；或者，按照所述测试模板的格式，将所述测试指令合并入已生成的测试模板中。也即，这部分尚未进行成功调用测试的测试指令可以生成为仅包括这些测试指令的测试模板，以针对这些系统调用接口重新进行测试，这种重测试模板中可以仅包括上报的尚未进行成功调用测试的测试指令，使用该重测试模板重新进行调用测试，更具有针对性，测试时间和测试的系统调用接口也更少，既保证了测试的全面性，又保证了测试效率；此外，也可以将这部分尚未进行成功调用测试的测试指令合并入已生成的测试模板中，与其它尚未进行测试的测试指令一起进行后续的系统调用接口测试，以节省测试模板生成成本。

[0083] 通过本实施例，可以直接根据系统调用接口的信息，按照设定的生成规则生成用于对系统调用接口进行测试的测试模板，其中，生成规则可以按照对系统调用接口进行测试的测试逻辑或者规则设定；进一步地，可以将测试模板发送至需要进行测试的待测设备，由待测设备根据测试模板进行系统调用接口的测试。由此，一方面，可以系统地生成待测试的所有系统调用接口的测试指令，无须人工逐条编写指令；另一方面，对于需要测试的多个待测设备，可以使用同一测试模板进行本地的多个系统调用接口的测试，实现了待测设备系统调用接口的批量化测试。从而有效提高了系统调用接口的测试效率。

[0084] 本申请实施例提供的测试方法可以应用于计算机操作系统测试、嵌入式计算机操作系统测试、通用软件测试等。其中，所述操作系统包括但不限于，Windows操作系统、Linux操作系统、Unix操作系统、Android操作系统。

[0085] 实施例三

[0086] 参照图3，示出了根据本申请实施例三的一种测试方法的步骤流程图。

[0087] 本实施例以一个具体实例的形式，对本申请提供的测试方法进行说明。本实施例中，待测设备采用Linux操作系统，同时对多台待测设备进行测试。

[0088] 本实施例的测试方法包括以下步骤：

[0089] 步骤S301，接收用户输入的测试目标。

[0090] 本实施例中，在需要进行系统调用接口的测试时，用户声明测试目标，选择需被测试的系统调用接口的范围，为需要测试的系统调用接口根据其函数签名确定测试模板中测试指令的输入范围。

[0091] 本实施例中，以模糊测试为例，生成的模板也为模糊测试模板。

[0092] 例如，对于open系统调用接口：int open(char*[INT],int[INT],mode_t[INT])，其中，[INT]取值范围为该操作系统中Libc中整数取值范围。用户可以声明测试该open系统调用接口，并通过[INT]指明其测试范围。

[0093] 步骤S302，接收对待测试的系统调用接口的测试顺序设置。

[0094] 本实施例中，用户配置系统调用接口的测试顺序，即选择不同系统调用接口函数签名的排列顺序，若不指定顺序，则按照任意顺序排列函数签名。

[0095] 步骤S303，生成测试模板。

[0096] 本实施例中，采用模糊指令生成器生成测试模板，该模糊指令生成器根据步骤S302中生成的函数签名排列生成测试指令，并依照系统调用接口的各个参数的取值范围填入任意生成的参数，生成用户态系统调用接口测试模板。

[0097] 步骤S304，将测试模板发送给RPC服务器。

[0098] 本步骤中，模糊测试Server收集用户态系统调用接口测试模板，并将控制指令与测试模板输入RPC服务器。

[0099] 步骤S305，RPC服务器将控制指令与测试模板发送至RPC客户端，由RPC客户端调用模糊指令并行分发器进行分发准备。

[0100] 步骤S306，模糊指令并行分发器在多种程序并发性间做出选择。

[0101] 一般地，将在进程、线程、协程、不同命名空间内的进程间进行，并可由人工指定。

[0102] 步骤S307，模糊指令并行分发器将测试模板中的测试指令填入并行执行单元中，触发并行调用攻击操作系统内核。

[0103] 此种情况下，测试指令根据测试目的具备相应的输入顺序。

[0104] 测试过程中，模糊测试Server将保存测试模板，每当Client完成一部分测试指令执行，其结果将通过RPC通道返回模糊测试Server，此时模糊测试Server将执行过的测试指令标记为安全。

[0105] 此外，在整个测试过程中，模糊测试Server直接探活被测Client，防止其在完全崩溃后无法通过RPC Client返回测试结果。

[0106] 步骤S308，监测测试过程，如果未发生崩溃，则根据配置的测试方式返回步骤S306或S307继续测试；如果发生崩溃，则上报未被标识为安全的测试指令，并返回步骤S303，重新生成测试模板进行测试。

[0107] 如果发生崩溃，则依照步骤S307中的标注方法，应总存在一部分测试指令未被标识为安全，这些测试指令将被上报，并返回步骤S303，重新生成新的测试模板(即重测试模板)继续测试，直至发现导致崩溃的较小测试指令的代码段，汇报结果。

[0108] 可选地，该系统调用接口测试同时可与代码覆盖技术进行组合，以加快问题定位速度。如若被测试操作系统内核被配置了代码覆盖，亦即于操作系统用户态内存在一个非特权二进制，将操作系统内核代码命中次数写入某非易失性存储内的技术，则可以在测试中加快定位到最终问题代码段的速度。

[0109] 在一种可行的实施方式中，待测设备中运行的测试指令可以是一段段代码，而测试的目的是找出导致崩溃的最小代码段。其中，首次测试触及崩溃后，会得到崩溃代码段。并且，因为崩溃发生在一个“时间点”，所以在崩溃代码段中存在一处函数调用，是崩溃的精确诱因。在此情况下，与代码覆盖技术结合可以加快定位速度。结合测试的方案如下，首先记载代码行触及的系统调用接口，再运行对应代码行。如此，最终返回测试结果时，不仅有崩溃代码段，如一系列系统调用+二进制参数，还有崩溃过程中触发的系统调用接口。进一步地，可以在崩溃代码段中筛选出与该被触发的系统调用接口相对应的代码，使用该代码进行再次测试，崩溃代码段中不相关的代码可以不进行测试。所以，测试方法与代码覆盖技术进行组合，可以避免部分测试代码的重复测试，从而加快了定位到最终问题代码段的速度。

[0110] 通过本实施例，提供了一套完整的系统调用接口的自动化缺陷测试与发现方案，通过增加测试模板及模板生成自循环提纯机制扩展一般模板生成工具(如American Fuzz Lop等)，采用RPC替代一般的基于图形界面的缺陷崩溃监测机制(如OpenQA或Monkeyrunner等采用的监测机制)等，实现了针对Linux Kernel的高效操作系统模糊测试方案。

[0111] 本领域的技术人员应明白，本发明实施例的实施例可提供为方法、装置(设备)、或计算机程序产品。因此，本发明实施例可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明实施例可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

[0112] 本发明实施例是参照根据本发明实施例的方法、装置(设备)和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

[0113] 这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

[0114] 这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

[0115] 尽管已描述了本发明实施例的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例作出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本发明实施例范围的所有变更和修改。显然，本领域的技术人员可以对本发明实施例进行各种改动和变型而不脱离本发明实施例的精神和范围。这样，倘若本发明实施例的这些修改和变型属于本发明实施例权利要求及其等同技术的范围之内，则本发明实施例也意图包含这些改动和变型在内。