Database test scene playback method and device, equipment, storage medium and program product

Abstract

The invention provides a database test scene playback method and device, equipment, a storage medium and a program product, and relates to the technical field of database test. The method comprises the following steps: acquiring a target database log in the database; under the condition that a structured query language (SQL) statement bound with a binding variable exists in the target database log, the binding variable in the SQL statement is replaced with a corresponding parameter value in the database log, and a target SQL statement with complete semantics is obtained; sorting the target SQL statement to obtain an executable SQL file; and playing back the test environment according to the SQL file. The method is used for improving the playback efficiency and the reliability of the test result.

Description

Technical Field

[0001] This application relates to the field of database testing technology, and in particular to a database test scenario playback method, apparatus, device, storage medium, and program product. Background Technology

[0002] During the development and maintenance of database systems, it is necessary to test the system's functionality and performance. Database log files, as a core data source, are used to record database operations. Replaying these logs in a test environment allows for the detection of the system's actual functionality and performance. Therefore, database test scenario replay is crucial.

[0003] Currently, existing database test scenario replay methods primarily rely on capturing and replaying workloads from database logs. This method requires testers to use replay tools to reproduce the business workload (such as SQL statements and transaction operations) from the production environment in the test environment. However, because these existing database test scenario replay methods depend on manual intervention, they suffer from low replay efficiency and poor test results. Summary of the Invention

[0004] This application provides a database test scenario playback method, apparatus, device, storage medium, and program product to improve playback efficiency and test result reliability.

[0005] Firstly, this application provides a method for replaying database test scenarios, including:

[0006] Obtain the target database logs from the database;

[0007] If a Structured Query Language (SQL) statement with bound variables exists in the target database log, the bound variables in the SQL statement are replaced with the corresponding parameter values ​​in the database log to obtain a semantically complete target SQL statement.

[0008] The target SQL statement is processed to obtain an executable SQL file;

[0009] Replay the test environment based on the SQL file.

[0010] In one possible implementation, if a Structured Query Language (SQL) statement with bound variables exists in the target database log, the bound variables in the SQL statement are replaced with the corresponding parameter values ​​in the database log to obtain a semantically complete target SQL statement, including:

[0011] Parse the SQL statements in the target database logs to identify bind variable identifiers;

[0012] Extract the parameter value corresponding to the bind variable identifier from the target database log;

[0013] The bind variable identifier is replaced with the parameter value to obtain the target SQL statement containing the actual parameter value.

[0014] In one possible implementation, obtaining the target database logs in the database includes:

[0015] The test request retrieves the full log data from the database; the test request includes the database schema, database name, and / or username; the database schema refers to the logical structure of the object.

[0016] The full log data is filtered according to the test request to obtain the target database log;

[0017] The parsing of SQL statements in the target database log includes:

[0018] The SQL statement is obtained by filtering the target database according to preset keywords;

[0019] Parse the SQL statement.

[0020] In one possible implementation, prior to parsing the SQL statement, the method further includes:

[0021] Identify block statements within the SQL statement and add block statement identifiers;

[0022] Add a statement separator after the SQL statement corresponding to the block statement identifier. The statement separator is a symbol used to separate independent SQL statements.

[0023] In one possible implementation, the step of organizing the target SQL statement to obtain an executable SQL file includes:

[0024] The target SQL statement is deduplicated, semicolons are added, special characters are replaced, and / or encoding is converted to obtain the executable SQL file.

[0025] In one possible implementation, after obtaining the target database logs from the database, the method further includes:

[0026] Perform a logical backup and restore operation to generate a logical backup and restore file;

[0027] The replay of the test environment based on the SQL file includes:

[0028] The database restoration operation was performed on the test system using the aforementioned logical backup and restore file.

[0029] The SQL file was run on the test system to obtain the execution results.

[0030] In one possible implementation, replacing the bind variable in the SQL statement with the corresponding parameter value in the database log includes:

[0031] By combining the key field 'parameters' in the target database log, the bind variables of the SQL statement are replaced with actual parameter values.

[0032] Secondly, this application provides a database test scenario playback device, comprising:

[0033] The acquisition module is used to acquire the target database logs in the database;

[0034] The replacement module is used to replace the bound variables in the structured query language SQL statement with the corresponding parameter values ​​in the database log when there is a structured query language SQL statement with bound variables in the target database log, so as to obtain a semantically complete target SQL statement.

