Multi-shot comparison test method and device, electronic equipment and program product

Abstract

The invention provides a multiple comparison test method and device, electronic equipment and a program product. Accuracy, light weight and high efficiency of multi-heterogeneous database adaptation test are achieved. The storage process of the application layer is analyzed to generate unified execution logic, independent test transactions are created for each target database, business logic is executed in the transactions, fragmentation deviation is avoided, result comparative analysis is matched, and test accuracy and exception recognition precision are guaranteed; on the basis of a multi-source data configuration and storage process analysis result, core resources are preloaded to a shared memory, an application layer only needs to maintain one set of service logic, multiple libraries do not need to be independently adapted to versions, repeated analysis and disk IO are reduced, and resource occupation and deployment cost is remarkably reduced; the multi-database connection configuration is quickly matched through the storage process identifier and the data source name, the sub-threads are configured according to the number of the databases and are executed concurrently, a test script does not need to be written manually, batch comparison can be initiated through simple configuration, the test period is greatly shortened, and the adaptation development and execution efficiency is effectively improved.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of database testing, in particular to a multi-source comparison testing method and device, electronic equipment and program product. BACKGROUND

[0002] For database testing, especially for multi-source testing comparison technology of heterogeneous databases, the existing multi-database testing scheme mainly includes two types: one is to add a Java Database Connectivity (JDBC) proxy layer between the application layer and the database, to forward the SQL fragments and compare the results; the other is to realize multi-forwarding through a business gateway, which requires the deployment of multiple sets of application layer services. Both schemes are used to solve the adaptation testing needs of multi-heterogeneous databases.

[0003] The above-mentioned scheme has obvious defects: the JDBC proxy layer only forwards isolated SQL fragments, missing transaction context, resulting in result deviation due to isolation difference of different databases, affecting the testing accuracy; the gateway scheme requires the deployment of multiple sets of application layer services, causing resource waste, and cannot efficiently adapt to multi-lingual domestic databases. SUMMARY

[0004] The purpose of the present application is to provide a multi-source comparison testing method, device, electronic equipment and program product, which can reduce the implementation cost of multi-source comparison and improve the accuracy of comparison results.

[0005] In order to achieve the above-mentioned purpose, the technical scheme adopted by the embodiments of the present application is as follows: In a first aspect, the embodiments of the present application provide a multi-source comparison testing method, comprising: According to the multi-source data configuration, the database connection layer resource is stored in the shared memory; the database connection layer resource contains the corresponding relationship between the data source name and the multiple database connection configurations; The application layer stored procedure is parsed, and the business execution layer resource is stored in the shared memory; the business execution layer resource contains the stored procedure instance and the logical execution tree; the database connection layer resource and the business execution layer resource establish a mapping relationship through the data source name; When the 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 according to the target data source name; A corresponding test transaction is created for each target database, and a target logical execution tree corresponding to the source test target is executed in the corresponding test transaction; The execution result fed back by each target database is obtained, and comparison analysis is performed.

[0006] Secondly, embodiments of this application provide a multi-shot comparison testing device, comprising: 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; 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.

[0007] Thirdly, embodiments of this application provide an electronic device, including: 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 the first aspects above is implemented.

[0008] 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.

[0009] 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.

[0010] In order to make the above objectives, characteristics and advantages of the present application more apparent, more comprehensible, the following preferred embodiments are specifically described in detail below, and the accompanying drawings are referred to. BRIEF DESCRIPTION OF DRAWINGS

[0011] In order to more clearly illustrate the technical solutions of the embodiments of the present application, the following will briefly introduce the drawings needed to be used in the embodiments, and it should be understood that the following drawings only show some embodiments of the present application, and therefore should not be regarded as a limitation to the scope, and for those skilled in the art, other related drawings can also be obtained without paying creative labor on the basis of these drawings.

