CN103136095A - 一种测试应用程序接口的方法、装置及系统 - Google Patents

Abstract

本申请公开了一种测试应用程序接口的方法、装置及系统，其中该方法用于由客户端测试设置于服务器上的应用程序接口，所述方法包括以下步骤：步骤S1：通过所述客户端的人机界面接收所述应用程序接口的参数信息与断言；步骤S2：根据所述客户端与所述服务器间的通信协议，将所述参数信息封装为符合所述通信协议的接口测试数据向所述服务器发送；步骤S3：接收所述服务器处理后的返回数据；以及步骤S4：通过所述断言解析所述返回数据并通过人机界面显示测试结果。本申请无需测试人员编写测试代码，通过页面输入测试数据并可通过页面直接显示测试结果，能够减小测试人员的工作量并提高准确性。

Description

一种测试应用程序接口的方法、装置及系统

技术领域

本申请涉及计算机技术领域，特别是涉及一种测试应用程序接口的方法、装置及系统。

背景技术

目前，在应用程序接口(简称接口)功能测试中，测试人员需要手动编写测试用例，或通过配置文件形式编写测试用例来进行用例管理；编写sql语句准备测试数据；对得到的返回结果进行纯肉眼的比对，或借助测试代码比对。

举例而言，现有技术中对Java接口进行自动化测试，一般采用JTester框架，JTester是一个类似JUnit的基于Java的单元测试框架。针对每个接口的自动化测试，均需要功能测试人员使用JTester手工编写不同的Java测试代码，并且按照JTester的特定格式准备测试用例文件，测试用例文件通过wiki的方式来准备。

而使用JTester执行Java接口测试，需要针对每个接口编写不同的Java测试代码，并按照JTester特定格式准备测试用例和测试数据，无法通过通用的页面，来完成不同接口的自动化测试执行，而且，对测试代码缺乏统一的规划和管理，容易造成测试代码的低复用率和低使用率。

另外，手工准备测试数据，纯肉眼比对测试结果，不仅工作量大，并且容易造成人为误判，从而影响测试结果的正确性。

发明内容

有鉴于此，本申请提出一种测试应用程序接口的方法、装置及系统，以解决现有技术测试应用程序接口工作量大，正确性不高的问题。

为实现上述目的，本申请的实施例提供了一种测试应用程序接口的方法，用于通过由客户端测试设置于服务器上的应用程序接口，所述方法包括以下步骤：步骤S1：通过所述客户端的人机界面接收所述应用程序接口的参数信息与断言；步骤S2：根据所述客户端与所述服务器间的通信协议，将所述参数信息封装为符合所述通信协议的接口测试数据向所述服务器发送；步骤S3：接收所述服务器处理后的返回数据；以及步骤S4：通过所述断言解析所述返回数据并通过人机界面显示测试结果。

较佳地，所述参数信息包括接口信息和测试数据。

较佳地，所述接口信息包括通信协议和接口地址。

较佳地，所述接口信息还包括接口名称和/或接口版本号。

较佳地，所述通信协议为HTTP协议、HESSIAN协议或DUBBO协议。

较佳地，当所述通信协议为HESSIAN协议或DUBBO协议时，且所述应用程序接口为Java应用程序接口时，步骤S2之前包括以下步骤：步骤S2A：接收打包有所述应用程序接口本身和解析文件的归档文件JAR包；以及步骤S2B：根据Java中的反射技术从JAR包中获取所述应用程序接口的输入参数和输出参数的数据类型。

本申请的实施例还提供了一种测试应用程序接口的装置，用于测试设置于服务器上的应用程序接口，包括：信息接收单元，用于通过人机界面接收所述应用程序接口的参数信息与断言；封装单元，用于根据所述装置与所述服务器间的通信协议，将所述参数信息封装为符合所述通信协议的接口测试数据；发送单元，用于将所述测试数据向所述服务器发送；接收单元，用于接收所述服务器处理后的返回数据；解析单元，用于通过所述断言解析所述返回数据；以及显示单元，用于将解析后的结果通过人机界面显示。

较佳地，所述参数信息包括接口信息和测试数据。

较佳地，所述接口信息包括通信协议和接口地址。

较佳地，所述接口信息还包括接口名称和/或接口版本号。

较佳地，所述通信协议为HTTP协议、HESSIAN协议或DUBBO协议。

