Abnormal statement determination method and device, equipment and computer readable storage medium

Abstract

The application provides a method, device and equipment for determining an abnormal statement, and a computer readable storage medium. The method comprises: when a test data collection instruction is acquired, at least one historical test statement and at least one historical performance parameter are acquired from a function test log of an application in response to the test data collection instruction; one or more candidate abnormal statements are screened from the at least one historical test statement based on the at least one historical performance parameter; an execution process of the one or more candidate abnormal statements is analyzed to obtain one or more analysis results corresponding to the one or more candidate abnormal statements; and a target abnormal statement is screened from the one or more candidate abnormal statements according to the one or more analysis results. The application can improve the efficiency of determining an abnormal statement of a database.

Description

Technical Field

[0001] This application relates to database technology, and more particularly to a method, apparatus, device, and computer-readable storage medium for determining abnormal statements. Background Technology

[0002] Before being deployed, application software must undergo functional testing, stress testing, and other tests to ensure it functions correctly. Currently, an increasing number of applications require a database to store the various data generated during operation. However, database anomalies can occur during application operation, potentially caused by the use of inappropriate database statements.

[0003] In related technologies, database security and maintenance are mainly achieved through operation and maintenance monitoring after the application software goes live. In the early testing phase, less attention is paid to the database, making it difficult to expose database problems in advance, which ultimately leads to low efficiency in identifying abnormal statements in the database. Summary of the Invention

[0004] This application provides a method, apparatus, device, and computer-readable storage medium for determining abnormal statements, which can improve the efficiency of determining abnormal statements in a database.

[0005] The technical solution of this application embodiment is implemented as follows:

[0006] This application provides a method for determining abnormal statements, including:

[0007] When a test data collection instruction is received, in response to the test data collection instruction, at least one historical test statement and at least one historical performance parameter are obtained from the application's functional test log.

[0008] Wherein, the at least one historical test statement is a database statement used when performing functional testing on the application, and the at least one historical performance parameter is a database performance parameter when executing the at least one historical test statement;

[0009] Based on the at least one historical performance parameter, one or more candidate abnormal statements are selected from the at least one historical test statement;

[0010] The execution process of the one or more candidate exception statements is analyzed to obtain one or more analysis results corresponding one-to-one with the one or more candidate exception statements;

[0011] Based on the one or more analysis results, the target abnormal statement is selected from the one or more candidate abnormal statements.

[0012] In some embodiments of this application, after performing performance stress tests on the database using the stress test statements and the stress test data to obtain stress test results, the method further includes:

[0013] Obtain functional test monitoring data and stress test monitoring data;

[0014] The functional test monitoring data represents the execution details of at least one historical test statement when performing functional tests on the application; the stress test monitoring data represents the execution details of the stress test statement when performing performance stress tests on the database.

[0015] Based on the functional test monitoring data and the stress test monitoring data, test execution information is generated in the database.

[0016] This application provides an abnormal statement determination device, including:

[0017] The data acquisition module is used to, upon receiving a test data collection instruction, in response to the test data collection instruction, acquire at least one historical test statement and at least one historical performance parameter from the application's functional test log; wherein, the at least one historical test statement is a database statement used when performing functional testing on the application, and the at least one historical performance parameter is a database performance parameter when executing the at least one historical test statement;

[0018] The statement filtering module is used to filter one or more candidate abnormal statements from the at least one historical test statements based on the at least one historical performance parameter; and to filter the target abnormal statement from the one or more candidate abnormal statements based on the one or more analysis results.

[0019] The results analysis module is used to analyze the execution process of the one or more candidate exception statements and obtain one or more analysis results corresponding to the one or more candidate exception statements.

[0020] In some embodiments of this application, the abnormal statement determination device further includes: a stress testing module;

[0021] The stress testing module is used to generate stress testing statements for the database; generate stress testing data according to the structure of the data tables in the database; perform performance stress testing on the database using the stress testing statements and the stress testing data to obtain stress testing results; and determine supplementary abnormal statements from the at least one historical test statement based on the stress testing results and the target abnormal statement.

[0022] In some embodiments of this application, the at least one historical performance parameter is at least one processing time; the statement filtering module is further configured to select a preset number of processing times from the at least one processing time in descending order as abnormal processing times; and to select historical test statements corresponding to the abnormal processing times from the at least one historical test statements to obtain the one or more candidate abnormal statements.

[0023] In some embodiments of this application, the result analysis module is further configured to analyze the index usage of each candidate abnormal statement among the one or more candidate abnormal statements to obtain the index usage result of each candidate abnormal statement; the index usage result indicates whether each candidate abnormal statement uses an index; analyze the data table scan of each candidate abnormal statement to obtain the data table scan result of each candidate abnormal statement; the data table scan result indicates whether each candidate abnormal statement has undergone a full table scan; use the index usage result and the data table scan result to compose the analysis result corresponding to each candidate abnormal statement; when the analysis result is determined for all one or more candidate abnormal statements, the one or more analysis results corresponding one-to-one with the one or more candidate abnormal statements are obtained.

[0024] In some embodiments of this application, the data acquisition module is used to extract all historical statements and all historical parameters corresponding to the all historical statements from the functional test log of the application; wherein, the all historical statements are all statements used during the functional test; the database statements in the all historical statements are selected to obtain at least one historical test statement; and at least one historical performance parameter corresponding to the at least one historical test statement is selected from the all historical parameters.

[0025] In some embodiments of this application, the stress testing module is further configured to use a preset database statement as the stress testing statement of the database; or, use the target abnormal statement as the stress testing statement of the database; or, use at least one of the database statement that appears most frequently within a preset time and the database statement with the largest request traffic within the preset time as the stress testing statement of the database.

[0026] In some embodiments of this application, the stress testing module is further configured to parse the structure of the data table in the database to obtain at least one data type contained in the data table, and generate the stress test data based on the at least one data type; or, to obtain the online data corresponding to the data table and filter the online data to obtain the stress test data.

[0027] In some embodiments of this application, the abnormal statement determination device further includes: an execution information determination module;

[0028] The execution information determination module is used to acquire functional test monitoring data and stress test monitoring data; wherein, the functional test monitoring data represents the execution details of at least one historical test statement when performing functional testing on the application; the stress test monitoring data represents the execution details of the stress test statement when performing performance stress testing on the database; and test execution information of the database is generated based on the functional test monitoring data and the stress test monitoring data.

[0029] This application provides an abnormal statement determination device, including:

[0030] Memory, used to store executable exception statement determination instructions;

[0031] The processor, when executing executable exception statement determination instructions stored in the memory, implements the exception statement determination method provided in the embodiments of this application.

[0032] This application provides a computer-readable storage medium storing executable exception statement determination instructions, which are used to implement the exception statement determination method provided in this application when the processor is executed.

[0033] The embodiments of this application have the following beneficial effects: The abnormal statement determination device can first use at least one historical performance parameter to preliminarily screen out one or more candidate abnormal statements that may have problems from at least one historical test statement. Then, it analyzes the execution process of one or more candidate abnormal statements one by one. By combining the analysis results of each candidate abnormal statement, that is, the detailed execution information of the database when it is executed, the target abnormal statement can be further screened out. In this way, based on the test records left during functional testing, the problems existing in the database can be quickly and accurately located before the application goes online, which greatly improves the efficiency of determining abnormal statements in the database. Attached Figure Description

[0034] Figure 1 This is an optional architecture diagram of the exception statement determination system 100 provided in this application embodiment;

[0035] Figure 2 This is provided by the embodiments of this application. Figure 1 The exception statements in the code determine the structural diagram of the device;

[0036] Figure 3 This is a flowchart illustrating the method for determining abnormal statements provided in the embodiments of this application. Figure 1 ;

[0037] Figure 4 This is a flowchart illustrating the method for determining abnormal statements provided in the embodiments of this application. Figure 2 ;

[0038] Figure 5 This is a flowchart illustrating the method for determining abnormal statements provided in the embodiments of this application. Figure 3 ;