[0012] Figure 1 The schematic diagram of the prior art multi-issuing comparison test architecture using JDBC agent layer; Figure 2 The schematic diagram of the prior art multi-issuing comparison test architecture using multi-issuing comparison gateway; Figure 3 The schematic diagram of the multi-issuing comparison test device provided by the present application; Figure 4 The schematic diagram of the multi-issuing comparison test method flow provided by the embodiment of the present application; Figure 5 The schematic diagram of another multi-issuing comparison test method flow provided by the embodiment of the present application; Figure 6 The schematic diagram of another multi-issuing comparison test method flow provided by the embodiment of the present application; Figure 7 The schematic diagram of another multi-issuing comparison test device provided by the present application; Figure 8 The schematic diagram of another multi-issuing comparison test method flow provided by the embodiment of the present application; Figure 9 The schematic diagram of another multi-issuing comparison test method flow provided by the embodiment of the present application; Figure 10 The schematic diagram of the structure of an electronic device provided by the embodiment of the present application. DETAILED DESCRIPTION

[0013] In order to make the objectives, technical solutions and advantages of the embodiments of the present application more apparent, the following will clearly and completely describe the technical solutions of the embodiments of the present application in combination with the drawings in the embodiments of the present application. Obviously, the described embodiments are some embodiments of the present application, but not all the embodiments. The components of the embodiments of the present application described and shown in the drawings here can be arranged and designed in various different configurations.

[0014] The following detailed description of embodiments of the application in the drawings attached hereto is included to provide a thorough understanding of the application. However, the application can be practiced without resorting to the details discussed in the following description. Accordingly, the following description is included to enable others skilled in the art to practice the application.

[0015] It should be noted that like reference numerals and letters refer to like items in the following figures, and as a result, once an item is defined in one figure, it is not necessary to further define and explain it in the subsequent figures. Also, in the description of the application, the terms "first", "second", and so on are used merely to distinguish one item from another, and are not to be construed as indicating or implying relative importance.

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

[0017] In the prior art, in order to implement multi-release comparison testing for different language system databases, one way is to use a JDBC agent layer to execute the testing process. Specifically, Figure 1 For the architecture diagram of the prior art using a JDBC agent layer to execute multi-release comparison testing, see Figure 1 The architecture includes an application layer service, a JDBC agent / gateway, a plurality of language system databases to be tested (such as Figure 1 Oracle system databases, Mysql databases, and PG system databases), and a comparison service.

[0018] 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.

[0019] 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.

[0020] 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.

[0021] 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.

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

[0023] 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.

[0024] Optionally, Figure 3 A schematic diagram of a multi-source comparison test device is provided in the present application, see Figure 3 The multi-source comparison test device 10 comprises a startup configuration component 101, a shared memory 102, and a comparison module 103.

[0025] The startup configuration component 101 is configured to load a multi-source data configuration. Optionally, the multi-source data configuration is used to uniformly manage the connection attribute information of various heterogeneous databases under different credit systems, and through a preset naming rule, a standard data source name is defined for each business scenario data source, thereby establishing a one-to-one mapping or one-to-many mapping relationship between the data source name and the database connection configuration (DataSource). Further, a database connection layer resource is constructed.

[0026] Optionally, the startup configuration component 101 stores a business execution layer resource in the shared memory by analyzing an application layer stored procedure. The business execution layer resource represents a core execution class resource set stored in the shared memory after the application layer stored procedure is structurally analyzed, and is a key carrier connecting the application layer business logic and the multi-database test execution, thereby providing a standardized and executable business logic benchmark for batch comparison test of stored procedures under multi-heterogeneous databases.

[0027] Optionally, the business execution layer resource comprises a stored procedure instance and a logical execution tree. Moreover, the database connection layer resource and the business execution layer resource establish a mapping relationship through the data source name.

[0028] Optionally, in order to improve the retrieval efficiency and data consistency of the execution mechanism resource of the present application, the above-mentioned database connection layer resource and business execution layer resource can be stored in the shared memory 102, so as to be called by the subsequent comparison test running.

[0029] Referring to Figure 3 The comparison module 103 comprises a running component 103-1 and a comparison component 103-2.

[0030] The running component 103-1 is configured to determine a corresponding target data source name based on a source test target stored procedure when the comparison test is triggered through the front end; 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 a target logical execution tree corresponding to the source test target in the corresponding test transaction.

[0031] The comparison component 103-2 is configured to obtain an execution result fed back by each target database, perform comparison analysis, and feed back the comparison result to the front end.

