Interface document automatic verification method, device and server

Abstract

The application provides an interface document automatic verification method, device and server, and relates to the field of computers. The method comprises the following steps: a server obtains a success uploading message of successful execution and a to-be-verified interface corresponding to the success uploading message from a log file. The server determines the corresponding interface document of the to-be-verified interface according to the interface name of the to-be-verified interface. The server determines the check rule of each uploading parameter in the interface document by analyzing the interface document. The server modifies the parameter value of the uploading field in the success uploading message according to the check rule, generates a test uploading message and an expected result. The server calls a test interface by using the test uploading message, and obtains a corresponding test return message. The test return message comprises an execution result. The server realizes the verification of the interface document of the to-be-verified interface according to the comparison result of the execution result of each test uploading message and the prediction result. The method provided in the application improves the verification efficiency of the interface document.

Description

Technical Field

[0001] This application relates to the field of computers, and more particularly to a method, apparatus, and server for automated verification of interface documents. Background Technology

[0002] In software development, every interface program needs to be accompanied by a corresponding interface document. Before an interface program is put into use, it is usually necessary to test both the interface program and the interface document to ensure their effectiveness.

[0003] In existing technologies, programmers can use white-box testing to set test cases for the interface program based on its code, thereby testing the interface program. Programmers can also use white-box testing to set test cases based on the interface documentation, thereby verifying the interface documentation.

[0004] However, in the existing technology, the test cases for this white-box testing usually need to be set by the programmer according to the interface documentation. The test effect depends on the programmer's own experience and may have poor test results. Summary of the Invention

[0005] This application provides a method, apparatus, and server for automated verification of interface documents, in order to solve the problem of poor testing results in the prior art.

[0006] Firstly, this application provides a method for automated verification of interface documents, including:

[0007] Obtain the log file, and based on the log file, determine a successful upload message and an interface to be verified;

[0008] Based on the interface document corresponding to the interface to be verified and the successful upload message, generate multiple test upload messages and obtain the test return message for each test upload message;

[0009] When all the test results return correct messages, it is determined that the interface documentation of the interface to be verified has passed verification.

[0010] Optionally, determining a successful upload message and an interface to be verified based on the log file specifically includes:

[0011] According to the preset success identifier, search the log file for a successful return message that includes the success identifier. The success identifier is used to indicate that the successful return message is the message returned after the corresponding uploaded message is successfully executed.

[0012] Based on the upload identifier in the successful return message, search the log file for a successful upload message corresponding to the successful return message. The upload identifier is used to uniquely identify an upload message.

[0013] The corresponding interface to be verified is determined based on the successful return message.

[0014] Optionally, when the log file includes multiple successful return messages, the method further includes:

[0015] Parse the successful upload message corresponding to each of the aforementioned successful return messages, and determine the interface name corresponding to each of the aforementioned successful upload messages;

[0016] Based on the preset mapping table between interface names and priorities, determine the priority corresponding to each successfully uploaded message;

[0017] Select the highest priority success message.

[0018] Optionally, generating multiple test upload messages based on the interface document corresponding to the interface to be verified and the successful upload message specifically includes:

[0019] By parsing the successful upload message through natural language processing, the interface name of the interface to be verified, the upload fields of the message, and the parameter values ​​of each upload field are obtained.

[0020] Based on the interface name, obtain and parse the interface document corresponding to the interface to be verified, determine the interface submission fields corresponding to the interface to be verified, and at least one verification rule for each interface submission field;

[0021] Based on the verification rules of the interface sent fields of the interface to be verified, the sent message is modified to obtain multiple test sent messages.

[0022] Optionally, the step of modifying the uploaded message according to the verification rules of the interface uploaded field of the interface to be verified to obtain multiple test uploaded messages specifically includes:

[0023] Obtain the validation rule for a field sent by the interface;

[0024] According to the verification rules, modify the parameter value of the message sending field corresponding to the interface sending field in the successful sending message to obtain a test sending message;

[0025] Repeat the above steps until all the validation rules for all fields sent by all the interfaces have been used.

[0026] Optionally, determining that the interface documentation verification of the interface to be verified has passed when all the test return messages are correct specifically includes:

[0027] Parse each test return message to determine the test execution result of each test return message;

[0028] Based on the verification rules of the test upload message corresponding to each test return message, determine the expected result of each test return message;

[0029] When the test execution result of all the test return messages is the same as the expected result, it is determined that all the test return messages are correct.

[0030] When all the test results return correct messages, the interface documentation verification for the interface to be verified is deemed successful.

[0031] Secondly, this application provides an automated verification device for interface documents, comprising:

[0032] The acquisition module is used to acquire log files and, based on the log files, determine a successful upload message and an interface to be verified.

[0033] The verification module is used to generate multiple test upload messages based on the interface document corresponding to the interface to be verified and the successful upload message, and to obtain the test return message of each test upload message; when all the test return messages are correct, it is determined that the interface document of the interface to be verified has been verified.

[0034] Optionally, the acquisition module is specifically used for:

[0035] According to the preset success identifier, search the log file for a successful return message that includes the success identifier. The success identifier is used to indicate that the successful return message is the message returned after the corresponding uploaded message is successfully executed.