[0035] The processing module is used to process the target SQL statement to obtain an executable SQL file;

[0036] The replay module is used to replay the test environment based on the SQL file.

[0037] Thirdly, embodiments of this application provide an electronic device, including: a memory and a processor;

[0038] The memory stores computer-executed instructions;

[0039] The processor executes computer execution instructions stored in the memory, causing the processor to perform the method described in any of the first aspects above.

[0040] Fourthly, embodiments of this application provide a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the method described in any of the first aspects above.

[0041] Fifthly, embodiments of this application provide a computer program product, including a computer program that, when executed by a processor, implements the method described in any of the first aspects above.

[0042] This application provides a database test scenario replay method, apparatus, device, storage medium, and program product. It obtains target database logs from the database, laying the foundation for subsequent operations. When the target database logs contain Structured Query Language (SQL) statements with bound variables, replacing the bound variables in the SQL statements with the corresponding parameter values ​​from the database logs yields semantically complete target SQL statements, improving processing accuracy and efficiency. Further refining the target SQL statements produces executable SQL files, enhancing their executability. Replaying the test environment based on these SQL files improves replay efficiency and the reliability of test results. Attached Figure Description

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

[0044] Figure 1 A flowchart illustrating a database test scenario replay method provided in this application;

[0045] Figure 2 A flowchart illustrating another database test scenario replay method provided in this application;

[0046] Figure 3 A schematic diagram of the structure of a database test scenario playback device provided in this application;

[0047] Figure 4 This is a schematic diagram of the structure of an electronic device provided in this application.

[0048] The accompanying drawings illustrate specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concepts of this application to those skilled in the art through reference to particular embodiments. Detailed Implementation

[0049] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0050] In this application, the term "comprising" and its variations can refer to non-limiting inclusion; the term "or" and its variations can refer to "and / or". The terms "first", "second", etc., in this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. In this application, "multiple" refers to two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. The character " / " generally indicates that the preceding and following related objects have an "or" relationship.

[0051] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, storage, use, processing, transmission, provision, disclosure, and application of the relevant data all comply with the relevant laws, regulations, and standards of the relevant countries and regions, have taken necessary confidentiality measures, do not violate public order and good morals, and provide corresponding operation access points for users to choose to authorize or refuse.

[0052] Furthermore, the technical solution involved in this application, which involves big data analysis of user information (including but not limited to personal biometrics, identity data, consumption data, asset data, electronic terminal operation data, etc.) and the use of artificial intelligence technology for automated decision-making, and makes decisions that have a significant impact on personal rights based on the results of automated decision-making, provides users with corresponding operation entry points for users to choose to agree to or reject the results of automated decision-making; if the user chooses to reject, the process will proceed to the expert decision-making process.

[0053] First, let's explain some of the terms used in this application:

[0054] Structured Query Language (SQL) is a standardized programming language used to interact with relational databases for querying, updating, defining, and controlling data.

[0055] During the development and maintenance of database systems, it is necessary to test the system's functionality and performance. Database log files, as a core data source, are used to record database operations. Replaying these logs in a test environment allows for the detection of the system's actual functionality and performance. Therefore, database test scenario replay is crucial.

[0056] Currently, existing database test scenario replay methods primarily rely on capturing and replaying database log load. This method requires testers to use replay tools to reproduce the business load (such as SQL statements and transaction operations) from the production environment in the test environment. Therefore, existing database test scenario replay methods, due to their dependence on manual intervention, suffer from low replay efficiency and poor test results.

[0057] Considering the aforementioned problems with existing database test scenario replay methods, this application proposes a database test scenario replay method based on dynamic filtering and statement optimization processing of database logs to achieve accurate extraction of SQL statements, thereby improving replay efficiency and test result reliability.

[0058] The execution entity of this database test scenario replay method can be, for example, a replay system. Optionally, the replay system can be any existing electronic device with processing capabilities, such as a terminal or a server. In some embodiments, the replay system can also be deployed in a server cluster or cloud environment. This application does not limit the deployment environment of the replay system.

[0059] The technical solution of this application and how the technical solution of this application solves the above-mentioned technical problems are described in detail below with specific embodiments.

[0060] The following specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will be described below with reference to the accompanying drawings.

[0061] Figure 1 This is a flowchart illustrating a database test scenario replay method provided in this application. Figure 1 As shown, the method includes:

