Test data management method, device, computer equipment and storage medium

Abstract

The present application discloses a test data management method, apparatus, computer device, and storage medium, including: collecting the functional architecture of a target terminal, where the functional architecture is composed of multiple functional units; configuring verification rules for each functional unit based on the functional architecture and a preset rule database, where the rule database is used to store verification rules corresponding to various types of functional units; extracting test data of the target terminal, and splitting the test data according to each functional unit to generate multiple functional test data; respectively performing data verification on the corresponding functional test data according to the verification rules of each functional unit; and when any one of the functional test data fails to pass the verification, sending a verification error message to the target terminal. This avoids the problem of missing test scenarios caused by only focusing on test results, improves the coverage of test scenarios in test verification, and makes the test results more real and accurate.

Description

Technical Field

[0001] Embodiments of the present invention relate to the field of data processing, and in particular, to a test data management method, apparatus, computer device, and storage medium. Background Art

[0002] A test case is a document and is the smallest entity to be executed. A test case includes input, action, time, and an expected result, and its purpose is to determine whether a certain feature of an application can work properly and achieve the result designed by the program, so as to test a certain program path or verify whether a specific requirement is met. Generally, before designing a test case, it is necessary to comprehensively understand the functions of the product to be tested, clarify the test scope, and have basic test techniques and methods, etc.

[0003] The inventors of the present invention found in their research that in the prior art, when using test cases to perform software testing on a terminal, only the success of the execution of the test results of the test cases is concerned, while the review of the various index information in the data generated by the test is ignored, resulting in the omission of test scenarios. Summary of the Invention

[0004] Embodiments of the present invention provide a test data management method, apparatus, computer device, and storage medium for improving the test quality of test data.

[0005] To solve the above technical problems, an embodiment of the present invention adopts a technical solution: providing a test data management method, including:

[0006] Collecting the functional architecture of the target terminal, where the functional architecture is composed of multiple functional units;

[0007] Configuring verification rules for each functional unit based on the functional architecture and a preset rule database, where the rule database is used to store verification rules corresponding to various functional units;

[0008] Extracting the test data of the target terminal and splitting the test data into multiple functional test data according to each functional unit;

[0009] Performing data verification on the corresponding functional test data according to the verification rules of each functional unit;

[0010] When any one of the functional test data fails to pass the verification, sending a verification error message to the target terminal.

[0011] Optionally, the collecting the functional architecture of the target terminal includes:

[0012] Reading multiple call interfaces of the target terminal;

[0013] Based on the call interfaces and a preset function database, match the function units corresponding to each call interface, where the function database stores the function units corresponding to various types of call interfaces;

[0014] According to the mutual call relationship between the function units, perform topological connection on the matched function units to generate the function architecture.

[0015] Optionally, before configuring the verification rules for each function unit based on the function architecture and a preset rule database, it includes:

[0016] Convert the function architecture into a function topology graph;

[0017] Input the function topology graph into a preset function screening model, where the function screening model is a neural network model that has been pre-trained to a converged state and is used to screen non-matching function units;

[0018] Delete the non-matching function units in the function architecture according to the classification result output by the function screening model.

[0019] Optionally, after sending a verification error message to the target terminal when any one of the function test data verification fails, it includes:

[0020] Extract the first error function unit in the target terminal according to the verification error message;

[0021] Determine the target node of the first error function unit in the function topology graph;

[0022] Differentially display the target node in the function topology graph, and associatively store the verification error message with the differentially displayed target node.

[0023] Optionally, the differentially displaying the target node in the function topology graph and associatively storing the verification error message with the differentially displayed target node includes:

[0024] Collect the node graphic set of the function topology graph, where the node graphic set includes graphic shapes and graphic colors;

[0025] Input the graphic shapes and graphic colors into a preset shape screening model, where the shape screening model is a neural network model that has been pre-trained to a converged state and is used to generate differential graphics according to existing graphic shapes and graphic colors;

[0026] Differentially display the target node according to the classification result output by the shape screening model, and associatively store the verification error message with the differentially displayed target node according to the data linked list.

[0027] Optionally, after sending a verification error message to the target terminal when any of the function test data verification fails, the following steps are included:

[0028] Extract the second error function unit in the target terminal according to the verification error message;

[0029] Collect the environmental information of the second error function unit, and construct a test container corresponding to the second error function unit according to the environmental information;

[0030] Adapt the test cases corresponding to the second error function unit in a preset test database;

[0031] Input the test cases into the test container for running tests, and generate the test results of the second error function unit according to the running test results.

[0032] Optionally, the step of collecting the environmental information of the second error function unit and constructing a test container corresponding to the second error function unit according to the environmental information includes:

[0033] Collect the environmental information of the second error function unit, where the environmental information includes the application type and application configuration parameters of the second error function unit;

[0034] Call the corresponding installation file according to the application type, and configure the installation file according to the application configuration parameters to generate an image file;

[0035] Input the image file into a preset blank container to generate the test container.

[0036] To solve the above technical problems, an embodiment of the present invention further provides a test data management device, including:

[0037] A collection module, configured to collect the function architecture of the target terminal, where the function architecture is composed of multiple function units;

[0038] A configuration module, configured to configure the verification rules of each function unit based on the function architecture and a preset rule database, where the rule database is used to store the verification rules corresponding to various function units;

[0039] An extraction module, configured to extract the test data of the target terminal and split the test data into multiple function test data according to each function unit;

[0040] A processing module, configured to perform data verification on the corresponding function test data according to the verification rules of each function unit;

[0041] An execution module, configured to send a verification error message to the target terminal when any one of the function test data verifications fails.

[0042] Optionally, the test data management device further includes:

[0043] A first reading sub-module, configured to read a plurality of call interfaces of the target terminal;

[0044] A first processing sub-module, configured to match function units corresponding to each call interface based on the call interface and a preset function database, where the function database stores function units corresponding to various types of call interfaces;

[0045] A first execution sub-module, configured to topologically connect the matched function units according to the mutual call relationship between the function units to generate the function architecture.

[0046] Optionally, the test data management device further includes:

[0047] A first conversion sub-module, configured to convert the function architecture into a function topology diagram;

[0048] A second processing sub-module, configured to input the function topology diagram into a preset function screening model, where the function screening model is a neural network model that has been pre-trained to a convergence state and is used to screen out non-adapted function units;

[0049] A second execution sub-module, configured to delete non-adapted function units in the function architecture according to the classification result output by the function screening model.

[0050] Optionally, the test data management device further includes:

[0051] A first extraction sub-module, configured to extract a first error function unit in the target terminal according to the verification error message;

[0052] A third processing sub-module, configured to determine a target node of the first error function unit in the function topology diagram;

[0053] A third execution sub-module, configured to differentially display the target node in the function topology diagram and associatively store the verification error message with the differentially displayed target node.

[0054] Optionally, the test data management device further includes:

[0055] A first collection sub-module, configured to collect a node graphic set of the function topology diagram, where the node graphic set includes graphic shapes and graphic colors;

[0056] A fourth processing sub-module, configured to input the graphic shape and graphic color into a preset shape screening model, where the shape screening model is a neural network model that has been pre-trained to a convergence state and is used to generate a differentiated graphic based on the existing graphic shape and graphic color;

[0057] A fourth execution sub-module, configured to perform differentiated display on the target node according to the classification result output by the shape screening model, and associate and store the verification error information with the differentiated-displayed target node according to the data linked list.

[0058] Optionally, the test data management device further includes:

[0059] A second extraction sub-module, configured to extract a second error function unit in the target terminal according to the verification error information;

[0060] A second acquisition sub-module, configured to acquire the environmental information of the second error function unit, and construct a test container corresponding to the second error function unit according to the environmental information;

[0061] A fifth processing sub-module, configured to adapt a test case corresponding to the second error function unit in a preset test database;

[0062] A fifth execution sub-module, configured to input the test case into the test container for running tests, and generate a test result of the second error function unit according to the running test result.

[0063] Optionally, the test data management device further includes:

[0064] A third acquisition sub-module, configured to acquire the environmental information of the second error function unit, where the environmental information includes the application type and application configuration parameters of the second error function unit;

[0065] A sixth processing sub-module, configured to call a corresponding installation file according to the application type, and configure the installation file according to the application configuration parameters to generate an image file;

[0066] A sixth execution sub-module, configured to input the image file into a preset blank container to generate the test container.

[0067] To solve the above technical problems, an embodiment of the present invention further provides a computer device, including a memory and a processor. A computer-readable instruction is stored in the memory. When the computer-readable instruction is executed by the processor, the processor is caused to execute the steps of the above test data management method.

[0068] In order to solve the above technical problem, an embodiment of the present invention further provides a computer storage medium, and when the computer-readable instructions are executed by one or more processors, the one or more processors execute the steps of the above test data management method.

[0069] The beneficial effect of the embodiment of the present invention is that when auditing the test data of the target terminal, the functional units constituting the target terminal are obtained by calling the functional architecture of the target terminal, and then, the inspection rules of each type of functional unit are configured according to the type of each intermediate unit, and the test data of the target terminal is split according to the function, and the test data of the corresponding functional unit is verified using the inspection rules of each type of functional unit, and the functional units that fail the verification are extracted. This method can pay attention to whether the data generated by the most basic functional units constituting the target terminal are compliant, and can perform detailed verification of various indicator data generated by the test, avoiding the problem of missing test scenarios due to only focusing on test results, improving the coverage of test scenarios in test verification, and making the test results more real and accurate. BRIEF DESCRIPTION OF THE DRAWINGS

[0070] The above and / or additional aspects and advantages of the present application will become apparent and easily understood from the following description of the embodiments in conjunction with the accompanying drawings, in which:

[0071] Figure 1 A basic flow chart of a test data management method according to a specific embodiment of the present application;

[0072] Figure 2 A schematic diagram of a flow chart of constructing a functional unit according to a calling interface in a specific embodiment of the present application;

[0073] Figure 3 A schematic diagram of a process for verifying the functional architecture of a target terminal according to a specific embodiment of the present application;

[0074] Figure 4 A schematic diagram of a flow chart for concretely displaying an erroneous functional unit according to a specific embodiment of the present application;

[0075] Figure 5 A schematic diagram of a process of performing differentiated display through a neural network model according to a specific embodiment of the present application;

[0076] Figure 6 A schematic diagram of a flow chart of testing an erroneous functional unit according to a specific embodiment of the present application;

[0077] Figure 7 A schematic diagram of a process for generating a test container according to an embodiment of the present application;

[0078] Figure 8Schematic diagram of the basic structure of a test data management device according to an embodiment of the present application;

[0079] Figure 9 Block diagram of the basic structure of a computer device according to an embodiment of the present application. Detailed implementation manners

[0080] The embodiments of the present application will be described in detail below. Examples of the embodiments are shown in the accompanying drawings, where the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described by referring to the accompanying drawings are exemplary only for explaining the present application and should not be construed as limiting the present application.

[0081] Those skilled in the art of the present technology can understand that unless specifically stated otherwise, the singular forms "a", "an", "the" and "said" used herein may also include the plural forms. It should be further understood that the term "including" used in the specification of the present application means the presence of the described features, integers, steps, operations, elements and / or components, but does not exclude the presence or addition of one or more other features, integers, steps, operations, elements, components and / or their groups.

[0082] Those skilled in the art of the present technology can understand that unless otherwise defined, all terms (including technical terms and scientific terms) used herein have the same meaning as the general understanding of those of ordinary skill in the art to which the present application belongs. It should also be understood that terms such as those defined in a general dictionary should be understood to have a meaning consistent with the meaning in the context of the prior art, and will not be interpreted in an idealized or overly formal sense unless specifically defined as here.