[0036] Based on the upload identifier in the successful return message, search the log file for a successful upload message corresponding to the successful return message. The upload identifier is used to uniquely identify an upload message.

[0037] The corresponding interface to be verified is determined based on the successful return message.

[0038] Optionally, when the log file includes multiple successful return messages, the acquisition module is further configured to:

[0039] Parse the successful upload message corresponding to each of the aforementioned successful return messages, and determine the interface name corresponding to each of the aforementioned successful upload messages;

[0040] Based on the preset mapping table between interface names and priorities, determine the priority corresponding to each successfully uploaded message;

[0041] Select the highest priority success message.

[0042] Optionally, the verification module is specifically used for:

[0043] By parsing the successful upload message through natural language processing, the interface name of the interface to be verified, the upload fields of the message, and the parameter values ​​of each upload field are obtained.

[0044] Based on the interface name, obtain and parse the interface document corresponding to the interface to be verified, determine the interface submission fields corresponding to the interface to be verified, and at least one verification rule for each interface submission field;

[0045] Based on the verification rules of the interface sent fields of the interface to be verified, the sent message is modified to obtain multiple test sent messages.

[0046] Optionally, the verification module is specifically used for:

[0047] Obtain the validation rule for a field sent by the interface;

[0048] According to the verification rules, modify the parameter value of the message sending field corresponding to the interface sending field in the successful sending message to obtain a test sending message;

[0049] Repeat the above steps until all the validation rules for all fields sent by all the interfaces have been used.

[0050] Optionally, the verification module is specifically used for:

[0051] Parse each test return message to determine the test execution result of each test return message;

[0052] Based on the verification rules of the test upload message corresponding to each test return message, determine the expected result of each test return message;

[0053] When the test execution result of all the test return messages is the same as the expected result, it is determined that all the test return messages are correct.

[0054] When all the test results return correct messages, the interface documentation verification for the interface to be verified is deemed successful.

[0055] Thirdly, this application provides a server, including: a memory and a processor;

[0056] The memory is used to store computer programs; the processor is used to execute the interface document automated verification method in the first aspect and any possible design of the first aspect according to the computer programs stored in the memory.

[0057] Fourthly, this application provides a computer-readable storage medium storing a computer program, which, when executed by at least one processor of a server, enables the server to perform the interface document automated verification method of the first aspect and any possible design of the first aspect.

[0058] Fifthly, this application provides a computer program product comprising a computer program that, when at least one processor of a server executes the computer program, enables the server to execute the interface document automated verification method in the first aspect and any possible design of the first aspect.

[0059] The interface documentation automated verification method, apparatus, and server provided in this application improve the verification efficiency and testing effectiveness of interface documentation by: retrieving log files from a log database; obtaining successful upload messages from the log files after successful execution; determining the interface to be verified corresponding to the successful upload message; determining the corresponding interface documentation based on the interface name of the interface to be verified; determining the verification rules for each upload parameter in the interface documentation by parsing the interface documentation; modifying the parameter values ​​of the upload fields in the successful upload message according to the verification rules, thereby generating a new test upload message and generating the expected result; calling the test interface using the test upload message and obtaining the test return message corresponding to each test upload message; the test return message may include the execution result of the interface to be tested; when the execution result is consistent with the predicted result, it indicates that the returned test message is correct; when all test return messages are correct, it indicates that the verification rules of the interface documentation of the interface to be verified are consistent with the interface to be tested, and the verification is successful. Attached Figure Description

[0060] To more clearly illustrate the technical solutions in this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0061] Figure 1 A schematic diagram of the structure of an automated interface document verification system provided in an embodiment of this application;

[0062] Figure 2 A flowchart illustrating an automated verification method for interface documentation, provided as an embodiment of this application;

[0063] Figure 3 A schematic diagram of an automated interface document verification device provided in an embodiment of this application;

[0064] Figure 4 This is a schematic diagram of the hardware structure of a server provided in one embodiment of this application. Detailed Implementation

[0065] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0066] The terms "first," "second," "third," "fourth," etc., used in the specification, claims, and accompanying drawings of this application 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 used interchangeably where appropriate. For example, without departing from the scope of this document, first information can also be referred to as second information, and similarly, second information can also be referred to as first information.

[0067] Depending on the context, the word "if" as used here can be interpreted as "when," "when," or "in response to determination."

[0068] Furthermore, as used herein, the singular forms “a,” “one,” and “the” are intended to also include the plural forms, unless the context indicates otherwise.

[0069] It should be further understood that the terms “comprising” or “including” indicate the presence of features, steps, operations, elements, components, items, kinds, and / or groups, but do not exclude the presence, occurrence, or addition of one or more other features, steps, operations, elements, components, items, kinds, and / or groups.

[0070] The terms “or” and “and / or” as used herein are interpreted as inclusive, or mean any one or any combination thereof. Therefore, “A, B, or C” or “A, B, and / or C” means “any one of the following: A; B; C; A and B; A and C; B and C; A, B, and C”. Exceptions to this definition occur only when combinations of elements, functions, steps, or operations are inherently mutually exclusive in some way.