[0039] Figure 6 This is a flowchart illustrating the method for determining abnormal statements provided in the embodiments of this application. Figure 4 ;

[0040] Figure 7 This is a process example diagram of database statements for analyzing anomalies in a business system provided in an embodiment of this application. Detailed Implementation

[0041] To make the objectives, technical solutions, and advantages of this application clearer, the application will be further described in detail below with reference to the accompanying drawings. The described embodiments should not be regarded as limitations on this application. All other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0042] In the following description, references are made to “some embodiments,” which describe a subset of all possible embodiments. However, it is understood that “some embodiments” may be the same subset or different subsets of all possible embodiments and may be combined with each other without conflict.

[0043] In the implementation of this application, the collection and processing of relevant data should strictly comply with the requirements of relevant laws and regulations, obtain the informed consent or separate consent of the personal information subject, and carry out subsequent data use and processing within the scope of laws and regulations and the authorization of the personal information subject.

[0044] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used herein is for the purpose of describing embodiments of this application only and is not intended to limit this application.

[0045] Before providing a further detailed description of the embodiments of this application, the nouns and terms involved in the embodiments of this application will be explained, and the nouns and terms involved in the embodiments of this application shall be interpreted as follows.

[0046] 1) Cloud technology refers to a managed technology that unifies a series of resources such as hardware, software, and networks within a wide area network or local area network to realize the computing, storage, processing, and sharing of data.

[0047] Cloud technology, based on the cloud computing business model, encompasses network technology, information technology, integration technology, management platform technology, and application technology. It can form resource pools, providing flexible and convenient on-demand access. Cloud computing technology will become a crucial support. Backend services of network systems require substantial computing and storage resources, such as video websites, image websites, and many portal websites. With the rapid development and application of the internet industry, every item may have its own identification mark in the future, requiring data to be transmitted to backend systems for logical processing. Different levels of data will be processed separately, and various industry data will require robust system support, which can only be achieved through cloud computing.

[0048] 2) A database, simply put, can be viewed as an electronic filing cabinet, a place to store electronic files. Users can perform operations such as adding, querying, updating, and deleting data in the files. A "database" is a collection of data stored together in a certain way, which can be shared by multiple users, has the lowest possible redundancy, and is independent of application programs.

[0049] A Database Management System (DBMS) is a computer software system used to manage databases, typically possessing basic functions such as storage, retrieval, security, and backup. DBMSs can be categorized based on the database model they support, such as relational or Extensible Markup Language (XML); or by the type of computer they support, such as server clusters or mobile devices; or by the query language used, such as Structured Query Language (SQL); or by performance priorities, such as maximum scale or highest operating speed; or other classification methods. Regardless of the classification method used, some DBMSs can cross categories, for example, simultaneously supporting multiple query languages.

[0050] 3) Abnormal statements are database statements that, during testing or actual online operation, cause a significant degrade in database performance, prevent the database from performing normal functions, or enable the database to perform unauthorized operations. For example, a database statement that allows unauthorized reading or modification of user privacy data in the database is an abnormal statement.

[0051] 4) Functional testing can be understood as testing by simulating user operations to determine whether the application meets its corresponding design requirements. In other words, it is testing to ensure that the application runs in the expected way.

[0052] 5) Performance stress testing is used to test the maximum service level of the database corresponding to the application. Performance stress testing involves gradually increasing the load and testing the changes in performance to determine under what load performance will fail.

[0053] 6) Indexes are used to speed up the process of searching or sorting data in a database table. Using an index allows for quick access to specific information in the database. For example, to query the data of a user with an ID of 100, you would need to traverse the table until the row with ID 100 is found, which would inevitably take a lot of time. However, if an index has been created for that ID beforehand, the desired data can be found much faster.

[0054] 7) Full table scan refers to the process of scanning every single record in a database table. Full table scans are generally performed when querying data from a table without an index.

[0055] Before being launched, application software typically undergoes testing, such as functional testing and stress testing, to ensure it functions as intended. Currently, an increasing number of applications need to store user data, leading to the widespread adoption of databases to store various data generated during application operation, such as online shopping records and chat logs, for user retrieval. However, database anomalies can occur during application operation, such as data read / write errors or inability to retrieve data. These anomalies are likely caused by the use of inappropriate database statements during database design and construction.

[0056] In related technologies, database quality assurance and maintenance are mainly focused on post-application software deployment through operational monitoring. During typical early testing phases, less attention is paid to the database, making it difficult to expose database problems early on. This results in low efficiency in identifying database anomalies. However, after application software deployment, most problems and bottlenecks are related to the database; therefore, early detection of database issues is crucial.

[0057] Database exceptions are typically identified using pre-prepared test cases. However, writing database test cases is time-consuming, and the effectiveness of exposing exceptions is closely related to the quality of these manually written test cases. Therefore, manually writing test cases for database testing can lead to relatively low efficiency in identifying database exceptions.

[0058] This application provides a method, apparatus, device, and computer-readable storage medium for determining abnormal statements, which can improve the efficiency of determining abnormal statements in a database. The following describes an exemplary application of the abnormal statement determination device provided in this application. This device can be implemented as a terminal or a server. The server can be an independent physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN, and big data and artificial intelligence platforms. The terminal can be a smartphone, tablet, laptop, desktop computer, smart speaker, smartwatch, etc., but is not limited to these. The terminal and server can be directly or indirectly connected via wired or wireless communication, which is not limited herein. The following will describe an exemplary application of the abnormal statement determination device.

[0059] See Figure 1 , Figure 1 This is an optional architecture diagram of the abnormal statement determination system 100 provided in this application embodiment. To support an abnormal statement determination application, the terminal 400 is equipped with an application awaiting testing and is configured with a database 500 corresponding to the application. The database 500 provides data services to the terminal 400. The terminal 400 is connected to the abnormal statement determination device 200 through a network 300, which can be a wide area network (WAN), a local area network (LAN), or a combination of both.

[0060] When the exception statement determination device 200 receives a test data collection instruction, it responds by retrieving the functional test logs corresponding to the application mounted on the terminal 400. Then, it retrieves at least one historical test statement and at least one historical performance parameter from the application's functional test logs. The at least one historical test statement is a database statement used during the functional testing of the application, and the at least one historical performance parameter is the performance parameter of the database 500 when executing the at least one historical test statement. Based on the at least one historical performance parameter, the exception statement determination device 200 filters one or more candidate exception statements from the at least one historical test statement. It then analyzes the execution process of the one or more candidate exception statements to obtain one or more analysis results corresponding one-to-one with the one or more candidate exception statements. Afterward, based on the one or more analysis results, the exception statement determination device 200 filters the target exception statement from the one or more candidate exception statements, thereby completing the exception statement determination process.

[0061] Furthermore, after identifying the target abnormal statement, the abnormal statement device 200 can modify the target abnormal statement to obtain the latest version of the application, thereby improving the performance of the application installed in the terminal 400.

[0062] See Figure 2 , Figure 2 This is provided by the embodiments of this application. Figure 1 The abnormal statements in the code determine the structural diagram of the device. Figure 2 The exception statement determination device 200 shown includes at least one processor 210, a memory 250, at least one network interface 220, and a user interface 230. The various components in the exception statement determination device 200 are coupled together via a bus system 240. It is understood that the bus system 240 is used to implement communication between these components. In addition to a data bus, the bus system 240 also includes a power bus, a control bus, and a status signal bus. However, for clarity, in... Figure 2 The general labeled all buses as Bus System 240.

[0063] Processor 210 can be an integrated circuit chip with signal processing capabilities, such as a general-purpose processor, a digital signal processor (DSP), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. Among them, the general-purpose processor can be a microprocessor or any conventional processor, etc.

[0064] User interface 230 includes one or more output devices 231 that enable the presentation of media content, including one or more speakers and / or one or more visual displays. User interface 230 also includes one or more input devices 232, including user interface components that facilitate user input, such as a keyboard, mouse, microphone, touch screen display, camera, other input buttons and controls.

