Software test engineering conversion and test method and device, storage medium and computer equipment
By replacing the base class with a new one and generating core test logic methods in the software testing project, the problem of large workload and errors caused by the large number of scenario test cases was solved, and efficient and accurate test method generation and execution were achieved.
Patent Information
- Application Number
- CN202511908667.6
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-12-17
- Publication Date
- 2026-03-03
AI Technical Summary
In existing software testing engineering, the number of scenario test cases is huge, and manual modification is a huge, time-consuming, and labor-intensive task that is prone to errors, affecting the testing progress and quality.
By identifying and replacing the original base class in the test class with a new base class, the new base class adds the ability to set data sources and read data, generates the core test logic methods, and generates independent test methods for each scenario test case, reducing the workload of manual modification and improving testing efficiency.
It enables seamless conversion of software testing engineering, reduces the workload and potential errors caused by manual modifications, improves the relevance and efficiency of testing, and adapts to different testing needs.
Smart Images
Figure CN121597587A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of software testing technology, and in particular to a software testing engineering conversion and testing method, apparatus, storage medium and computer equipment. Background Technology
[0002] In the field of software testing, automated testing has become a key means of ensuring software quality due to its advantages such as efficiency and repeatability. In typical automated testing solutions, a single data storage file is used to store test data for multiple scenario test cases, and this data storage file is then used to test all scenario test cases throughout the entire software testing process.
[0003] As business grows and testing requirements change, the number of scenario test cases in software testing engineering continues to expand. In this context, whenever a scenario changes within the software testing engineering, tests in all scenario test cases must be run in full, based on the data storage files. Therefore, some scenario test cases require manual modification of the software testing engineering, splitting it from "multiple scenarios corresponding to one test execution entry point" to "one scenario corresponding to one test execution entry point," so that regression testing is performed only on the core scenario test cases. However, the sheer number of scenario test cases in the software testing engineering makes manual modification not only extremely labor-intensive but also time-consuming, error-prone, and impacts testing progress and quality. Summary of the Invention
[0004] The purpose of this application is to at least address one of the aforementioned technical deficiencies, particularly the technical deficiency in existing software testing engineering where the number of scenario test cases is enormous, manual modification is not only a huge workload, but the conversion process is also time-consuming, labor-intensive, and prone to errors, thus affecting testing progress and quality.
[0005] This application provides a software test engineering conversion method, the method comprising:
[0006] The test class inheriting from the test base class is identified from the original test project, and the original base class in the test class is replaced with the new base class; the new base class is reconstructed based on the original base class by adding data source setting capabilities and data reading capabilities.
[0007] The test class after the base class is replaced is parsed to obtain the original test method containing multiple scenario test cases, and the core test logic method corresponding to the original test method is generated; the core test logic method reads the test data line from the data storage file of the test class by calling the new base class;
[0008] Based on the data storage file and the core test logic method, an independent test method is generated for each scenario test case; wherein, each scenario test case has a corresponding test data line in the data storage file;
[0009] The original test project is structurally transformed based on each independent test method to obtain a new test project.
[0010] Optionally, the reconstruction process of the new base class includes:
[0011] Determine the original base class in the test class, and obtain the intermediate base class by inheriting the original capabilities of the original base class through the newly created parent class;
[0012] The ability to set up a data source is established; the data reading capability is used to specify the path of the data storage file for the test class.
[0013] Build a data reading capability; the data reading capability is used to load the test data line corresponding to the current scenario use case in the data storage file;
[0014] The data source setting capability and the data reading capability are added to the intermediate base class to form a new base class.
[0015] Optionally, the method for generating the core test logic corresponding to the original test method includes:
[0016] The original test method is parsed to obtain the test logic code and the code content of the test logic code.
[0017] A new data-driven framework is built based on the data source setting and data reading capabilities of the new base class;
[0018] The code content is transferred from the original data-driven framework in the test logic code to the new data-driven framework to form the core method of the test logic.
[0019] Optionally, the method of generating an independent test method for each scenario test case based on the data storage file and the core test logic includes:
[0020] Traverse the data storage file to determine the scenario test cases for each test class; each row of test data in the data storage file corresponds to one scenario test case;
[0021] Multiple method names are generated sequentially according to the line order of the data storage file, and a mapping relationship is established between each method name and the number of data lines;
[0022] Based on the mapping relationships and the core test logic method, an independent test method is generated for each scenario test case.
[0023] Optionally, the method further includes:
[0024] When a new scenario test case is added to the test class, a test data row for the new scenario test case is added to the data storage file;
[0025] Determine the core test logic method corresponding to the new scenario test case, and generate an independent test method corresponding to the new scenario test case based on the core test logic method and the test data row;
[0026] The independent test method is tested, and after the test is successful, the independent test method is added to the new test project.
[0027] This application also provides a software engineering testing method, the method comprising:
[0028] When performing smoke testing on test classes in a new test project, select independent test methods carrying core identifiers from the test classes and mark them as methods to be tested; wherein, the test class contains multiple independent test methods, and each independent test method corresponds to a scenario test case;
[0029] The core test logic method in the method under test is triggered to call the new base class; the new base class includes data source setting capabilities and data reading capabilities.
[0030] The data source setting capability is used to determine the data storage file of the test class, and the data reading capability is used to obtain the test data line corresponding to the method name of the method to be tested from the data storage file;
[0031] Based on the test data in the test data row, the core method of the test logic is executed to obtain the test result of the method to be tested.
[0032] This application also provides a software testing engineering conversion device, comprising:
[0033] The base class refactoring module is used to identify test classes that inherit from the test base class from the original test project, and replace the original base class in the test class with a new base class; the new base class is refactored based on the original base class by adding data source setting capabilities and data reading capabilities.
[0034] The code parsing module is used to parse the code of the test class after the base class is replaced, obtain the original test method containing multiple scenario test cases, and generate the core test logic method corresponding to the original test method; the core test logic method reads the test data line in the data storage file of the test class by calling the new base class;
[0035] The scenario-independent module is used to generate independent test methods for each scenario test case based on the data storage file and the core test logic method; wherein, each scenario test case has a corresponding test data line in the data storage file;
[0036] The project conversion module is used to perform structural conversion on the original test project based on each independent test method to obtain a new test project.
[0037] This application also provides a software testing engineering testing apparatus, including:
[0038] The method marking module is used to filter out independent test methods carrying core identifiers from the test classes in a new test project when performing smoke tests on the test classes, and mark them as methods to be tested; wherein, the test class contains multiple independent test methods, and each independent test method corresponds to a scenario test case;
[0039] The base class invocation module is used to trigger the core test logic method in the method under test to call the new base class; the new base class includes data source setting capabilities and data reading capabilities.
[0040] The data acquisition module is used to determine the data storage file of the test class by using the data source setting capability, and to obtain the test data line corresponding to the method name of the method to be tested from the data storage file by using the data reading capability;
[0041] The method testing module is used to execute the core method of the test logic based on the test data in the test data row, and obtain the test result of the method to be tested.
[0042] This application also provides a storage medium storing computer-readable instructions, which, when executed by one or more processors, cause the one or more processors to perform the steps of the software test engineering conversion method and the steps of the software test engineering test method as described in any of the above embodiments.
[0043] This application also provides a computer device, including: one or more processors, and memory;
[0044] The memory stores computer-readable instructions, which, when executed by the one or more processors, perform the steps of the software test engineering conversion method and the software test engineering test method as described in any of the above embodiments.
[0045] As can be seen from the above technical solutions, the embodiments of this application have the following advantages:
[0046] The software testing engineering conversion and testing method, apparatus, storage medium, and computer equipment provided in this application, during engineering structure conversion, can first identify test classes that inherit from the test base class from the original test project, and replace the original base class in the test class with a new base class. Since the new base class is reconstructed by adding data source setting and data reading capabilities to the original base class, it can accurately read test data for specific scenarios. Subsequently, code parsing of the test class after base class replacement yields the original test methods containing multiple scenario test cases, and generates the corresponding core test logic methods. By concentrating the common test logic for various scenario test cases in the core methods, the workload of generating independent test methods for each scenario test case can be significantly reduced. These independent test methods not only have independent execution entry points but can also accurately read and execute the corresponding test data lines in the data storage file through the new base class. Therefore, the new test project obtained by structurally converting the original test project based on each independent test method can avoid the large workload and potential errors caused by manual modification, and better adapt to different testing needs. Attached Figure Description
[0047] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.
[0048] Figure 1 A flowchart illustrating a software test engineering conversion method provided in an embodiment of this application;
[0049] Figure 2 A flowchart illustrating a software testing engineering testing method provided in an embodiment of this application;
[0050] Figure 3 A schematic diagram of the structure of a software testing engineering conversion device provided in an embodiment of this application;
[0051] Figure 4 This is a schematic diagram of the structure of a software testing engineering testing device provided in an embodiment of this application;
[0052] Figure 5 This is a schematic diagram of the internal structure of a computer device provided in an embodiment of this application. Detailed Implementation
[0053] 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 skilled in the art without creative effort are within the scope of protection of this application.
[0054] As business grows and testing requirements change, the number of scenario test cases in software testing engineering continues to expand. In this context, whenever a scenario changes within the software testing engineering, tests in all scenario test cases must be run in full, based on the data storage files. Therefore, some scenario test cases require manual modification of the software testing engineering, splitting it from "multiple scenarios corresponding to one test execution entry point" to "one scenario corresponding to one test execution entry point," so that regression testing is performed only on the core scenarios. However, the sheer number of scenario test cases in the software testing engineering makes manual modification not only extremely labor-intensive but also time-consuming, error-prone, and impacts testing progress and quality.
[0055] Based on this, this application proposes the following technical solution, as detailed below:
[0056] In one embodiment, such as Figure 1 As shown, Figure 1 This is a flowchart illustrating a software test engineering conversion method provided in an embodiment of this application. The application provides a software test engineering conversion method, specifically including the following:
[0057] S110: Identify the test class that inherits from the test base class from the original test project, and replace the original base class in the test class with the new base class; the new base class is reconstructed based on the original base class by adding data source setting capabilities and data reading capabilities.
[0058] In this step, this application uses a conversion tool to restructure the original test project. The conversion tool can identify test classes that inherit from the test base class from the original test project and replace the original base class in the test class with the new base class. Since the new base class is reconstructed by adding data source setting capabilities and data reading capabilities on the basis of the original base class, the new base class can accurately read test data for specific scenarios.
[0059] It's important to note that in the original test project, to ensure consistent execution across all test cases, each test case needed to inherit from a common test base class. This inheritance mechanism allowed test cases to reuse the core logic of the test base class, achieving a standardized and reusable test execution flow without having to repeatedly write basic code in each test class.
[0060] Therefore, the conversion tool can replace the inheritance relationship of test classes in the original test project with one pointing to the refactored new base class. This allows each test class to have independent data source setting and data reading capabilities while maintaining its existing test logic. Based on the capabilities of the new base class, the project can flexibly set the data source according to different needs during testing, accurately reading test data for specific test cases. This meets the need for fine-grained selection of test case execution, avoids executing all test cases, and improves the targeting and efficiency of testing.
[0061] S120: Perform code parsing on the test class after the base class replacement to obtain the original test method containing multiple scenario test cases, and generate the core test logic method corresponding to the original test method; the core test logic method reads the test data line from the data storage file of the test class by calling the new base class.
[0062] In this step, after the test class is replaced with a base class in step S110, the conversion tool can parse the code of the test class after the base class is replaced, obtain the original test method containing multiple scenario test cases, and generate the core test logic method corresponding to the original test method. By concentrating the common test logic of each scenario test case in the core method, the workload of generating independent test methods for each scenario test case can be greatly reduced.
[0063] Each test class contains at least one original test method, and each original test method can contain multiple scenario test cases. For example, when the original test method is a login test, the test case scenarios it contains can be normal login scenario, incorrect password scenario, locked account login scenario, empty username scenario, and empty password scenario, etc.
[0064] Specifically, the conversion tool can perform structured code parsing on the updated test classes, automatically identifying the original test methods used to execute multiple test scenarios. Based on the internal flow of the original test methods, it extracts stable and unchanging business verification steps, common data processing logic, and general assertion rules, thereby generating a core test logic method corresponding to the original test method. This core method, serving as the logical skeleton, can uniformly encapsulate the execution flow shared by all scenarios, enabling the test project to maintain consistency in its original behavior while achieving logic reuse and structural refactoring, fundamentally reducing code volume and repetitive work.
[0065] It is understood that in this application, the core method of the test logic can, during execution, accurately locate the test data line in the data storage file that matches the test case based on the data source setting capability and data reading capability provided by the new base class bound to the test class, and read the test data from it as the input of the core method, so that the core method can accurately drive the execution process of a specific scenario within a unified test logic framework.
[0066] S130: Generate independent test methods for each scenario test case based on data storage files and core test logic methods; each scenario test case has a corresponding test data line in the data storage file.
[0067] In this step, after generating the core test logic method through step S120, the conversion tool can generate an independent test method for each scenario test case based on the data storage file and the core test logic method. This independent test method not only has an independent execution entry point, but can also accurately read the test data line corresponding to its scenario in the data storage file through the new base class and execute the test.
[0068] Understandably, in the data storage file, each scenario test case corresponds to a unique and structured line of test data. Therefore, after constructing the core test logic methods, the conversion tool can further associate the data storage file with the core methods, mapping the test data lines corresponding to each scenario test case to the core methods, forming an independent test method. Each independent test method has a complete and independent execution entry point, can be scheduled independently, and internally can precisely lock and load the test data lines matching the scenario at test startup by calling the data reading capabilities of the new base class, ensuring the accuracy and reliability of the data source during test execution.
[0069] S140: Based on each independent test method, the original test project is structurally transformed to obtain a new test project.
[0070] In this step, after generating independent test methods for each scenario test case through step S130, the conversion tool can perform structural conversion on the original test project based on each independent test method to obtain a new test project. This avoids the large amount of workload and potential errors caused by manual modification and better adapts to different testing needs.
[0071] Specifically, the conversion tool can automatically analyze the directory layout, inheritance relationships between classes, method organization, and data file referencing of the original test project, and accordingly make unified adjustments to the package structure, test class granularity, data source binding method, and execution entry configuration within the project. This allows the old project form, which relied on a single entry point and drove multi-scenario testing through data, to smoothly evolve into a new project form with independent test methods at its core and finely divided according to scenarios.
[0072] Understandably, during the transformation process, the transformation tool can automate all the tedious tasks that require manual processing, including class rewriting, method generation, data reference binding, project structure migration and integrity verification, etc., to ensure that the new test project after reconstruction remains stable and reliable in terms of logical consistency, code compilability and test executability, thereby achieving seamless replacement.
[0073] In the above embodiments, during the engineering structure conversion, test classes inheriting from the test base class can be identified from the original test project, and the original base class in the test class can be replaced with a new base class. Since the new base class is reconstructed by adding data source setting capabilities and data reading capabilities to the original base class, the new base class can accurately read test data for specific scenarios. Subsequently, code parsing of the test class after the base class replacement can yield the original test methods containing multiple scenario test cases, and generate the core test logic method corresponding to the original test method. By concentrating the common test logic for various scenario test cases in the core method, the workload of generating independent test methods for each scenario test case can be greatly reduced. These independent test methods not only have independent execution entry points, but can also accurately read and execute the corresponding test data lines in the data storage file through the new base class. Therefore, the new test project obtained by structurally converting the original test project based on each independent test method can avoid the large workload and potential errors caused by manual modification, and better adapt to different testing needs.
[0074] In one embodiment, the reconstruction process of the new base class in step S110 may include:
[0075] S111: Determine the original base class in the test class, and obtain the intermediate base class by inheriting the original capabilities of the original base class through the newly created parent class.
[0076] S112: Build data source settings capability; data reading capability is used to specify the path of the data storage file for the test class.
[0077] S113: Build data reading capability; the data reading capability is used to load the test data line corresponding to the current scenario use case in the data storage file.
[0078] S114: Add the data source setting capability and data reading capability to the intermediate base class to form a new base class.
[0079] In this embodiment, when reconstructing the new base class, the conversion tool first determines the original base class in the test class, and then inherits the original capabilities of the original base class through a newly created parent class to obtain an intermediate base class. Next, it constructs data source setting capabilities and data reading capabilities. The data reading capability can be used to specify the path to the data storage file of the test class, and it can be used to load the test data rows corresponding to the current scenario test cases in the data storage file. Finally, the conversion tool adds the data source setting capabilities and data reading capabilities to the intermediate base class, thus forming the new base class.
[0080] It can be understood that by inheriting from the original base class, the new base class can fully retain the general capabilities of the original testing system, thereby ensuring the consistency of behavior between the old and new structures. Subsequently, the conversion tool can extend the scenario-based data management capabilities, namely the data source setting capability and data reading capability, on the basis of the intermediate base class, so that the new base class can automatically parse the test data line corresponding to the current test scenario test case in the data storage file during test execution, ensuring that scenario-level data can be accurately extracted and used for test case testing.
[0081] For example, in a test class, all test cases inherit from the original base class `BaseTestNg`, enabling each test case to automatically complete the user login operation before execution, ensuring smooth access to the server for subsequent business operations. Based on this, the conversion tool can construct a new base class `BaseSplitTestNg`, using `BaseTestNg` as the parent class, allowing `BaseSplitTestNg` to directly inherit the common initialization logic related to login. Subsequently, the conversion tool adds data source setting and data reading capabilities to `BaseSplitTestNg`. The data source setting capability can be implemented through the `setDataSrc` method, providing a clear data source configuration entry point for subclasses. Test classes can specify the data storage file path and file name that their scenario depends on by calling the `setDataSrc` method. The data reading capability can open the corresponding data storage file based on the file path and file name passed in by the subclass, and read specific data rows corresponding to the current test scenario test cases as needed during the test execution phase.
[0082] In one embodiment, the process of generating the core test logic method corresponding to the original test method in step S120 may include:
[0083] S121: Perform code parsing on the original test method to obtain the test logic code and its contents.
[0084] S122: Build a new data-driven framework based on the data source setting and data reading capabilities of the new base class.
[0085] S123: Transfer the code content from the original data-driven framework in the test logic code to the new data-driven framework to form the core method of the test logic.
[0086] In this embodiment, the conversion tool can parse the original test method to obtain the test logic code and its content. Then, it can build a new data-driven framework based on the new base class's data source setting and data reading capabilities, and transfer the code content from the original data-driven framework in the test logic code to the new data-driven framework to form the core test logic method.
[0087] Specifically, the conversion tool first performs static code analysis on the original test method to identify the test logic code used for business verification within the method, and then extracts the complete code content of this logic code. Subsequently, based on the data source setting and data reading capabilities provided by the new base class, the conversion tool can build a new data-driven framework, enabling test classes to independently use different data rows according to scenarios, instead of relying on the `testComplext` method in the original test method to uniformly process all data in a loop. After the new framework is built, the conversion tool can extract the code content parsed from the original test method from the original data-driven structure under the `testComplext` method and migrate it to the new data-driven framework as the core execution unit, thus forming a clearly structured and single-responsibility core test logic method.
[0088] Understandably, by separating the test logic code from the old data-driven structure and migrating it to the new core method, the test logic code can completely get rid of complex multi-scenario loop control, and the logic clarity and readability are greatly improved. Relying on the precise data reading mechanism provided by the new base class, each scenario test case only needs to process the data row associated with itself during execution, thereby avoiding the performance overhead and execution redundancy caused by the original full data traversal.
[0089] In one embodiment, the process of generating an independent test method for each scenario use case based on the data storage file and the core test logic method in step S130 may include:
[0090] S131: Traverse the data storage file to determine the scenario test cases for each test class; each line of test data in the data storage file corresponds to one scenario test case.
[0091] S132: Generate multiple method names sequentially according to the line order of the data storage file, and establish a mapping relationship between each method name and the number of data lines.
[0092] S133: Generate independent test methods for each scenario test case based on various mapping relationships and core test logic methods.
[0093] In this embodiment, when splitting the original test method into scenarios, since each test data line in the data storage file corresponds to a scenario test case, the conversion tool can traverse the test data lines in the data storage file to determine the scenario test cases of the test class based on the number of lines. At the same time, it can generate multiple method names sequentially according to the line order of the data storage file and establish a mapping relationship between each method name and the number of data lines. Subsequently, the conversion tool can generate an independent test method corresponding to each scenario test case based on each mapping relationship and the core test logic method.
[0094] Specifically, during the traversal of the data storage file, the conversion tool can determine the unique identifier of each scenario test case based on the index or line number of the data row. It can also generate corresponding test method names for each test case according to the line order and internally establish a mapping relationship between method names and data row numbers, ensuring that each generated independent test method is precisely associated with its corresponding test data row. Based on this mapping relationship, the conversion tool can bind the core test logic method to each method name when generating independent test methods. This ensures that each generated independent test method has a complete execution entry point and can accurately load its corresponding test data row from the data storage file during execution using the data reading capability of the new base class, achieving scenario-driven test execution.
[0095] For example, in a data storage file TestData.xlsx corresponding to a test class, there are 5 rows of data. The first row is the header row, and rows 2 through 5 are the test data rows for the four scenario test cases. When processing the test class, the conversion tool can automatically skip the header row and traverse each row of test data starting from the second row. During the traversal, the conversion tool can generate the corresponding method names sequentially according to the order of the data rows. For example, the second row generates the case0() method, the third row generates the case1() method, the fourth row generates the case2() method, and the fifth row generates the case3() method. At the same time, the conversion tool can also establish a mapping relationship between the data row number and the generated method name, so that the method can accurately retrieve its corresponding data row when executed by leveraging the data reading capabilities of the new base class.
[0096] In one embodiment, the method may further include:
[0097] S141: When adding a new scenario test case in a test class, add a test data row for the new scenario test case to the data storage file.
[0098] S142: Determine the core test logic method corresponding to the new scenario test case, and generate an independent test method corresponding to the new scenario test case based on the core test logic method and the test data row.
[0099] S143: Test the independent test method and add it to the new test project after the test is successful.
[0100] In this embodiment, if a new scenario test case is added to the test class, the conversion tool can add a test data row for the new scenario test case to the data storage file, and then determine the core test logic method corresponding to the new scenario test case. Based on the core test logic method and the test data row, an independent test method corresponding to the new scenario test case can be generated. After the independent test method is generated, this application can also test it through a testing system, and after successful testing, the independent test method can be added to a new test project.
[0101] Understandably, adding test data lines for the new scenario's test cases to the data storage file ensures the data integrity and correct structure for each new scenario. Subsequently, the conversion tool analyzes the business logic corresponding to the new scenario's test cases and determines the core test logic methods to be used, ensuring that the new scenario can follow existing test processes and assertion logic during execution, while maintaining behavioral consistency. Based on this core method and the newly added test data lines, the conversion tool can automatically generate independent test methods corresponding to the new scenario's test cases, giving them both an independent execution entry point and the ability to accurately load the corresponding data test lines through the data reading capabilities of the new base class, thus completing scenario-driven test execution.
[0102] Furthermore, after generating an independent test method, this application can further utilize a testing system to verify and execute the method, ensuring that the new scenario is logically correct, the data matches accurately, and does not affect the normal operation of other scenarios during execution. After the test confirms that there are no errors, the conversion tool can automatically integrate the independent test method and add it to the new test project, enabling the new test project to fully cover all existing and newly added scenario test cases.
[0103] In one embodiment, such as Figure 2 As shown, Figure 2 This application provides a flowchart illustrating a software testing engineering method according to an embodiment of the present application; the present application also provides a software engineering testing method, specifically including the following:
[0104] S150: When performing smoke testing on test classes in a new test project, select independent test methods carrying core identifiers from the test classes and mark them as methods to be tested; wherein, the test class contains multiple independent test methods, and each independent test method corresponds to a scenario test case.
[0105] S160: Triggers a call to the core test logic method in the method under test to the new base class; the new base class includes data source setting capabilities and data reading capabilities.
[0106] S170: Use the data source setting capability to determine the data storage file of the test class, and use the data reading capability to retrieve the test data line corresponding to the method name of the method to be tested from the data storage file.
[0107] S180: Based on the test data in the test data row, execute the core test logic method to obtain the test results of the method under test.
[0108] In this embodiment, based on the new test project obtained through structural transformation, the testing system can perform smoke testing on its test classes. During the testing process, the testing system can first filter out independent test methods carrying core identifiers from the test classes, mark them as methods to be tested, and then trigger the core test logic method in the method to be tested to call a new base class with data source setting and data reading capabilities to read the corresponding data test lines. The data source setting capability determines the data storage file of the test class, and the data reading capability retrieves the test data lines corresponding to the method name of the method to be tested from the data storage file. Finally, based on the test data in the test data lines, the testing system can execute the core test logic method to obtain the test results of the method to be tested.
[0109] It should be noted that the test cases in the test class can be labeled with P1 and P2, where P1 represents the core scenario and P2 represents the non-core scenario. Therefore, the test system can execute only the P1 core test cases during the smoke test phase to quickly confirm the stability of the software version and the availability of key functions, thereby saving time and resources, and providing a basis for decision-making in subsequent regression testing or comprehensive testing.
[0110] Specifically, during the testing process, the testing system first scans the test classes, filters out independent test methods carrying core identifiers, and marks these methods as methods to be tested, thus clarifying the target scope of this test execution. Subsequently, the testing system can trigger the core test logic method within each method to be tested. During execution, the core method can call the data source setting and data reading capabilities provided by the new base class to accurately retrieve the test data line corresponding to the method to be tested from the data storage file, thereby providing the core test logic method with dedicated, scenario-specific input data. Using the test data in these test data lines, the core method can execute complete test operations according to the established business process, validation rules, and assertion logic, ultimately generating the execution result of the method to be tested, including success or failure status and related output information.
[0111] The software test engineering conversion device and software test engineering device provided in the embodiments of this application are described below. The software test engineering conversion device and software test engineering device described below can be referred to in correspondence with the software test engineering conversion method and software test engineering method described above.
[0112] In one embodiment, such as Figure 3 As shown, Figure 3 This application provides a schematic diagram of a software testing engineering conversion device according to an embodiment of the present application. The present application also provides a software testing engineering conversion device, including a base class refactoring module 210, a code parsing module 220, a scenario independence module 230, and an engineering conversion module 240, specifically comprising the following:
[0113] The base class refactoring module 210 is used to identify test classes that inherit from the test base class from the original test project, and replace the original base class in the test class with the new base class; the new base class is refactored by adding data source setting capabilities and data reading capabilities on the basis of the original base class.
[0114] The code parsing module 220 is used to parse the code of the test class after the base class replacement, obtain the original test method containing multiple scenario test cases, and generate the core test logic method corresponding to the original test method. The core test logic method reads the test data lines from the data storage file of the test class by calling the new base class.
[0115] The scenario-independent module 230 is used to generate independent test methods for each scenario test case based on the data storage file and the core test logic method; wherein, each scenario test case has a corresponding test data line in the data storage file.
[0116] The engineering conversion module 240 is used to perform structural conversion on the original test project based on each independent test method to obtain a new test project.
[0117] In the above embodiments, during the engineering structure conversion, test classes inheriting from the test base class can be identified from the original test project, and the original base class in the test class can be replaced with a new base class. Since the new base class is reconstructed by adding data source setting capabilities and data reading capabilities to the original base class, the new base class can accurately read test data for specific scenarios. Subsequently, code parsing of the test class after the base class replacement can yield the original test methods containing multiple scenario test cases, and generate the core test logic method corresponding to the original test method. By concentrating the common test logic for various scenario test cases in the core method, the workload of generating independent test methods for each scenario test case can be greatly reduced. These independent test methods not only have independent execution entry points, but can also accurately read and execute the corresponding test data lines in the data storage file through the new base class. Therefore, the new test project obtained by structurally converting the original test project based on each independent test method can avoid the large workload and potential errors caused by manual modification, and better adapt to different testing needs.
[0118] In one embodiment, the base class refactoring module 210 may include:
[0119] The capability inheritance submodule is used to determine the original base class in the test class and obtain the intermediate base class by inheriting the original capabilities of the original base class through the newly created parent class.
[0120] The first construction submodule is used to build the data source setting capability; the data reading capability is used to specify the path of the data storage file of the test class.
[0121] The second submodule is used to build the data reading capability; the data reading capability is used to load the test data lines corresponding to the current scenario use cases in the data storage file.
[0122] The capability-adding submodule is used to add data source setting capabilities and data reading capabilities to the intermediate base class, forming a new base class.
[0123] In one embodiment, the code parsing module 220 may include:
[0124] The code parsing submodule is used to parse the original test method to obtain the test logic code and its content.
[0125] The framework construction submodule is used to build a new data-driven framework based on the data source setting and data reading capabilities of the new base class.
[0126] The code transfer submodule is used to transfer code content from the original data-driven framework in the test logic code to the new data-driven framework, forming the core methods of the test logic.
[0127] In one embodiment, the scene-independent module 230 may include:
[0128] The scenario determination submodule is used to traverse the data storage file and determine the scenario test cases for each test class; each line of test data in the data storage file corresponds to one scenario test case.
[0129] The relational mapping submodule is used to generate multiple method names sequentially according to the line order of the data storage file, and to establish a mapping relationship between each method name and the number of data rows.
[0130] The method generation submodule is used to generate independent test methods for each scenario test case based on various mapping relationships and core test logic methods.
[0131] In one embodiment, the apparatus may further include:
[0132] The data addition module is used to add test data rows for new scenario test cases to the data storage file when a new scenario test case is added to a test class.
[0133] The method generation module is used to determine the core test logic method corresponding to the new scenario test case, and generate an independent test method corresponding to the new scenario test case based on the core test logic method and the test data row.
[0134] The method addition module is used to test independent test methods and add them to a new test project after the test is successful.
[0135] In one embodiment, such as Figure 4 As shown, Figure 4This application provides a schematic diagram of a software testing engineering testing device according to an embodiment of the present application. The present application also provides a software testing engineering testing device, including a method marking module 250, a base class calling module 260, a data acquisition module 270, and a method testing module 280, specifically comprising the following:
[0136] The method marking module 250 is used to filter out independent test methods carrying core identifiers from the test classes in a new test project when performing smoke tests on the test classes, and mark them as methods to be tested; wherein, the test class contains multiple independent test methods, and each independent test method corresponds to a scenario test case.
[0137] The base class calls module 260, which is used to trigger the core test logic method in the method under test to call the new base class; the new base class includes data source setting capabilities and data reading capabilities.
[0138] The data acquisition module 270 is used to determine the data storage file of the test class by using the data source setting capability, and to obtain the test data line corresponding to the method name of the method to be tested from the data storage file by using the data reading capability.
[0139] The method testing module 280 is used to execute the core test logic method based on the test data in the test data row and obtain the test results of the method under test.
[0140] In one embodiment, this application also provides a storage medium storing computer-readable instructions, which, when executed by one or more processors, cause the one or more processors to perform the steps of the software test engineering conversion method and the software test engineering test method as described in any of the above embodiments.
[0141] In one embodiment, this application also provides a computer device storing computer-readable instructions, which, when executed by one or more processors, cause the one or more processors to perform the steps of the software test engineering conversion method and the software test engineering test method as described in any of the above embodiments.
[0142] Indicatively, such as Figure 5 As shown, Figure 5 This is a schematic diagram of the internal structure of a computer device 300 provided in an embodiment of this application. The computer device 300 can be provided as a server. (Refer to...) Figure 5The computer device 300 includes a processing component 302, which further includes one or more processors, and memory resources represented by memory 301 for storing instructions executable by the processing component 302, such as application programs. The application programs stored in memory 301 may include one or more modules, each corresponding to a set of instructions. Furthermore, the processing component 302 is configured to execute instructions to perform the software test engineering conversion method and software test engineering test method of any of the above embodiments.
[0143] The computer device 300 may also include a power supply component 303 configured to perform power management of the computer device 300, a wired or wireless network interface 304 configured to connect the computer device 300 to a network, and an input / output (I / O) interface 305. The computer device 300 may operate on an operating system stored in memory 301, such as Windows Server™, Mac OS X™, Unix™, Linux™, Free BSD™, or similar.
[0144] Those skilled in the art will understand that Figure 5 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.
[0145] Finally, it should be noted that in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, 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. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.
[0146] The various embodiments in this specification are described in a progressive manner. Each embodiment focuses on the differences from other embodiments. The various embodiments can be combined as needed, and the same or similar parts can be referred to each other.
[0147] The above description of the disclosed embodiments enables those skilled in the art to make or use this application. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of this application. Therefore, this application is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.
Claims
1. A software test engineering conversion method, characterized in that, The method includes: The test class inheriting from the test base class is identified from the original test project, and the original base class in the test class is replaced with the new base class; the new base class is reconstructed based on the original base class by adding data source setting capabilities and data reading capabilities. The test class after the base class is replaced is parsed to obtain the original test method containing multiple scenario test cases, and the core test logic method corresponding to the original test method is generated; the core test logic method reads the test data line from the data storage file of the test class by calling the new base class; Based on the data storage file and the core test logic method, an independent test method is generated for each scenario test case; wherein, each scenario test case has a corresponding test data line in the data storage file; The original test project is structurally transformed based on each independent test method to obtain a new test project.
2. The software test engineering conversion method according to claim 1, characterized in that, The reconstruction process of the new base class includes: Determine the original base class in the test class, and obtain the intermediate base class by inheriting the original capabilities of the original base class through the newly created parent class; The ability to set up a data source is established; the data reading capability is used to specify the path of the data storage file for the test class. Build a data reading capability; the data reading capability is used to load the test data line corresponding to the current scenario use case in the data storage file; The data source setting capability and the data reading capability are added to the intermediate base class to form a new base class.
3. The software test engineering conversion method according to claim 1, characterized in that, The core method for generating the test logic corresponding to the original test method includes: The original test method is parsed to obtain the test logic code and the code content of the test logic code. A new data-driven framework is built based on the data source setting and data reading capabilities of the new base class; The code content is transferred from the original data-driven framework in the test logic code to the new data-driven framework to form the core method of the test logic.
4. The software test engineering conversion method according to claim 1, characterized in that, The method for generating independent test methods for each scenario test case based on the data storage file and the core test logic includes: Traverse the data storage file to determine the scenario test cases for each test class; each row of test data in the data storage file corresponds to one scenario test case; Multiple method names are generated sequentially according to the line order of the data storage file, and a mapping relationship is established between each method name and the number of data lines; Based on the mapping relationships and the core test logic method, an independent test method is generated for each scenario test case.
5. The software test engineering conversion method according to claim 1, characterized in that, The method further includes: When a new scenario test case is added to the test class, a test data row for the new scenario test case is added to the data storage file; Determine the core test logic method corresponding to the new scenario test case, and generate an independent test method corresponding to the new scenario test case based on the core test logic method and the test data row; The independent test method is tested, and after the test is successful, the independent test method is added to the new test project.
6. A software engineering testing method, characterized in that, The method includes: When performing smoke testing on test classes in a new test project, independent test methods carrying core identifiers are selected from the test classes and marked as methods to be tested; wherein, the test class contains multiple independent test methods, and each independent test method corresponds to a scenario test case; The core test logic method in the method under test is triggered to call the new base class; the new base class includes data source setting capabilities and data reading capabilities. The data source setting capability is used to determine the data storage file of the test class, and the data reading capability is used to obtain the test data line corresponding to the method name of the method to be tested from the data storage file; Based on the test data in the test data row, the core method of the test logic is executed to obtain the test result of the method to be tested.
7. A software testing engineering conversion device, characterized in that, include: The base class refactoring module is used to identify test classes that inherit from the test base class from the original test project, and replace the original base class in the test class with the new base class. The new base class is reconstructed based on the original base class by adding data source setting capabilities and data reading capabilities; The code parsing module is used to parse the code of the test class after the base class is replaced, obtain the original test method containing multiple scenario test cases, and generate the core test logic method corresponding to the original test method; The core method of the test logic reads the test data line from the data storage file of the test class by calling the new base class; The scenario-independent module is used to generate independent test methods for each scenario test case based on the data storage file and the core test logic method; wherein, each scenario test case has a corresponding test data line in the data storage file; The project conversion module is used to perform structural conversion on the original test project based on each independent test method to obtain a new test project.
8. A software testing engineering testing device, characterized in that, include: The method marking module is used to filter out independent test methods carrying core identifiers from the test classes in a new test project when performing smoke tests on the test classes, and mark them as methods to be tested; wherein, the test class contains multiple independent test methods, and each independent test method corresponds to a scenario test case; The base class invocation module is used to trigger the core test logic method in the method under test to call the new base class; the new base class includes data source setting capabilities and data reading capabilities. The data acquisition module is used to determine the data storage file of the test class by using the data source setting capability, and to obtain the test data line corresponding to the method name of the method to be tested from the data storage file by using the data reading capability; The method testing module is used to execute the core method of the test logic based on the test data in the test data row, and obtain the test result of the method to be tested.
9. A storage medium, characterized in that: The storage medium stores computer-readable instructions that, when executed by one or more processors, cause the one or more processors to perform the steps of the software test engineering conversion method as described in any one of claims 1 to 6, and the steps of the software test engineering test method as described in claim 7.
10. A computer device, characterized in that, include: One or more processors, and memory; The memory stores computer-readable instructions that, when executed by the one or more processors, perform the steps of the software test engineering conversion method as described in any one of claims 1 to 6, and the steps of the software test engineering test method as described in claim 7.