A multiple-shot alignment test method, device, electronic equipment and program product

Abstract

The application provides a multi-release comparison test method and device, electronic equipment and program product, realizes accurate, light and efficient multi-heterogeneous database adaptation test. The application layer storage process is analyzed to generate unified execution logic, and independent test transactions are created for each target database. The business logic is executed in the transaction to avoid fragmentation bias, cooperate with result comparison analysis, and ensure test accuracy and abnormal recognition accuracy. Based on the multi-source data configuration and the storage process analysis result, the core resources are preloaded to the shared memory. The application layer only needs to maintain a set of business logic, and does not need to adapt the version of multiple databases separately, thereby reducing repeated analysis and disk IO, and significantly reducing resource occupation and deployment cost. The storage process identifier and the data source name are matched with the multi-database connection configuration, the sub-thread is configured according to the number of databases, and the concurrent execution is performed. The test script does not need to be manually written, and the batch comparison can be initiated by simple configuration, thereby greatly shortening the test period and effectively improving the adaptation development and execution efficiency.

Description

Technical Field

[0001] This application relates to the field of database testing technology, and more specifically, to a multi-comparison testing method, apparatus, electronic device, and program product. Background Technology

[0002] For database testing, especially for multi-database testing and comparison techniques targeting heterogeneous databases, existing multi-database testing solutions mainly fall into two categories: one is to add a Java Database Connectivity (JDBC) proxy layer between the application layer and the database to forward SQL fragments through multiple paths and compare the results; the other is to implement multi-path forwarding through a business gateway, which requires the deployment of multiple application layer services. Both solutions are used to address the adaptation testing needs of multiple heterogeneous databases.

[0003] The above solutions have obvious drawbacks: the JDBC proxy layer only forwards isolated SQL fragments and lacks transaction context, which leads to result deviations due to differences in isolation between different databases and affects the accuracy of testing; the gateway solution requires the deployment of multiple application layer services, resulting in resource waste and inefficiency in adapting to multilingual domestic databases. Summary of the Invention

[0004] The purpose of this application is to provide a method, apparatus, electronic device and program product for multiple comparison testing, which can reduce the implementation cost of multiple comparison and improve the accuracy of comparison results.

[0005] To achieve the above objectives, the technical solutions adopted in the embodiments of this application are as follows:

[0006] In a first aspect, embodiments of this application provide a multi-shot comparison test method, including:

[0007] Based on the multi-source data configuration, database connection layer resources are stored in shared memory; the database connection layer resources include the correspondence between data source names and multiple database connection configurations;

[0008] The application layer stored procedure is parsed, and the business execution layer resources are stored in the shared memory; the business execution layer resources include stored procedure instances and logical execution trees; the database connection layer resources and the business execution layer resources are mapped through the data source name;

[0009] When a comparison test is triggered, the corresponding target data source name is determined based on the stored procedure of the source test target;

[0010] At least one target database connection configuration is determined in the shared memory based on the target data source name;

[0011] Create a corresponding test transaction for each target database, and execute the target logic execution tree corresponding to the source test target in the corresponding test transaction;

[0012] Obtain the execution results returned by each target database and perform comparative analysis.

[0013] Secondly, embodiments of this application provide a multi-shot comparison testing device, comprising:

[0014] The startup configuration component is used to store database connection layer resources in shared memory based on multi-source data configuration; the database connection layer resources include the correspondence between data source names and multiple database connection configurations; the application layer stored procedure is parsed and the business execution layer resources are stored in the shared memory; the business execution layer resources include stored procedure instances and logical execution trees; the database connection layer resources and the business execution layer resources are mapped through the data source names;

[0015] The comparison module is used to determine the corresponding target data source name based on the stored procedure of the source test target when a comparison test is triggered; determine at least one target database connection configuration in the shared memory according to the target data source name; create a corresponding test transaction for each target database, and execute the target logic execution tree corresponding to the source test target in the corresponding test transaction; obtain the execution results fed back by each target database, and perform comparison analysis.

[0016] Thirdly, embodiments of this application provide an electronic device, including:

[0017] Memory, used to store one or more programs;

[0018] processor;

[0019] When the one or more programs are executed by the processor, the method as described in any one of the first aspects above is implemented.

[0020] Fourthly, embodiments of this application provide a program product that, when executed by a processor, implements the method as described in any one of the first aspects above.