[0065] The memory 250 may be removable, non-removable, or a combination thereof. Exemplary hardware devices include solid-state storage, hard disk drives, optical disk drives, etc. The memory 250 may optionally include one or more storage devices physically located away from the processor 210.

[0066] The memory 250 may include volatile memory or non-volatile memory, or both. The non-volatile memory may be read-only memory (ROM), and the volatile memory may be random access memory (RAM). The memory 250 described in this application embodiment is intended to include any suitable type of memory.

[0067] In some embodiments, memory 250 is capable of storing data to support various operations, examples of which include programs, modules, and data structures or subsets or supersets thereof, as illustrated below.

[0068] Operating system 251 includes system programs for handling various basic system services and performing hardware-related tasks, such as the framework layer, core library layer, driver layer, etc., for implementing various basic business functions and handling hardware-based tasks;

[0069] The network communication module 252 is used to reach other computing devices via one or more (wired or wireless) network interfaces 220, such as Bluetooth, Wi-Fi, and Universal Serial Bus (USB).

[0070] Presentation module 253 is configured to enable the presentation of information (e.g., a user interface for operating peripheral devices and displaying content and information) via one or more output devices 231 associated with user interface 230 (e.g., a display screen, a speaker, etc.).

[0071] The input processing module 254 is used to detect and translate one or more user inputs or interactions from one or more input devices 232.

[0072] In some embodiments, the abnormal statement determination device provided in this application can be implemented in software. Figure 2 An abnormal statement determination device 255 stored in memory 250 is shown. It can be software in the form of programs and plug-ins, including the following software modules: data acquisition module 2551, statement filtering module 2552, result analysis module 2553, stress testing module 2554, and execution information determination module 2555. These modules are logically related and can therefore be arbitrarily combined or further split according to the functions they implement.

[0073] The functions of each module will be explained below.

[0074] In other embodiments, the abnormal statement determination device provided in this application can be implemented in hardware. As an example, the abnormal statement determination device provided in this application can be a processor in the form of a hardware decoding processor, which is programmed to execute the abnormal statement determination method provided in this application. For example, the processor in the form of a hardware decoding processor can be one or more application-specific integrated circuits (ASICs), DSPs, programmable logic devices (PLDs), complex programmable logic devices (CPLDs), field-programmable gate arrays (FPGAs), or other electronic components.

[0075] For example, an embodiment of this application provides an abnormal statement determination device, including:

[0076] Memory, used to store executable exception statement determination instructions;

[0077] The processor, when executing executable exception statement determination instructions stored in the memory, implements the exception statement determination method provided in the embodiments of this application.

[0078] The exemplary application and implementation of the abnormal statement determination device provided in the embodiments of this application will be used to illustrate the method for determining abnormal statements provided in the embodiments of this application. It should be noted that the embodiments in this application can be implemented with the aid of cloud technology.

[0079] See Figure 3 , Figure 3 This is a flowchart illustrating the method for determining abnormal statements provided in the embodiments of this application. Figure 1 , will combine Figure 3 The steps shown are explained.

[0080] S101. When a test data collection instruction is received, in response to the test data collection instruction, at least one historical test statement and at least one historical performance parameter are obtained from the application's functional test log.

[0081] This application embodiment is implemented in a scenario where abnormal statements are identified from various database statements used to implement functions. Specifically, it utilizes historical test records retained from functional testing of the application to analyze abnormal database statements. This allows for the early analysis of database problems before application deployment, improving the efficiency of identifying abnormal statements and reducing resource investment in database testing and maintenance. In this embodiment, the abnormal statement identification process is triggered by a test data collection command. Therefore, the abnormal statement identification device monitors whether a test data collection command has been received. When the device receives a test data collection command, it initiates the abnormal statement identification process, simultaneously responding to the command by extracting the application's daily functional test logs. Then, it extracts at least one historical test statement and at least one historical performance parameter corresponding to that historical test statement from the functional test logs.

[0082] Understandably, database statements are inevitably used during functional testing of applications. This is because most current application software relies on database support to implement its designed functions, such as data storage and retrieval. These functions all utilize corresponding database statements. When performing functional testing, application testing equipment records all statements used to perform the tests, along with the application's and its corresponding database's performance parameters, resulting in a functional test log. Therefore, the exception statement identification device can extract the statements used during functional testing from this log. These statements include database statements, which the device then extracts as historical test statements. In other words, at least one historical test statement must be a database statement used during the application's functional testing.

[0083] Similarly, the device for identifying abnormal statements can extract the application's performance parameters and the corresponding database's performance parameters from the functional test logs. Then, from these extracted performance parameters, it can further filter out the database performance parameters used during the execution of the functional tests, and use these filtered performance parameters as historical performance parameters. In other words, at least one historical performance parameter corresponds to the database performance parameters used when at least one historical test statement was executed, thus ensuring a one-to-one correspondence between at least one historical performance parameter and at least one historical test statement.

[0084] In some embodiments of this application, the test data collection instruction can be triggered by test personnel. For example, when routine functional testing is completed, test personnel can trigger the test data collection instruction by interacting with the exception statement determination device. The test data collection instruction can also be triggered periodically. For example, at a set time, the exception statement determination device automatically generates a test data collection instruction, thereby initiating the exception statement determination process. Of course, the test data collection instruction can also be sent by other control devices, such as sending a test data collection instruction to the exception statement determination device via a remote control terminal to initiate the exception statement determination process.

[0085] In some embodiments of this application, the application's testing device can be the exception statement identification device itself. That is, the exception statement identification device performs routine functional tests and also analyzes the database for exception statements based on historical test records from these routine functional tests. Of course, the application's testing device can also be another device. For example, the application's testing device can be a terminal, and the exception statement identification device can be a server. The terminal generates functional test logs during routine functional tests and then sends these logs to the server. The server analyzes the historical test records in the functional test logs to identify the database for exception statements.

[0086] In some embodiments of this application, the application's functional test logs may be recorded by the application's logging module, and the application's functions may be implemented by the application's service management module.

[0087] S102. Based on at least one historical performance parameter, select one or more candidate exception statements from at least one historical test statement.

[0088] After obtaining at least one historical test statement and at least one historical performance parameter, the anomaly statement identification device first reads each of the at least one historical performance parameter to determine the database performance during the execution of each historical test statement. Next, the device selects one or more historical performance parameters from the at least one historical performance parameter that indicate database anomalies. Then, based on the one-to-one correspondence between the at least one historical performance parameter and the at least one historical test statement, it selects historical test statements from the at least one historical test statement that correspond to the one or more historical performance parameters indicating database anomalies, thus obtaining one or more candidate anomaly statements.

[0089] Understandably, database problems can often be determined through performance parameters. For example, excessively long query times might indicate the use of inappropriate database statements, leading to flawed database design. Therefore, anomaly detection devices can initially use historical performance parameters that characterize database anomalies to filter out candidate anomaly statements from at least one historical test statement. These candidate statements may actually be the cause of the database problem, or they may be incorrectly identified as normal statements. The anomaly detection device then needs to further analyze these candidate anomaly statements to pinpoint the true anomaly.

[0090] In some embodiments of this application, historical performance parameters can be processing time or hardware resources consumed, such as the amount of memory or computing resources consumed. Of course, historical performance parameters can also be set to other types of parameters as needed, and this application does not limit this.

[0091] In some embodiments of this application, the abnormal statement determination device can use a query tool to find abnormal historical performance parameters from at least one historical performance parameter, and then determine one or more candidate abnormal statements. For example, it can use a slow query analysis tool (pt-query-digest) to find abnormal historical performance parameters. The abnormal statement determination device can also use a custom code segment to find abnormal historical performance parameters from at least one historical performance parameter, and then determine one or more candidate abnormal statements. This embodiment of the application does not limit this.

[0092] It should be noted that, in some embodiments of this application, the abnormal statement determination device may first perform a compliance check on at least one historical test statement, that is, check whether there are any historical test statements that do not comply with specific industry standards or business standards among at least one historical test statement, remove the non-compliant historical test statements first, and then, based on the historical performance parameters corresponding to the removed non-compliant historical test statements, select one or more candidate abnormal statements from the removed non-compliant historical test statements.

