Test case generation method and device, electronic equipment, medium and product

Abstract

The application discloses a test case generation method and device, electronic equipment, medium and product, and relates to the technical field of software testing. The trained operation behavior path generation model is trained according to a development test operation behavior path library and a user operation behavior path library, can take into account standard procedures and user real operation scenarios, and generates a plurality of initial operation behavior paths. According to the plurality of initial operation behavior paths, a plurality of final operation behavior paths are obtained; the final operation behavior paths are converted into graph-form operation behavior paths, and then test cases are generated according to preset application program interfaces of each operation step, the accuracy of the test cases is improved, and therefore the user experience is improved. From receiving a test case generation request to outputting the plurality of initial operation behavior paths, obtaining the plurality of final operation behavior paths, converting into the graph-form operation behavior paths, and then generating the test cases, the full-automation process is realized, and the test efficiency is improved.

Description

Technical Field

[0001] This application relates to the field of software testing technology, and in particular to methods, apparatus, electronic devices, media, and products for generating test cases. Background Technology

[0002] With the rapid development of software technology, modern software systems are characterized by cross-platform deployment, increased functional complexity, and diversified user operations. In software development, the testing phase requires testing with test cases to ensure the correctness, stability, and reliability of software functionality and user experience.

[0003] Currently, traditional testing methods involve testers writing test cases during the test script writing phase. However, this method reduces testing efficiency and suffers from limited test case coverage and inaccuracies, leading to defects remaining after software release and negatively impacting user experience. Summary of the Invention

[0004] This application provides a method, apparatus, electronic device, medium, and product for generating test cases, in order to at least address the problems of low testing efficiency and poor user experience in related technologies.

[0005] This application provides a method for generating test cases, comprising: receiving a test case generation request sent by a test terminal; inputting the test case generation request into a trained operation behavior path generation model, such that the trained operation behavior path generation model outputs multiple initial operation behavior paths that meet preset test requirements based on the test case generation request; wherein the trained operation behavior path generation model is trained based on a development test operation behavior path library and a user operation behavior path library; obtaining multiple final operation behavior paths based on the multiple initial operation behavior paths; wherein each operation behavior path includes multiple operation steps; converting each final operation behavior path into a graph-based operation behavior path to obtain multiple graph-based operation behavior paths; and generating test cases for each graph-based operation behavior path based on preset application interfaces for each operation step to obtain multiple test cases.

[0006] This application also provides a test case generation device, comprising: a receiving module for receiving a test case generation request sent by a test terminal; a first generation module for inputting the test case generation request into a trained operation behavior path generation model, such that the trained operation behavior path generation model outputs multiple initial operation behavior paths that meet preset test requirements based on the test case generation request; wherein the trained operation behavior path generation model is trained based on a development test operation behavior path library and a user operation behavior path library; an acquisition module for acquiring multiple final operation behavior paths based on the multiple initial operation behavior paths; wherein the operation behavior path includes multiple operation steps; a conversion module for converting each final operation behavior path into a graph-based operation behavior path, resulting in multiple graph-based operation behavior paths; and a second generation module for generating test cases for each graph-based operation behavior path based on preset application interface of each operation step, thereby obtaining multiple test cases.

[0007] This application also provides an electronic device, including: a memory for storing a computer program; and a processor for implementing the steps of the test case generation method described above when executing the computer program.

[0008] This application also provides a computer-readable storage medium storing a computer program, wherein when the computer program is executed by a processor, it implements the steps of any of the above-described test case generation methods.

[0009] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of any of the above-described test case generation methods.

[0010] This application demonstrates that the trained operation behavior path generation model is derived from both a development / testing operation behavior path library and a user operation behavior path library. The development / testing library covers the operation behavior paths of developers and testers, balancing standard and regulated procedures. The user operation behavior path library covers the operation behavior paths of users, balancing real-world usage scenarios. Therefore, the multiple initial operation behavior paths output by the trained model can accommodate both standard procedures and real-world usage scenarios, avoiding the limitations of single-source operation behavior paths and enabling subsequent test cases to cover more comprehensive test scenarios. The final operation behavior paths are then converted into graphical representations for a more intuitive display. Based on these graphical operation behavior paths, test cases are generated according to the pre-defined application interfaces for each operation step, improving the accuracy of the test cases. By increasing the coverage and accuracy of test cases, defects are avoided after software release, thus improving the user experience. The entire process of receiving test case generation requests, from the trained operation behavior path generation model outputting multiple initial operation behavior paths, obtaining multiple final operation behavior paths, converting them into graph-based operation behavior paths, and finally generating test cases, transforms the traditional model that relies on manual test case writing into automated processing, improving testing efficiency. Furthermore, on the one hand, when dealing with operation behavior paths containing many steps, using the shortest operation behavior path allows for more effective focus on test issues, ensuring efficiency and further improving testing efficiency. On the other hand, by considering the preset weights of each operation step, the weights of each initial operation behavior path are obtained. Based on the weights of each initial operation behavior path, the multiple initial operation behavior paths are sorted in descending order. From the sorted initial operation behavior paths, starting from the first initial operation behavior path, a preset number of operation behavior paths are extracted to obtain high-weight operation behavior paths. These high-weight operation behavior paths cover more operation steps, further improving test coverage. Attached Figure Description

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

[0012] Figure 1 A schematic diagram illustrating a scenario for the test case generation method provided in this application embodiment;

[0013] Figure 2A flowchart illustrating the test case generation method provided in the embodiments of this application. Figure 1 ;

[0014] Figure 3 A flowchart illustrating the test case generation method provided in the embodiments of this application. Figure 2 ;

[0015] Figure 4 A schematic diagram of the structure of the test case generation device provided in the embodiments of this application;

[0016] Figure 5 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0017] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the protection scope of this application.

[0018] It should be noted that, in the description of this application, the terms "comprising," "including," or any other variations thereof are 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 a process, method, article, or apparatus. The terms "first," "second," etc., in this application are used to distinguish similar objects and are not used to describe a specific order or sequence.