[0083] Those skilled in the art of the present technology can understand that the "terminal" used here includes both a device with a wireless signal receiver that only has the ability to receive without transmitting, and a device with receiving and transmitting hardware that has the receiving and transmitting hardware capable of performing two-way communication on a two-way communication link. Such devices may include: cellular or other communication devices, which may have a single-line display or a multi-line display or a cellular or other communication device without a multi-line display; PCS (Personal Communications Service), which may combine voice, data processing, fax, and / or data communication capabilities; PDA (Personal Digital Assistant), which may include a radio frequency receiver, a pager, Internet / intranet access, a web browser, a notepad, a calendar, and / or a GPS (Global Positioning System) receiver; a conventional laptop and / or palm computer or other device, which is a conventional laptop and / or palm computer or other device with and / or including a radio frequency receiver. The "terminal" used here may be portable, transportable, installed in a vehicle (air, sea, and / or land), or suitable for and / or configured to operate locally, and / or operate in a distributed form at any other location on the earth and / or in space. The "terminal" used here may also be a communication terminal, an Internet access terminal, a music / video playback terminal, such as a PDA, a MID (Mobile Internet Device), and / or a mobile phone with music / video playback functions, or may also be a smart TV, a set-top box, and other devices.

[0084] Please refer to Figure 1 , Figure 1 which is a schematic diagram of the basic process of the test data management method of this embodiment.

[0085] As Figure 1 shown, a test data management method includes:

[0086] S110. Collect the functional architecture of the target terminal, where the functional architecture is composed of multiple functional units;

[0087] In this embodiment, each target terminal supports n (n is a positive integer greater than or equal to 1) functions, that is, the intelligent terminal corresponds to n functional units, and each functional unit is an independent functional module, and they operate independently of each other without interference. Therefore, the functional architecture of the intelligent terminal is a tree topology structure composed of n functional units.

[0088] After the target terminal finishes the test tasks of the test cases, it is necessary to extract the functional architecture of the target terminal. In some embodiments, since the parameters of some target terminals do not include the functional architecture of the terminal itself. Therefore, the server side needs to construct the functional architecture of the target terminal by itself. The specific method is as follows: extract all the call interfaces in the target terminal. The call interfaces include API interfaces and SDK interfaces. Since each functional unit is independent, the call interfaces corresponding to each functional unit are also independent. API (Application Programming Interface) is some predefined interfaces (such as functions, HTTP interfaces), or refers to the convention for the connection of different components of a software system. It is used to provide a set of routines for applications and developers to access based on a certain software or hardware. The SDK interface is the general interface of multiple API interfaces, and multiple API interfaces can be obtained by parsing the SDK interface.

[0089] After obtaining multiple interfaces of the target terminal, match the functional units corresponding to the call interfaces in the function database preset on the server side. The server side pre-constructs a function database, which stores all functional units, and each functional unit uses the corresponding call interface as an index label. Therefore, after the call interfaces of the target terminal are extracted, the corresponding functional units can be retrieved according to the call interfaces in the function database.

[0090] In some embodiments, there is a data cooperation relationship between different functional units. According to the sequence of data cooperation, there is a call relationship for functional units to call each other's data. For example, if functional unit B needs to call the data of functional unit A before it can perform calculations, then a call relationship is formed between functional unit B and functional unit A, and the call relationship points from B to A. Then the corresponding topological relationship is that functional unit B is connected behind functional unit A. The call relationships between functional units are recorded in the function database by the server side after statistics. After the functional units are extracted, the call relationships between the functional units can be obtained, and then various call relationships can be used to construct the functional architecture of the target terminal.

[0091] In some embodiments, after the functional architecture of the target terminal is constructed, it is necessary to review the rationality of the functional architecture of the target terminal. The review method is to judge through a neural network model.

[0092] Specifically, a function screening model is constructed on the server side. The function screening model needs to be pre-trained, that is, by collecting a large number of functional architecture topology diagrams of the terminal as positive and negative samples, and training the initial neural network model through supervised training. When the number of training times of the function screening model reaches a predetermined number of times after training is completed or it is determined through verification samples that the judgment accuracy rate of the function screening model is greater than the set accuracy rate threshold, then the function screening model is trained to convergence. The function screening model trained to the convergence state can extract the unreasonable functional units in the functional architecture of the target terminal. The function screening model in this embodiment can be trained by (but not limited to): a convolutional neural network model, a deep convolutional neural network model, a recurrent neural network model, or a variant model of any one of the above neural network models.

[0093] Since the function screening model is an image processing model, therefore, it is necessary to convert the functional architecture of the target terminal into a functional topology diagram. That is, each functional unit in the functional architecture is converted into a functional graph, and each functional graph is marked with the functional unit corresponding to the functional graph. Then, according to the mutual call relationship between the functional units, after connecting the functional graphs, a functional topology diagram of the functional units is generated.

[0094] The functional topology diagram converted from the functional units of the target terminal is input into the function screening model. The function screening model extracts the features in the functional topology diagram and identifies the functional units that are not adapted to the target terminal. When the non-adapted functional unit is identified, the non-adapted functional unit is deleted from the target terminal to ensure the accuracy of the functional architecture in the target terminal and reduce the number of unnecessary data error alarms in subsequent processing.

[0095] S120. Configure the verification rules for each functional unit based on the functional architecture and a preset rule database, where the rule database is used to store the verification rules corresponding to various functional units;

[0096] The server side also constructs a rule database, and the verification rules for each type of functional unit during operation are recorded in the rule database. For example, verification rules such as whether it contains empty data, whether it contains null data, whether the data is equal, whether it is included in a preset interval, the data deviation is not less than x%, and whether there is an empty value. Some of the above verification rules are obtained by the server side through statistical historical data, and some are rules written by users according to the needs of the adaptation scenario. The verification rules in the rule database are not chaotic, but are classified according to functional units. Therefore, for each functional unit in the rule database, one or more verification rules are correspondingly set. Since the verification rules are classified and stored according to functional units, only by splitting and retrieving the functional units in the functional architecture, the verification rules corresponding to each functional unit can be obtained.

[0097] S130. Extract the test data of the target terminal, and split the test data according to each functional unit to generate multiple functional test data;

[0098] After obtaining the configuration rules of each functional unit, the server extracts the test data generated by the target terminal when running the test cases. This test data is the overall test data generated by the target terminal when running the test cases, including the detailed test data of each functional unit. Therefore, it is necessary to split the test data.