[0021] Compared to existing technologies, the multi-database comparison testing method, apparatus, electronic device, and program product provided in this application achieves accurate, lightweight, and efficient multi-heterogeneous database adaptation testing. It parses application-layer stored procedures to generate unified execution logic, creating independent test transactions for each target database. Business logic is executed within each transaction, avoiding fragmentation bias. Combined with result comparison analysis, this ensures test accuracy and precise anomaly identification. Based on multi-source data configuration and stored procedure parsing results, core resources are preloaded into shared memory. The application layer only needs to maintain one set of business logic, eliminating the need for separate adaptation versions for multiple databases, reducing redundant parsing and disk I / O, and significantly lowering resource consumption and deployment costs. It quickly matches multi-database connection configurations through stored procedure identifiers and data source names, configuring sub-threads for concurrent execution based on the number of databases. No manual test script writing is required; simple configuration initiates batch comparisons, significantly shortening the testing cycle and effectively improving adaptation development and execution efficiency.

[0022] To make the above-mentioned objectives, features and advantages of this application more apparent and understandable, preferred embodiments are described below in detail with reference to the accompanying drawings. Attached Figure Description

[0023] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0024] Figure 1 This is a schematic diagram of the architecture for performing multi-comparison tests using a JDBC proxy layer in existing technologies.

[0025] Figure 2 This is a schematic diagram of the architecture for performing multi-match testing using a multi-match gateway in existing technologies;

[0026] Figure 3 A schematic diagram of a multi-shot comparison testing device provided by the present invention;

[0027] Figure 4 This is a schematic diagram of a multi-shot comparison test method provided in an embodiment of the present invention;

[0028] Figure 5 This is a schematic diagram of another multi-shot comparison test method provided in an embodiment of the present invention;

[0029] Figure 6 This is a schematic diagram of another multi-shot comparison test method provided in an embodiment of the present invention;

[0030] Figure 7A schematic diagram of another multi-shot comparison test device provided by the present invention;

[0031] Figure 8 This is a schematic diagram of another multi-shot comparison test method provided in an embodiment of the present invention;

[0032] Figure 9 This is a schematic diagram of another multi-shot comparison test method provided in an embodiment of the present invention;

[0033] Figure 10 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present invention. Detailed Implementation

[0034] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. The components of the embodiments of this application described and shown in the accompanying drawings can generally be arranged and designed in various different configurations.

[0035] Therefore, the following detailed description of the embodiments of this application provided in the accompanying drawings is not intended to limit the scope of the claimed application, but merely to illustrate selected embodiments of the application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without inventive effort are within the scope of protection of this application.

[0036] It should be noted that similar reference numerals and letters in the following figures indicate similar items; therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures. Furthermore, in the description of this application, terms such as "first," "second," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0037] It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0038] In existing technologies, one approach to achieve multi-test comparison against databases of different language families is to utilize a JDBC proxy layer to execute the test process. Specifically, Figure 1 See the diagram below for an existing architecture that utilizes a JDBC proxy layer to perform multi-shot comparison tests. Figure 1 The architecture includes: application layer services, JDBC proxy / gateway, and multiple language-specific databases to be tested (such as...). Figure 1 The databases shown include Oracle, MySQL, and PostgreSQL databases, as well as a comparison service.

[0039] Users transmit SQL statements used for comparison tests to the JDBC proxy / gateway through application-layer services. Optionally, although multiple SQL statements can belong to a single test transaction, in this architecture, fragmented SQL statements are sent to multiple databases under test, without considering the context of the test transaction. Since each database under test only executes the SQL statements to obtain corresponding test results, if anomalies occur during the comparison of these results, the anomalies may stem from the intended issues identified by the comparison test, or from anomalies caused by a lack of context. Clearly, this type of comparison significantly reduces the accuracy of anomaly identification.

[0040] For example, sending query SQL statements to multiple databases under test, but in the context, these query SQL statements are preceded by an INSERT type SQL statement that inserts data into table A. Figure 1 In the architecture shown, fragmented sending of query SQL statements without context can cause the database under test to fail to retrieve table A based on the given SQL statement, resulting in abnormal test results. This abnormality is not the situation the comparison test itself intends to identify.

[0041] In another implementation, test SQL statements can be forwarded in multiple ways based on a multi-comparison gateway. Specifically, Figure 2 This is a schematic diagram of the architecture for performing multi-match testing using a multi-match gateway in existing technology. See [link / reference] Figure 2 The architecture includes: a multi-comparison gateway, application-layer services that match the database to be tested, and multiple language-based databases to be tested (such as...). Figure 2 The databases shown include Oracle, MySQL, and PostgreSQL databases, as well as a comparison service.