较佳地，还包括：JAR包接收单元，用于当所述通信协议为HESSIAN协议或DUBBO协议时，且所述应用程序接口为Java应用程序接口时，接收打包有所述应用程序接口本身和解析文件的归档文件JAR包；数据类型获取单元，用于根据Java中的反射技术从所述JAR包中获取所述应用程序接口的输入参数和输出参数的数据类型。

本申请的实施例还提供了一种测试应用程序接口的系统，包括上述任一种装置和设置有应用程序接口的服务器。

由上述技术方案可知，本申请的实施例具有以下有益效果：无需测试人员编写测试代码，通过页面输入测试数据并可通过页面直接显示测试结果，能够减小测试人员的工作量并提高准确性。

通过以下参照附图对优选实施例的说明，本申请的上述以及其它目的、特征和优点将更加明显。

附图说明

图1为根据本申请一实施例提供的测试应用程序接口方法的流程图；

图2为根据本申请一实施例的接口信息输入界面示意图；

图3为根据本申请一实施例的测试数据输入界面示意图；

图4为根据本申请一实施例的测试数据输入界面示意图；

图5为根据本申请一实施例的显示数据类型的界面的示意图；

图6为根据本申请一实施例的断言输入界面示意图；

图7为根据本申请一实施例的测试结果显示界面示意图；

图8为根据本申请一实施例提供的测试应用程序接口的装置的框图。

具体实施方式

下面将详细描述本申请的具体实施例。应当注意，这里描述的实施例只用于举例说明，并不用于限制本申请。而且，在下述说明中，不同的“一实施例”或“实施例”指的不一定是同一实施例。此外，一或多个实施例中的特定特征、结构、或特点可由任何合适形式组合。

请参阅图1所示，其为根据本申请一实施例提供的测试应用程序接口方法的流程图。本实施例的方法用于由客户端测试设置于服务器上的应用程序接口。

其中，客户端上可设有测试平台，该测试平台例如包括浏览器以及具有数据处理能力的装置，并以页面的形式作为人机界面来接收测试人员输入的参数信息。在一实施例中，客户端与服务器间基于B/S(Browser/Server，浏览器/服务器)架构。

本申请一实施例提供的测试应用程序接口的方法中，客户端执行以下步骤：

步骤S1：通过客户端的人机界面接收应用程序接口的参数信息与断言；

在本申请的实施例中，参数信息和断言可由测试人员通过人机界面输入。这里，参数信息可包括接口信息和测试数据。其中，接口信息可包括通信协议、接口地址、接口名称或接口版本号等信息中的一种或几种，并可由如图2所示的接口信息输入界面输入。

通信协议是指客户端与服务器间的通信协议，在如图2所示的实施例中，可选的通信协议包括HTTP协议(HyperText Transfer Protocol，超文本传输协议)、HESSIAN协议和DUBBO协议，其中，HESSIAN协议和DUBBO协议是本领域技术人员知晓的基于HTTP协议的网络传输协议。

测试人员可通过如图2所示的界面中参数名为“接口类型”的三个选项按钮选择所应用的协议。

接口地址是指应用程序接口所在的服务器的地址，例如可通过图2所示的界面中参数名为“服务提供者”的文本框输入。通过在界面中输入不同的接口地址来实现对不同接口进行测试。

需要说明的是，在配置接口地址时，由于HTTP协议有默认的端口号，所以如果选择HTTP协议，且采用默认的端口号，则不需要在接口地址里配置端口号，例如，只需输入地址“127.0.0.1/fly/recommend.do”，便会采用默认端口号，例如80。但是HESSIAN和DUBBO没有默认的端口号，所以在输入接口地址时，需要单独配置端口号，例如“127.0.0.1：51/fly/recommend.do”，其中“51”便为端口号。

客户端可根据拼装规则针对不同协议来拼装最终的接口地址，以寻找服务器，这里，最终的接口地址为URL(Uniform/Universal Resource Locator，统一资源定位符)。

在一实施例中，所采用的拼装规则为“通信协议+接口地址”。举例而言，若测试人员选择的通信协议为HTTP，在“服务提供者”的文本框中输入的接口地址为“127.0.0.1/fly/recommend.do”，则得到的URL为http://127.0.0.1/fly/recommend.do；若测试人员选择的通信协议为HESSIAN，在“服务提供者”的文本框中输入的接口地址为“127.0.0.1：51/fly/recommend.do”，则得到的URL为hessian://127.0.0.1：51/fly/recommend.do；若测试人员选择的通信协议为DUBBO，在“服务提供者”的文本框中输入的接口地址为“127.0.0.1：20880”，则得到的URL为“dubbo://127.0.0.1：20880”。

