Database migration test case generation method and device, equipment and storage medium

Abstract

The application discloses a database migration test case generation method and device, equipment and a storage medium, and relates to the technical field of database migration. The method comprises the following steps: obtaining a difference SQL path corresponding to a syntax difference rule between a source database and a target database in a code file to be migrated from the source database to the target database, and a test point corresponding to the difference SQL path; performing static change analysis on the code file to obtain a change SQL path and change interface information associated with the change SQL path; based on a path matching relationship between the difference SQL path and the change SQL path, associating and fusing the test point and the change interface information to generate association relationship data for indicating a test range; and calling an artificial intelligence model to generate a test case file according to the association relationship data.

Description

Technical Field

[0001] This application relates to the field of database migration technology, and in particular to a method, apparatus, device and storage medium for generating database migration test cases. Background Technology

[0002] Existing database migration testing requires testers to manually select the test scope and key points from a large number of data difference assets when generating test cases. This is time-consuming and prone to omissions, resulting in incomplete analysis of the impact of database associations.

[0003] Therefore, existing data migration testing suffers from low testing efficiency and low testing accuracy, which urgently need to be addressed. Summary of the Invention

[0004] The main purpose of this application is to provide a method, apparatus, device and storage medium for generating database migration test cases, which aims to solve the technical problems of low testing efficiency and low testing accuracy in existing data migration tests.

[0005] To achieve the above objectives, this application proposes a method for generating database migration test cases, the method comprising: Obtain the difference SQL paths in the code files of the source database to be migrated to the target database, which correspond to the syntax difference rules between the source database and the target database, as well as the test points corresponding to the difference SQL paths; Perform static change analysis on the code file to obtain the change SQL path and the change interface information associated with the change SQL path; Based on the path matching relationship between the difference SQL path and the change SQL path, the test points and the change interface information are associated and fused to generate association relationship data for indicating the test scope; Based on the aforementioned relationship data, an artificial intelligence model is invoked to generate test case files for database migration testing.

[0006] Furthermore, to achieve the above objectives, this application also proposes a database migration test case generation device, which includes: The first scanning module is used to obtain the difference SQL path in the code file of the source database to be migrated to the target database, which corresponds to the syntax difference rules between the source database and the target database, and the test points corresponding to the difference SQL path; The second scanning module is used to perform static change analysis on the code file to obtain the changed SQL path and the change interface information associated with the changed SQL path; The scope analysis module is used to associate and fuse the test points and the changed interface information based on the path matching relationship between the difference SQL path and the change SQL path, and generate association relationship data to indicate the test scope. The test case generation module is used to generate test case files for database migration testing by calling an artificial intelligence model based on the relationship data.

[0007] In addition, to achieve the above objectives, this application also proposes a database migration test case generation device, which includes: a memory, a processor, and a database migration test case generation program stored on the memory and capable of running on the processor. The database migration test case generation program is configured to implement the steps of the database migration test case generation method described above.

[0008] In addition, to achieve the above objectives, this application also provides a storage medium storing a program that implements a database migration test case generation method. The program that implements the database migration test case generation method is executed by a processor to implement the steps of the database migration test case generation method as described above.

[0009] This application provides a method, apparatus, device, and storage medium for generating database migration test cases. The method includes: obtaining the difference SQL paths in the code file of the source database to be migrated to the target database, corresponding to the syntax differences between the source and target databases, and the test points corresponding to the difference SQL paths; performing static change analysis on the code file to obtain the change SQL paths and the change interface information associated with them; based on the path matching relationship between the difference SQL paths and the change SQL paths, associating and fusing the test points and change interface information to generate association relationship data for indicating the test scope; and using the association relationship data to call an artificial intelligence model to generate test case files.

[0010] This application optimizes the accuracy and completeness of automatically identified test scope through the correlation and fusion analysis of SQL rule difference scanning and static code analysis, and combines the optimized test scope with the call of artificial intelligence model to realize intelligent generation of test cases, thereby effectively improving the testing efficiency and test accuracy of database migration testing. Attached Figure Description

[0011] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0012] 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, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0013] Figure 1 This is a flowchart illustrating the first embodiment of the database migration test case generation method of this application; Figure 2 This is a flowchart illustrating the second embodiment of the database migration test case generation method of this application; Figure 3 A schematic diagram of the model workflow for generating database migration test cases in this application; Figure 4 This is a simplified flowchart illustrating the database migration test case generation method used in this application. Figure 5 This is a schematic diagram of the module structure of the database migration test case generation device according to an embodiment of this application; Figure 6 This is a schematic diagram of the hardware operating environment involved in the database migration test case generation method in this application embodiment.

[0014] The purpose, features, and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0015] It should be understood that the specific embodiments described herein are merely illustrative of the technical solutions of this application and are not intended to limit this application. Furthermore, all actions involving the acquisition of signals, information, or data in this application are performed in accordance with the relevant data protection regulations of the country where the application is located and with authorization from the owner of the corresponding device.

[0016] To better understand the technical solution of this application, a detailed description will be provided below in conjunction with the accompanying drawings and specific implementation methods.

[0017] It should be noted that the execution subject of this embodiment can be a database migration test case generation system, or a computing service device with data processing, network communication, and program execution functions, such as a tablet computer, personal computer, or mobile phone, or a database migration test case generation device capable of performing the above functions. This embodiment does not specifically limit it in this way. The following uses a database migration test case generation device (hereinafter referred to as the generation device) as the execution subject as an example to describe this embodiment and the following embodiments.

[0018] Based on this, embodiments of this application provide a method for generating database migration test cases, referring to... Figure 1 , Figure 1 This is a flowchart illustrating the first embodiment of the database migration test case generation method of this application.

[0019] In this embodiment, the database migration test case generation method includes steps S10 to S40: Step S10: Obtain the difference SQL path in the code file of the source database to be migrated to the target database, which corresponds to the syntax difference rules between the source database and the target database, and the test points corresponding to the difference SQL path; Understandably, the source database can be the business system to be migrated that, before migration, carries data and executes SQL (Structured Query Language), corresponding to the data and code source of the database migration project. The target database, on the other hand, can be the target database system that the business system will switch to after the database migration project is completed, serving as the object for subsequent SQL syntax compatibility verification.

[0020] At this point, the code file can be a program file containing SQL execution statements in the business system to be migrated, such as an XML-formatted SQL mapping file that stores SQL statements in a Java project using the MyBatis framework. This code file is the core carrier for syntax scanning and change analysis in this embodiment.

[0021] It is easy to understand that syntax difference rules refer to the standardized rules governing the functional and stylistic differences between the source and target databases in terms of SQL syntax, numeric operations of built-in functions, data types, index constraints, and date processing. Furthermore, in this embodiment, these syntax difference rules serve as the core judgment criteria for performing standardized difference scanning between the source and target databases.

[0022] Understandably, the difference SQL path can be the complete file path in the project that, after scanning for syntax differences according to rules, contains SQL mapping files with incompatible / unverified syntax. This embodiment can locate code locations with migration compatibility risks based on the difference SQL path. The test points can refer to the specific set of checks that need to be verified for each type of syntax difference, such as the consistency of function return values, the correctness of boundary value handling, and the compatibility of null input parameters. These are the core input criteria for generating test cases in this embodiment.

[0023] For example, this embodiment can perform a full keyword scan on the SQL mapping files in the migration project based on a pre-built database syntax difference rule base, identify file paths with syntax difference risks, i.e., difference SQL paths, and match the test verification points corresponding to the scanned keywords from the rule base.