[0042] In this architecture, multiple application-layer services need to be deployed, such as Figure 2 As shown, application layer service 1 corresponds to Oracle databases, application layer service 2 corresponds to MySQL databases, and application layer service 3 corresponds to PG databases.

[0043] However, this architecture leads to a waste of application layer service resources.

[0044] Addressing the issues of low testing efficiency, inconsistent execution environments, difficulty in identifying adaptation anomalies, and chaotic resource scheduling in multi-database testing environments in existing technologies, this application provides a multi-stage comparison testing mechanism. The core idea is to constrain the comparison test within test transactions through a lightweight application layer. This avoids the resource waste of setting corresponding application layers for different databases, while also preventing the impact of fragmented SQL statements on the accuracy of the comparison test.

[0045] Optionally, Figure 3 This is a schematic diagram of a multi-shot comparison testing device provided by the present invention. See also: Figure 3 The multi-shot comparison test device 10 includes: a startup configuration component 101, a shared memory 102, and a comparison module 103.

[0046] The startup configuration component 101 is used to load multi-source data configuration. Optionally, this multi-source data configuration is used to uniformly manage the connection attribute information of various heterogeneous databases under different information technology innovation systems. Through preset naming rules, it defines a standard data source name for the data source of each business scenario, thereby establishing a one-to-one or one-to-many mapping relationship between the data source name and the database connection configuration (DataSource). This then constructs the database connection layer resources.

[0047] Optionally, the startup configuration component 101 stores business execution layer resources in shared memory by parsing application-layer stored procedures. These business execution layer resources represent the core execution class resource set stored in shared memory after the application-layer stored procedures have been structured and parsed. They are the key carrier connecting application-layer business logic with multi-database test execution, providing a standardized and executable business logic benchmark for batch comparison testing of stored procedures under multiple heterogeneous databases.

[0048] Optionally, the business execution layer resource includes stored procedure instances and a logical execution tree. Furthermore, the database connection layer resource and the business execution layer resource are mapped using the data source name.

[0049] Optionally, in order to improve the efficiency of resource retrieval and data consistency of the execution mechanism of this application, the aforementioned database connection layer resources and business execution layer resources can be stored in shared memory 102 for subsequent comparative testing.

[0050] See Figure 3 The comparison module 103 includes a running component 103-1 and a comparison component 103-2.

[0051] Among them, the running component 103-1 is used to determine the corresponding target data source name based on the stored procedure of the source test target when the comparison test is triggered by the front end; determine at least one target database connection configuration in shared memory according to the target data source name; create a corresponding test transaction for each target database, and execute the target logic execution tree corresponding to the source test target in the corresponding test transaction.

[0052] The comparison component 103-2 is used to obtain the execution results returned by each target database, perform comparison analysis, and feed the comparison results back to the front end.

[0053] Optionally, based on the above architecture, please provide a possible implementation of the multi-shot comparison testing method. Specifically, Figure 4 This is a schematic diagram of a multi-shot comparison test method provided in an embodiment of the present invention. See also: Figure 4 The method includes:

[0054] Step 200: Based on the multi-source data configuration, store the database connection layer resources in shared memory.

[0055] Step 201: Parse the application layer stored procedure and store the business execution layer resources in shared memory.

[0056] Step 202: When the comparison test is triggered, determine the corresponding target data source name based on the stored procedure of the source test target.

[0057] Step 203: Determine at least one target database connection configuration in shared memory based on the target data source name.

[0058] Step 204: Create a corresponding test transaction for each target database, and execute the target logic execution tree corresponding to the source test target in the corresponding test transaction.

[0059] Step 205: Obtain the execution results returned by each target database and perform comparative analysis.

[0060] The multi-database comparison testing method provided in this invention achieves accuracy, lightweightness, and efficiency in multi-heterogeneous database adaptation testing. It parses application-layer stored procedures to generate unified execution logic, creating independent test transactions for each target database. Business logic execution is confined within transaction boundaries, avoiding fragmented execution bias. Combined with comparative analysis of execution results, it ensures testing accuracy and precise anomaly identification. Based on multi-source data configuration and the parsing results of application-layer stored procedures, core resources are preloaded into shared memory. The application layer only needs to maintain one set of business logic, eliminating the need to develop separate adaptation versions for different databases. This reduces redundant parsing and disk I / O operations, significantly lowering system resource consumption and deployment costs. By quickly matching multi-database connection configurations through stored procedure identifiers and data source names, and configuring sub-threads for concurrent execution based on the number of databases, it eliminates the need for manually writing test scripts. Simple configuration is all that's required to initiate multi-database batch comparisons, significantly shortening the testing cycle and effectively improving adaptation development and execution efficiency.

