CN108664385A - 一种应用程序编程接口的测试方法及装置 - Google Patents

一种应用程序编程接口的测试方法及装置 Download PDF

Info

Publication number
CN108664385A
CN108664385A CN201710198569.7A CN201710198569A CN108664385A CN 108664385 A CN108664385 A CN 108664385A CN 201710198569 A CN201710198569 A CN 201710198569A CN 108664385 A CN108664385 A CN 108664385A
Authority
CN
China
Prior art keywords
api
test
test case
interface
metadata
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN201710198569.7A
Other languages
English (en)
Inventor
李林锋
苗彩霞
丁伟峰
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Huawei Technologies Co Ltd
Original Assignee
Huawei Technologies Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Huawei Technologies Co Ltd filed Critical Huawei Technologies Co Ltd
Priority to CN201710198569.7A priority Critical patent/CN108664385A/zh
Publication of CN108664385A publication Critical patent/CN108664385A/zh
Pending legal-status Critical Current

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/36Preventing errors by testing or debugging software
    • G06F11/3668Software testing
    • G06F11/3672Test management
    • G06F11/3684Test management for test design, e.g. generating new test cases
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/36Preventing errors by testing or debugging software
    • G06F11/3668Software testing
    • G06F11/3672Test management
    • G06F11/3688Test management for test execution, e.g. scheduling of test suites

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Quality & Reliability (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Debugging And Monitoring (AREA)

Abstract

本申请公开了一种API的测试方法及装置,用以解决现有技术中存在的接口对接测试准确性较低的问题。方法包括:根据第一API的元数据,生成第一API与第二API间的测试用例和模拟测试桩,第一API和第二API为生产环境包含的多个API中任意两个不同的API,第一API的元数据用于表征第一API的接口信息;调用模拟测试桩在生产环境中执行测试用例;若测试用例执行通过,则确定第一API与第二API间的接口对接测试成功。

Description

一种应用程序编程接口的测试方法及装置
技术领域
本申请涉及计算机技术领域,尤其涉及一种应用程序编程接口(ApplicationProgramming Interface,API)的测试方法及装置。
背景技术
在通信技术领域,尤其是在复杂的信息技术/通信技术(InformationTechonology/Communication Techonology,IT/CT)***中,常常涉及多个API之间的集成对接。在对***中的API进行接口对接测试时,通常采用如下方法:调研人员对***中的API进行调研,形成API的调研文档;然后经研发人员与调研人员反复确定调研文档的技术细节;调研文档交由测试人员后,由测试人员根据调研文档搭建测试环境,然后在搭建的测试环境中对每两个API进行接口对接测试。
上述API的接口对接测试方法存在如下缺陷:API的接口对接测试是基于测试人员搭建的测试环境进行的,实现时难以保证测试环境与真实的生产环境的一致性,从而影响接口对接测试的准确性。
综上,现有技术中提供的方案中,存在接口对接测试的准确性较低的问题。
发明内容
本申请提供一种API的测试方法及装置,用以解决现有技术中存在的接口对接测试准确性较低的问题。
第一方面,本申请实施例提供一种API的测试方法。该方法包括如下步骤:根据第一API的元数据,生成第一API与第二API间的测试用例和模拟测试桩;调用模拟测试桩在生产环境中执行测试用例;若测试用例执行通过,则确定第一API与第二API间的接口对接测试成功。其中,第一API和第二API为生产环境包含的多个API中任意两个不同的API,第一API的元数据用于表征第一API的接口信息。
在第一方面提供的API的测试方法中,根据第一API的元数据,生成第一API与第二API间的测试用例和模拟测试桩,然后通过调用模拟测试桩在生产环境中执行测试用例,在测试用例执行通过时确定第一API与第二API间的接口对接测试成功。由于第一方面提供的方法是在生产环境中,通过调用模拟测试桩来执行测试用例实现的,因此采用第一方面提供的方法对API进行接口对接测试,测试的准确性更高。
基于第一方面,在一种可能的实现方式中,在调用模拟测试桩在生产环境中执行测试用例之后,还包括:若测试用例未执行通过,则修正第一API的元数据;然后,根据修正后的第一API的元数据,更新第一API与第二API间的测试用例和模拟测试桩;调用更新后的模拟测试桩在生产环境中执行更新后的测试用例,直至更新后的测试用例执行通过。
由于第一API的元数据可能存在错误,因此,当第一API与第二API的测试用例未执行通过时,即可认为第一API的元数据中存在错误,此时需要对第一API的元数据进行修正。通过对第一API的元数据进行修正,可以提高第一API的元数据的准确性,使得第一API的元数据能更真实地表征第一API的接口信息,从而提高接口对接测试的准确性。
在第一方面提供的方法中,测试用例未执行通过的原因有多种。针对不同原因,对第一API的元数据进行修正的方式也不同。下面仅列举其中三种情况:
第一种情况
若确定测试用例未执行通过的原因为第一API的元数据缺失可选字段,则在第一API的元数据中增加可选字段。
第二种情况
若确定测试用例未执行通过的原因为第一API中未携带第一API的元数据中定义的必选字段,则将第一API的元数据中定义的必选字段修正为可选字段。
第三种情况
若确定测试用例未执行通过的原因为传输数据的数据类型与第一API的元数据中定义的数据类型不一致,则将测试用例未执行通过的信息记录入第一API对应的接口日志中,并根据录入了上述信息的接口日志修正第一API的元数据。比如,若第一API的元数据中定义的数据类型为数字类型,而传输数据的数据类型为字符串类型,那么测试用例则会执行不通过。此时可将测试用例未执行通过的信息记录在第一API对应的接口日志中,后续即可根据第一API对应的接口日志修正第一API的元数据。
基于第一方面,在一种可能的实现方式中,在确定第一API与第二API间的接口对接测试成功之后,还包括:录制第一API与第二API间的调测环境信息,调测环境信息包含第一API与第二API间的接口契约、第一API对应的接口日志和测试用例,调测环境信息用于在开发环境中生成模拟生产环境的联调环境。在开发环境中导入多个API中任意两个不同的API生成的多个调测环境信息,即可生成模拟生产环境的联调环境。
生成模拟生产环境的联调环境后,即可在联调环境中对***中的多个接口进行接口对接测试,而不必再在生产环境中进行接口对接测试。从而避免***中的API在研发阶段进行不断修改时,需要频繁在生产环境中进行接口对接测试的问题。
基于第一方面,在一种可能的实现方式中,在生成模拟生产环境的联调环境之后,还可调用预先编译的第一API的实际测试桩在联调环境中执行测试用例,若测试用例执行通过,则确定该实际测试桩无误;若测试用例未执行通过,则调用修改后的所述实际测试桩在联调环境中执行所述测试用例,直至测试用例执行通过。
需要说明的是,在联调环境中调用实际测试桩执行测试用例的过程,与在生产环境中调用模拟测试桩执行测试用例的过程略有不同:在生产环境中执行测试用例时,第一API的请求消息或应答消息是模拟测试桩发送的,第二API的应答消息或请求消息是该第二API实体发送的;而在联调环境中执行测试用例时,第一API的请求消息或应答消息是通过调用研发人员编写的程序代码实现的,第二API的应答消息或请求消息是联调环境模拟发送的。因此,调用实际测试桩在联调环境中执行测试用例时,若测试用例未执行通过,说明研发人员编写的程序代码中存在错误,从而帮助研发人员改进程序代码,指导开发过程。
基于第一方面,在一种可能的实现方式中,若第一API处于客户端中,第二API处于服务端中,则预设的第一API与第二API间的接口契约包含第一API的接口信息、第二API的接口信息、第一API向第二API的请求信息、第二API向第一API的应答信息、以及第一API与第二API间的交互上下文信息;若第一API处于服务端中,第二API处于客户端中,则预设的第一API与第二API间的接口契约包含第一API的接口信息、第二API的接口信息、第一API向第二API的应答信息、第二API向第一API的请求信息、以及第一API与第二API间的交互上下文信息。
第二方面,本申请提供一种API的测试装置,该装置包括第一生成模块、调用模块和第一确定模块。
第一生成模块用于根据第一API的元数据,生成第一API与第二API间的测试用例和模拟测试桩;调用模块用于调用模拟测试桩在生产环境中执行测试用例;第一确定模块用于在测试用例执行通过时,确定第一API与第二API间的接口对接测试成功。
其中,第一API和第二API为生产环境包含的多个API中任意两个不同的API,第一API的元数据用于表征第一API的接口信息。
在第二方面提供的API的测试装置中,第一生成模块根据第一API的元数据,生成第一API与第二API间的测试用例和模拟测试桩,然后调用模块通过调用模拟测试桩在生产环境中执行测试用例,第一确定模块在测试用例执行通过时确定第一API与第二API间的接口对接测试成功。由于采用第二方面提供的API的测试装置进行接口对接测试时,调用模块通过调用模拟测试桩在生产环境中来执行测试用例,因此对第一API进行接口对接测试,测试的准确性更高。
基于第二方面,在一种可能的实现方式中,API的测试装置还包括修正模块,修正模块用于在测试用例未执行通过时,修正第一API的元数据;第一生成模块还用于根据修正模块修正后的第一API的元数据,更新第一API与第二API间的测试用例和模拟测试桩;调用模块还用于调用更新后的模拟测试桩在生产环境中执行更新后的测试用例,直至更新后的测试用例执行通过。
由于第一API的元数据可能存在错误,因此,当第一API与第二API的测试用例未执行通过时,即可认为第一API的元数据中存在错误,此时需要对第一API的元数据进行修正。通过修正模块对第一API的元数据进行修正,可以提高第一API的元数据的准确性,使得第一API的元数据能更真实地表征第一API的接口信息,从而提高接口对接测试的准确性。
在第二方面提供的API的测试装置中,测试用例未执行通过的原因有多种。针对不同原因,修正模块在修正第一API的元数据时,修正方式包括但不限于以下三种:
第一种情况
若确定测试用例未执行通过的原因为第一API的元数据缺失可选字段,则修正模块在第一API的元数据中增加可选字段。
第二种情况
若确定测试用例未执行通过的原因为第一API中未携带第一API的元数据中定义的必选字段,则修正模块将第一API的元数据中定义的必选字段修正为可选字段。
第三种情况
若确定测试用例未执行通过的原因为传输数据的数据类型与第一API的元数据中定义的数据类型不一致,则修正模块将测试用例未执行通过的信息记录入第一API对应的接口日志中,并根据录入了信息的接口日志修正第一API的元数据。
基于第二方面,在一种可能的实现方式中,API的测试装置还包括:录制模块,录制模块用于在第一确定模块确定第一API与第二API间的接口对接测试成功之后,录制第一API与第二API间的调测环境信息,调测环境信息包含第一API与第二API间的接口契约、第一API对应的接口日志和测试用例,调测环境信息用于在开发环境中生成模拟生产环境的联调环境。
此外,API的测试装置还可包括第二生成模块,第二生成模块用于在开发环境中导入多个API中任意两个不同的API生成的多个调测环境信息,生成模拟生产环境的联调环境。
第二生成模块生成模拟生产环境的联调环境后,即可在联调环境中对***中的多个接口进行接口对接测试,而不必再在生产环境中进行接口对接测试。从而避免***中的API在研发阶段进行不断修改时,需要频繁在生产环境中进行接口对接测试的问题。
基于第二方面,在一种可能的实现方式中,调用模块还用于在第二生成模块生成模拟生产环境的联调环境之后,调用预先编译的第一API的实际测试桩在联调环境中执行测试用例;该装置还可包括第二确定模块,第二确定模块用于在测试用例执行通过时,确定实际测试桩无误;调用模块还用于在测试用例未执行通过时,调用修改后的实际测试桩在联调环境中执行测试用例,直至测试用例执行通过。
需要说明的是,在联调环境中调用实际测试桩执行测试用例的过程,与在生产环境中调用模拟测试桩执行测试用例的过程略有不同:在生产环境中执行测试用例时,第一API的请求消息或应答消息是模拟测试桩发送的,第二API的应答消息或请求消息是该第二API实体发送的;而在联调环境中执行测试用例时,第一API的请求消息或应答消息是通过调用研发人员编写的程序代码实现的,第二API的应答消息或请求消息是联调环境模拟发送的。因此,调用模块调用实际测试桩在联调环境中执行测试用例时,若测试用例未执行通过,说明研发人员编写的程序代码中存在错误,从而帮助研发人员改进程序代码,指导开发过程。
基于第二方面,在一种可能的实现方式中,若第一API处于客户端中,第二API处于服务端中,则预设的第一API与第二API间的接口契约包含第一API的接口信息、第二API的接口信息、第一API向第二API的请求信息、第二API向第一API的应答信息、以及第一API与第二API间的交互上下文信息;若第一API处于服务端中,第二API处于客户端中,则预设的第一API与第二API间的接口契约包含第一API的接口信息、第二API的接口信息、第一API向第二API的应答信息、第二API向第一API的请求信息、以及第一API与第二API间的交互上下文信息。
第三方面,本申请实施例提供一种API的测试方法,该API的测试装置包括收发器,处理器和存储器。收发器、处理器和存储器通过总线连接。该收发器用于支持该API的测试装置与其他设备之间收发信息。处理器通过调用存储器中存储的程序代码和数据来实现对第一API进行接口对接测试。
第四方面,本申请实施例提供一种计算机可读存储介质,计算机可读存储介质中存储有计算机执行指令,当计算节点的至少一个处理器执行该计算机执行指令时,计算节点执行上述第一方面或者第一方面的各种可能实现方式提供的方法。
第五方面,本申请实施例提供一种计算机程序产品,该计算机程序产品包括计算机执行指令,该计算机执行指令存储在计算机可读存储介质中。计算节点的至少一个处理器可以从计算机可读存储介质读取该计算机执行指令,至少一个处理器执行该计算机执行指令使得计算节点实施上述第一方面或者第一方面的各种可能实现方式提供的方法。
附图说明
图1为本申请实施例提供的一种API的结构示意图;
图2为本申请实施例提供的一种API的测试方法的流程示意图;
图3为本申请实施例提供的一种在联调环境中执行测试用例的流程示意图;
图4为本申请实施例提供的另一种API的测试方法的流程示意图;
图5为本申请实施例提供的一种API的测试装置的结构示意图;
图6为本申请实施例提供的另一种API的测试装置的结构示意图。
具体实施方式
为了使本申请的目的、技术方案和优点更加清楚,下面将结合附图对本申请作进一步地详细描述。
本申请提供一种API的测试方法及装置,用以解决现有技术中存在的接口对接测试准确性较低的问题。其中,方法和装置是基于同一发明构思的,由于方法及装置解决问题的原理相似,因此装置与方法的实施可以相互参见,重复之处不再赘述。
在IT/CT***,尤其是复杂的IT/CT***中,常常涉及多个API间的集成对接。其中,多个API可能来自不同的厂家、采用不同的协议,因此如何对多个API进行接口对接测试是一个亟待解决的问题。以某个基站子***(Base Sation Subsystem,BSS)为例,该***中集成的API的相关数据如下:涉及集成对接的厂家超过100个,涉及集成对接的API超过1000个,涉及集成对接的协议超过4种。若等到***中的全部API开发完成后再在生产环境中对***中的多个API进行接口对接测试,往往会导致错误到最后一个环节才被发现,进而导致错误的修复成本变高。
现有技术中,为了将API的对接测试前置、尽早发现错误,通常在研发阶段即对API进行接口对接测试,方法如下:在API的需求调研环节,调研人员获取API提供者提供的API调研文档;研发人员获取该调研文档后,就简单对象访问协议(Simple Object AccessProtocol,SOAP)协议是否做安全认证、是否有抓包参考码流等技术细节与调研人员进行沟通,然后将最终确认的调研文档交给测试人员。测试人员根据调研文档搭建测试环境,并在搭建的测试环境中对API进行接口对接测试。
在这种对API进行接口对接测试的方法中,由于API的接口对接测试是基于测试人员搭建的测试环境进行的,实现时难以保证测试环境与真实的生产环境的一致性,从而影响接口对接测试的准确性。因此,现有技术中提供的对API进行接口对接测试的方案中,存在接口对接测试的准确性较低的问题。
本申请提供一种API的测试方法及装置,用以解决现有技术中存在的接口对接测试准确性较低的问题。
需要说明的是,本申请中所涉及的多个,是指两个或两个以上。另外,需要理解的是,在本申请的描述中,“第一”、“第二”等词汇,仅用于区分描述的目的,而不能理解为指示或暗示相对重要性,也不能理解为指示或暗示顺序。
下面,为了让本申请更容易被理解,对本申请中涉及的基本概念进行解释。
一、API的元数据
API的元数据用于表征API的接口信息,API的元数据通常与具体的API以及API使用的协议等无关。
本申请中,API元数据主要由以下四部分组成:
1、API描述:即API的type字段和metadata字段,type字段用来说明API使用的协议类型,metadata字段用来导入具体描述该API的协议规范(通常是W3C标准规范,或者业界广泛使用的准规范)文件。比如,当API的type为SOAP时,API的协议规范文件为*.wsdl文件,该协议规范文件可来定义API的协议参数、数据结构等。其中,API的数据结构包含请求消息的数据结构、应答消息的数据结构以及异常消息的数据结构等。
2、API资源:即通过services来描述API对应的服务实现。其中,复杂的API会关联多个服务实现者,因此一个API可以对应多个服务实现提供者。
3、API策略:API的策略包括路由策略、流控策略、超时控制、服务等级协议(Service-Level Agreement,SLA)策略等,API的策略可以通过policies元素对进行配置。
4、API元数据扩展点:协议类型type、policies元素等都支持扩展。通过与handlers组合使用,可以支持API元数据的扩展。
基于统一的API元数据,可以对不同厂家或使用不同协议的API进行标准化、规范化的描述。
二、测试用例、模拟测试桩和实际测试桩
本申请中,测试用例是为了测试API接口是否能够满足在某个应用场景下的应用而编写的测试输入以及预期结果等,以便测试该API能否满足该应用场景的使用需求。比如,当某个API为处于客户端中的API(API消费者),那么该API对端的API即处于服务端中的API(API提供者)。在查询用户的话费余额这一应用场景下,API消费者向API提供者发送查询请求,API提供者向API消费者发送应答消息,该应答消息中包含用户的话费余额信息。在这个例子中,查询请求即为测试输入,应答消息即为预期结果。
本申请中,模拟测试桩是在生产环境中根据API的元数据自动生成的。在生产环境中通过调用模拟测试桩可对测试用例进行测试。
通常来说,API包含以下几个部分,如图1所示:基础协议层,用于传输网络协议消息;消息编码和解码层,用于将网络协议消息转换成真实的数据结果;API实现层,用于进行业务逻辑处理。在对某个API进行接口对接测试时,通常难以知晓对端API的业务逻辑处理,即对端API的API实现层对本端的API来说是一个黑盒。
在对本端API进行接口对接测试时,需要API消费者发送请求,API提供者做出应答。假设要进行接口对接测试的API为API消费者,那么对API消费者进行接口对接测试时,若API消费者发出请求消息,API提供者会向API消费者发送相应的应答消息。在生产环境中,模拟测试桩可模拟API消费者发出请求消息,该请求消息虽然不能真实地模拟API消费者的请求消息,但能体现API消费者和API提供者间的接口契约等信息,生产环境中的API提供者实体在接收到该请求消息后,会向API消费者(模拟测试桩)发送应答消息。通过调用模拟测试桩执行测试用例,可通过测试用例的执行结果判断API的接口对接测试是否成功。
本申请中,对于一个API来说,在对该API(本端API)和对端API进行接口对接测试时,API、元数据、测试用例和模拟测试桩具有如下对应关系:本端API对应一个元数据,一个元数据对应多个测试用例,一个元数据对应一个模拟测试桩;多个测试用例代表本端API和对端API间的多个应用场景,模拟测试桩用于模拟本端API的请求消息或应答消息,通过调用该模拟测试桩可以分别执行多个测试用例,即测试本端API与对端API能否满足多个应用场景的使用需求。
也就是说,模拟测试桩虽不能真实地模拟本端API的业务处理逻辑,但是在进行接口对接测试时,若进行接口对接测试的为API提供者,模拟测试桩可在客户端向服务端发起请求时模拟服务端的应答消息,从而对API提供者进行接口对接测试;或者,若进行接口对接测试的为API消费者,模拟测试桩可模拟服务端接收的、来自客户端的请求消息,从而对API消费者进行接口对接测试。
本申请中,测试用例和模拟测试桩均可根据API的元数据生成。
生成测试用例的方式可以是:解析API元数据中的metadata字段,获取协议参数定义、请求消息的数据结构定义、应答消息的数据结构定义以及异常消息的数据结构定义。根据协议参数定义,生成参数配置模板;根据API的元数据中定义的字段类型、枚举值、异常类型等,生成边界条件测试和等价划分测试等策略,生成覆盖API主要执行路径的多个测试用例,生成的多个测试用例中包含正常场景下的测试用例以及异常场景下的测试用例。
生成模拟测试桩的方式可以是:解析API的元数据中的type字段,获取API的协议类型;解析API元数据中的metadata字段,获取请求消息的数据结构定义、应答消息的数据结构定义以及异常消息的数据结构定义。根据协议类型和消息(包含请求消息、应答消息和异常消息)的数据结构,调用接口模拟测试框架,即可生成API接口的模拟测试桩。其中,接口模拟测试框架的技术实现方式如下:根据该API的协议类型调用相关协议的服务端接口和客户端接口,创建服务端实例和客户端实例,并将请求消息和应答消息的数据结构绑定到服务端和客户端实例上,用于接收或者发送该协议的消息。
实际测试桩是研发人员编写的程序代码。显然,当进行接口对接测试的API处于客户端中时,通过实际测试桩可输出客户端的请求消息,或者当进行接口对接测试的API处于服务端中时,通过实际测试桩可输出服务端的应答消息。
需要说明的是,实际测试桩也可称为测试桩,本申请中为了将其与模拟测试桩区分开,将其称为“实际测试桩”。三、调测环境信息
本申请中,API的调测环境信息包含API的接口契约、接口日志和测试用例。
API的接口契约包含接口信息、请求信息、应答信息和交互上下文信息。其中,请求信息包含请求的URL(Uniform Resoure Locator,统一资源定位符)地址、HTTP(HyperTextTransfer Protocol,超文本传输协议)动作、请求的消息体;应答消息包含请求的URL地址、HTTP动作、请求的消息体;当API的协议类型为HTTP时,交互上下文信息可以为HTTP协议族的交互上下文信息。获取HTTP协议族的交互上下文信息的方式可以是:扩展的HTTP消息头采用Key:String-Value:String键值对的方式携带扩展字段,通过解析该扩展字段即可获取交互上下文信息。
API的接口日志是由模拟测试桩记录并生成的。当调用实际测试桩在联调环境中执行测试用例时,若测试用例未执行通过,API的接口日志可对结果判断和问题定位起到辅助作用。
四、生产环境、开发环境和联调环境
本申请中,生产环境是指交付客户正式为客户提供服务的环境;开发环境是指为支持***软件和应用软件的工程化开发和维护而使用的一组软件。
本申请中,联调环境是指在开发环境中生成的、用于模拟生产环境的环境。本申请中的联调环境可以真实地模拟生产环境。生成联调环境后,可在联调环境中对API进行接口对接测试。
下面结合附图对本申请提供的API测试方案进行具体说明。
参见图2,为本申请提供的一种API的测试方法的流程图。该方法包含如下步骤:
S201:根据第一API的元数据,生成第一API与第二API间的测试用例和模拟测试桩。
其中,第一API和第二API为生产环境包含的多个API中任意两个不同的API,第一API的元数据用于表征第一API的接口信息。本申请中所述的第一API和第二API并不是特指某两个接口,仅代表生产环境包含的多个API中任意两个不同的API。
本申请中,API可以是SOAP接口、RESTful接口或者其他私有接口,比如Oracle数据库的tuxedo接口。第一API的元数据可以是根据API自动化需求调研工具在生产环境中生成的。
S202:调用模拟测试桩在生产环境中执行测试用例。
其中,调用模拟测试桩在生产环境中执行测试用例可在第一API与第二API间的不同应用场景下对第一API和第二API进行接口对接测试。
需要说明的是,在对第一API和第二API进行接口对接测试时,对测试用例的数量不做限制。测试用例的数量与第一API和第二API间的应用场景的数量相同。比如,若第一API处于客户端中,第二API处于服务端中,客户端可向服务端查询话费余额和充值,那么,根据第一API的元数据可生成两个测试用例,一个测试用例用于客户端通过第一API请求向服务端查询话费余额,另一个测试用例用于客户端通过第一API请求向服务端进行充值。
S203:若测试用例执行通过,则确定第一API与第二API间的接口对接测试成功。
此外,若测试用例未执行通过,则修正第一API的元数据;根据修正后的第一API的元数据,更新第一API与第二API间的测试用例和模拟测试桩;然后调用更新后的模拟测试桩在生产环境中执行更新后的测试用例,直至更新后的测试用例执行通过。
由于第一API的元数据可能存在错误,因此,当第一API与第二API的测试用例未执行通过时,即可认为第一API的元数据中存在错误,此时需要对第一API的元数据进行修正。通过对第一API的元数据进行修正,可以提高第一API的元数据的准确性,使得第一API的元数据能更真实地表征第一API的接口信息,从而提高接口对接测试的准确性。
本申请中,第一API的元数据可以采用可读文本文件的格式,比如YAML格式,那么,当测试用例未执行通过时,可以直接使用文本编辑工具修改。
在图2所示的方法中,测试用例未执行通过的原因有多种。针对不同原因,对第一API的元数据进行修正的方式也不同。下面仅列举其中三种情况:
第一种情况
若确定测试用例未执行通过的原因为第一API的元数据缺失可选字段,则在第一API的元数据中增加可选字段。
第二种情况
若确定测试用例未执行通过的原因为第一API中未携带第一API的元数据中定义的必选字段,则将第一API的元数据中定义的必选字段修正为可选字段。
第三种情况
若确定测试用例未执行通过的原因为传输数据的数据类型与第一API的元数据中定义的数据类型不一致,则将测试用例未执行通过的信息记录入第一API对应的接口日志中,并根据录入了上述信息的接口日志修正第一API的元数据。比如,若第一API的元数据中定义的数据类型为数字类型,而传输数据的数据类型为字符串类型,那么测试用例则会执行不通过。此时可将测试用例未执行通过的信息记录在第一API对应的接口日志中,后续即可根据第一API对应的接口日志修正第一API的元数据。
需要说明的是,图2所述的API的测试方法是针对第一API的测试方法。通过执行图2所示的方法,可对第一API进行接口对接测试。假设***中包含A、B、C、D和E这五个API,若要对A进行接口对接测试,则将A作为第一API,然后依次将B、C、D和E作为第二API,即执行四次图2所示的方法,即可完成A与***中的其他API的对接测试。
通过执行图2所示的方法,可以对第一API进行接口对接测试。若S203中测试用例执行通过,则第一API与第二API间的接口对接测试成功;若S203中测试用例未执行通过,则可在修正第一API的元数据后更新第一API与第二API间的测试用例和模拟测试桩,然后调用更新后的模拟测试桩在生产环境中执行更新后的测试用例,直至更新后的测试用例执行通过。通过上述执行过程,可使得第一API与***中任一API间的接口对接测试成功。但是,在***开发过程中,由于API会不断修改,因此,通过执行图2所示的方法使得第一API与***中任一API间的接口对接测试成功后,若某个API进行了修改,还需对生产环境包含的多个API进行接口对接测试。若频繁在生产环境中进行接口对接测试,执行过程相对繁琐,且耗费大量的人力和物力。
为了避免频繁在生产环境中进行接口对接测试,本申请中,在确定第一API与第二API间的接口对接测试成功之后,还可录制第一API与第二API间的调测环境信息,该调测环境信息用于在开发环境中生成模拟生产环境的联调环境。生成模拟生产环境的联调环境后,即可在联调环境中对***中的多个接口进行接口对接测试,而不必再在生产环境中进行接口对接测试。
其中,调测环境信息包含第一API与第二API间的接口契约、第一API对应的接口日志和测试用例。若第一API处于客户端中,第二API处于服务端中,则预设的第一API与第二API间的接口契约包含第一API的接口信息、第二API的接口信息、第一API向第二API的请求信息、第二API向第一API的应答信息、以及第一API与第二API间的交互上下文信息;若第一API处于服务端中,第二API处于客户端中,则预设的第一API与第二API间的接口契约包含第一API的接口信息、第二API的接口信息、第一API向第二API的应答信息、第二API向第一API的请求信息、以及第一API与第二API间的交互上下文信息。
在录制调测环境信息中的接口契约时,可通过在第一API与第二API间的模拟测试桩采用抓包的方式获取请求码流和应答码流;根据请求码流和应答码流的消息头可解析得到第一API和第二API间的交互上下文信息。根据第一API的协议类型,调用相关协议的解析插件,获取该协议相关的字段、请求消息的数据结构以及应答消息的数据结构。以第一API的协议类型为HTTP为例,通过调用HTTP协议解析插件(例如Java的Servlet等)可获取HttpRequest对象,通过HttpRequest对象可以获取请求消息的数据结构(包括URL地址、请求的参数、method、以及HTTP Header等)和应答消息的数据结构(包括HTTP应答消息的响应码、应答Body、以及HTTP消息头等)。
通过对生产环境包含的多个API中的任意两个API执行图2所示的方法,并针对测试用例未执行通过的情况,通过修正第一API的元数据并重复执行测试用例直至执行通过,使得任意两个API间的测试用例在生产环境中均执行通过,即可录制得到任意两个不同的API间的多个调测环境信息。那么,在开发环境中导入多个API中任意两个不同的API生成的多个调测环境信息,即可生成模拟生产环境的联调环境。
联调环境中可包含生产环境中的多个API间的测试用例和模拟测试桩、多个API的接口契约、多个API的接口日志、API间的请求消息和应答消息等。
通过执行上述方案,可生成模拟生产环境的联调环境。由于联调环境是在对生产环境包含的多个API中的任意两个API的接口对接测试成功的前提下,通过录制任意两个API间的调测环境信息生成的,因此联调环境可真实地表征生产环境。在***开发过程中,在联调环境中对API进行接口对接测试的结果可靠性较高。
进一步地,在联调环境中,可调用预先编译的第一API的实际测试桩执行测试用例;若测试用例执行通过,则确定该实际测试桩无误;若测试用例未执行通过,则调用修改后的实际测试桩在所述联调环境中执行测试用例,直至测试用例执行通过。
需要说明的是,在联调环境中调用实际测试桩执行测试用例的过程,与在生产环境中调用模拟测试桩执行测试用例的过程略有不同:在生产环境中执行测试用例时,第一API的请求消息或应答消息是模拟测试桩发送的,第二API的应答消息或请求消息是该第二API实体发送的;而在联调环境中执行测试用例时,第一API的请求消息或应答消息是通过调用研发人员编写的程序代码实现的,第二API的应答消息或请求消息是联调环境模拟发送的。因此,调用实际测试桩在联调环境中执行测试用例时,若测试用例未执行通过,说明研发人员编写的程序代码中存在错误。若确定研发人员编写的程序代码中存在错误,那么,采用本申请提供的方法还可调用修改后的实际测试桩(修改后的程序代码)在联调环境中执行测试用例,直至测试用例执行通过。从而帮助研发人员改进程序代码,指导开发过程。
假设第一API为API提供者,第二API为API消费者,调用实际测试桩在模拟生产环境的联调环境中执行测试用例的过程可如图3所示。由图3可以看出,生产环境和模拟生产环境的联调环境是通过网络防火墙隔离的。在模拟生产环境的联调环境中调用实际测试桩执行测试用例的过程可以是:1、将该联调环境中API消费者的调测环境信息中的请求消息作为输入执行测试用例(即调用API消费者模拟桩执行测试用例,需要注意的是,这里的API消费者模拟桩与本申请中所述的模拟测试桩不同);2、API消费者模拟桩向API提供者发送请求消息;3、实际测试桩(图3中的API提供者)输出应答消息;4、将在生产环境中执行该测试用例得到的应答消息与在模拟生产环境的联调环境中执行该测试用例得到的应答消息作对比。若两个应答消息一致,说明研发人员编写的程序代码无误;若两个应答消息不一致,说明研发人员编写的程序代码有误。
对多个API的多个测试用例的接口对接测试结果进行整合,即可形成集成测试报告。集成测试报告中可包含测试用例的执行比例、执行成功率以及执行失败的测试用例的API接口日志等。集成测试报告可用于辅助研发人员和测试人员对测试不通过的测试用例进行问题定位。
在图2所示的API的测试方法中,根据第一API的元数据,生成第一API与第二API间的测试用例和模拟测试桩,然后通过调用模拟测试桩在生产环境中执行测试用例,在测试用例执行通过时确定第一API与第二API间的接口对接测试成功。由于图2所示方法是在生产环境中,通过调用模拟测试桩来执行测试用例实现的,因此采用该方法对API进行接口对接测试,测试的准确性更高。此外,若测试用例未执行通过,则可对第一API的元数据进行修正,根据修正后的第一API的元数据,更新第一API与第二API间的测试用例和模拟测试桩;然后调用更新后的模拟测试桩执行更新后的测试用例,直至更新后的测试用例执行通过。因此,采用本申请实施例提供的API的测试方法,可以对第一API的元数据进行修正,从而使得第一API的元数据能更真实地表征第一API的接口信息,提高接口对接测试的准确性。
基于上述API的测试方法及其各种可能的实现方式的描述可以获知:本申请提供的API的测试方法主要可以实现三个功能:一、在生产环境对API进行接口对接测试;二、录制生产环境中的API的调测环境信息;三、通过录制的调测环境信息生成联调环境,在联调环境中再次对API进行接口对接测试。因此,在具体实现时,可通过三个框架来实现上述三个功能,即API接口对接测试框架、API调测环境录制框架以及API环境重放框架。这三个测试框架可进行交互,从而实现图2所示的API的测试方法。
如图4所示,为本申请实施例提供的一种API的测试方法,该方法可视为图2所示方法的一个具体示例。如图4所示,该方法包含如下步骤:
1.API接口对接测试框架导入API的元数据。
图4所示方法中的API,可视为图2所示方法中的第一API。
2.API接口对接测试框架根据API的元数据,生成API测试用例。
3.API接口对接测试框架根据API的元数据,生成API模拟测试桩。
4.API接口对接测试框架根据API的测试用例和模拟测试桩生成API的测试任务。
其中,一个测试任务对应一个测试用例。本申请所提供的方法中可支持多个测试任务并发执行。
由于对API进行接口对接测试时需要执行对个测试任务。因此,本申请中还可通过接口对接测试任务管理模块对多个测试任务进行管理。接口对接测试任务管理模块对外提供Restful接口,且支持如下功能:
a、支持对测试任务的状态进行控制,接口对接测试任务状态包括,0:停止状态;1:暂停状态;2:启动状态,其中只有处于停止和暂停状态的任务可以启动。
b、支持定时执行、周期性执行、立即执行等多种测试任务的执行策略。以定时执行策略为例,定时执行策略技术上可以采用开源的定时任务框架(例如quartz),也可以直接基于JDK的定时任务Timer类,或者基于支持定时任务的线程池服务(Scheduled ExecutorService,SES)。
c、支持测试任务的执行轨迹查询,可以查看某个API接口的测试记录、执行结果等。
5.API接口对接测试框架调用API模拟测试桩,在生产环境中进行接口对接测试。
6.API调测环境录制框架录制每个API的调测环境信息。
其中,调测环境信息包含API的接口契约、接口日志和测试用例。
比如,一种用于查询余额的API的调测环境信息可如图3所示。
其中,API调测环境录制框架可对录制的每个API的调测环境信息进行分类和打包,从而支持将打包之后的API调测环境整体导出至API环境重放框架。
7.API环境重放框架导入API调测环境录制框架录制的调测环境信息。
8.API环境重放框架根据每个API的调测环境信息生成联调环境。
API环境重放框架通过在步骤7中导入的、生产***包含的每个API的调测环境信息,可生成联调环境。
9.API环境重放框架调用预先编译的该API的实际测试桩,在联调环境中执行API调测环境录制框架录制的测试用例。
10.API环境重放框架根据调用实际测试桩的测试结果,生成集成测试报告。
API环境重放框架将在联调环境中的测试结果与生产环境中的测试结果进行对比,可以生成集成测试报告。其中,集成测试报告中可包含测试用例的执行比例,执行成功率、执行失败的测试用例的API接口日志等。
本申请提供一种API的测试装置,该装置可用于执行图2所示的方法。如图5所示,该API的测试装置500(以下简称装置500)包括第一生成模块501、调用模块502和第一确定模块503。
第一生成模块501,用于根据第一API的元数据,生成第一API与第二API间的测试用例和模拟测试桩,第一API和第二API为生产环境包含的多个API中任意两个不同的API,第一API的元数据用于表征第一API的接口信息;
调用模块502,用于调用模拟测试桩在生产环境中执行测试用例;
第一确定模块503,用于在测试用例执行通过时,确定第一API与第二API间的接口对接测试成功。
可选地,装置500还包括:修正模块,用于在测试用例未执行通过时,修正第一API的元数据;第一生成模块501还用于根据修正模块修正后的第一API的元数据,更新第一API与第二API间的测试用例和模拟测试桩;调用模块502还用于调用更新后的模拟测试桩在生产环境中执行更新后的测试用例,直至更新后的测试用例执行通过。
可选地,修正模块在修正第一API的元数据时,具体用于:若确定测试用例未执行通过的原因为第一API的元数据缺失可选字段,则修正模块在第一API的元数据中增加可选字段;若确定测试用例未执行通过的原因为第一API中未携带第一API的元数据中定义的必选字段,则修正模块将第一API的元数据中定义的必选字段修正为可选字段;若确定测试用例未执行通过的原因为传输数据的数据类型与第一API的元数据中定义的数据类型不一致,则修正模块将测试用例未执行通过的信息记录入第一API对应的接口日志中,并根据录入了信息的接口日志修正第一API的元数据。
可选地,装置500还包括:录制模块,用于在第一确定模块503确定第一API与第二API间的接口对接测试成功之后,录制第一API与第二API间的调测环境信息,调测环境信息包含第一API与第二API间的接口契约、第一API对应的接口日志和测试用例,调测环境信息用于在开发环境中生成模拟生产环境的联调环境。
可选地,装置500还包括:第二生成模块,用于在开发环境中导入多个API中任意两个不同的API生成的多个调测环境信息,生成模拟生产环境的联调环境。
可选地,调用模块502还用于在第二生成模块生成模拟生产环境的联调环境之后,调用预先编译的第一API的实际测试桩在联调环境中执行测试用例;该装置还包括第二确定模块,第二确定模块用于在测试用例执行通过时,确定实际测试桩无误;调用模块还用于在测试用例未执行通过时,调用修改后的实际测试桩在联调环境中执行测试用例,直至测试用例执行通过。
可选地,若第一API处于客户端中,第二API处于服务端中,则预设的第一API与第二API间的接口契约包含第一API的接口信息、第二API的接口信息、第一API向第二API的请求信息、第二API向第一API的应答信息、以及第一API与第二API间的交互上下文信息;若第一API处于服务端中,第二API处于客户端中,则预设的第一API与第二API间的接口契约包含第一API的接口信息、第二API的接口信息、第一API向第二API的应答信息、第二API向第一API的请求信息、以及第一API与第二API间的交互上下文信息。
需要说明的是,本申请实施例中对模块的划分是示意性的,仅仅为一种逻辑功能划分,实际实现时可以有另外的划分方式。本申请实施例中的各功能模块可以集成在一个处理模块中,也可以是各个模块单独物理存在,也可以两个或两个以上模块集成在一个模块中。上述集成的模块既可以采用硬件的形式实现,也可以采用软件功能模块的形式实现。
需要说明的是,装置500可用于执行图2所示的API的测试方法。装置500中未详尽描述的实现方式可参见图2所示的API的测试方法中的相关描述。
在装置500中,第一生成模块501根据第一API的元数据,生成第一API与第二API间的测试用例和模拟测试桩,然后调用模块502通过调用模拟测试桩在生产环境中执行测试用例,第一确定模块503在测试用例执行通过时确定第一API与第二API间的接口对接测试成功。由于采用装置500进行接口对接测试时,调用模块502通过调用模拟测试桩在生产环境中来执行测试用例,因此对第一API进行接口对接测试,测试的准确性更高。此外,若测试用例未执行通过,则修正模块可对第一API的元数据进行修正,第一生成模块根据修正后的第一API的元数据,更新第一API与第二API间的测试用例和模拟测试桩;然后调用模块502调用更新后的模拟测试桩执行更新后的测试用例,直至更新后的测试用例执行通过。因此,采用本申请实施例提供的API的测试装置500,可以对第一API的元数据进行修正,从而使得第一API的元数据能更真实地表征第一API的接口信息,提高接口对接测试的准确性。
图6示出了上述实施例中所涉及的API的测试装置的另一种可能的结构示意图。
API的测试装置600包括收发器601、处理器602和存储器603。收发器601、处理器602和存储器603通过总线连接。该收发器601用于支持API的测试装置600与其他设备之间收发信息。处理器602通过调用存储器603中存储的程序代码和数据来执行图2所示的API的测试方法。
API的测试装置600可以是与API的测试装置500相同的装置,API的测试装置600可用于执行图2所示的API的测试方法。API的测试装置600中未详尽描述的实现方式可参见图2所示的API的测试方法和API的测试装置500中的相关描述。
综上,采用本申请提供的API的测试方法及装置,可以提高接口对接测试的准确性。
本领域内的技术人员应明白,本申请的实施例可提供为方法、***、或计算机程序产品。因此,本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且,本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。
本申请是参照根据本申请的方法、设备(***)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器,使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中,使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品,该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上,使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理,从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
显然,本领域的技术人员可以对本申请进行各种改动和变型而不脱离本申请的精神和范围。这样,倘若本申请的这些修改和变型属于本申请权利要求及其等同技术的范围之内,则本申请也意图包含这些改动和变型在内。

Claims (14)

1.一种应用程序编程接口API的测试方法,其特征在于,包括:
根据第一API的元数据,生成所述第一API与第二API间的测试用例和模拟测试桩,所述第一API和所述第二API为生产环境包含的多个API中任意两个不同的API,所述第一API的元数据用于表征所述第一API的接口信息;
调用所述模拟测试桩在所述生产环境中执行所述测试用例;
若所述测试用例执行通过,则确定所述第一API与所述第二API间的接口对接测试成功。
2.如权利要求1所述的方法,其特征在于,在调用所述模拟测试桩在所述生产环境中执行所述测试用例之后,还包括:
若所述测试用例未执行通过,则修正所述第一API的元数据;
根据修正后的第一API的元数据,更新所述第一API与第二API间的测试用例和模拟测试桩;
调用更新后的所述模拟测试桩在所述生产环境中执行更新后的所述测试用例,直至更新后的所述测试用例执行通过。
3.如权利要求2所述的方法,其特征在于,修正所述第一API的元数据,包括:
若确定所述测试用例未执行通过的原因为所述第一API的元数据缺失可选字段,则在所述第一API的元数据中增加所述可选字段;
若确定所述测试用例未执行通过的原因为所述第一API中未携带所述第一API的元数据中定义的必选字段,则将所述第一API的元数据中定义的所述必选字段修正为可选字段;
若确定所述测试用例未执行通过的原因为传输数据的数据类型与所述第一API的元数据中定义的数据类型不一致,则将所述测试用例未执行通过的信息记录入所述第一API对应的接口日志中,并根据录入了所述信息的接口日志修正所述第一API的元数据。
4.如权利要求1~3任一项所述的方法,其特征在于,在确定所述第一API与所述第二API间的接口对接测试成功之后,还包括:
录制所述第一API与所述第二API间的调测环境信息,所述调测环境信息包含所述第一API与所述第二API间的接口契约、所述第一API对应的接口日志和所述测试用例,所述调测环境信息用于在开发环境中生成模拟所述生产环境的联调环境。
5.如权利要求4所述的方法,其特征在于,还包括:
在所述开发环境中导入多个API中任意两个不同的API生成的多个调测环境信息,生成模拟所述生产环境的联调环境。
6.如权利要求5所述的方法,其特征在于,在生成模拟所述生产环境的联调环境之后,还包括:
调用预先编译的所述第一API的实际测试桩在所述联调环境中执行所述测试用例;
若所述测试用例执行通过,则确定所述实际测试桩无误;若所述测试用例未执行通过,则调用修改后的所述实际测试桩在所述联调环境中执行所述测试用例,直至所述测试用例执行通过。
7.如权利要求4~6任一项所述的方法,其特征在于,若所述第一API处于客户端中,所述第二API处于服务端中,则预设的所述第一API与所述第二API间的接口契约包含所述第一API的接口信息、所述第二API的接口信息、所述第一API向所述第二API的请求信息、所述第二API向所述第一API的应答信息、以及所述第一API与所述第二API间的交互上下文信息;
若所述第一API处于服务端中,所述第二API处于客户端中,则预设的所述第一API与所述第二API间的接口契约包含所述第一API的接口信息、所述第二API的接口信息、所述第一API向所述第二API的应答信息、所述第二API向所述第一API的请求信息、以及所述第一API与所述第二API间的交互上下文信息。
8.一种应用程序编程接口API的测试装置,其特征在于,包括:
第一生成模块,用于根据第一API的元数据,生成所述第一API与第二API间的测试用例和模拟测试桩,所述第一API和所述第二API为生产环境包含的多个API中任意两个不同的API,所述第一API的元数据用于表征所述第一API的接口信息;
调用模块,用于调用所述模拟测试桩在所述生产环境中执行所述测试用例;
第一确定模块,用于在所述测试用例执行通过时,确定所述第一API与所述第二API间的接口对接测试成功。
9.如权利要求8所述的装置,其特征在于,还包括:
修正模块,用于在所述测试用例未执行通过时,修正所述第一API的元数据;
所述第一生成模块,还用于根据所述修正模块修正后的第一API的元数据,更新所述第一API与第二API间的测试用例和模拟测试桩;
所述调用模块,还用于调用更新后的所述模拟测试桩在所述生产环境中执行更新后的所述测试用例,直至更新后的所述测试用例执行通过。
10.如权利要求9所述的装置,其特征在于,所述修正模块在修正所述第一API的元数据时,具体用于:
若确定所述测试用例未执行通过的原因为所述第一API的元数据缺失可选字段,则所述修正模块在所述第一API的元数据中增加所述可选字段;
若确定所述测试用例未执行通过的原因为所述第一API中未携带所述第一API的元数据中定义的必选字段,则所述修正模块将所述第一API的元数据中定义的所述必选字段修正为可选字段;
若确定所述测试用例未执行通过的原因为传输数据的数据类型与所述第一API的元数据中定义的数据类型不一致,则所述修正模块将所述测试用例未执行通过的信息记录入所述第一API对应的接口日志中,并根据录入了所述信息的接口日志修正所述第一API的元数据。
11.如权利要求8~10任一项所述的装置,其特征在于,还包括:
录制模块,用于在所述第一确定模块确定所述第一API与所述第二API间的接口对接测试成功之后,录制所述第一API与所述第二API间的调测环境信息,所述调测环境信息包含所述第一API与所述第二API间的接口契约、所述第一API对应的接口日志和所述测试用例,所述调测环境信息用于在开发环境中生成模拟所述生产环境的联调环境。
12.如权利要求11所述的装置,其特征在于,还包括:
第二生成模块,用于在所述开发环境中导入多个API中任意两个不同的API生成的多个调测环境信息,生成模拟所述生产环境的联调环境。
13.如权利要求12所述的装置,其特征在于,所述调用模块,还用于在所述第二生成模块生成模拟所述生产环境的联调环境之后,调用预先编译的所述第一API的实际测试桩在所述联调环境中执行所述测试用例;
所述装置还包括:第二确定模块,用于在所述测试用例执行通过时,确定所述实际测试桩无误;
所述调用模块,还用于在所述测试用例未执行通过时,调用修改后的所述实际测试桩在所述联调环境中执行所述测试用例,直至所述测试用例执行通过。
14.如权利要求11~13任一项所述的装置,其特征在于,若所述第一API处于客户端中,所述第二API处于服务端中,则预设的所述第一API与所述第二API间的接口契约包含所述第一API的接口信息、所述第二API的接口信息、所述第一API向所述第二API的请求信息、所述第二API向所述第一API的应答信息、以及所述第一API与所述第二API间的交互上下文信息;
若所述第一API处于服务端中,所述第二API处于客户端中,则预设的所述第一API与所述第二API间的接口契约包含所述第一API的接口信息、所述第二API的接口信息、所述第一API向所述第二API的应答信息、所述第二API向所述第一API的请求信息、以及所述第一API与所述第二API间的交互上下文信息。
CN201710198569.7A 2017-03-29 2017-03-29 一种应用程序编程接口的测试方法及装置 Pending CN108664385A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201710198569.7A CN108664385A (zh) 2017-03-29 2017-03-29 一种应用程序编程接口的测试方法及装置

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201710198569.7A CN108664385A (zh) 2017-03-29 2017-03-29 一种应用程序编程接口的测试方法及装置

Publications (1)

Publication Number Publication Date
CN108664385A true CN108664385A (zh) 2018-10-16

Family

ID=63786793

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201710198569.7A Pending CN108664385A (zh) 2017-03-29 2017-03-29 一种应用程序编程接口的测试方法及装置

Country Status (1)

Country Link
CN (1) CN108664385A (zh)

Cited By (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109408398A (zh) * 2018-11-13 2019-03-01 郑州云海信息技术有限公司 一种接口自动化测试装置及方法
CN109688202A (zh) * 2018-12-04 2019-04-26 北京腾云天下科技有限公司 一种接口数据的处理方法、装置、计算设备及存储介质
CN109726116A (zh) * 2018-11-08 2019-05-07 深圳壹账通智能科技有限公司 联调测试方法、装置、计算机装置及存储介质
CN110162455A (zh) * 2019-04-09 2019-08-23 口碑(上海)信息技术有限公司 软件的联调方法及装置、存储介质、电子装置
CN110162979A (zh) * 2019-05-27 2019-08-23 北京百度网讯科技有限公司 一种Web API的安全测试方法、装置、电子设备及存储介质
CN110618922A (zh) * 2019-08-15 2019-12-27 平安普惠企业管理有限公司 性能测试方法及相关设备
CN111444094A (zh) * 2020-03-25 2020-07-24 中国邮政储蓄银行股份有限公司 一种测试数据的生成方法和***
CN112256710A (zh) * 2020-09-30 2021-01-22 中孚安全技术有限公司 一种基于元数据的数据统计分析图表生成***、方法及设备

Cited By (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109726116A (zh) * 2018-11-08 2019-05-07 深圳壹账通智能科技有限公司 联调测试方法、装置、计算机装置及存储介质
CN109408398A (zh) * 2018-11-13 2019-03-01 郑州云海信息技术有限公司 一种接口自动化测试装置及方法
CN109688202A (zh) * 2018-12-04 2019-04-26 北京腾云天下科技有限公司 一种接口数据的处理方法、装置、计算设备及存储介质
CN109688202B (zh) * 2018-12-04 2021-07-02 北京腾云天下科技有限公司 一种接口数据的处理方法、装置、计算设备及存储介质
CN110162455A (zh) * 2019-04-09 2019-08-23 口碑(上海)信息技术有限公司 软件的联调方法及装置、存储介质、电子装置
CN110162979A (zh) * 2019-05-27 2019-08-23 北京百度网讯科技有限公司 一种Web API的安全测试方法、装置、电子设备及存储介质
CN110618922A (zh) * 2019-08-15 2019-12-27 平安普惠企业管理有限公司 性能测试方法及相关设备
CN110618922B (zh) * 2019-08-15 2022-10-04 平安普惠企业管理有限公司 性能测试方法及相关设备
CN111444094A (zh) * 2020-03-25 2020-07-24 中国邮政储蓄银行股份有限公司 一种测试数据的生成方法和***
CN111444094B (zh) * 2020-03-25 2023-08-04 中国邮政储蓄银行股份有限公司 一种测试数据的生成方法和***
CN112256710A (zh) * 2020-09-30 2021-01-22 中孚安全技术有限公司 一种基于元数据的数据统计分析图表生成***、方法及设备
CN112256710B (zh) * 2020-09-30 2022-12-06 中孚安全技术有限公司 一种基于元数据的数据统计分析图表生成***、方法及设备

Similar Documents

Publication Publication Date Title
CN108664385A (zh) 一种应用程序编程接口的测试方法及装置
US8504989B2 (en) Service definition document for providing blended services utilizing multiple service endpoints
Baker et al. Model-driven engineering in a large industrial context—Motorola case study
US7437275B2 (en) System for and method of multi-location test execution
WO2019072110A1 (zh) 应用程序的生成方法、装置、***、设备和介质
US20200133829A1 (en) Methods and systems for performance testing
CN109726016A (zh) 一种用于分布式***的链路追踪方法、装置和***
US20130339931A1 (en) Application trace replay and simulation systems and methods
CN107729228A (zh) 接口测试方法、装置、存储介质和处理器
US8918762B2 (en) Generating test plans and test cases from service-oriented architecture and process models
US11449414B2 (en) Mapping test parameter data elements during heterogeneous component-based testing in a portable automation framework in both API mode and UI mode
CN109460223A (zh) 一种api网关管理***及其方法
US20170220457A1 (en) Constructing test-centric model of application
US20210117313A1 (en) Language agnostic automation scripting tool
CN105871911A (zh) 一种服务调用引擎、方法及***
CN110209584A (zh) 一种测试数据自动生成方法和相关装置
US12013777B2 (en) Controlling heterogeneous component-based testing in a portable automation framework with test scripts in both API mode and UI mode
US11269712B1 (en) Customized categorial error handling framework for heterogeneous component-based testing in a portable automation framework
KR20150133902A (ko) 소프트웨어 제품 라인에 기반한 서비스 개발 시스템 및 방법
US11734134B2 (en) Automatically locating resources using alternative locator expressions during heterogeneous component-based testing in a portable automation framework
US11310680B2 (en) Reusing provisioned resources during heterogeneous component-based testing in a portable automation framework
CN110275731B (zh) 信息处理方法、装置、存储介质和电子设备
Anderson Performance modelling of reactive web applications using trace data from automated testing
Vu et al. Model-driven integration testing of hypermedia systems
Manova et al. TASSA Methodology: End-to-End Testing of Web Service Compositions

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
WD01 Invention patent application deemed withdrawn after publication
WD01 Invention patent application deemed withdrawn after publication

Application publication date: 20181016