[0024] In a feasible implementation, step S10 may include steps A1-A3: Step A1: Obtain the difference keywords representing the syntactic difference rules between the source database and the target database from the pre-built database difference rule library; Understandably, the aforementioned database difference rule base (hereinafter referred to as the rule base) can be a pre-built standardized knowledge base, which can be regularly reviewed and iteratively optimized by a panel of senior database experts, and stores the mapping relationship of all syntactic differences between the source database and the target database. In addition, the rule base may contain core data such as difference keywords, difference types, compatible syntax descriptions, and corresponding test points, which serve as the core benchmark assets for difference scanning in this embodiment.

[0025] It is important to understand that the aforementioned difference keywords can be characteristic strings that uniquely identify a certain type of SQL syntax difference, such as Oracle's "MONTHS_BETWEEN" function, "TO_NCHAR" function, and "AUTO_INCREMENT" syntax, which correspond to the smallest unit for scanning and matching in this embodiment. In this case, the generation device can retrieve the full set of difference keywords from the database difference rule base as preparatory information for subsequent scanning steps.

[0026] For example, the generation device can first call the pre-built database difference rule library interface to filter the full set of difference rules for the corresponding types based on the source and target database types of this migration project. Then, it extracts all difference keywords from the difference rules to form a keyword pattern set, and simultaneously loads the pre-stored association mapping data such as difference type, compatible syntax, and test points for each keyword from the rule library. Finally, the generation device can compile the keyword set into a regular expression matching pattern and load it into the scanning engine to complete the rule preparation before scanning.

[0027] Step A2: Locate the SQL mapping file in the code file of the source database according to the preset pipeline tag information, and scan the SQL mapping file line by line to determine the difference SQL path containing the difference keyword, and the matching keyword corresponding to the difference SQL path; Understandably, the aforementioned pipeline tag information can be unique identifiers for CI / CD continuous integration pipelines, such as pipeline number and pipeline name. This embodiment can use this tag to locate the project code directory and file range corresponding to this release, achieving precise targeting of the scanning scope.

[0028] It is easy to understand that the aforementioned SQL mapping file can be an XML (Extensible Markup Language) format file used in the MyBatis framework to store SQL statements. This is the direct object file for syntax scanning in this embodiment, and it is typically stored uniformly in the Mybatis directory of the migration project. At this point, the production device can locate the code directory for this release based on the pipeline tag information, and then search all XML format SQL files of the MyBatis framework in the directory to determine the target scanning scope.

[0029] Understandably, the aforementioned matching keywords can refer to the difference keywords that are actually matched after scanning the SQL mapping file line by line. These matching keywords can correspond to the index keys for subsequent queries of test points and difference types from the rule base. At this point, the generation device can use a regular expression matching algorithm to iterate through the text content of each SQL mapping file line by line, performing string matching with the difference keywords. If a match is found, the corresponding file path is marked as the difference SQL path.

[0030] For example, the production device can first receive a scan task triggered by a CI / CD (Continuous Integration / Continuous Delivery) pipeline, obtain the pipeline tag information carried by the task, and then, based on the mapping relationship between the pipeline tag and the code directory, accurately locate the project code repository path corresponding to this release, and further locate the MyBatis folder directory in the project. Next, it traverses all XML format files in the MyBatis folder and determines them as the scope of SQL mapping files for this scan, avoiding scanning non-SQL code files in the project.

[0031] Then, the scanning engine is activated, and a regular expression matching algorithm is used to traverse each SQL mapping file line by line, matching and verifying the file content against the difference keyword pattern. If at least one difference keyword is detected in a file, the complete project path of that file is marked as the difference SQL path, and all matching keywords under that path are recorded as matching keywords. Therefore, this embodiment can accurately lock the scanning range through pipeline tags, and combined with regular expression line-by-line matching technology, it can complete a full difference scan of tens of thousands of lines of code within minutes. Compared with existing manual screening, this embodiment can effectively improve screening efficiency. At the same time, this embodiment can scan based on a standardized rule base reviewed by experts, so that the identification results are not affected by the experience of the testers, ensuring the consistency of scanning results performed by different projects and different personnel, and achieving standardization of identification results.

[0032] Step A3: Based on the matching keywords, obtain the test points corresponding to the differential SQL path from the database differential rule base.

[0033] Furthermore, the generation device can also scan the matched keywords as indexes, perform mapping queries in the database difference rule base, retrieve the corresponding test point set, and realize automatic linkage between the scan results and verification points. For example, the generation device can use the matched keywords under each difference SQL path as indexes, traverse the mapping relationship of the database difference rule base, and query the test points corresponding to each matched keyword in the rule base one by one. Then, it can deduplicate and aggregate the test points corresponding to multiple keywords under the same SQL path, and finally form a complete scan result of "difference SQL path - matched keyword - corresponding test point", and output it as a standardized rule difference scan file.

[0034] Therefore, this embodiment can directly output the corresponding test points after keyword matching and scanning is completed, based on the pre-established mapping relationship between keywords and test points in the rule base, without the need for manual secondary matching, which can effectively reduce repetitive work. In addition, the rule base can be reused in all similar database migration projects and supports continuous iterative updates, achieving the effect of rules becoming more accurate with use.

[0035] Step S20: Perform static change analysis on the code file to obtain the change SQL path and the change interface information associated with the change SQL path; Understandably, the aforementioned static change analysis refers to identifying code content changes and tracing code call relationships in advance through techniques such as code version comparison and syntax structure parsing, without running the code program. Correspondingly, the aforementioned changed SQL path can refer to the file path of the SQL mapping file in the project where the SQL statement content of the changed content has been added, deleted, or modified. This embodiment can locate the actual code location where the code modification has occurred based on the changed SQL path.

[0036] At this point, the changed interface information can be the upper-layer business external interface information obtained by tracing the changed SQL statement upwards. In this embodiment, the scope of business impact corresponding to the code change can be clearly defined based on this. The generation device can then use abstract syntax tree parsing technology to trace the call chain of the changed SQL statement upwards, ultimately locating the business interface information corresponding to the changed SQL, i.e., the changed interface information.

[0037] It is easy to understand that, in order to solve the problems of existing technologies where the scope of changes relies entirely on manual sorting by developers, which easily leads to the omission of related interfaces and incomplete impact analysis, this embodiment can achieve automatic identification of change SQL and full-link interface tracing through automated static code analysis technology. Therefore, in a feasible implementation, in this embodiment, step S20 includes steps S21~S22: Step S21: Identify the SQL statement that has undergone code changes based on the SQL execution logic of the code file, and determine the changed SQL path; It's important to understand that SQL execution logic refers to the complete code logic chain of defining, calling, and executing corresponding SQL statements. This can include SQL statements defined in XML, calling methods in the DAO layer, and execution logic in the business layer. In this embodiment, it is the analysis object for identifying SQL changes. At this point, the generation device can use code version comparison technology to compare the differences between the current release code and the baseline code of the previous version, identify the SQL statements whose content has been added, deleted, or modified, and determine the changed SQL path.

[0038] For example, the production device can first pull the code baseline of the current release version and the previous stable production version to obtain a full list of files for both codebases. Then, using a text difference comparison algorithm, it compares the SQL mapping files in the two codebases file-by-file and line-by-line to identify the SQL statements that have been added, deleted, or modified in the current codefiles, locates the SQL mapping files containing these SQL statements, and records the file paths as changed SQL paths. Finally, the production device can compile a list of all changed SQL paths to clarify the scope of SQL files actually modified in this iteration.