[0061] Optionally, to standardize and structure the data of application-layer stored procedures so that it resides in shared memory, a possible implementation is provided below. Specifically, in Figure 4 On this basis, Figure 5 A schematic diagram of another multi-shot comparison test method provided in an embodiment of the present invention is shown below. Figure 5 Step 201 includes:

[0062] Step 201-1: Parse the application layer stored procedure to obtain the application layer stored procedure identifier, all SQL statements, and the identifier of each SQL statement.

[0063] Step 201-2: Construct a logical execution tree based on all SQL statements and the identifier of each SQL statement.

[0064] Step 201-3: Construct a stored procedure instance based on the application layer stored procedure identifier, data source name, and logical execution tree.

[0065] Alternatively, for application-layer stored procedures, it can be a PL / XML configured in the application-layer project, as shown in the following example:

[0066] <transform id="p_unique id" datasource="hspbs">

[0067] <desc><![CDATA[ Application layer PL / Xml stored procedure ]]>< / desc>

[0068] <param id="userId" dataType="string" value="#{userId}" desc="入参:用户id">

[0069] <param id="age" dataType="int" value="#{age}" default="18" desc="入参:用户年龄">

[0070] <!--Return logic control-->

[0071] <if test="userId == null">

[0072] <return mode="exception" message="入参age不能为空!" / >

[0073] < / if>

[0074] <!--Query SQL statement block-->

[0075] <selectsql id="selectUserCount">

[0076] select count(1)as "COUNT" from USER where USER_ID = #{userId}

[0077] < / selectsql>

[0078] <!--Logic control statement block-->

[0079] <if test="selectUserCount.COUNT lte 0 ">

[0080] <updatesql id="updateUser">

[0081] update USER set AGE = #{age} where USER_ID = #{userId}

[0082] < / updatesql>

[0083] < / if>

[0084] <selectlistsql id="selectUserList">

[0085] select user_id as "userId" from USER limit 10

[0086] < / selectlistsql>

[0087] <!--Cursor statement block -->

[0088] <cursor list="selectUserList" item="myItem" index="myIndex">

[0089] <param id="userId" dataType="string" value="#{myItem.userId}">

[0090] <updatesql id="updateUser2">

[0091] update USER set AGE = #{age} where USER_ID = #{userId}

[0092] < / updatesql>

[0093] < / cursor> [[ID=三十六]]

[0094] < / transform>

[0095] Perform a parsing operation on the above PL / Xml script:

[0096] Extract core identifiers and content: Obtain the unique identifier p_unique id of the application layer stored procedure, all SQL statements in the script (such as the query statement corresponding to selectUserCount, the update statement corresponding to updateUser, etc.), and the unique identifier of each SQL statement (selectUserCount, updateUser, selectUserList, updateUser2); Construct a logical execution tree: Based on the execution dependencies and flow control of SQL statements (such as throwing an exception when userId == null, executing updateUser when selectUserCount.COUNT ≤ 0, and executing updateUser2 in a loop driven by the query result of selectUserList), construct a logical execution tree with a fixed execution order and logical relationship; Construct a stored procedure instance: Combine the extracted stored procedure identifier p_unique id, the data source name hspbs bound to the script, and the above logical execution tree to generate a stored procedure instance; Finally, store the "stored procedure instance and logical execution tree" as business execution layer resources in shared memory, and establish a mapping relationship with the database connection layer resources stored in step 200 through the data source name hspbs.

[0097] Optionally, relying on the application-layer stored procedure identifier passed in from the front end, the corresponding business execution layer resources are accurately retrieved from shared memory, and the target data source name bound therein is extracted. The core purpose is to provide an accurate data source benchmark for subsequent matching of multi-database connection configurations, ensuring precise connection between test triggering and multi-source database adaptation, avoiding data source matching errors due to identifier confusion, and supporting the orderly conduct of batch comparison tests of multiple heterogeneous databases. Specifically, in Figure 4 On this basis, Figure 6 A schematic diagram of another multi-shot comparison test method provided in an embodiment of the present invention is shown below. Figure 6 Step 202 includes:

[0098] Step 202-1: Receive the target application layer stored procedure identifier corresponding to the source test target input from the front end.

