Test method of application program interface, device thereof and electronic equipment

By receiving configuration files and test data, decrypting them using the target key information, and obtaining the test conditions, the problem of low efficiency in application interface testing is solved, and efficient and comprehensive interface testing is achieved.

CN114546867BActive Publication Date: 2026-07-24INDUSTRIAL AND COMMERCIAL BANK OF CHINA
View PDF 2 Cites 0 Cited by

Patent Information

Authority / Receiving Office
CN · China
Patent Type
Patents(China)
Current Assignee / Owner
INDUSTRIAL AND COMMERCIAL BANK OF CHINA
Filing Date
2022-02-24
Publication Date
2026-07-24

AI Technical Summary

Technical Problem

Existing technologies for testing application programming interfaces (APIs) are inefficient, costly, and risky due to incomplete coverage. Furthermore, API testing tools may fail to provide access to APIs.

Method used

A testing method for application programming interfaces (APIs) is provided. This method receives a configuration file and test data, decrypts the data using the target key information to obtain test conditions, and performs state testing on the target API according to the test conditions. This includes generating test cases and comparing the results to determine the API state.

Benefits of technology

It enables comprehensive and efficient testing of application interfaces, reducing manual processing and improving testing efficiency.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN114546867B_ABST
    Figure CN114546867B_ABST
Patent Text Reader

Abstract

The application discloses a kind of application program interface test method, its device and electronic equipment. Among them, the method includes: receiving configuration file and the test data corresponding to target request party, wherein the test data is used to simulate the request data of target request party after encryption processing is sent to target application program interface, configuration file includes the multiple application program numbers corresponding to multiple request parties one by one, and the multiple key information corresponding to multiple application program numbers one by one;From the target key information corresponding to the application program number of target request party in configuration file;By target key information, the target data is obtained by decrypting test data;Obtain the target test condition corresponding to target application program interface;According to target test condition, the state of target application program interface is tested using target data. The application solves the problem of low test efficiency of application program interface in the prior art.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This invention relates to the field of functional testing technology, and more specifically, to a testing method, apparatus, and electronic device for an application programming interface (API). Background Technology

[0002] API (Application Programming Interface) typically refers to predefined interfaces (such as functions or HTTP interfaces) or conventions for connecting different components of a software system.

[0003] API services typically require integration with partners, necessitating detailed testing by the caller. This involves reliance on the caller's environment and familiarity with the functionality, and there's always the possibility of incomplete coverage of API branches by the caller. Therefore, testing costs are high, and there's a risk of incomplete coverage and quality issues. Using API testing tools like POSMAN can lead to access failures due to the lack of a signature generation mechanism.

[0004] There is currently no effective solution to the above problems. Summary of the Invention

[0005] The main objective of this invention is to provide a testing method, apparatus, and electronic device for application programming interfaces (APIs) to solve the problem of low testing efficiency for APIs in the prior art.

[0006] To achieve the above objectives, according to one aspect of the present invention, a method for testing an application programming interface (API) is provided, comprising: receiving a configuration file and test data corresponding to a target requester, wherein the test data is used to simulate encrypted request data sent by the target requester to the target API, the configuration file including multiple application IDs corresponding one-to-one with multiple requesters, and multiple key information corresponding one-to-one with multiple application IDs; reading target key information corresponding to the application ID of the target requester from the configuration file; decrypting the test data using the target key information to obtain target data; obtaining target test conditions corresponding to the target API; and testing the state of the target API using the target data according to the target test conditions.

[0007] Optionally, the method further includes: generating a configuration file based on the interface testing environment of different requesters, wherein the configuration file includes: multiple application IDs, multiple key information corresponding to the multiple application IDs, and multiple server addresses corresponding to the multiple requesters.

[0008] Optionally, obtaining the target test conditions corresponding to the target application interface includes: receiving a lightweight markup language document corresponding to the target requester; determining the target application interface based on the lightweight markup language document; and obtaining the target test conditions corresponding to the target application interface by parsing the lightweight markup language document. The target test conditions include: the data type of the target field, the length of the target field, and whether the target field allows null values.