需要说明的是，当测试人员选择的通信协议是DUBBO时，还需要输入接口的名称和版本号，这是因为：根据DUBBO协议规定，需要根据接口名称和版本号来确定一个唯一的接口。在如图2所示的实施例中，可通过参数名为“Interface”的文本框输入接口的名称，并通过参数名为“接口版本”的文本框输入版本号。

通常，需针对被测接口编写测试用例，在本申请的实施例中，测试用例包括测试数据和断言，其中，测试数据是为测试应用程序接口而输入的数据。例如，当测试一个登录功能时，测试人员需准备各种正确的和错误的用户名和密码，来验证登录功能是否正确，则在本例中，测试数据由用户名和密码组成，而每一组用户名和密码能否成功登录，可以通过断言来验证。

测试数据可通过页面来输入，在一实施例中，通过不同于图2接口信息输入界面的图3或图4的输入界面来输入测试数据，具体地，可通过点击图2中设置的按钮(未示出)跳转到图3或图4的界面，或通过文本框(未示出)输入网址来打开图3或图4的页面。本领域技术人员可以理解，测试数据输入界面也可与接口信息输入界面通过同一页面来实现。

在输入测试数据的界面中，包括参数名和参数值。例如，在图3所示的实施例中，“recid”、“uid”、“count”、“pageid”和“pid”为参数名，在各参数后的文本框中的“1001”、“lizhining”、“10”、“1234”和“5678”为各参数名的对应的参数值。

另外，人机界面所接收的断言用于解析服务器返回的处理数据。对于断言，将在后续做出详细说明。

步骤S2：根据客户端与服务器间的通信协议，将参数信息封装为符合该通信协议的接口测试数据向服务器发送；

需要说明的是，由于服务器对不同的数据类型有不同的处理方式，因此，客户端需知晓所接收的输入参数的数据类型和需要服务器输出的输出参数的数据类型以告知服务器。

在一实施例中，客户端与服务器间采用HTTP协议，由于HTTP协议的接口只能够接受字符串类型的数据，所以针对HTTP协议接口，只需配置如图3所示的参数和相应的参数值，便可完成测试数据的输入。

在完成接口信息和测试数据的输入后，客户端可将接口信息中的url与参数名及其参数值封装为接口测试数据向服务器发送。例如，若接口的url是http://127.0.0.1/test，则与图3组装后，接口测试数据是：http://127.0.0.1/test？recid＝1001&uid＝lizhining&count＝10&pageid＝1234&pid＝5678。

在另一实施例中，客户端与服务器间采用HESSIAN或DUBBO协议，由于这两个协议非单纯的HTTP协议，因而无法直接获知输入参数和输出参数的数据类型。

因此，在对Java应用程序接口进行测试的实施例中，在步骤S2之前，执行步骤S2A.接收打包有应用程序接口本身和解析文件的JAR(JavaArchive，Java归档文件)包，其中，应用程序接口本身可为该应用程序的源代码；步骤S2B.根据Java中的反射技术从JAR包中获取应用程序接口的输入参数和输出参数的数据类型，其中，反射技术是Java中自带的技术。

具体地，解析文件为用于解析服务器返回的处理数据的解析工具。对于HTTP协议，可以直接由断言解析服务器返回的处理数据，而对于HESSIAN协议和DUBBO协议，需经解析文件解析服务器返回的处理数据后，才能进一步由断言解析，这里，解析文件可为现有的某种解析工具。

JAR文件可由测试人员通过客户端提供的页面上传。JAR包中可包括多个应用程序接口的源程序，测试人员可以选择所需的输入参数和输入参数，并可通过例如如图5所示的页面显示所需接口的输入参数和输出参数的数据类型，以供测试人员更为直观地确认所选择的参数类型。

从图5中可以看出，通过Java中的反射技术得出参数“memberId”、“userName”和“password”的参数类型为“Java.lang.String”，其是标准的Java类型，而参数certificate的参数类型是“com.alibaba.dw.dwsoa.common.security.model.UserCertificate”，其是自定义的一种类型，而非标准的Java类型。

图5所示界面所属应用程序接口的测试数据输入界面即为图4。

步骤S3：接收所述服务器处理后的返回数据；

服务器在接收到接口测试数据后，会根据设于其上的应用程序接口对接口测试数据进行处理，并将处理后的数据返回。

步骤S4：通过断言解析返回数据并通过人机界面显示测试结果。