[0099] Step 202-2: Based on the target application layer stored procedure identifier, determine the corresponding target business execution layer resource in shared memory.

[0100] Step 202-3: Extract the target data source name contained in the target business execution layer resources.

[0101] Optionally, for comparison testing of multiple target databases, corresponding sub-threads are configured according to the number of databases and their respective connection configurations are bound. An independent test transaction is created for each database, and SQL statements in the logical execution tree are executed in a unified order within the transaction boundaries. The core is to achieve asynchronous parallel execution of multiple databases, using transactions to ensure the consistency and isolation of the execution environment of each database, ensuring unified execution logic, and providing real and comparable intra-transaction execution data for subsequent result comparison, thereby improving testing efficiency and result accuracy. Specifically, in Figure 3 On this basis, Figure 7 See the schematic diagram of another multi-shot comparison test device provided by the present invention. Figure 7 In the multi-shot comparison test device 10, the running component 103-1 includes a thread pool 103-11.

[0102] The thread pool 103-11 is used to provide sub-threads for each database under test, for deploying the corresponding test transactions.

[0103] Optionally, based on Figure 7 The multi-shot comparison test device shown is in Figure 4 On this basis, Figure 8 A schematic diagram of another multi-shot comparison test method provided in an embodiment of the present invention is shown below. Figure 8 Step 202 includes:

[0104] Step 202-1: Configure the corresponding number of child threads based on the total number of target databases.

[0105] Each sub-thread is matched with the corresponding target database connection configuration.

[0106] Step 202-2: Create test transactions for the corresponding target database connection configuration through each sub-thread.

[0107] Step 202-3: Each sub-thread, within its corresponding test transaction, calls the target logic execution tree corresponding to the source test target.

[0108] Step 202-4: Each sub-thread executes the SQL statement corresponding to the SQL statement identifier according to the execution order of the target logic execution tree.

[0109] Optionally, see [link to relevant documentation] Figure 7This shared memory, besides maintaining database connection layer resources and business execution layer resources, can also be used to maintain a context mapping table. Optionally, in one possible implementation, all SQL execution results within the test transactions of each target database are stored in the context mapping table. The anomaly type is determined hierarchically by result status: if any SQL execution fails, a compatibility anomaly is confirmed; if all executions succeed but the results are inconsistent, a comparison anomaly is confirmed. The core is to accurately identify adaptation anomalies in application-layer stored procedures under multiple heterogeneous databases, providing clear anomaly judgment criteria for multi-source database comparison testing, and ensuring the effective discovery of compatibility and result consistency issues. Specifically, in Figure 8 On this basis, Figure 9 A schematic diagram of another multi-shot comparison test method provided in an embodiment of the present invention is shown below. Figure 9 Step 205 includes:

[0110] Step 205-1: Store the execution results of all SQL statements within the same test transaction in the context mapping table as the execution results returned by the corresponding target database.

[0111] Step 205-2: When any SQL statement in the execution result indicates that the corresponding execution result has failed, confirm that the target database corresponding to the execution result has a compatibility anomaly.

[0112] Step 205-3: When all execution results are successful but inconsistencies exist, confirm that a comparison anomaly has occurred.

[0113] Optionally, through a hierarchical logic of "basic compatibility screening and in-depth result consistency verification," adaptation anomalies of different priorities and causes can be accurately distinguished. This ensures that no essential adaptation problems are overlooked, while also efficiently discovering hidden database characteristic differences. This provides a clear problem-oriented approach for multi-source database adaptation optimization, comprehensively improving the targeting and completeness of multi-heterogeneous database comparison testing. Specifically, the aforementioned "compatibility anomalies" can be classified as primary anomalies, and "comparison anomalies" as secondary anomalies, constructing a secondary anomaly identification mechanism for the comparison structure.

[0114] Specifically, the first level of anomalies is compatibility anomalies, which focus on basic adaptation obstacles and ensure the feasibility of testing.

[0115] The first level of exception addresses scenarios where differences in the basic syntax and database object support of SQL statements in application-layer stored procedures across multiple heterogeneous databases lead to SQL execution failures. Its core judgment logic is: when any SQL statement in the logical execution tree within the target database's test transaction results in "failure," it is directly judged as a compatibility exception.

[0116] For example, taking the data source name "hspbs" as an example, which is associated with three architecture types: distributed relational database, standalone relational database, and cloud-native database, the application layer PL / Xml stored procedure contains the SQL statement "select 1 from dual" (SQL identifier: selectDual). During execution, standalone relational databases and cloud-native databases support the dual table syntax and can execute normally and return results; however, some distributed relational databases do not adapt to the dual table, a common database object, causing the SQL statement to fail. In this case, the system directly determines that the distributed relational database has a first-level compatibility anomaly.