[0062] S101, retrieve the target database log from the database.

[0063] In some embodiments, the playback system can obtain full log data from the database based on a test request. The test request includes a database schema and database name, or it includes a database schema and username, or it includes a database schema, database name, and username. The database schema refers to the logical structure of the object. Then, the full log data is filtered according to the test request to obtain the target database log. Then, the target database is filtered according to preset keywords to obtain the SQL statement. Finally, the SQL statement is parsed.

[0064] For example, a test request could be an instruction to perform log processing.

[0065] For example, a database schema can be the logical structure of objects in a database.

[0066] For example, full log data can be all log records generated during a prolonged database operation. For instance, full log data can include timestamps of all database operations, the executing user, the database to which they belong, the SQL statements, and the operation results.

[0067] Optionally, the replay system can verify the correctness of parameters in the test request. For example, the replay system can check whether the database schema exists, and whether the database name or username is registered in the database. If the verification fails, the replay system can terminate the process and return an exception message. If the verification succeeds, the replay system can read the full log file in a local file in a specified directory of the database through the file system interface to obtain the full log data. It can also obtain the full log data of the corresponding database in batches from the distributed log system through the Application Programming Interface (API).

[0068] Optionally, the playback system can convert the acquired full log data into a structured data format, and based on the database schema and database name in the test request, or the database schema and username in the test request, or the database schema, database name, and username in the test request, filter the full log data in the above structured data format through a query engine to obtain the target database log.

[0069] Optionally, the replay system can categorize the configuration file according to SQL operation types based on user-defined or default configured keywords. These keywords can be, for example, data operation keywords, structure operation keywords, or transaction operation keywords. Preset keywords may also include statements and execute statements.

[0070] Optional. The playback system can match the target database logs based on the aforementioned preset keywords and regular expressions, and extract the SQL statements from the successfully matched log records.

[0071] Optionally, the playback system can input the above SQL statement into the parser, generate an abstract syntax tree (AST), and extract basic information, conditional information, and execution attributes from the SQL statement by traversing the AST. The extracted information is then converted into a standardized format. For example, each node in the AST can correspond to a syntactic unit, such as an operation type, table name, or field list.

[0072] Using the above method, the full log data in the database is obtained based on the test request, laying the foundation for subsequent operations. Filtering this full log data according to the test request yields the target database logs, improving the accuracy of log filtering. Filtering the target database according to preset keywords retrieves the SQL statement. Parsing this SQL statement reduces processing costs and improves playback efficiency.

[0073] As one possible implementation, before parsing the SQL statement, the playback system can identify the block statements within the SQL statement and add block statement identifiers. Then, a statement separator, a symbol used to separate independent SQL statements, is added after the SQL statement corresponding to the block statement identifier.

[0074] For example, a block statement identifier can be a symbol used to identify a compound SQL statement.

[0075] Optionally, the replay system can preset feature matching rules for block statements in different databases. For example, for block statements of transaction type in relational database (MySQL), the start feature is preset to start (BEGIN) and the end feature is preset to end (END).

[0076] Optionally, the playback system can use regular expressions to match the boundaries of block statements based on the aforementioned preset features. This can be done by using custom block statement identifiers or by using block statement boundary symbols. A "block start identifier" is added at the beginning of a block statement where a start feature is matched, and a "block end identifier" is added at the end of a block statement where an end feature is matched. Different identifiers can also be added for block statements at different levels.

[0077] Optionally, the playback system can add a corresponding statement separator after the block end marker based on the type of the block statement and the database syntax rules. For example, a statement separator can be added after the END of the block statement. If a statement separator already exists after the block statement, it can be skipped. If there are multiple consecutive block statements, a statement separator can be added after each block statement.

[0078] By using the above method, before parsing the SQL statement, block statements in the SQL statement can be identified and marked with block statement identifiers. Statement separators are then added after the corresponding SQL statements, so that block statements can be completely extracted and executed independently during playback. This ensures the integrity and independence of the SQL statement during playback and improves the reliability of the test results.

[0079] S102, if a Structured Query Language (SQL) statement with bound variables exists in the target database log, replace the bound variables in the SQL statement with the corresponding parameter values ​​in the database log to obtain a semantically complete target SQL statement.

[0080] As one possible implementation, the replay system can combine the key field parameters in the target database log to replace the bind variables of the SQL statement with the actual parameter values.