[0009] Optionally, by parsing the lightweight markup language document, the target test conditions corresponding to the target application interface are obtained, including: by parsing the lightweight markup language document, generating a visual communication area corresponding to the target application interface in the interactive interface; responding to the input command of the target object in the visual communication area, and obtaining the target test conditions corresponding to the input command.

[0010] Optionally, according to the target test conditions, the state of the target application interface is tested using target data, including: generating at least one test case based on the target test conditions, wherein the at least one test case includes: preset input parameter data for inputting the target application interface, and expected test results corresponding to the preset input parameter data and expected test results, wherein the preset input parameter data at least satisfies: required fields are empty, non-required fields are empty, the data type is different from the target field, and the length exceeds the target field; comparing the target data with at least one test case to obtain a comparison result; and determining whether the state of the target application interface is abnormal based on the comparison result and the expected test result.

[0011] Optionally, the method further includes: obtaining interface return information from the target application interface for the target data, wherein the interface return information includes the target payment address; converting the target payment address into a payment QR code; and sending the payment QR code to the target requester through the target application interface.

[0012] Optionally, the method further includes: determining the length of a custom field corresponding to a lightweight markup language document; comparing whether the lengths of each field in the interface returned information exceed the length of the custom field, and generating an error message if the comparison result indicates yes; and sending the error message to the target requester through the target application interface.

[0013] According to another aspect of the present invention, a testing apparatus for an application programming interface (API) is also provided, comprising: a receiving module for receiving a configuration file and test data corresponding to a target requester, wherein the test data is used to simulate encrypted request data sent by the target requester to the target API, and the configuration file includes multiple application IDs corresponding one-to-one with multiple requesters, and multiple key information corresponding one-to-one with multiple application IDs; a reading module for reading target key information corresponding to the application ID of the target requester from the configuration file; a decryption module for decrypting the test data using the target key information to obtain target data; an acquisition module for acquiring target test conditions corresponding to the target API; and a testing module for testing the state of the target API using the target data according to the target test conditions.

[0014] According to another aspect of the present invention, an electronic device is also provided, comprising: a processor; a memory for storing processor-executable instructions; wherein the processor is configured to execute instructions to implement the test method as described above.

[0015] According to another aspect of the present invention, a computer-readable storage medium is also provided, which, when the instructions in the computer-readable storage medium are executed by a processor of an electronic device, enables the electronic device to perform the test method as described above.

[0016] The present invention provides a method for testing application programming interfaces (APIs). This method first receives a configuration file and test data corresponding to a target requester. The configuration file includes multiple application IDs corresponding to multiple requesters and multiple key information corresponding to multiple application IDs. Then, it reads the target key information corresponding to the application ID of the target requester from the configuration file, and decrypts the test data using the target key information to obtain the target data. Next, it obtains the target test conditions corresponding to the target API, and tests the status of the target API using the target data according to the target test conditions. This allows direct querying of the application ID (APPID) of the target API provider with configured key information, reducing manual processing and solving the problem of low testing efficiency for APIs in the prior art, thus achieving comprehensive and efficient testing of APIs. Attached Figure Description

[0017] The accompanying drawings, which form part of this specification, are used to provide a further understanding of the invention. The illustrative embodiments of the invention and their descriptions are used to explain the invention and do not constitute an undue limitation of the invention. In the drawings:

[0018] Figure 1This is a hardware structure block diagram of a computer terminal for a testing method of an application programming interface, according to an exemplary embodiment.

[0019] Figure 2 This is a flowchart illustrating a testing method for an application programming interface according to an exemplary embodiment;

[0020] Figure 3 This is a flowchart of the testing method for the application programming interface according to Embodiment 2 of the present invention;

[0021] Figure 4 This is a block diagram of a testing device for an application programming interface according to Embodiment 2 of the present invention;

[0022] Figure 5 This is a block diagram of a simulator according to Embodiment 2 of the present invention;

[0023] Figure 6 This is a device block diagram of a terminal according to an embodiment of the present invention. Detailed Implementation

[0024] It should be noted that, unless otherwise specified, the embodiments and features described in the present invention can be combined with each other. The present invention will now be described in detail with reference to the accompanying drawings and embodiments.

[0025] To enable those skilled in the art to better understand the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present invention.

[0026] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate for the embodiments of the invention described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0027] Example 1