[0117] The core effect of this anomaly is to quickly locate the basic adaptation obstacles that prevent "execution". These anomalies are intuitive and easy to find, and they directly affect the conduct of subsequent tests. Therefore, they are marked as core anomalies that must be resolved first, ensuring the basic feasibility of multi-source comparison tests from the source and avoiding test invalidation due to basic adaptation issues.

[0118] Specifically, the second level of anomalies is the comparison anomaly, which focuses on the differences in results after successful execution and uncovers deep-seated adaptation issues.

[0119] Level 2 exceptions address scenarios where SQL statements execute successfully across all target databases, but the results are inconsistent. These exceptions are highly hidden and require precise comparison of results from multiple databases to detect. Their core function is to uncover deep-seated adaptation issues where "execution is successful but the results are poor." Specifically, they are divided into two sub-categories:

[0120] Optionally, this type of exception is for scenarios where the underlying business data of each target database is inconsistent, resulting in differences in the execution results of the same SQL. The judgment logic is as follows: all target database SQLs are executed successfully, but the number of rows changed by DML statements and the query result sets of DQL statements are inconsistent, and the cause can be traced back to differences in database table data.

[0121] For example, an application-layer PL / XML stored procedure containing the SQL statement "delete from USER where USER_ID = #{userId}" (SQL identifier: deleteUser) executes successfully in three architecture types: single-machine relational database (Type 1), single-machine relational database (Type 2), and open-source relational database. However, the number of changed rows returned is 1, 0, and 1 respectively. System tracing analysis reveals that the USER table in the single-machine relational database (Type 2) does not contain a user record corresponding to that userId, while the USER table in the other two architecture types does contain the record. This is determined to be a data inconsistency comparison anomaly.

[0122] The effect of this type of anomaly is that it accurately locates the adaptation interference factors at the "data level," clarifies that the cause of inconsistent test results is not a database architecture adaptation problem, but a lack of data synchronization, provides a basis for data standardization in the test environment, and avoids misjudging adaptation problems.

[0123] Optionally, this type of exception addresses scenarios where the inherent characteristics of different database architectures (such as function processing rules and syntax compatibility details) lead to inconsistent results despite successful SQL execution. The judgment logic is as follows: the inconsistency in results for all target database SQL executions is attributed to the characteristics of the database architecture itself, rather than data differences.

[0124] For example, an application-layer PL / XML stored procedure containing the string concatenation SQL statement "select CONCAT('user_', #{userId}) as userName" (SQL identifier: concatUserName) executes successfully in three architecture types: cloud-native databases, NewSQL databases, and distributed relational databases. However, the returned results differ: in cloud-native databases, if userId is null, the CONCAT function returns null; in NewSQL databases, it returns "user_null" when userId is null; and in distributed relational databases, it returns "user_". This difference stems from the inherent characteristics of how different database architectures handle null values ​​in the CONCAT function, and the system identifies this as a database characteristic difference comparison anomaly.

[0125] The effect of this type of anomaly is that it effectively discovers "hidden adaptation problems" that are difficult to detect in traditional testing. These problems are easily overlooked because the SQL execution is successful, but they can lead to deviations in business logic results. Through the multi-event comparison of this mechanism, they can be accurately identified, providing a clear basis for cross-architecture adaptation optimization of SQL statements (such as function replacement and syntax compatibility processing).

[0126] In summary, the two-level anomaly detection mechanism of this application, through a layered logic of "basic compatibility first, then deep consistency," forms a comprehensive anomaly identification system covering "execution failure, execution success but data inconsistency, and execution success but feature differences." It can not only quickly identify the fundamental adaptation obstacles that must be addressed, ensuring test feasibility, but also accurately uncover hidden deep adaptation problems. This solves the pain points of incomplete anomaly identification and ambiguous cause localization in traditional multi-database testing, providing precise and layered problem guidance for the adaptation and optimization of multi-heterogeneous database architectures, and significantly improving the depth and effectiveness of multi-source database comparison testing.

[0127] The above example in this application, based on the structured parsing of application-layer PL / XML stored procedures, shared memory resource scheduling, and transactional execution mechanisms, achieves the triple core effects of "accuracy, lightweight, and efficiency" in multi-heterogeneous database adaptation testing:

[0128] 1) Accurate and controllable comparison results: SQL execution of all databases is limited to the boundaries of independent test transactions. Relying on a unified logical execution tree and a two-layer unique identification system, the results deviation caused by SQL fragmented execution is avoided. Combined with a two-level anomaly judgment mechanism, compatibility anomalies, data inconsistencies and database characteristic differences are accurately distinguished, and the causes of anomalies are clearly located.

[0129] 2) Lightweight and efficient architecture deployment: The application layer only needs to maintain one set of PL / Xml stored procedures and business logic, without the need to develop separate adaptation versions for different databases; by preloading core resources through shared memory, repeated parsing and disk I / O are avoided, which greatly reduces the system deployment and resource consumption costs.

[0130] 3) Improved test execution and development efficiency: Supports concurrent execution and automatic comparison of multiple heterogeneous databases through simple configuration, eliminating the need to manually write multi-database test scripts; multi-threaded asynchronous scheduling and shared memory fast retrieval mechanism significantly shorten the test startup and execution cycle, reducing the development and testing costs of adapting to multiple databases in the domestic IT innovation industry.

[0131] To achieve the steps and corresponding technical effects of the above examples, this application also provides a multi-shot comparison testing device, the implementation architecture of which is described above. Figure 3 and Figure 4 .

[0132] Specifically, the multi-shot comparison testing device provided in this application has the following functions:

[0133] Startup configuration component 101 is used to configure database connection layer resources in shared memory 102 based on multi-source data configuration; and to parse application layer stored procedures and store business execution layer resources in shared memory.

[0134] The comparison module 103 is used to determine the corresponding target data source name based on the stored procedure of the source test target when the comparison test is triggered; determine at least one target database connection configuration in shared memory according to the target data source name; create a corresponding test transaction for each target database and execute the target logic execution tree corresponding to the source test target in the corresponding test transaction; obtain the execution results fed back by each target database and perform comparison analysis.

[0135] Optionally, the configuration component 101 is started, specifically used for: parsing the application layer stored procedure to obtain the application layer stored procedure identifier, all SQL statements, and each SQL statement identifier; constructing a logical execution tree based on all SQL statements and each SQL statement identifier; and constructing a stored procedure instance based on the application layer stored procedure identifier, the data source name, and the logical execution tree.

[0136] Optionally, the comparison module 103 is specifically used to receive the target application layer stored procedure identifier corresponding to the source test target input from the front end; determine the corresponding target business execution layer resource in the shared memory 102 according to the target application layer stored procedure identifier; and extract the target data source name contained in the target business execution layer resource.

[0137] Optionally, the comparison module 103 also includes a thread pool 103-1.

[0138] Thread pool 103-1 is used to configure a corresponding number of child threads based on the total number of target databases; each child thread creates a test transaction for the corresponding target database connection configuration; within the corresponding test transaction, each child thread calls the target logic execution tree corresponding to the source test target; each child thread executes the SQL statement corresponding to the SQL statement identifier according to the execution order of the target logic execution tree.

[0139] Optionally, the comparison module 103 further includes: comparison component 103-2.

[0140] The comparison component 103-2 is used to store the execution results of all SQL statements within the same test transaction into the context mapping table as the execution results returned by the corresponding target database. When any SQL statement in the execution result indicates that the corresponding execution result has failed, it is confirmed that the target database corresponding to the execution result has a compatibility anomaly. When all execution results are executed successfully and there is inconsistency, it is confirmed that a comparison anomaly has occurred.

[0141] This invention also provides an electronic device that can execute all the steps of the examples described above to achieve the corresponding technical effects. Specifically, Figure 10 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present invention. See also: Figure 10 The electronic device 30 includes: a memory 301 and a processor 300;

[0142] Memory 301 is used to store one or more programs;

[0143] Processor 300;

[0144] When one or more programs are executed by a processor, the electronic device 30 can achieve the steps and corresponding technical effects when it performs the steps shown in the above-described method examples.

[0145] In the embodiments provided in this application, it should be understood that the disclosed apparatus and methods can also be implemented in other ways. The apparatus embodiments described above are merely illustrative. For example, the flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of apparatus, methods, and computer 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, which contains one or more executable instructions for implementing a 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 marked in the drawings. For example, two consecutive 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 a block diagram and / or flowchart, and combinations of blocks in block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or action, or using a combination of dedicated hardware and computer instructions.

[0146] In addition, the functional modules in the various embodiments of this application can be integrated together to form an independent part, or each module can exist independently, or two or more modules can be integrated to form an independent part.