[0071] In software development, every interface program requires a corresponding interface document. However, there can be a disconnect between the interface program and its document. That is, the description in the document may differ from the actual logic of the program. For example, the document might state that a field cannot be empty, but the actual interface program might not have this empty validation. This lack of validation can have extremely serious consequences. Therefore, before an interface program and its document are deployed, they typically need to be tested to ensure their validity and consistency. The interface program includes the interface code. Developers and testers can then design test cases based on the logic and flow of this code to perform white-box testing. The interface document generally uses tables and / or natural language. It may include multiple fields to be sent to the interface and multiple validation rules for each field. These validation rules typically include three categories: whether the field is empty, whether the field has a limited input range, and the field length. When a field has a limited input range, it usually includes a "data dictionary." The field specification specifies whether it limits the input range, which can be defined by a "data dictionary." This "data dictionary" can include multiple selectable parameters for the field. If the parameters for the field are within the range of this "data dictionary," the field call succeeds. Otherwise, the field call fails. The field length limit restricts the character length of the field. If the character length exceeds the specified limit, an error will occur. This interface documentation is typically highly readable. Developers and testers can quickly and effectively understand the interface's implementation mechanism by reading the documentation. Developers and testers can design test cases based on the validation rules in the interface documentation to perform black-box testing of the interface program. This black-box testing verifies whether the interface documentation matches the interface program.

[0072] However, in existing technologies, test cases for this type of white-box testing typically require programmers to set them up themselves based on the interface documentation. The effectiveness of these tests relies heavily on the programmer's experience, potentially leading to poor test results. Furthermore, the interface program and documentation are updated and iterated very rapidly. Each time the interface program or documentation is updated, the programmer needs to verify the consistency between the updated documentation and the updated program to ensure the effective use of the interface. If programmers have to re-set test cases every time, this results in low testing efficiency.

[0073] To address the aforementioned issues, this application proposes an automated method for verifying interface documentation. This application can automatically verify whether the validation rules of the fields submitted by the interface program are consistent with those described in the interface documentation. In this application, the server can automatically traverse all possibilities for each submitted field of the interface to be verified. The server can generate test cases based on each possibility of each submitted field, thereby verifying whether the validation rules of each submitted field are the same as those described in the interface documentation. When the programmer modifies the interface program, the server can use the method of this application to automatically verify both the interface program and the interface documentation, thereby ensuring the consistency between the interface documentation and the interface program.

[0074] The technical solutions of this application will be described in detail below with specific embodiments. The following specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments.

[0075] Figure 1 This illustration shows a schematic diagram of the structure of an automated interface document verification system according to an embodiment of this application. Figure 1 As shown, the automated interface documentation verification system of this application is used to dynamically and automatically verify whether the verification rules of the fields sent by the interface program to be verified are consistent with the description in the interface documentation. This automated interface documentation verification system includes five modules: a sent message acquisition module, an interface documentation parsing module, a sent message generation module, an interface execution module, and a consistency verification result output module.

[0076] The upload message acquisition module is used to obtain upload messages that have been successfully executed. Since interface programs are often used to implement transactions in financial scenarios, this module can acquire upload messages that demonstrate successful transaction execution. This module can connect to a database that stores log files of interface program execution. The module can automatically capture successfully executed upload messages from each interface program in the log files. Alternatively, when the interface program is used to implement transactions, the module can automatically capture transaction logs from the log files and filter for successfully executed upload messages. It can also acquire successfully executed upload messages manually uploaded by testers, developers, or other programmers. The purpose of this module is to obtain successfully executed upload messages. Selecting these messages facilitates subsequent modification to generate test upload messages, thereby improving verification efficiency.

[0077] The interface priority determination module is used to classify interface programs. The server can prioritize the verification of higher-priority interface programs. Based on this priority, the server can also output the verification results of each interface program, thereby reducing the analysis workload for programmers. The interface priority determination module continuously receives uploaded messages collected by the uploaded message acquisition module. It can classify and store all received uploaded messages. Finally, the interface priority determination module can sequentially transmit uploaded messages to subsequent modules in descending order of priority.

[0078] The interface document parsing module is used to parse the validation rules for each parameter sent by the interface in the interface document. Generally, interface documents come in two formats: Word and Excel. The interface document parsing module can read both Word and Excel documents. It can read the interface name, the fields sent by the interface, and the validation rules from the interface document. The module can also associate the interface code corresponding to the sent message with the interface code in the interface document to obtain all validation rules for each sent field. These validation rules may include "whether it is empty," "data dictionary," and "length limit," etc. For example, Table 1 shows an interface document.

[0079] Table 1

[0080]

[0081]

[0082] The upload message generation module, based on the upload message acquisition module and the interface document parsing module, after acquiring a successfully executed upload message, modifies each field in the upload message according to the upload field verification rules described in the interface document to obtain a test upload message. This test upload message can fully cover all possible uploads. In this process, only one upload field of the upload message is changed at a time, while the remaining upload fields remain unchanged. This method of controlling variables clearly defines the impact of the changed fields on the execution result. The upload message generation module can also provide expected results for each test upload message. Expected results can be divided into success and failure. For example, as shown in Table 1, according to the interface document, the corresponding upload message can include 8 upload field modifications and expected execution results. The expected results are as follows: (1) if the proName field is empty, the expected result is failure; (2) if the proName field is not empty, the expected result is success; (3) if the operFlag field is 1, the expected result is success; (4) if the operFlag field is 2, the expected result is success; (5) if the operFlag field is 3, the expected result is failure; (6) if the proName is a string of length 1, the expected result is success; (7) if the proName is a string of length 10, the expected result is success; (8) if the proName is a string of length 11, the expected result is failure.