[0019] With the rapid development of software technology, modern software systems exhibit characteristics such as cross-platform deployment, increased functional complexity, and diversified user operations. In software development, the testing phase requires testing with test cases to ensure the correctness, stability, and reliability of software functionality and user experience. Currently, traditional testing methods involve testers writing test cases during the test script writing phase. However, this method reduces testing efficiency and suffers from limited test case coverage and inaccuracies, leading to defects remaining after software release and diminishing the user experience.

[0020] To address the aforementioned technical issues, this application proposes the following concept: by improving the coverage and accuracy of test cases, defects can be avoided after software release, thereby enhancing the user experience. Specifically, a trained operation behavior path generation model is used to output multiple initial operation behavior paths based on test case generation requests. This model is trained using a development / testing operation behavior path library and a user operation behavior path library. The development / testing library covers the operation behavior paths of developers and testers, balancing standard and regulated procedures. The user operation behavior path library covers the operation behavior paths of users, balancing real-world usage scenarios. Therefore, the multiple initial operation behavior paths output by the trained model can balance standard procedures with real-world usage scenarios, avoiding the limitations of single-source operation behavior paths and enabling subsequent test cases to cover more comprehensive test scenarios. Based on these initial operation behavior paths, multiple final operation behavior paths are obtained. The final operation path is transformed into a graph-based operation path, providing a clear visual representation. Based on these graph-based operation paths, test cases are generated according to the pre-defined application interfaces for each operation step, improving the accuracy of the test cases. The entire process—from receiving test case generation requests, to the trained operation path generation model outputting multiple initial operation paths, obtaining multiple final operation paths, transforming them into graph-based operation paths, and finally generating test cases—automates the traditional manual test case writing process, significantly improving testing efficiency.

[0021] To enable those skilled in the art to better understand the present application, the present application will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0022] The specific application environment architecture or specific hardware architecture on which the execution of the test case generation method depends is described here.

[0023] refer to Figure 1 , Figure 1 This is a schematic diagram illustrating a scenario for the test case generation method provided in an embodiment of this application. For example... Figure 1 As shown, it includes a test terminal 101 and an electronic device 102.

[0024] In this embodiment, the test terminal 101 sends a test case generation request to the electronic device 102. The electronic device 102 inputs the test case generation request into a trained operation behavior path generation model, causing the trained operation behavior path generation model to output multiple initial operation behavior paths that meet preset test requirements based on the test case generation request. The trained operation behavior path generation model is trained using a development test operation behavior path library and a user operation behavior path library. Based on the multiple initial operation behavior paths, multiple final operation behavior paths are obtained. Each operation behavior path includes multiple operation steps. Each final operation behavior path is converted into a graph-based operation behavior path, resulting in multiple graph-based operation behavior paths. For each graph-based operation behavior path, test cases are generated based on the preset application interface of each operation step, resulting in multiple test cases. The electronic device 102 sends the multiple test cases to the test terminal 101, enabling the test terminal 101 to perform tests based on the multiple test cases.

[0025] Figure 2 A flowchart illustrating the test case generation method provided in the embodiments of this application. Figure 1 ,like Figure 2 As shown, embodiments of this application provide a method for generating test cases, which is described in detail below:

[0026] S201: Receive test case generation request sent by the test terminal.

[0027] In this embodiment, when the testing end needs to test any function or reproduce a problem, it needs to generate test cases for testing. The test case generation request includes the target test task.

[0028] S202: Input the test case generation request into the trained operation behavior path generation model, so that the trained operation behavior path generation model outputs multiple initial operation behavior paths that meet the preset test requirements based on the test case generation request; wherein the trained operation behavior path generation model is trained based on the development test operation behavior path library and the user operation behavior path library.

[0029] The operation behavior path refers to the sequence of pages, functions clicked, and operations performed by users or development and testing personnel during the use of software.

[0030] Specifically, the process involves obtaining the target test task from the test case generation request; obtaining multiple operation behavior paths corresponding to the target test task based on the development test operation behavior path library and the user operation behavior path library; and selecting multiple initial operation behavior paths from the multiple operation behavior paths corresponding to the target test task based on preset test requirement conditions.

[0031] In this embodiment, paths related to the target test task are selected from the development test operation behavior path library and the user operation behavior path library; from the multiple operation behavior paths corresponding to the target test task, operation behavior paths that meet the preset test requirements are retained to form multiple initial operation behavior paths.

[0032] In this embodiment, the preset test requirements cover multiple dimensions, including software functionality, user frequency, failure rate, and performance metrics. Simultaneously, reasonable weights are assigned to different preset test requirements to reflect their importance in the testing process. The test requirements are dynamically adjusted based on actual testing needs and model training results, improving the relevance and effectiveness of the testing and achieving dynamic adjustment.

[0033] In subsequent embodiments, the training process of the operation behavior path generation model, the development and testing of the operation behavior path library, and the user operation behavior path library are described in detail.

[0034] S203: Based on multiple initial operation behavior paths, obtain multiple final operation behavior paths; wherein the operation behavior path includes multiple operation steps.

[0035] Specifically, step S203 includes Sa~Sc:

[0036] Sa: Obtain the shortest operation path based on multiple initial operation paths.

[0037] Specifically, multiple initial operation behavior paths are deduplicated to obtain multiple deduplicated initial operation behavior paths; a directed graph of operation behavior paths is constructed based on the multiple deduplicated initial operation behavior paths; the starting operation step node and the ending operation step node are obtained from the directed graph of operation behavior paths; and the shortest operation behavior path between the starting operation step node and the ending operation step node is obtained from the directed graph of operation behavior paths.

[0038] In this embodiment, the shortest operation path represents the simplest operation steps for testing any function or reproducing a problem. When dealing with operation scenarios involving many operation steps, it can more effectively focus on the problem and ensure efficiency.