[0093] S103. Analyze the execution process of one or more candidate exception statements to obtain one or more analysis results that correspond one-to-one with one or more candidate exception statements.

[0094] After identifying one or more candidate exception statements, the exception statement identification device begins to analyze the execution process of each candidate exception statement one by one. This analysis clarifies the detailed execution information of the database during the execution of each candidate exception statement, and the detailed database execution information corresponding to each candidate exception statement is used as the analysis result for that statement. Once the exception statement identification device has completed the analysis of the execution process of all candidate exception statements, it will obtain one or more analysis results. In other words, there is a one-to-one correspondence between the one or more analysis results and the one or more candidate exception statements.

[0095] It should be noted that the exception statement determination device can analyze the execution process of each candidate exception statement using database execution analysis tools, such as using the explain tool to analyze the detailed execution information of each candidate exception statement. Of course, the exception statement determination device can also use other methods, such as custom code snippets to analyze the detailed execution information of each candidate exception statement, etc., which are not limited in this embodiment.

[0096] The detailed execution information of the database may include information about the type of operation performed on the database, such as whether it is a query operation and what type of query operation it is; it may also include information about the indexes used during execution, such as whether an index was used, which index was used, and the byte length of the index used; it may also include data table scan information, such as which data table was scanned during execution, how many rows were scanned, and whether a full table scan was performed. Of course, the detailed execution information of the database may also include other types of information, which are not limited in this embodiment.

[0097] Based on this, in the analysis results corresponding to each candidate abnormal statement, one or more of the following information can be selected according to the actual situation: information on the type of operation on the database, information on the index used during execution, information on the scanning of the data table, and other types of information. This application embodiment does not limit this.

[0098] S104. Based on one or more analysis results, select the target abnormal statement from one or more candidate abnormal statements.

[0099] Since the analysis results are detailed execution information of the database corresponding to each candidate exception statement, and this detailed execution information indicates the database's operational status, combining the analysis results corresponding to each candidate exception statement clarifies how the database operated when executing the candidate exception statement. This allows for analysis of the historical test parameters that caused the exception, thus determining whether the candidate exception statement truly has a problem. When the exception statement identification device determines that a candidate exception statement truly has a problem, it selects that candidate exception statement as the target exception statement. In this way, the exception statement identification device can filter out the target exception statement that needs to be modified from one or more candidate exception statements. This enables the device to quickly and accurately locate the target exception statement based on the test records retained during daily functional testing, improving the efficiency of identifying database exception statements.

[0100] It should be noted that since the analysis results of each candidate abnormal statement can include one or more of the following: information about the type of database operation, information about the index used during execution, information about the data table scan, and other types of information, the process of filtering target abnormal statements based on the analysis results is actually based on the content contained in the analysis results.

[0101] Furthermore, in some embodiments of this application, when an analysis result includes information about the type of operation performed on the database, it can be determined whether the candidate exception statement corresponding to the analysis result is a target exception statement that needs to be modified subsequently, based on whether the operation was successfully completed or whether it timed out. For example, if a candidate exception statement performs a query operation on the database during execution, but the query operation always times out, then it can be clearly identified as a target exception statement. When an analysis result includes information about the index used during the execution of a candidate exception statement, it can be determined whether the candidate exception statement is a target exception statement based on whether an index was used during execution, or even based on the length of the index if an index was used. For example, if a candidate exception statement uses an index with a length exceeding the specified limit during execution, then it is confirmed that the candidate exception statement is a target exception statement. When an analysis result includes data table scan information during the execution of a candidate exception statement, it can be determined whether the candidate exception statement is a target exception statement based on whether a full table scan was performed. For example, if a candidate exception statement always requires frequent full table scans to obtain specific data during execution, then it can be assumed that a corresponding index needs to be created for that specific data, and consequently, the candidate exception statement needs to be modified.

[0102] When the analysis results include multiple information such as the type of database operation, index usage, and table scan information, the content included in the analysis results can be combined to jointly determine whether the corresponding candidate abnormal statement is the target abnormal statement. For example, it is possible to combine whether an index was used, whether a full table scan was performed, or whether an index was used, whether the query timed out, and whether a full table scan was performed to determine whether the candidate abnormal statement is the target abnormal statement.

[0103] In this embodiment, the abnormal statement determination device can first use at least one historical performance parameter to preliminarily screen out one or more candidate abnormal statements that may have problems from at least one historical test statement. Then, it analyzes the execution process of one or more candidate abnormal statements one by one. By combining the analysis results of each candidate abnormal statement, that is, the detailed execution information of the database when it is executed, the target abnormal statement can be further screened out. In this way, based on the test records left during functional testing, the problems existing in the database can be quickly and accurately located before the application goes online, which greatly improves the efficiency of determining abnormal statements in the database.

[0104] based on Figure 3 See Figure 4 , Figure 4 This is a flowchart illustrating the method for determining abnormal statements provided in the embodiments of this application. Figure 2 In some embodiments of this application, after selecting the target abnormal statement from one or more candidate abnormal statements based on one or more analysis results, i.e., after S104, the method further includes: S105-S108, as follows:

[0105] S105. Generate load testing statements for the database.

[0106] In addition to identifying the target abnormal statement from at least one historical test statement, the abnormal statement identification device can also identify supplementary abnormal statements through performance stress testing. This allows for the continued identification of statements requiring modification from at least one historical test statement from a stress testing perspective. This is because performance stress testing can uncover problems that are not apparent in routine functional testing environments. These problems may be caused by the previously identified target abnormal statement, or by other test statements in at least one historical test statement besides the target abnormal statement. The purpose of this application embodiment is to find the problems that are not apparent in routine functional testing environments from at least one historical test statement, and then distinguish whether these problems are caused by the target abnormal statement. Before performing performance stress testing on the database corresponding to the application, the abnormal statement identification device needs to generate statements for performance stress testing, i.e., generate stress testing statements, so that subsequent performance stress testing can be performed using these statements.

[0107] S106. Generate stress test data based on the structure of the data tables in the database.

[0108] In addition to generating load testing statements, the anomaly detection device also needs to generate data for performance stress testing, i.e., load testing data. At this point, the anomaly detection device first parses the data tables in the database to obtain the table structure, thereby identifying the data types present in the tables. Then, based on the data types in the tables, it automatically generates the load testing data.

[0109] It's important to note that the reason the anomaly detection device automatically generates load test data based on the data table structure is that during stress testing, the focus is more on database performance than the specific data itself. Furthermore, manually generating load test data is slow and inefficient, and for multi-table joins, manual construction is even more costly. The anomaly detection device automatically generates and constructs data based on data type, quickly obtaining a large amount of load test data, undoubtedly improving the efficiency of the overall performance stress test and thus the efficiency of identifying database anomalies. Simultaneously, because the load test data is automatically generated, it is not limited by the quality of test cases written by testers, accurately locating database problems and identifying anomalous database statements, thereby improving the efficiency of database statement identification.

[0110] S107. Use load testing statements and load testing data to perform performance stress tests on the database and obtain the stress test results.

[0111] After receiving the load test statement and load test data, the exception detection device will use the load test statement to operate on the load test data and record the database performance parameters during the operation as the stress test result. When the operation to be performed by the load test statement is a read operation, the exception detection device will write the load test data to the database; when the load test statement is a write operation, the exception detection device will read the load test data in the database (assuming that the database has been written with load test data beforehand).

[0112] In some embodiments of this application, the exception statement determination device can perform performance stress testing based on concurrency. In this case, performance stress test parameters can also be configured, such as performance stress test time, concurrency, etc.

[0113] S108. Based on the stress test results and the target abnormal statement, determine the supplementary abnormal statement from at least one historical test statement.