[0083] The interface execution module can use the test upload messages generated by the upload message generation module to call the interface one by one and initiate access requests. This module can also record the execution result of each access request. For example, the interface execution module can use the eight test upload messages listed in Table 1 to call the interface and record the transaction results.

[0084] The consistency verification result output module is used to organize the execution results and generate a report. This module can also output the report to inform developers or testers whether the description of the uploaded field verification in the interface documentation matches the actual execution result of the interface. For each interface execution, the consistency verification result output module compares the expected result generated in the uploaded message module with the transaction execution result of the interface execution module. If the expected result matches the execution result, it indicates that the interface documentation and the actual verification rules of the interface are consistent. Otherwise, it indicates that there is an inconsistency between the interface documentation and the interface, requiring developers to reconfirm.

[0085] In this application, a server is used as the execution subject to perform the interface document automated verification method of the following embodiments. Specifically, the execution subject can be a server hardware device, a software application implementing the following embodiments on the server, a computer-readable storage medium on which the software application implementing the following embodiments is installed, or code implementing the software application of the following embodiments.

[0086] Figure 2 A flowchart illustrating an embodiment of an interface document automated verification method provided in this application is shown. Figure 1 Based on the illustrated embodiments, as Figure 2 As shown, with the server as the execution entity, the method in this embodiment may include the following steps:

[0087] S101. Obtain the log file and, based on the log file, determine a successful upload message and an interface to be verified.

[0088] In this embodiment, the server can retrieve log files from a log repository. These log files can be usage logs for one or more target software or system platforms. Alternatively, they can be interface call records generated during testing after a version update of the target software or system platform. The testing can be code testing executed after generating test cases based on the code of the target software or system platform. Alternatively, the testing can also be functional testing executed based on the functionality of the target software or system platform. During this testing process, the programmer needs to call all interfaces of the target software or system platform to determine its effectiveness.

[0089] The log file may include access records for various interfaces of the target software or system platform. Each access record may include one uploaded message and one returned message. In these access records, some uploaded messages receive a returned message upon successful execution, while others receive a returned message upon failure. The server can first obtain the uploaded messages that receive a returned message upon successful execution. This successful uploaded message ensures its availability. To distinguish these successfully executed uploaded messages, in the following embodiments, these uploaded messages that receive a returned message upon successful execution are referred to as successful uploaded messages. The server can also determine the interface to be verified corresponding to the successful uploaded message based on it.

[0090] In one example, the server can send the log file to the programmer after retrieving it. The programmer can then manually process the log file and extract the successful upload message. The programmer can then manually enter this successful upload message into the server.

[0091] In another example, the server can retrieve the successful upload message from the log file through a search. The specific steps may include:

[0092] Step 1: Each access record can include one uploaded message and one returned message. The returned message can include a "return code" field. This field is used to identify whether the returned message is a success message or a failure message. Currently, the success parameter value for the "return code" is generally set to "0". The server can search the log file for successful returned messages containing this default success flag. The success flag indicates that the successful returned message is the message returned after the corresponding uploaded message was successfully executed. When the uploaded message is a successful uploaded message, it means that the format of the uploaded message is correct. Otherwise, if the uploaded message fails to execute, it cannot be guaranteed whether the format of the uploaded message is correct or whether any uploaded fields are missing. Therefore, the server cannot generate a correct test uploaded message based on an incorrect uploaded message.

[0093] Step 2: The server can execute many access requests simultaneously, and each access request generates an access record. Long interface processing times and a large number of simultaneously sent upload messages can cause upload and return messages within an access request to be discontinuous. That is, in the log file, the upload and return messages of an access request may include other upload messages or other return messages. Therefore, upload messages generally contain an upload identifier. This upload identifier typically includes the access code and a timestamp. The return message also contains this upload identifier. Upload and return messages can be matched using this upload identifier. Therefore, the server can search the log file for a successful upload message corresponding to a successful return message based on the upload identifier in the successful return message, thus obtaining the successful upload message. The upload identifier is used to uniquely identify an upload message.

[0094] Step 3: After confirming the successful transmission of the message, the server can determine the corresponding interface to be verified based on the successful return message.

[0095] In another example, the server may need to verify multiple interfaces in the target software or system platform. In this case, the log file of the target software or system platform may include interface access records. These access records may include multiple successful return messages. After identifying these successful upload messages, the server can parse them and determine the interface name corresponding to each successful upload message. The server can determine the priority of each successful upload message based on a preset mapping table of interface names and priorities. The server can then verify the interfaces corresponding to these successful upload messages one by one according to this priority. When selecting a successful upload message to process, the server can choose the interface to be verified from the highest priority successful upload message.

[0096] It's important to note that among the multiple successful upload messages retrieved by the server from a log file, several may correspond to the same interface. In this case, the server can select one successful upload message from these multiple messages for the following steps. The server can also delete other successful upload messages corresponding to that interface.