[0039] In this embodiment, multiple initial operation paths are deduplicated to avoid redundant calculations; a directed graph of operation paths is constructed to integrate the steps and sequence relationships of the multiple deduplicated initial operation paths; and the shortest operation path between the starting step node and the ending step node is found based on the directed graph of operation paths.

[0040] Alternatively, algorithms such as dynamic programming or genetic algorithms can be used to determine the shortest operation path.

[0041] Sb: Based on the preset weights of each operation step, a preset number of operation behavior paths are selected from multiple initial operation behavior paths.

[0042] Specifically, based on the preset weights of each operation step, the weights of each initial operation behavior path are obtained; based on the weights of each initial operation behavior path, the multiple initial operation behavior paths are sorted in descending order to obtain multiple sorted initial operation behavior paths; among the multiple sorted initial operation behavior paths, starting from the first initial operation behavior path, a preset number of operation behavior paths are extracted.

[0043] The preset weights for each operation step are pre-set by the development and testing personnel based on a comprehensive consideration of factors such as the importance of the operation content, the frequency of user use, the level of risk, and the frequency of current problems.

[0044] In this embodiment, the preset weights of multiple operation steps in each initial operation path are summed to obtain the weight of each initial operation path. The paths are then sorted in descending order of weight, and the first preset number of operation paths are selected as high-weight operation paths. These high-weight operation paths encompass the most comprehensive set of operation steps related to the target test task, and involve a large number of related test functions, ensuring test diversity.

[0045] Sc: Based on the shortest operation path and a preset number of operation paths, multiple final operation paths are determined.

[0046] In this embodiment, the shortest operation path and a preset number of operation paths are merged to form multiple final operation paths, which balances the simplicity and comprehensiveness of the operation paths.

[0047] S204: Convert each final operation behavior path into a graph-based operation behavior path to obtain multiple graph-based operation behavior paths.

[0048] In this embodiment, the final operation paths are in the form of data, which is neither easy to read or view nor can it be run directly, and requires processing. Converting the final operation paths into an intuitive graphical form allows for a clear understanding and mastery of the sequence and process of the operation steps.

[0049] In this embodiment, the graphical representation includes a timeline graph and a node graph.

[0050] Specifically, step S204 includes Sd~Sf:

[0051] Sd: Obtain the operation content, operation page, and operation time of each operation step from each final operation behavior path.

[0052] In this embodiment, the operation content refers to the specific operations performed by the user or development and testing personnel in the software; the operation page refers to the page on which the user or development and testing personnel perform operations in the software; and the operation time refers to the time during which the user or development and testing personnel perform operations in the software.

[0053] Se: If the graph is a timeline graph, then perform the following first operation.

[0054] In this embodiment, the first operation includes: using a straight line as a time axis, marking the operation time of each operation step on the time axis to obtain multiple operation time markers; adding the operation content and operation page of each operation step to the operation time marker corresponding to each operation step on the time axis; and connecting the operation time markers corresponding to each operation step in sequence according to the order of the operation time of each operation step on the time axis to obtain a graphical operation behavior path.

[0055] For example, consider the operational behavior path of a login function malfunction. The process of converting the operation path of opening the software, entering the login page, entering the password, and submitting into a timeline diagram is as follows: Draw a horizontal straight line as the timeline, the length of which is determined by the number of operation steps; mark the starting point T0 on the left side of the timeline and the ending point T3 on the right side, with T0-T3 representing a virtual time scale for the sequence of operation steps; evenly divide the timeline according to the number of steps, marking the operation times of opening the software, entering the login page, entering the password, and submitting on the timeline, corresponding to T0, T1, T2, and T3 respectively. On the timeline, draw a preset graphic on each operation time mark, adding the operation content and operation page next to the graphic. The preset graphic can be a circle or a square, with the same size. For example, next to the T0 graphic, add the operation content and operation page of opening the software; next to the T1 graphic, add the operation content and operation page of entering the login page; next to the T2 graphic, add the operation content and operation page of entering the password; and next to the T3 graphic, add the operation content and operation page of submitting. On the timeline, T0, T1, T2, and T3 are connected sequentially with solid or dashed lines according to the order of operation time of each operation step, resulting in a graphical operation behavior path.

[0056] Sf: If the graph is a node graph, then perform the following second operation.

[0057] In this embodiment, the second operation includes: treating each operation step as a node, adding the operation content, operation page, and operation time of each operation step to the node corresponding to each operation step; and connecting the nodes corresponding to each operation step sequentially with arrows according to the order of the operation time of each operation step to obtain a graph-like operation behavior path.

[0058] For example, let's take the login function malfunction as an example. The process of converting the operation path of opening the software, entering the login page, entering the password, and submitting into a node graph is as follows: Treat opening the software, entering the login page, entering the password, and submitting as four nodes, using a pre-defined shape of uniform size. Arrange the nodes from left to right or from top to bottom according to the chronological order of the operation steps, leaving sufficient space between nodes to avoid overcrowding. Add the operation content, operation page, and operation time for each operation step to each node. For example, the first node is "opening the software," accompanied by the operation content, operation page, and operation time; the second node is "entering the login page," accompanied by the operation content, operation page, and operation time; the third node is "entering the password," accompanied by the operation content, operation page, and operation time; and the fourth node is "submitting," accompanied by the operation content, operation page, and operation time. Connect the nodes corresponding to each operation step sequentially with arrows to obtain the operation path in graph form.

[0059] Optionally, an interactive interface can be provided to allow developers and testers to adjust the display and content of the operation steps as needed.

[0060] S205: For each type of operation behavior path, generate test cases based on the preset application interface of each operation step to obtain multiple test cases.

[0061] In this embodiment, the purpose of step S205 is to convert the graph-based operation behavior path into automatically executable test cases. By associating the preset application interfaces of each operation step, the conversion from visualization to code-level logic is achieved.