[0114] After receiving the stress test results, the anomaly detection device reads these results to determine the database's performance during the stress test. When the stress test results indicate abnormal database performance, the device selects the test statements used in conjunction with the stress test statements from at least one historical test statement. It then analyzes the execution process of these related test statements to determine if any of them caused the performance anomaly. Next, the device checks if these statements causing the performance anomaly contain a target anomaly statement. If a target anomaly statement is found, the remaining statements causing the performance anomaly, excluding the target anomaly statement, are designated as supplementary anomaly statements. If no target anomaly statement is found, all statements causing the performance anomaly are designated as supplementary anomaly statements.

[0115] In this embodiment, the abnormal statement determination device can first generate stress test statements and stress test data, then use these statements and data to perform performance stress tests on the database to discover problems that cannot be found in routine functional testing, obtaining stress test results. Finally, based on the stress test results, it selects statements that cause abnormal database performance from at least one historical test statement, thereby determining supplementary abnormal statements. In this way, the abnormal statement determination device can also determine supplementary abnormal statements in addition to the target abnormal statement based on performance stress testing, further improving the efficiency of determining abnormal statements in the database.

[0116] In some embodiments of this application, at least one historical performance parameter is at least one processing time. In this case, based on at least one historical performance parameter, one or more candidate abnormal statements are selected from at least one historical test statement. That is, the specific implementation process of S102 may include: S1021-S1022, as follows:

[0117] S1021. From at least one processing time, select a preset number of processing times in order of largest value as abnormal processing times.

[0118] When using at least one processing time as at least one historical performance parameter, the anomaly detection device can first sort the at least one processing time in descending order, thereby determining the order of each processing time among all processing times. Then, the anomaly detection device extracts a preset number of processing times in descending order and treats these extracted processing times as anomaly times.

[0119] It is understood that in this embodiment, the preset quantity can be set according to actual needs. For example, the preset quantity can be set to 1, 3, or 10. Therefore, the abnormal statement determination device will select one or more abnormal time-consuming statements.

[0120] S1022. From at least one historical test statement, select the historical test statement corresponding to the abnormal time consumption to obtain one or more candidate abnormal statements.

[0121] After identifying abnormal processing times, the abnormal statement identification device will, based on the correspondence between processing times and historical test statements, select the historical test statements corresponding to the abnormal processing times from at least one historical test statement as candidate abnormal statements. Since the abnormal statement identification device selects one or more abnormal processing times and selects corresponding candidate abnormal statements for each abnormal processing time, the abnormal statement identification device selects one or more candidate abnormal statements in total.

[0122] In this embodiment of the application, the abnormal statement determination device first selects the largest preset number of abnormal times from at least one processing time, and then determines one or more candidate abnormal statements corresponding to the preset number of abnormal times based on the correspondence between processing time and historical test statements, thereby realizing the process of determining one or more candidate abnormal statements based on at least one historical performance parameter.

[0123] See Figure 5 , Figure 5 This is a flowchart illustrating the method for determining abnormal statements provided in the embodiments of this application. Figure 3In some embodiments of this application, the execution process of one or more candidate exception statements is analyzed to obtain one or more analysis results corresponding one-to-one with the one or more candidate exception statements, i.e., the specific implementation process of S103, which may include: S1031-S1034, as follows:

[0124] S1031. Analyze the index usage of each candidate exception statement in one or more candidate exception statements to obtain the index usage result of each candidate exception statement.

[0125] When analyzing the execution process of one or more candidate exception statements, the exception statement determination device first analyzes the index usage of each candidate exception statement to determine whether the index was used during execution. The result of this determination is the index usage result. In other words, the index usage result indicates whether each candidate exception statement used an index.

[0126] In some embodiments of this application, the exception statement determination device can also analyze the index used when the candidate exception statement is executed, such as the byte length of the index used and the operation time when the index is used. This application does not limit this.

[0127] S1032. Analyze the data table scan of each candidate abnormal statement to obtain the data table scan result of each candidate abnormal statement.

[0128] The abnormal statement identification device also analyzes and judges the data table scan situation during the execution of each candidate abnormal statement, thereby determining whether a full table scan was performed during the execution of each candidate abnormal statement. The judgment result obtained is the data table scan result. In other words, the data table scan result indicates whether a full table scan was performed for each candidate abnormal statement.

[0129] In some embodiments of this application, the abnormal statement determination device can further analyze the situation when a full table scan is used during the execution of a candidate abnormal statement. For example, it can analyze the time taken by the full table scan and which data table in the database was scanned. This application does not limit this.

[0130] S1033. Using the index usage results and data table scan results, construct the analysis results corresponding to each candidate abnormal statement.

[0131] S1034. When the analysis results are determined for one or more candidate exception statements, one or more analysis results corresponding one-to-one with one or more candidate exception statements are obtained.

[0132] After obtaining the index usage results and data table scan results for each candidate abnormal statement, the abnormal statement identification device integrates these results to obtain the analysis result for each candidate abnormal statement. Once the abnormal statement identification device has determined the corresponding analysis results for all candidate abnormal statements, it can obtain one or more analysis results corresponding to one or more candidate abnormal statements.

[0133] In this embodiment, the abnormal statement determination device analyzes the index usage and data table scanning of each candidate abnormal statement one by one, obtaining the index usage result and data table scanning result corresponding to each candidate abnormal statement. The index usage result and data table scanning result are then combined to form the analysis result. When the above operation is performed on all candidate abnormal statements, one or more analysis results are obtained. Thus, the abnormal statement determination device realizes the analysis of the execution process of one or more candidate abnormal statements.

[0134] In some embodiments of this application, obtaining at least one historical test statement and at least one historical performance parameter from the application's functional test log, i.e., the specific implementation process of S101, may include: S1011-S1013, as follows:

[0135] S1011. Extract all historical statements and corresponding historical parameters from the application's functional test logs.

[0136] In this embodiment, the abnormal statement determination device first parses the functional test logs of the application, extracting all historical statements used during testing to obtain a complete set of test statements. In other words, the complete set of historical statements comprises all statements used during functional testing. Next, the abnormal statement determination device extracts the performance parameters corresponding to all statements in the complete set of historical statements to obtain a complete set of historical parameters.

[0137] S1012. Select database statements from the full set of historical statements to obtain at least one historical test statement.

[0138] After obtaining the full set of historical statements, the exception statement identification device determines whether each statement belongs to the database or other non-database categories, thus classifying each statement. Next, the device selects the database statements as test statements. Since more than one database statement may be used in the full set of historical statements, the device will obtain at least one test statement.

[0139] In some embodiments of this application, after selecting historical statements belonging to database statements, the abnormal statement determination device can also clean these historical statements, remove duplicate and invalid statements, and obtain cleaned statements. The cleaned statements are then used as historical test statements to obtain at least one historical test statement.

[0140] S1013. Select at least one historical performance parameter from the full set of historical parameters that corresponds to at least one historical test statement.

[0141] After identifying at least one historical test statement, the anomaly statement determination device selects the corresponding historical performance parameter from the entire set of historical parameters, based on the correspondence between the historical test statements and historical performance parameters. Once the historical performance parameter has been selected for each historical test statement, the anomaly statement determination device obtains at least one historical performance parameter.

[0142] In this embodiment, the abnormal statement determination device can filter out at least one historical test statement from the full set of historical statements recorded in the functional test log, and then, based on the relationship between the historical test statement and historical performance parameters, filter out at least one historical performance parameter from the full set of performance parameters recorded in the functional test log. In this way, the abnormal statement determination device obtains at least one historical test statement and at least one historical performance parameter.

[0143] In some embodiments of this application, the specific implementation process of generating load testing statements for the database, i.e., S105, may include any one of S1051-S1053, as follows:

[0144] S1051. Use the pre-defined database statements as the database load test statements.

[0145] When the device generates load testing statements for the database, it can directly obtain a preset database statement and use it as the load testing statement. This allows the device to specify the scenario that needs to be tested and perform the test on that scenario.

[0146] It is understood that in the embodiments of this application, the preset database statements can be set according to actual needs. For example, when it is necessary to test the data reading process of the database, the preset database statements can be data reading statements; when it is necessary to test the data writing process of the database, the preset database statements can be data writing statements.

[0147] S1052. Use the target exception statement as the database load test statement.