[0097] During the iterative updates of the target software or system platform, new versions typically involve the addition or modification of interfaces compared to older versions. Since interface documentation usually includes access records for all interfaces of the target software or system platform, the log file will inevitably contain the interfaces that have been modified or added in the new version. Considering that programmers generally only process the code corresponding to the interfaces that need to be added or modified during version updates, the newly added or modified interfaces will be the first to be verified among the numerous interface access records in the log file. Without a priority determination process, the server will verify the interfaces corresponding to all successfully uploaded messages appearing in the log file. If the target software or system platform involves a large number of interfaces, this method will be time-consuming and contain only a small amount of useful information. Therefore, to improve verification efficiency, the server can use a pre-defined mapping table between interface names and priorities to prioritize the newly added or modified interfaces and review them first.

[0098] This pre-defined mapping table between interface names and priorities can be created by programmers based on the importance and modification status of various interfaces in the target software or system platform. This mapping table allows for the hierarchical classification of interfaces. Higher-priority interfaces can be verified first. Furthermore, the server can organize reports according to different priorities, thereby reducing the workload of subsequent analysis.

[0099] For example, priorities can be set using numbers 1-4. Priority 4 is the highest, and 1 is the lowest. Priority 4 indicates that the interface sends fields that require verification, such as passwords, SMS verification codes, or PIN codes. Priority 3 represents interfaces newly added or modified in the current period. Priority 2 represents interfaces involving sensitive customer information. All others are interfaces with a priority of 1.

[0100] For example, this preset mapping table between interface names and priorities defines the relationship between each interface and its priority by submitting the names of the fields. Interfaces with priority 4 include fields such as PassWord, PWD, PIN, PW, and MassageCode. Interfaces with priority 3 include the TransCode field. And / or, interfaces with priority 3 may include the names of interfaces added or modified in the current version. Interfaces with priority 2 may include fields that may involve sensitive customer information, such as name, certCode, tel, and telno. During the generation of this mapping table, programmers can expand the keywords included in each priority level according to the actual code requirements. This mapping table can be implemented based on keyword matching.

[0101] S102. Based on the interface documentation and successful upload message corresponding to the interface to be verified, generate multiple test upload messages and obtain the test return message for each test upload message.

[0102] In this embodiment, the server can determine the corresponding interface document based on the interface name of the interface to be verified. The server can parse the interface document to determine the verification rules for each uploaded parameter. Based on these verification rules, the server can modify the parameter values ​​of the uploaded fields in the successful uploaded message, thereby generating a new test uploaded message. The server can use the test uploaded message to call the test interface and obtain the test return message corresponding to each test uploaded message.

[0103] In one example, the process of generating the test upload message may specifically include the following steps:

[0104] Step 1: The server parses the successful upload message using natural language processing. This successful upload message can be text information generated by the interface after receiving the upload message, based on the parameters in the upload message. The server can parse the information in the upload message according to the rules for generating this text information. This information can include the interface name of the interface to be verified, the upload fields in the message, and the parameter values ​​of each upload field. For example, the interface name of the interface to be verified can include an English name and a Chinese name. The English name can be TransCode. The server can at least parse the English name from the successful upload message.

[0105] Step 2: The server can search in a preset directory based on the interface name to obtain the corresponding interface document. The name of this interface document can be based on the interface name. For example, the name of the interface document can include the English name of the interface. For instance, when the English name of the interface to be verified is "TransCode," the server can associate it with the interface document whose name contains "TransCode." After the message and interface document are associated, the server can parse the interface document corresponding to the interface to be verified. The interface document can be as shown in Table 1. During this parsing process, the server can determine the interface submission fields corresponding to the interface to be verified, and at least one validation rule for each submission field. For example, in the interface document shown in Table 1, the interface submission fields can include four: proName, apiName, fundid_group, and operFlag. The validation rules for the proName field can include whether it is empty and two rules for a field length of 10. The validation rules for the apiName field can include whether it is empty and two rules for a field length of 15. The validation rules for the fundid_group field can include whether it is empty and two rules for whether the content is within the data field range of the submitted field. The validation rules for the operFlag field sent by the interface can include three criteria: whether it is empty, whether the content is within the range of the data fields of the sent field, and whether the field length is 1.

[0106] Step 3: To control variables and better determine the correctness of each verification rule, the server can retrieve the verification rules for the fields sent by the interface to be verified one by one. Each verification rule can include multiple valid parameter values ​​and multiple invalid parameter values. The server can modify the parameter values ​​of the corresponding fields in the successful upload message based on the multiple parameter values ​​corresponding to each verification rule. The server can obtain a test upload message after each modification.

[0107] For example, the server can obtain a validation rule for whether the `proName` field sent by an interface is empty. Based on this rule, the server can determine whether the corresponding two parameter values ​​are empty or not. The server can set the parameter values ​​of the interface sent field corresponding to `proName` in a successful sent message to empty, resulting in a test sent message. The server can also set the parameter values ​​of the sent field corresponding to `proName` in a successful sent message to not empty, resulting in another test sent message. The server can repeat these steps until all validation rules for all interface sent fields have been used.

[0108] For example, in the above loop, when the server receives the interface upload field 'operFlag', and the validation rule is whether the content is within the range of the data field of this upload field, the server can determine that its corresponding parameter value can include 1, 2, and 3. Here, 1 and 2 are reasonable parameter values, and 3 is an unreasonable parameter value. The server can set the parameter value of the upload field corresponding to the interface upload field 'operFlag' in the successful upload message to 1, 2, and 3 respectively, and obtain three test upload messages.