[0032] Optionally, based on the above architecture, a possible implementation of a multi-issuing comparison test method is provided, in particular, Figure 4 A multi-issuing comparison test method flowchart is provided for the embodiment of the application, referring to Figure 4 The method comprises the following steps: Step 200, according to the multi-source data configuration, store the database connection layer resource in the shared memory. Step 201, parse the application layer stored procedure, and store the business execution layer resource in the shared memory.

[0033] 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.

[0034] Step 203, determine at least one target database connection configuration in the shared memory according to the target data source name.

[0035] Step 204, create a corresponding test transaction for each target database, and execute the target logical execution tree corresponding to the source test target in the corresponding test transaction.

[0036] Step 205, obtain the execution result fed back by each target database, and perform comparison analysis.

[0037] The multi-issuing comparison test method provided by the embodiment of the application realizes accurate, lightweight and efficient multi-heterogeneous database adaptation test. The application layer stored procedure is parsed to generate unified execution logic, and independent test transactions are created for each target database. The business logic execution is limited within the transaction boundary, avoiding fragmented execution deviation. The comparison analysis of the execution result guarantees the test accuracy and the accuracy of abnormal identification. Based on the multi-source data configuration and the parsing result of the application layer stored procedure, the core resource is preloaded to the shared memory. The application layer only needs to maintain a set of business logic, and does not need to develop an adaptation version for different databases, reducing repeated parsing and disk IO operation, and significantly reducing system resource occupation and deployment cost. The multi-database connection configuration is quickly matched through the stored procedure identifier and the data source name. The sub-thread is configured for concurrent execution according to the number of databases. There is no need to manually write test scripts. The multi-database batch comparison can be initiated only by simple configuration, greatly shortening the test period and effectively improving the adaptation development and execution efficiency.

[0038] Optionally, in order to standardize and structure the data of the application layer stored procedure, so as to reside in the shared memory, a possible implementation is provided as follows, in particular, based on Figure 4 , the application layer stored procedure is parsed to generate a unified execution logic, and the business logic execution is limited within the transaction boundary, avoiding fragmented execution deviation. Figure 5 Another multi-issuing comparison test method flowchart is provided for the embodiment of the application, referring to Figure 5 Step 201 comprises the following steps: Step 201-1, parsing the application layer stored procedure to obtain the application layer stored procedure identifier corresponding to the application layer stored procedure, all SQL statements and each SQL statement identifier.

[0039] Step 201-2, constructing a logical execution tree based on all SQL statements and each SQL statement identifier.

[0040] Step 201-3, constructing a stored procedure instance according to the application layer stored procedure identifier, data source name and logical execution tree.

[0041] Optionally, for the application layer stored procedure, it can be a PL / Xml configured in the application layer project, for example: <transform id="p_unique id" datasource="hspbs"> <desc><![CDATA[ Application layer PL / Xml stored procedure ]]>< / desc> <param id="userId" dataType="string" value="#{userId}" desc="入参:用户id"> <param id="age" dataType="int" value="#{age}" default="18" desc="入参:用户年龄"> <!-- Return logic control --> <if test="userId == null"> <return mode="exception" message="入参age不能为空!" / > < / if> <!-- Query SQL statement block --> <selectsql id="selectUserCount"> select count(1)as "COUNT" from USER where USER_ID = #{userId} < / selectsql> <!-- Logic control statement block --> <if test="selectUserCount.COUNT lte 0 "> <updatesql id="updateUser"> update USER set AGE = #{age} where USER_ID = #{userId} < / updatesql> < / if> <selectlistsql id="selectUserList"> select user_id as "userId" from USER limit 10 < / selectlistsql> <!-- Cursor statement block --> <cursor list="selectUserList" item="myItem" index="myIndex"> <param id="userId" dataType="string" value="#{myItem.userId}"> <updatesql id="updateUser2"> update USER set AGE = #{age} where USER_ID = #{userId} < / updatesql> < / cursor> < / transform> Performing a parsing operation on the above PL / Xml script: Extracting core identifier and content: obtaining the unique identifier p_unique id of the application layer stored procedure, all SQL statements (such as the query statement corresponding to selectUserCount, the update statement corresponding to updateUser, etc.) in the script and the unique identifier of each SQL statement (selectUserCount, updateUser, selectUserList, updateUser2); constructing a logical execution tree: based on the execution dependency and flow control of the SQL statement (such as throwing an exception when userId == null, executing updateUser when selectUserCount.COUNT <= 0, and executing updateUser2 in a loop driven by the selectUserList query result cursor), constructing a logical execution tree of the solidified execution order and logical relationship; constructing a stored procedure instance: combining the extracted stored procedure identifier p_unique id, the data source name hspbs bound by the script and the above logical execution tree, generating a stored procedure instance; finally, storing the "stored procedure instance and logical execution tree" as a business execution layer resource into the shared memory, and establishing a mapping relationship with the database connection layer resource stored in step 200 through the data source name hspbs.

