CN108241576A - 一种接口测试方法及系统 - Google Patents

Abstract

本发明实施例提供了一种接口测试方法及系统，方法包括接收测试用例文件；解析所接收的测试用例文件，将解析出来的信息反馈到系统界面，并根据系统界面上的输入内容修改测试用例文件；以所指示的协议接口发送修改后的测试用例文件。本申请提供的实施例实现了多种方式对测试用例文件进行自动填充，即根据用户在系统界面上的输入内容自动填充XML文件的不同节点，避免了测试人员手工写多个测试用例，使测试人员减少了手工修改及维护的工作，提高了接口测试的效率。

Description

一种接口测试方法及系统

技术领域

本发明涉及软件测试领域，尤其涉及一种接口测试方法及系统。

背景技术

目前，很多针对接口的自动化测试系统都是在Selenium或者QTP(QuickestProfessional)的基础上进行开发的，而针对接口的测试系统一般属于轻量级的测试系统，运用上述方式开发出的测试系统虽然扩展性较强，但是对于针对接口级别的测试来说，就会出现系统体系繁重，测试脚本复杂，开发成本高的问题。

再者，接口测试系统的测试脚本的重复利用率不高，如果用基于Selenium或者QTP开发出的测试系统进行测试的话，由于测试系统的测试脚本复杂，就会使得脚本的维护修改成本大大高于手工测试的成本，不利于测试系统的推广和使用。

发明内容

本发明的实施例提供了一种接口测试方法及系统，实现了多种方式对测试用例文件进行自动填充，即根据用户在系统界面上的输入内容自动填充XML文件的不同节点，避免了测试人员手工写多个测试用例，使测试人员减少了手工修改及维护的工作，提高了接口测试的效率。

为达到上述目的，本发明的实施例采用如下技术方案：

一方面，本发明实施例提供了一种接口测试方法，包括接收测试用例文件；解析所接收的测试用例文件，将解析出来的信息反馈到系统界面，并根据系统界面上的输入内容修改测试用例文件；以所指示的协议接口发送修改后的测试用例文件。

另一方面，本发明实施例还提供了一种接口测试系统，包括接收模块，用于接收测试请求端输入的测试用例文件；处理模块，用于解析测试请求端输入的测试用例文件，将解析出来的信息反馈到系统界面，并根据系统界面上的输入内容修改测试用例文件；发送模块，用于以所指示的协议接口发送修改后的测试用例文件到要测试的服务端。

综上，本发明实施例提供的接口测试方法及系统，采取了多种方式对测试用例文件进行自动填充，根据用户在系统界面上的输入内容自动填充XML文件的不同节点，避免了测试人员手工写多个测试用例，使测试人员减少了手工修改及维护的工作，尤其在回归测试中，降低手工测试工作量的效果更显著，同时也提高了测试效率。

附图说明

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

图1为本发明实施例提供的接口测试方法流程图；

图2为本发明实施例提供的接口测试系统结构图。

具体实施方式

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

接口测试的目的是测试接口，尤其是测试与系统相关联的接口。目前，很多都是运用Selenium或者QTP(Quickest Professional)等测试工具的方式对接口进行测试，但是对于轻量级的接口测试来说，这种测试工具的体系繁重，而且测试脚本维护的成本较大。本发明实施例利用XML(Extensible Markup Language，可扩展性标记语言)对于不同的系统复用性强的特点，将所有测试用例转化为XML文件，达到自动化测试的目的。在本申请实施例中，接口测试系统的一端为测试请求端，另一端为要测试的服务端，测试请求端和要测试的服务端通过接口进行通信。

如图1所示，测试系统首先执行步骤S101：接收测试用例文件，这里的测试用例文件可以是XML测试文件。

然后执行步骤S102：解释接收到的测试用例文件，将解析出来的信息反馈到系统界面上，并根据系统界面上的输入内容修改接收到的测试用例文件。

以下述的一段XML测试用例文件举例对该步骤进行说明：