[0039] Step S22: By analyzing and tracing the call chain of the changed SQL path through abstract syntax tree, determine the changed business interface associated with the changed SQL path, and obtain the changed interface information associated with the changed SQL path.

[0040] Understandably, an Abstract Syntax Tree (AST) refers to a tree-like structure generated after parsing source code according to syntactic rules. This AST clearly presents the hierarchical structure, call relationships, and syntactic semantics of the code. In this case, the aforementioned call chain can be a complete code call path tracing upwards from the execution location of the SQL statement to the DAO (Data Access Object) layer, Service layer, and Controller layer. This call chain can be used to trace the upper-level business entry point corresponding to the SQL statement. That is, this embodiment can, based on the AST parsing results, start from the execution node of the SQL statement and search upwards layer by layer for method call relationships until the top-level business interface is located. In this case, this embodiment covers all levels of call relationships through full-link tracing based on AST, including indirectly called interfaces, avoiding potential omissions that may occur with existing manual analysis and ensuring the completeness of the change impact analysis.

[0041] Therefore, the aforementioned change business interface can be the external business interface ultimately located by the SQL statement of code change through the call chain. It is typically an HTTP (Hypertext Transfer Protocol) interface or an RPC (Remote Procedure Call) interface at the Controller layer, serving as the core identifier of the business impact scope corresponding to the change SQL statement. The aforementioned change interface information can be structured information of the change business interface. In this embodiment, it may include the interface name, interface path, request method, affiliated functional module, and affiliated business domain. At this time, the generation device can extract the structured information such as the name and path of the business interface associated with the change SQL path by parsing the interface annotations and configuration files in the code, thus obtaining the change interface information. Therefore, this embodiment can automatically complete the identification of change SQL and interface tracing, achieving the effect of outputting the complete change scope within minutes, effectively improving the efficiency of the process.

[0042] For example, the generation device can parse the XML file corresponding to each identified change SQL path to obtain the unique identifier ID (Identity) corresponding to the change SQL statement; then perform abstract syntax tree parsing on the Java code of the migration project to build a method call relationship graph for the entire project; and then search for the Mapper method corresponding to the identified SQL ID in the DAO layer as the starting point of the call chain.

[0043] Then, the generation device can traverse upwards from the Mapper method, layer by layer, based on the method call graph to find the upper-level business method that calls the method, successively passing through the Service layer and the Manager layer, and finally locating the interface method in the Controller layer. Next, the generation device can mark the located top-level interface method as the change business interface corresponding to the change SQL. At the same time, it performs annotation parsing on the located change business interface, identifies interface annotations such as "@ApiOperation", "@RequestMapping", and "@PostMapping", extracts information such as interface name, request path, and request method, and combines the code package path and module configuration to parse the functional module and business domain information to which the interface belongs.

[0044] Finally, the generating device integrates all information to form a structured static code analysis result of "Change SQL Path - Change Business Interface - Interface Details", and outputs it as a change code analysis file. Therefore, this embodiment can output structured and standardized change interface information, which testers can directly associate with business functions to quickly clarify the scope of the test.

[0045] Step S30: Based on the path matching relationship between the difference SQL path and the change SQL path, the test points and the change interface information are associated and fused to generate association relationship data for indicating the test scope; Understandably, the aforementioned path matching relationship refers to the degree of matching between the code files pointed to by the difference SQL path and the change SQL path, respectively. That is, this embodiment can associate and integrate the aforementioned difference scan results and the aforementioned change analysis results by determining whether the difference SQL path and the change SQL path point to the same code file. Therefore, in the aforementioned association and fusion process, this embodiment can use the SQL path as the association link, for example, using the file path as the matching key, and use a filename fuzzy matching algorithm to map and bind the test points of the syntax difference dimension with the change interface information of the code change dimension, forming a unified associated dataset.

[0046] It is easy to understand that the aforementioned relational data can refer to the structured dataset generated after correlation and fusion, which may contain the mapping relationship between "different SQL paths - changed business interfaces - corresponding test points". This embodiment can completely and clearly indicate the test coverage of this database migration based on this relational data.

[0047] Step S40: Based on the relationship data, call the artificial intelligence model to generate test case files for database migration testing.

[0048] It is easy to understand that the aforementioned artificial intelligence model can be a large language model with knowledge of database migration, and this embodiment can adopt a multi-round iterative Agent architecture of "generation-review-modification" to automatically generate standardized test cases based on the test points in the relational data. Accordingly, the aforementioned test case file can be a structured file containing fields such as test scenario number, verification scope, verification points, and expected results, and the test case file conforms to the import format of the test case management platform and can be directly used for test execution, thereby further improving testing efficiency.

[0049] Therefore, in this embodiment, the structured relational data can be input into the artificial intelligence model, and the model can automatically design test scenarios, output verification points and expected results, and finally organize and generate standardized test files.

[0050] In summary, to address the problems of existing test case generation solutions that rely on manual screening of massive amounts of differing assets, resulting in high time consumption, heavy workload, and low testing efficiency; and the potential for missing related interfaces, leading to incomplete impact analysis and insufficient test coverage, this embodiment achieves the effect of covering all syntax differences and relating them to actual business changes through two-dimensional data fusion of SQL rule difference scanning and static code analysis. This enables automated identification of a complete and accurate test scope. It effectively replaces a large amount of repetitive work in manual screening and sorting, improves overall test design efficiency, and ensures the completeness and accuracy of the test scope.

[0051] Furthermore, addressing the issues of traditional solutions where test cases rely entirely on manual writing, demanding high levels of experience from testers, making it difficult for newcomers to quickly produce qualified test cases, and resulting in low writing efficiency, this embodiment can automate the output of standardized test results by deeply integrating artificial intelligence capabilities with database migration test scenarios. This allows testers to quickly conduct migration testing by calling artificial intelligence models through the aforementioned generated structured relational data, without needing extensive knowledge of database differences or experience in test case design, thereby further improving testing efficiency.

[0052] This embodiment provides a method for generating database migration test cases. The method includes: obtaining the difference SQL paths in the code file of the source database to be migrated to the target database, corresponding to the syntax difference rules between the source database and the target database, and the test points corresponding to the difference SQL paths; performing static change analysis on the code file to obtain the change SQL paths and the change interface information associated with the change SQL paths; based on the path matching relationship between the difference SQL paths and the change SQL paths, associating and fusing the test points and change interface information to generate association relationship data for indicating the test scope; and calling an artificial intelligence model to generate test case files based on the association relationship data.

[0053] This embodiment optimizes the accuracy and completeness of automatically identified test scope through the correlation and fusion analysis of SQL rule difference scanning and static code analysis. It also calls an artificial intelligence model to intelligently generate test cases based on the optimized test scope, thereby effectively improving the testing efficiency and accuracy of database migration testing.

[0054] Based on the first embodiment of this application, in the second embodiment of this application, the same or similar content as the first embodiment described above can be referred to the above description, and will not be repeated hereafter.