[0042] Optionally, relying on the application layer stored procedure identifier transmitted by the front end, the corresponding business execution layer resource is accurately called from the shared memory, and the target data source name bound therein is extracted; the core is to provide an accurate data source benchmark for subsequent matching of multi-database connection configuration, to ensure the accurate connection of test triggering and multi-source database adaptation link, to avoid data source matching errors caused by identifier confusion, to support the orderly development of multi-heterogeneous database batch comparison test, specifically, on the basis of Figure 4 Figure 6 ​Another multi-issuing comparison test method flow diagram provided by the embodiment of the application is shown in FIG. 2. Figure 6 Step 202 comprises: Step 202-1, receiving the target application layer storage process identifier corresponding to the source test target input in the front end.

[0043] Step 202-2, determining the corresponding target business execution layer resource in the shared memory according to the target application layer storage process identifier.

[0044] Step 202-3, extracting the target data source name contained in the target business execution layer resource.

[0045] Optionally, for the comparison test requirement of multiple target databases, the corresponding sub-thread is configured according to the number of databases and is bound to the respective connection configuration, an independent test transaction is created for each database, and the SQL statements in the logical execution tree are executed in a unified order within the transaction boundary; the core is to implement multi-database asynchronous parallel execution, to guarantee the consistency and isolation of the execution environment of each database in a transaction, to ensure the unified execution logic, to provide real and comparable transaction internal execution data for subsequent result comparison, and to improve the test efficiency and result accuracy. Specifically, on the basis of Figure 3 , Figure 7 Another multi-issuing comparison test device diagram provided by the application is shown in FIG. 3. Figure 7 The running component 103-1 in the multi-issuing comparison test device 10 comprises a thread pool 103-11.

[0046] The thread pool 103-11 is used to provide a sub-thread for each database to be tested, which is used to deploy a corresponding test transaction.

[0047] Optionally, based on the multi-issuing comparison test device shown in Figure 7 , on the basis of Figure 4 , Figure 8 Another multi-issuing comparison test method flow diagram provided by the embodiment of the application is shown in FIG. 2. Figure 8 Step 202 comprises: Step 202-1, configuring a corresponding number of sub-threads based on the number of all target databases.

[0048] Each sub-thread is matched with a corresponding target database connection configuration.

[0049] Step 202-2, creating a test transaction for the corresponding target database connection configuration through each sub-thread.

[0050] Step 202-3, each sub-thread calls the target logical execution tree corresponding to the source test target in the corresponding test transaction.

[0051] Step 202-4, each sub-thread executes the SQL statement identified corresponding SQL statement according to the execution order of the target logical execution tree.

[0052] Optionally, continuing to refer to Figure 7 , in addition to maintaining the database connection layer resources and the business execution layer resources, the shared memory can also be used to maintain the context mapping table. Optionally, in a possible implementation manner, all SQL execution results in each target database test transaction are stored to the context mapping table, and the abnormal types are determined by the result state layering: the compatibility exception is confirmed when any SQL execution fails, and the comparison exception is confirmed when all executions are successful but the results are inconsistent; the core is to accurately identify the adaptation exception of the application layer stored procedure under the multi-heterogeneous database, to provide clear abnormal determination basis for the multi-source database comparison test, and to guarantee the effective discovery of compatibility and result consistency problems. Specifically, based on Figure 8 , Figure 9 Another multi-source comparison test method flowchart provided by the embodiment of the present application is shown in FIG. 5, and the steps 205 include: Figure 9 Step 205-1, the execution results of all SQL statements in the same test transaction are stored in the context mapping table as the execution results fed back by the corresponding target database.