[0062] In this implementation, the prerequisite for executing step S205 is to pre-define corresponding application programming interfaces (APIs) for each operation step of the software. Each operation step refers to the user or development / testing personnel through the interface, while the API refers to a test case, equivalent to a specific action on the interface. Establishing a mapping relationship between operation steps and APIs ensures that operation steps can be accurately converted into test cases.

[0063] Specifically, step S205 includes Sg~Sk:

[0064] Sg: Based on the operation behavior path in each diagram, obtain the sequence of each operation step, as well as the operation content and operation page of each operation step.

[0065] In this embodiment, the order of each operation step is determined according to the connection relationship of each operation step in the operation behavior path in the form of a graph, and the operation content and operation page of each operation step are read.

[0066] Sh: Determines whether parameter fields exist in the preset application interface for each operation step.

[0067] In this embodiment, the preset application programming interface for each operation step is set in advance according to the function to be achieved by each operation step.

[0068] In this embodiment, it is determined whether there are parameter fields in the preset application interface corresponding to each operation step, so as to provide a basis for subsequent parameter filling or direct calling.

[0069] For example, when the operation step is to open the software, the corresponding default application interface is openApp(), which has no parameter fields; when the operation step is to enter the login page, the corresponding default application interface is navigateToLoginPage(), which has no parameter fields; when the operation step is to enter the password, the corresponding default application interface is inputPassword(str), which has parameter fields; when the operation step is to submit, the corresponding default application interface is submitLoginRequest(), which has no parameter fields.

[0070] Si: If a parameter field is determined to exist, the parameter value corresponding to the parameter field is obtained from the operation content and operation page of each operation step; and the parameter value is used to replace the parameter field in the preset application interface to obtain the first application interface to be called for each operation step.

[0071] For example, inputPassword(str) has a parameter field, str, which represents the password to be entered. The password to be entered, such as password, is obtained from the operation content and the operation page. Replace str with password, and use inputPassword(password) as the first application interface to be called.

[0072] Optionally, when a parameter field requires page context information, it can be extracted from the operation page. For example, if the operation page is the user center page, and the default user ID is user_1001, then user_1001 can be extracted from the operation page information when user parameters are needed.

[0073] Sj: If it is determined that no parameter field exists, the preset application interface will be used as the second application interface to be called.

[0074] For example, if openApp() has no parameter field, then openApp() is directly used as the second application interface to be called; if navigateToLoginPage() has no parameter field, then navigateToLoginPage() is directly used as the second application interface to be called; if submitLoginRequest() has no parameter field, then submitLoginRequest() is directly used as the second application interface to be called.

[0075] Sk: Assemble the first or second application programming interface to be called for each operation step according to the order of operation steps, and generate test cases.

[0076] For example, based on the order of opening the software, entering the login page, entering the password, and submitting, the test cases generated after assembling the first application programming interface (API) or the second API corresponding to each operation step are as follows:

[0077] {

[0078] "Use Case ID":"LoginCase_001",

[0079] "Test Objective": "Verify the process of entering and submitting the password on the login page",

[0080] "Execution steps":[

[0081] "openApp()",

[0082] "navigateToLoginPage()",

[0083] "inputPassword (password)"

[0084] "submitLoginRequest()"

[0085] ],

[0086] Expected result: "submitLoginRequest() returns {"code":200, "msg":"Submission successful"}

[0087] }

[0088] Optionally, after obtaining the test cases, run the test cases and analyze the results.

[0089] Specifically, test cases are integrated into continuous integration or continuous deployment processes to automate their execution. During execution, the relevant operations and data within the test cases are adjusted multiple times, especially when reproducing issues. If a problem is not reproduced during testing, developers and testers can manually adjust the test cases and rerun them until the problem is reproduced, ultimately obtaining the final test cases that satisfy the test or reproduce the problem. When conditions permit, multiple test cases can be run in parallel to improve testing efficiency. The execution process and results of the test cases are recorded in detail for subsequent analysis and problem localization.

[0090] In this embodiment, test results are displayed in the form of charts or reports, which makes it easier for testers and management to intuitively understand the test situation, analyze the results, and adjust test cases.

[0091] Optionally, developers and testers can perform actions within the test cases through the software interface, generating action paths from event tracking data and storing them in the development and testing action path library. After software release, event tracking data for new user actions is continuously collected, converted into user action paths, and updated to the user action path library to ensure coverage of the latest scenarios. A training cycle is set, and the action path generation model is retrained based on the updated development and testing action path library and user action path library. The performance of the action path generation model before and after training is compared, and the version with better performance is retained. New test cases are generated using the trained action path generation model. This cycle of running test cases, analyzing results, updating the development and testing action path library and user action path library, and retraining the model is repeated to improve the test coverage and accuracy of test cases generated based on the action path generation model.

[0092] In summary, the trained operation behavior path generation model is derived from both the development / testing operation behavior path library and the user operation behavior path library. The development / testing library covers the operation behavior paths of developers and testers, balancing standard and regulated procedures. The user operation behavior path library covers the operation behavior paths of users, balancing real-world usage scenarios. Therefore, the multiple initial operation behavior paths output by the trained model can accommodate both standard procedures and real-world usage scenarios, avoiding the limitations of single-source operation behavior paths and enabling subsequent test cases to cover more comprehensive test scenarios. Converting the final operation behavior paths into graphical representation provides a clear visual representation. Based on these graphical operation behavior paths, test cases are generated according to the preset application interfaces for each operation step, improving the accuracy of the test cases. By increasing the coverage and accuracy of test cases, defects are avoided after software release, enhancing the user experience. The entire process of receiving test case generation requests, from the trained operation behavior path generation model outputting multiple initial operation behavior paths, obtaining multiple final operation behavior paths, converting them into graph-based operation behavior paths, and finally generating test cases, transforms the traditional model that relies on manual test case writing into automated processing, improving testing efficiency. Furthermore, on the one hand, when dealing with operation behavior paths containing many steps, using the shortest operation behavior path allows for more effective focus on test issues, ensuring efficiency and further improving testing efficiency. On the other hand, by considering the preset weights of each operation step, the weights of each initial operation behavior path are obtained. Based on the weights of each initial operation behavior path, the multiple initial operation behavior paths are sorted in descending order. From the sorted initial operation behavior paths, starting from the first initial operation behavior path, a preset number of operation behavior paths are extracted to obtain high-weight operation behavior paths. These high-weight operation behavior paths cover more operation steps, further improving test coverage.