[0055] It is easy to understand that the above-mentioned preset classification model needs to be iteratively trained before classifying the processed experimental data. Therefore, based on the first embodiment, please refer to... Figure 2 , Figure 2This is a flowchart illustrating the second embodiment of the database migration test case generation method of this application. In this embodiment, step S40 includes steps S41 to S44: Step S41: Obtain the target difference type from the database difference rule base according to the matching keyword; Understandably, the aforementioned target difference types can be classifications of syntactic differences between the source and target databases obtained from the rule base based on matching keywords, and can be used to provide a scenario context for generating test cases for artificial intelligence models. In this embodiment, the target difference types may include four main categories: date processing differences, type conversion differences, numeric operation differences, and index and constraint differences.

[0056] Step S42: Input the target difference type and the test points in the correlation data into the artificial intelligence model to generate initial test cases. The initial test cases include verification points and expected results. At this point, the initial test cases can refer to the set of test cases generated by the AI ​​model in the first round, which may include fields such as test scenario (i.e., the aforementioned target difference type), verification points, and expected results. Verification points refer to the specific content in the test cases that needs to be verified, corresponding to the test points in the input data, and can serve as the core operational basis for executing the database migration test. Expected results can be specific, quantifiable, and verifiable standards clearly defined in the test cases, serving as the basis for determining whether the database migration test has passed.

[0057] Understandably, the generating device can input the test points from the target difference type and correlation data into the artificial intelligence model. The model, based on pre-configured domain knowledge and contextual reasoning capabilities, designs test scenarios for the target difference type and outputs verification points and expected results corresponding to the test points, generating the first round of test cases.

[0058] Step S43: Iteratively optimize the initial test cases until the real-time test cases output by the artificial intelligence model meet the preset output conditions, and obtain the full set of test cases; Understandably, the aforementioned iterative optimization can refer to the use of a "generate-review-modify" loop mechanism to optimize the initial test cases multiple times until it is determined that the real-time test cases output by the artificial intelligence model meet the quality requirements corresponding to the preset output conditions. Here, the preset output conditions can be pre-defined test case qualification criteria. In this embodiment, the preset output conditions can be expressed as "the verification points corresponding to the real-time test cases output by the model must cover all input test points, and all expected results must be clear, executable, and unambiguous."

[0059] It's easy to understand that the aforementioned full set of test cases can be a complete set of test cases that has undergone multiple rounds of iterative optimization and meets the preset output conditions. This set can cover all the test points input during migration testing from the source database to the target database. At this point, the generation device can use a multi-round dialogue agent collaboration mechanism to cyclically execute the "review-modification" process. In the review stage, it checks the coverage of key points and the clarity of results. In the modification stage, it supplements missing key points and corrects ambiguous results until the qualification standard is met.

[0060] Therefore, this embodiment can ensure the quality of test cases generated by the artificial intelligence model through an iterative optimization mechanism of "generation-review-modification," and organize them according to business interfaces. This addresses the problems of unstable test case output, omission of key points, vague expected results, and fragmented test cases that cannot be directly implemented in existing artificial intelligence models, effectively outputting high-quality, directly executable full-scale test cases. For ease of understanding, refer to... Figure 3 The iterative optimization process of the model will be explained. Figure 3 This is a schematic diagram of the model workflow for generating database migration test cases in this application.

[0061] like Figure 3 As shown, in this embodiment, the generation device can first obtain the combination type of the source database and target database involved in the migration project during the input parsing stage, that is... Figure 3 The migration type is specified, such as Oracle to GaussDB or MySQL to PostgreSQL. The core function of this step is to define the scope of the generated test cases, ensuring that subsequent rule bases and test points match the migration type and preventing the generation of irrelevant content. Then, a pre-configured professional knowledge base that the device can recognize is generated. Figure 3 Domain knowledge - center checklist.

[0062] Next, in the migration test case generation phase, the generation device can retrieve the database difference rule base corresponding to the current migration type from the domain knowledge-center check list based on the migration type. This step injects specialized domain knowledge of database migration into the subsequent intelligent test case generation process, avoiding the artificial intelligence model's reliance on general knowledge to generate test cases and ensuring that the test cases subsequently generated by the model conform to migration testing specifications.

[0063] Then, the generation device can retrieve syntax compatibility check rules from the database difference rule base. At this point, the generation device can use the matching keywords corresponding to each difference SQL path as an index to query the difference category mapping relationship in the database difference rule base, extracting the difference types corresponding to the matching keywords, such as date processing differences, numeric operation differences, etc., as scenario context information for subsequent AI model-generated test cases. Simultaneously, based on the matching keywords, it can extract compatibility verification rules for various types of syntax differences from the rule base, including fully compatible, conditionally compatible, and completely incompatible, as well as the verification logic and concerns corresponding to each type of difference, i.e., test points.

[0064] Next, the generation device can extract test points and design test scenarios based on the acquired rules. At this point, the generation device can organize the target difference types and corresponding test points into a structured Prompt, and clarify that the role of the artificial intelligence model is an advanced database testing expert, whose core task is to generate executable test cases based on the test points. Then, the structured Prompt is input into the artificial intelligence model to trigger the test case generation process, so that the model designs corresponding test scenarios one by one according to the test points and difference types, clarifies the verification points and expected results of each scenario, and outputs an initial test case set in JSON format.

[0065] Once the initial test cases are generated, the test case review phase can be automatically triggered. For example... Figure 3 As shown, in this process, the AI ​​model can extract the original test points and compare the initial test cases with the test points, checking one by one whether all test points are covered and counting any missing points. At the same time, it can also check one by one whether the expected result of each test case is specific and verifiable, eliminating vague and general statements. Then, the review results can be output, indicating whether it is qualified. If it is unqualified, the missing points and the problematic test cases are identified.

[0066] At this point, during the test case modification phase, if the review fails—that is, if a test case is found to have missing checkpoints or unclear or ambiguous expected results—the test case modification process can be automatically triggered. For missing test points, the model can automatically generate corresponding test cases; for test cases with ambiguous expected results, the model can correct and optimize them to make the expected results clear and executable.

[0067] Afterwards, the model can output a modified set of test cases and repeat the review and modification process, forming an iterative loop, until the review results determine that the test cases cover all test points and all expected results meet the explicitness requirements, i.e., when the preset output conditions are met, the artificial intelligence model finally outputs a qualified full set of test cases. Figure 3The structured output is used in the model. Therefore, this embodiment can effectively solve the problem of unstable output of large models through a multi-round iterative mechanism of "generation-review-modification", ensuring comprehensive coverage of test points and that the expected results of model output test cases are clear and executable, thus effectively improving the quality of test cases.

[0068] Step S44: Classify and organize all test cases according to the change interface information in the association data, and generate test case files.

[0069] It should be noted that the device can extract the changed interface information from the associated data, establish a mapping relationship of "SQL path - changed interface", and then classify and organize all test cases according to the corresponding changed interface, the corresponding compatibility type, etc., so that all test cases of the same type can be integrated into a test file. Finally, a standardized test case file containing multiple test files is generated that can be directly imported and used without manual secondary processing.

[0070] Furthermore, this embodiment can introduce a compatibility risk rating to achieve a two-dimensional, refined classification of test cases. This addresses the problem that existing test cases do not differentiate risk levels, making it difficult for testers to allocate testing efforts reasonably, resulting in insufficient verification of high-risk scenarios and wasted resources in low-risk scenarios, thus achieving a differentiated testing strategy. In a feasible implementation, step S44 may include steps B1-B3: Step B1: Based on the matching keywords, obtain the target compatible syntax from the database difference rule base; Understandably, the target compatible syntax can be a syntax compatibility specification for the corresponding matching keyword obtained from the database difference rule base, including detailed information such as the support status of the syntax in the target database, compatibility prerequisites, and equivalent rewriting methods. For example, the generation device can use the matching keyword of each difference SQL path as an index to query the database difference rule base, thereby extracting the database types, version requirements, usage restrictions, and alternative syntax schemes pre-configured in the rule base for the matching keyword, as the target compatible syntax.