[0053] Step 205-2, when the execution result of any SQL statement fails, it is confirmed that the target database corresponding to the execution result has a compatibility exception.

[0054] Step 205-3, when all execution results are successfully executed and there is inconsistency, it is confirmed that a comparison exception occurs.

[0055] Optionally, through the hierarchical logic of “basic compatibility screening and deep result consistency verification”, the adaptation exceptions of different priorities and different causes are accurately distinguished, which not only ensures that the basic adaptation problems must be solved without omission, but also efficiently discovers hidden database characteristic difference problems, provides clear problem orientation for multi-source database adaptation optimization, and comprehensively improves the pertinence and integrity of multi-heterogeneous database comparison test. Specifically, the above-mentioned “compatibility exception” can be used as a first-level exception, and the “comparison exception” can be used as a second-level exception to construct a two-level exception identification mechanism of comparison structure.

[0056] Specifically, the first-level exception: compatibility exception, focuses on the basic adaptation obstacles, and guarantees the test feasibility.

[0057] ​The first-level exception is directed to the scene that the SQL statement in the application layer storage process of the multi-heterogeneous database is different in basic syntax and database object support, resulting in SQL execution failure. The core determination logic is: when the corresponding execution result of any SQL statement identification in the logical execution tree in the target database test transaction is "failure", it is directly determined as a compatibility exception.

[0058] For example, taking the distributed architecture relational database, single machine architecture relational database, and cloud native database associated with the data source name "hspbs" as an example, the application layer PL / Xml storage process contains the SQL statement "select 1 from dual" (SQL identification: selectDual). During execution, the single machine architecture relational database and the cloud native database support the dual table syntax and can execute normally and return the result; while some distributed architecture relational databases do not adapt to the dual table, a general database object, resulting in an error in the execution of the SQL statement. At this time, the system directly determines that the distributed architecture relational database has a first-level compatibility exception.

[0059] The core effect of this exception is to quickly locate the basic adaptation obstacles that "cannot be executed". This type of exception is intuitive and easy to find, and directly affects the subsequent test, so it is marked as a core exception that must be solved first. From the source, it guarantees the basic feasibility of multi-source comparison test, and avoids invalid test due to basic adaptation problems.

[0060] Specifically, the second-level exception: comparison exception, focuses on the result difference after successful execution, and digs deep adaptation problems.

[0061] The second-level exception is directed to the scene that all SQL statements of the target database are executed successfully, but the execution results are inconsistent. This type of exception has strong concealment and can only be found through accurate comparison of multi-library results. The core role is to dig deep adaptation problems of "can execute but execution effect is poor". Specifically, it is divided into two types of sub-exceptions: Optionally, this type of exception is directed to the scene that the underlying business data of each target database is inconsistent, resulting in differences in the execution results of the same SQL. The determination logic is: all target database SQLs are executed successfully, but the DML statement changes the row number, the DQL statement query result set is inconsistent, and the cause can be traced back to the database table data difference.

[0062] For example, the application layer PL / Xml stored procedure contains a delete SQL statement "delete from USER where USER_ID = #{userId}" (SQL identifier: deleteUser), which is successfully executed in the first type of single-machine architecture relational database, the second type of single-machine architecture relational database, and the open source relational database, but the number of changed rows returned is 1, 0, and 1 respectively. Through system trace analysis, there is no user record corresponding to the userId in the USER table of the second type of single-machine architecture relational database, while the USER table of the other two types of architecture databases has the record, thus determining that it is a data inconsistency comparison exception.

[0063] The effect of this type of exception is to accurately locate the adaptation interference factors at the "data layer", to determine that the inconsistent test results are not due to database architecture adaptation problems, but due to data synchronization missing, to provide a basis for data standardization of the test environment, and to avoid misjudgment of adaptation problems.