[0028] According to an embodiment of the present invention, a testing method for an application programming interface is provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0029] The method embodiment provided in Embodiment 1 of this application can be executed in a mobile terminal, computer terminal or similar computing device. Figure 1 A hardware block diagram of a computer terminal (or mobile device) for implementing a testing method for an application programming interface is shown. Figure 1 As shown, the computer terminal 10 (or mobile device) may include one or more processors 102 (shown as 102a, 102b, ..., 102n in the figure) 102 (processor 102 may include, but is not limited to, a microprocessor MCU or a programmable logic device FPGA, etc.), a memory 104 for storing data, and a transmission device for communication functions. In addition, it may also include: a display, an input / output interface (I / O interface), a universal serial bus (USB) port (which may be included as one of the ports of a BUS bus), a network interface, a power supply, and / or a camera. Those skilled in the art will understand that... Figure 1 The structure shown is for illustrative purposes only and does not limit the structure of the aforementioned electronic device. For example, computer terminal 10 may also include... Figure 1 The more or fewer components shown, or having the same Figure 1 The different configurations shown.

[0030] It should be noted that the aforementioned one or more processors 102 and / or other data processing circuits are generally referred to herein as "data processing circuits". These data processing circuits may be embodied, in whole or in part, in software, hardware, firmware, or any other combination thereof. Furthermore, the data processing circuits may be a single, independent processing module, or may be integrated, in whole or in part, into any other element within the computer terminal 10 (or mobile device). As involved in the embodiments of this application, the data processing circuits serve as a processor control mechanism (e.g., selection of a variable resistor termination path connected to an interface).

[0031] The memory 104 can be used to store software programs and modules of application software, such as the program instructions / data storage device corresponding to the testing method of the application programming interface in this embodiment of the invention. The processor 102 executes various functional applications and data processing by running the software programs and modules stored in the memory 104, that is, implementing the table processing method of the application program described above. The memory 104 may include high-speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 104 may further include memory remotely located relative to the processor 102, and these remote memories can be connected to the computer terminal 10 via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0032] The transmission device is used to receive or send data via a network. Specific examples of the network described above may include a wireless network provided by the communication provider of computer terminal 10. In one example, the transmission device includes a Network Interface Controller (NIC), which can connect to other network devices via a base station to communicate with the Internet. In another example, the transmission device may be a Radio Frequency (RF) module, used for wireless communication with the Internet.

[0033] The display can be, for example, a touchscreen liquid crystal display (LCD) that allows the user to interact with the user interface of the computer terminal 10 (or mobile device).

[0034] Under the aforementioned operating environment, this application provides the following: Figure 2 The test method for the application interface is shown. Figure 2 This is a flowchart of a testing method for an application programming interface according to Embodiment 1 of the present invention, as shown below. Figure 2 As shown, the method includes the following steps:

[0035] Step S202: Receive the configuration file and test data corresponding to the target requester. The test data is used to simulate the encrypted request data sent by the target requester to the target application interface. The configuration file includes multiple application numbers corresponding to multiple requesters and multiple key information corresponding to multiple application numbers.

[0036] Step S204: Read the target key information corresponding to the application ID of the target requester from the configuration file;

[0037] Step S206: Decrypt the test data using the target key information to obtain the target data;

[0038] Step S208: Obtain the target test conditions corresponding to the target application interface;

[0039] Step S210: According to the target test conditions, the target application interface is tested using target data.

[0040] Using the testing method described in this embodiment, the application ID (APPID) of the target application interface (API) provider with configured key information can be directly queried, reducing manual processing and solving the problem of low testing efficiency of application interfaces in the prior art, thus realizing comprehensive and efficient testing of APIs.

[0041] In step S202 above, the requesting party is an application that calls different application programming interfaces (APIs). It can achieve the required functions by calling the interfaces provided by the API provider. Different requesting parties can call different interfaces, and multiple interfaces can call each other. Multiple applications calling multiple interfaces are marked to obtain multiple application IDs (APPIDs). Since the request data from the requesting party calling the interfaces usually needs to be encrypted, the above test data is used to simulate the encrypted request data sent by the target requesting party to the target application interface. The application IDs and multiple key information corresponding one-to-one with the multiple application IDs are stored in a configuration file.

[0042] For example, after a user initiates a test request, the test data is processed using algorithm A to obtain test data encrypted with algorithm A.