[0093] refer to Figure 3 , Figure 3 A flowchart illustrating the test case generation method provided in the embodiments of this application. Figure 2 ,like Figure 3 The training process of the operation behavior path generation model is described in detail below:

[0094] S301: Collect embedded data.

[0095] Tracking data involves inserting tracking code (usually scripts or functions) at key interactive nodes in the software, such as clicking login, entering passwords, and submitting, to capture various behaviors and events during user or developer / tester interactions. It's crucial to ensure that the tracking code does not impact software performance or user experience. Before collecting tracking data, explicit user authorization is required, and sensitive information must be encrypted to ensure data security. User actions on the software are recorded as tracking data. In terms of content, tracking data includes user identifiers (e.g., encrypted user IDs), action content (e.g., clicked buttons and entered text), action time, current page information, and functional module information, and may include other information as needed by business requirements.

[0096] The event tracking data includes development and testing event tracking data and user event tracking data. Development and testing event tracking data is the operation data of developers and testers interacting with the software before the software is released; user event tracking data is the operation data of users interacting with the software after the software is released.

[0097] In this embodiment, before software release, during functional and boundary testing by development and testing personnel, operational data is automatically captured via embedded code and stored in real-time on the test data server. After software release, operational data is automatically captured during user usage, requiring user authorization before the data is encrypted and transmitted to the production data server. Development and testing embedded data and user embedded data are stored in separate databases to avoid data confusion.

[0098] S302: Based on the data points, obtain the development and testing operation behavior path library and the user operation behavior path library.

[0099] In this embodiment, the step of obtaining the development and testing operation behavior path library based on the tracking data includes S1~Sp:

[0100] Sl: Perform data cleaning on the development and testing event tracking data to obtain the cleaned development and testing event tracking data; the development and testing event tracking data includes the development and testing personnel identification and the operation time of the development and testing personnel.

[0101] In this embodiment, invalid data in the development and testing data points are deleted, such as data points with empty operation times and operation content that do not match any functional nodes; for duplicate data points of the same development and testing personnel, the same time, and the same operation, only one record is retained.

[0102] Sm: Divide the cleaned development and testing event tracking data according to the development and testing personnel identifiers to obtain multiple sub-event data corresponding to the development and testing personnel identifiers.

[0103] In this embodiment, the cleaned development and testing event tracking data is split into multiple sub-event data using the development and testing personnel identifier as the grouping key. Each sub-event data corresponds to the operation data of a single development and testing personnel.

[0104] Sn: For each development and tester's identifier, the corresponding sub-inclusion data is sorted according to the operation time of the development and testers to obtain the operation sequence of the development and testers.

[0105] In this embodiment, the data of each sub-tracking point is sorted in ascending order by operation time to form the operation sequence of the development and testing personnel, such as opening the software at 10:00, entering the login page at 10:01, entering the password at 10:02, and submitting at 10:03. Each element in the sequence includes the operation time, operation content, and operation page.

[0106] In this embodiment, the purpose of obtaining the operation sequence of the development and testing personnel is to determine the order in which the development and testing personnel operate the data.

[0107] So: Transform the sequence of operations performed by developers and testers into action paths for development and testing.

[0108] In this embodiment, an operation behavior path is formed according to the order of operations in the operation sequence.

[0109] In this embodiment, the development and testing operation path includes steps such as page access, function usage, and operation execution by the development and testing personnel in the software. Each operation step on the path records information such as when the development and testing personnel are on page A, clicked button A1, or processed data A2 at any given time.

[0110] Sp: Using a genetic algorithm, the development and testing operation behavior paths are extended to obtain a development and testing operation behavior path library.

[0111] In this embodiment, the development and testing operation paths are limited. To improve coverage, a genetic algorithm is introduced to expand the development and testing operation paths by simulating natural selection and genetic mutation processes, generating more related development and testing operation paths. The development and testing operation paths generated by the genetic algorithm may contain some dirty data, requiring data cleaning to ensure the legitimacy of the development and testing operation paths saved in the development and testing operation path library. The genetic algorithm operations include population initialization, selection, crossover, and mutation.

[0112] Specifically, the process involves several steps: Initializing the population: Each development and testing operation path is used as an initial individual to form the initial population for the algorithm. Selection: High-quality development and testing operation paths are selected based on the richness of the functional scenarios they cover, such as paths covering normal login and incorrect password login. Crossover: Key steps of two high-quality development and testing operation paths are crossed to generate new paths, such as entering an account, entering an incorrect password, submitting, reporting an error, re-entering the correct password, submitting again, and succeeding. Mutation: Non-critical steps in the development and testing operation paths are randomly fine-tuned, such as adding rules for viewing an account after entering an account, generating mutated paths. The initialization, selection, crossover, and compilation processes are repeated. Optionally, this can be repeated up to 20 times, and the number of repetitions can be adjusted based on actual needs. The development and testing operation paths, along with the new development and testing operation paths obtained through the genetic algorithm, together constitute the development and testing operation path library.

[0113] In this embodiment, when constructing the development and testing operation behavior path library, a structured database such as MySQL can be used for storage. The operation behavior path data can be categorized and stored according to factors such as the functional logic and operation type of the software system, facilitating subsequent querying and analysis. An efficient indexing mechanism is established for the database to improve data retrieval speed, and the path library is regularly optimized and maintained to ensure data consistency and integrity.

[0114] In this embodiment, the step of obtaining the user operation behavior path library based on the embedded data includes Sq~Su:

[0115] Sq: Perform data cleaning on the user event tracking data to obtain cleaned user event tracking data; the user event tracking data includes user identifier and user operation time.

[0116] Sr: The cleaned user tracking data is divided according to user identifiers to obtain sub-tracking data corresponding to multiple user identifiers.

[0117] Ss: For each user identifier, the sub-tracking data is sorted according to the user's operation time to obtain the user's operation sequence.

[0118] St: Converts the user's sequence of actions into a user action path.

[0119] Su: A genetic algorithm is used to expand the user operation behavior path to obtain a user operation behavior path library.

[0120] In this embodiment, the process of obtaining the user operation behavior path library is the same as the process of obtaining the development and testing operation behavior path library, and will not be described again here.

[0121] In this embodiment, user tracking data includes tracking data generated from normal operations and tracking data generated from abnormal operations. The former represents the user's usage habits, including steps and frequency, ensuring the authenticity of the data, while the latter represents leaked issues. A leaked issue may be associated with other potential undiscovered issues. Based on the leaked issue, in order to fully explore other potential issues, the tracking data corresponding to the leaked issue is converted into an operation behavior path. Then, a genetic algorithm is used to expand the user's operation behavior path, increasing the probability of discovering potential unreported issues.

[0122] S303: Obtain software design functional documents and historical test data.

[0123] In this embodiment, the software design functional document includes the division of functional modules, the expected operation flow of each function, and the constraints of key operations.

[0124] In this embodiment, the historical test data includes information such as historical test cases, fault records, and test pass rates.

[0125] S304: Configure training environment parameters and model training parameters.

[0126] In this embodiment, the training environment parameters are configured to match the actual operating environment parameters of the software; the model training parameters include the learning rate and discount factor, etc.

[0127] S305: Set test requirements and conditions.

[0128] In this embodiment, the test requirements should cover multiple dimensions, including software functionality, user frequency, failure rate, and performance metrics. Simultaneously, appropriate weights are assigned to different test requirements to reflect their importance in the testing process. The test requirements are dynamically adjusted based on actual testing needs and model training results to improve the relevance and effectiveness of the testing, achieving dynamic adjustment.

[0129] S306: A distributed training reinforcement learning model is adopted. Based on the development test operation behavior path library, user operation behavior path library, software design function documents and historical test data, the model is trained according to the training environment parameters, model training parameters and test requirements to obtain a trained operation behavior path generation model.

[0130] In this embodiment, the distributed training reinforcement learning model can be a Deep Q-Network (DQN) model or a Proximal Policy Optimization (PPO) model, etc. These models perform well in dealing with sequential decision problems.

[0131] In this embodiment, the model training parameters are adjusted based on the training effect during the training process to optimize model performance.

[0132] In summary, by collecting event tracking data, the data source for training the operation behavior path generation model can cover both the standard processes of the testing phase and the diverse scenarios of actual user use. Considering the limited number of development test operation behavior paths and user operation behavior paths, a genetic algorithm is introduced to expand the coverage, resulting in both a development test operation behavior path library and a user operation behavior path library. The distributed training reinforcement learning model can efficiently process the large amount of data in the operation behavior path library. Combined with software functional documents and historical test data, the operation behavior path generation model can generate operation behavior paths that meet preset test requirements, providing a foundation for generating test cases.

[0133] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods according to the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method.

[0134] Figure 4 This is a schematic diagram of the structure of the test case generation device provided in the embodiments of this application. Figure 4 As shown, embodiments of this application also provide a test case generation device, including: a receiving module 401, a first generation module 402, an acquisition module 403, a conversion module 404, and a second generation module 405.

[0135] The receiving module 401 is used to receive test case generation requests sent by the testing end.

[0136] The first generation module 402 is used to input the test case generation request into the trained operation behavior path generation model, so that the trained operation behavior path generation model outputs multiple initial operation behavior paths that meet the preset test requirements based on the test case generation request; wherein the trained operation behavior path generation model is trained based on the development test operation behavior path library and the user operation behavior path library.

[0137] The acquisition module 403 is used to acquire multiple final operation behavior paths based on multiple initial operation behavior paths; wherein the operation behavior path includes multiple operation steps.

[0138] The conversion module 404 is used to convert each final operation behavior path into a graph-based operation behavior path, resulting in multiple graph-based operation behavior paths.

[0139] The second generation module 405 is used to generate test cases for each operation behavior path in the form of a diagram, based on the preset application interface of each operation step, so as to obtain multiple test cases.

[0140] In one possible implementation, the first generation module 402 is specifically used to: obtain the target test task in the test case generation request; obtain multiple operation behavior paths corresponding to the target test task according to the development test operation behavior path library and the user operation behavior path library; and select multiple initial operation behavior paths from the multiple operation behavior paths corresponding to the target test task according to preset test requirement conditions.

[0141] In one possible implementation, the acquisition module 403 is specifically used to: acquire the shortest operation behavior path based on multiple initial operation behavior paths; filter out a preset number of operation behavior paths from multiple initial operation behavior paths based on the preset weight of each operation step; and determine multiple final operation behavior paths based on the shortest operation behavior path and the preset number of operation behavior paths.

[0142] In one possible implementation, the acquisition module 403 is further configured to: deduplicate multiple initial operation behavior paths to obtain multiple deduplicated initial operation behavior paths; construct a directed graph of operation behavior paths based on the multiple deduplicated initial operation behavior paths; obtain the starting operation step node and the ending operation step node from the directed graph of operation behavior paths; and obtain the shortest operation behavior path between the starting operation step node and the ending operation step node in the directed graph of operation behavior paths.

[0143] In one possible implementation, the acquisition module 403 is further configured to: acquire the weight of each initial operation behavior path according to the preset weight of each operation step; sort the multiple initial operation behavior paths in descending order according to the weight of each initial operation behavior path to obtain multiple sorted initial operation behavior paths; and extract a preset number of operation behavior paths from the sorted multiple initial operation behavior paths, starting from the first initial operation behavior path.