断言，也就是对服务器的返回数据进行判断的一个过程，其可通过页面来输入，例如如图6所示的界面，在一实施例中，断言输入界面和测试数据输入界面通过同一页面来实现。

如上所述，对于应用HTTP协议时得到的返回结果，可以直接由断言判断返回结果；而对于HESSIAN协议和DUBBO协议，需经上述解析文件解析服务器返回的处理结果后，才能进一步由断言作出判断。

以下，以Java应用程序接口的测试为例作出说明，这里，断言支持对象断言方式，即支持Java中所有对象的比较与判断。

在一实施例中，服务器所返回的数据(或经解析工具解析后的数据，以下统称为返回数据)为标准的JSON(Java Script Object Notation，Java Script对象标识)格式，例如返回数据为：{″returnCode″：0，″successed″：true，″returnValue″：{″count″：0}，″returnMessage″：″ok″，″returnErrorStackTrace″：″″}。

针对该标准JSON格式的返回数据，可通过断言对其进行解析。例如测试人员需要判断returnValue中的count值是否为0，在一实施例中，可使用如下断言方式：returnValue.count|object_equals|0。其中，returnValue.count是按照标准的Java格式所编写，即服务器返回的实际结果，|object_equals|是本申请约定的一个断言类型，即对象断言的实例化，0是我们所希望的预期结果，本断言用以判断服务器返回的returnValue.count是否为“0”。

因此，针对上例中所属，该断言返回结果为通过。但如果断言配置为：returnValue.count|object_equals|1，则断言的返回结果为失败。

另外，本实施例也支持标准的Java方法，包括字符串、数组等的所有方法。例如，对于如下返回结果，{″returnCode″：0，″successed″：true，″returnValue″：[{″vistConCnt″：10}，{″vistConCnt″：11}]}，returnValue便为一数组，测试人员可使用调用数组的所有方法，例如，想要判断该数组的长度是否等于2，即可通过如下方式编写断言：returnValue.size()|object_equals|2。图6即为编写的断言的示例。

相较于现有技术中需通过测试代码获取接口的返回结果，并且需手动编写断言的判断方式，本实施例可直接对返回结果进行解析与直观显示。

需要说明的是，以上所示的各界面仅为客户端界面的一种可选形式，本领域技术人员可以采用其他合适的界面形式和其他方式的界面相互链接关系。另外，界面可以是页面形式，也可以是其他显示的人机界面。

执行断言后会在例如图7所示的页面上显示每个断言执行成功或者失败的结果，以供测试人员参考，其中，若预期结果与实际结果一致，则为执行成功的结果，显示为“Pass”；若预期结果与实际结果不一致，则为执行失败的结果，显示为“Fail”。在图6和图7所示的示例中，图6最后一行表示断言参数retureValue.size()的预期结果为“4”，而在图7中可以看出，服务器返回的实际结果却为“5”，因此，执行结果为“Fail”。在实际工作中，测试人员可通过界面仅关注失败的断言来确定应用程序接口是否正确工作，可大大提高测试效率。

由上可知，本申请的实施例中无需测试人员编写测试代码，通过通用页面输入测试数据并可通过页面直接显示测试结果，能够减小测试人员的工作量并提高准确性。

与上述方法相对应，本申请还提供一种测试应用程序接口的装置。

请参阅图8所示，在本实施例中，该测试应用程序接口的装置8用于测试设置于服务器上的应用程序接口，包括：信息接收单元81、封装单元82、发送单元83、接收单元84、解析单元85以及显示单元86。

信息接收单元81，用于通过人机界面接收应用程序接口的参数信息与断言。

封装单元82，用于根据装置与所述服务器间的通信协议，将参数信息封装为符合通信协议的接口测试数据；

发送单元83，用于将测试数据向服务器发送；

接收单元84，用于接收服务器处理后的返回数据；

解析单元85，用于通过断言解析返回数据；以及

显示单元86，用于将解析后的结果通过人机界面显示。

其中，参数信息可包括接口信息和测试数据；接口信息可包括通信协议和接口地址，还可包括接口名称和/或接口版本号。

其中，通信协议为HTTP协议、HESSIAN协议或DUBBO协议。

优选地，该测试装置8还包括JAR包接收单元87，用于当所述通信协议为HESSIAN协议或DUBBO协议时，且所述应用程序接口为Java应用程序接口时，接收打包有应用程序接口本身和解析文件的归档文件JAR包；以及数据类型获取单元88，用于根据Java中的反射技术从JAR包中获取应用程序接口的输入参数和输出参数的数据类型。