[0043] As an optional implementation, a configuration file is generated based on the interface testing environment of different requesters. In addition to multiple application IDs and multiple key information corresponding to the multiple application IDs, the configuration file also includes multiple server addresses corresponding to multiple requesters. The server calls the corresponding application interface (API) through the address corresponding to the target requester.

[0044] In step S206 above, the test data is decrypted using the target key information to obtain the target data.

[0045] For example, test data encrypted with algorithm A and target key information are sent to the target application interface (API). The API then decrypts the encrypted test data using the target key information to obtain target data for testing the API's state. Algorithms such as Algorithm A include Base64 and DES.

[0046] In step S208 above, the target test conditions corresponding to the target application interface are obtained. These target test conditions are used to determine whether the target application interface is abnormal after the request data sent by the requester enters the target application interface. Abnormal interface states may include: required fields being empty, optional fields being empty, data types not matching, exceeding the preset field length, etc.

[0047] As an optional embodiment, obtaining the target test conditions corresponding to the target application interface includes: receiving a lightweight markup language document corresponding to the target requester; determining the target application interface based on the lightweight markup language document; and obtaining the target test conditions corresponding to the target application interface by parsing the lightweight markup language document, wherein the target test conditions include: the data type of the target field, the length of the target field, and whether the target field allows null values.

[0048] In the above embodiments, the lightweight markup language document can be an MD (Markdown) document. Markdown is a lightweight markup language that allows documents to be written in an easy-to-read and easy-to-write plain text format. It can be parsed and converted into richly formatted HTML pages with a visual communication area. Markdown documents have the .md extension.

[0049] In the above embodiments, parsing a lightweight markup language document to obtain target test conditions corresponding to the target application interface can include: generating a visual communication area corresponding to the target application interface in the interactive interface by parsing the lightweight markup language document; responding to the input command of the target object in the visual communication area and obtaining the target test conditions corresponding to the input command. By modifying the input content of the visual communication area, manual testing of the target application interface status can be achieved.

[0050] For example, import the target application interface's corresponding MD document (defining the interface communication area, the attributes, length, and whether nullable fields are allowed). Based on the MD document, a visual interface communication area can be generated, allowing users to fill in information in the visualized communication area on the IE front end. Furthermore, the application ID (APPID), key information (public and private keys), and the communication area information generated from the MD document can be concatenated into a message according to the document's required format. Based on the server address, this message is sent to the API interface to complete a call transaction.

[0051] In step S210 above, the state of the target application interface is tested using target data according to the target test conditions. This involves sending request data that meets the target test conditions to the interface provider via a simulated request, and receiving the data returned by the server to test whether the interface is abnormal.

[0052] As an optional embodiment, the state of the target application interface is tested using target data according to the target test conditions, including: generating at least one test case based on the target test conditions, wherein the at least one test case includes: preset input parameter data for inputting the target application interface, and expected test results corresponding to the preset input parameter data and expected test results, wherein the preset input parameter data at least satisfies the following conditions: required fields are empty, non-required fields are empty, the data type is different from the target field, and the length exceeds the target field; comparing the target data with at least one test case to obtain a comparison result; and determining whether the state of the target application interface is abnormal based on the comparison result and the expected test result.

[0053] In the above embodiments, automated testing of the application interface status can be achieved by generating multiple test cases. Specifically, the target test conditions can be obtained through the visual interface communication area generated by the MD document. Based on the input parameter attributes of the MD document, at least one test case can be generated, and multiple test cases can be called in a loop to automatically test the status of the target application interface. For example, if the MD document defines field A as 5 bytes long, numeric, and not allowed to be empty, the test cases used to test the target application interface include inputting 6 bytes, letters, empty data, etc., and the expected test result is an interface anomaly.

[0054] As an optional embodiment, the above testing method further includes: obtaining the interface return information of the target application interface for the target data, wherein the interface return information includes the target payment address; converting the target payment address into a payment QR code; and sending the payment QR code to the target requester through the target application interface. By converting the payment URL returned by the interface into a QR code, further QR code scanning test operations are supported.