[0099] Specifically, each set of test data is composed of the test data of multiple functional units, and each functional unit is independent of each other. Therefore, the test data is composed of the functional test data of each functional unit. Each functional unit has a corresponding functional field or call interface field, and these fields play a role in data segmentation in the test data. Therefore, the test data can be split into multiple functional test data through the functional field or call interface field of the functional unit. Each set of functional test data corresponds to a functional unit.

[0100] S140. Perform data verification on the corresponding functional test data according to the verification rules of each functional unit;

[0101] After splitting to obtain the functional test data corresponding to the functional unit, it is necessary to verify the functional test data of each functional unit. Since each functional unit has a corresponding verification rule, when verifying, the verification rule of each functional unit is used to verify its corresponding functional test data. Specifically, in the verification rule corresponding to the functional unit, parameters such as whether it contains empty data, whether it contains null data, whether the data is equal, whether it is included in a preset interval, the data deviation is not less than x%, or whether there is emptiness are recorded, and the functional test data is compared and verified according to one or more of the above rules. When any one of the parameters in any functional unit appears abnormally, it is determined that the verification of the functional test data of that functional unit fails. Only when all the verification parameters are correct can it be determined that the verification of the functional test data of that functional unit is successful.

[0102] S150. When any one of the functional test data verification fails, send a verification error message to the target terminal.

[0103] When any one of the functional test data verification fails, the server sends a verification error message to the target terminal. The verification error message includes: which functional unit of the target terminal and which parameter in that functional unit has an error. The target terminal can perform targeted debugging on that functional unit when obtaining the verification error message to avoid the recurrence of the error.

[0104] In the above embodiments, when auditing the test data of the target terminal, the functional units that make up the target terminal are obtained by invoking the functional architecture of the target terminal. Then, the inspection rules for each type of functional unit are configured according to the type of each energy unit, and the test data of the target terminal are split by function. The inspection rules for each type of functional unit are used to verify the test data of the corresponding functional unit, and the functional units with unqualified verification are extracted. This method can pay attention to whether the data generated by the most basic functional units that make up the target terminal are compliant, can verify various index data generated by the test in detail, avoids the problem of missing test scenarios caused by only focusing on the test results, improves the coverage of test scenarios in test verification, and makes the test results more real and accurate.

[0105] In some embodiments, it is necessary to construct the terminal architecture of the target terminal according to the call interface of the target terminal. Please refer to Figure 2 , Figure 2 which is a schematic flowchart of constructing functional units according to the call interface in this embodiment.

[0106] As Figure 2 shown, S110 includes:

[0107] S111. Read multiple call interfaces of the target terminal;

[0108] In some embodiments, since the parameters of some target terminals do not include the functional architecture of the terminal itself. Therefore, the server side needs to construct the functional architecture of the target terminal by itself. The specific method is: extract all the call interfaces in the target terminal, and the call interface includes API interfaces and SDK interfaces. Since each functional unit is independent, the call interfaces corresponding to each functional unit are also independent. API (Application Programming Interface) is some predefined interfaces (such as functions, HTTP interfaces), or refers to the convention for the connection of different components of a software system. It is used to provide a set of routines for applications and developers to access based on a certain software or hardware. The SDK interface is the general interface of multiple API interfaces, and multiple API interfaces can be obtained from the SDK interface through parsing.

[0109] S112. Based on the call interface and a preset functional database, match the functional units corresponding to each call interface, where the functional database stores the functional units corresponding to each type of call interface;

[0110] After obtaining multiple interfaces of the target terminal, match the function units corresponding to the call interfaces in the function database preset on the server side. The server side pre-builds a function database, which stores all function units, and each function unit uses the corresponding call interface as an index label. Therefore, after extracting the call interface of the target terminal, retrieve the corresponding function unit according to the call interface in the function database.

[0111] S113. According to the mutual call relationship between function units, topologically connect the matched function units to generate the function architecture.

[0112] There is a data collaboration relationship between different function units. According to the sequence of data collaboration, there is a call relationship for function units to mutually call data. For example, if function unit B needs to call the data of function unit A before performing operations, then a call relationship is formed between function unit B and function unit A, and the call relationship points from B to A. Then the corresponding topological relationship is that function unit B is connected behind function unit A. After the server side statistically records the call relationships between function units in the function database, when the function units are extracted, the call relationships between various function units can be obtained, and then various call relationships are used to construct the function architecture of the target terminal.

[0113] In some embodiments, after the function architecture of the target terminal is constructed, it is necessary to review the rationality of the function architecture of the target terminal. Please refer to Figure 3 , Figure 3 which is a schematic flowchart for verifying the function architecture of the target terminal in this embodiment.

[0114] As Figure 3 shown, before S120, it includes:

[0115] S114. Convert the function architecture into a function topology graph;

[0116] Convert each function unit in the function architecture into a function graph, and mark the function unit corresponding to the function graph in each function graph. Then, according to the mutual call relationship between function units, connect the function graphs to generate the function topology graph of the function units.

[0117] S115. Input the function topology graph into a preset function screening model, where the function screening model is a neural network model that has been pre-trained to a convergent state and is used to screen non-adapted function units;

[0118] Build a function screening model on the server side. The function screening model needs to be pre-trained, that is, by collecting a large number of functional architecture topology diagrams of the terminal as positive and negative samples, and training the initial neural network model through supervised training. When the number of training times of the function screening model reaches a predetermined number of times after training is completed or it is determined through verification samples that the judgment accuracy rate of the function screening model is greater than the set accuracy rate threshold, then the function screening model is trained to convergence. The function screening model trained to the convergence state can extract the unreasonable functional units in the functional architecture of the target terminal. The function screening model in this embodiment can be obtained by (but not limited to): a convolutional neural network model, a deep convolutional neural network model, a recurrent neural network model, or a variant model of any one of the above neural network models.

[0119] S116. Delete the non-adapted functional units in the functional architecture according to the classification result output by the function screening model.

