Interface testing method and device

By scene classification and grouping of interface request messages, a full-link test case is generated, which solves the problem that existing interface testing solutions cannot perform full-link testing, and achieves a more comprehensive test scope and more efficient test results.

CN119938501APending Publication Date: 2025-05-06BEIJING JINGDONG YUANSHENG TECH CO LTD
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
CN202311434421.0
Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Filing Date
2023-10-31
Publication Date
2025-05-06

AI Technical Summary

Technical Problem

The existing interface testing scheme cannot conduct full-link interface testing according to the actual operation of the user, resulting in the incomplete test scope.

Method used

By collecting multiple interface request messages in the target system during the statistical period, performing scene classification and marking processing, dividing interface request messages into multiple request packets, determining the scene call order of each request packet, and assembling test cases based on this information for interface testing.

Benefits of technology

The full-link simulation of interface tests is realized, the testing scope is expanded, the test cases are consistent with the actual business scenarios, the generation of invalid cases is reduced, and the testing effect is improved.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN119938501A_ABST
    Figure CN119938501A_ABST
Patent Text Reader

Abstract

The invention discloses an interface testing method and device, and relates to the technical field of computers. A specific embodiment of the method comprises the following steps: collecting a plurality of interface request messages of a target system in a statistical time period; performing scene classification and marking processing on the plurality of interface request messages; dividing the plurality of interface request messages into a plurality of request groups; for each request group, determining a scene calling sequence of each scene classification corresponding to the request group; determining a scene classification to which each interface request message in the request group belongs; and according to the scene calling sequence and the scene classification to which each interface request message in the request group belongs, assembling each interface request message in the request group, and generating a test case corresponding to the request group so as to perform interface test on the target system. According to the embodiment, the full-link interface test can be carried out according to the actual operation condition of the user, so that the test range of the interface test is more comprehensive.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] The present invention relates to the field of computer technology, and in particular to an interface testing method and device. Background Art

[0002] Interface testing is a test of the interfaces between system components. Interface testing is mainly used to detect the interaction points between external systems and systems and between internal subsystems. The focus of interface testing is to check the data exchange, transmission and control management process, as well as the mutual logical dependencies between systems. Existing interface testing solutions generally only test scattered interfaces and cannot perform full-link interface testing according to the actual user operation conditions, making the test scope of interface testing not comprehensive enough. Summary of the invention

[0003] In view of this, an embodiment of the present invention provides an interface testing method and device, which can simulate the actual operation of the user and perform a full-link interface test, so that the test scope of the interface test is more comprehensive.

[0004] In a first aspect, an embodiment of the present invention provides an interface testing method, comprising:

[0005] Collect multiple interface request messages of the target system within the statistical period;

[0006] Classifying the multiple interface request messages by scenario, and marking each of the interface request messages according to the scenario classification to which each of the interface request messages belongs;

[0007] Dividing the multiple interface request messages into multiple request groups;

[0008] For each of the request groups, determine the scene call order of each scene classification corresponding to the request group; determine the scene classification to which each interface request message in the request group belongs according to the mark in the interface request message; assemble each interface request message in the request group according to the scene call order and the scene classification to which each interface request message in the request group belongs, and generate a test case corresponding to the request group;

[0009] The interface test of the target system is performed using the test cases corresponding to the request groups.

[0010] Optionally, the performing scenario classification on the multiple interface request messages includes:

[0011] Determining a current interface request message from the multiple interface request messages;

[0012] Determine the message attribute value of each target attribute corresponding to the current interface request message;

[0013] Combining the message attribute values ​​to generate a message sample corresponding to the current interface request message;

[0014] Determine a decision sample corresponding to each of the scene classifications, wherein the decision sample is generated by combining the decision attribute values ​​of the scene classifications corresponding to each of the target attributes;

[0015] Respectively determining the correlation value between the message sample and each of the decision samples;

[0016] The scenario classification to which the current interface request message belongs is determined according to the correlation degree values ​​between the message sample and each of the decision samples.

[0017] Optionally, respectively determining the correlation value between the message sample and each of the decision samples includes:

[0018] Determining a current scene classification from the plurality of scene classifications;

[0019] Determine a current decision sample corresponding to the current scene classification;

[0020] For each of the target attributes, determine the current decision value of the current decision sample corresponding to the target attribute; calculate the certainty value between the message attribute value corresponding to the target attribute and the current decision value;

[0021] According to the certainty degree value between the message attribute value corresponding to each of the target attributes and the current decision value, the correlation degree value between the message sample and the current decision sample is determined.

[0022] Optionally, the performing scenario classification on the multiple interface request messages includes:

[0023] Obtain the mapping relationship between keywords and scene classifications;

[0024] Determining a current interface request message from the multiple interface request messages;

[0025] Traversing the current interface request message, determining whether the current interface request message contains a target keyword, the target keyword being a keyword contained in the mapping relationship;

[0026] In response to the current interface request message containing the target keyword, determining a target scene classification corresponding to the target keyword according to the mapping relationship;

[0027] The current interface message is classified into the target scenario classification.

[0028] Optionally, determining the scene calling order of each scene classification corresponding to the request group includes:

[0029] On the target page, the scene categories corresponding to the request group are displayed;

[0030] Receive a drag operation for the displayed scene classification;

[0031] According to the dragging operation, adjusting the display position of the displayed scene classification in the target page;

[0032] The scene calling order of each scene classification corresponding to the request group is determined according to the display position of each scene classification corresponding to the request group in the target page.