[0081] For example, a bind variable can be a symbol used as a temporary placeholder in an SQL statement.

[0082] Optionally, the playback system can parse the bind variables in the SQL statement using regular expressions and read the contents of the parameters field based on the structured data in the target database log file, either through a parser or by column index.

[0083] Optionally, the replay system can, based on the type of the bind variable, map the actual parameter values ​​of the key field `parameters` to the placeholders in the SQL statement, and replace the bind variables in the SQL statement with the actual parameter values. For example, for positional bind variables, the replay system can replace them by sequentially taking the parameter values ​​from the `parameters` list according to the order in which the bind variables appear; for named bind variables, the replay system can replace them by taking the value of the corresponding key from the `parameters` dictionary according to the name of the bind variable.

[0084] Optionally, if, during the process of replacing the bind variables of the SQL statement with actual parameter values, situations arise such as a mismatch in the number of processed parameters, the absence of named variables, or incompatible parameter types, the replay system can issue an alarm and record an exception log.

[0085] By using the above method, and combining the key field parameters in the target database log, the bind variables of the SQL statement are replaced with actual parameter values, thereby improving playback efficiency.

[0086] In some embodiments, the playback system can parse the SQL statements in the target database log to identify bind variable identifiers. Then, it extracts the parameter values ​​corresponding to the bind variable identifiers from the target database log. Finally, it replaces the bind variable identifiers with the parameter values ​​to obtain the target SQL statement containing the actual parameter values.

[0087] Optionally, the replay system can identify all bind variable identifiers from the SQL statement through syntax matching, recording their type, location, name, and quantity. Based on the type of the bind variable identifier, the corresponding parameter value is extracted from the parameters field of the log, establishing a mapping relationship between bind variable identifiers and parameter values.

[0088] Optionally, the replay system can query the mapping relationship between bind variable identifiers and parameter values, replace the bind variable identifiers with the corresponding parameter values, and perform SQL syntax escaping on the parameter values. For example, for string parameter values, single quotes are added for SQL syntax escaping, and null parameter values ​​are escaped to unquoted null values ​​(NILL) using SQL syntax escaping. After the replacement is complete, an executable target SQL statement containing the actual parameter values ​​is generated.

[0089] By parsing the SQL statements in the target database logs using the above method to identify bind variable identifiers, and extracting the parameter values ​​corresponding to these bind variable identifiers from the target database logs, we can ensure that SQL statements with different parameter values ​​can be correctly distinguished, thus improving playback efficiency. Replacing the bind variable identifier with the parameter value yields the target SQL statement containing the actual parameter values, improving the reliability of the test results.

[0090] S103, Organize the target SQL statement to obtain an executable SQL file.

[0091] As one possible implementation, the playback system can perform deduplication, semicolon padding, special character replacement, or encoding conversion on the target SQL statement, or perform deduplication, semicolon padding, special character replacement, and encoding conversion on the target SQL statement to obtain the executable SQL file.

[0092] Optionally, the replay system can utilize the hash value or normalized string of the stored statements to identify and remove duplicate SQL statements while preserving the execution order of the SQL statements. The replay system can check for semicolons at the end of SQL statements, remove extra spaces or newlines, and add semicolons if none are present. The replay system can convert full-width characters to half-width characters and remove invisible characters. Furthermore, the replay system can detect the original encoding of the statements and convert it to the target encoding.

[0093] Optionally, the playback system can write the preprocessed SQL statements sequentially into a text file, add necessary header comments, and generate a uniformly encoded and syntactically compliant SQL file. For example, the header comments can include execution instructions and generation time.

[0094] By using the methods described above, the target SQL statement can be deduplicated, semicolons can be added, special characters can be replaced, or encoding can be converted. Alternatively, the target SQL statement can be deduplicated, semicolons can be added, special characters can be replaced, and encoding can be converted to obtain the executable SQL file, thereby improving the reliability of execution.

[0095] S104, Replay the test environment based on this SQL file.

[0096] Optionally, the replay system can be configured with a test environment database version consistent with the production environment, synchronizing the table structure, indexes, and stored procedures of the production environment, importing historical data from the production environment into the test environment, and synchronizing the database configuration of the production environment.

[0097] Optionally, the replay system can read the SQL file line by line and execute it one by one using a database command-line tool, or it can use a thread pool to concurrently replay the test environment according to the execution timestamps of the SQL statements in the SQL file.