[0120] Input the functional topology diagram converted from the functional units of the target terminal into the function screening model. The function screening model extracts the features in the functional topology diagram and identifies the functional units that are not adapted to the target terminal. After the non-adapted functional units are identified, the non-adapted functional units are deleted from the target terminal to ensure the accuracy of the functional architecture in the target terminal and reduce the number of unnecessary data error alarms in subsequent processing.

[0121] In some embodiments, when it is determined that there is a target terminal with a running error in the target terminal, it is necessary to visually display the functional unit so that the user can maintain and upgrade the functional unit. Please refer to Figure 4 , Figure 4 This is the schematic flow chart for visually displaying the error functional unit in this embodiment.

[0122] As Figure 4 shown, after S150 includes:

[0123] S161. Extract the first error functional unit in the target terminal according to the error information;

[0124] When any functional test data verification fails, the server side sends verification error information to the target terminal. The verification error information includes: which functional unit of the target terminal and the information that a certain parameter in the functional unit is incorrect.

[0125] Therefore, when the verification error information is obtained, after parsing the verification error information, the first error functional unit with a running error in the target terminal can be obtained.

[0126] S162. Determine the target node of the first error functional unit in the functional topology diagram;

[0127] Each functional unit in the functional architecture is transformed into a functional graph, and the functional unit corresponding to the functional graph is marked in each functional graph. Therefore, in the functional topology graph, there is also a functional graph corresponding to the first error functional unit, and the functional graph corresponding to the first error functional unit is defined as the target node.

[0128] S163. Differentially display the target node in the functional topology graph, and associatively store the verification error information with the differentially displayed target node.

[0129] The differential display of the functional graph represented by the target node can be achieved in the following ways: differential display by color. For example, in the functional topology graph, the functional images corresponding to other functional units are all black, while the color of the functional graph corresponding to the target node is modified to red or other colors different from black. In some embodiments, the differential display method can be image differential display. For example, in the functional topology graph, the functional images corresponding to other functional units are all square, while the shape of the functional graph corresponding to the target node is modified to circular or other shapes different from square. In some embodiments, the differential display method can be identification differential display. For example, an "X" shape is marked around the shape of the functional graph corresponding to the target node to distinguish the functional image of the target node from the functional graphs of other functional units.

[0130] In some embodiments, when there are many shapes or colors of the functional graphs in the functional topology graph, the server needs to select the most discriminative graph or color from the numerous shapes and colors to represent the target node, making the display of the target node more prominent.

[0131] Specifically, a shape screening model is constructed on the server side. The shape screening model needs to be pre-trained, that is, by collecting a large number of positive and negative samples of graphs related to topological graphs, and training the initial neural network model in a supervised training manner. When the number of training times of the shape screening model reaches a predetermined number of times after training is completed or it is determined through verification samples that the judgment accuracy rate of the shape screening model is greater than the set accuracy rate threshold, the shape screening model is trained to convergence. The shape screening model trained to the convergence state can screen out the graph shape or graph color with the greatest difference from the input graph in the set graph database according to the shape and color of the input graph. The shape screening model in this embodiment can be obtained by (but not limited to): a convolutional neural network model, a deep convolutional neural network model, a recurrent neural network model, or a variant model of any one of the above neural network models.

[0132] Before model screening, the collected functional topology diagrams are split, and the diagrams are classified according to the shape and color of the diagrams, that is, the diagrams with the same shape and color are classified into one category, and the set of diagrams obtained by classification is the node diagram set.

[0133] The node diagram set is input into the shape screening model, and the shape screening model extracts features, and calculates the feature distance between the above features and the diagram features in the diagram database, and outputs the diagram with the largest feature distance as the classification result.

[0134] After differential display, the target node and the verification error information need to be associated and stored so that the user can obtain the detailed information of the verification error information after clicking on the target node. The way of associated storage is to store through a data linked list. A data linked list is a linear storage structure that is physically non-continuous, and the logical order of data elements is linked by pointers in the linked list. The linked list consists of a series of nodes (each element in the linked list is called a node), and the nodes are dynamically generated (malloc) during operation. Each node includes two parts: one is the data field for storing data elements, and the other is the pointer field for storing the address of the next node. In this embodiment, the verification error information is stored in the data field, and the address of the target node is stored in the pointer field. However, the way of associated storage is not limited to storing through a data linked list. In some embodiments, the target node and the verification error information are stored in the form of key-value pairs.

[0135] In some embodiments, neural network models need to be used to assist in differential display. Please refer to Figure 5 , Figure 5 which is the schematic flow diagram of differential display through neural network models in this embodiment.

[0136] As Figure 5 shown, S163 includes:

[0137] S164. Collect the node diagram set of the functional topology diagram, where the node diagram set includes diagram shapes and diagram colors;

[0138] Before model screening, the collected functional topology diagrams are split, and the diagrams are classified according to the shape and color of the diagrams, that is, the diagrams with the same shape and color are classified into one category, and the set of diagrams obtained by classification is the node diagram set.

[0139] S165. Input the diagram shapes and diagram colors into a preset shape screening model, where the shape screening model is a neural network model that has been pre-trained to a convergent state and is used to generate differential diagrams according to existing diagram shapes and diagram colors;

[0140] Build a shape screening model on the server side. The shape screening model needs to be pre-trained, that is, by collecting a large number of positive and negative samples of graphics related to topological graphics, and training the initial neural network model through supervised training. When the number of training times of the shape screening model reaches the predetermined number of times after training is completed, or when it is determined through the verification samples that the judgment accuracy rate of the shape screening model is greater than the set accuracy rate threshold, then the shape screening model is trained to convergence. The shape screening model trained to the convergence state can screen out the graphic shape or graphic color with the greatest difference from the input graphic in the set graphic database according to the shape and color of the input graphic. The shape screening model in this embodiment can be obtained by training (but not limited to): a convolutional neural network model, a deep convolutional neural network model, a recurrent neural network model, or a variant model of any one of the above neural network models.

[0141] S166. Differentially display the target node according to the classification result output by the shape screening model, and associatively store the verification error information with the differentially displayed target node according to the data linked list.

[0142] Input the node graphic set into the shape screening model, extract features by the shape screening model, and calculate the feature distance between the above features and the graphic features in the graphic database, and output the graphic with the largest feature distance as the classification result.