[0064] Optionally, this type of exception is aimed at the differences in the inherent characteristics (such as function processing rules, syntax compatibility details) of different database architectures, which lead to the scene where SQL execution is successful but the results are inconsistent. The determination logic is that all target database SQL executions are successful, and the cause of inconsistent results is attributed to the inherent characteristics of the database architecture, rather than data differences.

[0065] For example, the application layer PL / Xml stored procedure contains a string concatenation SQL statement "select CONCAT('user_', #{userId}) as userName" (SQL identifier: concatUserName), which is successfully executed in the cloud-native database, NewSQL architecture database, and distributed architecture relational database, but the returned results differ: if the userId is null in the cloud-native database, the CONCAT function returns null; the NewSQL architecture database returns "user_null" when the userId is null; and the distributed architecture relational database returns "user_". This difference is due to the inherent characteristics of different database architectures in handling null values of the CONCAT function, and the system determines it as a database characteristic difference comparison exception.

[0066] The effect of this type of exception is to effectively discover "hidden adaptation problems" that are difficult to detect in traditional testing. This type of problem is easily overlooked because SQL execution is successful, but it can cause business logic result deviation. Through the multi-release comparison of this mechanism, it can be accurately identified, providing clear evidence for cross-architecture adaptation optimization of SQL statements (such as function replacement, syntax compatibility processing).

[0067] In summary, the secondary exception determination mechanism of the application forms a full-scenario exception identification system covering "execution failure, execution success but data inconsistency, execution success but feature difference" through the hierarchical logic of "basic compatibility first, deep consistency second". It not only can quickly lock the basic adaptation obstacles that must be solved, and guarantee the test feasibility, but also can accurately excavate the hidden deep adaptation problems, solve the pain points of incomplete exception identification and fuzzy cause positioning in traditional multi-library testing, provide accurate and hierarchical problem guidance for the adaptation optimization of multi-heterogeneous database architecture, and significantly improve the depth and effectiveness of multi-source database comparison testing.

[0068] The above examples of the application are based on the structured analysis of the application layer PL / Xml stored procedure, the shared memory resource scheduling and the transactional execution mechanism, and realize the "accurate, lightweight and efficient" triple core effect of multi-heterogeneous database adaptation testing: 1) Accurate and controllable comparison results: all SQL executions of the databases are limited within the independent test transaction boundary, relying on the unified logical execution tree and the double-layer unique identification system to avoid result deviation caused by SQL fragmentation execution; combined with the secondary exception determination mechanism, the compatibility exceptions, data inconsistency and database feature difference problems are accurately distinguished, and the exception cause positioning is clear.

[0069] 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 adaptation versions for different databases; by preloading core resources through shared memory, repeated parsing and disk IO are avoided, and the system deployment and resource occupation cost are greatly reduced.

[0070] 3) Test execution and development efficiency: support concurrent execution and automatic comparison of multi-heterogeneous databases through simple configuration, without the need to manually write multi-library test scripts; multi-thread asynchronous scheduling and shared memory fast retrieval mechanism significantly shorten the test startup and execution period, and reduce the development and test cost of signal creation multi-database adaptation.

[0071] In order to realize each step of the above examples and the corresponding technical effects, the application further provides a multi-source comparison testing device, and the implementation architecture thereof is as follows Figure 3 And Figure 4 .

[0072] Specifically, the multi-source comparison testing device provided by the application has the following functions: The startup configuration component 101 is configured to store database connection layer resources in the shared memory 102 according to multi-source data configuration; and the application layer stored procedure is parsed, and the business execution layer resources are stored in the shared memory.

[0073] The comparison module 103 is configured to determine a corresponding target data source name based on a 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 a target logical execution tree corresponding to the source test target in the corresponding test transaction, and obtain an execution result fed back by each target database for comparison analysis.

[0074] Optionally, the start configuration component 101 is configured to parse an application layer stored procedure, obtain an application layer stored procedure identifier, all SQL statements and a SQL statement identifier corresponding to the application layer stored procedure, construct a logical execution tree based on the all SQL statements and the SQL statement identifier, and construct a stored procedure instance according to the application layer stored procedure identifier, a data source name and the logical execution tree.

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