[0071] Step B2: Determine the compatibility tag of the SQL path corresponding to the matching keyword based on the target compatible syntax and the syntax type of the target database; Step B3: Classify the full set of test cases according to the changed interface information and the compatibility tags in the association data, and generate test case files.

[0072] At this point, the compatibility label can be an identifier representing the degree of syntax compatibility between the differential SQL path corresponding to each matching keyword and the target database. In this embodiment, the risk level after migrating the SQL path corresponding to the matching keyword to the target database can be intuitively identified based on the compatibility label. For example, in this embodiment, the generation device can combine the target compatible syntax and the version characteristics of the target database to rate the syntax compatibility of each differential SQL path and generate a corresponding compatibility label.

[0073] In one feasible implementation, the compatibility tags include fully compatible, conditionally compatible, and completely incompatible. Fully compatible means that the SQL syntax for matching keywords in the source database is natively and fully supported in the target database, requiring no code modification. After migration, the functionality and execution results are completely consistent with the source database, resulting in extremely low migration risk. Conditionally compatible indicates that the SQL syntax for matching keywords requires specific conditions to be met (such as the target database reaching a specified version, configuring specific parameters, or conforming to a specific use case) to function correctly in the target database, posing a certain migration risk. Completely incompatible means that the target database does not natively support the SQL syntax for matching keywords, requiring code rewriting to complete the migration, representing the highest migration risk. In this case, the judgment rules for each type of compatibility tag can be pre-entered into a database difference rule library and mapped one-to-one with the difference keywords.

[0074] Therefore, if the generating device detects that the current version of the target database natively fully supports the syntax corresponding to the matching keyword without any usage restrictions, the compatibility tag for the matching keyword can be marked as fully compatible; if the syntax requires specific version, specific parameter configuration, or specific use case to function properly, it can be marked as compatible under the corresponding conditions; if the target database does not support the syntax at all and code rewriting is required, it can be marked as completely incompatible. Ultimately, the generating device generates a unique compatibility tag for each identified differential SQL path.

[0075] In this embodiment, the generating device can be further classified based on the classification of changed interface information, by adding compatibility tags to create test case files with more dimensions. That is, this embodiment can achieve risk grading through compatibility tags, changing the testing scope from a "one-size-fits-all" approach to hierarchical management, and proposing a more scientific testing strategy.

[0076] Furthermore, in order to form a directly implementable tiered testing strategy and address the problem in existing technologies where the correspondence between compatibility tiers and testing strategies is unclear and cannot directly guide test execution, in a feasible implementation, the test case file includes at least one of the full set of test cases and a subset of the first to third test cases; in this embodiment, step B3 may include steps B31 to B33: Step B31: Summarize the test cases containing the changed interface information in the full set of test cases into a first subset of test cases; Step B32: The test cases in the full set of test cases that do not contain the changed interface information and whose compatibility type label is not the fully compatible SQL path are summarized into a second test case subset; Step B33: The test cases in the full set of test cases that do not contain the changed interface information and whose compatibility type label is the fully compatible SQL path are summarized into the third test case subset.

[0077] Understandably, the first subset of test cases can refer to the set of test cases in the full set of test cases that contain corresponding changed interface information, corresponding to the high-priority test scope of "having both syntax differences and code changes"; the second subset of test cases can refer to the set of test cases in the full set of test cases that do not contain corresponding changed interface information and whose compatibility label is not fully compatible, corresponding to the pending confirmation test scope of "having syntax differences but not changed this time"; and the third subset of test cases can refer to the set of test cases in the full set of test cases that do not contain corresponding changed interface information and whose compatibility label is fully compatible, corresponding to the low-risk test scope of "fully compatible syntax and not changed this time". At this point, testers can directly execute the corresponding test strategies based on the refined subset classifications, further improving testing efficiency.

[0078] It should be noted that the generation device can filter out test cases associated with changed interface information from the full set of test cases and integrate them to form a first subset of test cases. This subset corresponds to the scenario of "SQL differences + code changes" and can be marked as "key verification class". The testing strategy can be configured to perform full and detailed verification. For example, the generation device can traverse the full set of test cases, determine whether the SQL path corresponding to each test case is associated with changed interface information, and then summarize all test cases that are found to have corresponding changed interface information to form the first subset of test cases.

[0079] In addition, the generation device can filter out test cases with no changed interface information and non-fully compatible compatibility tags from the full set of test cases, and integrate them to form a second subset of test cases. This subset corresponds to the scenario of "SQL differences + no code changes", and can be marked as "pending confirmation". The testing strategy can be configured to confirm with the development team whether it needs to be handled. After confirmation, targeted testing will be performed on this subset. At this time, the generation device can further filter the test cases that are not associated with changed interface information after traversing the full set of test cases, and obtain the test cases whose compatibility tags are not "fully compatible" (i.e., conditionally compatible and completely incompatible). The test cases that meet this condition are summarized to form the second subset of test cases.

[0080] Simultaneously, the generation device can also filter out test cases with unchanged interface information and a fully compatible compatibility tag from the full set of test cases, integrating them to form a third subset of test cases. This subset corresponds to the scenario of "no SQL compatibility risk + no code change," and can be marked as "select coverage class." The testing strategy can be configured to select high-risk modules for sampling verification. At this point, the generation device can further filter out test cases with a "fully compatible" compatibility tag from the test cases with unchanged interface information, and then summarize the test cases that meet this condition to form the third subset of test cases. In this implementation, all test cases can be divided into two dimensions: "whether a change has occurred" and "compatibility level." This ensures that the categorized subsets address both the risks associated with changes and the compatibility risks inherent in the syntax itself. Furthermore, the three subsets further categorized based on compatibility tags and changed interface information can each correspond to three distinct testing strategies. This allows the output test case results to directly guide test execution, eliminating the need for testers to manually determine priorities.

[0081] Furthermore, as can be seen from the above generation process, this embodiment can set different labels for different test words (i.e., the above-mentioned "key verification class", "to be confirmed class" and "selection coverage class"), which allows testers to tilt test resources towards the high-risk first test case subset during the actual testing process, and only sample and verify the low-risk third use case set. This can effectively save test manpower input while ensuring test quality and maximize the efficiency of test resources.

[0082] Understandably, relying solely on code scanning can lead to incomplete coverage and omissions of implicit differences such as configuration and permissions. To ensure the comprehensiveness of migration testing, this embodiment also proposes a method to include non-code-related differences in the classification scope. In this case, as an implementation method, the test case file further includes a fourth subset of test cases; in this embodiment, steps S45-S47 may also be included after step S43: Step S45: Obtain the target data change type; Understandably, the aforementioned target data change types can refer to non-SQL code changes that cannot be identified through code scanning in this database migration project, such as changes to database configuration parameters, user permissions, transaction isolation levels, stored procedures, and database character sets. In this embodiment, the generation device can also identify all non-SQL code changes based on the migration plan and scope of this database migration project. Then, the changes are categorized to determine the corresponding target data change types.