[0143] After differential display, it is necessary to associatively store the target node and the verification error information so that the user can obtain the detailed information of the verification error information after clicking on the target node. The way of associative storage is to store through a data linked list. A data linked list is a linear storage structure that is physically non-continuous, and the logical order of data elements is realized through the pointer link order in the linked list. The linked list consists of a series of nodes (each element in the linked list is called a node), and the nodes are dynamically generated (malloc) during operation. Each node includes two parts: one is the data field for storing data elements, and the other is the pointer field for storing the address of the next node. In this embodiment, the verification error information is stored in the data field, and the address of the target node is stored in the pointer field.

[0144] In some embodiments, when an error functional unit appears on the target terminal, in order to check whether the error functional unit is caused by accidental factors, it is necessary to separately test the error functional unit for accidental risk investigation. Please refer to Figure 6 , Figure 6 which is the schematic flow chart of testing the error functional unit in this embodiment.

[0145] As Figure 6 shown, after S160 includes:

[0146] S171. Extract the second error functional unit in the target terminal according to the verification error information;

[0147] When any functional test data verification fails, the server sends verification error information to the target terminal. The verification error information includes: which functional unit of the target terminal and information about an error in a certain parameter in that functional unit.

[0148] Therefore, after obtaining the verification error information and parsing it, the second error functional unit with a running error in the target terminal can be obtained. Among them, the second error functional unit and the first error functional unit can be the same functional unit or different units. To avoid confusion, they are distinguished by the first and second.

[0149] S172. Collect the environmental information of the second error functional unit and construct a test container corresponding to the second error functional unit according to the environmental information;

[0150] Read the environmental information of the second error functional unit. The environmental information includes the application type, application configuration parameters, API interfaces of task threads, and SDK interfaces of the second error functional unit.

[0151] Collect the running environment of the target terminal. The collection method is: extract through the task log of the target terminal. The task log of the target terminal records the parameter data during the test process of the target terminal, among which, it includes the environmental information of the second error functional unit. Through the fields of the second error functional unit, the environmental information of the second error functional unit can be extracted from the task log.

[0152] After obtaining the environmental information, it is necessary to start a running instance that simulates this environmental information. This running instance is the test container. The test container shares the operating system / kernel of its host. That is, the test container shares the operating system / kernel of the server side. After only sending the application type and application configuration parameters for executing tasks in the second error functional unit to the test container, the test container can simulate the running environment of the target terminal when executing user instructions.

[0153] Specifically, the application type corresponds to the type of the application program for the error task executed by the second error functional unit. Therefore, after obtaining the application type, the application file (installation package) of this application program can be obtained. After obtaining the installation package of the application program, it is necessary to configure the various parameters in the installation package so that the installation package can adapt to the running environment of the second error functional unit when it is run. After the parameter configuration of the installation package is completed, the installation package is converted in format and compressed to generate an image file. After the image file is sent to an empty container on the server side for installation, the empty container becomes the test container corresponding to the second error functional unit.

[0154] S173. Adapt the test cases corresponding to the second error functional unit in a preset test database;

[0155] In this embodiment, a test database is built on the server side, and the test cases corresponding to all functional units are stored in the test database. Moreover, each test case in the test database uses itself and its corresponding functional unit as an index label. After obtaining the second error functional unit, the test cases corresponding to the second error functional unit can be retrieved in the test database. And this test case is the test case that the second error functional unit executes when the target terminal is tested.

[0156] S174. Input the test cases into the test container for running tests, and generate the test results of the second error functional unit according to the running test results.

[0157] Input the test cases corresponding to the second error functional unit into the test container. The test container runs this test case, and the result obtained from the running is the test result. If this test result is the same as the functional test data corresponding to the second error functional unit in the target terminal, it indicates that there are indeed parameter errors in the test cases or the second error functional unit, indicating that this test case cannot be run in the second error functional unit, and the running error is not an accidental error. If the test result is different from the functional test data corresponding to the second error functional unit in the target terminal, and the test result indicates that the test case runs successfully, it means that the failure of the test case to execute is only an accidental error, and there is no need to troubleshoot errors for the second error functional unit and the test cases, improving the efficiency of error troubleshooting.

[0158] In some embodiments, to perform a simulation test on the second error functional unit, a test container corresponding to the second error functional unit needs to be built. Please refer to Figure 7 , Figure 7 which is a schematic flowchart of generating a test container for this embodiment.

[0159] As Figure 7 shown, S172 includes:

[0160] S175. Collect the environmental information of the second error functional unit, where the environmental information includes the application type and application configuration parameters of the second error functional unit;

[0161] Read the environmental information of the second error functional unit. The environmental information includes the application type, application configuration parameters, API interfaces of task threads, and SDK interfaces of the second error functional unit.

[0162] Collect the operating environment of the target terminal. The collection method is as follows: extract it from the task log of the target terminal. The task log of the target terminal records the parameter data of the target terminal during the test process, including the environment information of the second error function unit. Through the fields of the second error function unit, the environment information of the second error function unit can be extracted from the task log.

[0163] S176. Call the corresponding installation file according to the application type, and configure the installation file according to the application configuration parameters to generate an image file.

[0164] The application type corresponds to the type of the application program for the second error function unit to execute the error task. Therefore, when the application type is obtained, the application file (installation package) of the application program can be obtained. After obtaining the installation package of the application program, the parameters in the installation package need to be configured so that the installation package can adapt to the operating environment of the second error function unit when it is run. After the parameters of the installation package are configured, the installation package is converted in format and compressed to generate an image file.

[0165] S177. Input the image file into a preset blank container to generate the test container.

[0166] After sending the image file to the blank container on the server side for installation, the blank container becomes the test container corresponding to the second error function unit.

[0167] To solve the above technical problems, an embodiment of the present invention also provides a test data management device. For details, please refer to Figure 8 , Figure 8 which is the basic structure schematic diagram of the test data management device in this embodiment.