[0098] Optionally, the replay system can retain transaction statements in the SQL file. For Data Definition Language (DDL), it is necessary to confirm whether the test environment allows execution and to back up the table structure in advance.

[0099] Optionally, the replay system can also obtain the sequence number of the executed SQL statements, the execution information of the SQL statements, error information, and system metrics, and record the above information in the replay log file. After replay is complete, it verifies whether all SQL statements were executed successfully, and compares whether the key table data in the test environment and the production environment are consistent, generating a replay report. For example, the replay report may include basic replay information, execution statistics, performance data, and data consistency verification results.

[0100] In this embodiment, the target database log is obtained, laying the foundation for subsequent operations. If the target database log contains a Structured Query Language (SQL) statement with bound variables, replacing the bound variables in the SQL statement with the corresponding parameter values ​​from the database log yields a semantically complete target SQL statement, improving processing accuracy and efficiency. Further refining this target SQL statement yields an executable SQL file, enhancing its executability. Using this SQL file for test environment replay improves replay efficiency and the reliability of test results.

[0101] As one possible implementation, after obtaining the target database logs, the playback system can perform a logical backup and restore operation to generate a logical backup and restore file. Then, this logical backup and restore file is used on the test system to perform a database restore operation. Finally, the SQL file is run on the test system to obtain the execution results.

[0102] Optionally, the playback system can extract the execution timestamps of all SQL statements from the target database logs, using the earliest timestamp as the backup time point. If no timestamps are found in the target database logs, the start time of the target business cycle in the production database is selected as the backup time point. Backup commands are executed via a script file to generate a logical backup restore file.

[0103] Optionally, the replay system can clear the original data in the target database of the test system, import the generated logical backup and restore file into the test system's database using native tools or programmatic methods, and perform a database restoration operation. After the test database restoration is complete, the replay system can run the aforementioned SQL file on the test system, record and analyze the execution results.

[0104] After obtaining the target database logs using the above method, a logical backup and restore operation is performed to generate a logical backup and restore file, improving the accuracy of SQL replay results. This logical backup and restore file is then used to perform database restoration operations on the test system. Running the SQL file on this test system yields execution results, reducing manual intervention and improving replay efficiency.

[0105] Figure 2 This is a flowchart illustrating another database test scenario replay method provided in this application. Figure 2 As shown, the method includes:

[0106] (1) Starting from “Start”, the input source is “database system log file”, and subsequent operations revolve around this log file.

[0107] (2) Log file verification: Verify the input log file. If the verification result is "no", the process ends directly; if the result is "yes", proceed to subsequent processing.

[0108] (3) Data object filtering: For logs that have passed the verification, filter the data objects contained therein.

[0109] (4) Filter by keyword: Based on preset keywords, further filter the content after filtering.

[0110] (5) Block statement judgment: Determine whether the current content is a block statement:

[0111] If so, execute the "identifier block statement" operation;

[0112] If not, proceed to the "whether it is a bind variable statement" check.

[0113] (6) Checking for bound variable statements: Determine if the content is a bound variable statement:

[0114] If so, execute "parameter replacement";

[0115] If not, proceed directly to "Extract SQL Statement".

[0116] (7) SQL processing and output: After extracting the SQL statement, perform the "deduplication" and "statement optimization" operations in sequence, "generate SQL file", and the process "ends".

[0117] Optionally, the input preparation phase may include:

[0118] (1) The database system enables full log collection configuration and executes business operations to generate a full log file in comma-separated values ​​(CSV) format.

[0119] (2) The database system performs a logical backup and restore operation to generate a logical backup and restore file.

[0120] Optionally, the log processing phase may include:

[0121] (1) Perform preliminary filtering of log files based on input, such as database mode, database name, or username.

[0122] (2) Extract the SQL statement based on the key fields “statement” and “execute” in the log file.

[0123] (3) Combine the key field "parameters" in the log file to replace the extracted SQL statement bind variables with the actual input values.

[0124] (4) Optimize the generated SQL statements by removing duplicates, adding semicolons, replacing special symbols, and converting encoding.

[0125] (5) Generate an SQL format file.

[0126] Optionally, the playback evaluation phase may include:

[0127] (1) Perform database restoration operation on the test system using the logical backup and restore file generated during the preparation phase.