[0083] Step S46: Obtain supplementary check items that do not support the static code analysis from the preset database difference document according to the target data change type; At this point, the pre-set database difference document can refer to a supplementary asset document of the database difference rule base. This document can also be pre-maintained by the database expert team and summarizes various difference check items that cannot be identified by SQL keyword scanning and static code analysis, as well as the corresponding test focus and check points.

[0084] Therefore, the aforementioned supplementary check items can be verification items recorded in the preset database difference document that cannot be scanned and covered by automated tools. They can supplement the aforementioned code scanning results, thereby ensuring the completeness of test coverage. At this time, the generation device can perform a matching search in the preset database difference document according to the target data change type, and filter out all supplementary check items under the corresponding type. Each supplementary check item can be accompanied by corresponding test points, verification methods, and precautions. In addition, supplementary check items can be continuously updated with project experience, thereby continuously improving the comprehensiveness of difference coverage.

[0085] Step S47: Based on the test points corresponding to the supplementary check items, select a fourth subset of test cases from the full set of test cases.

[0086] Understandably, the fourth subset of test cases can be an independent subset of test cases compiled based on the test points corresponding to the supplementary check items, corresponding to the test scope of "the tool does not support scanning and manual confirmation is required", supplementing the coverage blind spots of the aforementioned automated code scanning.

[0087] It's important to understand that the generation device can then match corresponding test points for each supplementary check item, compiling standardized test case entries containing fields such as verification scope, verification points, and expected results. These test case entries for all supplementary check items are then aggregated to form a fourth subset of test cases. This fourth subset can be marked as "Tool-unsupported scan items - pending confirmation," and the testing strategy can be configured for manual verification by testers and developers after confirmation.

[0088] Therefore, this embodiment can fill the coverage blind spots of automated code scanning based on the fourth test case subset, and include non-code differences in the test scope, further ensuring the integrity of migration testing and reducing the risk of going live.

[0089] This embodiment discloses a process for obtaining target difference types from a database difference rule base based on matching keywords; inputting the target difference types and test points from the association data into an artificial intelligence model to generate initial test cases, which include verification points and expected results; iteratively optimizing the initial test cases until the initial test cases output by the artificial intelligence model cover all test points and the expected results meet preset output conditions, thus obtaining a full set of test cases; obtaining target compatible syntax from the database difference rule base based on matching keywords; determining the compatibility label of the SQL path corresponding to the matching keywords based on the target compatible syntax and the syntax type of the target database; and classifying the full set of test cases according to the change interface information and compatibility labels in the association data to generate a test case file.

[0090] This embodiment also discloses that compatibility tags include fully compatible, conditionally compatible, and completely incompatible; the test case file includes all test cases and at least one of the first to third test case subsets. Test cases with changed interface information in the full set of test cases are summarized into a first test case subset; test cases with no changed interface information and whose compatibility type tag is not fully compatible for SQL paths in the full set of test cases are summarized into a second test case subset; test cases with no changed interface information and whose compatibility type tag is fully compatible for SQL paths in the full set of test cases are summarized into a third test case subset. The target data change type is obtained; supplementary check items that do not support static code analysis are obtained from a preset database difference document based on the target data change type; based on the test points corresponding to the supplementary check items, a fourth test case subset is selected from the full set of test cases.

[0091] In summary, this embodiment can ensure the quality of test cases generated by the artificial intelligence model through an iterative optimization mechanism of "generation-review-modification". It combines all the test cases generated by the model and organizes them by business interface and compatibility tags to achieve test case classification. Furthermore, it improves the subset of test cases that the generated code cannot scan. This solves the problems of unstable test case output, easy omission of key points, vague expected results, and fragmented test cases that cannot be directly implemented in the current artificial intelligence model. It outputs high-quality, directly executable test cases and allows testers to allocate testing efforts according to different test subsets, focusing on high-risk scenarios and simplifying verification of low-risk scenarios. This saves testing manpower while ensuring quality and further improves testing efficiency.

[0092] For example, to help understand the technical concept or principle of the database migration test case generation method after combining this embodiment with the above-described Embodiments 1 and 2, please refer to Figure 4 , Figure 4 A simplified flowchart illustrating the database migration test case generation method of this application is shown below: This application utilizes a two-dimensional data fusion approach—SQL rule difference scanning and static code analysis—to automatically identify a complete and accurate test scope. Combined with an artificial intelligence model, it intelligently generates test cases, thus addressing the problems of low efficiency and potential omissions in manual test scope selection, incomplete change impact analysis, and low efficiency due to reliance on human experience in test case writing in existing technologies. This overall improves the efficiency and accuracy of database migration testing. As shown in the figure, this application primarily achieves high-precision and high-efficiency automatic generation of database migration test cases through the following five steps: Step 1: Perform an SQL rule scan to obtain the differing SQL paths and corresponding test points: The generation device can pre-add rules for scanning, build a syntax difference rule library corresponding to the source and target databases, complete expert review and standardization of the rules, and then trigger a scanning task at the project release node to obtain the database difference rule library corresponding to the migration type. Then, using the difference keywords in the database difference rule library as the matching benchmark, a full scan of all SQL mapping files in the migration project is performed. At the same time, the scan results are downloaded and saved to a local folder.

[0093] Then, the device can parse the Excel files in the target folder, checking each file for discrepancy keywords. File paths containing these keywords are marked as discrepancy SQL paths, and the discrepancy keywords matched for each path are recorded as matching keywords. Based on the matched keywords, corresponding test points are queried from the discrepancy rule base. The obtained test points are then processed, removing duplicate checkpoints and appending unique checkpoints, forming the first basic dataset of "discrepancy SQL path - matching keyword - test point".

[0094] Step 2: Perform static change analysis to obtain the change SQL path and associated change interface information: At this point, the generation device can add static code analysis, which involves pulling the code baseline of the current release and the previous stable version, identifying all modified SQL statements by comparing the code content, locating the SQL mapping file where the changed SQL statements are located, and recording the file path as the changed SQL path.

[0095] The modification SQL statements are parsed using an abstract syntax tree, tracing the call chain layer by layer from the SQL execution location upwards to locate the DAO layer methods, Service layer business methods, and Controller layer external interfaces. Simultaneously, interface annotations and configuration files are parsed to extract information such as interface name and module, forming a second basic dataset of "Modification SQL Path - Modification Interface Information," thus revealing the relationship between the modification SQL file and the interface.

[0096] Step 3: Merge and correlate the two-dimensional data to generate correlation data for the test scope. The SQL path field is extracted from two basic datasets, and path matching is performed using "string inclusion matching" as the matching rule: it is determined whether the filename string of the changed SQL path is contained in the complete path string of the differing SQL path; if so, the match is considered successful. Then, for the successfully matched path entries, their corresponding test points are bound and integrated with the changed interface information; for the differing SQL paths that do not match the changed interface, their test point information is retained and marked as having no corresponding changed interface. Finally, the two basic datasets are integrated to form a structured relational data. This relational data can completely cover all SQL paths with syntactic differences and their corresponding interface information and test points, serving as the basis for the complete scope of this test.

[0097] Step 4: Call the artificial intelligence model to generate standardized test case files: The structured data in the relational data, such as transformation types (i.e., the aforementioned target difference types), test points, and keyword types, corresponding to the first basic dataset, are formatted and passed as input parameters to the artificial intelligence model (i.e., ...). Figure 4 The AI ​​model is then called to process the data. Based on the domain rules of database migration testing, corresponding test scenarios, verification points and expected results are generated for each test point to form an initial test case set.