在该段XML中，本申请实施例假定带有{}的节点内容会显示在系统界面上，测试系统根据用户在系统界面上的输入内容填充相应的内容。带有^^的节点的内容可以是中英文随机的内容。带有||的节点内容会根据用户输入的起止号来填充内容，例如，上述XML文件中有<FPQQLSH>|流水号|</FPQQLSH>的内容，测试系统在读取到该XML文件后，会在系统界面显示两个输入框，一个输入框为流水号起号输入框，一个输入框为流水号止号输入框。如果用户在系统界面流水号起号输入框内填写的起号为1，在流水号止号输入框内填写的止号为10，那么测试系统就会将1自动填充到XML文件中的<FPQQLSH>节点中，即形成<FPQQLSH>|1|</FPQQLSH>，然后将节点<FPQQLSH>内容为1的XML文件发送到要测试的服务端；将2自动填充到XML文件中的<FPQQLSH>节点中，即形成<FPQQLSH>|2|</FPQQLSH>，然后将节点<FPQQLSH>内容为2的XML文件发送到要测试的服务端……，直至将节点<FPQQLSH>内容为10的XML文件发送到要测试的服务端。上述的10个修改测试用例文件的过程可以是串行进行的，也可以是并行进行的。即可以顺序将1,2,3……，10的数字填写到10个XML文件中的<FPQQLSH>节点，也可以同时将1,2,3……，10的数字同时填写到10个XML文档中。如此，当将测试用例文件输入到测试系统中后，测试系统会将XML文件加载到内存中，然后遍历整个XML文件，按照以上规则替换测试用例文件中的内容后，执行步骤S103：以所指示的协议接口发送修改后的测试用例文件。也就是说，对于上述的这段XML文件，测试系统就会分别发送<FPQQLSH>节点为1～10，<DSPTBM>节点为用户在系统界面上的输入内容，<NSRSBH>也为用户在系统界面上的输入内容，<NSRMC>为中英文随机内容，总计10次测试请求到要测试的服务端。

上面描述的接口测试方法，采取了多种方式对测试用例文件进行自动填充，根据用户在系统界面上的输入内容自动填充XML文件的不同节点，避免了测试人员手工写多个测试用例，使测试人员减少了手工修改及维护的工作，尤其在回归测试中，降低手工测试工作量的效果更显著，同时也提高了测试效率。

可选地，步骤S103具体为：识别要测试的服务端的接口地址，根据识别到的接口地址来判断接口协议类型，如果识别到接口地址的后缀名为wsdl(webservice描述语言，webservice description language)，则对应的接口协议类型为webservice，此时接口测试系统就以webservice接口的方式发送修改后的测试用例文件，如果接口地址的后缀名不是wsdl，而是其他内容，则对应的接口协议类型为serverlet，此时接口测试系统以serverlet的方式发送修改后的测试用例文件。综上，本申请实施例中的接口测试系统主要针对webservice接口和serverlet接口的测试。

如果根据接口地址判断为webservice接口方式，接口测试系统可以根据wsdl解析出接口的方法名和命名空间等接口信息，并将解析出来的信息反馈给系统用户，系统用户根据具体业务，选择需要调用的方法名等之后，将测试用例文件发送出去，在测试请求方和测试响应方之间就以webservice接口的方式通信。

可选地，测试人员可以通过修改配置文件来选择要测试的协议接口类型，如果根据接口地址判断为serverlet接口方式，那么，测试人员在配置文件中写入需要测试的服务端地址即可。指定完需要测试的服务端地址后，再将系统的外层报文指定在模板文件中，此时测试人员即可载入测试用例文件所在的文件夹，测试系统将该文件夹下所有的测试用例从硬盘加载到内存之后，反馈到系统界面上，并将用户在系统界面上选择的测试用例编写成http报文，并以serverlet接口发送编写后的http报文。

可选地，在测试系统对接口进行测试的过程中，还可以对被测试的接口做校验，以防止一条报文多次重复发送。