[0148] The exception statement analysis tool can also directly use the analyzed target exception statements as load test statements, enabling focused analysis of these statements and further pinpointing the problems the database encounters when executing them. This allows for in-depth analysis of the target exception statements. In this way, it's possible to locate not only the problems caused during functional testing but also those caused during stress testing.

[0149] S1053. Select at least one of the database statements that appear most frequently within a preset time period and the database statements that have the highest request traffic within a preset time period as the database stress test statements.

[0150] In addition to using preset database statements and target abnormal statements as load testing statements, the abnormal statement identification device can also identify the most frequently occurring database statements and the database statements with the highest request traffic within a preset time period, and use either the most frequently occurring or the database statements with the highest request traffic within a preset time period as load testing statements. Alternatively, the device can simultaneously use both the most frequently occurring and the database statements with the highest request traffic within a preset time period as load testing statements; that is, the load testing statements include both the most frequently occurring and the database statements with the highest request traffic within a preset time period.

[0151] It's important to note that the anomaly detection device can identify the most frequently occurring database statements and the database statements with the highest request traffic within a preset timeframe during functional testing, as well as during trial operation or official operation. Regardless of the stage—functional testing, trial operation, or official operation—the most frequently occurring and highest-traffic database statements within a preset timeframe are crucial to the application's functionality. Therefore, using these database statements as load test statements can, to some extent, replicate user behavior when using the application, thus mimicking online user behavior and allowing for further identification of database issues based on that online behavior.

[0152] It is understood that the preset time can be set according to actual needs, such as setting the preset time to 1 day, 1 hour, or 1 month, etc., and this application embodiment does not limit it here.

[0153] In this embodiment, the abnormal statement determination device can identify the corresponding stress test statements for the database in three different ways, thereby enabling stress testing of the database in different scenarios and facilitating further identification of database problems.

[0154] In some embodiments of this application, the specific implementation process of generating stress test data according to the structure of the data tables in the database, i.e., S106, may include: S1061 or S1062, as follows:

[0155] S1061. Parse the structure of the data tables in the database to obtain at least one data type contained in the data tables, and generate stress test data based on at least one data type.

[0156] When generating load test data, the anomaly detection device may first retrieve pre-defined data tables from a database, then parse the table structure to extract the data types contained within. Since a data table may contain more than one data type, the anomaly detection device can parse at least one data type from the table. Next, based on each of the at least one data type, the device generates test data that conforms to each data type. Finally, the device packages and integrates the test data for each data type to obtain the load test data.

[0157] It is understood that, in the embodiments of this application, when the anomaly statement determination device generates corresponding test data according to each data type, it may randomly generate the data type according to the data format specified by the data type. For example, when the data type is an 18-digit ID number, the anomaly statement determination device may randomly generate an 18-digit string and use this string as the test data corresponding to that type. The anomaly statement determination device may also expand upon the standard test data input by the tester for each data type to construct constructed test data similar to the standard test data, and use the constructed test data and the standard test data together as the test data corresponding to that type.

[0158] S1062. Obtain the online data corresponding to the data table, and filter the online data to obtain the load test data.

[0159] In addition to generating load test data based on at least one data type in the data table, the abnormal statement identification device can also directly obtain online data corresponding to the data table, filter sensitive information in the online data, and use the filtered data as load test data.

[0160] It should be noted that the online data in this application embodiment can be user data stored in the database during application trial operation or even formal launch, or it can be publicly available data obtained from online open datasets that has the same data structure and data type as the data table. This application does not limit the scope of the data data.

[0161] In this embodiment, the abnormal statement determination device can directly parse the data tables in the database and automatically generate stress test data based on the data types contained in the data tables. Alternatively, it can obtain data corresponding to the data tables online, filter the online data, and obtain stress test data so that the abnormal statement determination device can use the stress test data to perform performance stress tests on the database.

[0162] based on Figure 4 See Figure 6 , Figure 6 This is a flowchart illustrating the method for determining abnormal statements provided in the embodiments of this application. Figure 4 In some embodiments of this application, after performing performance stress tests on the database using stress test statements and stress test data, and obtaining the stress test results, i.e., after S107, the method may further include: S109-S110, as follows:

[0163] S109. Obtain functional test monitoring data and stress test monitoring data.

[0164] Among them, functional test monitoring data represents the execution details of at least one historical test statement when performing functional tests on the application; stress test monitoring data represents the execution details of stress test statements when performing performance stress tests on the database.

[0165] Since the execution details of database test statements can indirectly reflect database performance during functional testing and performance stress testing, in this embodiment, the abnormal statement determination device monitors the database execution details during the execution of at least one historical test data point to obtain functional test monitoring data, and monitors the database execution details during the execution of stress test statements to obtain stress test monitoring data. Upon completion of the database performance stress test, the abnormal statement determination device acquires both the functional test monitoring data and the stress test monitoring data to subsequently generate database execution information during the test based on this monitoring data.

[0166] In some embodiments of this application, functional test monitoring data may include the number of times a lock is used, the lock wait time, the cache hit rate, and other monitoring data, which are not limited herein. Similarly, stress test monitoring data may also include the number of times a lock is used, the lock wait time, the cache hit rate, and other monitoring data, which are not specifically limited herein.

[0167] S110. Generate test execution information for the database based on functional test monitoring data and stress test monitoring data.

[0168] After receiving functional test monitoring data and stress test monitoring data, the device will integrate the two data sets and use the integrated result as the database's test execution information. This allows testers to assess the database's performance based on the test execution information.

[0169] Furthermore, in some embodiments of this application, after the abnormal statement determination device integrates the functional test monitoring data and the stress test monitoring data to obtain the integrated result, it can also analyze the integrated result, such as analyzing the performance of the database and using the performance analysis result of the database as the test execution information of the database.

[0170] In this embodiment of the application, the abnormal statement determination device can also monitor the execution details of the database during functional testing and performance stress testing, thereby obtaining functional test monitoring data and stress test monitoring data, and then obtaining the test execution information of the database, which facilitates subsequent testers to judge the performance of the database.

[0171] The following will describe an exemplary application of the embodiments of this application in a real-world application scenario.

[0172] The embodiments of this application were implemented during testing of the database corresponding to a business system (application) involving database operations.

[0173] See Figure 7 , Figure 7 This is a process example diagram of database statements for analyzing anomalies in a business system provided in an embodiment of this application. For example... Figure 7 As shown, for the business system under test 7-1, there is a dedicated service management terminal (application service management module) 7-11 that implements functions during testing, and a dedicated log collection module 7-12 (application logging module). The log collection module 7-12 is used to collect daily test data and record it in the test behavior log. This application collects and analyzes abnormal SQL statements (target abnormal statements) during the testing process through daily test behavior (daily functional testing).

[0174] The intelligent module 7-2 (abnormal statement identification device) includes a collector 7-21, an information filtering module 7-22, and an intelligent analysis module 7-23. The collector 7-21 issues a database statement to the business system under test 7-1 to begin analyzing anomalies, requiring the business system under test 7-1 to provide test behavior logs (functional test logs) (test data collection instructions). After receiving the command from the collector 7-21 to provide test behavior logs, the business system under test 7-1 provides the test behavior logs to the information filtering module 7-22 of the intelligent module 7-2. The information filtering module 7-22 cleans the invalid and duplicate data recorded in the test behavior logs, obtaining the cleaned source data (at least one historical test statement and at least one historical performance parameter). The intelligent analysis module 7-23 performs anomaly analysis on the cleaned data.