[0168] As Figure 8 shown, a test data management device includes: a collection module 110, a configuration module 120, an extraction module 130, a processing module 140, and an execution module. Among them, the collection module 110 is used to collect the functional architecture of the target terminal, where the functional architecture is composed of multiple functional units; the configuration module 120 is used to configure the verification rules of each functional unit based on the functional architecture and a preset rule database, where the rule database is used to store the verification rules corresponding to various functional units; the extraction module 130 is used to extract the test data of the target terminal and split the test data into multiple functional test data according to each functional unit; the processing module 140 is used to perform data verification on the corresponding functional test data according to the verification rules of each functional unit; the execution module 150 is used to send a verification error message to the target terminal when any one of the functional test data fails the verification.

[0169] When the test data management device conducts the audit of the test data of the target terminal, it obtains the functional units that make up the target terminal by invoking the functional architecture of the target terminal. Then, it configures the inspection rules for each type of functional unit according to the type of each functional unit, and splits the test data of the target terminal by function. It verifies the test data of the corresponding functional unit using the inspection rules for each type of functional unit, and extracts the functional units that fail the verification. This method can pay attention to whether the data generated by the most basic functional units that make up the target terminal is compliant, can verify various index data generated by the test in detail, avoids the problem of missing test scenarios caused by only focusing on the test results, improves the coverage of test scenarios in test verification, and makes the test results more real and accurate.

[0170] In some embodiments, the test data management device further includes:

[0171] A first reading sub-module, configured to read a plurality of call interfaces of the target terminal;

[0172] A first processing sub-module, configured to match the functional units corresponding to each call interface based on the call interface and a preset functional database, wherein the functional database stores the functional units corresponding to each type of call interface;

[0173] A first execution sub-module, configured to topologically connect the matched functional units according to the mutual call relationship between the functional units to generate the functional architecture.

[0174] In some embodiments, the test data management device further includes:

[0175] A first conversion sub-module, configured to convert the functional architecture into a functional topology diagram;

[0176] A second processing sub-module, configured to input the functional topology diagram into a preset functional screening model, wherein the functional screening model is a neural network model that has been pre-trained to a converged state and is used to screen out non-matching functional units;

[0177] A second execution sub-module, configured to delete the non-matching functional units in the functional architecture according to the classification result output by the functional screening model.

[0178] In some embodiments, the test data management device further includes:

[0179] A first extraction sub-module, configured to extract the first faulty functional unit in the target terminal according to the error information;

[0180] A third processing sub-module, configured to determine the target node of the first faulty functional unit in the functional topology diagram;

[0181] A third execution sub-module, configured to distinctively display the target node in the functional topology graph, and associatively store the verification error information with the distinctively displayed target node.

[0182] In some embodiments, the test data management device further includes:

[0183] A first acquisition sub-module is configured to acquire a node graphic set of the functional topology graph, where the node graphic set includes graphic shapes and graphic colors;

[0184] A fourth processing sub-module is configured to input the graphic shapes and graphic colors into a preset shape screening model, where the shape screening model is a neural network model that has been pre-trained to a convergent state and is used to generate a distinct graphic based on existing graphic shapes and graphic colors;

[0185] A fourth execution sub-module is configured to distinctively display the target node according to the classification result output by the shape screening model, and associatively store the verification error information with the distinctively displayed target node according to a data linked list.

[0186] In some embodiments, the test data management device further includes:

[0187] A second extraction sub-module is configured to extract a second error function unit in the target terminal according to the verification error information;

[0188] A second acquisition sub-module is configured to acquire environment information of the second error function unit, and construct a test container corresponding to the second error function unit according to the environment information;

[0189] A fifth processing sub-module is configured to adapt a test case corresponding to the second error function unit in a preset test database;

[0190] A fifth execution sub-module is configured to input the test case into the test container for running tests, and generate a test result of the second error function unit according to the running test result.

[0191] In some embodiments, the test data management device further includes:

[0192] A third acquisition sub-module is configured to acquire environment information of the second error function unit, where the environment information includes an application type and application configuration parameters of the second error function unit;

[0193] A sixth processing sub-module is configured to call a corresponding installation file according to the application type, and configure the installation file according to the application configuration parameters to generate an image file;

[0194] The sixth execution sub-module is configured to input the mirror file into a preset blank container to generate the test container.

[0195] To solve the above technical problems, an embodiment of the present invention further provides a computer device. Specifically, please refer to Figure 9 , Figure 9 which is the basic structural block diagram of the computer device in this embodiment.

[0196] As Figure 9 shown, it is a schematic internal structure diagram of a computer device. The computer device includes a processor, a non-volatile storage medium, a memory, and a network interface connected through a system bus. Among them, the non-volatile storage medium of the computer device stores an operating system, a database, and computer-readable instructions. The control information sequence can be stored in the database. When the computer-readable instructions are executed by the processor, the processor can implement a test data management method. The processor of the computer device is used to provide computing and control capabilities to support the operation of the entire computer device. The memory of the computer device can store computer-readable instructions. When the computer-readable instructions are executed by the processor, the processor can execute a test data management method. The network interface of the computer device is used to connect and communicate with a terminal. Those skilled in the art can understand that Figure 9 the structure shown in

[0197] is only a block diagram of some structures related to the solution of this application, and does not constitute a limitation on the computer device to which the solution of this application is applied. The specific computer device may include more or fewer components than those shown in the figure, or combine certain components, or have a different component layout. Figure 8 In this embodiment, the processor is used to execute the specific functions of the acquisition module 110, the configuration module 120, the extraction module 130, the processing module 140, and the execution module 150 in

[0198] When a computer device conducts a review of the test data of a target terminal, it obtains the functional units that make up the target terminal by invoking the functional architecture of the target terminal. Then, it configures the inspection rules for each type of functional unit according to the type of each medium-capacity unit, splits the test data of the target terminal by function, validates the test data of the corresponding functional unit using the inspection rules for each type of functional unit, and extracts the functional units that fail the validation. This method can pay attention to whether the data generated by the most basic functional units that make up the target terminal is compliant, can conduct a detailed validation of various types of index data generated by the test, avoids the problem of only focusing on the test results and causing the omission of test scenarios, improves the coverage of test scenarios in test validation, and makes the test results more real and accurate.