[0147] If a function is implemented as a software module and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a program product. This program product is stored in a computer-readable storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as a USB flash drive, a portable hard drive, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk.

[0148] The above are merely preferred embodiments of this application and are not intended to limit this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application.

[0149] It will be apparent to those skilled in the art that this application is not limited to the details of the exemplary embodiments described above, and that this application can be implemented in other specific forms without departing from the spirit or essential characteristics of this application. Therefore, the embodiments should be considered exemplary and non-limiting in all respects, and the scope of this application is defined by the appended claims rather than the foregoing description. Thus, all variations falling within the meaning and scope of equivalents of the claims are intended to be included within this application. No reference numerals in the claims should be construed as limiting the scope of the claims.

Claims

1. A method for multiple comparison tests, characterized in that, include: Based on the multi-source data configuration, database connection layer resources are stored in shared memory; The database connection layer resources include the correspondence between data source names and multiple database connection configurations; Parse the application layer stored procedure to obtain the application layer stored procedure identifier, all SQL statements, and the identifier of each SQL statement corresponding to the application layer stored procedure. Construct a logical execution tree based on all the SQL statements and the identifier of each SQL statement; A stored procedure instance is constructed based on the application layer stored procedure identifier, the data source name, and the logical execution tree; When a comparison test is triggered, the corresponding target data source name is determined based on the stored procedure of the source test target; At least one target database connection configuration is determined in the shared memory based on the target data source name; Based on the total number of target databases, configure a corresponding number of sub-threads; wherein each sub-thread is configured to match the connection of a corresponding target database. Each of the sub-threads creates a test transaction for the corresponding target database connection configuration; Each of the sub-threads, within its corresponding test transaction, invokes the target logic execution tree corresponding to the source test target; Each of the sub-threads executes the SQL statement corresponding to the SQL statement identifier in the execution order of the target logic execution tree; Obtain the execution results returned by each target database and perform comparative analysis.

2. The method according to claim 1, characterized in that, The step of determining the corresponding target data source name based on the stored procedure of the source test target when the comparison test is triggered includes: Receive the target application layer stored procedure identifier corresponding to the source test target input from the front end; Based on the target application layer stored procedure identifier, determine the corresponding target business execution layer resource in the shared memory; Extract the name of the target data source contained in the target business execution layer resource.

3. The method according to claim 1, characterized in that, The step of obtaining the execution results returned by each of the target databases and performing comparative analysis includes: The execution results of all SQL statements within the same test transaction are stored in the context mapping table as the execution results returned by the target database. When any of the SQL statements in the execution results fail, it is confirmed that the target database corresponding to the execution result has a compatibility anomaly. If all the execution results are successful but inconsistencies exist, a comparison anomaly is confirmed.

4. A multi-shot comparison testing device, characterized in that, include: Startup configuration components are used to configure database connection layer resources in shared memory based on multi-source data configuration; The database connection layer resources include the correspondence between data source names and multiple database connection configurations; Parse the application layer stored procedure to obtain the application layer stored procedure identifier, all SQL statements, and the identifier of each SQL statement; A logical execution tree is constructed based on all SQL statements and the identifier of each SQL statement. Construct a stored procedure instance based on the application layer stored procedure identifier, data source name, and logical execution tree; The comparison module is used to determine the corresponding target data source name based on the stored procedure of the source test target when a comparison test is triggered; At least one target database connection configuration is determined in the shared memory based on the target data source name; a corresponding number of sub-threads are configured based on the total number of target databases; a test transaction is created for the corresponding target database connection configuration through each sub-thread; within the corresponding test transaction, each sub-thread calls the target logic execution tree corresponding to the source test target; Each sub-thread executes the SQL statement corresponding to the SQL statement identifier according to the execution order of the target logic execution tree; obtains the execution results fed back by each target database, and performs comparative analysis.

5. The apparatus according to claim 4, characterized in that, The comparison module is specifically used to receive the target application layer stored procedure identifier corresponding to the source test target input from the front end; and to determine the corresponding target business execution layer resource in the shared memory based on the target application layer stored procedure identifier. Extract the name of the target data source contained in the target business execution layer resource.

6. An electronic device, characterized in that, include: Memory, used to store one or more programs; processor; When the one or more programs are executed by the processor, the method as described in any one of claims 1-3 is implemented.

7. A program product, characterized in that, When the program product is executed by the processor, it implements the method as described in any one of claims 1-3.

Images