[0098] Next, the initial test cases can be verified for completeness and compliance. After verification, the test cases are categorized and organized according to the file format requirements of the test management platform based on business interfaces and risk levels. Finally, test case files that can be directly imported into the test platform are output, completing the full set of test cases (i.e., Figure 4 Automatic generation of sheet1 in the document.

[0099] Step 5: Output all test cases by category: To further improve testing efficiency, all test cases can be categorized hierarchically based on the path matching relationship between differing and changed SQL paths, as well as compatibility tags, ultimately forming a subset of five test cases (i.e., Figure 4 The test case files (sheets 1-5) in the document.

[0100] Understandably, the generating device can first use "if the SQL has changed" as the judgment node. That is, this application can perform primary classification based on the path matching relationship between the difference SQL path and the change SQL path. The classification method can be to use a file name fuzzy matching algorithm to determine whether the current difference SQL path belongs to the change SQL path (i.e., whether there is a corresponding code change).

[0101] At this point, for test cases where the SQL has changed (successful matching, change interface exists), corresponding to the high-risk scenario of "SQL syntax differences + actual code changes," the first subset of test cases output, sheet2, can contain the corresponding change interface information, test category (which may contain several test points), and the changed SQL path (i.e., the corresponding...). Figure 4 The test class lists the triples of relational SQL changes and can mark the subset as requiring key verification.

[0102] When it is detected that the SQL has not changed (match failed, no corresponding change interface), it can enter the second-level compatibility judgment. At this time, "whether it is fully compatible" can be used as the judgment node. That is, the generating device can be classified in a second way based on the compatibility label. Specifically, it is determined whether its compatibility level is "fully compatible" based on the compatibility label of the different SQL path.

[0103] The second subset of test cases, Sheet3, which corresponds to incomplete compatibility (conditional compatibility / complete incompatibility), can correspond to the pending confirmation scenario of "SQL syntax differences + code unchanged this time." In other words, this application can mark cases where SQL differs but the code remains unchanged as pending confirmation, so that testers and developers can confirm whether processing is necessary before conducting targeted testing. Sheet3 can specifically include a dictionary structure of test categories, differing SQL paths, and matching keywords.

[0104] The third test case subset, sheet 4, corresponding to the fully compatible compatibility label, represents a low-risk scenario of "fully compatible syntax + no code changes in this application." In this case, for SQL-independent scenarios, only high-risk modules need to be sampled for verification, and therefore it can be marked as selected for coverage. It may contain the differing SQL paths, matching keywords, and test points for fully compatible items.

[0105] Furthermore, the generation device can also filter corresponding supplementary checkpoints from public difference assets based on the migration type to fill the coverage blind spots of automated scanning. At this point, the corresponding target data change type can be obtained first, and then supplementary checkpoints that do not support static code analysis can be obtained from the preset database difference documents. Specifically, for difference items such as database configuration, user permissions, and character sets that cannot be identified through code scanning, a fourth test case subset, sheet5, is obtained, summarizing the test items that the automated tool cannot scan. The test cases corresponding to the items that the tool does not support scanning in sheet5 can be marked as requiring manual verification, ensuring the completeness of test coverage from a mechanism perspective.

[0106] Finally, the generated device can combine sheets 1-5 into a test case file, and organize the categorized test cases according to business dimensions. For example... Figure 4As shown, Sheet2 can be imported into the decision table to generate project-level test cases. At this point, focusing on the key verification cases in Sheet2, project-level test cases can be generated according to the decision table template format of the test management platform, covering all verification requirements of the changed business. Then, test cases for all test categories associated with the change are imported into the function, and organized by business function / interface dimension, ensuring complete coverage of the key test points within the scope of the change's impact, corresponding to the implementation of the first subset of test cases.

[0107] In addition, the test categories corresponding to sheets 3 to 5 can also be introduced into the function items. As long as the coverage verification at the category level is ensured, the application of the second to fourth test case subsets can be realized.

[0108] It should be noted that the above examples are only for understanding this application and do not constitute a limitation on the database migration test case generation method of this application. Any simple modifications based on this technical concept are within the protection scope of this application.

[0109] This application also provides a database migration test case generation device; please refer to... Figure 5 , Figure 5 This is a schematic diagram of the module structure of the database migration test case generation device according to an embodiment of this application. In this embodiment, the database migration test case generation device includes: The first scanning module T1 is used to obtain the difference SQL path in the code file of the source database to be migrated to the target database, which corresponds to the syntax difference rules between the source database and the target database, and the test points corresponding to the difference SQL path; The second scanning module T2 is used to perform static change analysis on the code file to obtain the changed SQL path and the change interface information associated with the changed SQL path; The scope analysis module T3 is used to associate and fuse the test points and the changed interface information based on the path matching relationship between the difference SQL path and the change SQL path, and generate association relationship data to indicate the test scope. The case generation module T4 is used to generate test case files for database migration testing by calling an artificial intelligence model based on the relationship data.

[0110] The database migration test case generation apparatus provided in this application, employing the database migration test case generation method in the above embodiments, can solve the technical problem of database migration test case generation. Compared with the prior art, the beneficial effects of the database migration test case generation apparatus provided in this application are the same as those of the database migration test case generation method provided in the above embodiments, and other technical features in the database migration test case generation apparatus are the same as those disclosed in the methods of the above embodiments, and will not be repeated here.

[0111] This application provides a database migration test case generation device, which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to execute the database migration test case generation method in Embodiment 1 above.

[0112] The following is for reference. Figure 6 The diagram illustrates a structural schematic of a database migration test case generation device suitable for implementing embodiments of this application. The database migration test case generation device in embodiments of this application may include, but is not limited to, mobile terminals such as mobile phones, laptops, digital broadcast receivers, PDAs (Personal Digital Assistants), PADs (Portable Application Description), PMPs (Portable Media Players), in-vehicle terminals (e.g., in-vehicle navigation terminals), and fixed terminals such as digital TVs and desktop computers. Figure 6 The database migration test case generation device shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0113] like Figure 6As shown, the database migration test case generation device may include a processing unit 1001 (e.g., a central processing unit, a graphics processing unit, etc.) that can perform various appropriate actions and processes according to a program stored in read-only memory (ROM) 1002 or a program loaded from storage device 1003 into random access memory (RAM) 1004. The RAM 1004 also stores various programs and data required for the operation of the database migration test case generation device. The processing unit 1001, ROM 1002, and RAM 1004 are interconnected via a bus 1005. An input / output interface 1006 is also connected to the bus. Typically, the following systems can be connected to the input / output interface 1006: input devices 1007 including, for example, touchscreens, touchpads, keyboards, mice, image sensors, microphones, accelerometers, gyroscopes, etc.; output devices 1008 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 1003 including, for example, magnetic tapes, hard disks, etc.; and communication devices 1009. Communication device 1009 allows the database migration test case generation device to communicate wirelessly or wiredly with other devices to exchange data. While the figure shows a database migration test case generation device with various systems, it should be understood that implementation or possession of all the systems shown is not required. More or fewer systems may be implemented alternatively.

[0114] Specifically, according to the embodiments disclosed in this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, an embodiment disclosed in this application includes a database migration test case generation program product, which includes a database migration test case generation program carried on a computer-readable medium, the database migration test case generation program containing program code for performing the methods shown in the flowcharts. In such an embodiment, the database migration test case generation program can be downloaded and installed from a network via a communication device, or installed from storage device 1003, or installed from read-only memory 1002. When the database migration test case generation program is executed by processing device 1001, it performs the functions defined in the methods of the embodiments disclosed in this application.

[0115] The database migration test case generation device provided in this application, employing the database migration test case generation method in the above embodiments, can solve the technical problem of database migration test case generation. Compared with the prior art, the beneficial effects of the database migration test case generation device provided in this application are the same as those of the database migration test case generation method provided in the above embodiments, and other technical features in this database migration test case generation device are the same as those disclosed in the method of the previous embodiment, and will not be repeated here.

[0116] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any suitable manner in one or more embodiments or examples.

[0117] The above are merely specific embodiments of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0118] This application provides a storage medium having computer-readable program instructions (i.e., a database migration test case generation program) stored thereon, which are used to execute the database migration test case generation method in the above embodiments.