[0076] Optionally, the comparison module 103 further includes a thread pool 103-1.

[0077] The thread pool 103-1 is configured to configure a corresponding number of sub-threads based on the number of all target databases, create a test transaction for a corresponding target database connection configuration through each sub-thread, call a target logical execution tree corresponding to the source test target in the corresponding test transaction by each sub-thread, and execute a SQL statement corresponding to the SQL statement identifier according to an execution order of the target logical execution tree by each sub-thread.

[0078] Optionally, the comparison module 103 further includes a comparison component 103-2.

[0079] The comparison component 103-2 is configured to store execution results of all SQL statements in a same test transaction in a context mapping table as execution results fed back by a corresponding target database, confirm that a compatible exception occurs in the corresponding target database when a corresponding execution result of any SQL statement identifier in the execution results fails, and confirm that a comparison exception occurs when all execution results are successfully executed and there is inconsistency.

[0080] The embodiment of the application further provides an electronic device which can execute the steps of all examples of the embodiment of the application to achieve corresponding technical effects. Figure 10 A structural schematic diagram of an electronic device provided by the embodiment of the application is shown in FIG. 1. Figure 10The electronic device 30 comprises a memory 301 and a processor 300. The memory 301 is configured to store one or more programs. The processor 300. When the one or more programs are executed by the processor, when the electronic device 30 is configured to execute the steps shown in the above various method examples, the various steps and corresponding technical effects can be achieved.

[0081] In the embodiments provided in the present application, it should be understood that the disclosed apparatus and method can also be implemented by other means. The apparatus embodiment described above is only schematic, for example, the flowchart and block diagram in the drawings show the possible implementation architecture, function and operation of the apparatus, method and computer program product according to the embodiments of the present application. In this regard, each block in the flowchart or block diagram can represent a module, a program segment or a part of code, which contains one or more executable instructions for implementing the specified logical function. It should also be noted that in some alternative implementations, the functions noted in the blocks can occur in a different order than that shown in the figure. For example, two consecutive blocks can actually be executed substantially in parallel, and sometimes they can be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagram and / or flowchart, and the combination of blocks in the block diagram and / or flowchart, can be implemented by a dedicated hardware-based system, or can be implemented by a combination of dedicated hardware and computer instructions.

[0082] In addition, the functional modules in the various embodiments of the present 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.