可选地，在以所指示的协议接口发送修改后的测试用例文件之前还包括：判断是否需要对已修改的测试用例文件加密和/或压缩，因为本申请实施例中的接口测试系统还集成了加密和压缩功能，比如，集成了base64，3DES，CA多种加密算法以及Gzip压缩算法，用户可以根据具体情况选取加密算法和压缩算法。测试系统根据用户所选择的加密算法和/或压缩算法，对已修改的测试用例文件加密和/或压缩后，以所指示的协议接口发送加密和/或压缩后的测试用例文件。

进一步地，在执行完步骤S103之后，接口测试系统生成测试报告,当测试用例文件执行成功时，测试报告包括测试结果，当测试用例文件执行失败时，测试报告既包括测试结果，又包括失败的原因。

在判断执行成功还是执行失败时，是通过比较测试用例文件的期望测试结果与实际测试结果来实现的，如果期望测试结果与实际测试结果相同，则测试用例文件就是执行成功，否则就是执行失败。

具体实现时，测试请求端在将测试用例XML文件发送到要测试的服务端之前，编辑测试用例XML文件的文件名以PASS或者FAILED结尾，这里的PASS和FAILED是测试请求端对测试用例XML文件的期望测试结果，也就是说，如果编辑XML文件的文件名以PASS结尾，那么就说明期望测试结果为执行成功，如果文件名以FAILED结尾，那么就说明期望测试结果为执行失败。在测试请求端将测试用例XML文件发送到要测试的服务端之后，服务端返回测试的请求结果，对于文件名结尾为PASS的测试用例XML文件，如果请求结果为请求成功，则该测试用例XML文件的测试结果为执行成功，如果请求结果为请求失败，则该测试用例XML文件的测试结果为执行失败；对于文件名结尾为FAILED的测试用例XML文件，如果请求结果为请求成功，则该测试用例XML文件的测试结果为执行失败，否则，该测试用例XML文件的测试结果为执行成功。

对上述判断测试用例XML文件最终的测试结果的过程进行举例说明，比如测试请求端在将测试用例XML文件发送到要测试的服务端之前，编辑文件名为单商品行单价×数量与项目金额误差等于0.01_LP_PASS.xml的文件，将该文件发送到要测试的服务端之后，若服务端返回的请求结果为通过，则该XML文件的最终测试结果为执行成功，若服务端返回的请求结果为失败，则该XML文件的最终测试结果为执行失败；反之，如果编辑的文件为单商品行单价×数量与项目金额误差等于0.01_LP_FAILED.xml，将该文件发送到要测试的服务端之后，若服务端返回的请求结果为失败，则该XML文件的最终测试结果为执行成功，若服务端返回的请求结果为通过，则该XML文件的最终测试结果为执行失败。

可选地，还可以将测试用例XML文件的期望测试结果与实际测试结果进行二值化，比如，将期望测试结果设置为1，表示期望测试结果为执行成功，将期望测试结果设置为0，表示期望测试结果为执行失败。同样，将服务端返回的请求结果也进行二值化，如果返回的请求结果为1，表示请求成功，如果返回的请求结果为0，表示请求失败。在判断测试用例XML文件的最终测试结果时，可以将二值化后的期望测试结果和实际测试结果进行异或运算，只有在二值化后的期望测试结果与实际测试结果均为1或者均为0时，异或运算的结果才为1，即只有在期望测试结果与实际测试结果相同时，最终的测试结果才为执行成功。

可选地，可以将测试报告中，最终测试结果为执行失败的测试用例文件用红色的标记标出，以方便测试人员对执行失败的测试用例进行失败原因的分析。

由上述实施例可以看出，本发明实施例的接口测试方法在支持对webservice和serverlet两种接口测试的情况下，通过多种方式自动填充测试用例文件，使得测试人员可以批量修改指定的测试用例文件，而测试用例往往多达几百条，因此，本申请实施例的接口测试方法大大降低了手工修改节点内容的成本。而且，测试系统融合了加密和/或压缩算法，可以将测试用例文件进行加密和/或压缩算法后发送。