[0175] See also Figure 7 When performing anomaly analysis, the intelligent analysis module 7-23 first performs a compliance check on the cleaned source data (7-231). This involves selecting SQL statements (database statements) from the cleaned source data based on specific industry and business standards, recording any non-compliant SQL statements so that these statements can be communicated to the relevant responsible parties. Next, the intelligent analysis module 7-23 analyzes the SQL statements using pt-query-digest to perform a comprehensive analysis of the SQL statements in the cleaned source data, filtering out the top anomalous operations (one or more candidate anomalous statements), such as the top 10 slowest query times (processing times). Next, the intelligent analysis module 7-23 uses `EXPLAIN` to analyze the execution process of individual SQL statements in the top anomaly operations. The analysis points mainly include: whether an index was used (obtaining index usage results), whether a full table scan was performed (obtaining data table scan results), and whether the SQL execution time was still slow even when using an index (execution status of candidate anomaly statements when using indexes), whether there were problems with the index creation, etc. Problematic anomaly SQL statements (target anomaly statements) are filtered out, and reports are generated for these statements to reach the project manager. After identifying the anomaly SQL statements, they can be directly modified. For some statements requiring in-depth analysis, the load testing module 7-3 can be used to further locate database problems. This is because the difference between manual functional testing in the test environment and real online stress is significant. Manual functional testing operations are generally single-threaded, and even an individual can hardly achieve high concurrency. Database performance problems generally occur under high concurrency, so necessary performance load testing can uncover problems that cannot be found in manual functional testing.

[0176] The process of load testing using the load testing module 7-3 mainly consists of three parts: data generation (generating load testing data), generation of load testing SQL statements (generating load testing statements), and load testing execution. Data generation, aided by the data module, can quickly generate large amounts of data 7-31. There are two main methods for data generation: one is automatic generation based on the project's table structure (data table structure), which determines common data types such as addresses, IPs, emails, and ID card numbers; the other is replaying online data in the test environment, in which case sensitive data needs to be filtered. Predicting SQL statements can involve uploading custom load testing scripts (pre-defined database statements as load testing statements), allowing for load testing of specific scenarios, such as read-only or read-write mixed scenarios; or using abnormal SQL statements discovered during anomaly analysis (target abnormal statements as load testing statements); or considering using online SQL replay, selecting the most frequently occurring statements daily (the most frequently occurring database statements within a preset time period) and the statements with the highest online traffic requests (the database statements with the highest request traffic within a preset time period), combining them into load testing requests. This can, to some extent, replicate online behavior. When the load test is executed (7-32), it is based on concurrent execution and supports configurable parameters such as load test time and concurrency. After obtaining the load test results, the load test module (7-3) will also return the results to the intelligent analysis module (7-23) to generate corresponding reports.

[0177] During testing, since the database cannot be monitored constantly, database monitoring is essential. Therefore, a simple monitoring module can be set up in the business system under test to monitor the execution of SQL statements in the database during testing (execution details of at least one historical test statement and the execution details of the load test statement), such as the number of locks used, lock wait time, cache hit rate, etc. The monitoring module can automatically collect this data and generate relevant information (test execution information) with one click during testing.

[0178] The above method allows for the analysis of SQL statements during the functional testing phase, saving testing manpower. By simply checking the anomaly analysis report later, the abnormal SQL statements can be identified, improving the efficiency of identifying abnormal SQL statements. At the same time, it can also reduce the shortcomings caused by differences in the experience of testers.

[0179] The following description continues to illustrate the exemplary structure of the abnormal statement determination device 255 provided in the embodiments of this application as a software module. In some embodiments, such as Figure 2 As shown, the software module in the exception statement determination device 255 stored in the memory 250 may include:

[0180] The data acquisition module 2551 is used to, when a test data collection instruction is received, in response to the test data collection instruction, acquire at least one historical test statement and at least one historical performance parameter from the functional test log of the application; wherein, the at least one historical test statement is a database statement used when performing functional testing on the application, and the at least one historical performance parameter is a database performance parameter when executing the at least one historical test statement;

[0181] The statement filtering module 2552 is used to filter one or more candidate abnormal statements from the at least one historical test statements based on the at least one historical performance parameter; and to filter the target abnormal statement from the one or more candidate abnormal statements based on the one or more analysis results.

[0182] The result analysis module 2553 is used to analyze the execution process of the one or more candidate exception statements and obtain one or more analysis results corresponding to the one or more candidate exception statements.

[0183] In some embodiments of this application, the abnormal statement determination device 255 further includes: a stress test module 2554;

[0184] The stress testing module 2554 is used to generate stress testing statements for the database; generate stress testing data according to the structure of the data tables in the database; perform performance stress testing on the database using the stress testing statements and the stress testing data to obtain stress testing results; and determine supplementary abnormal statements from the at least one historical test statements based on the stress testing results and the target abnormal statement.

[0185] In some embodiments of this application, the at least one historical performance parameter is at least one processing time; the statement filtering module 2552 is further configured to select a preset number of processing times from the at least one processing time in descending order as abnormal processing times; and to select historical test statements corresponding to the abnormal processing times from the at least one historical test statements to obtain the one or more candidate abnormal statements.

[0186] In some embodiments of this application, the result analysis module 2553 is further configured to analyze the index usage of each candidate abnormal statement among the one or more candidate abnormal statements to obtain the index usage result of each candidate abnormal statement; the index usage result indicates whether each candidate abnormal statement uses an index; analyze the data table scan of each candidate abnormal statement to obtain the data table scan result of each candidate abnormal statement; the data table scan result indicates whether each candidate abnormal statement has undergone a full table scan; use the index usage result and the data table scan result to form the analysis result corresponding to each candidate abnormal statement; when the analysis result is determined for all one or more candidate abnormal statements, the one or more analysis results corresponding one-to-one with the one or more candidate abnormal statements are obtained.

[0187] In some embodiments of this application, the data acquisition module 2551 is used to extract all historical statements and all historical parameters corresponding to the all historical statements from the functional test log of the application; wherein, the all historical statements are all statements used during the functional test; the database statements in the all historical statements are selected to obtain at least one historical test statement; and at least one historical performance parameter corresponding to the at least one historical test statement is selected from the all historical parameters.

[0188] In some embodiments of this application, the stress testing module 2554 is further configured to use a preset database statement as the stress testing statement of the database; or, use the target abnormal statement as the stress testing statement of the database; or, use at least one of the database statement that appears most frequently within a preset time and the database statement with the largest request traffic within the preset time as the stress testing statement of the database.

[0189] In some embodiments of this application, the stress testing module 2554 is further configured to parse the structure of the data table in the database to obtain at least one data type contained in the data table, and generate the stress test data based on the at least one data type; or, to obtain the online data corresponding to the data table, and filter the online data to obtain the stress test data.

[0190] In some embodiments of this application, the abnormal statement determination device 255 further includes: an execution information determination module 2555;

[0191] The execution information determination module 2555 is used to acquire functional test monitoring data and stress test monitoring data; wherein, the functional test monitoring data represents the execution details of at least one historical test statement when performing functional testing on the application; the stress test monitoring data represents the execution details of the stress test statement when performing performance stress testing on the database; and test execution information of the database is generated based on the functional test monitoring data and the stress test monitoring data.

[0192] This application provides a computer program product or computer program that includes computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the exception statement determination method described above in this application.

[0193] This application provides a computer-readable storage medium storing executable instructions, including executable exception statement determination instructions. When these instructions are executed by a processor, the processor will execute the exception statement determination method provided in this application. For example, ... Figure 3 , Figure 4 , Figure 5 and Figure 6 The method shown.

[0194] In some embodiments, the computer-readable storage medium may be a memory such as FRAM, ROM, PROM, EPROM, EEPROM, flash memory, magnetic surface memory, optical disk, or CD-ROM; or it may be a variety of devices including one or any combination of the above-mentioned memories.

[0195] In some embodiments, executable exception statement determination instructions may take the form of a program, software, software module, script, or code, written in any form of programming language (including compiled or interpreted languages, or declarative or procedural languages), and may be deployed in any form, including as a standalone program or as a module, component, subroutine, or other unit suitable for use in a computing environment.

[0196] As an example, executable exception statements can, but do not necessarily, correspond to files in the file system. They can be stored as part of a file that holds other programs or data, for example, in one or more scripts in a Hyper Text Markup Language (HTML) document, in a single file dedicated to the program in question, or in multiple co-located files (e.g., files that store one or more modules, subroutines, or code sections).