[0055] This embodiment can also perform data length checks on the return information of the target application interface. Specifically, it determines the length of the custom field corresponding to the lightweight markup language document; compares whether the length of each field in the interface return information exceeds the length of the custom field; if the comparison result indicates yes, it generates an error message; and sends the error message to the target requester through the target application interface.

[0056] like Figure 3As shown, the above-mentioned testing method using this embodiment can have the following processing flow: First, import the MD document and parse out the corresponding interface communication area; according to the configuration application parameter information, read the key and APPID configuration information, and select an APPID; according to the interface name in the MD document, locate the interface to be tested, click automatic testing, and then perform routine testing on each field; modify the input content of the communication area and perform manual testing; verify the test results; convert the payment URL returned by the interface into a QR code to support further QR code scanning testing; and check the data length of the information data returned by the interface.

[0057] Example 2

[0058] According to embodiments of the present invention, an apparatus for implementing the above-described testing method for application programming interfaces is also provided. Figure 4 This is a structural block diagram of a testing device for an application programming interface according to Embodiment 2 of the present invention, as shown below. Figure 4 As shown, the device includes: a receiving module 302, a reading module 304, a decryption module 306, an acquisition module 308, and a testing module 310. The device will be described in detail below.

[0059] The receiving module 302 is used to receive the configuration file and test data corresponding to the target requester. The test data is used to simulate the encrypted request data sent by the target requester to the target application interface. The configuration file includes multiple application numbers corresponding to multiple requesters and multiple key information corresponding to multiple application numbers.

[0060] The reading module 304 is used to read the target key information corresponding to the application ID of the target requester from the configuration file;

[0061] The decryption module 306 is used to decrypt the test data using the target key information to obtain the target data;

[0062] Module 308 is used to obtain the target test conditions corresponding to the target application interface;

[0063] Test module 310 is used to test the state of the target application interface using target data according to the target test conditions.

[0064] It should be noted that the receiving module 302, reading module 304, decryption module 306, acquisition module 308, and testing module 310 mentioned above correspond to steps S202 to S210 in Embodiment 1. Multiple modules implement the same instances and application scenarios as their corresponding steps, but are not limited to the content disclosed in Embodiment 1. It should also be noted that the above modules, as part of the device, can run on the computer terminal 10 provided in Embodiment 1.

[0065] For example, the above-mentioned testing apparatus is as follows: Figure 5 The simulator shown supports various components, which are divided into two categories. The first category includes encryption / decryption components and MD document processing components. The second category includes components for converting URLs to QR codes, used for testing payment-related API services, comparing interface return information with the database, and length checks. The first category of components is relatively fixed due to the characteristics of API testing. The second category of components, however, can be continuously added and configured based on the functional characteristics of the API being tested.

[0066] The functions of the first type of component mentioned above are as follows:

[0067] Encryption Component: Data communication is encrypted before the partner calls the API interface. The simulator encrypts data according to publicly available industry methods. The encryption component is configured based on API testing environments for different applications to obtain the interface provider's identity and key information. The configuration file includes: the application's server address, user, password, and the public and private keys storing the application ID (APPID). When the test user selects application information from the page and then selects the APPID from the dropdown, the background automatically obtains the corresponding public and private keys based on the configuration file information.

[0068] MD document processing component: Imports the MD document corresponding to the test interface from the simulator front end (defining the interface communication area, data type, field length, and whether fields can be empty). Based on the MD document, a visual communication area can be generated, and users can fill in the information in the visualized communication area in the IE front end.

[0069] Manual testing: Modify the input parameters of the visual communication area and perform manual testing;

[0070] Automated testing: Stores common test cases such as empty required fields, empty optional fields, data type mismatch, and input parameters exceeding the document definition length. Based on the attributes of the input parameters in the MD document, it iteratively calls the data in the test case library to automatically test the interface.

[0071] The functions of the second type of component mentioned above are as follows:

[0072] QR code payment: Converts the payment URL of the valid returned information from the interface into a QR code, thereby supporting further scanning test operations.

[0073] Return information check: Perform length validation on the valid return information of the interface. For example, it can be compared with the length defined in the MD document field. If the length is exceeded, an error will be reported.

[0074] Example 4

[0075] Embodiments of the present invention can provide an electronic device, which can be a terminal or a server. In this embodiment, the electronic device, as a terminal, can be any computer terminal device in a group of computer terminals. Optionally, in this embodiment, the terminal can also be a mobile terminal or other terminal device.