[0128] (2) Run the generated SQL file on the test system and analyze the execution results.

[0129] The above are the method embodiments provided in this application. The apparatus provided in this application will be described below.

[0130] Figure 3 A schematic diagram of a database test scenario playback device provided in this application is shown below. Figure 3 As shown, the database test scenario playback device 300 provided in this embodiment includes: an acquisition module 301, a replacement module 302, an organization module 303, and a playback module 304. Among them,

[0131] Module 301 is used to obtain the target database logs in the database.

[0132] Replacement module 302 is used to replace the bind variables in the structured query language SQL statement with the corresponding parameter values ​​in the database log when there is a structured query language SQL statement with bind variables in the target database log, so as to obtain a semantically complete target SQL statement.

[0133] The processing module 303 is used to process the target SQL statement to obtain an executable SQL file;

[0134] The playback module 304 is used to replay the test environment based on the SQL file.

[0135] Optionally, the acquisition module 301 is also used to acquire full log data in the database based on a test request; the test request includes the database schema, database name and / or username; the database schema refers to the logical structure of the object;

[0136] Based on the test request, the full log data was filtered to obtain the target database log;

[0137] The SQL statements in the target database logs are parsed, including:

[0138] The SQL statement is obtained by filtering the target database according to preset keywords.

[0139] Parse the SQL statement.

[0140] Optionally, the acquisition module 301 is also used to identify block statements in the SQL statement and add block statement identifiers before parsing the SQL statement;

[0141] Add a statement separator after the corresponding SQL statement in this block. This statement separator is a symbol used to separate independent SQL statements.

[0142] Optionally, the acquisition module 301 is also used to acquire the target database log in the database and then perform a logical backup and restore operation to generate a logical backup and restore file.

[0143] The test environment should be replayed based on this SQL file, including:

[0144] The logical backup and restore file was used to perform database restore operations on the test system.

[0145] Run the SQL file on the test system and obtain the execution results.

[0146] Optionally, the replacement module 302 is also used to parse the SQL statements in the target database log to identify bind variable identifiers;

[0147] Extract the parameter value corresponding to the bind variable identifier from the target database log;

[0148] Replace the bind variable identifier with the parameter value to obtain the target SQL statement containing the actual parameter value.

[0149] Optionally, the replacement module 302 is also used to replace the bind variables of the SQL statement with actual parameter values ​​in conjunction with the key field parameters in the target database log.

[0150] Optionally, the sorting module 303 is also used to deduplicatize, add semicolons, replace special characters and / or convert the encoding of the target SQL statement to obtain the executable SQL file.

[0151] This embodiment provides a database test scenario playback device that can execute the methods provided in any of the above method embodiments. The implementation principle and technical effect are similar, and will not be described in detail here.

[0152] Figure 4 This is a schematic diagram of the structure of an electronic device provided in this application. Figure 4 As shown, the electronic device 400 provided in this embodiment includes at least one processor 401 and a memory 402. Optionally, the device 400 further includes a communication component 403. The processor 401, memory 402, and communication component 403 are connected via a bus 404.

[0153] In a specific implementation, at least one processor 401 executes computer execution instructions stored in memory 402, causing at least one processor 401 to perform the above-described method.

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

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

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

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

[0158] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the above-described method.

[0159] This application also provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, implement the above-described method.

[0160] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, as some steps may be performed in other orders or simultaneously according to this application. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are all optional embodiments, and the actions and modules involved are not necessarily essential to this application.

[0161] It should be further noted that although the steps in the flowchart are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowchart may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these sub-steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the sub-steps or stages of other steps.

[0162] It should be understood that the above-described device embodiments are merely illustrative, and the device of this application can also be implemented in other ways. For example, the division of units / modules in the above embodiments is only a logical functional division, and there may be other division methods in actual implementation. For example, multiple units, modules, or components may be combined, or integrated into another system, or some features may be ignored or not executed.

[0163] Furthermore, unless otherwise specified, the functional units / modules in the various embodiments of this application can be integrated into one unit / module, or each unit / module can exist physically separately, or two or more units / modules can be integrated together. The integrated units / modules described above can be implemented in hardware or as software program modules.