[0033] Optionally, determining the scene calling order of each scene classification corresponding to the request group includes:

[0034] Determine a tracking identifier corresponding to each interface request message in the request group, wherein the tracking identifier is used to represent a calling order of the interface request message;

[0035] According to the tracking identifiers corresponding to the interface request messages in the request group and the scene categories to which they belong, the scene calling order of the scene categories corresponding to the request group is determined.

[0036] Optionally, assembling each interface request message in the request group according to the scenario calling sequence and the scenario classification to which each interface request message in the request group belongs, and generating a test case corresponding to the request group includes:

[0037] Assembling the interface request messages in the request group according to the scene calling sequence and the scene classification to which the interface request messages in the request group belong, and generating an assembly use case corresponding to the request group;

[0038] identifying at least one parameter to be replaced in the assembly use case;

[0039] Extracting replacement values ​​corresponding to the parameters to be replaced from the test document;

[0040] Each of the parameters to be replaced in the assembly case is replaced with its corresponding replacement value to generate a test case corresponding to the request group.

[0041] In a second aspect, an embodiment of the present invention provides an interface testing device, including:

[0042] A message collection module is used to collect multiple interface request messages of the target system within a statistical period;

[0043] A message marking module, used to classify the multiple interface request messages according to scenarios, and mark each of the interface request messages according to the scenario classification to which each of the interface request messages belongs;

[0044] A message grouping module, used for dividing the multiple interface request messages into multiple request groups;

[0045] A use case generation module is used to determine, for each request group, a scene call sequence of each scene classification corresponding to the request group; determine, according to the mark in the interface request message, the scene classification to which each interface request message in the request group belongs; assemble each interface request message in the request group according to the scene call sequence and the scene classification to which each interface request message in the request group belongs, and generate a test case corresponding to the request group;

[0046] The interface testing module is used to perform interface testing on the target system using the test cases corresponding to each of the request groups.

[0047] In a third aspect, an embodiment of the present invention provides an electronic device, including:

[0048] one or more processors;

[0049] a storage device for storing one or more programs,

[0050] When the one or more programs are executed by the one or more processors, the one or more processors implement the method described in any of the above embodiments.

[0051] In a fourth aspect, an embodiment of the present invention provides a computer-readable medium having a computer program stored thereon, wherein the program, when executed by a processor, implements the method described in any of the above embodiments.

[0052] An embodiment of the above invention has the following advantages or beneficial effects: Scenario classification and labeling of multiple interface request messages collected from the target system. Multiple interface request messages are divided into multiple request groups. The request group corresponds to a group of interface request messages involved in the user's continuous operation process, that is, a group of interface request messages involved in the full-link operation. Determine the scene call order of each scenario classification corresponding to the request group. According to the mark in the interface request message, determine the scenario classification to which each interface request message belongs. According to the scene call order and the scenario classification to which each interface request message in the request group belongs, assemble each interface request message in the request group, generate a test case corresponding to the request group, and complete the interface test of the target system.

[0053] Since the request grouping corresponds to a group of interface request messages involved in the user's full-link operation, the test cases generated based on the request grouping can simulate the user's actual operation conditions and perform full-link interface testing, making the test scope of the interface test more comprehensive.

[0054] In addition, according to the scenario calling sequence corresponding to the request group, the interface request messages in the request group are assembled to generate test cases. This can make the sending sequence of the interface request messages in the test case consistent with the actual business, reduce the risk of generating invalid use cases, and make the interface test more effective.

[0055] The further effects of the above-mentioned non-conventional optional manner will be described below in conjunction with the specific implementation manner. BRIEF DESCRIPTION OF THE DRAWINGS

[0056] The accompanying drawings are used to better understand the present invention and do not constitute an improper limitation of the present invention.

[0057] Figure 1 is a schematic diagram of a process of an interface testing method provided by an embodiment of the present invention;

[0058] Figure 2 is a schematic diagram of a process of an interface testing method provided by another embodiment of the present invention;

[0059] Figure 3 is a schematic diagram of a process of an interface testing method provided by another embodiment of the present invention;

[0060] Figure 4 is a schematic diagram of a process of an interface testing method provided by yet another embodiment of the present invention;

[0061] Figure 5 is a structural schematic diagram of an interface testing device provided by an embodiment of the present invention;

[0062] Figure 6 It is a schematic diagram of the structure of a computer system of a terminal device or a server suitable for implementing an embodiment of the present invention. DETAILED DESCRIPTION

[0063] The following is a description of exemplary embodiments of the present invention in conjunction with the accompanying drawings, including various details of the embodiments of the present invention to facilitate understanding, which should be considered as merely exemplary. Therefore, it should be recognized by those of ordinary skill in the art that various changes and modifications may be made to the embodiments described herein without departing from the scope and spirit of the present invention. Similarly, for clarity and conciseness, the description of well-known functions and structures is omitted in the following description.

[0064] It should be noted that the acquisition, storage, use, and processing of data in the technical solutions of the embodiments of the present invention are in compliance with the relevant provisions of national laws and regulations.

[0065] Figure 1 FIG. 1 is a schematic diagram of a process of an interface testing method provided by an embodiment of the present invention. Figure 1As shown, the method includes:

[0066] Step 101: Collect multiple interface request messages of the target system within a statistical period.

[0067] Step 102: categorize multiple interface request messages by scenario, and mark each interface request message according to the scenario category to which each interface request message belongs.