[0076] Optionally, in this embodiment, the terminal may be located in at least one of a plurality of network devices in a computer network.

[0077] Optionally, Figure 6 This is a structural block diagram of a terminal according to an exemplary embodiment. For example... Figure 6 As shown, the terminal may include: one or more (only one is shown in the figure) processors 41 and a memory 42 for storing processor-executable instructions; wherein the processor is configured to execute instructions to implement the above-mentioned test method for the application programming interface.

[0078] The memory can be used to store software programs and modules, such as the program instructions / modules corresponding to the table processing method and apparatus in this embodiment of the invention. The processor executes various functional applications and data processing by running the software programs and modules stored in the memory, thereby implementing the aforementioned table processing method. The memory may include high-speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory may further include memory remotely located relative to the processor, and these remote memories can be connected to a computer terminal via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0079] The processor can invoke information and applications stored in memory via a transmission device to perform the following steps: receiving a configuration file and test data corresponding to the target requester, wherein the test data is used to simulate encrypted request data sent by the target requester to the target application interface; the configuration file includes multiple application IDs corresponding one-to-one with multiple requesters, and multiple key information corresponding one-to-one with multiple application IDs; reading the target key information corresponding to the application ID of the target requester from the configuration file; decrypting the test data using the target key information to obtain the target data; obtaining the target test conditions corresponding to the target application interface; and testing the state of the target application interface using the target data according to the target test conditions.

[0080] Optionally, the processor may also execute program code that performs the following steps: generating a configuration file based on the interface testing environment of different requesters, wherein the configuration file includes: multiple application IDs, multiple key information corresponding to the multiple application IDs, and multiple server addresses corresponding to the multiple requesters.

[0081] Optionally, the processor may also execute program code that performs the following steps: obtaining target test conditions corresponding to the target application interface, including: receiving a lightweight markup language document corresponding to the target requester; determining the target application interface based on the lightweight markup language document; and obtaining the target test conditions corresponding to the target application interface by parsing the lightweight markup language document, wherein the target test conditions include: the data type of the target field, the length of the target field, and whether the target field is allowed to be null.

[0082] Optionally, the processor may also execute program code that performs the following steps: parsing a lightweight markup language document to obtain target test conditions corresponding to the target application interface, including: parsing the lightweight markup language document to generate a visual communication area corresponding to the target application interface in the interactive interface; responding to the input command of the target object in the visual communication area and obtaining the target test conditions corresponding to the input command.

[0083] Optionally, the processor may also execute program code with the following steps: testing the state of the target application interface using target data according to the target test conditions, including: generating at least one test case based on the target test conditions, wherein the at least one test case includes: preset input parameter data for inputting the target application interface, and the expected test result corresponding to the preset input parameter data and the expected test result, wherein the preset input parameter data at least satisfies: required fields are empty, non-required fields are empty, the data type is different from the target field, and the length exceeds the target field; comparing the target data with at least one test case to obtain a comparison result; and determining whether the state of the target application interface is abnormal based on the comparison result and the expected test result.

[0084] Optionally, the processor may also execute program code that performs the following steps: obtaining interface return information from the target application interface for the target data, wherein the interface return information includes the target payment address; converting the target payment address into a payment QR code; and sending the payment QR code to the target requester through the target application interface.

[0085] Optionally, the processor may also execute program code that performs the following steps: determines the length of a custom field corresponding to a lightweight markup language document; compares the lengths of each field in the interface return information to see if they exceed the length of the custom field, and generates an error message if the comparison result indicates yes; and sends the error message to the target requester through the target application interface.

[0086] Those skilled in the art will understand that Figure 6 The structure shown is for illustrative purposes only. For example, the terminal mentioned above can also be a smartphone (such as an Android phone, an iOS phone, etc.), a tablet computer, a mobile internet device (MID), a PAD, and other terminal devices. Figure 6 This does not limit the structure of the aforementioned electronic device. For example, it may also include devices that are more... Figure 6 The more or fewer components shown (such as network interfaces, display devices, etc.), or having the same Figure 6 The different configurations shown.