[0144] In one possible implementation, the conversion module 404 is specifically used to: obtain the operation content, operation page, and operation time of each operation step from each final operation behavior path; if the graph is a timeline graph, then the following first operation is performed; the first operation includes: using a straight line as a time axis, marking the operation time of each operation step on the time axis to obtain multiple operation time markers; adding the operation content and operation page of each operation step to the operation time markers corresponding to each operation step on the time axis; connecting the operation time markers corresponding to each operation step in sequence according to the order of the operation time of each operation step on the time axis to obtain a graph-like operation behavior path; if the graph is a node graph, then the following second operation is performed; the second operation includes: using each operation step as a node, adding the operation content, operation page, and operation time of each operation step to the node corresponding to each operation step; connecting the nodes corresponding to each operation step in sequence with arrows in sequence according to the order of the operation time of each operation step to obtain a graph-like operation behavior path.

[0145] In one possible implementation, the second generation module 405 is specifically used to: obtain the sequence of each operation step, as well as the operation content and operation page of each operation step, according to the operation behavior path in the form of each diagram; determine whether there is a parameter field in the preset application interface of each operation step; if it is determined that there is a parameter field, obtain the parameter value corresponding to the parameter field from the operation content and operation page of each operation step; and replace the parameter field in the preset application interface with the parameter value to obtain the first application interface to be called corresponding to each operation step; if it is determined that there is no parameter field, use the preset application interface as the second application interface to be called; and assemble the first application interface or the second application interface to be called corresponding to each operation step according to the sequence of each operation step to generate test cases.

[0146] In one possible implementation, the test case generation device further includes a training module, which is specifically used for: collecting event tracking data; obtaining a development test operation behavior path library and a user operation behavior path library based on the event tracking data; obtaining software design functional documents and historical test data; configuring training environment parameters and model training parameters; setting test requirement conditions; and using a distributed training reinforcement learning model to train the development test operation behavior path library, user operation behavior path library, software design functional documents, and historical test data according to the training environment parameters, model training parameters, and test requirement conditions to obtain a trained operation behavior path generation model.

[0147] In one possible implementation, the event tracking data includes development and testing event tracking data and user event tracking data. Development and testing event tracking data refers to the operation data of developers and testers interacting with the software before release; user event tracking data refers to the operation data of users interacting with the software after release. Accordingly, the training module is further configured to: perform data cleaning on the development and testing event tracking data to obtain cleaned development and testing event tracking data; wherein the development and testing event tracking data includes the developer / tester identifier and the developer / tester's operation time; divide the cleaned development and testing event tracking data according to the developer / tester identifier to obtain multiple sub-event data corresponding to each developer / tester identifier; and sort the sub-event data corresponding to each developer / tester identifier according to the developer / tester's operation time. The process involves: obtaining the operation sequences of development and testing personnel; converting these sequences into operation behavior paths; expanding these paths using a genetic algorithm to create a library of operation behavior paths; cleaning user event tracking data to obtain cleaned user event tracking data, which includes user identifiers and user operation times; dividing the cleaned user event tracking data according to user identifiers to obtain sub-event data corresponding to multiple user identifiers; sorting the sub-event data corresponding to each user identifier according to the user's operation time to obtain the user's operation sequence; converting these sequences into user operation behavior paths; and expanding these paths using a genetic algorithm to create a library of user operation behavior paths.

[0148] For a description of the features in the embodiment corresponding to the test case generation device, please refer to the relevant description of the embodiment corresponding to the test case generation method, which will not be repeated here.

[0149] Figure 5 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Figure 5 As shown, the electronic device provided in this embodiment includes at least one processor 501 and a memory 502. Optionally, the electronic device further includes a communication component 503. The processor 501, memory 502, and communication component 503 are connected via a bus.

[0150] In the specific implementation process, at least one processor 501 executes computer execution instructions stored in memory 502, causing at least one processor 501 to execute the above-described test case generation method embodiment.

[0151] The specific implementation process of processor 501 can be found in the above method embodiments, and its implementation principle and technical effect are similar. It will not be repeated here.

[0152] In the above embodiments, it should be understood that the processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), etc. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in the application can be directly manifested as being executed by a hardware processor, or executed by a combination of hardware and software modules within the processor.

[0153] The memory may include random access memory (RAM) and may also include non-volatile memory (NVM), such as at least one disk storage device.

[0154] The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of illustration, the buses shown in the accompanying drawings are not limited to a single bus or a single type of bus.

[0155] Embodiments of this application also provide a computer-readable storage medium storing a computer program, wherein the computer program is configured to execute the steps in any of the above-described test case generation method embodiments at runtime.

[0156] In one exemplary embodiment, the aforementioned computer-readable storage medium may include, but is not limited to, various media capable of storing computer programs, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard disk, magnetic disk, or optical disk.

[0157] Embodiments of this application also provide a computer program product, which includes a computer program that, when executed by a processor, implements the steps in any of the above-described test case generation method embodiments.

[0158] Embodiments of this application also provide another computer program product, including a non-volatile computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps in any of the above-described test case generation method embodiments.

[0159] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0160] The foregoing has provided a detailed description of a test case generation method, apparatus, electronic device, medium, and product provided in this application. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the embodiments above are only intended to aid in understanding the method and core ideas of this application. It should be noted that those skilled in the art can make various improvements and modifications to this application without departing from its principles, and these improvements and modifications also fall within the protection scope of the claims of this application.

Claims