[0068] Scenario classification can be set according to the architecture design, application scenarios and specific needs of the target system. For example, for an e-commerce system, scenario classification may include: placing an order, modifying an order, confirming an order, querying an order, and making a payment.

[0069] The preset field of the interface request message can be set to the identifier of the scene classification corresponding to the interface request message, or a prefix or suffix representing the scene classification can be added to the preset field. For example, the "-od" suffix can be added to the end of the host field value of the request header of the interface request message to represent that the scene classification to which the interface request message belongs is order placement.

[0070] Step 103: Divide the multiple interface request messages into multiple request groups.

[0071] A request group corresponds to a set of interface request messages involved in the continuous operation process of the user, that is, a set of interface request messages involved in the full-link operation. Each interface request message has an execution order. For example, the user's order process can correspond to the following business scenarios in sequence: order placement, order modification, order confirmation, and payment. Therefore, the interface request messages corresponding to order placement, order modification, order confirmation, and payment can be grouped into a request group. The entire process of the user's order placement can be tested through the test case corresponding to the request group.

[0072] Requests are grouped according to the configured rule information. For example, multiple interface request messages with the same order number during the statistical period can be grouped into one request group. Multiple interface request messages with the same order number and user ID during the statistical period can also be grouped into one request group, etc.

[0073] Step 104: For each request group, determine the scene calling order of each scene classification corresponding to the request group.

[0074] Each scenario classification corresponding to the request group has a calling order. For example, when a user performs an order modification operation, he places an order first and then modifies the order. If the order is modified first and then placed, the execution will fail.

[0075] The scene calling order of each scene classification corresponding to the request group can be determined manually, or it can be determined based on the execution time, tracking mark, etc. of the interface request message corresponding to each scene classification.

[0076] Step 105: Determine the scenario category to which each interface request message in the request group belongs according to the tag in the interface request message.

[0077] Step 106: According to the scenario calling sequence and the scenario classification to which each interface request message in the request group belongs, assemble each interface request message in the request group to generate a test case corresponding to the request group.

[0078] According to the scene call sequence, the interface request messages in the request group are assembled in sequence to generate the test cases corresponding to the request group. The test case is a simulation of the user's operation scenario. It can also identify the parameters to be replaced in the test case and reset the parameters to be replaced to generate a test case that meets the sequencing needs.

[0079] Step 107: Use the test cases corresponding to each request group to perform interface testing on the target system.

[0080] Set external parameters, such as execution environment parameters, interface call interval, etc. According to the external parameters, call the interface message request in each test case to implement the interface test of the target system.

[0081] In the scheme of the embodiment of the present invention, the multiple interface request messages collected from the target system are scenario-classified and marked. The multiple interface request messages are divided into multiple request groups. The request group corresponds to a group of interface request messages involved in the continuous operation process of the user, that is, a group of interface request messages for full-link operations. Determine the scene call order of each scene classification corresponding to the request group. According to the mark in the interface request message, determine the scene classification to which each interface request message belongs. According to the scene call order and the scene classification to which each interface request message in the request group belongs, assemble each interface request message in the request group, generate a test case corresponding to the request group, and complete the interface test of the target system.

[0082] Since the request grouping corresponds to a group of interface request messages of the user's full-link operation, the test cases generated based on the request grouping can perform full-link interface testing according to the user's actual operation conditions, making the test scope of the interface test more comprehensive.

[0083] In one embodiment of the present invention, multiple interface request messages are subjected to scenario classification, including: determining a current interface request message from multiple interface request messages; determining message attribute values ​​corresponding to each target attribute of the current interface request message; combining each message attribute value to generate a message sample corresponding to the current interface request message; determining a decision sample corresponding to each scenario classification, the decision sample being generated by combining the decision attribute values ​​corresponding to each target attribute of the scenario classification; respectively determining a correlation value between the message sample and each decision sample; and determining the scenario classification to which the current interface request message belongs based on the correlation value between the message sample and each decision sample.

[0084] The target attributes can be set according to specific needs. The value of the target attribute is used to characterize the characteristic information of the interface request message. The interface request message is classified according to the value of each target attribute. The target attributes can include: request call chain ID, interface information, request header, request parameters, response parameters, etc.

[0085] Each decision attribute value corresponding to the scene classification is a typical value of the target attribute corresponding to the scene classification. The decision attribute value can be set by relevant personnel based on experience. For example, the scene classification includes: female and male, and the target attributes include: hair length and height. The decision attribute value corresponding to the female classification is: long hair, below 165. The decision attribute value corresponding to the male classification is: short hair, above 165. The attribute value corresponding to the sample is long hair, 160, then the correlation value of the sample with the female decision sample is higher, and the sample can be classified into the female classification.

[0086] The correlation value is used to characterize the degree of association between the message sample and each decision sample. The correlation value can be the Euclidean distance, Manhattan distance, and Hamming distance between the message sample and each decision sample. The correlation value can also be determined using fuzzy rough set technology.

[0087] The scene classification corresponding to the decision sample with the largest correlation value can be used as the scene classification to which the message sample belongs. If the correlation values ​​corresponding to each decision sample are less than the preset threshold, the scene classification corresponding to the message sample cannot be determined, and the interface request message corresponding to the message sample is discarded.

[0088] In one embodiment of the present invention, the correlation degree values ​​between the message sample and each decision sample are determined respectively, including: determining the current scene classification from multiple scene classifications; determining the current decision sample corresponding to the current scene classification; determining, for each target attribute, the current decision value of the target attribute corresponding to the current decision sample; calculating the certainty degree value between the message attribute value corresponding to the target attribute and the current decision value; and determining the correlation degree value between the message attribute value corresponding to each target attribute and the current decision value.

[0089] The certainty value is used to characterize the degree of association between the message attribute value and the decision value. The certainty value can be the Euclidean distance, Manhattan distance, and Hamming distance between the message attribute value and the decision value. The certainty value can also be determined using fuzzy rough set technology.

[0090] The statistical value of the certainty degree value between the message attribute value corresponding to each target attribute and the decision value can be used as the correlation degree value between the message sample and the decision sample. The statistical value can be a mean, a mode, a maximum value, etc.

[0091] In one embodiment of the present invention, multiple interface request messages are subjected to scene classification, including: obtaining a mapping relationship between keywords and scene classifications; determining a current interface request message from multiple interface request messages; traversing the current interface request message to determine whether the current interface request message contains a target keyword, the target keyword being a keyword included in the mapping relationship; in response to the current interface request message containing the target keyword, determining a target scene classification corresponding to the target keyword according to the mapping relationship; and classifying the current interface message into the target scene classification.

[0092] The mapping relationship between keywords and scene classifications can be preset in the system, and the mapping relationship between keywords, message fields and scene classifications can also be preset. Each interface request message is traversed, and the keyword is searched in the interface request message or the message field of the interface request message by using a regular expression. If the search is successful, the interface request message is classified into the scene classification corresponding to the keyword.

[0093] In one embodiment of the present invention, the scene calling order of each scene classification corresponding to the request group is determined, including: displaying each scene classification corresponding to the request group in the target page; receiving a drag operation for the displayed scene classification; adjusting the display position of the displayed scene classification in the target page according to the drag operation; and determining the scene calling order of each scene classification corresponding to the request group according to the display position of each scene classification corresponding to the request group in the target page.

[0094] The user can adjust the calling order of each scene category by dragging. The scene calling order of each scene category corresponding to the request group is determined according to the display rules and the display position of each scene category. The display rule can be that the scene category closer to the left in the horizontal direction has a higher calling order, and the scene category closer to the top in the vertical direction has a higher calling order, etc.

[0095] Figure 2 FIG. 1 is a schematic diagram of a process of an interface testing method provided by another embodiment of the present invention. Figure 2 As shown, the method includes:

[0096] Step 201: Collect multiple interface request messages of the target system within a statistical period.

[0097] Step 202: categorize multiple interface request messages by scenario, and mark each interface request message according to the scenario category to which each interface request message belongs.

[0098] Step 203: Divide the multiple interface request messages into multiple request groups.

[0099] Step 204: For each request group, determine the tracking identifier corresponding to each interface request message in the request group.

[0100] The trace identifier is used to represent the calling order of the interface request message, such as traceId. Since the traceId of the interface called earlier is smaller, the calling order corresponding to each scenario classification can be determined from small to large traceId. The trace identifier can also be the mobilization time and execution order of the interface request message.

[0101] Step 205: Determine the scenario category to which each interface request message in the request group belongs according to the tag in the interface request message.

[0102] Step 206: Determine the scene calling order of each scene category corresponding to the request group according to the tracking identifier corresponding to each interface request message in the request group and the scene category to which it belongs.

[0103] Step 207: According to the scenario calling sequence, assemble the interface request messages in the request group and generate a test case corresponding to the request group.

[0104] Step 208: Use the test cases corresponding to each request group to perform interface testing on the target system.

[0105] In the solution of the embodiment of the present invention, the scene call sequence of each scene classification corresponding to the request group is determined according to the tracking identifier corresponding to each interface request message in the request group and the scene classification to which it belongs. The subsequent request group for executing the same business can directly use the scene call sequence to generate the corresponding test case. The generated test case is a simulation of the actual user operation, which can better evaluate the operation of the target system.

[0106] Figure 3 FIG. 1 is a schematic diagram of a process of an interface testing method provided by another embodiment of the present invention. Figure 3 As shown, the method includes:

[0107] Step 301: Collect multiple interface request messages of the target system within a statistical period.

[0108] Step 302: categorize multiple interface request messages by scenario, and mark each interface request message according to the scenario category to which each interface request message belongs.

[0109] Step 303: Divide the multiple interface request messages into multiple request groups.

[0110] Step 304: For each request group, determine the scene calling order of each scene classification corresponding to the request group.

[0111] Step 305: Determine the scenario category to which each interface request message in the request group belongs according to the tag in the interface request message.

[0112] Step 306: According to the scenario calling sequence and the scenario classification to which each interface request message in the request group belongs, assemble each interface request message in the request group to generate an assembly use case corresponding to the request group.

[0113] Step 307: Identify at least one parameter to be replaced in the assembly use case; and extract replacement values ​​corresponding to each parameter to be replaced from the test document.

[0114] The parameters to be replaced can be saved in a parameter table to be identified or a parameter text to be identified. At least one parameter to be replaced can be identified from the assembly case by using JsonPath, XmlPath or regular expressions. Then, the replacement values ​​corresponding to the parameters to be replaced can be extracted from the test document by using JsonPath, XmlPath or regular expressions.

[0115] Step 308: Replace each parameter to be replaced in the assembly case with its corresponding replacement value, and generate a test case corresponding to the request group.

[0116] Parameter replacement can be achieved through MockJs, Freemarker, regular expressions and other related methods.

[0117] Step 309: Use the test cases corresponding to each request group to perform interface testing on the target system.

[0118] In the scheme of the embodiment of the present invention, at least one parameter to be replaced in the assembly case is identified, and each parameter to be replaced in the assembly case is replaced to generate each test case that meets the test requirements. When the same parameter to be tested corresponds to multiple replacement values, multiple test cases corresponding to a request group can also be generated, so that the test case meets the test requirements and improves the execution efficiency of the test case.

[0119] Figure 4 FIG. 1 is a schematic diagram of a process of an interface testing method provided by another embodiment of the present invention. Figure 4As shown, the method includes the following steps: user real traffic collection, full-link automation, traffic intelligent analysis and coloring, interface automation scenario assembly and keyword parameterization.

[0120] Collect real user traffic and record all requests sent by relevant users on a server within a certain statistical time period.

[0121] Full-link automation, within a certain period of time, assembles the interface call requests recorded on the system into automation scenarios according to the call sequence of the user's actual operations. The assembled automation scenarios are consistent with the user's actual operations.

[0122] The message collection module provides traffic recording function. The recording of one traffic includes one entry call and several sub-calls. The traffic recording process is to bind the entry call and sub-calls into a complete record.

[0123] Intelligent traffic analysis and coloring, analyze the collected traffic through keyword matching algorithm and call chain tracking technology. The request message is classified into scenarios through the keyword matching algorithm. First, a set of keywords is defined in the configuration library, such as interface name and method, request parameters, call chain ID, request header, response content, etc. Then, each interface request message is traversed to check whether any keyword is contained in the interface request message. If the keyword is contained, the interface request message is classified into the corresponding scenario classification.

[0124] You can get the mapping relationship between predefined keywords and scene classifications, then traverse the interface request message list, and classify and color each interface request message. You can use regular expressions to search for keywords in various fields of the interface request message. If the search is successful, the interface request message is classified into the corresponding scene classification.

[0125] Interface automatic scenario assembly and keyword parameterization are responsible for automatic scenario assembly and parameterization of classified interfaces. Scenario assembly will assemble interface use cases into end-to-end full-link business scenario use cases according to business scenarios. The order between interface use case steps can be adjusted by dragging and dropping. Parameterization and assertions and interface use cases reference each other for quick extraction. Parameter identification can be performed through JsonPath, XmlPath, regular expressions, etc. Parameter setting can be achieved through MockJs, Freemarker and other related methods.

[0126] The interface is recorded through traffic collection, and the recorded traffic is identified by business scenario keywords. Different scenario classifications are identified based on the interface definition and interface message keywords. The following introduces the implementation principle of the scenario classification algorithm model using the e-commerce system as the target system.

[0127] For the convenience of introduction, "recording traffic" is defined as a data set. The attribute set C in the data set is {c1, c2, ... ci}. c1, c2, ... ci are different attributes. Attributes may include: request call chain ID, interface information, request header, request parameters, response parameters, etc. Message sample set X = {x1, x2, ... xi}. Each message sample consists of different attribute values, that is, x1 = {c11, c21, ... ci1}. In the e-commerce system, the decision sample set D corresponding to the scenario classification is {d1, d2, ... di}. Scenario classification may include: placing an order, modifying an order, querying an order, confirming an order, etc.

[0128] Data preprocessing includes steps such as sample set division, invalid data elimination, noise data elimination and setting rules for decision attribute sets.

[0129] Sample set division: The sample set is divided according to the request call chain ID. The data information belonging to the same request call chain ID is the same sample.

[0130] Invalid data elimination: Interface traffic requests that cannot be successfully divided into sample sets will be eliminated.

[0131] Noise data removal: According to the noise data rules, the sample set is processed and the noise data is removed.

[0132] The classification algorithm is implemented using fuzzy rough set technology. According to the concept of upper and lower approximation of fuzzy rough set, the boundary domain of fuzzy concept X in fuzzy rough set can be defined as follows:

[0133]

[0134] Therefore, the uncertainty calculation formula of concept X in feature subset P is defined as follows:

[0135]

[0136] From the above, we can see that the total uncertainty degree of all concepts based on the fuzzy equivalence relationship between the attribute set P and the attribute Q on the domain U is:

[0137]

[0138] The fuzzy rough set technology is used to implement the solution of the embodiment of the present invention. The algorithm flow is as follows:

[0139] Step 01: For each target attribute, calculate the certainty value 1-ρ between each message sample xi{c1i,c2i,…cii} and the decision sample C(D). For each target attribute, calculate the certainty value of the target attribute in the message sample and the value in the decision sample, and construct the similarity matrix of the message sample. The following table is an example of a similarity matrix of a message sample.

[0140] Table 1 Similarity matrix example of message samples

[0141] Kd InF header Rep Scene Classification 0.01 0.8 0.75 0.85 Od 0.01 0.01 0.3 0.02 Md 0.01 0 0.1 0.01 QUR

[0142] As shown in Table 1, kd represents the request call chain ID, InF represents the interface information, header represents the request header, and Req represents the request parameters. Od corresponds to the order placement scenario classification, Md corresponds to the order modification scenario classification, and Qy corresponds to the order query scenario classification.

[0143] According to the similarity matrix, the scene classification to which the message sample belongs is determined. For the decision samples corresponding to each scene classification, the statistical value of the certainty degree value corresponding to each target attribute can be used as the correlation degree value between the message sample and the decision sample. The statistical value can be the mean, mode, maximum value, etc.

[0144] For the message sample shown in Table 1, when the statistical value is the mean, it can be calculated that the correlation value between the message sample and the decision sample of the order scenario classification (Od) is 0.6, the correlation value between the message sample and the decision sample of the order modification scenario classification (Md) is 0.085, and the correlation value between the message sample and the decision sample of the order query scenario classification (Qy) is 0.03. Therefore, the scenario classification to which the message sample belongs is the order scenario classification, and the keyword Od is marked for the message sample. Repeat the above algorithm process for other message samples to obtain the scenario classification corresponding to all interface request messages.

[0145] Step 02: According to the interface message keywords and scenario configuration rules, the automation scenario is automatically assembled to group multiple related interface request messages into a request group. Request grouping can be performed based on the configured rule information, such as a unique primary key such as the order number.

[0146] Step 03: Determine the calling order of the request messages in the request group based on the call chain tracking technology. Since the traceId of the interface called earlier is smaller, the interface request messages in the group can be sorted by traceId from small to large. The sorted scenario is the user's real operation scenario, and a test case is generated.

[0147] Step 04: Set the external parameters in the call configuration library, such as the execution environment, interface call interval, etc., call the test cases corresponding to each request group, and perform interface testing on the target system. The test case is a simulation of the user's operation scenario.

[0148] The solution of the embodiment of the present invention can solve the pain point that the prior art can only simulate independent interface units but cannot simulate real online business. For example, for order modification business, the actual business scenario is: first generate an order through the order interface, and then modify the order. In the existing solution, since the real business scenario cannot be identified, when verifying the order modification business, the modification interface may be called first, and then the order interface may be called, resulting in failure of automated execution. The test case generated by this solution is a simulation of the user operation scenario, which can ensure the validity and authenticity of the test case.

[0149] Figure 5 FIG. 1 is a schematic diagram of the structure of an interface testing device provided by an embodiment of the present invention. Figure 5 As shown, the device comprises:

[0150] The message collection module 501 is used to collect multiple interface request messages of the target system within the statistical period;

[0151] The message marking module 502 is used to classify multiple interface request messages by scenario, and mark each interface request message according to the scenario classification to which each interface request message belongs;

[0152] A message grouping module 503, used for dividing a plurality of interface request messages into a plurality of request groups;

[0153] The use case generation module 504 is used to determine, for each request group, the scene call sequence of each scene classification corresponding to the request group; determine the scene classification to which each interface request message in the request group belongs according to the mark in the interface request message; assemble each interface request message in the request group according to the scene call sequence and the scene classification to which each interface request message in the request group belongs, and generate a test case corresponding to the request group;

[0154] The interface testing module 505 is used to perform interface testing on the target system using the test cases corresponding to each request group.

[0155] Optionally, the message marking module 502 is specifically configured to:

[0156] Determine a current interface request message from multiple interface request messages;

[0157] Determine the message attribute value corresponding to each target attribute of the current interface request message;

[0158] Combine the attribute values ​​of each message to generate a message sample corresponding to the current interface request message;

[0159] Determine the decision samples corresponding to each scene classification, where the decision samples are generated by combining the decision attribute values ​​corresponding to each target attribute of the scene classification;

[0160] Respectively determine the correlation value between the message sample and each decision sample;

[0161] According to the correlation degree values ​​between the message sample and each decision sample, the scenario classification to which the current interface request message belongs is determined.

[0162] Optionally, the message marking module 502 is specifically configured to:

[0163] Determine a current scene classification from multiple scene classifications;

[0164] Determine the current decision sample corresponding to the current scene classification;

[0165] For each target attribute, determine the current decision value of the current decision sample corresponding to the target attribute; calculate the certainty value between the message attribute value corresponding to the target attribute and the current decision value;

[0166] According to the certainty degree value between the message attribute value corresponding to each target attribute and the current decision value, the correlation degree value between the message sample and the current decision sample is determined.

[0167] Optionally, the message marking module 502 is specifically configured to:

[0168] Obtain the mapping relationship between keywords and scene classifications;

[0169] Determine a current interface request message from multiple interface request messages;

[0170] Traversing the current interface request message to determine whether the current interface request message contains a target keyword, where the target keyword is a keyword contained in the mapping relationship;

[0171] In response to the target keyword being included in the current interface request message, determining a target scene classification corresponding to the target keyword according to a mapping relationship;

[0172] Classify the current interface message into the target scenario classification.

[0173] Optionally, the use case generation module 504 is specifically used for:

[0174] On the target page, display the scene categories corresponding to the request grouping;

[0175] Receive a drag operation for the displayed scene classification;

[0176] According to the drag operation, adjust the display position of the displayed scene classification in the target page;

[0177] According to the display position of each scene classification corresponding to the request group in the target page, the scene calling order of each scene classification corresponding to the request group is determined.

[0178] Optionally, the use case generation module 504 is specifically used for:

[0179] Determine a tracking identifier corresponding to each interface request message in the request group, where the tracking identifier is used to represent the calling order of the interface request message;

[0180] According to the tracking identifiers corresponding to the interface request messages in the request group and the scene categories to which they belong, the scene call order of each scene category corresponding to the request group is determined.

[0181] Optionally, the use case generation module 504 is specifically used for:

[0182] According to the scene calling sequence and the scene classification to which each interface request message in the request group belongs, assemble each interface request message in the request group to generate an assembly use case corresponding to the request group;

[0183] identifying at least one parameter to be replaced in the assembly use case;

[0184] Extract the replacement value corresponding to each parameter to be replaced from the test document;

[0185] Replace each parameter to be replaced in the assembly case with its corresponding replacement value, and generate a test case corresponding to the request group.

[0186] An embodiment of the present invention provides an electronic device, including:

[0187] one or more processors;

[0188] a storage device for storing one or more programs,

[0189] When one or more programs are executed by one or more processors, the one or more processors implement the method of any of the above embodiments.

[0190] Reference below Figure 6 , which shows a schematic diagram of the structure of a computer system 600 of a terminal device suitable for implementing an embodiment of the present invention. Figure 6 The terminal device shown is only an example and should not bring any limitation to the functions and scope of use of the embodiments of the present invention.

[0191] like Figure 6As shown, the computer system 600 includes a central processing unit (CPU) 601, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 602 or a program loaded from a storage part 608 into a random access memory (RAM) 603. In the RAM 603, various programs and data required for the operation of the system 600 are also stored. The CPU 601, the ROM 602, and the RAM 603 are connected to each other via a bus 604. An input / output (I / O) interface 605 is also connected to the bus 604.

[0192] The following components are connected to the I / O interface 605: an input section 606 including a keyboard, a mouse, etc.; an output section 607 including a cathode ray tube (CRT), a liquid crystal display (LCD), etc., and a speaker, etc.; a storage section 608 including a hard disk, etc.; and a communication section 609 including a network interface card such as a LAN card, a modem, etc. The communication section 609 performs communication processing via a network such as the Internet. A drive 610 is also connected to the I / O interface 605 as needed. A removable medium 611, such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, etc., is installed on the drive 610 as needed, so that a computer program read therefrom is installed into the storage section 608 as needed.

[0193] In particular, according to the embodiments disclosed in the present invention, the process described above with reference to the flowchart can be implemented as a computer software program. For example, the embodiments disclosed in the present invention include a computer program product, which includes a computer program carried on a computer-readable medium, and the computer program includes a program code for executing the method shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from the network through the communication part 609, and / or installed from the removable medium 611. When the computer program is executed by the central processing unit (CPU) 601, the above-mentioned functions defined in the system of the present invention are executed.

[0194] It should be noted that the computer-readable medium shown in the present invention may be a computer-readable signal medium or a computer-readable storage medium or any combination of the above two. The computer-readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, device or device, or any combination of the above. More specific examples of computer-readable storage media may include, but are not limited to: an electrical connection with one or more wires, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above. In the present invention, a computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in combination with an instruction execution system, device or device. In the present invention, a computer-readable signal medium may include a data signal propagated in a baseband or as part of a carrier wave, which carries a computer-readable program code. This propagated data signal may take a variety of forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination of the above. Computer-readable signal media may also be any computer-readable medium other than computer-readable storage media, which may send, propagate or transmit a program for use by or in conjunction with an instruction execution system, apparatus or device. The program code contained on the computer-readable medium may be transmitted using any appropriate medium, including but not limited to: wireless, wire, optical cable, RF, etc., or any suitable combination of the above.

[0195] The flow chart and block diagram in the accompanying drawings illustrate the possible architecture, function and operation of the system, method and computer program product according to various embodiments of the present invention. In this regard, each box in the flow chart or block diagram can represent a module, a program segment, or a part of a code, and the above-mentioned module, program segment, or a part of a code contains one or more executable instructions for realizing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the box can also occur in a different order from the order marked in the accompanying drawings. For example, two boxes represented in succession can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each box in the block diagram or flow chart, and the combination of the boxes in the block diagram or flow chart can be implemented with a dedicated hardware-based system that performs a specified function or operation, or can be implemented with a combination of dedicated hardware and computer instructions.

[0196] The modules involved in the embodiments of the present invention may be implemented by software or hardware. The modules described may also be arranged in a processor, for example, they may be described as: a message collection module, a message marking module, a message grouping module, a use case generation module, and an interface testing module. The names of these modules do not constitute a limitation on the modules themselves in certain circumstances, for example, the message collection module may also be described as a "module for collecting multiple interface request messages of the target system within a statistical period".

[0197] As another aspect, the present invention further provides a computer-readable medium, which may be included in the device described in the above embodiment; or may exist independently without being assembled into the device. The above computer-readable medium carries one or more programs, and when the above one or more programs are executed by a device, the device includes:

[0198] Collect multiple interface request messages of the target system within the statistical period;

[0199] Classifying the multiple interface request messages by scenario, and marking each of the interface request messages according to the scenario classification to which each of the interface request messages belongs;

[0200] Dividing the multiple interface request messages into multiple request groups;

[0201] For each of the request groups, determine the scene call order of each scene classification corresponding to the request group; determine the scene classification to which each interface request message in the request group belongs according to the mark in the interface request message; assemble each interface request message in the request group according to the scene call order and the scene classification to which each interface request message in the request group belongs, and generate a test case corresponding to the request group;

[0202] The interface test of the target system is performed using the test cases corresponding to the request groups.

[0203] According to the technical solution of an embodiment of the present invention, the multiple interface request messages of the collected target system are scene-classified and marked. The multiple interface request messages are divided into multiple request groups. The request group corresponds to a group of interface request messages involved in the continuous operation process of the user, that is, a group of interface request messages for full-link operations. Determine the scene call order of each scene classification corresponding to the request group. According to the mark in the interface request message, determine the scene classification to which each interface request message belongs. According to the scene call order and the scene classification to which each interface request message in the request group belongs, assemble each interface request message in the request group, generate a test case corresponding to the request group, and complete the interface test of the target system.

[0204] Since the request grouping corresponds to a group of interface request messages of the user's full-link operation, the test cases generated based on the request grouping can perform full-link interface testing according to the user's actual operation conditions, making the test scope of the interface test more comprehensive.

[0205] The above specific implementations do not constitute a limitation on the protection scope of the present invention. It should be understood by those skilled in the art that various modifications, combinations, sub-combinations and substitutions may occur depending on design requirements and other factors. Any modification, equivalent substitution and improvement made within the spirit and principle of the present invention shall be included in the protection scope of the present invention.

Claims

1. An interface testing method, characterized in that: include: Collect multiple interface request messages of the target system within the statistical period; Classifying the multiple interface request messages by scenario, and marking each of the interface request messages according to the scenario classification to which each of the interface request messages belongs; Dividing the multiple interface request messages into multiple request groups; For each of the request groups, determining a scene calling order of each scene classification corresponding to the request group; Determining, according to the tag in the interface request message, the scene classification to which each interface request message in the request group belongs; Assembling the interface request messages in the request group according to the scenario calling sequence and the scenario classification to which the interface request messages in the request group belong, and generating a test case corresponding to the request group; The interface test of the target system is performed using the test cases corresponding to the request groups.

2. The method according to claim 1, characterized in that The performing scenario classification on the multiple interface request messages includes: Determining a current interface request message from the multiple interface request messages; Determine the message attribute value of each target attribute corresponding to the current interface request message; Combining the message attribute values ​​to generate a message sample corresponding to the current interface request message; Determine a decision sample corresponding to each of the scene classifications, wherein the decision sample is generated by combining the decision attribute values ​​of the scene classifications corresponding to each of the target attributes; Respectively determining the correlation value between the message sample and each of the decision samples; The scenario classification to which the current interface request message belongs is determined according to the correlation degree values ​​between the message sample and each of the decision samples.

3. The method according to claim 2, characterized in that The respectively determining the correlation value between the message sample and each of the decision samples comprises: Determining a current scene classification from the plurality of scene classifications; Determine a current decision sample corresponding to the current scene classification; For each of the target attributes, determine the current decision value of the current decision sample corresponding to the target attribute; calculate the certainty value between the message attribute value corresponding to the target attribute and the current decision value; According to the certainty degree value between the message attribute value corresponding to each of the target attributes and the current decision value, the correlation degree value between the message sample and the current decision sample is determined.

4. The method according to claim 1, characterized in that: The performing scenario classification on the multiple interface request messages includes: Obtain the mapping relationship between keywords and scene classifications; Determining a current interface request message from the multiple interface request messages; Traversing the current interface request message, determining whether the current interface request message contains a target keyword, the target keyword being a keyword contained in the mapping relationship; In response to the current interface request message containing the target keyword, determining a target scene classification corresponding to the target keyword according to the mapping relationship; The current interface message is classified into the target scenario classification.

5. The method according to claim 1, characterized in that The determining the scene calling order of each scene classification corresponding to the request group includes: On the target page, the scene categories corresponding to the request group are displayed; Receive a drag operation for the displayed scene classification; According to the dragging operation, adjusting the display position of the displayed scene classification in the target page; The scene calling order of each scene classification corresponding to the request group is determined according to the display position of each scene classification corresponding to the request group in the target page.

6. The method according to claim 1, characterized in that The determining the scene calling order of each scene classification corresponding to the request group includes: Determine a tracking identifier corresponding to each interface request message in the request group, wherein the tracking identifier is used to represent a calling order of the interface request message; According to the tracking identifiers corresponding to the interface request messages in the request group and the scene categories to which they belong, the scene calling order of the scene categories corresponding to the request group is determined.

7. The method according to claim 1, characterized in that The step of assembling the interface request messages in the request group according to the scenario calling sequence and the scenario classification to which the interface request messages in the request group belong, and generating a test case corresponding to the request group includes: Assembling the interface request messages in the request group according to the scene calling sequence and the scene classification to which the interface request messages in the request group belong, and generating an assembly use case corresponding to the request group; identifying at least one parameter to be replaced in the assembly use case; Extracting replacement values ​​corresponding to the parameters to be replaced from the test document; Each of the parameters to be replaced in the assembly case is replaced with its corresponding replacement value to generate a test case corresponding to the request group.

8. An interface testing device, characterized in that: include: A message collection module is used to collect multiple interface request messages of the target system within a statistical period; A message marking module, used to classify the multiple interface request messages according to scenarios, and mark each of the interface request messages according to the scenario classification to which each of the interface request messages belongs; A message grouping module, used for dividing the plurality of interface request messages into a plurality of request groups; A use case generation module, used to determine, for each request group, a scene call sequence of each scene classification corresponding to the request group; Determining, according to the tag in the interface request message, the scene classification to which each interface request message in the request group belongs; Assembling the interface request messages in the request group according to the scenario calling sequence and the scenario classification to which the interface request messages in the request group belong, and generating a test case corresponding to the request group; The interface testing module is used to perform interface testing on the target system using the test cases corresponding to each of the request groups.

9. An electronic device, characterized in that: include: one or more processors; a storage device for storing one or more programs, When the one or more programs are executed by the one or more processors, the one or more processors implement the method according to any one of claims 1 to 7.

10. A computer readable medium having a computer program stored thereon, characterized in that: When the program is executed by a processor, the method according to any one of claims 1 to 7 is implemented.