[0087] Those skilled in the art will understand that all or part of the steps in the various methods of the above embodiments can be implemented by a program instructing the hardware related to the terminal device. The program can be stored in a computer-readable storage medium, which may include: flash drive, read-only memory (ROM), random access memory (RAM), disk or optical disk, etc.

[0088] Example 5

[0089] In an exemplary embodiment, a computer-readable storage medium including instructions is also provided, which, when executed by a processor of a terminal, enable the terminal to perform the testing method of the application programming interface described above. Optionally, the computer-readable storage medium may be a non-transitory computer-readable storage medium, such as a ROM, random access memory (RAM), CD-ROM, magnetic tape, floppy disk, and optical data storage device.

[0090] Optionally, in this embodiment, the computer-readable storage medium described above can be used to store the program code executed by the test method of the application programming interface provided in Embodiment 1.

[0091] Optionally, in this embodiment, the computer-readable storage medium may be located in any computer terminal in a group of computer terminals in a computer network, or in any mobile terminal in a group of mobile terminals.

[0092] Optionally, in this embodiment, the computer-readable storage medium is configured to store program code for performing the following steps: receiving a configuration file and test data corresponding to a target requester, wherein the test data is used to simulate encrypted request data sent by the target requester to the target application interface, and the configuration file includes multiple application IDs corresponding one-to-one with multiple requesters, and multiple key information corresponding one-to-one with multiple application IDs; reading the target key information corresponding to the application ID of the target requester from the configuration file; decrypting the test data using the target key information to obtain target data; obtaining target test conditions corresponding to the target application interface; and testing the state of the target application interface using the target data according to the target test conditions.

[0093] Optionally, in this embodiment, the computer-readable storage medium is configured to store program code for performing the following steps: generating a configuration file based on the interface testing environment of different requesters, wherein the configuration file includes: multiple application IDs, multiple key information corresponding to the multiple application IDs, and multiple server addresses corresponding to the multiple requesters.

[0094] Optionally, in this embodiment, the computer-readable storage medium is configured to store program code for performing the following steps: obtaining target test conditions corresponding to the target application interface, including: receiving a lightweight markup language document corresponding to the target requester; determining the target application interface based on the lightweight markup language document; obtaining the target test conditions corresponding to the target application interface by parsing the lightweight markup language document, wherein the target test conditions include: the data type of the target field, the length of the target field, and whether the target field allows null values.

[0095] Optionally, in this embodiment, the computer-readable storage medium is configured to store program code for performing the following steps: obtaining target test conditions corresponding to the target application interface by parsing a lightweight markup language document, including: generating a visual communication area corresponding to the target application interface in the interactive interface by parsing the lightweight markup language document; and obtaining the target test conditions corresponding to the input command in response to the input command of the target object in the visual communication area.

[0096] Optionally, in this embodiment, the computer-readable storage medium is configured to store program code for performing the following steps: testing the state of the target application interface using target data according to target test conditions, including: generating at least one test case based on the target test conditions, wherein the at least one test case includes: preset input parameter data for inputting the target application interface, and an expected test result corresponding to the preset input parameter data and the expected test result, wherein the preset input parameter data at least satisfies: required fields are empty, non-required fields are empty, the data type is different from the target field, and the length exceeds the target field; comparing the target data with at least one test case to obtain a comparison result; and determining whether the state of the target application interface is abnormal based on the comparison result and the expected test result.

[0097] Optionally, in this embodiment, the computer-readable storage medium is configured to store program code for performing the following steps: obtaining interface return information of the target application interface for the target data, wherein the interface return information includes the target payment address; converting the target payment address into a payment QR code; and sending the payment QR code to the target requester through the target application interface.

[0098] Optionally, in this embodiment, the computer-readable storage medium is configured to store program code for performing the following steps: determining the length of a custom field corresponding to a lightweight markup language document; comparing whether the lengths of each field in the interface returned information exceed the length of the custom field, and generating an error message if the comparison result indicates yes; and sending the error message to the target requester through the target application interface.

[0099] The sequence numbers of the above embodiments of the present invention are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0100] In the above embodiments of the present invention, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0101] In the several embodiments provided in this application, it should be understood that the disclosed technical content can be implemented in other ways. The device embodiments described above are merely illustrative; for example, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection of units or modules may be electrical or other forms.

[0102] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0103] Furthermore, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0104] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of the present invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, read-only memory (ROM), random access memory (RAM), portable hard drives, magnetic disks, or optical disks.

[0105] The above description is merely a preferred embodiment of the present invention and is not intended to limit the invention. Various modifications and variations can be made to the present invention by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A testing method for an application programming interface (API), characterized in that, include: Receive configuration file and test data corresponding to the target requester, wherein the test data is used to simulate the encrypted request data sent by the target requester to the target application interface, and the configuration file includes multiple application IDs corresponding to multiple requesters, and multiple key information corresponding to the multiple application IDs. Read the target key information corresponding to the application ID of the target requester from the configuration file; The test data is decrypted using the target key information to obtain the target data; Obtain the target test conditions corresponding to the target application interface; According to the target test conditions, the state of the target application interface is tested using the target data; The step of obtaining the target test conditions corresponding to the target application interface includes: receiving a lightweight markup language document corresponding to the target requester; determining the target application interface based on the lightweight markup language document; and obtaining the target test conditions corresponding to the target application interface by parsing the lightweight markup language document, wherein the target test conditions include: the data type of the target field, the length of the target field, and whether the target field is allowed to be empty.

2. The test method according to claim 1, characterized in that, The method further includes: Based on the interface testing environment of different requesters, the configuration file is generated, wherein the configuration file includes: multiple application IDs, multiple key information corresponding to the multiple application IDs, and multiple server addresses corresponding to the multiple requesters.

3. The test method according to claim 1, characterized in that, The step of parsing the lightweight markup language document to obtain the target test conditions corresponding to the target application interface includes: By parsing the lightweight markup language document, a visual communication area corresponding to the target application interface is generated in the interactive interface; In response to the input command from the target object in the visualization communication area, the target test conditions corresponding to the input command are obtained.

4. The test method according to claim 1, characterized in that, The step of testing the state of the target application interface using the target data according to the target test conditions includes: Based on the target test conditions, at least one test case is generated, wherein the at least one test case includes: preset input parameter data for inputting the target application interface, and expected test results corresponding to the preset input parameter data, wherein the preset input parameter data at least satisfies: required fields are empty, non-required fields are empty, the data type is different from the target field, and the length exceeds the target field. The target data is compared with the at least one test case to obtain the comparison result; Based on the comparison results and the expected test results, determine whether the state of the target application interface is abnormal.

5. The test method according to claim 2, characterized in that, The method further includes: Obtain the interface return information of the target application interface for the target data, wherein the interface return information includes the target payment address; Convert the target payment address into a payment QR code; The payment QR code is sent to the target requester via the target application interface.

6. The test method according to claim 5, characterized in that, The method further includes: Determine the length of the custom field corresponding to the lightweight markup language document; The comparison interface returns information to check if the length of each field exceeds the length of the custom field. If the comparison result indicates yes, an error message is generated. The error message is sent to the target requester through the target application interface.

7. A testing apparatus for an application programming interface (API), characterized in that, include: The receiving module is used to receive a configuration file and test data corresponding to the target requester. The test data is used to simulate the encrypted request data sent by the target requester to the target application interface. The configuration file includes multiple application IDs corresponding to multiple requesters and multiple key information corresponding to the multiple application IDs. The reading module is used to read the target key information corresponding to the application ID of the target requester from the configuration file; The decryption module is used to decrypt the test data using the target key information to obtain the target data; The acquisition module is used to acquire the target test conditions corresponding to the target application interface; The testing module is used to test the state of the target application interface using the target data according to the target test conditions. The acquisition module is further configured to receive a lightweight markup language document corresponding to the target requester; determine the target application interface based on the lightweight markup language document; and obtain target test conditions corresponding to the target application interface by parsing the lightweight markup language document, wherein the target test conditions include: the data type of the target field, the length of the target field, and whether the target field is allowed to be empty.

8. An electronic device, characterized in that, include: processor; Memory used to store the processor's executable instructions; The processor is configured to execute the instructions to implement the test method as described in any one of claims 1 to 7.

9. A computer-readable storage medium, characterized in that, When the instructions in the computer-readable storage medium are executed by the processor of the electronic device, the electronic device is able to perform the test method as described in any one of claims 1 to 7.