对于测试应用程序接口的装置8进行测试的实现细节，可参见方法实施例的具体描述，在此不再赘述。

本申请实施例中的测试应用程序接口的装置，无需测试人员编写测试代码，通过通用页面输入测试数据并可通过页面直接显示测试结果，能够减小测试人员的工作量并提高准确性。

本申请还提供一种测试应用程序接口的系统，其包括上述任一种测试应用程序接口的装置和设置有应用程序接口的服务器。

本领域技术人员可以明白，这里结合所公开的实施例描述的各种示例性的方法步骤和装置单元均可以电子硬件、软件或二者的结合来实现。为了清楚地示出硬件和软件之间的可交换性，以上对各种示例性的步骤和单元均以其功能性的形式进行总体上的描述。这种功能性是以硬件实现还是以软件实现依赖于特定的应用和整个系统所实现的设计约束。本领域技术人员能够针对每个特定的应用，以多种方式来实现所描述的功能性，但是这种实现的结果不应解释为倒是背离本申请的范围。

虽然已参照几个典型实施例描述了本申请，但应当理解，所用的术语是说明和示例性、而非限制性的术语。由于本申请能够以多种形式具体实施而不脱离发明的精神或实质，所以应当理解，上述实施例不限于任何前述的细节，而应在随附权利要求所限定的精神和范围内广泛地解释，因此落入权利要求或其等效范围内的全部变化和改型都应为随附权利要求所涵盖。

Claims (13)

1.一种测试应用程序接口的方法，其特征在于，用于由客户端测试设置于服务器上的应用程序接口，所述方法包括以下步骤：

步骤S1：通过所述客户端的人机界面接收所述应用程序接口的参数信息与断言；

步骤S2：根据所述客户端与所述服务器间的通信协议，将所述参数信息封装为符合所述通信协议的接口测试数据向所述服务器发送；

步骤S3：接收所述服务器处理后的返回数据；以及

步骤S4：通过所述断言解析所述返回数据并通过人机界面显示测试结果。

2.根据权利要求1所述的方法，其特征在于，所述参数信息包括接口信息和测试数据。

3.根据权利要求2所述的方法，其特征在于，所述接口信息包括通信协议和接口地址。

4.根据权利要求3所述的方法，其特征在于，所述接口信息还包括接口名称和/或接口版本号。

5.根据权利要求1所述的方法，其特征在于，所述通信协议为HTTP协议、HESSIAN协议或DUBBO协议。

6.根据权利要求1所述的方法，其特征在于，当所述通信协议为HESSIAN协议或DUBBO协议时，且所述应用程序接口为Java应用程序接口时，步骤S2之前包括以下步骤：

步骤S2A：接收打包有所述应用程序接口本身和解析文件的归档文件JAR包；以及

步骤S2B：根据Java中的反射技术从JAR包中获取所述应用程序接口的输入参数和输出参数的数据类型。

7.一种测试应用程序接口的装置，其特征在于，用于测试设置于服务器上的应用程序接口，包括：

信息接收单元，用于通过人机界面接收所述应用程序接口的参数信息与断言；

封装单元，用于根据所述装置与所述服务器间的通信协议，将所述参数信息封装为符合所述通信协议的接口测试数据；

发送单元，用于将所述测试数据向所述服务器发送；

接收单元，用于接收所述服务器处理后的返回数据；

解析单元，用于通过所述断言解析所述返回数据；以及

显示单元，用于将解析后的结果通过人机界面显示。

8.根据权利要求7所述的装置，其特征在于，所述参数信息包括接口信息和测试数据。

9.根据权利要求8所述的装置，其特征在于，所述接口信息包括通信协议和接口地址。

10.根据权利要求9所述的装置，其特征在于，所述接口信息还包括接口名称和/或接口版本号。

11.根据权利要求7所述的装置，其特征在于，所述通信协议为HTTP协议、HESSIAN协议或DUBBO协议。

12.根据权利要求7所述的装置，其特征在于，还包括：

JAR包接收单元，用于当所述通信协议为HESSIAN协议或DUBBO协议时，且所述应用程序接口为Java应用程序接口时，接收打包有所述应用程序接口本身和解析文件的归档文件JAR包；

数据类型获取单元，用于根据Java中的反射技术从所述JAR包中获取所述应用程序接口的输入参数和输出参数的数据类型。

13.一种测试应用程序接口的系统，其特征在于，包括如权利要求7-12中任一项所述的装置和设置有应用程序接口的服务器。

Images