基于同样的发明构思，如图2所示，本申请实施例还提供了一种接口测试系统，包括：接收模块，用于接收测试请求端输入的测试用例文件；处理模块，用于解析测试请求端输入的测试用例文件，将解析出来的信息反馈到系统界面，并根据系统界面上的输入内容修改测试用例文件；发送模块，用于以所指示的协议接口发送修改后的测试用例文件到要测试的服务端。

可选地，该接口测试系统的处理模块还用于识别接口地址，如果识别到的接口地址的后缀名为wsdl，则指示发送模块以webservice接口发送修改后的测试用例文件到要测试的服务端，否则，则指示发送模块以serverlet接口发送修改后的测试用例文件到要测试的服务端。

可选地，处理模块指示发送模块以webservice接口发送修改后的测试用例文件到要测试的服务端之前还执行步骤：从wsdl中解析出接口的方法名和命名空间，将方法名和命名空间反馈到系统界面，并接收用户在系统界面上的输入；处理模块指示发送模块以webservice接口发送修改后的测试用例文件具体为：由处理模块指示发送模块根据用户在系统界面上的输入，以webservice接口发送修改后的测试用例文件。

可选地，如果处理模块识别到的接口地址的后缀名不是wsdl，则将所接收的测试请求端发送的测试用例文件反馈到系统界面上，并将用户选中的测试用例编写成http报文，以serverlet接口发送编写后的http报文。

可选地，上述的接口测试系统还包括判断模块，用于判断是否需要对修改后的测试用例文件加密和/或压缩；加密模块，用于在需要对修改后的测试用例文件加密时，按照用户选择的加密方式，对修改后的测试用例文件加密；压缩模块，用于在需要对修改后的测试用例文件压缩时，按照用户选择的压缩方式，对修改后的测试用例文件压缩。

可选地，上述的接口测试系统还包括测试报告生成模块，用于当测试用例文件执行成功时，生成包括测试成功的结果的测试报告，当测试用例文件执行失败时，生成包括测试失败的结果和失败原因的测试报告。

可以通过比较测试用例文件的期望测试结果和实际测试结果得到测试结果，如果期望测试结果与实际测试结果相同，则判断测试用例文件执行成功，否则，判断测试用例文件执行失败。

具体地，也可以将测试用例文件的期望测试结果与实际测试结果二值化，并将二值化后的期望测试结果与实际测试结果进行异或运算，如果异或运算的结果为1，则判断测试用例文件执行成功，如果为0，则判断测试用例文件执行失败。

在测试报告中，执行失败的测试用例文件以红色标记标出。

在测试人员使用本申请实施例的接口测试系统时，只需要按照测试用例整理XML报文到文件夹中，然后在测试系统中指定文件夹以及指定内容不能重复的XML节点，选择需要加密的方式以及压缩的方式，就可以将所有测试用例报文发送给要测试的服务端，测试系统就会出具测试结果和报告。

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

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

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

上述以软件功能单元的形式实现的集成的单元，可以存储在一个计算机可读取存储介质中。上述软件功能单元存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本发明各个实施例方法的部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(Read-Only Memory，简称ROM)、随机存取存储器(Random Access Memory，简称RAM)、磁碟或者光盘等各种可以存储程序代码的介质。

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

Claims (14)

1.一种接口测试方法，其特征在于，包括：

接收测试用例文件；

解析所述测试用例文件，将解析出来的信息反馈到系统界面，并根据系统界面上的输入内容修改所述测试用例文件；

以所指示的协议接口发送修改后的测试用例文件。

2.根据权利要求1所述的接口测试方法，其特征在于，所述以所指示的协议接口发送修改后的测试用例文件具体为：

识别要测试的服务端的接口地址；

如果识别到所述接口地址的后缀名为wsdl，则以webservice接口发送修改后的测试用例文件，否则，以serverlet接口发送修改后的测试用例文件。

3.根据权利要求2所述的接口测试方法，其特征在于，所述如果所述接口地址的后缀名为wsdl，则以webservice接口发送修改后的测试用例文件具体为：