[0197] As an example, executable exception statement determination instructions can be deployed to execute on a single computing device, or on multiple computing devices located in one location, or on multiple computing devices distributed across multiple locations and interconnected via a communication network.

[0198] The above description is merely an embodiment of this application and is not intended to limit the scope of protection of this application. Any modifications, equivalent substitutions, and improvements made within the spirit and scope of this application are included within the scope of protection of this application.

Claims

1. A method for determining abnormal statements, characterized in that, Before an application goes live, the application is equipped with a corresponding database to store data generated during the application's operation. The method includes: When a test data collection instruction is received, in response to the test data collection instruction, at least one historical test statement and at least one historical performance parameter are obtained from the functional test log of the application. Wherein, the at least one historical test statement is a database statement used when performing functional testing on the application, and the at least one historical performance parameter is a database performance parameter when executing the at least one historical test statement; Based on the at least one historical performance parameter, one or more candidate abnormal statements are selected from the at least one historical test statement; The execution process of the one or more candidate exception statements is analyzed to obtain one or more analysis results corresponding one-to-one with the one or more candidate exception statements; Based on the one or more analysis results, the target abnormal statement is selected from the one or more candidate abnormal statements; Generate load testing statements for the database; Based on the structure of the data tables in the database, stress test data is generated; The database is subjected to performance stress testing using the stress testing statements and the stress testing data, and the stress test results are obtained. Based on the stress test results and the target abnormal statement, a supplementary abnormal statement is determined from the at least one historical test statement; Obtain functional test monitoring data and stress test monitoring data; The functional test monitoring data represents the execution details of at least one historical test statement when performing functional tests on the application, and the functional test monitoring data includes the number of times the lock is used, the lock wait time, and the cache hit rate. The stress test monitoring data represents the execution details of the stress test statements when the database is subjected to performance stress testing; Based on the functional test monitoring data and the stress test monitoring data, test execution information is generated in the database.

2. The method according to claim 1, characterized in that, The at least one historical performance parameter is at least one processing time; The step of filtering one or more candidate abnormal statements from the at least one historical test statement based on the at least one historical performance parameter includes: From the at least one processing time, a preset number of processing times are selected in descending order as abnormal processing times; From the at least one historical test statement, select the historical test statement corresponding to the abnormal time consumption to obtain the one or more candidate abnormal statements.

3. The method according to claim 1, characterized in that, The analysis of the execution process of the one or more candidate exception statements to obtain one or more analysis results corresponding one-to-one with the one or more candidate exception statements includes: The index usage of each candidate exception statement in the one or more candidate exception statements is analyzed to obtain the index usage result of each candidate exception statement; the index usage result indicates whether each candidate exception statement uses an index. The data table scan of each candidate abnormal statement is analyzed to obtain the data table scan result of each candidate abnormal statement; the data table scan result indicates whether a full table scan was performed for each candidate abnormal statement. The analysis results corresponding to each candidate abnormal statement are composed using the index usage results and the data table scan results. When the analysis results are determined for all one or more candidate exception statements, one or more analysis results corresponding one-to-one with the one or more candidate exception statements are obtained.

4. The method according to claim 1, characterized in that, The step of obtaining at least one historical test statement and at least one historical performance parameter from the application's functional test logs includes: Extract all historical statements and corresponding historical parameters from the application's functional test logs; wherein, the all historical statements are all statements used during the functional test. Select database statements from the full set of historical statements to obtain at least one historical test statement; From the full set of historical parameters, select at least one historical performance parameter that corresponds to at least one historical test statement.

5. The method according to claim 1, characterized in that, The generation of load testing statements for the database includes: Use a pre-defined database statement as the load testing statement for the database; or, Use the target exception statement as the load test statement for the database; or, The database statement that appears most frequently within a preset time period and the database statement with the highest request traffic within the preset time period shall be used as the stress test statement of the database.

6. The method according to claim 1, characterized in that, The step of generating stress test data based on the structure of the data tables in the database includes: The structure of the data tables in the database is parsed to obtain at least one data type contained in the data tables, and the stress test data is generated based on the at least one data type; or, Obtain the online data corresponding to the data table, and filter the online data to obtain the stress test data.

7. An abnormal statement determination device, characterized in that, Before an application goes live, the application is equipped with a corresponding database to store data generated during the application's operation. The device includes: The data acquisition module is used to, upon receiving a test data collection instruction, respond to the test data collection instruction by acquiring at least one historical test statement and at least one historical performance parameter from the functional test log of the application; wherein, the at least one historical test statement is a database statement used when performing functional testing on the application, and the at least one historical performance parameter is a performance parameter of the database when executing the at least one historical test statement; The statement filtering module is used to filter one or more candidate abnormal statements from the at least one historical test statements based on the at least one historical performance parameter; and to filter the target abnormal statement from the one or more candidate abnormal statements based on one or more analysis results. The result analysis module is used to analyze the execution process of the one or more candidate exception statements and obtain one or more analysis results corresponding to the one or more candidate exception statements. The stress testing module is used to generate stress testing statements for the database; generate stress testing data according to the structure of the data tables in the database; perform performance stress testing on the database using the stress testing statements and the stress testing data to obtain stress testing results; and determine supplementary abnormal statements from at least one historical test statement based on the stress testing results and the target abnormal statement. An execution information determination module is used to acquire functional test monitoring data and stress test monitoring data; wherein, the functional test monitoring data represents the execution details of at least one historical test statement when performing functional testing on the application, and the functional test monitoring data includes the number of times locks are used, the lock wait time, and the cache hit rate; the stress test monitoring data represents the execution details of the stress test statement when performing performance stress testing on the database; and test execution information of the database is generated based on the functional test monitoring data and the stress test monitoring data.

8. The apparatus according to claim 7, characterized in that, The at least one historical performance parameter is at least one processing time; The statement filtering module is further configured to select a preset number of processing times from the at least one processing time in descending order as abnormal processing times; and to select historical test statements corresponding to the abnormal processing times from the at least one historical test statements to obtain the one or more candidate abnormal statements.

9. The apparatus according to claim 7, characterized in that, The result analysis module is further configured to analyze the index usage of each candidate exception statement among the one or more candidate exception statements, and obtain the index usage result of each candidate exception statement; the index usage result indicates whether each candidate exception statement uses an index; The data table scan of each candidate abnormal statement is analyzed to obtain the data table scan result of each candidate abnormal statement; the data table scan result indicates whether a full table scan was performed for each candidate abnormal statement. Using the index usage results and the data table scan results, an analysis result corresponding to each candidate abnormal statement is formed; when an analysis result is determined for all one or more candidate abnormal statements, one or more analysis results corresponding one-to-one with the one or more candidate abnormal statements are obtained.

10. The apparatus according to claim 7, characterized in that, The data acquisition module is further configured to extract all historical statements and all historical parameters corresponding to the all historical statements from the functional test log of the application; wherein, the all historical statements are all statements used during the functional test; to select database statements from the all historical statements to obtain at least one historical test statement; and to select at least one historical performance parameter corresponding to the at least one historical test statement from the all historical parameters.

11. The apparatus according to claim 7, characterized in that, The stress testing module is further configured to use a preset database statement as the stress testing statement for the database; or, use the target abnormal statement as the stress testing statement for the database; or, use at least one of the database statement that appears most frequently within a preset time period and the database statement with the largest request traffic within the preset time period as the stress testing statement for the database.

12. The apparatus according to claim 7, characterized in that, The stress testing module is also used to parse the structure of the data tables in the database to obtain at least one data type contained in the data tables, and generate the stress test data based on the at least one data type; or, to obtain the online data corresponding to the data tables, and filter the online data to obtain the stress test data.

13. An abnormal statement determination device, characterized in that, include: Memory, used to store executable exception statement determination instructions; A processor, when executing executable exception statement determination instructions stored in the memory, implements the method according to any one of claims 1 to 6.

14. A computer-readable storage medium, characterized in that, It stores executable exception statement determination instructions, which, when executed by a processor, implement the method described in any one of claims 1 to 6.

Images