[0109] For example, in the above loop, when the server receives the interface sending field "proName" and the validation rule is that the field length is 10, the server can determine that the length of its corresponding parameter value can be 1, 10, or 11. Among them, lengths of 1 and 10 are reasonable parameter values, while a length of 11 is an unreasonable parameter value. The server can then set these three strings of length 1, 10, and 11 into the parameter value of the sending field corresponding to the interface sending field "proName" in the successful sending message, respectively, to obtain three test sending messages.

[0110] In the above steps, the server generates test upload messages based on the field verification rules in the interface documentation. Each time, the server only modifies the parameter values ​​of the aforementioned fields in one message from the successful upload messages. Since the successful upload messages obtained by the server are already successfully executed upload messages, their format is guaranteed to be correct, and they contain the necessary fields and parameter values ​​for successful interface execution. When the server modifies the parameter values ​​of one upload field in the successful upload message according to the verification rules in the interface documentation, it effectively ensures that the parameter values ​​of other upload fields are valid. This way, if a problem occurs during the interface call using the generated test upload message, the erroneous upload field can be accurately located.

[0111] S103. When all test return messages are correct, it is determined that the interface documentation of the interface to be verified has passed verification.

[0112] In this embodiment, the server can generate expected results simultaneously when generating test upload messages. These expected results can include both successful and failed execution. The server can use the test upload messages to call the interface under test and obtain the test return message corresponding to each test upload message. The test return message can include the execution result of the interface under test. When the execution result matches the predicted result, it indicates that the returned test message is correct. Otherwise, it indicates that the returned test message is incorrect. When all test return messages are correct, it indicates that the verification rules of the interface documentation for the interface under test are consistent with the interface under test, and the verification has passed.

[0113] For example, since the validation rule for the proName field in the API documentation is "required," the value of the proName parameter cannot be empty. That is, if the parameter value corresponding to the proName in the test submission is empty, the predicted result is execution failure. As another example, the validation rule for the operFlag field in the API submission is within the range of {1,2} in the "data dictionary." Therefore, if the parameter value corresponding to the operFlag in the test submission is 3, the predicted result is execution failure. If the parameter value corresponding to the operFlag in the test submission is 1, the predicted result is execution success.

[0114] In one example, the specific process by which the server verifies the interface documentation for the interface to be verified may include the following steps:

[0115] Step 1: The server parses each test return message and determines the test execution result of each test return message.

[0116] Step 2: The server determines the expected result of each test return message based on the verification rules of the test upload message corresponding to each test return message.

[0117] Step 3: When the execution results of all test return messages are the same as the expected results, the server determines that all test return messages are correct.

[0118] Step 4: When the server returns correct messages for all tests, it confirms that the interface documentation verification for the interface to be verified has passed.

[0119] The automated verification method for interface documentation provided in this application allows the server to retrieve log files from a log database. The server can first obtain the successful upload message from the log files, following successful execution. Based on this successful upload message, the server can determine the interface to be verified. The server can also determine the corresponding interface documentation based on the interface name. The server can parse the interface documentation to determine the verification rules for each uploaded parameter. Based on these verification rules, the server can modify the parameter values ​​of the uploaded fields in the successful upload message, thereby generating a new test upload message. The server can generate expected results simultaneously when generating the test upload message. The server can use the test upload message to call the test interface and obtain the test return message corresponding to each test upload message. This test return message can include the execution result of the interface under test. When the execution result matches the predicted result, the returned test message is correct. When all test return messages are correct, it indicates that the verification rules of the interface documentation for the interface to be verified are consistent with those of the interface under test, and the verification has passed. In this application, by obtaining a successful upload message and modifying the parameters in the successful upload message according to the verification rules in the interface document, the verification of the interface document is realized, thereby improving the verification efficiency of the interface document. When the upload message fails during testing, the erroneous verification rules can be accurately located based on the modified parameters, thus improving the testing effect.

[0120] Figure 3 This illustration shows a structural schematic diagram of an interface document automated verification device according to an embodiment of this application, as shown below. Figure 3 As shown, the interface document automated verification device 10 of this embodiment is used to implement the operation corresponding to the server in any of the above method embodiments. The interface document automated verification device 10 of this embodiment includes:

[0121] The acquisition module 11 is used to acquire the log file and, based on the log file, determine a successful upload message and an interface to be verified.

[0122] Verification module 12 is used to generate multiple test upload messages based on the interface documentation and successful upload messages corresponding to the interface to be verified, and to obtain the test return message for each test upload message. When all test return messages are correct, it is determined that the interface documentation of the interface to be verified has passed verification.

[0123] In one example, module 11 is used specifically for:

[0124] Based on the preset success flag, search the log file for a successful return message that includes the success flag. The success flag is used to indicate that the successful return message is the message returned after the corresponding uploaded message is successfully executed.

[0125] Based on the upload identifier in the successful return message, search the log file for the successful upload message corresponding to the successful return message. The upload identifier is used to uniquely identify an upload message.

[0126] The corresponding interface to be verified is determined based on the successful return message.