[0199] The present invention also provides a computer storage medium. When computer-readable instructions are executed by one or more processors, the one or more processors are caused to execute the steps of the test data management method according to any of the above embodiments.

[0200] Those of ordinary skill in the art can understand that all or part of the processes of implementing the methods in the above embodiments can be completed by instructing relevant hardware through a computer program. The computer program can be stored in a computer-readable storage medium. When the program is executed, it can include the processes of the embodiments of the above methods. Among them, the aforementioned storage medium can be a non-volatile storage medium such as a magnetic disk, an optical disc, a read-only memory (ROM), etc., or a random access memory (RAM), etc.

[0201] Those skilled in the art of this technology can understand that the steps, measures, and solutions in the various operations, methods, and processes discussed in this application can be alternated, changed, combined, or deleted. Further, the other steps, measures, and solutions in the various operations, methods, and processes discussed in this application can also be alternated, changed, rearranged, decomposed, combined, or deleted. Further, the steps, measures, and solutions in the prior art that are the same as those disclosed in the various operations, methods, and processes in this application can also be alternated, changed, rearranged, decomposed, combined, or deleted.

[0202] The above are only some embodiments of the present application. It should be noted that for those of ordinary skill in the art of this technology, without departing from the principle of the present application, several improvements and refinements can be made, and these improvements and refinements should also be regarded as the protection scope of the present application.

Claims

1. A test data management method, characterized in that, Including: Collect the functional architecture of the target terminal, where the functional architecture consists of multiple functional units; Based on the functional architecture and a preset rule database, configure the verification rules for each functional unit, where the rule database is used to store the verification rules corresponding to various types of functional units; Extract the test data of the target terminal, and split the test data according to each functional unit to generate multiple functional test data; Perform data verification on the corresponding functional test data according to the verification rules of each functional unit; When any one of the functional test data fails to be verified, send a verification error message to the target terminal; Before configuring the verification rules for each functional unit based on the functional architecture and a preset rule database, it includes: Convert each functional unit in the functional architecture into a functional graph, and mark the functional unit corresponding to the functional graph in each functional graph. Then, according to the mutual call relationship between the functional units, connect the functional graphs to generate a functional topology graph of the functional units; Input the functional topology graph into a preset functional screening model, where the functional screening model is a neural network model that has been pre-trained to a convergent state and is used to screen non-conforming functional units; Delete the non-conforming functional units in the functional architecture according to the classification result output by the functional screening model.

2. The test data management method according to claim 1, wherein The collection of the functional architecture of the target terminal includes: Read multiple call interfaces of the target terminal; Based on the call interfaces and a preset functional database, match the functional units corresponding to each call interface, where the functional database stores the functional units corresponding to various types of call interfaces; According to the mutual call relationship between the functional units, perform topological connection on the matched functional units to generate the functional architecture.

3. The test data management method according to claim 1, characterized in that After sending the verification error message to the target terminal when any one of the functional test data fails to be verified, it includes: Extract the first error functional unit in the target terminal according to the verification error message; Determine the target node of the first error functional unit in the functional topology graph; Differentially display the target node in the functional topology graph, and associatively store the verification error message with the differentially displayed target node.

4. The test data management method according to claim 3, characterized in that The differentially displaying the target node in the functional topology graph and associatively storing the verification error message with the differentially displayed target node includes: Collect the node graph set of the functional topology graph, where the node graph set includes graph shapes and graph colors; Input the graph shapes and graph colors into a preset shape screening model, where the shape screening model is a neural network model that has been pre-trained to a convergent state and is used to generate a differential graph according to the existing graph shapes and graph colors; Differentially display the target node according to the classification result output by the shape screening model, and associatively store the verification error message with the differentially displayed target node according to the data linked list.

5. The test data management method according to claim 1, characterized in that After sending the verification error message to the target terminal when any one of the functional test data fails to be verified, it includes: Extract the second error functional unit in the target terminal according to the verification error message; Collect the environmental information of the second error functional unit, and construct a test container corresponding to the second error functional unit according to the environmental information; Adapt the test cases corresponding to the second error functional unit in a preset test database; Input the test cases into the test container for running tests, and generate the test results of the second error functional unit according to the running test results.

6. The test data management method according to claim 5, wherein The step of collecting the environmental information of the second error functional unit and constructing a test container corresponding to the second error functional unit according to the environmental information includes: Collect the environmental information of the second error functional unit, where the environmental information includes the application type and application configuration parameters of the second error functional unit; Call the corresponding installation file according to the application type, and configure the installation file according to the application configuration parameters to generate an image file; Input the image file into a preset blank container to generate the test container.

7. A test data management device, characterized in that, Includes: A collection module for collecting the functional architecture of the target terminal, where the functional architecture consists of multiple functional units; A configuration module for configuring the verification rules of each functional unit based on the functional architecture and a preset rule database, where the rule database is used to store the verification rules corresponding to various functional units; An extraction module for extracting the test data of the target terminal and splitting the test data into multiple functional test data according to each functional unit; A processing module for performing data verification on the corresponding functional test data according to the verification rules of each functional unit; An execution module for sending a verification error message to the target terminal when any one of the functional test data verification fails; A first conversion sub-module for converting each functional unit in the functional architecture into a functional graph, marking the functional unit corresponding to the functional graph in each functional graph, and then connecting the functional graphs according to the mutual call relationship between the functional units to generate a functional topology graph of the functional units; A second processing sub-module for inputting the functional topology graph into a preset functional screening model, where the functional screening model is pre-trained to a convergent state and is a neural network model for screening non-adapted functional units; A second execution sub-module for deleting the non-adapted functional units in the functional architecture according to the classification result output by the functional screening model.

8. A computer device, characterized in that, Includes a memory and a processor. When the computer-readable instructions stored in the memory are executed by the processor, the processor executes the steps of the test data management method according to any one of claims 1 to 6.

9. A computer storage medium, characterized in that, When the computer-readable instructions are executed by one or more processors, the one or more processors execute the steps of the test data management method according to any one of claims 1 to 6.

Images