[0164] When integrated units / modules are implemented in hardware, the hardware can be digital circuits, analog circuits, etc. The physical implementation of the hardware structure includes, but is not limited to, transistors, memristors, etc. Unless otherwise specified, the processor can be any suitable hardware processor, such as a CPU, GPU, FPGA, DSP, and ASIC, etc. Unless otherwise specified, the storage unit can be any suitable magnetic or magneto-optical storage medium, such as Resistive Random Access Memory (RRAM), Dynamic Random Access Memory (DRAM), Static Random Access Memory (SRAM), Enhanced Dynamic Random Access Memory (EDRAM), High-Bandwidth Memory (HBM), Hybrid Memory Cube (HMC), etc.

[0165] If the integrated unit / module is implemented as a software program module and sold or used as an independent product, it can be stored in a computer-readable storage device (CMD). Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a memory 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 memory includes various media capable of storing program code, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard drive, magnetic disk, or optical disk.

[0166] In the above embodiments, the descriptions of each embodiment have their own emphasis. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments. The technical features of the above embodiments can be combined arbitrarily. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as the combination of these technical features does not contradict each other, it should be considered within the scope of this specification.

[0167] Other embodiments of this application will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of this application that follow the general principles of this application and include common knowledge or customary techniques in the art not disclosed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of this application are indicated by the following claims.

[0168] It should be understood that this application is not limited to the precise structure described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this application is limited only by the appended claims.

Claims

1. A method for replaying database test scenarios, characterized in that, The method includes: Obtain the target database logs from the database; If a Structured Query Language (SQL) statement with bound variables exists in the target database log, the bound variables in the SQL statement are replaced with the corresponding parameter values ​​in the database log to obtain a semantically complete target SQL statement. The target SQL statement is processed to obtain an executable SQL file; Replay the test environment based on the SQL file.

2. The method according to claim 1, characterized in that, If a Structured Query Language (SQL) statement with bound variables exists in the target database log, the bound variables in the SQL statement are replaced with the corresponding parameter values ​​in the database log to obtain a semantically complete target SQL statement, including: Parse the SQL statements in the target database logs to identify bind variable identifiers; Extract the parameter value corresponding to the bind variable identifier from the target database log; The bind variable identifier is replaced with the parameter value to obtain the target SQL statement containing the actual parameter value.

3. The method according to claim 1, characterized in that, The step of obtaining the target database logs in the database includes: The test request retrieves the full log data from the database; the test request includes the database schema, database name, and / or username; the database schema refers to the logical structure of the object. The full log data is filtered according to the test request to obtain the target database log; The parsing of SQL statements in the target database log includes: The SQL statement is obtained by filtering the target database according to preset keywords; Parse the SQL statement.

4. The method according to claim 3, characterized in that, Before parsing the SQL statement, the process also includes: Identify block statements within the SQL statement and add block statement identifiers; Add a statement separator after the SQL statement corresponding to the block statement identifier. The statement separator is a symbol used to separate independent SQL statements.

5. The method according to any one of claims 1-4, characterized in that, The step of organizing the target SQL statement to obtain an executable SQL file includes: The target SQL statement is deduplicated, semicolons are added, special characters are replaced, and / or encoding is converted to obtain the executable SQL file.

6. The method according to any one of claims 1-4, characterized in that, After obtaining the target database logs from the database, the process further includes: Perform a logical backup and restore operation to generate a logical backup and restore file; The replay of the test environment based on the SQL file includes: The database restoration operation was performed on the test system using the aforementioned logical backup and restore file. The SQL file was run on the test system to obtain the execution results.

7. The method according to any one of claims 1-4, characterized in that, The step of replacing the bind variable in the SQL statement with the corresponding parameter value in the database log includes: By combining the key field 'parameters' in the target database log, the bind variables of the SQL statement are replaced with actual parameter values.

8. A database test scenario playback device, comprising: The acquisition module is used to acquire the target database logs in the database; The replacement module is used to replace the bound variables in the structured query language SQL statement with the corresponding parameter values ​​in the database log when there is a structured query language SQL statement with bound variables in the target database log, so as to obtain a semantically complete target SQL statement. The processing module is used to process the target SQL statement to obtain an executable SQL file; The replay module is used to replay the test environment based on the SQL file.

9. An electronic device, characterized in that, include: A processor, and a memory communicatively connected to the processor; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory to implement the method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, are used to implement the method as described in any one of claims 1 to 7.

11. A computer program product, characterized in that, Includes a computer program that, when executed by a processor, implements the method of any one of claims 1 to 7.

Images