[0119] The storage medium provided in this application may be, for example, a USB flash drive, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices, or any combination thereof. More specific examples of the storage medium may include, but are not limited to: electrical connections with one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this embodiment, the storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, system, or device. The program code contained on the storage medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, RF (Radio Frequency), etc., or any suitable combination thereof.

[0120] The aforementioned storage medium may be included in the database migration test case generation device; or it may exist independently and not be assembled into the database migration test case generation device.

[0121] The aforementioned storage medium carries one or more programs. When the aforementioned one or more programs are executed by the database migration test case generation device, the database migration test case generation device becomes: database migration test case generation.

[0122] Database migration test case generation program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof. These programming languages ​​include object-oriented programming languages—such as Java, Smalltalk, and C++—as well as conventional procedural programming languages—such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a Local Area Network (LAN) or a Wide Area Network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0123] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of system, method, and database migration test case generation program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the blocks may occur in a different order than those shown in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0124] The modules described in the embodiments of this application can be implemented in software or hardware. The names of the modules do not necessarily limit the functionality of the unit itself.

[0125] The readable storage medium provided in this application is a storage medium that stores computer-readable program instructions (i.e., a database migration test case generation program) for executing the above-described database migration test case generation method, and can solve the technical problem of database migration test case generation. Compared with the prior art, the beneficial effects of the storage medium provided in this application are the same as the beneficial effects of the database migration test case generation method provided in the above embodiments, and will not be repeated here.

[0126] The above are only some embodiments of this application and do not limit the scope of the solution of this application. All equivalent structural transformations made under the technical concept of this application and using the content of this application specification and drawings, or direct / indirect applications in other related technical fields, are included within the protection scope of this application.

Claims

1. A database migration testing method, characterized in that, The method includes: Obtain the difference SQL paths in the code files of the source database to be migrated to the target database, which correspond to the syntax difference rules between the source database and the target database, as well as the test points corresponding to the difference SQL paths; Perform static change analysis on the code file to obtain the change SQL path and the change interface information associated with the change SQL path; Based on the path matching relationship between the difference SQL path and the change SQL path, the test points and the change interface information are associated and fused to generate association relationship data for indicating the test scope; Based on the aforementioned relationship data, an artificial intelligence model is invoked to generate test case files for database migration testing.

2. The method as described in claim 1, characterized in that, The step of obtaining the difference SQL path in the code file of the source database to be migrated to the target database, corresponding to the syntax difference rules between the source database and the target database, and the test points corresponding to the difference SQL path, includes: Obtain difference keywords that represent the syntactic difference rules between the source database and the target database from a pre-built database difference rule library; Based on the preset pipeline label information, locate the SQL mapping file in the code file of the source database, and scan the SQL mapping file line by line to determine the difference SQL path containing the difference keyword, and the matching keyword corresponding to the difference SQL path; Based on the matching keywords, the test points corresponding to the differential SQL paths are obtained from the database differential rule base.

3. The method as described in claim 2, characterized in that, The step of performing static change analysis on the code file to obtain the change SQL path and the change interface information associated with the change SQL path includes: Identify the SQL statements that have undergone code changes based on the SQL execution logic of the code file, and determine the changed SQL path; By analyzing and tracing the call chain of the changed SQL path through abstract syntax tree, the change business interface associated with the changed SQL path is determined, and the change interface information associated with the changed SQL path is obtained.

4. The method as described in claim 3, characterized in that, The step of generating test case files for database migration testing by calling an artificial intelligence model based on the association data includes: Based on the matching keywords, the target difference type is obtained from the database difference rule base; The target difference type and the test points in the correlation data are input into the artificial intelligence model to generate initial test cases, which include verification points and expected results. The initial test cases are iteratively optimized until the real-time test cases output by the artificial intelligence model meet the preset output conditions, thus obtaining a full set of test cases; Based on the change interface information in the associated data, all test cases are categorized and organized to generate test case files.

5. The method as described in claim 4, characterized in that, The step of classifying and organizing all test cases according to the change interface information in the association data and generating test case files includes: Based on the matching keywords, the target compatible syntax is obtained from the database difference rule base; The compatibility tag of the SQL path corresponding to the matching keyword is determined based on the target compatible syntax and the syntax type of the target database; Based on the changed interface information and compatibility tags in the association data, the full set of test cases are categorized to generate test case files.

6. The method as described in claim 5, characterized in that, The compatibility tags include fully compatible, conditionally compatible, and completely incompatible; the test case file includes all test cases and at least one subset of the first to third test cases. The step of classifying the full set of test cases according to the change interface information and the compatibility tags in the association data, and generating test case files, includes: The test cases containing the changed interface information in the full set of test cases are summarized into a first subset of test cases; The test cases in the full set of test cases that do not contain the changed interface information and whose compatibility type label is not the fully compatible SQL path are summarized into a second test case subset; The test cases that do not contain the changed interface information and whose compatibility type label is the fully compatible SQL path are summarized into the third test case subset.

7. The method as described in claim 6, characterized in that, The test case file also includes a fourth subset of test cases; after iteratively optimizing the initial test cases until the real-time test cases output by the artificial intelligence model meet the preset output conditions and all test cases are obtained, the process further includes: Obtain the target data change type; Based on the target data change type, obtain supplementary check items from the preset database difference document that do not support the static code analysis; Based on the test points corresponding to the supplementary check items, a fourth subset of test cases is selected from the full set of test cases.

8. A database migration test case generation device, characterized in that, The device includes: The first scanning module is used to obtain the difference SQL path in the code file of the source database to be migrated to the target database, which corresponds to the syntax difference rules between the source database and the target database, and the test points corresponding to the difference SQL path; The second scanning module is used to perform static change analysis on the code file to obtain the changed SQL path and the change interface information associated with the changed SQL path; The scope analysis module is used to associate and fuse the test points and the changed interface information based on the path matching relationship between the difference SQL path and the change SQL path, and generate association relationship data to indicate the test scope. The test case generation module is used to generate test case files for database migration testing by calling an artificial intelligence model based on the relationship data.

9. A database migration test case generation device, characterized in that, The device includes: a memory, a processor, and a database migration test case generation program stored on the memory and executable on the processor, the database migration test case generation program being configured to implement the steps of the database migration test case generation method as described in any one of claims 1 to 7.

10. A storage medium, characterized in that, The storage medium stores a database migration test case generation program, which, when executed by a processor, implements the steps of the database migration test case generation method as described in any one of claims 1 to 7.

Images