[0127] In one example, when the log file includes multiple successful return messages, module 11 is also used for:

[0128] Parse the successful upload message corresponding to each successful return message to determine the interface name corresponding to each successful upload message.

[0129] Based on the preset mapping table between interface names and priorities, the priority corresponding to each successfully uploaded message is determined.

[0130] Select the highest priority successful upload message.

[0131] In one example, verification module 12 is specifically used for:

[0132] Through natural language processing, the successfully uploaded message is parsed to obtain the interface name of the interface to be verified, the fields uploaded in the message, and the parameter values ​​of each field uploaded in the message.

[0133] Obtain and parse the interface document corresponding to the interface to be verified based on the interface name, determine the fields to be sent by the interface to be verified, and at least one verification rule for each field sent by the interface.

[0134] Based on the validation rules of the fields sent by the interface to be verified, modify the sent message to obtain multiple test sent messages.

[0135] In one example, verification module 12 is specifically used for:

[0136] Get a validation rule for a field sent by an interface.

[0137] According to the verification rules, modify the parameter values ​​of the message sending fields corresponding to the interface sending fields in the successful sending message to obtain a test sending message.

[0138] Repeat the above steps until all validation rules for all fields sent by all interfaces are used.

[0139] In one example, verification module 12 is specifically used for:

[0140] Parse each test return message to determine the test execution result of each test return message.

[0141] Based on the verification rules of the test upload message corresponding to each test return message, determine the expected result of each test return message.

[0142] If the test execution results in all test return messages are the same as the expected results, then all test return messages are considered correct.

[0143] When all tests return correct messages, it is determined that the interface documentation verification for the interface to be verified has passed.

[0144] The interface document automated verification device 10 provided in this application embodiment can execute the above method embodiment. Its specific implementation principle and technical effect can be found in the above method embodiment, and will not be repeated here.

[0145] Figure 4 A schematic diagram of the hardware structure of a server provided in an embodiment of this application is shown. Figure 4 As shown, the server 20 is used to implement the operations corresponding to the server in any of the above method embodiments. The server 20 in this embodiment may include: a memory 21 and a processor 22.

[0146] The memory 21 is used to store computer programs. The memory 21 may include high-speed random access memory (RAM) and may also include non-volatile memory (NVM), such as at least one disk storage device, and may also be a USB flash drive, external hard drive, read-only memory, disk or optical disc, etc.

[0147] Processor 22 is used to execute the computer program stored in memory to implement the interface document automated verification method in the above embodiments. For details, please refer to the relevant descriptions in the foregoing method embodiments. The processor 22 can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), etc. A general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in this invention can be directly manifested as execution by a hardware processor, or execution by a combination of hardware and software modules within the processor.

[0148] Alternatively, the memory 21 can be either standalone or integrated with the processor 22.

[0149] When the memory 21 is a device independent of the processor 22, the server 20 may also include a bus 23. This bus 23 is used to connect the memory 21 and the processor 22. The bus 23 may be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of illustration, the buses shown in the accompanying drawings are not limited to a single bus or a single type of bus.

[0150] The server provided in this embodiment can be used to execute the above-described automated verification method for interface documents. Its implementation and technical effects are similar, and will not be described again here.

[0151] This application also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, is used to implement the methods provided in the various embodiments described above.

[0152] The computer-readable storage medium can be a computer storage medium or a communication medium. A communication medium includes any medium that facilitates the transfer of a computer program from one location to another. A computer storage medium can be any available medium accessible to a general-purpose or special-purpose computer. For example, a computer-readable storage medium is coupled to a processor, enabling the processor to read information from and write information to the computer-readable storage medium. Of course, the computer-readable storage medium can also be a component of the processor. The processor and the computer-readable storage medium can reside in an Application Specific Integrated Circuit (ASIC). Alternatively, the ASIC can reside in a user equipment. Of course, the processor and the computer-readable storage medium can also exist as discrete components in a communication device.

[0153] Specifically, the computer-readable storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as Static Random-Access Memory (SRAM), Electrically Erasable Programmable Read-Only Memory (EEPROM), Erasable Programmable Read Only Memory (EPROM), Programmable Read-Only Memory (PROM), Read-Only Memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. The storage medium can be any available medium accessible to general-purpose or special-purpose computers.

[0154] This application also provides a computer program product comprising a computer program stored in a computer-readable storage medium. At least one processor of the device can read the computer program from the computer-readable storage medium, and the at least one processor executes the computer program to cause the device to implement the methods provided in the various embodiments described above.

[0155] This application also provides a chip including a memory and a processor. The memory is used to store a computer program, and the processor is used to call and run the computer program from the memory, so that a device with the chip installed performs the methods described in the various possible implementations above.

[0156] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of modules is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple modules 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 between apparatuses or modules may be electrical, mechanical, or other forms.

[0157] The modules can be physically separate, for example, installed in different locations within a single device, installed on different devices, distributed across multiple network units, or distributed across multiple processors. Alternatively, the modules can be integrated, for example, installed in the same device, or integrated into a single codebase. The modules can exist in hardware form, software form, or a combination of both. This application can select some or all of the modules to achieve the objectives of this embodiment based on actual needs.

