CN111950252A - HTTP response message format verification method, device and equipment - Google Patents
HTTP response message format verification method, device and equipment Download PDFInfo
- Publication number
- CN111950252A CN111950252A CN202010755781.0A CN202010755781A CN111950252A CN 111950252 A CN111950252 A CN 111950252A CN 202010755781 A CN202010755781 A CN 202010755781A CN 111950252 A CN111950252 A CN 111950252A
- Authority
- CN
- China
- Prior art keywords
- request
- response
- format
- parameter
- http
- 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
Links
- 230000004044 response Effects 0.000 title claims abstract description 109
- 238000000034 method Methods 0.000 title claims abstract description 54
- 238000012795 verification Methods 0.000 title claims abstract description 14
- 238000004422 calculation algorithm Methods 0.000 claims abstract description 13
- 238000012360 testing method Methods 0.000 claims description 13
- 238000004590 computer program Methods 0.000 claims description 8
- 235000014510 cooky Nutrition 0.000 claims description 3
- 238000001514 detection method Methods 0.000 abstract description 4
- 230000009286 beneficial effect Effects 0.000 abstract description 2
- 230000008569 process Effects 0.000 description 6
- 230000006870 function Effects 0.000 description 4
- 238000012423 maintenance Methods 0.000 description 3
- 238000010586 diagram Methods 0.000 description 2
- 238000006467 substitution reaction Methods 0.000 description 2
- 238000013024 troubleshooting Methods 0.000 description 2
- 230000004075 alteration Effects 0.000 description 1
- 230000014509 gene expression Effects 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 230000008520 organization Effects 0.000 description 1
- 238000012827 research and development Methods 0.000 description 1
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F40/00—Handling natural language data
- G06F40/10—Text processing
- G06F40/194—Calculation of difference between files
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/445—Program loading or initiating
- G06F9/44521—Dynamic linking or loading; Link editing at or after load time, e.g. Java class loading
- G06F9/44526—Plug-ins; Add-ons
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
Abstract
The invention relates to a method, a device and equipment for checking the format of an HTTP response message, comprising the following steps: acquiring a response instance of the tested interface based on a Jmeter tool; positioning to a response message format responseBodySchema of the tested interface based on preset parameters OpenAPI document path, Request method and Request path; and carrying out consistency check on each parameter in the responseBodySchema and the corresponding parameter in the response instance based on a recursive algorithm, and throwing out a checked error field to prompt the expected data type of the error field. The invention has the beneficial effects that: by including data type verification in the verified response message format, only three entry parameters, namely Open API document path, request method and request path, are needed, and the response instance acquired after the HTTP request is sent automatically performs format verification of each parameter based on a recursion algorithm and a message predefined by a document, so that missing detection is avoided and the coverage rate is 100%; in addition, the tester does not need to input the field needing to be checked in response, so that parameter errors caused by manual input are avoided, and the working efficiency is greatly improved.
Description
Technical Field
The invention belongs to the technical field of interface response testing, and particularly relates to a method, a device and equipment for verifying HTTP response message format.
Background
With the popularization of mobile internet, various mobile phone applications and web pages have been developed endlessly, and they have played an irreplaceable role in our daily life, so that it has become a key point of research and development how to better and more quickly develop products convenient for users to use, and it is important to automatically check the interface message formats of these network products within a limited time, and speed up the positioning of the problem of client-side server-side joint debugging and the efficiency of regression testing.
Apache JMeter is a Java-based interface testing tool developed by the Apache organization. JMeter can perform a function/regression test on the application to verify that the program returned the desired message format by creating a script with assertions. JMeter allows assertions to be created using regular expressions for maximum flexibility.
The basic idea of the existing Assertion message format based on the Jmeter is to add an Assertion plug-in to the Sampler, manually configure required test parameters, or implement the Assertion message format through Java codes in the similar BeanShell Assertion. The above technology requires the tester to input parameters accurately, and the requirement of code capability is high. When the tester writes the test parameters, errors often occur, for example, one more symbol or incorrect symbol, the input parameters are incorrect, and the like, and a lot of time is spent on troubleshooting the errors, so that the test efficiency is reduced. The other is to realize the assertion message format through Java codes, which has high requirements on the code capability of testers and low expandability.
Disclosure of Invention
In order to solve the problems of low test efficiency and low expandability in the prior art, the invention provides a method, a device and equipment for verifying the format of an HTTP response message, which have the characteristics of improved working efficiency, simple operation, low maintenance cost and the like.
According to the specific implementation manner of the invention, the method for verifying the format of the HTTP response message comprises the following steps:
acquiring a response instance of the tested interface based on a Jmeter tool;
positioning to a response message format responseBodySchema of the tested interface based on preset parameters OpenAPI document path, Request method and Request path;
and carrying out consistency check on each parameter in the responseBodySchema and the corresponding parameter in the response instance based on a recursive algorithm, and throwing out a checked error field to prompt the expected data type of the error field.
Further, the HTTP response packet format verification method further includes: and if the consistency check is passed, the format of the response instance message is correct.
Further, the acquiring a response instance of the tested interface based on the Jmeter tool specifically includes:
creating an HTTP request in a Jmeter tool, configuring relevant parameters of the HTTP request to form a request script, and operating the request script to acquire the response instance of the tested interface.
Further, the responding message format responsebody schema positioned to the tested interface based on the preset parameters OpenAPI document path, Request method, and Request path includes:
obtaining an API specification document of a tested interface, and taking the preset parameter OpenAPI document path as a storage path of the API specification document on a server;
and adding the preset parameters OpenAPI document path, Request method and Request path to the HTTP Request, and positioning a response message format responseBodySchema of the tested interface when the Request script is operated.
Further, the API specification document stores the suffix of.yaml based on the YAML implementation.
Further, still include: and adding Name and Comments parameters to the HTTP request to Name and remark the response message format responseBodySchema.
Further, the creating of the HTTP request in the meter tool and the configuring of the relevant parameters of the HTTP request to form the request script specifically include:
adding a thread group under a test plan, and adding an HTTP request, an HTTP Cookie manager and a plug-in for checking a result tree under the thread group;
and configuring relevant parameters of the HTTP request to form a request script.
Further, the performing consistency check on each parameter in the responseBodySchema and the corresponding parameter in the response instance based on the recursive algorithm specifically includes:
determining the type of each parameter in the responseBodySchema;
comparing the type of the parameter with the type of the response return parameter corresponding to the response instance;
if the types are not consistent, prompting that the field names which are unqualified in verification and the predefined data types of the field names are contained;
and if the types are consistent, continuously checking the type of the next parameter until all the parameters in the response instance are traversed.
An HTTP response packet format verification apparatus provided in accordance with a specific embodiment of the present invention includes:
the response message module is used for acquiring a response instance of the tested interface based on the Jmeter tool;
the response parameter module is used for positioning a response message format responseBodySchema of the tested interface based on preset parameters OpenAPI document path, Request method and Request path; and
and the checking module is used for carrying out consistency checking on each parameter in the responseBodySchema and the corresponding parameter in the response instance based on a recursive algorithm and throwing out a checked error field to prompt the expected data type of the error field.
According to a specific embodiment of the present invention, there is provided an apparatus including:
a processor, and a memory coupled to the processor;
the memory is used for storing a computer program, and the computer program is at least used for executing the HTTP response message format checking method;
the processor is used for calling and executing the computer program in the memory.
The invention has the beneficial effects that: by including data type verification in the verified response message format, only three entry parameters, namely Open API document path, request method and request path, are needed, and the response instance acquired after the HTTP request is sent automatically performs format verification of each parameter based on a recursion algorithm and a message predefined by a document, so that missing detection is avoided and the coverage rate is 100%; in addition, the tester does not need to input the field needing to be checked in response, so that parameter errors caused by manual input are avoided, the working efficiency is greatly improved, the operation is simple, and the maintenance cost is low.
Drawings
In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the embodiments or the prior art will be briefly described below, it is obvious that the drawings in the following description are only some embodiments of the present invention, and for those skilled in the art, other drawings can be obtained according to the drawings without creative efforts.
Fig. 1 is a flowchart of a method for checking an HTTP response packet format according to an example embodiment;
fig. 2 is a schematic diagram of an HTTP response message format checking apparatus provided in accordance with an example embodiment;
fig. 3 is a schematic diagram of an apparatus provided in accordance with an example embodiment.
Detailed Description
In order to make the objects, technical solutions and advantages of the present invention more apparent, the technical solutions of the present invention will be described in detail below. It is to be understood that the described embodiments are merely exemplary of the invention, and not restrictive of the full scope of the invention. All other embodiments, which can be derived by a person skilled in the art from the examples given herein without any inventive step, are within the scope of the present invention.
Referring to fig. 1, an embodiment of the present invention provides a method for checking an HTTP response packet format, including the following steps:
101. acquiring a response instance of the tested interface based on a Jmeter tool;
102. positioning to a response message format responseBodySchema of the tested interface based on preset parameters OpenAPI document path, Request method and Request path;
103. and performing consistency check on each parameter in the responseBodySchema and the corresponding parameter in the response instance based on a recursive algorithm, and throwing out a checked error field to prompt the expected data type of the error field.
Specifically, the main disadvantages of the prior art are three: firstly, when the number of response parameters of the interface is more, the partial field format is generally predicated, the coverage rate does not reach 100%, and the problem of missed detection exists; secondly, when the testers write the test parameters, errors often occur, for example, one more symbol is added or the symbol is incorrect, the input parameters are wrong, and a large amount of time is spent for troubleshooting, so that the test efficiency is reduced, and when the message structure is changed, a large amount of time is spent for maintaining the script; thirdly, in the process of realizing the assertion message format through Java codes, the requirement on the coding capability of testers is higher, the universality is poorer, and different interfaces need to be rewritten.
The embodiment of the invention can be uniquely positioned to the responseBodySchema through the OpenAPI document path, the Request Method and the Request path; then, a response instance can be obtained by running a Jmeter script; through a recursive algorithm, traversing each parameter of the responseBodySchema and a parameter corresponding to response to carry out consistency check on the mandatory item and the data type; if the consistency check fails, the Assertion result will throw the wrong field and indicate the expected data type of the field. If the message passes, the format of the response message is correct. Therefore, the format of each parameter can be verified, so that the omission is avoided, and the coverage rate is 100%; in addition, the tester does not need to input the field needing to be checked in response, so that parameter errors caused by manual input are avoided, and the working efficiency is greatly improved.
As a possible implementation manner of the above embodiment, the process of checking the format of the response message based on the Jmeter may be mainly divided into API document preparation, script preparation, and assertion setting.
The API specification of the interface to be tested is implemented using YAML format documents, with the suffix saved as.yaml. The API specification document defines service information, request and return parameters, state codes and the like of the interface, and is a bridge for connecting the client and the server. The input parameter OpenAPI document path of the assertion plug-in is defined as a storage path of the API document on the server, such as http: [ IP ]/API. In the execution process of the Jmeter script, the API document to be used can be positioned through the OpenAPI document path parameter.
The realization of the assertion plug-in can be based on an HTTP request, and an HTTP request is newly built in a Jmeter tool, and the specific steps are that a thread group is added under a test plan, the HTTP request, an HTTP Cookie manager and a result tree plug-in are added under the thread group; and then configuring the protocol, IP, request method, request path and request parameters of the tested HTTP request. Thus, a script of the Jmeter-based HTTP request is prepared.
And then adding an assertion plug-in the HTTP Request in a plug-in adding mode for assertion, wherein parameters of the assertion plug-in comprise five parts, namely Name, Comments, OpenAPI document path, Request Method and Request path. Wherein, the Name displays the Name of the plug-in and can be freely defined; comments are remarks which can be filled in freely; the OpenAPI document path is the storage position of the API document on the server; the Request Method is a Method for requesting a message; the Request path is the URL of the Request message. After a Jmeter script is started and a response instance is obtained, a response message format responseBodySchema (which is a predefined response parameter format) of a tested interface can be uniquely positioned according to the OpenAPI document path, the Request method and the Request path based on an assertion plug-in.
After a response instance and a predefined response parameter format responseBodySchema are obtained, a recursive algorithm is utilized to firstly judge which data type the predefined response parameter belongs to, whether the predefined response parameter belongs to is one of Object, Array, Integer, String, Number, Boolean and the like, then the predefined response parameter is compared with the response return parameter type of the corresponding response instance, if the predefined response parameter type is not consistent with the response return parameter type of the response instance, an exception prompt is thrown, and the prompt language content comprises the field name which is unqualified in verification and the predefined data type thereof. Otherwise, the next parameter format is checked. And automatically checking the format of the predefined parameters and the response return parameters until all predefined parameters are traversed, and realizing 100% checking of all predefined fields.
In another specific implementation manner of the invention, the feasibility of the assertion plug-in the method can be verified based on the positive and negative use cases of the HTTP request interface. For example, a response message of a forward use case HTTP request is as follows:
{"status":true,
"message": operation was successful,
"statusCode":"SYS0001",
"result":{"token":"wJPzpL4VL/3EEifzDg1AMmMIzmqCXvKHJEzLGX4JIm6Ri BBzlT2BX/s3Z3Kqe1/q"}
}。
a reverse use case is prepared such that the parameter result is null, the interface fails to run, and the assertion results throw the field and the data type of the field defined by the document. Thereby verifying the feasibility of the assertion run.
Some embodiments of the present invention shown in fig. 2 further provide an HTTP response message format verification apparatus, including:
the response message module is used for acquiring a response instance of the tested interface based on the Jmeter tool;
the response parameter module is used for positioning a response message format responseBodySchema of the tested interface based on preset parameters OpenAPI document path, Request method and Request path; and
and the checking module is used for carrying out consistency checking on each parameter in the responseBodySchema and the corresponding parameter in the response instance based on a recursive algorithm and throwing out the checked error field to prompt the expected data type of the error field.
In a specific implementation process, the response message module may be a response script edited by using a Jmeter tool, the response parameter module obtains a response message format responsebydyschema for an assertion plug-in added in the response script, and the verification module performs consistency judgment on the parameters in the responsebydyschema and the types of the parameters in the response instance to further implement traversal of all predefined parameters, and automatically verifies the format of the response return parameters, thereby implementing 100% verification of all predefined fields.
Referring to fig. 3, an embodiment of the present invention, which is adapted to the HTTP response packet format verifying apparatus provided in the foregoing embodiment of the present invention, further provides an apparatus, including:
a processor, and a memory coupled to the processor;
the memory is used for storing a computer program, and the computer program is at least used for executing the HTTP response message format checking method in the embodiment;
the processor is used to call and execute the computer program in the memory.
For a specific implementation manner of the device, reference may be made to the specific implementation manner of the HTTP response packet format checking method provided in the foregoing embodiment, and details of the present invention are not described herein again.
According to the method, the device and the equipment for verifying the format of the HTTP response message, provided by the embodiment of the invention, through three entry parameters of Open API document path, request method and request path, the format of each parameter is automatically verified between the response instance obtained after the request is sent and the message predefined by the API document, so that the condition that detection is not missed is ensured, and the coverage rate is 100%; in addition, the tester does not need to input the field needing to be checked in response, so that parameter errors caused by manual input are avoided, the working efficiency is greatly improved, and the assertion plug-in generated by the method is high in transportability, simple to operate and low in maintenance cost.
Any process or method descriptions in flow charts or otherwise described herein may be understood as representing modules, segments, or portions of code which include one or more executable instructions for implementing specific logical functions or steps of the process, and alternate implementations are included within the scope of the preferred embodiment of the present invention in which functions may be executed out of order from that shown or discussed, including substantially concurrently or in reverse order, depending on the functionality involved, as would be understood by those reasonably skilled in the art of the present invention.
It should be understood that portions of the present invention may be implemented in hardware, software, firmware, or a combination thereof. In the above embodiments, the various steps or methods may be implemented in software or firmware stored in memory and executed by a suitable instruction execution system. For example, if implemented in hardware, as in another embodiment, any one or combination of the following techniques, which are known in the art, may be used: a discrete logic circuit having a logic gate circuit for implementing a logic function on a data signal, an application specific integrated circuit having an appropriate combinational logic gate circuit, a Programmable Gate Array (PGA), a Field Programmable Gate Array (FPGA), or the like.
In the description herein, references to the description of the term "one embodiment," "some embodiments," "an example," "a specific example," or "some examples," etc., mean that a particular feature, structure, material, or characteristic described in connection with the embodiment or example is included in at least one embodiment or example of the invention. In this specification, the schematic representations of the terms used above do not necessarily refer to the same embodiment or example. Furthermore, the particular features, structures, materials, or characteristics described may be combined in any suitable manner in any one or more embodiments or examples.
What has been described above includes examples of one or more embodiments. It is, of course, not possible to describe every conceivable combination of components or methodologies for purposes of describing the aforementioned embodiments, but one of ordinary skill in the art may recognize that many further combinations and permutations of various embodiments are possible. Accordingly, the embodiments described herein are intended to embrace all such alterations, modifications and variations that fall within the scope of the appended claims. Furthermore, to the extent that the term "includes" is used in either the detailed description or the claims, such term is intended to be inclusive in a manner similar to the term "comprising" as "comprising" is interpreted when employed as a transitional word in a claim. Furthermore, any use of the term "or" in the specification of the claims is intended to mean a "non-exclusive or".
The above description is only for the specific embodiments of the present invention, but the scope of the present invention is not limited thereto, and any person skilled in the art can easily conceive of the changes or substitutions within the technical scope of the present invention, and all the changes or substitutions should be covered within the scope of the present invention. Therefore, the protection scope of the present invention shall be subject to the protection scope of the appended claims.
Claims (10)
1. A method for checking the format of an HTTP response message is characterized by comprising the following steps:
acquiring a response instance of the tested interface based on a Jmeter tool;
positioning to a response message format responseBodySchema of the tested interface based on preset parameters OpenAPI document path, Request method and Request path;
and carrying out consistency check on each parameter in the responseBodySchema and the corresponding parameter in the response instance based on a recursive algorithm, and throwing out a checked error field to prompt the expected data type of the error field.
2. The method for checking the format of the HTTP response packet according to claim 1, further comprising: and if the consistency check is passed, the format of the response instance message is correct.
3. The method for verifying the format of the HTTP response packet according to claim 1, wherein the acquiring a response instance of the interface to be tested based on the Jmeter tool specifically includes:
creating an HTTP request in a Jmeter tool, configuring relevant parameters of the HTTP request to form a request script, and operating the request script to acquire the response instance of the tested interface.
4. The method for verifying the format of the HTTP response packet according to claim 3, wherein the response packet format responsebydyschema that is located to the interface to be tested based on the preset parameters OpenAPI document path, Request method, and Request path includes:
obtaining an API specification document of a tested interface, and taking the preset parameter OpenAPI document path as a storage path of the API specification document on a server;
and adding the preset parameters OpenAPI document path, Request method and Request path to the HTTP Request, and positioning a response message format responseBodySchema of the tested interface when the Request script is operated.
5. The method of claim 4, wherein the API specification document stores a.yaml suffix based on a YAML implementation.
6. The method for checking the format of the HTTP response packet according to claim 4, further comprising: and adding Name and Comments parameters to the HTTP request to Name and remark the response message format responseBodySchema.
7. The method for verifying the format of the HTTP response packet according to claim 3, wherein creating the HTTP request in the Jmeter tool and configuring the relevant parameters of the HTTP request to form a request script specifically includes:
adding a thread group under a test plan, and adding an HTTP request, an HTTP Cookie manager and a plug-in for checking a result tree under the thread group;
and configuring relevant parameters of the HTTP request to form a request script.
8. The method for checking the format of the HTTP response packet according to any one of claims 1 to 7, wherein the performing, based on a recursive algorithm, the consistency check on each parameter in the responsebody schema and the corresponding parameter in the response instance specifically includes:
determining the type of each parameter in the responseBodySchema;
comparing the type of the parameter with the type of the response return parameter corresponding to the response instance;
if the types are not consistent, prompting that the field names which are unqualified in verification and the predefined data types of the field names are contained;
and if the types are consistent, continuously checking the type of the next parameter until all the parameters in the response instance are traversed.
9. An apparatus for verifying an HTTP response packet format, comprising:
the response message module is used for acquiring a response instance of the tested interface based on the Jmeter tool;
the response parameter module is used for positioning a response message format responseBodySchema of the tested interface based on preset parameters OpenAPI document path, Request method and Request path; and
and the checking module is used for carrying out consistency checking on each parameter in the responseBodySchema and the corresponding parameter in the response instance based on a recursive algorithm and throwing out a checked error field to prompt the expected data type of the error field.
10. An apparatus, comprising:
a processor, and a memory coupled to the processor;
the memory is configured to store a computer program configured to at least perform the HTTP response message format checking method according to any one of claims 1 to 8;
the processor is used for calling and executing the computer program in the memory.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202010755781.0A CN111950252A (en) | 2020-07-31 | 2020-07-31 | HTTP response message format verification method, device and equipment |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202010755781.0A CN111950252A (en) | 2020-07-31 | 2020-07-31 | HTTP response message format verification method, device and equipment |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN111950252A true CN111950252A (en) | 2020-11-17 |
Family
ID=73338941
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202010755781.0A Pending CN111950252A (en) | 2020-07-31 | 2020-07-31 | HTTP response message format verification method, device and equipment |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN111950252A (en) |
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN112463261A (en) * | 2020-11-20 | 2021-03-09 | 北京达佳互联信息技术有限公司 | Interface calling method and device |
| CN112860551A (en) * | 2021-02-02 | 2021-05-28 | 浪潮云信息技术股份公司 | Method for realizing online debugging and document export based on API gateway |
Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN106155891A (en) * | 2015-04-02 | 2016-11-23 | 阿里巴巴集团控股有限公司 | Interface test method, interface description data library generating method and device |
| CN109189684A (en) * | 2018-08-28 | 2019-01-11 | 四川长虹电器股份有限公司 | Automatic interface testing method based on Python |
| CN111143192A (en) * | 2019-11-28 | 2020-05-12 | 叮当快药科技集团有限公司 | Interface automation test method and device and related product |
| US20200241872A1 (en) * | 2019-01-25 | 2020-07-30 | Allstate Insurance Company | Systems and Methods for Automating and Monitoring Software Development Operations |
-
2020
- 2020-07-31 CN CN202010755781.0A patent/CN111950252A/en active Pending
Patent Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN106155891A (en) * | 2015-04-02 | 2016-11-23 | 阿里巴巴集团控股有限公司 | Interface test method, interface description data library generating method and device |
| CN109189684A (en) * | 2018-08-28 | 2019-01-11 | 四川长虹电器股份有限公司 | Automatic interface testing method based on Python |
| US20200241872A1 (en) * | 2019-01-25 | 2020-07-30 | Allstate Insurance Company | Systems and Methods for Automating and Monitoring Software Development Operations |
| CN111143192A (en) * | 2019-11-28 | 2020-05-12 | 叮当快药科技集团有限公司 | Interface automation test method and device and related product |
Cited By (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN112463261A (en) * | 2020-11-20 | 2021-03-09 | 北京达佳互联信息技术有限公司 | Interface calling method and device |
| CN112860551A (en) * | 2021-02-02 | 2021-05-28 | 浪潮云信息技术股份公司 | Method for realizing online debugging and document export based on API gateway |
| CN112860551B (en) * | 2021-02-02 | 2024-04-30 | 浪潮云信息技术股份公司 | Method for realizing online debugging and document export based on API gateway |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN111159049B (en) | Automatic interface testing method and system | |
| US10853227B2 (en) | Systems and methods for modular test platform for applications | |
| CN106897215A (en) | A kind of method gathered based on WebView webpages loading performance and user behavior flow data | |
| US20130339931A1 (en) | Application trace replay and simulation systems and methods | |
| CN111752843B (en) | Method, apparatus, electronic device and readable storage medium for determining influence surface | |
| CN111427765B (en) | Method and system for automatically starting interface performance test realized based on jmeter | |
| CN111124919A (en) | User interface testing method, device, equipment and storage medium | |
| CN111950252A (en) | HTTP response message format verification method, device and equipment | |
| CN108809755B (en) | Automatic testing method and system for home gateway compatible with command line and WEB interface | |
| CN111444111A (en) | Performance testing method and device based on python, computer equipment and storage medium | |
| CN109218407B (en) | Code management and control method based on log monitoring technology and terminal equipment | |
| CN106339273A (en) | Application program restoration method, terminal and server | |
| US11573780B2 (en) | Automated generation of status chains for software updates | |
| US20200104246A1 (en) | Continuous automation with test suite engine | |
| CN109657475A (en) | Code vulnerabilities check method, apparatus, equipment and storage medium | |
| CN112559348B (en) | Test analysis method, system, equipment and medium based on jacoco | |
| CN106571975A (en) | Fault tolerance method of communication data and apparatus thereof | |
| US11132286B1 (en) | Dynamic reordering of test case execution | |
| KR20070104202A (en) | Automation test service system for view software of portable telephone and method thereof | |
| Jin et al. | NChecker: Saving mobile app developers from network disruptions | |
| CN116340169A (en) | XPath path detection method and device for page element | |
| CN115454860A (en) | Automatic testing method and device, storage medium and electronic equipment | |
| Pereyda | boofuzz Documentation | |
| Cavalli et al. | Use of invariant properties to evaluate the results of fault-injection-based robustness testing of protocol implementations | |
| CN110134904B (en) | Page checking method, device, equipment and medium |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination |