Automatic generation method and device of test program and electronic equipment

Abstract

The invention provides an automatic generation method and device of a test program and electronic equipment. The method comprises the following steps: establishing a graph database corresponding to a total transaction process, wherein the total transaction process is composed of one or more to-be-tested transactions connected according to an execution sequence; a to-be-tested transaction name is obtained, a to-be-tested transaction process group is determined in the graph database according to the to-be-tested transaction name, the to-be-tested transaction name refers to the name of the current to-be-tested transaction in the total transaction process, and the to-be-tested transaction process group at least comprises one or more nodes corresponding to the to-be-tested transaction; a transaction message corresponding to the to-be-tested transaction process group is obtained, the transaction message is analyzed to obtain transaction information, a test program corresponding to the to-be-tested transaction process group is generated according to the transaction information, and the transaction information at least comprises a transaction code. According to the method and the device, the problem that the efficiency is low due to the fact that logic relations among multiple transaction steps need to be manually combed and a test program needs to be written in the prior art is solved.

Description

Technical Field

[0001] This application relates to the technical field of program testing. Specifically, it relates to a method, device, computer-readable storage medium, and electronic device for automatically generating a test program. Background Art

[0002] During the stress testing process, the stress test is initiated from the system dimension. Since a system consists of many transactions, and there are dependencies between these transactions. For example, a transaction includes the following steps: obtaining a token, creating a reservation order, initializing the reservation order, obtaining a signature, handling immediately, submitting or sending an instruction or hanging up. During the test execution, if testing the transaction step "obtaining a signature", it requires the token field of the "obtaining a token" transaction, the reservation order number of the "creating a reservation order" transaction, and the signature of the "initializing the reservation order" transaction. Because the transactions are complex, each transaction has more than 20 input parameters and output parameters during the debugging process. Manually sorting out these transactions requires more than 100 sorts. If it is the most basic-level transaction, such as "submitting", "sending an instruction", "hanging up" transactions, there are more pre-dependent transactions, and the input and output parameters involved also increase exponentially.

[0003] Therefore, for multiple transactions with dependencies, there are many input and output parameters involved when writing stress test scripts and conducting stress tests. And for each additional level of dependency, the increased parameters grow exponentially. In this process, a lot of dependency relationships need to be manually sorted out and the scripts need to be continuously debugged, involving a large amount of manual operations and wasting a lot of time, and relying on specific testers. Summary of the Invention

[0004] The main purpose of this application is to provide a method, device, computer-readable storage medium, and electronic device for automatically generating a test program, so as to at least solve the problem of low efficiency in manually sorting out the logical relationships between multiple transaction steps and writing a test program in the prior art.

[0005] To achieve the above object, according to one aspect of the present application, a method for automatically generating a test program is provided, including: establishing a graph database corresponding to the overall transaction process, where the overall transaction process is composed of one or more to-be-tested transactions connected in the execution order, the graph database includes one or more nodes and the connection relationships between the nodes, and each of the nodes corresponds to one of the to-be-tested transactions; obtaining the name of the to-be-tested transaction, and determining a to-be-tested transaction process group in the graph database according to the name of the to-be-tested transaction, where the name of the to-be-tested transaction refers to the name of the current to-be-tested transaction in the overall transaction process, and the to-be-tested transaction process group includes at least one or more nodes corresponding to the to-be-tested transactions; obtaining the transaction message corresponding to the to-be-tested transaction process group, parsing the transaction message to obtain transaction information, and generating a test program corresponding to the to-be-tested transaction process group according to the transaction information, where the transaction information includes at least a transaction code.

[0006] Optionally, establishing a graph database corresponding to the overall transaction process includes: obtaining one or more of the to-be-tested transactions, determining the execution order of the to-be-tested transactions, generating the nodes corresponding to the to-be-tested transactions, and connecting the nodes according to the execution order; calculating the neighbor degrees of each of the nodes to the root node to obtain the graph database, where the neighbor degree is the number of nodes from each of the nodes to the root node.

[0007] Optionally, obtaining the name of the to-be-tested transaction and determining a to-be-tested transaction process group in the graph database according to the name of the to-be-tested transaction includes: determining whether there is a pre-transaction according to the name of the to-be-tested transaction, where the pre-transaction refers to a transaction whose execution order is before the to-be-tested transaction; in the case of the existence of the pre-transaction, starting from the current node corresponding to the to-be-tested transaction in the graph database, traversing backward to the root node of the current node, and determining each node from the root node to the current node and the corresponding to-be-tested transaction as the to-be-tested transaction process group; in the case of the non-existence of the pre-transaction, determining the current node and the to-be-tested transaction as the to-be-tested transaction process group.

[0008] Optionally, obtaining the transaction message corresponding to the to-be-tested transaction process group includes: obtaining the name of the to-be-tested transaction for each of the to-be-tested transactions in the to-be-tested transaction process group; obtaining the transaction message with the same name as the to-be-tested transaction name from the stress test server to obtain the transaction message corresponding to the to-be-tested transaction process group, where each of the to-be-tested transactions corresponds to one transaction message.

[0009] Optionally, the transaction information is obtained by parsing the transaction message, including: reading the target path and request fields of the transaction message, where the target path represents the path of the transaction message, and the request fields represent the fields corresponding to the information to be parsed; parsing the transaction message according to the target path and the request fields to obtain the transaction information.

[0010] Optionally, after generating the test program corresponding to the to-be-tested transaction process group according to the transaction information, the method further includes: extracting the input parameters and output parameters of the transaction message corresponding to each to-be-tested transaction in the to-be-tested transaction process group, and representing the input parameters and the output parameters in the form of key-value pairs, where both the input parameters and the output parameters include a parameter name and a data type; calculating the parameter name similarity and data type similarity between the input parameters and the output parameters, and determining the input parameters of the test program according to the parameter name similarity and the data type similarity, where the parameter name similarity represents the similarity of the parameter names, the data type similarity represents the similarity of the data types, and a similarity greater than a preset threshold indicates that the input parameters and the output parameters have a dependency relationship, and a similarity less than or equal to the preset threshold indicates that the input parameters and the output parameters have no dependency relationship.

[0011] Optionally, calculating the parameter name similarity and data type similarity between the input parameters and the output parameters, and determining the input parameters of the test program according to the parameter name similarity and the data type similarity includes: calculating the data type similarity between the output parameters corresponding to the current to-be-tested transaction and the input parameters corresponding to the next to-be-tested transaction; in the case where both the data type similarity and the parameter name similarity indicate that the output parameters and the input parameters have a dependency relationship, determining that the output parameters corresponding to the current to-be-tested transaction are the input parameters corresponding to the next to-be-tested transaction; in the case where the data type similarity and / or the parameter name similarity indicates that the output parameters and the input parameters have no dependency relationship, determining that the output parameters corresponding to the current to-be-tested transaction are not the input parameters corresponding to the next to-be-tested transaction.

[0012] According to another aspect of the present application, there is provided an apparatus for automatically generating a test program, including: a building unit configured to build a graph database corresponding to a total transaction process, wherein the total transaction process is composed of one or more to-be-tested transactions connected in an execution order, the graph database includes one or more nodes and connection relationships between the nodes, and each of the nodes corresponds to one of the to-be-tested transactions; a first determination unit configured to obtain a name of a to-be-tested transaction, and determine a to-be-tested transaction process group in the graph database according to the name of the to-be-tested transaction, wherein the name of the to-be-tested transaction refers to the name of the current to-be-tested transaction in the total transaction process, and the to-be-tested transaction process group includes at least one or more nodes corresponding to the to-be-tested transactions; a generating unit configured to obtain a transaction message corresponding to the to-be-tested transaction process group, parse the transaction message to obtain transaction information, and generate a test program corresponding to the to-be-tested transaction process group according to the transaction information, wherein the transaction information includes at least a transaction code.

[0013] According to yet another aspect of the present application, there is provided a computer-readable storage medium, which includes a stored program, wherein when the program runs, it controls a device where the computer-readable storage medium is located to execute any one of the methods for automatically generating a test program.

[0014] According to still another aspect of the present application, there is provided an electronic device, including: one or more processors, a memory, and one or more programs, wherein the one or more programs are stored in the memory and are configured to be executed by the one or more processors, and the one or more programs include those for executing any one of the methods for automatically generating a test program.

[0015] Applying the technical solution of the present application, a graph database corresponding to the overall transaction process is established, the name of the transaction to be tested is obtained, and the transaction process group to be tested is determined in the graph database according to the name of the transaction to be tested. The transaction process group to be tested includes at least one or more nodes corresponding to the transactions to be tested; the transaction message corresponding to the transaction process group to be tested is obtained, the transaction message is parsed to obtain transaction information, and a test program corresponding to the transaction process group to be tested is generated according to the transaction information. Compared with the prior art in which it is necessary to manually sort out the logical relationship between multiple transaction steps and write a test program with low efficiency, the present application first establishes a graph database of the overall transaction process, and automatically determines the transaction process group to be tested corresponding to the name of the transaction to be tested by means of the graph database, that is, determines the logical relationship between the transaction steps in the process group. Then, the corresponding transaction message is obtained and parsed to obtain transaction information, and then the transaction information is used to generate a test program. The test program generated in this way is a test program generated according to the logical relationship between the actual transaction steps, and there is no need to manually perform logical sorting and program writing, which improves the test efficiency. Therefore, it can solve the problem of low efficiency in manually sorting out the logical relationship between multiple transaction steps and writing a test program in the prior art, and achieve the effect of improving the test efficiency. BRIEF DESCRIPTION OF THE DRAWINGS

[0016] The accompanying drawings forming a part of this application are used to provide a further understanding of the application. The illustrative embodiments and descriptions thereof of the application are used to explain the application and do not constitute an improper limitation of the application. In the drawings:

[0017] Figure 1 The hardware structure block diagram of a mobile terminal for implementing an automatic generation method of a test program provided by an embodiment of the present application is shown;

[0018] Figure 2 The flowchart of an automatic generation method of a test program provided by an embodiment of the present application is shown;

[0019] Figure 3 The flowchart of an overall transaction process provided by an embodiment of the present application is shown;

[0020] Figure 4 The flowchart of a specific automatic generation method of a test program provided by an embodiment of the present application is shown;

[0021] Figure 5 The structure block diagram of an automatic generation device of a test program provided by an embodiment of the present application is shown.

[0022] Among them, the above-mentioned accompanying drawings include the following reference numerals:

[0023] 102. Processor; 104. Memory; 106. Transmission device; 108. Input / output device. Detailed Implementation Manner

[0024] It should be noted that, without conflict, the embodiments in the present application and the features in the embodiments can be combined with each other. The present application will be described in detail below with reference to the accompanying drawings and in combination with the embodiments.

[0025] In order to enable those skilled in the art to better understand the solution of the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings in the embodiments of the present application. Obviously, the described embodiments are only a part of the embodiments of the present application, rather than all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without making creative efforts shall fall within the protection scope of the present application.

[0026] It should be noted that the terms "first", "second", etc. in the specification and claims of the present application and the above-mentioned drawings are used to distinguish similar objects, and do not necessarily need to be used to describe a specific order or sequence. It should be understood that such data can be interchanged under appropriate circumstances for the embodiments of the present application described herein. In addition, the terms "comprising" and "having" and any variations thereof are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or device that includes a series of steps or units does not necessarily need to be limited to those steps or units clearly listed, but may include other steps or units not clearly listed or inherent to these processes, methods, products, or devices.

[0027] For the convenience of description, some terms and nouns involved in the present application will be explained below:

[0028] TF-IDF: Term Frequency-Inverse Document Frequency, abbreviated as TF-IDF. It is a statistical method widely used in information retrieval and text mining, and is used to evaluate the importance of a word in a document.

[0029] Cosine Similarity: It is a similarity calculation method used to measure the cosine value of the angle between two non-zero vectors, and is usually used in fields such as text analysis, information retrieval, and recommendation systems to evaluate the similarity between documents or vectors. The core idea of this method is to compare the cosine value of the included angle between two vectors. The closer the cosine value is to 1, the more similar the two vectors are; the closer it is to 0, the less similar they are.

[0030] As introduced in the background art, in the prior art, it is inefficient to manually sort out the logical relationships between multiple transaction steps and write test programs. To solve the problem of low efficiency in manually sorting out the logical relationships between multiple transaction steps and writing test programs, embodiments of the present application provide an automatic generation method, device, computer-readable storage medium, and electronic device for test programs.

[0031] Next, the technical solutions in the embodiments of the present invention will be clearly and completely described with reference to the accompanying drawings in the embodiments of the present invention.

[0032] The method embodiments provided in the embodiments of the present application can be executed on a mobile terminal, a computer terminal, or a similar computing device. Taking running on a mobile terminal as an example, Figure 1 is a hardware structure block diagram of a mobile terminal for an automatic generation method of a test program according to an embodiment of the present invention. As Figure 1 shown, the mobile terminal may include one or more ( Figure 1 only one is shown in the figure) processors 102 (the processors 102 may include, but are not limited to, processing devices such as a microprocessor MCU or a field programmable gate array FPGA) and a memory 104 for storing data. Among them, the above mobile terminal may further include a transmission device 106 for communication functions and an input / output device 108. Those of ordinary skill in the art can understand that Figure 1 the structure shown is only schematic and does not limit the structure of the above mobile terminal. For example, the mobile terminal may further include more or fewer components than Figure 1 shown in the figure, or have a different configuration from Figure 1 shown in the figure.

[0033] The memory 104 can be used to store computer programs, such as software programs and modules of application software, such as the computer program corresponding to the method for automatically generating a test program in an embodiment of the present invention. The processor 102 executes various functional applications and data processing by running the computer program stored in the memory 104, that is, the above-mentioned method is implemented. The memory 104 may include a high-speed random access memory, and may also include a non-volatile memory, such as one or more magnetic storage devices, flash memories, or other non-volatile solid-state memories. In some instances, the memory 104 may further include a memory remotely disposed relative to the processor 102, and these remote memories may be connected to the mobile terminal through a network. Examples of the above network include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof. The transmission device 106 is used to receive or send data via a network. A specific example of the above network may include a wireless network provided by a communication provider of the mobile terminal. In one instance, the transmission device 106 includes a network adapter (Network Interface Controller, abbreviated as NIC), which can be connected to other network devices through a base station and thus can communicate with the Internet. In one instance, the transmission device 106 may be a radio frequency (RF) module, which is used to communicate with the Internet wirelessly.

[0034] In this embodiment, a method for automatically generating a test program running on a mobile terminal, a computer terminal, or a similar computing device is provided. It should be noted that the steps shown in the flowchart of the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions, and although the logical order is shown in the flowchart, in some cases, the steps shown or described can be executed in a different order than here.

[0035] Figure 2 It is a flowchart of the method for automatically generating a test program according to an embodiment of the present application. As Figure 2 shown, the method includes the following steps:

[0036] Step S201, establish a graph database corresponding to the overall transaction process, where the overall transaction process is composed of one or more to-be-tested transactions connected in an execution order, the graph database includes one or more nodes and the connection relationships between the nodes, and each node corresponds to one of the to-be-tested transactions;

[0037] Specifically, first, design and construct a graph database, and construct the overall transaction process of the business into a graph structure according to its execution logical relationship. The overall transaction process is as Figure 3As shown in the figure, it includes: obtaining a token, creating a reservation form, initializing the reservation form, obtaining a signature, handling immediately, submitting or sending an instruction or hanging up. Each business transaction is regarded as a node in the figure, and the nodes are connected by edges, indicating the direct dependency relationship between transactions. For example, the "obtaining a token" transaction can be regarded as a node in the figure, and the directly connected "creating a reservation form" transaction is regarded as another node, connected by an edge representing the dependency relationship. This design of the graph database can intuitively display the connectivity between business transactions, facilitating subsequent process analysis and script generation. By transforming the business transaction relationship into the node and edge relationship in the graph database, the visualization and understanding degree of the transaction process are improved, the process of sorting out the transaction dependency relationship is simplified, and the time and error rate of manual sorting are reduced. This is because the graph database can intuitively display the hierarchy and association between all transactions, and testers or systems can easily read and understand the process from the graph structure without manually checking the dependency relationship of each transaction one by one.

[0038] Step S202: Obtain the name of the transaction to be tested, and determine the transaction process group to be tested in the graph database according to the name of the transaction to be tested. Herein, the name of the transaction to be tested refers to the name of the current transaction to be tested in the total transaction process, and the transaction process group to be tested includes at least one or more nodes corresponding to the transaction to be tested.

[0039] Specifically, the transaction name is matched with the nodes in the graph database to confirm the existence of the transaction. Then, the system will start from this transaction and traverse the entire graph database in reverse to find all the nodes of the previous transactions, output them in reverse order, and form the transaction process group to be tested. For example, if the input is the "obtaining a signature" transaction, the system will traverse the graph database, find the previous transactions such as "initializing the reservation form", "creating a reservation form", and "obtaining a token", arrange them in reverse order, and form a complete transaction process group to be tested. By automatically obtaining and determining the transaction process group, the preparation time and complexity before writing the test script are significantly reduced. This is because the system can automatically identify and collect all necessary previous transactions, avoiding the cumbersome work of testers manually searching and sorting out the transaction process group one by one. At the same time, the reverse output strategy ensures the correct execution order of the transaction process, improving the test accuracy and efficiency.

[0040] Step S203: Obtain the transaction message corresponding to the transaction process group to be tested, parse the transaction message to obtain transaction information, and generate a test program corresponding to the transaction process group to be tested according to the transaction information. Herein, the transaction information includes at least the transaction code.

[0041] Specifically, obtain the transaction messages of each transaction in the transaction process group to be tested from the stress test server. The transaction messages can be JSON messages. These messages contain the complete information of the transaction, including the transaction code, request path, request fields, etc. The system reads the messages, parses the headers and message bodies therein, and then generates corresponding test programs using this transaction information. The test programs can be JMX test scripts. For example, for the "obtain signature" transaction, the system will read its JSON message, parse out information such as the transaction code, request path, and request fields, and generate a JMX script for the "obtain signature" transaction. Automatically generating test scripts using transaction messages greatly improves the speed and accuracy of script generation. This is because the system directly extracts information from real transaction messages, avoiding errors and omissions that may occur when manually writing scripts, and can quickly generate scripts, reducing the time consumption in the test preparation stage. This method ensures a high degree of fit between the test script and the actual transaction scenario, improving the effectiveness and pertinence of the stress test.

[0042] Through this embodiment, a graph database corresponding to the total transaction process is established, the name of the transaction to be tested is obtained, and the transaction process group to be tested is determined in the graph database according to the name of the transaction to be tested. The transaction process group to be tested includes at least one or more nodes corresponding to the transactions to be tested; obtain the transaction messages corresponding to the transaction process group to be tested, parse the transaction messages to obtain transaction information, and generate a test program corresponding to the transaction process group to be tested according to the transaction information. Compared with the prior art where it is inefficient to manually sort out the logical relationships between multiple transaction steps and write test programs, this application first establishes a graph database of the total transaction process, and automatically determines the transaction process group to be tested corresponding to the name of the transaction to be tested with the help of the graph database, that is, determines the logical relationships between the various transaction steps in the process group. Then, the corresponding transaction messages are obtained and parsed to obtain transaction information, and then the transaction information is used to generate a test program. In this way, the generated test program is a test program generated according to the logical relationships between the actual transaction steps, and there is no need to manually sort out the logic and write the program, improving the test efficiency. Therefore, it can solve the problem of low efficiency in manually sorting out the logical relationships between multiple transaction steps and writing test programs in the prior art, and achieve the effect of improving the test efficiency.

[0043] In the specific implementation process, the above step S201 can be implemented through the following steps: Step S2011: Obtain one or more of the to-be-tested transactions, determine the execution order of the to-be-tested transactions, generate the nodes corresponding to the to-be-tested transactions, and connect the nodes according to the execution order; Step S2012: Calculate the neighbor degrees of each of the nodes and the root node to obtain the graph database, where the neighbor degree is the number of nodes from each of the nodes to the root node. This method calculates the neighbor degrees, which can automatically analyze and organize the dependency relationships of each transaction step, avoiding the manual process of sorting out and understanding the transaction process, and improving the accuracy and efficiency of stress test script generation.

[0044] Specifically, obtain one or more of the to-be-tested transactions, determine the execution order of the to-be-tested transactions, generate the nodes corresponding to the to-be-tested transactions, and connect the nodes according to the execution order. This process is essentially mapping the logical relationships of business transactions to the nodes and edges in the graph database. The system first identifies all the to-be-tested transactions, and then establishes the dependency relationships between the transactions according to the order of transaction execution. For example, "create a reservation order" can only be executed after "obtain a token", and these two transactions are represented as an edge from the "obtain a token" node to the "create a reservation order" node, clearly defining the dependency level between the transactions. The calculation of the neighbor degree mainly traverses all the nodes in the graph database to determine the distance between each node and the root node, that is, how many nodes are passed through to reach. For example, the "obtain a token" transaction can be used as the root node, then the neighbor degree of the "create a reservation order" transaction is 1, and the neighbor degree of the "reservation order initialization" transaction is 2, and so on. This setting of the neighbor degree helps the system to automatically identify the transaction order and transaction logic that need to be executed when generating the script in the subsequent process, avoiding the complexity of manual adjustment and configuration.

[0045] In some embodiments, the above step S202 can be specifically implemented through the following steps: Step S2021: Determine whether there is a pre-transaction according to the name of the to-be-tested transaction, where the pre-transaction refers to the transaction whose execution order is before the to-be-tested transaction; Step S2022: In the case where there is a pre-transaction, starting from the current node corresponding to the to-be-tested transaction in the graph database, traverse backward to the root node of the current node, and determine each node from the root node to the current node and the corresponding to-be-tested transaction as the to-be-tested transaction process group; Step S2023: In the case where there is no pre-transaction, determine the current node and the to-be-tested transaction as the to-be-tested transaction process group. By automatically determining the to-be-tested transaction process group, it avoids the complexity of testers manually searching for and arranging the transaction process, and greatly shortens the test preparation time.

[0046] Specifically, it is determined whether there is a pre - transaction according to the name of the transaction to be tested. If there is a pre - transaction, the system starts from the current transaction node and traverses the entire transaction process in reverse until it reaches the root node, and determines the transactions corresponding to all nodes on this path as the transaction process group to be tested. For example, if the transaction to be tested is "obtain signature", the system will identify its pre - transactions as "appointment order initialization", "create appointment order" and "obtain token", and automatically add these transactions to the process group and output them in reverse order. If there is no pre - transaction, it means that the current transaction is independent or the starting point of the process, then the system directly determines this transaction as the transaction process group to be tested. The reverse - order output strategy ensures that the execution order of the transactions in the process group is consistent with the actual business process, improving the accuracy and reliability of the test script. In the case of no pre - transaction, the system can quickly identify and locate independent transactions, further optimizing the script generation process.

[0047] In some other alternative embodiments, the above - mentioned step S203 of obtaining the transaction message corresponding to the transaction process group to be tested can be implemented through the following steps: Step S2031: Obtain the name of the transaction to be tested for each transaction to be tested in the transaction process group to be tested; Step S2032: Obtain the transaction message with the same name as the transaction to be tested from the stress - testing server, and obtain the transaction message corresponding to the transaction process group to be tested, where each transaction to be tested corresponds to one transaction message. This method can ensure that the generated test script is based on real business data by directly obtaining the transaction message from the server, improving the accuracy and effectiveness of the test. Automatically obtaining the message eliminates the steps of manually searching for and copying the message, saving time and avoiding data input errors, ensuring the efficiency and quality of script generation.

[0048] Specifically, the json messages of the transactions to be tested are pre - placed on the stress - testing server and the above - mentioned messages to be tested are named after the transaction names. Therefore, the transaction message with the same name as the transaction to be tested is directly obtained from the stress - testing server for generating the test script. In this process, the system will read the transaction names in the transaction process group to be tested one by one, and then search for the transaction message matching this name on the server. For example, for the "appointment order initialization" transaction in the process group, the system will read in its name and search for the corresponding json message on the stress - testing server.

[0049] In some alternative embodiments, the step S203 of parsing the transaction message to obtain transaction information can be implemented through the following steps: Step S2033: Read the target path and request fields of the transaction message, where the target path represents the path of the transaction message, and the request fields represent the fields corresponding to the information to be parsed; Step S2034: Parse the transaction message according to the target path and the request fields to obtain the transaction information. This method avoids the cumbersome manual check of each message item by automated parsing, improves the data processing speed, and at the same time reduces data errors caused by human negligence, ensuring the accuracy and reliability of the generated script.

[0050] Specifically, the system reads the target path and request fields of the transaction message and parses to obtain transaction information. This process involves in-depth parsing of the transaction message to identify the key paths and fields therein. For example, for the json message of the "reservation form initialization" transaction, the system will parse out important information such as its request path, request header information, all fields and their types in the message body, providing a data basis for generating test scripts. By accurately parsing the transaction message, the key information of the transaction can be accurately extracted, including but not limited to the transaction code, request path, and fields, etc., providing accurate data support for subsequent generation of test scripts.

[0051] In some alternative embodiments, the above method further includes step S204: After generating the test program corresponding to the to-be-tested transaction process group according to the transaction information, extract the input parameters and output parameters of the transaction message corresponding to each to-be-tested transaction in the to-be-tested transaction process group, and represent the input parameters and the output parameters in the form of key-value pairs, where both the input parameters and the output parameters include a parameter name and a data type; Step S205: Calculate the parameter name similarity and data type similarity between the input parameters and the output parameters, and determine the input parameters of the test program according to the parameter name similarity and the data type similarity, where a similarity greater than a preset threshold indicates that the input parameters and the output parameters have a dependency relationship, and a similarity less than or equal to the preset threshold indicates that the input parameters and the output parameters have no dependency relationship. This method greatly reduces the workload of testers for manually verifying parameter dependencies through the above steps, improving the test efficiency.

[0052] Specifically, the system further extracts the input parameters and output parameters, represented in the form of key-value pairs, and then calculates the parameter name similarity and data type similarity. This calculation process is a comparison of the parameter names and data types in the previous and subsequent steps to determine the dependency relationship between the output parameters of the previous step and the input parameters of the subsequent step. For example, the system can identify that the output parameter "reservation order number" of the "reservation order initialization" transaction is similar in name and consistent in data type with the input parameter "reservation order number" of the "obtain signature" transaction, thereby determining that there is a direct dependency between the two, and taking the output parameter "reservation order number" of the "reservation order initialization" transaction as the input parameter of the "obtain signature" transaction. Otherwise, it is not used as the input parameter of the subsequent step. By automatically calculating the parameter similarity and type matching, the dependency of parameters between transactions can be intelligently identified, effectively avoiding errors in parameter references in the stress test script. The setting of the preset threshold ensures that only truly similar parameters are regarded as dependency relationships, improving the accuracy of the test script and the intelligence of automatically generating the script.

[0053] In some other alternative embodiments, step S205 can be implemented through the following steps. Step S2051: Calculate the data type similarity between the output parameters corresponding to the current transaction to be tested and the input parameters corresponding to the next transaction to be tested. Step S2052: When both the data type similarity and the parameter name similarity indicate that there is a dependency relationship between the output parameters and the input parameters, determine that the output parameters corresponding to the current transaction to be tested are the input parameters corresponding to the next transaction to be tested. Step S2053: When the data type similarity and / or the parameter name similarity indicate that there is no dependency relationship between the output parameters and the input parameters, determine that the output parameters corresponding to the current transaction to be tested are not the input parameters corresponding to the next transaction to be tested. By combining the calculation of data type and parameter name similarity, this method can more accurately judge the dependency relationship between parameters, thereby correctly referencing parameters in the generated test script and avoiding invalid or incorrect parameter connections.

[0054] Specifically, calculate the data type similarity and parameter name similarity between the output parameters of the current transaction and the input parameters of the next transaction, and determine the dependency relationship between the parameters through these two indicators. For example, the output parameter "reservation order number" of the "reservation order initialization" transaction and the input parameter "reservation order number" of the "obtain signature" transaction both reach the preset threshold in terms of data type similarity and parameter name similarity. The system determines that there is a dependency relationship for the "reservation order number" and can reference the output result of the "reservation order initialization" transaction as the input of the "obtain signature" transaction in the generated test script. If the output parameter "version number" of the "reservation order initialization" transaction and the input parameter "signature method" of the "obtain signature" transaction are quite different in terms of data type and name, exceeding the preset threshold, it is determined that there is no dependency relationship between the two. In the specific implementation process, the TF-IDF combined with the Cosine Similarity method is used for the connection and replacement of dependent parameters, and the steps are as follows: (1) Obtain the original transaction message (including input parameters and output parameters), perform data preprocessing on the original transaction message, extract the input parameters and output parameters in the message in the form of KV (key-value pairs), and the data form after preprocessing can be as follows: "orderid: 1234 (int)", "status: success (string)", "customerNO: 0012345 (int)". In the data preprocessing stage, if camel case or underscores are used in the parameters, the field format is unified. (2) Calculate the similarity between the input parameters and output parameters to automatically confirm the dependency relationship between the output parameters and input parameters. The similarity calculation method used is the TF-IDF combined with the Cosine Similarity method, and the matching dimensions are "data type" and "name similarity". The input parameters and output parameters form a pair of comparison samples. Taking the input parameters as an example, calculate the term frequency of each parameter (TF (input parameter) = number of occurrences of the input parameter field / total number of input parameter fields), inverse document frequency (IDF = log(2 / number of occurrences of the input parameter field)), calculate TF-IDF (TF-IDF = TF * IDF), and construct a vector to calculate the cosine similarity According to the "data type" and "name similarity" dimensions, a cosine similarity value can be calculated respectively. The "data type" dimension has the right of prior veto. If the cosine similarity is 0, it means that there is no dependency relationship between the input parameter and the output parameter. If the cosine similarity of the "data type" is 1, then continue to calculate the cosine similarity value of the "name similarity". Sort the cosine similarities of the "name similarity" from largest to smallest, and take the largest value of the cosine similarity between the input parameter and the output parameter as the final result. If this value is less than 0.5 (preset threshold), it is discarded; otherwise, it is determined that there is a dependency relationship between the output parameter and the input parameter, and at the same time, change the input parameter to the output parameter in the jmx script.

[0055] In order to enable those skilled in the art to more clearly understand the technical solution of the present application, the implementation process of the method for automatically generating the test program of the present application will be described in detail below in conjunction with specific embodiments.

[0056] This embodiment relates to a specific method for automatically generating a test program. As Figure 4 shown, it includes the following steps:

[0057] Step S1: Start;

[0058] Step S2: Input the transaction name to be tested in the input module;

[0059] Step S3: Determine whether it is the first run. If so, execute Step S4. If not, run the corresponding script. The method for determining whether it is the first run is as follows: If the transaction is tested for the first time, it is named with "transaction name, 0". If the transaction is not tested for the first time, it is directly named with "transaction name". For example, if the library table information query transaction is tested for the first time, it is written into the input module in the form of "library table information query, 0". If it is not tested for the first time, it is directly named with "library table information query";

[0060] Step S4: Establish a graph database according to the logical relationship;

[0061] Step S5: Determine whether there is a pre-node according to the transaction name. If so, execute Step S6. If not, import the generation module (which can be software for generating scripts) and generate the corresponding single-transaction script under jmeter bin;

[0062] Step S6: Traverse the nodes to the root node and output the found transaction names in reverse order;

[0063] Step S7: Import the generation module to read the transaction name and generate the corresponding associated transaction script;

[0064] Step S8: Connect to the replacement module to replace the input and output parameters;

[0065] Step S9: End.

[0066] The embodiment of the present application also provides an apparatus for automatically generating a test program. It should be noted that the apparatus for automatically generating a test program in the embodiment of the present application can be used to execute the method for automatically generating a test program provided in the embodiment of the present application. This apparatus is used to implement the above embodiments and preferred implementation manners, and those that have been described will not be repeated. As used below, the term "module" can be a combination of software and / or hardware that can achieve a predetermined function. Although the apparatus described in the following embodiments is preferably implemented in software, implementation in hardware, or a combination of software and hardware is also possible and contemplated.

[0067] The following introduces the automatic generation device for the test program provided by the embodiments of the present application.

[0068] Figure 5 It is a schematic diagram of the automatic generation device for the test program according to the embodiments of the present application. As Figure 5 shown, the device includes:

[0069] A building unit 10, configured to build a graph database corresponding to the overall transaction process, where the overall transaction process is composed of one or more to-be-tested transactions connected in an execution order, the graph database includes one or more nodes and the connection relationships between the nodes, and each of the nodes corresponds to one of the to-be-tested transactions;

[0070] Specifically, first, design and construct a graph database, and construct the overall transaction process of the service into a graph structure according to its execution logic relationship. The overall transaction process is as Figure 3 shown, including: obtaining a token, creating a reservation form, initializing the reservation form, obtaining a signature, handling immediately, submitting or sending an instruction or hanging up. Each service transaction is regarded as a node in the graph, and the nodes are connected by edges, indicating the direct dependency relationship between the transactions. For example, the "obtaining a token" transaction can be regarded as a node in the graph, and the directly connected "creating a reservation form" transaction is regarded as another node, connected by an edge representing the dependency relationship. The design of this graph database can intuitively display the connectivity between service transactions, facilitating subsequent process analysis and script generation. By converting the service transaction relationship into the node and edge relationship in the graph database, the visualization and understanding degree of the transaction process are improved, the process of sorting out the transaction dependency relationship is simplified, and the time and error rate of manual sorting are reduced. This is because the graph database can intuitively display the hierarchy and association between all transactions, and testers or systems can easily read and understand the process from the graph structure without manually checking the dependency relationship of each transaction one by one.

[0071] A first determination unit 20, configured to obtain the name of the to-be-tested transaction, and determine a to-be-tested transaction process group in the graph database according to the name of the to-be-tested transaction, where the name of the to-be-tested transaction refers to the name of the current to-be-tested transaction in the overall transaction process, and the to-be-tested transaction process group includes at least one or more nodes corresponding to the to-be-tested transactions;

[0072] Specifically, the transaction name is matched with the nodes in the graph database to confirm the existence of the transaction. Then, starting from this transaction, the system traverses the entire graph database in reverse, finds all the nodes of the previous transactions, outputs them in reverse order, and forms a transaction process group to be tested. For example, if the input is the "Obtain Signature" transaction, the system will traverse the graph database, find the previous transactions such as "Reservation Form Initialization", "Create Reservation Form", and "Obtain Token", arrange them in reverse order, and form a complete transaction process group to be tested. By automatically obtaining and determining the transaction process group, the preparation time and complexity before writing the test script are significantly reduced. This is because the system can automatically identify and collect all necessary previous transactions, avoiding the cumbersome work of testers manually searching and sorting the transaction process group one by one. At the same time, the reverse output strategy ensures the correct execution order of the transaction process, improving the test accuracy and efficiency.

[0073] A generation unit 30 is configured to obtain a transaction message corresponding to the transaction process group to be tested, parse the transaction message to obtain transaction information, and generate a test program corresponding to the transaction process group to be tested according to the transaction information, where the transaction information at least includes a transaction code.

[0074] Specifically, obtain the transaction messages of each transaction in the transaction process group to be tested from the stress testing server. The transaction messages can be json messages. These messages contain the complete information of the transaction, including the transaction code, request path, request fields, etc. The system reads the messages, parses the header and the message body, and then generates the corresponding test program using this transaction information. The test program can be a jmx test script. For example, for the "Obtain Signature" transaction, the system will read its json message, parse out the transaction code, request path, request fields, etc., and generate the jmx script for the "Obtain Signature" transaction. Automatically generating test scripts using transaction messages greatly improves the speed and accuracy of script generation. This is because the system directly extracts information from the real transaction messages, avoiding errors and omissions that may occur when manually writing scripts, and can generate scripts quickly, reducing the time consumption in the test preparation stage. This device ensures a high degree of fit between the test script and the actual transaction scenario, improving the effectiveness and pertinence of the stress test.

[0075] Through this embodiment, a graph database corresponding to the overall transaction process is established, the name of the transaction to be tested is obtained, and the transaction process group to be tested is determined in the graph database according to the name of the transaction to be tested. The transaction process group to be tested includes at least one or more nodes corresponding to the transactions to be tested; the transaction message corresponding to the transaction process group to be tested is obtained, the transaction message is parsed to obtain transaction information, and a test program corresponding to the transaction process group to be tested is generated according to the transaction information. Compared with the prior art in which it is inefficient to manually sort out the logical relationships between multiple transaction steps and write test programs, the present application first establishes a graph database of the overall transaction process, and automatically determines the transaction process group to be tested corresponding to the name of the transaction to be tested by means of the graph database, that is, determines the logical relationships between the various transaction steps in the process group. Then, the corresponding transaction message is obtained and parsed to obtain transaction information, and then the transaction information is used to generate a test program. The test program generated in this way is a test program generated according to the logical relationships between the actual transaction steps, and there is no need to manually sort out the logic and write the program, which improves the test efficiency. Therefore, it can solve the problem of low efficiency in manually sorting out the logical relationships between multiple transaction steps and writing test programs in the prior art, and achieve the effect of improving the test efficiency.

[0076] In the specific implementation process, the above-mentioned establishment unit includes a connection module and a first calculation module. The connection module is used to obtain one or more of the transactions to be tested, determine the execution order of the transactions to be tested, generate the nodes corresponding to the transactions to be tested, and connect the nodes according to the execution order; the first calculation module is used to calculate the neighbor degrees of each of the nodes and the root node to obtain the graph database, where the neighbor degree is the number of nodes from each of the nodes to the root node. The device calculates the neighbor degree, which can automatically analyze and organize the dependency relationships of each transaction step, avoid the manual process of sorting out and understanding the transaction process, and improve the accuracy and efficiency of generating the stress test script.

[0077] Specifically, one or more of the transactions to be tested are obtained, the execution order of the transactions to be tested is determined, nodes corresponding to each of the transactions to be tested are generated, and the nodes are connected according to the execution order. This process essentially maps the logical relationships of business transactions to the nodes and edges in the graph database. The system first identifies all the transactions to be tested, and then establishes the dependency relationships between the transactions according to the order of transaction execution. For example, "create a reservation order" can only be executed after "obtain a token", and these two transactions are represented as an edge from the "obtain a token" node to the "create a reservation order" node, clearly defining the dependency hierarchy between the transactions. The calculation of the neighbor degree is mainly achieved by traversing all the nodes in the graph database to determine the distance between each node and the root node, that is, how many nodes are passed through to reach. For example, if the "obtain a token" transaction can be used as the root node, then the neighbor degree of the "create a reservation order" transaction is 1, and the neighbor degree of the "reservation order initialization" transaction is 2, and so on. This setting of the neighbor degree helps the system to automatically identify the order of transactions to be executed and the transaction logic when generating scripts in the subsequent process, avoiding the complexity of manual adjustment and configuration.

[0078] In some embodiments, the above first determination unit includes a first determination module, a second determination module, and a third determination module. The first determination module is used to determine whether there is a pre-transaction according to the name of the transaction to be tested, where the pre-transaction refers to a transaction whose execution order is before the transaction to be tested; the second determination module is used to, when there is a pre-transaction, start from the current node corresponding to the transaction to be tested in the graph database and traverse backward to the root node of the current node, and determine each node from the root node to the current node and the corresponding transaction to be tested as the transaction to be tested process group; the third determination module is used to, when there is no pre-transaction, determine the current node and the transaction to be tested as the transaction to be tested process group. By automatically determining the transaction to be tested process group, it avoids the complexity of testers manually searching for and arranging the transaction process, and greatly shortens the test preparation time.

[0079] Specifically, it is determined whether there is a pre - transaction according to the name of the transaction to be tested. If there is a pre - transaction, the system starts from the current transaction node and traverses the entire transaction process in reverse until it reaches the root node, and determines all the transactions corresponding to the nodes on this path as the transaction process group to be tested. For example, if the transaction to be tested is "obtain signature", the system will identify its pre - transactions including "appointment order initialization", "create appointment order", and "obtain token", and automatically add these transactions to the process group, and output them in reverse order. If there is no pre - transaction, it means that the current transaction is independent or the starting point of the process, then the system directly determines this transaction as the transaction process group to be tested. The reverse - order output strategy ensures that the execution order of the transactions in the process group is consistent with the actual business process, improving the accuracy and reliability of the test script. In the case of no pre - transaction, the system can quickly identify and locate independent transactions, further optimizing the script generation process.

[0080] In some other alternative embodiments, the above - mentioned generation unit includes a first acquisition module and a second acquisition module. The first acquisition module is used to acquire the name of the transaction to be tested for each transaction to be tested in the transaction process group to be tested; the second acquisition module is used to acquire the transaction message with the same name as the transaction to be tested from the stress - testing server, so as to obtain the transaction message corresponding to the transaction process group to be tested, where each transaction to be tested corresponds to one transaction message. By directly acquiring the transaction message from the server, this device can ensure that the generated test script is based on real business data, improving the accuracy and effectiveness of the test. The automatic acquisition of the message eliminates the steps of manually searching for and copying the message, saving time and avoiding data input errors, ensuring the efficiency and quality of script generation.

[0081] Specifically, the json messages of the transactions to be tested are pre - placed on the stress - testing server, and the above - mentioned messages to be tested are named after the transaction names. Therefore, the transaction messages with the same name as the transaction to be tested are directly acquired from the stress - testing server for generating test scripts. In this process, the system will read the transaction names in the transaction process group to be tested one by one, and then search for the transaction messages matching this name on the server. For example, for the "appointment order initialization" transaction in the process group, the system will read in its name and search for the corresponding json message on the stress - testing server.

[0082] In some alternative embodiments, the above-mentioned generating unit further includes a reading module and a parsing module. The reading module is configured to read the target path and request fields of the transaction message, where the target path represents the path of the transaction message, and the request fields represent the fields corresponding to the information to be parsed; the parsing module is configured to parse the transaction message according to the target path and the request fields to obtain the transaction information. By means of automated parsing, this device avoids the cumbersome process of manually checking each message one by one, improves the data processing speed, and at the same time reduces data errors caused by human negligence, ensuring the accuracy and reliability of the generated script.

[0083] Specifically, the system reads the target path and request fields of the transaction message and parses them to obtain the transaction information. This process involves in-depth parsing of the transaction message to identify the key paths and fields therein. For example, for the json message of the "reservation form initialization" transaction, the system will parse out important information such as its request path, request header information, all fields and their types in the message body, providing a data basis for generating test scripts. By accurately parsing the transaction message, the key information of the transaction can be accurately extracted, including but not limited to the transaction code, request path, and fields, etc., providing accurate data support for subsequent generation of test scripts.

[0084] In some alternative embodiments, the above-mentioned device further includes a representation unit and a second determination unit. The representation unit is configured to, after generating the test program corresponding to the to-be-tested transaction process group according to the transaction information, extract the input parameters and output parameters of the transaction message corresponding to each to-be-tested transaction in the to-be-tested transaction process group, and represent the input parameters and the output parameters in the form of key-value pairs, where both the input parameters and the output parameters include a parameter name and a data type; the second determination unit is configured to calculate the parameter name similarity and data type similarity between the input parameters and the output parameters, and determine the input parameters of the test program according to the parameter name similarity and the data type similarity, where a similarity greater than a preset threshold indicates that the input parameters and the output parameters have a dependency relationship, and a similarity less than or equal to the preset threshold indicates that the input parameters and the output parameters have no dependency relationship. By the above steps, this device greatly reduces the workload for testers to manually verify parameter dependencies and improves the test efficiency.

[0085] Specifically, the system further extracts the input parameters and output parameters, represented in the form of key-value pairs, and then calculates the parameter name similarity and data type similarity. This calculation process is a comparison of the parameter names and data types of the previous and subsequent steps to determine the dependency relationship between the output parameters of the previous step and the input parameters of the subsequent step. For example, the system can identify that the output parameter "reservation order number" of the "reservation order initialization" transaction is similar in name and consistent in data type with the input parameter "reservation order number" of the "obtain signature" transaction, thus determining that there is a direct dependency between the two, and taking the output parameter "reservation order number" of the "reservation order initialization" transaction as the input parameter of the "obtain signature" transaction. Otherwise, it is not used as the input parameter of the subsequent step. By automatically calculating the parameter similarity and type matching, the dependency of parameters between transactions can be intelligently identified, effectively avoiding errors in parameter references in the stress test script. The setting of the preset threshold ensures that only parameters with real similarity are regarded as dependency relationships, improving the accuracy of the test script and the intelligence of automatically generating the script.

[0086] In some other alternative embodiments, the second determination unit includes a second calculation module, a fourth determination module, and a fifth determination module. The second calculation module is used to calculate the data type similarity between the output parameters corresponding to the current transaction to be tested and the input parameters corresponding to the next transaction to be tested; the fourth determination module is used to determine that the output parameters corresponding to the current transaction to be tested are the input parameters corresponding to the next transaction to be tested when both the data type similarity and the parameter name similarity indicate that the output parameters and the input parameters have a dependency relationship; the fifth determination module is used to determine that the output parameters corresponding to the current transaction to be tested are not the input parameters corresponding to the next transaction to be tested when the data type similarity and / or the parameter name similarity indicate that the output parameters and the input parameters have no dependency relationship. By combining the calculation of data type and parameter name similarity, the device can more accurately judge the dependency relationship between parameters, so as to correctly reference the parameters in the generated test script and avoid invalid or incorrect parameter connections.

[0087] Specifically, calculate the data type similarity and parameter name similarity between the output parameters of the current transaction and the input parameters of the next transaction, and determine the dependency relationship between the parameters based on these two metrics. For example, the output parameter "reservation order number" of the "reservation order initialization" transaction and the input parameter "reservation order number" of the "obtain signature" transaction both reach the preset threshold in terms of data type similarity and parameter name similarity. The system determines that the "reservation order number" has a dependency relationship, and the output result of the "reservation order initialization" transaction can be referenced as the input of the "obtain signature" transaction in the generated test script. If the output parameter "version number" of the "reservation order initialization" transaction and the input parameter "signature method" of the "obtain signature" transaction have significant differences in data type and name, exceeding the preset threshold, it is determined that there is no dependency relationship between the two. In the specific implementation process, the TF-IDF combined with the Cosine Similarity device is used to connect and replace the dependent parameters. The steps are as follows: (1) Obtain the original transaction message (including input and output parameters), perform data preprocessing on the original transaction message, and extract the input and output parameters in the message in the form of KV (key-value pairs). The data form after preprocessing can be as follows: "orderid: 1234 (int)", "status: success (string)", "customerNO: 0012345 (int)". In the data preprocessing stage, if the camel case or underscore is used in the parameters, the field format is unified. (2) Calculate the similarity between the input and output parameters to confirm the dependency relationship between the output and input parameters in an automated manner. The similarity calculation device used is the TF-IDF combined with the Cosine Similarity device, and the matching dimensions are "data type" and "name similarity". The input and output parameters form a pair of comparison samples. Taking the input parameters as an example, calculate the term frequency of each parameter (TF (input parameter) = number of occurrences of the input parameter field / total number of input parameter fields), inverse document frequency (IDF = log(2 / number of occurrences of the input parameter field)), calculate TF-IDF (TF-IDF = TF * IDF), and construct a vector to calculate the cosine similarity According to the "data type" and "name similarity" dimensions, a cosine similarity value can be calculated respectively. The "data type" dimension has the right of prior veto. If the cosine similarity is 0, it means that there is no dependency relationship between the input and output parameters. If the cosine similarity of the "data type" is 1, then continue to calculate the cosine similarity value of the "name similarity". Sort the cosine similarities of the "name similarity" from large to small, and take the maximum value of the cosine similarity between the input and output parameters as the final result. If this value is less than 0.5 (preset threshold), it is discarded; otherwise, it is determined that there is a dependency relationship between the output and input parameters, and at the same time, change the input parameter to the output parameter in the jmx script

[0088] The automatic generation device of the test program includes a processor and a memory. The above-mentioned establishment unit, first determination unit, generation unit, etc. are all stored in the memory as program units, and the processor executes the above-mentioned program units stored in the memory to implement corresponding functions. The above-mentioned modules are all located in the same processor; alternatively, the above-mentioned each module is located in different processors in any combined form.

[0089] The processor contains a kernel, and the kernel retrieves the corresponding program units from the memory. One or more kernels can be set, and the trading test program is automatically generated by adjusting the kernel parameters.

[0090] The memory may include non-permanent memory in a computer-readable medium, in the form of random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash memory (flash RAM), and the memory includes at least one storage chip.

[0091] An embodiment of the present invention provides a computer-readable storage medium, and the computer-readable storage medium includes a stored program. Wherein, when the program runs, it controls the device where the computer-readable storage medium is located to execute the automatic generation method of the test program.

[0092] Specifically, the automatic generation method of the test program includes:

[0093] Step S201, establish a graph database corresponding to the total trading process, where the total trading process is composed of one or more to-be-tested transactions connected in the execution order, the graph database includes one or more nodes and the connection relationships between the nodes, and each node corresponds to one of the to-be-tested transactions;

[0094] Step S202, obtain the name of the to-be-tested transaction, and determine the to-be-tested transaction process group in the graph database according to the name of the to-be-tested transaction. Wherein, the name of the to-be-tested transaction refers to the name of the current to-be-tested transaction in the total trading process, and the to-be-tested transaction process group includes at least one or more nodes corresponding to the to-be-tested transactions;

[0095] Step S203, obtain the trading message corresponding to the to-be-tested transaction process group, parse the trading message to obtain trading information, and generate a test program corresponding to the to-be-tested transaction process group according to the trading information. Wherein, the trading information includes at least a trading code.

[0096] An embodiment of the present invention provides an electronic device, including a processor, a memory, and a program stored on the memory and executable on the processor. When the processor executes the program, it realizes at least the following steps:

[0097] Step S201, establish a graph database corresponding to the overall transaction process, where the overall transaction process consists of one or more to-be-tested transactions connected in the execution order, the graph database includes one or more nodes and the connection relationships between the nodes, and each node corresponds to one of the to-be-tested transactions;

[0098] Step S202, obtain the name of the to-be-tested transaction, and determine the to-be-tested transaction process group in the graph database according to the name of the to-be-tested transaction, where the name of the to-be-tested transaction refers to the name of the current to-be-tested transaction in the overall transaction process, and the to-be-tested transaction process group includes at least one or more nodes corresponding to the to-be-tested transactions;

[0099] Step S203, obtain the transaction message corresponding to the to-be-tested transaction process group, parse the transaction message to obtain transaction information, and generate a test program corresponding to the to-be-tested transaction process group according to the transaction information, where the transaction information includes at least a transaction code.

[0100] The devices in this article can be servers, PCs, PADs, mobile phones, etc.

[0101] This application also provides a computer program product, including a computer program, and when the computer program is executed by a processor, it implements the steps of the methods in the various embodiments of this application:

[0102] Step S201, establish a graph database corresponding to the overall transaction process, where the overall transaction process consists of one or more to-be-tested transactions connected in the execution order, the graph database includes one or more nodes and the connection relationships between the nodes, and each node corresponds to one of the to-be-tested transactions;

[0103] Step S202, obtain the name of the to-be-tested transaction, and determine the to-be-tested transaction process group in the graph database according to the name of the to-be-tested transaction, where the name of the to-be-tested transaction refers to the name of the current to-be-tested transaction in the overall transaction process, and the to-be-tested transaction process group includes at least one or more nodes corresponding to the to-be-tested transactions;

[0104] Step S203, obtain the transaction message corresponding to the to-be-tested transaction process group, parse the transaction message to obtain transaction information, and generate a test program corresponding to the to-be-tested transaction process group according to the transaction information, where the transaction information includes at least a transaction code.

[0105] Obviously, those skilled in the art should understand that the various modules or steps of the present invention described above can be implemented by a general-purpose computing device. They can be concentrated on a single computing device or distributed on a network composed of multiple computing devices. They can be implemented by program codes executable by the computing device. Thus, they can be stored in a storage device and executed by the computing device. And in some cases, the steps shown or described can be executed in a different order than here, or they can be separately fabricated into individual integrated circuit modules, or multiple modules or steps among them can be fabricated into a single integrated circuit module for implementation. In this way, the present invention is not limited to any specific combination of hardware and software.

[0106] Those skilled in the art should understand that the embodiments of the present application can be provided as a method, a system, or a computer program product. Therefore, the present application can take the form of a complete hardware embodiment, a complete software embodiment, or an embodiment combining software and hardware aspects. Moreover, the present application can take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program codes.

[0107] The present application is described with reference to the flowcharts and / or block diagrams of methods, apparatuses (systems), and computer program products according to the embodiments of the present application. It should be understood that each flow and / or block in the flowchart and / or block diagram, as well as the combination of flows and / or blocks in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to the processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing devices to generate a machine, such that the instructions executed by the processor of the computer or other programmable data processing devices generate a device for implementing the functions specified in Figure 1 one or more of the flows Figure 1 or multiple flows and / or blocks

[0108] These computer program instructions can also be stored in a computer-readable memory capable of guiding the computer or other programmable data processing devices to work in a specific manner, such that the instructions stored in the computer-readable memory generate a manufactured article including an instruction device, and the instruction device implements the functions specified in Figure 1 one or more of the flows Figure 1 or multiple flows and / or blocks

[0109] These computer program instructions can also be loaded onto the computer or other programmable data processing devices, such that a series of operation steps are executed on the computer or other programmable devices to generate a computer-implemented process. Thus, the instructions executed on the computer or other programmable devices provide for implementing in the processFigure 1 one or more processes and / or blocks Figure 1 steps of functions specified in one or more blocks

[0110] In a typical configuration, a computing device includes one or more processors (CPUs), an input / output interface, a network interface, and memory.

[0111] The memory may include non-permanent memory in the form of computer-readable media, random access memory (RAM), and / or non-volatile memory such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0112] Computer-readable media includes permanent and non-permanent, removable and non-removable media and can store information by any method or technology. The information can be computer-readable instructions, data structures, program modules, or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, compact disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical storage, magnetic cassette tapes, magnetic disk storage or other magnetic storage devices, or any other non-transitory media that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transitory media such as modulated data signals and carrier waves.

[0113] It should also be noted that the term "comprising", "including" or any other variation thereof is intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the statement "comprising an..." does not exclude the presence of additional identical elements in the process, method, article, or apparatus that comprises the element.

[0114] From the above description, it can be seen that the above-described embodiments of the present application achieve the following technical effects:

[0115] 1) In the method for automatically generating a test program of the present application, a graph database corresponding to the overall transaction process is established, the name of the transaction to be tested is obtained, and in the graph database, a transaction process group to be tested is determined according to the name of the transaction to be tested. The transaction process group to be tested includes at least one or more nodes corresponding to the transactions to be tested; the transaction message corresponding to the transaction process group to be tested is obtained, the transaction message is parsed to obtain transaction information, and a test program corresponding to the transaction process group to be tested is generated according to the transaction information. Compared with the prior art where it is inefficient to manually sort out the logical relationships between multiple transaction steps and write test programs, the present application first establishes a graph database of the overall transaction process, and automatically determines the transaction process group to be tested corresponding to the name of the transaction to be tested by means of the graph database, that is, determines the logical relationships between the various transaction steps in the process group. Then, the corresponding transaction message is obtained and parsed to obtain transaction information, and then the transaction information is used to generate a test program. The test program generated in this way is a test program generated according to the logical relationships between the actual transaction steps, and there is no need to manually sort out the logic and write the program anymore, improving the test efficiency. Therefore, it can solve the problem in the prior art of low efficiency in manually sorting out the logical relationships between multiple transaction steps and writing test programs, and achieve the effect of improving the test efficiency.

[0116] 2) In the device for automatically generating a test program of the present application, a graph database corresponding to the overall transaction process is established, the name of the transaction to be tested is obtained, and in the graph database, a transaction process group to be tested is determined according to the name of the transaction to be tested. The transaction process group to be tested includes at least one or more nodes corresponding to the transactions to be tested; the transaction message corresponding to the transaction process group to be tested is obtained, the transaction message is parsed to obtain transaction information, and a test program corresponding to the transaction process group to be tested is generated according to the transaction information. Compared with the prior art where it is inefficient to manually sort out the logical relationships between multiple transaction steps and write test programs, the present application first establishes a graph database of the overall transaction process, and automatically determines the transaction process group to be tested corresponding to the name of the transaction to be tested by means of the graph database, that is, determines the logical relationships between the various transaction steps in the process group. Then, the corresponding transaction message is obtained and parsed to obtain transaction information, and then the transaction information is used to generate a test program. The test program generated in this way is a test program generated according to the logical relationships between the actual transaction steps, and there is no need to manually sort out the logic and write the program anymore, improving the test efficiency. Therefore, it can solve the problem in the prior art of low efficiency in manually sorting out the logical relationships between multiple transaction steps and writing test programs, and achieve the effect of improving the test efficiency.

[0117] The above are only the preferred embodiments of the present application and are not intended to limit the present application. For those skilled in the art, the present application may have various changes and modifications. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present application shall be included within the protection scope of the present application.

Claims

1. An automatic generation method for a test program, characterized in that, Including: Establish a graph database corresponding to the overall transaction process, where the overall transaction process consists of one or more to-be-tested transactions connected in the execution order, the graph database includes one or more nodes and the connection relationships between the nodes, and each of the nodes corresponds to one of the to-be-tested transactions; Obtain the name of the to-be-tested transaction, and determine the to-be-tested transaction process group in the graph database according to the name of the to-be-tested transaction, where the name of the to-be-tested transaction refers to the name of the current to-be-tested transaction in the overall transaction process, and the to-be-tested transaction process group includes at least one or more nodes corresponding to the to-be-tested transactions; Obtain the transaction message corresponding to the to-be-tested transaction process group, parse the transaction message to obtain transaction information, and generate a test program corresponding to the to-be-tested transaction process group according to the transaction information, where the transaction information includes at least a transaction code.

2. The automatic generation method of the test program according to claim 1, characterized in that, Establishing a graph database corresponding to the overall transaction process, including: Obtain one or more of the to-be-tested transactions, determine the execution order of the to-be-tested transactions, generate the nodes corresponding to each of the to-be-tested transactions, and connect the nodes according to the execution order; Calculate the neighbor degrees of each of the nodes and the root node to obtain the graph database, where the neighbor degree is the number of nodes from each of the nodes to the root node.

3. The automatic generation method of the test program according to claim 1, characterized in that Obtain the name of the to-be-tested transaction, and determine the to-be-tested transaction process group in the graph database according to the name of the to-be-tested transaction, including: Determine whether there is a pre-transaction according to the name of the to-be-tested transaction, where the pre-transaction refers to the transaction whose execution order is before the to-be-tested transaction; In the case where there is a pre-transaction, starting from the current node corresponding to the to-be-tested transaction in the graph database, traverse backward to the root node of the current node, and determine each node from the root node to the current node and the corresponding to-be-tested transaction as the to-be-tested transaction process group; In the case where there is no pre-transaction, determine the current node and the to-be-tested transaction as the to-be-tested transaction process group.

4. The automatic generation method of the test program according to claim 1, wherein Obtain the transaction message corresponding to the to-be-tested transaction process group, including: Obtain the name of the to-be-tested transaction for each of the to-be-tested transactions in the to-be-tested transaction process group; Obtain the transaction message with the same name as the to-be-tested transaction name from the stress test server to obtain the transaction message corresponding to the to-be-tested transaction process group, where each of the to-be-tested transactions corresponds to one transaction message.

5. The automatic generation method of the test program according to claim 1, characterized in that, Parsing the transaction message to obtain transaction information, including: Read the target path and request field of the transaction message, where the target path represents the path of the transaction message, and the request field represents the field corresponding to the information to be parsed; Parse the transaction message according to the target path and the request field to obtain the transaction information.

6. The automatic generation method of the test program according to claim 1, wherein, After generating the test program corresponding to the to-be-tested transaction process group according to the transaction information, the method further includes: Extract the input parameters and output parameters of the transaction message corresponding to each of the to-be-tested transactions in the to-be-tested transaction process group, and represent the input parameters and the output parameters in the form of key-value pairs, where both the input parameters and the output parameters include a parameter name and a data type; Calculate the parameter name similarity and data type similarity between the input parameters and the output parameters, and determine the input parameters of the test program according to the parameter name similarity and the data type similarity, where the parameter name similarity represents the similarity of the parameter names, the data type similarity represents the similarity of the data types, and a similarity greater than a preset threshold indicates that there is a dependency relationship between the input parameters and the output parameters, and a similarity less than or equal to the preset threshold indicates that there is no dependency relationship between the input parameters and the output parameters.

7. The method for automatically generating a test program according to claim 6, wherein Calculating the parameter name similarity and data type similarity between the input parameters and the output parameters, and determining the input parameters of the test program according to the parameter name similarity and the data type similarity, includes: Calculate the data type similarity between the output parameters corresponding to the current to-be-tested transaction and the input parameters corresponding to the next to-be-tested transaction; When both the data type similarity and the parameter name similarity indicate that there is a dependency relationship between the output parameters and the input parameters, determine that the output parameters corresponding to the current to-be-tested transaction are the input parameters corresponding to the next to-be-tested transaction; When the data type similarity and / or the parameter name similarity indicates that there is no dependency relationship between the output parameters and the input parameters, determine that the output parameters corresponding to the current to-be-tested transaction are not the input parameters corresponding to the next to-be-tested transaction.

8. An automatic generation device for a test program, characterized in that, Includes: A building unit for building a graph database corresponding to the total transaction process, where the total transaction process is composed of one or more to-be-tested transactions connected in an execution order, the graph database includes one or more nodes and the connection relationships between the nodes, and each node corresponds to one of the to-be-tested transactions; A first determination unit for obtaining the name of the to-be-tested transaction, and determining the to-be-tested transaction process group in the graph database according to the name of the to-be-tested transaction, where the name of the to-be-tested transaction refers to the name of the current to-be-tested transaction in the total transaction process, and the to-be-tested transaction process group includes at least one or more nodes corresponding to the to-be-tested transactions; A generating unit for obtaining the transaction message corresponding to the to-be-tested transaction process group, parsing the transaction message to obtain transaction information, and generating a test program corresponding to the to-be-tested transaction process group according to the transaction information, where the transaction information includes at least a transaction code.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium includes a stored program, where when the program runs, it controls the device where the computer-readable storage medium is located to execute the method for automatically generating the test program according to any one of claims 1 to 7.

10. An electronic device, characterized in that, Includes: One or more processors, a memory, and one or more programs, wherein the one or more programs are stored in the memory and configured to be executed by the one or more processors, and the one or more programs include an automatic generation method for executing the test program described in any one of claims 1 to 7.

Images