[0083] If the functions are implemented in the form of software function modules and sold or used as independent products, they can be stored in a computer readable storage medium. Based on this understanding, the technical solutions of the present application can be embodied in the form of a program product, which is stored in a computer readable storage medium and includes a plurality of instructions for causing a computer device (which can be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the various embodiment methods of the present application. The aforementioned storage medium includes: a U disk, a mobile hard disk, a read-only memory (ROM, Read-Only Memory), a random access memory (RAM, Random Access Memory), a magnetic disk or an optical disk, and various media that can store program codes.

[0084] The above merely provides preferred embodiments of the present application, and is not intended to limit the present application. For those skilled in the present application, various modifications and variations can be made thereto. Any modifications, equivalent replacements, improvements, etc. made within the spirit and principle of the present application shall fall within the scope of the present application.

[0085] It is apparent for those skilled in the art that the present application is not limited to the details of the foregoing exemplary embodiments, but can be implemented in other concrete forms without departing from the spirit or essential characteristics of the present application. Therefore, the embodiments should be considered in all aspects as illustrative and not restrictive, and the scope of the present application is defined by the appended claims rather than the foregoing description, and it is intended to embrace all changes falling within the meaning and range of equivalents of the claims. Any reference signs in the claims should not be considered as limiting the claims involved.

Claims

1. A multiple occurrence alignment test method, characterized by, The application relates to a method for testing database compatibility, and belongs to the technical field of database compatibility testing. According to a multi-source data configuration, a database connection layer resource is stored in shared memory; The database connection layer resource contains a corresponding relationship between a data source name and a plurality of database connection configurations; An application layer stored procedure is parsed, and a business execution layer resource is stored in the shared memory; the business execution layer resource contains a stored procedure instance and a logical execution tree; The database connection layer resource and the business execution layer resource establish a mapping relationship through the data source name; When a comparison test is triggered, a corresponding target data source name is determined based on a stored procedure of a source test target; At least one target database connection configuration is determined in the shared memory according to the target data source name; A corresponding test transaction is created for each target database, and a target logical execution tree corresponding to the source test target is executed in the corresponding test transaction; Execution results fed back by each target database are obtained, and comparison analysis is performed.

2. The method of claim 1, wherein, The step of parsing the application layer stored procedure and storing the business execution layer resource in the shared memory comprises the following steps: The application layer stored procedure is parsed to obtain an application layer stored procedure identifier, all SQL statements and an SQL statement identifier of each SQL statement corresponding to the application layer stored procedure; The logical execution tree is constructed based on all the SQL statements and the SQL statement identifier of each SQL statement; The stored procedure instance is constructed according to the application layer stored procedure identifier, the data source name and the logical execution tree.

3. The method of claim 2, wherein, 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 comprises the following steps: The target application layer stored procedure identifier corresponding to the source test target is received through front-end input; The corresponding target business execution layer resource is determined in the shared memory according to the target application layer stored procedure identifier; The target data source name contained in the target business execution layer resource is extracted.

4. The method of claim 2, wherein, The step of creating a corresponding test transaction for each target database and executing a target logical execution tree corresponding to the source test target in the corresponding test transaction comprises the following steps: A corresponding number of sub-threads are configured based on the number of all the target databases; each sub-thread is matched with a corresponding target database connection configuration; A test transaction is created for the corresponding target database connection configuration through each sub-thread; Each sub-thread calls a target logical execution tree corresponding to the source test target in the corresponding test transaction; Each sub-thread executes an SQL statement corresponding to the SQL statement identifier according to the execution order of the target logical execution tree.

5. The method of claim 4, wherein, The step of obtaining the execution results fed back by each target database and performing comparison analysis comprises the following steps: The execution results of all the SQL statements in the same test transaction are stored in a context mapping table as the execution results fed back by the corresponding target database; When the execution result of any SQL statement identifier in the execution result fails, it is confirmed that a compatible exception occurs in the target database corresponding to the execution result; When all the execution results are successfully executed and there is inconsistency, it is confirmed that a comparison exception occurs.

6. A multiple-shot alignment testing device, characterized by, The application relates to a method for testing database compatibility, and belongs to the technical field of database compatibility testing. A starting configuration component is configured to store database connection layer resources in shared memory according to multi-source data configuration; The database connection layer resources include a correspondence between a data source name and a plurality of database connection configurations; an application layer stored procedure is parsed, and business execution layer resources are stored in the shared memory; the business execution layer resources include a stored procedure instance and a logical execution tree; The database connection layer resources and the business execution layer resources establish a mapping relationship through the data source name; A comparison module is configured to determine a corresponding target data source name based on a stored procedure of a source test target when a comparison test is triggered; At least one target database connection configuration is determined in the shared memory according to the target data source name; A corresponding test transaction is created for each target database, and a target logical execution tree corresponding to the source test target is executed in the corresponding test transaction; Execution results fed back by each target database are obtained, and comparison analysis is performed.

7. The apparatus of claim 6, wherein, The starting configuration component is specifically configured to parse the application layer stored procedure, obtain an application layer stored procedure identifier, all SQL statements, and an SQL statement identifier of each SQL statement corresponding to the application layer stored procedure; The logical execution tree is constructed based on all the SQL statements and the SQL statement identifier of each SQL statement; The stored procedure instance is constructed according to the application layer stored procedure identifier, the data source name, and the logical execution tree.

8. The apparatus of claim 7, wherein, The comparison module is specifically configured to receive a target application layer stored procedure identifier corresponding to the source test target input by a front end, determine corresponding target business execution layer resources in the shared memory according to the target application layer stored procedure identifier, and extract the target data source name included in the target business execution layer resources. The method comprises the following steps:

9. An electronic device, comprising: A memory is configured to store one or more programs; A processor; When the one or more programs are executed by the processor, the method of any one of claims 1-5 is implemented. The program product is executed by the processor, and the method of any one of claims 1-5 is implemented.

10. A program product, characterized by ​

Images