[0158] When the various modules are implemented as integrated software functional modules, they can be stored in a computer-readable storage medium. The aforementioned software functional modules, stored in a storage medium, include several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) or processor to execute some steps of the methods of the various embodiments of this application.

[0159] It should be understood that although the steps in the flowcharts of the above embodiments are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some of the steps in the figures may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily completed at the same time, but can be executed at different times, and their execution order is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the sub-steps or stages of other steps.

[0160] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and not to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features. These modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application.

Claims

1. A method for automated verification of interface documentation, characterized in that, The method includes: Obtain the log file, and based on the log file, determine a successful upload message and an interface to be verified; Based on the interface document corresponding to the interface to be verified and the successful upload message, generate multiple test upload messages and obtain the test return message for each test upload message; When all the test return messages are correct, it is determined that the interface documentation verification of the interface to be verified has passed; The step of determining a successfully uploaded message and an interface to be verified based on the log file specifically includes: According to the preset success identifier, search the log file for a successful return message that includes the success identifier. The success identifier is used to indicate that the successful return message is the message returned after the corresponding uploaded message is successfully executed. Based on the upload identifier in the successful return message, search the log file for a successful upload message corresponding to the successful return message. The upload identifier is used to uniquely identify an upload message. The corresponding interface to be verified is determined based on the successful return message. The step of generating multiple test upload messages based on the interface document corresponding to the interface to be verified and the successful upload message specifically includes: By parsing the successful upload message through natural language processing, the interface name of the interface to be verified, the upload fields of the message, and the parameter values ​​of each upload field of the message are obtained. Based on the interface name, obtain and parse the interface document corresponding to the interface to be verified, determine the interface submission fields corresponding to the interface to be verified, and at least one verification rule for each interface submission field; According to the verification rules of the interface sent fields of the interface to be verified, the sent message is modified to obtain multiple test sent messages; wherein, each time one sent field of the sent message is changed, the other sent fields in the sent message remain unchanged. When all the test return messages are correct, it is determined that the interface document verification of the interface to be verified has passed, specifically including: Parse each test return message to determine the test execution result of each test return message; Based on the verification rules of the test upload message corresponding to each test return message, determine the expected result of each test return message; When the test execution result of all the test return messages is the same as the expected result, it is determined that all the test return messages are correct. When all the test results return correct messages, the interface documentation verification for the interface to be verified is deemed successful.

2. The method according to claim 1, characterized in that, When the log file includes multiple successful return messages, the method further includes: Parse the successful upload message corresponding to each successful return message and determine the interface name corresponding to each successful upload message; Based on the preset mapping table between interface names and priorities, determine the priority corresponding to each successfully uploaded message; Select the highest priority success message.

3. The method according to claim 1, characterized in that, The step of modifying the uploaded message according to the verification rules of the interface uploaded by the interface to be verified, to obtain multiple test uploaded messages, specifically includes: Obtain the validation rule for a field sent by the interface; According to the verification rules, modify the parameter values ​​of the message sending field corresponding to the interface sending field in the successful sending message to obtain a test sending message; Repeat the above steps until all the validation rules for all fields sent by all the interfaces have been used.

4. An automated verification device for interface documents, characterized in that, The device includes: The acquisition module is used to acquire log files and, based on the log files, determine a successful upload message and an interface to be verified. The verification module is used to generate multiple test upload messages based on the interface document corresponding to the interface to be verified and the successful upload message, and to obtain the test return message of each test upload message; when all the test return messages are correct, it is determined that the interface document of the interface to be verified has been verified. The acquisition module is specifically used to search for a successful return message including the preset success identifier in the log file. The success identifier is used to indicate that the successful return message is the message returned after the corresponding uploaded message is successfully executed. Based on the upload identifier in the successful return message, search the log file for a successful upload message corresponding to the successful return message. The upload identifier is used to uniquely identify an upload message. The corresponding interface to be verified is determined based on the successful return message. The verification module is specifically used to parse the successful upload message through natural language processing to obtain the interface name of the interface to be verified, the message upload fields, and the parameter values ​​of each of the message upload fields. Based on the interface name, obtain and parse the interface document corresponding to the interface to be verified, determine the interface submission fields corresponding to the interface to be verified, and at least one verification rule for each interface submission field; According to the verification rules of the interface sent fields of the interface to be verified, the sent message is modified to obtain multiple test sent messages; wherein, each time one sent field of the sent message is changed, the other sent fields in the sent message remain unchanged. The verification module is specifically used to parse each of the test return messages and determine the test execution result of each of the test return messages; Based on the verification rules of the test upload message corresponding to each test return message, determine the expected result of each test return message; When the test execution result of all the test return messages is the same as the expected result, it is determined that all the test return messages are correct. When all the test results return correct messages, the interface documentation verification for the interface to be verified is deemed successful.

5. A server, characterized in that, The server includes: a memory and a processor; the memory is used to store a computer program; the processor is used to implement the interface document automated verification method as described in any one of claims 1 to 3 according to the computer program stored in the memory.

6. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, which, when executed by a processor, is used to implement the interface document automated verification method as described in any one of claims 1 to 3.

7. A computer program product, characterized in that, The computer program product includes a computer program that, when executed by a processor, implements the interface document automated verification method according to any one of claims 1 to 3.

Images