从所述wsdl中解析出接口的方法名和命名空间；

将所述方法名和命名空间反馈到系统界面，并接收用户在所述系统界面上的输入；

根据用户的输入，以webservice接口发送修改后的测试用例文件。

4.根据权利要求2所述的接口测试方法，其特征在于，所述以serverlet接口发送修改后的测试用例文件具体为：

将接收的测试用例文件反馈到系统界面上；

将用户选中的测试用例编写成http报文，以serverlet接口发送编写后的http报文。

5.根据权利要求1所述的接口测试方法，其特征在于，所述以所指示的协议接口发送修改后的测试用例文件之前还包括：

判断是否需要对所述修改后的测试用例文件加密和/或压缩；

如果需要，则按照用户选择的加密方式和/或压缩方式对所述修改后的测试用例文件加密和/或压缩后，以所指示的协议接口发送加密和/或压缩后的测试用例文件。

6.根据权利要求1所述的接口测试方法，其特征在于，所述以所指示的协议接口发送修改后的测试用例文件之后还包括：

生成测试报告，其中，当所述测试用例文件执行成功时，所述测试报告包括测试结果，当所述测试用例文件执行失败时，所述测试报告包括测试结果和失败原因。

7.根据权利要求6所述的接口测试方法，其特征在于，所述测试用例文件的测试结果的判断过程为：

比较所述测试用例文件的期望测试结果与实际测试结果；

如果所述期望测试结果与所述实际测试结果相同，则所述测试用例文件执行成功，否则，所述测试用例文件执行失败。

8.根据权利要求6所述的接口测试方法，其特征在于，所述测试用例文件的测试结果的判断过程为：

将所述测试用例文件的期望测试结果与实际测试结果做异或运算；

如果异或运算的结果为1，则所述测试用例文件执行成功，否则，所述测试用例文件执行失败。

9.根据权利要求6所述的接口测试方法，其特征在于，所述测试报告中执行失败的测试用例文件以红色标记标出。

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

接收模块，用于接收测试请求端输入的测试用例文件；

处理模块，用于解析测试请求端输入的测试用例文件，将解析出来的信息反馈到系统界面，并根据系统界面上的输入内容修改所述测试用例文件；

发送模块，用于以所指示的协议接口发送修改后的测试用例文件到要测试的服务端。

11.根据权利要求10所述的接口测试系统，其特征在于，所述处理模块还用于识别要测试的服务端的接口地址，如果识别到所述接口地址的后缀名为wsdl，则指示所述发送模块以webservice接口发送修改后的测试用例文件到要测试的服务端，否则，则指示所述发送模块以serverlet接口发送修改后的测试用例文件到要测试的服务端。

12.根据权利要求11所述的接口测试系统，其特征在于，在所述处理模块指示所述发送模块以webservice接口发送修改后的测试用例文件到要测试的服务端之前还执行步骤：从所述wsdl中解析出接口的方法名和命名空间，将所述方法名和命名空间反馈到系统界面，并接收用户在所述系统界面上的输入；所述处理模块指示所述发送模块以webservice接口发送修改后的测试用例文件具体为：由所述处理模块指示所述发送模块根据用户在系统界面上的输入，以webservice接口发送修改后的测试用例文件。

13.根据权利要求11所述的接口测试系统，其特征在于，如果所述处理模块识别到接口地址的后缀名不是wsdl，则将所接收的测试请求端发送的测试用例文件反馈到系统界面上，并将用户选中的测试用例编写成http报文，以serlet接口发送编写后的http报文。

14.根据权利要求10所述的接口测试系统，其特征在于，所述系统还包括：

判断模块，用于判断是否需要对所述修改后的测试用例文件加密和/或压缩；

加密模块，用于在需要对所述修改后的测试用例文件加密时，按照用户选择的加密方式，对所述修改后的测试用例文件加密；

压缩模块，用于在需要对所述修改后的测试用例文件压缩时，按照用户选择的压缩方式，对所述修改后的测试用例文件压缩。