1. A method for generating test cases, characterized in that, include: Receive test case generation requests sent by the testing end; The test case generation request is input into the trained operation behavior path generation model, so that the trained operation behavior path generation model outputs multiple initial operation behavior paths that meet the preset test requirements based on the test case generation request. The trained operation behavior path generation model is obtained by training based on the development and testing operation behavior path library and the user operation behavior path library. Based on the multiple initial operation behavior paths, multiple final operation behavior paths are obtained; The operation path includes multiple operation steps; Each final operation path is transformed into a graph-based operation path, resulting in multiple graph-based operation paths. For each type of operation behavior path, test cases are generated based on the preset application interface of each operation step to obtain multiple test cases. The step of obtaining multiple final operation behavior paths based on the multiple initial operation behavior paths includes: Based on the multiple initial operation behavior paths, obtain the shortest operation behavior path; Based on the preset weights of each operation step, a preset number of operation behavior paths are selected from the multiple initial operation behavior paths; Based on the shortest operation path and the preset number of operation paths, multiple final operation paths are determined.

2. The method according to claim 1, characterized in that, The trained operation behavior path generation model generates requests based on the test cases and outputs multiple initial operation behavior paths that meet preset test requirements, including: Obtain the target test task from the test case generation request; Based on the development test operation behavior path library and the user operation behavior path library, obtain multiple operation behavior paths corresponding to the target test task; Based on the preset test requirements, multiple initial operation behavior paths are selected from the multiple operation behavior paths corresponding to the target test task.

3. The method according to claim 2, characterized in that, The step of obtaining the shortest operation behavior path based on the multiple initial operation behavior paths includes: The multiple initial operation behavior paths are deduplicated to obtain multiple deduplicated initial operation behavior paths; Based on the multiple initial operation behavior paths after deduplication, construct a directed graph of operation behavior paths; From the directed graph of the operation behavior path, obtain the starting operation step node and the ending operation step node; In the directed graph of the operation behavior path, the shortest operation behavior path between the starting operation step node and the ending operation step node is obtained.

4. The method according to claim 2, characterized in that, The step of selecting a preset number of operation behavior paths from the plurality of initial operation behavior paths according to the preset weights of each operation step includes: Based on the preset weights of each operation step, obtain the weights of each initial operation behavior path; Based on the weight of each initial operation path, the initial operation paths are sorted in descending order to obtain sorted initial operation paths. Among the sorted initial operation paths, starting from the first initial operation path, a preset number of operation paths are extracted.

5. The method according to claim 1, characterized in that, The process of converting each final operation path into a graph-like operation path includes: From each final operation path, obtain the operation content, operation page, and operation time of each operation step; If the chart is a timeline chart, then perform the following first operation; The first operation includes: Using a straight line as a time axis, the operation time of each operation step is marked on the time axis to obtain multiple operation time marks; On the timeline, the operation content and operation page of each operation step are added to the operation time marker corresponding to each operation step; On the timeline, the operation time markers corresponding to each operation step are connected sequentially according to the order of their operation times to obtain a graphical operation behavior path. If the graph is a node graph, then perform the following second operation; The second operation includes: Each operation step is treated as a node, and the operation content, operation page, and operation time of each operation step are added to the node corresponding to each operation step. According to the chronological order of the operation steps, the nodes corresponding to each operation step are connected sequentially with arrows to obtain the operation behavior path in the form of a graph.

6. The method according to claim 1, characterized in that, The operation behavior paths for each diagram form generate test cases based on the preset application interface of each operation step, including: Based on the operation behavior paths in each diagram, obtain the sequence of each operation step, as well as the operation content and operation page of each operation step; Determine whether parameter fields exist in the preset application interface of each operation step; If the parameter field is determined to exist, the parameter value corresponding to the parameter field is obtained from the operation content and operation page of each operation step; and the parameter value is used to replace the parameter field in the preset application interface to obtain the first application interface to be called corresponding to each operation step. If it is determined that the parameter field does not exist, then the preset application interface is used as the second application interface to be called; According to the order of the operation steps, the first application interface to be called or the second application interface to be called corresponding to each operation step is assembled to generate test cases.

7. The method according to claim 1, characterized in that, Before receiving the test case generation request sent by the test terminal, the process also includes: Collect embedded data; Based on the data points, obtain the development and testing operation behavior path library and the user operation behavior path library; Obtain software design functional documents and historical test data; Configure training environment parameters and model training parameters; Define the test requirements and conditions; A distributed training reinforcement learning model is adopted. Based on the development and testing operation behavior path library, the user operation behavior path library, the software design function document, and the historical test data, the model is trained according to the training environment parameters, model training parameters, and test requirements to obtain a trained operation behavior path generation model.

8. The method according to claim 7, characterized in that, The event tracking data includes development and testing event tracking data and user event tracking data; wherein the development and testing event tracking data is the operation data of the development and testing personnel during the interaction with the software before the software is released; and the user event tracking data is the operation data of the user during the interaction with the software after the software is released. Accordingly, obtaining the development and testing operation behavior path library and the user operation behavior path library based on the embedded data includes: The development and testing data points are cleaned to obtain cleaned development and testing data points; wherein the development and testing data points include the development and testing personnel identification and the operation time of the development and testing personnel. The cleaned development and testing data points are divided according to the development and testing personnel identifiers to obtain multiple sub-data points corresponding to the development and testing personnel identifiers. For each development and testing personnel's identifier, the corresponding sub-inclusion data is sorted according to the operation time of the development and testing personnel to obtain the operation sequence of the development and testing personnel; The operation sequence of the development and testing personnel is converted into a development and testing operation behavior path; A genetic algorithm is used to expand the development and testing operation behavior paths to obtain a development and testing operation behavior path library. The user tracking data is cleaned to obtain cleaned user tracking data; wherein the user tracking data includes user identifier and user operation time. The cleaned user tracking data is divided according to the user identifier to obtain sub-tracking data corresponding to multiple user identifiers; For each user identifier, the sub-inclusion data is sorted according to the user's operation time to obtain the user's operation sequence; The user's operation sequence is converted into a user operation behavior path; A genetic algorithm is used to expand the user operation behavior path to obtain a user operation behavior path library.

9. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor, configured to implement the steps of the test case generation method as described in any one of claims 1-8 when executing the computer program.

Images