A database testing method and device, electronic equipment and storage medium

Abstract

The application discloses a database test method and device, electronic equipment and storage medium, wherein the method comprises: obtaining the to-be-processed traffic of a target database, and determining the protocol characteristic information corresponding to at least one data packet in the to-be-processed traffic; generating at least one to-be-injected abnormal script based on the protocol characteristic information of each data packet and the protocol state machine corresponding to the target database; determining the communication protocol layer corresponding to each to-be-injected abnormal script, and injecting to obtain an abnormal test model; and generating a test report according to the comparison result of the output data of the abnormal test model and the target comparison data corresponding to the target database. The corresponding abnormal test model is constructed according to the protocol interaction characteristics of the database, the coverage of the test scene to the abnormal conditions in the real network is improved through the abnormal scene added in the abnormal test model, and then the security test effect of the target database is targeted.

Description

Technical Field

[0001] The present invention relates to the technical field of database testing, and in particular to a database testing method, device, electronic equipment and storage medium. Background Art

[0002] As a domestic transactional database, GBase8s database is widely used in high-concurrency transaction processing and distributed deployment.

[0003] At present, traditional database testing tools only focus on performance indicators and cannot simulate abnormal scenarios such as network jitter or TCP retransmission. Existing network injection technology only targets general middleware and does not adapt to the characteristics of the GBase8s database to provide a systematic anomaly detection mechanism. As a result, there is a problem that the test scenarios do not cover abnormal situations in the real network sufficiently.

[0004] In order to solve the above problems, it is necessary to improve the database testing method. Summary of the Invention

[0005] The present invention provides a database testing method, device, electronic device and storage medium to solve the problems in the prior art of insufficient coverage of abnormal scenarios of the database and failure to adapt abnormality detection to the characteristics of the database, resulting in inaccurate test results for the database.

[0006] In a first aspect, an embodiment of the present invention provides a database testing method, comprising:

[0007] Obtaining to-be-processed traffic from a target database, and determining protocol feature information corresponding to at least one data packet in the to-be-processed traffic;

[0008] generating at least one abnormal script to be injected based on the protocol feature information of each data packet and the protocol state machine corresponding to the target database; wherein the protocol state machine includes at least one communication protocol layer;

[0009] Determine the communication protocol layer corresponding to each abnormal script to be injected, and inject it to obtain an abnormal test model;

[0010] A test report is generated based on the comparison results of the output data of the abnormal test model and the target comparison data corresponding to the target database.

[0011] In a second aspect, an embodiment of the present invention further provides a database testing device, comprising:

[0012] A traffic acquisition module, configured to acquire the to-be-processed traffic of a target database and determine protocol feature information corresponding to at least one data packet in the to-be-processed traffic;

[0013] a script generation module, configured to generate at least one exception script to be injected based on the protocol feature information of each data packet and a protocol state machine corresponding to the target database; wherein the protocol state machine includes at least one communication protocol layer;

[0014] The model generation module is used to determine the communication protocol layer corresponding to each abnormal script to be injected, and inject it to obtain an abnormal test model;

[0015] The report generation module is used to generate a test report based on the comparison results of the output data of the abnormal test model and the target comparison data corresponding to the target database.

[0016] In a third aspect, an embodiment of the present invention further provides an electronic device, including:

[0017] at least one processor; and

[0018] a memory communicatively connected to the at least one processor; wherein,

[0019] The memory stores a computer program that can be executed by the at least one processor. The computer program is executed by the at least one processor to enable the at least one processor to perform the database testing method described in any embodiment of the present invention.

[0020] In a fourth aspect, an embodiment of the present invention further provides a computer-readable storage medium, wherein the computer-readable storage medium stores computer instructions, and the computer instructions are used to enable a processor to implement the database testing method described in any embodiment of the present invention when executed.

[0021] In a fifth aspect, an embodiment of the present invention further provides a computer program product, comprising a computer program, which, when executed by a processor, implements the database testing method as described in any one of the embodiments of the present invention.

[0022] The technical scheme of the embodiment of the application comprises the following steps: obtaining to-be-processed traffic of a target database, and determining protocol feature information corresponding to at least one data packet in the to-be-processed traffic; generating at least one to-be-injected abnormal script based on the protocol feature information of each data packet and a protocol state machine corresponding to the target database; determining a communication protocol layer corresponding to each to-be-injected abnormal script, and injecting the to-be-injected abnormal script to obtain an abnormal test model; and generating a test report according to an output data of the abnormal test model and a comparison result of target comparison data corresponding to the target database. In the technical scheme, to-be-processed traffic is obtained by performing traffic packet capturing on a preset port of a target database, and protocol feature information corresponding to a data packet is extracted from the to-be-processed traffic. Meanwhile, a protocol state machine is constructed according to state conversion information in a protocol interaction process of the target database, so as to establish an abnormal scene based on the protocol feature information of each data packet and the protocol state machine, inject a to-be-injected abnormal script corresponding to the abnormal scene into a corresponding communication protocol layer, and construct an abnormal test model corresponding to the target database. The technical scheme solves the problems of insufficient coverage of an abnormal scene of a database in the prior art and non-adaptation of abnormal detection to database characteristics, realizes construction of a corresponding abnormal test model according to protocol interaction characteristics of a database, improves the coverage of a test scene to abnormal conditions in a real network through an abnormal scene added in the abnormal test model, and thus can perform security testing on a target database according to protocol characteristics of the target database.

[0023] It should be understood that the content described in this part is not intended to identify key or important features of the embodiments of the application, nor is it used to limit the scope of the application. Other features of the application will become apparent from the following description. BRIEF DESCRIPTION OF DRAWINGS

[0024] In order to more clearly illustrate the technical solutions in the embodiments of the application, the following will briefly introduce the drawings needed to be used in the embodiment description. Obviously, the drawings in the following description are only some embodiments of the application, and other drawings can also be obtained by those skilled in the art without creative effort on the basis of these drawings.

[0025] Figure 1 is a flow chart of a database testing method provided by the first embodiment of the application;

[0026] Figure 2 is a flow chart of a database testing method provided by the second embodiment of the application;

[0027] Figure 3 is a structural schematic diagram of a database testing device provided by the third embodiment of the application;

[0028] Figure 4The diagram is a structural diagram of an electronic device for implementing the database testing method according to an embodiment of the present invention. DETAILED DESCRIPTION

[0029] In order to enable those skilled in the art to better understand the solutions of the present invention, the technical solutions in the embodiments of the present invention will be clearly and completely described below in conjunction with the drawings in the embodiments of the present invention. Obviously, the described embodiments are only embodiments of a part of the present invention, not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work should fall within the scope of protection of the present invention. The acquisition, transmission, storage, use, and processing of data in the technical solution of this application comply with the relevant provisions of national laws and regulations. It should be noted that in the embodiments of this application, certain software, components, or models that already exist in the industry may be mentioned. They should be regarded as exemplary. Their purpose is only to illustrate the feasibility of the implementation of the technical solution of this application, but it does not mean that the applicant has or must use the solution.

[0030] It should be noted that the terms "first," "second," and the like in the description and claims of the present invention and the accompanying drawings are used to distinguish similar objects and are not necessarily used to describe a specific order or precedence. It should be understood that the terms used in this manner are interchangeable where appropriate, such that the embodiments of the present invention described herein can be practiced in an order other than that illustrated or described herein.

[0031] Example 1

[0032] Figure 1 A flowchart of a database testing method is provided for the first embodiment of the present invention. This embodiment can be applied to obtain protocol feature information of data packets based on the traffic of the database, and combine the protocol feature information with the protocol state machine of the database to construct an abnormal test model. At the same time, abnormal scenarios in a real network are simulated to perform abnormal simulation during the operation of the database, and then the output data of the abnormal test model is compared with the output data of the database under normal operating conditions to generate a test report to perform security testing on the database according to the test report. The method can be executed by a database testing device, which can be implemented in the form of hardware and / or software, and the database testing device can be configured in a computing device that can execute the database testing method.

[0033] like Figure 1 As shown, the method includes:

[0034] S110: Obtain the traffic to be processed of the target database, and determine protocol feature information corresponding to at least one data packet in the traffic to be processed.

[0035] The target database refers to the database whose fault tolerance to network fluctuations needs to be tested. The target database can be a business database or a transactional database. For example, the target database can be a GBase8s database, and the traffic to be processed refers to the communication traffic during the use of the target database. For example, the traffic to be processed can be the TCP traffic in the target database through port 9088. Protocol characteristic information refers to the specific identification, structure, or behavior pattern contained in the target database operation data packet transmitted through the network. This information can reflect the core attributes of the target database, such as the type of communication protocol, operation type, and data format.

[0036] In a specific example, the target database's traffic to be processed is obtained, and the protocol characteristic information corresponding to at least one data packet in the traffic to be processed is determined, including: performing packet capture processing on a preset port of the target database to obtain the traffic to be processed; for each data packet in the traffic to be processed, parsing the data packet based on preset detection rules to obtain the protocol characteristic information corresponding to each data packet.

[0037] The protocol characteristic information includes at least one of the type of data packet, fixed bytes or key fields, and the preset detection rules include detection rules corresponding to data packet type detection, fixed bytes detection and key field detection.

[0038] For example, assuming the target database is GBase8s and the default port is 9088, packet capture is performed on port 9088 of the GBase8s database, capturing the TCP traffic on port 9088. This captured TCP traffic is then deeply parsed to obtain at least one data packet. Furthermore, a specially developed GBase8s protocol parsing plug-in is used to identify each data packet and extract GBase8s-specific protocol features. This process is then continued until a sufficient number of business scenario data packets are collected, including various operations such as connection establishment, SQL queries, transaction processing, and heartbeat maintenance.

[0039] Specifically, each acquired data packet is parsed byte by byte based on preset detection rules to identify fixed features in each data packet, such as whether the first two bytes of the data packet are the fixed bytes "0x4854", where 0x4854 represents a heartbeat packet.

[0040] Specifically, each data packet is inspected to determine its corresponding type, and corresponding protocol characteristics are determined based on the data packet type. For example, the three-way handshake characteristics of the target database during the connection establishment phase, the username / password encryption method of the authentication packet, the location and format of the XID field in the transaction control packet, the fragmentation flag and verification mechanism of the large object packet, and the sending interval and timeout mechanism of the heartbeat packet can be determined based on the data packet.

[0041] S120 : Generate at least one abnormal script to be injected based on the protocol feature information of each data packet and the protocol state machine corresponding to the target database.

[0042] In this technical solution, a protocol state machine refers to a finite state machine model corresponding to the target database, which can be used to manage the database communication protocol interaction process. The protocol state machine includes at least one communication protocol layer. By defining the states, events, and transition rules in protocol interactions, the protocol state machine ensures that database clients and servers can correctly parse data packets, maintain session integrity, and achieve transaction consistency during network communications.

[0043] The "abnormal script to be injected" is a script converted from an abnormal scenario in the target database. An abnormal scenario is a scenario that simulates an abnormal situation in a real network environment. For example, abnormal scenarios include at least one of delay injection, packet loss simulation, out-of-order attacks, and connection pool contention under high latency.

[0044] In this technical solution, complete state transition information can be established based on the protocol interaction process of each data packet of the target database, such as the connection establishment state, authentication state, activity state, transaction processing state, heartbeat maintenance state, and abnormal recovery state. By verifying the transition conditions between each state using actual packet capture data, a protocol state machine corresponding to the target database is constructed. Furthermore, by simulating abnormal situations in a real network environment and combining the unique communication protocol and transaction mechanism of the GBase8s database, the robustness, fault tolerance, and automatic recovery capabilities of the GBase8s database can be systematically tested.

[0045] Optionally, based on the protocol feature information of each data packet and the protocol state machine corresponding to the target database, at least one exception script to be injected is generated, including: constructing a protocol state machine corresponding to the target database; for each communication protocol layer of the protocol state machine, determining at least one associated data packet associated with the current communication protocol layer, and simulating the abnormal scenario corresponding to the current communication protocol layer according to the protocol feature information of the associated data packet; performing script conversion on the abnormal scenario to obtain the abnormal script to be injected corresponding to the current communication protocol layer.

[0046] The communication protocol layering in the target database usually runs on the application layer of the network protocol stack and relies on the underlying protocol to complete data transmission. For example, the communication protocol layering can be the transport layer and the network layer.

[0047] Taking the TCP / IP model as an example, the communication protocol layering can include the physical layer, network layer, transport layer, and application layer. The transport layer provides end-to-end communication control. Common protocols include TCP and UDP. TCP is connection-oriented, ensuring reliable transmission, while UDP is connectionless, suitable for low-latency scenarios. In this technical solution, abnormal situations of the target database can be simulated in two dimensions: the TCP / IP layer (i.e., the transport layer) and the application layer. The target database is then simulated in conjunction with the target database's corresponding protocol state machine to ensure that the test of the target database covers various edge scenarios of the target database driver layer.

[0048] Among them, building a protocol state machine corresponding to the target database includes: determining state transition information between each protocol interaction state based on at least one protocol interaction state of the target database during use; and building a protocol state machine corresponding to the target database based on the state transition information.

[0049] On this basis, based on the acquired protocol feature information of the associated data packets of each communication protocol layer, an abnormal scenario simulation is performed. For at least one associated data packet associated with the communication protocol layer, predefined abnormal injection rules for various abnormal scenarios and parameter configurations are established. For example, the abnormal injection rules include: target data packet feature description, injectable abnormality type, abnormal parameter configuration range, and expected impact assessment. The detailed description of the abnormal injection rules is as follows:

[0050] (1) Delayed injection

[0051] Inject a delay during commit statement transmission to verify whether a transaction timeout rollback is triggered. Setting a fixed delay (e.g., 200ms) for commit packets using Linux's tc netem is suitable for testing driver behavior in a stable, high-latency environment.

[0052] Add jitter to heartbeat (Keepalive) responses to detect whether the connection keepalive mechanism has failed. Simulate real network fluctuations for heartbeat packets, set a base latency ± random offset (e.g., 100ms ± 20ms), and test the driver's adaptability to sudden changes in latency.

[0053] (2) Packet loss simulation

[0054] If packets are lost during the result set transmission process, verify whether the driver reissues the request or returns partial result errors. Randomly drop a specified percentage of packets (e.g., 15%) to simulate normal network congestion.

[0055] During the login authentication phase, server response packets are discarded to test whether the client retries or issues an authentication timeout. If specific packet types (such as ACK packets) are continuously discarded, the TCP retransmission mechanism is forced to trigger.

[0056] (3) Out-of-order attack

[0057] Shuffle the returned results of paged queries to verify the integrity of the result set. Randomly reorder packets within a specified window size (e.g., 5 packets).

[0058] When transferring large objects, the fragment order is disrupted to check whether the driver verifies data boundaries. Manually adjust the order for specific protocol packets (such as BLOB fragment packets).

[0059] (4) Connection pool competition under high latency

[0060] Set a baseline latency of 300ms and initialize the connection pool (10 connections). Execute 20 transactions concurrently, each containing a SELECT query (which triggers connection pool preemption). Inject an additional 500ms delay during the UPDATE phase. Randomly discard 30% of the COMMIT packets to observe connection leaks.

[0061] On this basis, script conversion is performed on each abnormal scenario to obtain the abnormal script to be injected corresponding to the corresponding communication protocol layer.

[0062] Specifically, you can use the tc netem command to simulate basic network anomalies, combine iptables to simulate connection interruptions, and use Python injection code to convert simulated abnormal scenarios into corresponding abnormal scripts to be injected.

[0063] Exemplarily, at least one abnormal script to be injected is generated based on the protocol feature information of each data packet and the protocol state machine of the target database as follows:

[0064] (1) Transport layer abnormal injection

[0065] Delay injection (TCP / UDP layer)

[0066] Fixed delay (applicable to transaction scenarios): tc qdisc add dev eth0 root netem delay 200ms

[0067] Random jitter (simulating a real network) tc qdisc change dev eth0 root netem delay 100ms50ms 25%

[0068] Packet loss and duplication

[0069] Random packet loss 15% (simulating congestion) tc qdisc change dev eth0 root netem loss 15%

[0070] Out of order and connection interruption

[0071] Forced connection interruption (RST attack) nmap --script rst-injection -p 9088 target_ip

[0072] (2) Application layer protocol attacks

[0073] GBase protocol tampering

[0074] Tampering with protocol fields using Scapy

[0075] def corrupt_packet(pkt):

[0076] if pkt[TCP].dport == 9088:

[0077] raw = pkt[TCP].payload.load

[0078] raw = raw[:12] + b"\x12\x00\x00\x00" + raw[16:] # Modify the length field

[0079] sendp(pkt)

[0080] S130: Determine the communication protocol layer corresponding to each abnormal script to be injected, and inject it to obtain an abnormal test model.

[0081] On the basis of the above example, according to the abnormal scenario corresponding to each abnormal script to be injected, the communication protocol layer corresponding to the abnormal script to be injected is determined, and each abnormal script to be injected is injected into the corresponding communication protocol layer.

[0082] Take state-triggered injection as an example: it can be based on SQL-type dynamic injection. The specific injection method is as follows:

[0083] def dynamic_inject(pkt):

[0084] payload = pkt[TCP].payload.load

[0085] if b"UPDATE" in payload:

[0086] os.system("tc qdisc change dev eth0 root netem delay 50msloss 10%")

[0087] S140: Generate a test report based on the comparison results of the output data of the abnormal test model and the target comparison data corresponding to the target database.

[0088] The target comparison data refers to the output data of the target database when it is operating normally and no abnormal scenarios are injected.

[0089] In practical applications, to determine whether the target database can operate normally under network anomalies, it is possible to test the target database by simulating abnormal scenarios. Therefore, to determine whether the target database's security meets requirements, it is possible to pre-collect target comparison data from the target database under normal operating conditions, compare the output data of the abnormal test model with the target comparison data, and generate a test report based on the comparison results. This test report can then be used to determine whether the target database's security meets requirements.

[0090] The technical solution of the embodiment of the present invention is to obtain the to-be-processed traffic of the target database and determine the protocol characteristic information corresponding to at least one data packet in the to-be-processed traffic; generate at least one to-be-injected exception script based on the protocol characteristic information of each data packet and the protocol state machine corresponding to the target database; determine the communication protocol layer corresponding to each to-be-injected exception script and inject it to obtain an exception test model; and generate a test report based on the comparison result of the output data of the exception test model and the target comparison data corresponding to the target database. In this technical solution, the to-be-processed traffic is obtained by capturing the traffic packets of the preset port of the target database, and the protocol characteristic information corresponding to the data packet is extracted from the to-be-processed traffic. At the same time, a protocol state machine is constructed based on the state transition information in the protocol interaction process of the target database, so as to establish an exception scenario based on the protocol characteristic information of each data packet and the protocol state machine, and the to-be-injected exception script corresponding to the exception scenario is injected into the corresponding communication protocol layer to construct an exception test model corresponding to the target database. The problem of insufficient coverage of abnormal scenarios of the database and failure to adapt to the characteristics of the database for abnormal detection in the existing technology is solved. The corresponding abnormal test model is constructed according to the protocol interaction characteristics of the database. By adding abnormal scenarios to the abnormal test model, the coverage of the test scenario for abnormal situations in the real network is improved, so that the security test effect of the target database can be carried out in a targeted manner according to the protocol characteristics of the target database.

[0091] Example 2

[0092] Figure 2 This is a flowchart of a database testing method provided in the second embodiment of the present invention. Optionally, a test report is generated based on the comparison results of the output data of the abnormal test model and the target comparison data corresponding to the target database to be refined.

[0093] like Figure 2As shown, the method includes:

[0094] S210: Obtain the traffic to be processed of the target database, and determine protocol feature information corresponding to at least one data packet in the traffic to be processed.

[0095] S220 : Generate at least one abnormal script to be injected based on the protocol feature information of each data packet and the protocol state machine corresponding to the target database.

[0096] In a specific example, a protocol state machine corresponding to the target database is constructed. For example, the transition condition from the "connection establishment state" to the "authentication state" is defined in the state machine model: when the TCP three-way handshake is successful①, the client sends an authentication request packet containing the username / password (starting with the fixed byte "0x4854")②, the server receives and verifies it successfully and returns a confirmation response, at which point the state transitions to the "authentication state"③.

[0097] For example, consider Abnormal Scenario 1: Packet loss during the TCP three-way handshake (①); Associated Packet Feature Description: SYN packet during the TCP three-way handshake; Injectable Abnormal Type: Packet Loss. Abnormal Parameter Configuration Range: Packet Loss Probability: 0% to 100%. For example, a setting of 50% indicates a 50% probability of packet loss. Packet Loss Direction: Client to Server, Server to Client, or Both Directions. Expected Impact Assessment: If SYN packet is lost, the client will time out and resend the SYN request.

[0098] In another example, Abnormal Scenario 2: Authentication Request Packet Tampered (②); Target Packet Characteristics: Authentication Request Packet Sent by the Client (Packet Starting with 0x4854); Injectable Abnormal Type: Packet Content Tampering. Abnormal Parameter Configuration Range: Tampered Field: Username, Password Encrypted Part, or Other Key Fields; Tampering Method: Randomly Modify Byte Values, Replace Fixed Values, or Clear Fields; Expected Impact Assessment: After receiving the tampered packet, the server will fail authentication and return an error response.

[0099] Based on the above examples, the abnormal scenarios are converted into scripts to obtain the corresponding abnormal scripts to be injected for each abnormal scenario. For example, the tc netem command is used to simulate basic network abnormalities, combined with iptables to simulate connection interruptions and Python injection code to convert the abnormal scenarios into scripts.

[0100] S230: Determine the communication protocol layer corresponding to each abnormal script to be injected, and inject it to obtain an abnormal test model.

[0101] In this technical solution, the target database corresponds to a protocol state machine. After injecting the exception script to be injected into the protocol state machine, an exception test model is obtained. The exception test model can be used to simulate the abnormal situation of the target database in the real network state.

[0102] Optionally, determine the communication protocol layer corresponding to each abnormal script to be injected, and inject it to obtain an abnormal test model, including: determining the injection information corresponding to each abnormal script to be injected, and the communication protocol layer corresponding to each abnormal script to be injected; inject the abnormal script to be injected into the corresponding communication protocol layer to obtain the abnormal test model.

[0103] The injection information includes at least one of an injection timing, an abnormal scenario type, and an injection method corresponding to the script to be injected.

[0104] In practical applications, in order to more realistically simulate the fault tolerance of the target database when facing abnormal situations in a real network, when generating the abnormal scripts to be injected corresponding to each abnormal scenario, the injection information can be set as the identification information of the abnormal script to be injected, so that the abnormal script to be injected can be injected into the corresponding communication protocol layer according to the injection information to obtain an abnormal test model.

[0105] S240: Acquire output data of the protocol abnormality test type in real time, and acquire output data of the target database in a normal execution state as target comparison data.

[0106] S250 , comparing the output data with the target comparison data based on consistency verification rules, and generating a test report according to the comparison results.

[0107] The consistency check rule refers to a rule for detecting the consistency between output data and target comparison data, and is used to detect whether the data contents of the output data and target comparison data corresponding to the same business are consistent.

[0108] Based on the above example, the output data of the abnormal test model and the target comparison data output by the protocol state machine are obtained. Taking the output data of the abnormal test model as an example, the following output data are obtained: (1) The connection pool status of the abnormal test model is collected every 5 seconds, and the number of active connections and zombie connections is counted through the gbase_admin list connections command, focusing on the success rate of automatic connection recovery after abnormal interruption. (2) The Valgrind tool is used to monitor the memory allocation and release of the driver process, and the number of unreleased memory blocks and their growth trend are recorded during the test. (3) File descriptor leaks are tracked through the lsof command to ensure that resources are completely recovered after each test case is executed. Real-time packet capture is performed at the network layer to verify the integrity of the GBase protocol header and the consistency of the transaction ID. For example, check whether the XID of each transaction remains unchanged during retransmission and whether the result set transmission ends with a legal terminator (such as 0xFFFF).

[0109] On this basis, the same method is used to obtain the target comparison data output by the protocol state machine corresponding to the output data of the abnormal test model.

[0110] Specifically, a script was developed to perform consistency checks on the output data of the abnormal test model and the target comparison data output by the protocol state machine under normal execution. In actual applications, the consistency check can ignore field order differences caused by disorder, but strictly verifies the consistency of data content. It also automatically analyzes error codes in the driver log, calculates the frequency of each error type and the triggering scenarios, and generates an error distribution report (i.e., a test report).

[0111] For example, the time point and parameters of the abnormal injection of the abnormal script to be injected are associated with the system error log, and a test report containing the following elements is automatically generated: injection type (such as "delay 200ms + packet loss 15%"), observed error phenomenon (such as "connection pool leaks 3 handles"), and business data consistency check results.

[0112] On this basis, the output data and the target comparison data are compared based on the consistency verification rules, and a test report is generated according to the comparison results, including: determining the abnormal data in the output data according to the comparison results, and determining the abnormal scenarios corresponding to the abnormal data according to the identification information associated with the abnormal data; if the frequency of occurrence of the abnormal scenario is greater than the preset frequency of occurrence, the corresponding abnormal scenario and the corresponding abnormal script to be injected are eliminated; repeatedly determine the communication protocol layer corresponding to each abnormal script to be injected, and inject it to obtain an abnormal test model, and generate a test report according to the comparison results of the output data of the abnormal test model and the target comparison data corresponding to the target database until the growth rate of the frequency of occurrence of the abnormal scenario is less than the preset growth rate.

[0113] In the actual testing process of the target database, the comparison results can be used to determine whether there is abnormal data in the output data of the abnormal test model. It should be noted that the abnormal scenarios corresponding to different abnormal data may be the same. For example, if packet loss occurs during data transmission, corresponding abnormal data will appear in the collected output data, and the packet loss phenomenon may exist in different abnormal scenarios, such as discarding the server response packet during the login phase, or losing the data packet when the client returns data. When the frequency of occurrence of the same abnormal scenario is greater than the preset frequency, it indicates that the abnormal test model has a major problem in this abnormal scenario. At this time, while marking the abnormal scenario, in order to improve the testing speed of the abnormal test model, the abnormal scenarios with a frequency greater than the preset frequency can be eliminated, and the script can be updated based on the eliminated abnormal scenarios, and the corresponding communication protocol layer in the abnormal test model can be re-injected based on the updated abnormal script to be injected to obtain an updated abnormal test model.

[0114] For example, the fault detection rate (i.e., occurrence frequency) of each abnormal scenario is statistically analyzed by comparing the output data of the abnormal test model with the target comparison data, and redundant scenarios with a fault detection rate greater than 90% (such as pure delay injection that does not trigger new errors in 5 consecutive tests) are removed (i.e., abnormal scenarios with an occurrence frequency greater than a preset occurrence frequency are eliminated) to reduce invalid execution time, concentrate resources on scenarios that are more likely to trigger new defects, and improve the defect discovery rate per unit time.

[0115] The benefit of this setup is that by adjusting the exception test model based on the comparison results and re-executing the test using the optimized solution, this closed-loop optimization process not only improves test efficiency, but also quickly discovers and fixes potential problems, thereby improving the quality and stability of the target database driver.

[0116] The technical solution of the embodiment of the present invention is to obtain the to-be-processed traffic of the target database and determine the protocol feature information corresponding to at least one data packet in the to-be-processed traffic; generate at least one exception script to be injected based on the protocol feature information of each data packet and the protocol state machine corresponding to the target database; determine the communication protocol layer corresponding to each exception script to be injected, and inject it to obtain an exception test model; obtain the output data of the protocol exception test type in real time, and obtain the output data of the target database in a normal execution state as the target comparison data; compare the output data and the target comparison data based on the consistency verification rule, and generate a test report based on the comparison result. By determining the frequency of occurrence of abnormal scenarios of the abnormal test model during the test process based on the test report, and eliminating abnormal scenarios with a frequency greater than the preset frequency, and updating the abnormal test model according to the to-be-injected exception script corresponding to the eliminated abnormal scenario, the problem of redundant scenario testing and low test speed in the prior art of database testing is solved, and the effect of improving the test speed is achieved while meeting the requirements of abnormal scenario coverage.

[0117] Example 3

[0118] Figure 3 This is a schematic diagram of the structure of a database testing device provided in the third embodiment of the present invention. Figure 3 As shown, the apparatus includes: a traffic acquisition module 310 , a script generation module 320 , a model generation module 330 and a report generation module 340 .

[0119] The traffic acquisition module 310 is configured to acquire the traffic to be processed from the target database and determine protocol feature information corresponding to at least one data packet in the traffic to be processed;

[0120] The script generation module 320 is configured to generate at least one exception script to be injected based on the protocol feature information of each data packet and the protocol state machine corresponding to the target database; wherein the protocol state machine includes at least one communication protocol layer;

[0121] The model generation module 330 is used to determine the communication protocol layer corresponding to each abnormal script to be injected, and inject it to obtain an abnormal test model;

[0122] The report generation module 340 is used to generate a test report based on the comparison results of the output data of the abnormal test model and the target comparison data corresponding to the target database.

[0123] The technical solution of the embodiment of the present invention is to obtain the to-be-processed traffic of the target database and determine the protocol characteristic information corresponding to at least one data packet in the to-be-processed traffic; generate at least one to-be-injected exception script based on the protocol characteristic information of each data packet and the protocol state machine corresponding to the target database; determine the communication protocol layer corresponding to each to-be-injected exception script and inject it to obtain an exception test model; and generate a test report based on the comparison result of the output data of the exception test model and the target comparison data corresponding to the target database. In this technical solution, the to-be-processed traffic is obtained by capturing the traffic packets of the preset port of the target database, and the protocol characteristic information corresponding to the data packet is extracted from the to-be-processed traffic. At the same time, a protocol state machine is constructed based on the state transition information in the protocol interaction process of the target database, so as to establish an exception scenario based on the protocol characteristic information of each data packet and the protocol state machine, and the to-be-injected exception script corresponding to the exception scenario is injected into the corresponding communication protocol layer to construct an exception test model corresponding to the target database. The problem of insufficient coverage of abnormal scenarios of the database and failure to adapt to the characteristics of the database for abnormal detection in the existing technology is solved. The corresponding abnormal test model is constructed according to the protocol interaction characteristics of the database. By adding abnormal scenarios to the abnormal test model, the coverage of the test scenario for abnormal situations in the real network is improved, so that the security test effect of the target database can be carried out in a targeted manner according to the protocol characteristics of the target database.

[0124] Optionally, the traffic acquisition module includes: a packet capture unit, configured to capture packets on a preset port of the target database to obtain traffic to be processed;

[0125] An information determination unit is used to parse and process each data packet in the traffic to be processed based on preset detection rules to obtain protocol feature information corresponding to each data packet; wherein the protocol feature information includes at least one of the type, fixed bytes or key fields of the data packet.

[0126] Optionally, the script generation module includes: a state machine construction unit, configured to construct a protocol state machine corresponding to the target database;

[0127] an abnormal scenario simulation unit, configured to determine, for each communication protocol layer of the protocol state machine, at least one associated data packet associated with the current communication protocol layer, and simulate an abnormal scenario corresponding to the current communication protocol layer based on protocol feature information of the associated data packet; wherein the abnormal scenario includes at least one of delay injection, packet loss simulation, out-of-order attack, and connection pool contention under high latency;

[0128] The script generation unit is used to convert the abnormal scenario into a script to obtain the abnormal script to be injected corresponding to the current communication protocol layer.

[0129] Optionally, the state machine construction unit includes: a conversion information determination subunit, configured to determine state conversion information between each protocol interaction state according to at least one protocol interaction state during use of the target database;

[0130] The state machine construction subunit is used to construct a protocol state machine corresponding to the target database according to the state transition information.

[0131] Optionally, the model generation module includes: a layer determination unit, configured to determine injection information corresponding to each abnormal script to be injected, and a communication protocol layer corresponding to each abnormal script to be injected; wherein the injection information includes at least one of an injection timing, an abnormal scenario type, and an injection method corresponding to the script to be injected;

[0132] The model generation unit is used to inject the exception script to be injected into the corresponding communication protocol layer to obtain an exception test model.

[0133] Optionally, the report generation module includes: a data acquisition unit for acquiring output data of the protocol anomaly test type in real time, and acquiring output data of the target database in a normal execution state as target comparison data;

[0134] The report generation unit is used to compare the output data with the target comparison data based on the consistency verification rules, and generate a test report according to the comparison results.

[0135] Optionally, the report generating unit includes: an abnormal scenario determining subunit, configured to determine abnormal data in the output data according to the comparison result, and determine an abnormal scenario corresponding to the abnormal data according to identification information associated with the abnormal data;

[0136] The elimination sub-unit is used to eliminate the corresponding abnormal scene and the corresponding abnormal script to be injected if the frequency of occurrence of the abnormal scene is greater than the preset frequency;

[0137] The repeated execution sub-unit is used to repeatedly execute the communication protocol layering corresponding to each abnormal script to be injected, and inject it to obtain an abnormal test model. According to the comparison results of the output data of the abnormal test model and the target comparison data corresponding to the target database, a test report is generated until the growth rate of the occurrence frequency of the abnormal scenario is less than the preset growth rate.

[0138] The database testing device provided in the embodiment of the present invention can execute the database testing method provided in any embodiment of the present invention, and has the corresponding functional modules and beneficial effects of the execution method.

[0139] Example 4

[0140] Figure 4A schematic diagram of the structure of an electronic device 10 according to an embodiment of the present invention is shown. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device may also represent various forms of mobile devices, such as personal digital assistants, cellular phones, smartphones, wearable devices (such as helmets, glasses, watches, etc.), and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely examples and are not intended to limit the implementation of the present invention described and / or claimed herein.

[0141] like Figure 4 As shown, electronic device 10 includes at least one processor 11 and memory, such as read-only memory (ROM) 12 and random access memory (RAM) 13, communicatively connected to at least one processor 11. The memory stores computer programs executable by the at least one processor. Processor 11 can perform various appropriate actions and processes based on the computer programs stored in ROM 12 or loaded from storage unit 18 into RAM 13. RAM 13 can also store various programs and data required for the operation of electronic device 10. Processor 11, ROM 12, and RAM 13 are interconnected via bus 14. An input / output (I / O) interface 15 is also connected to bus 14.

[0142] Multiple components in the electronic device 10 are connected to the I / O interface 15, including an input unit 16, such as a keyboard, a mouse, etc.; an output unit 17, such as various types of displays, speakers, etc.; a storage unit 18, such as a magnetic disk, an optical disk, etc.; and a communication unit 19, such as a network card, a modem, a wireless communication transceiver, etc. The communication unit 19 allows the electronic device 10 to exchange information / data with other devices via a computer network such as the Internet and / or various telecommunication networks.

[0143] Processor 11 can be any general-purpose and / or specialized processing component with processing and computing capabilities. Some examples of processor 11 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various specialized artificial intelligence (AI) computing chips, various processors running machine learning model algorithms, a digital signal processor (DSP), and any other suitable processor, controller, microcontroller, etc. Processor 11 executes the various methods and processes described above, such as the database testing method.

[0144] In some embodiments, the database testing method can be implemented as a computer program tangibly embodied in a computer-readable storage medium, such as storage unit 18. In some embodiments, part or all of the computer program can be loaded and / or installed on electronic device 10 via ROM 12 and / or communication unit 19. When the computer program is loaded into RAM 13 and executed by processor 11, one or more steps of the database testing method described above can be performed. Alternatively, in other embodiments, processor 11 can be configured to execute the database testing method in any other suitable manner (e.g., via firmware).

[0145] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field programmable gate arrays (FPGAs), application specific integrated circuits (ASICs), application specific standard products (ASSPs), systems on a chip (SOCs), complex programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments can include being implemented in one or more computer programs that are executable and / or interpreted on a programmable system that includes at least one programmable processor, which can be a special purpose or general purpose programmable processor that can receive data and instructions from a storage system, at least one input device, and at least one output device, and transmit data and instructions to the storage system, the at least one input device, and the at least one output device.

[0146] Computer programs for implementing the database testing methods of the present invention can be written in any combination of one or more programming languages. These computer programs can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device, such that, when executed by the processor, the computer programs implement the functions / operations specified in the flowcharts and / or block diagrams. The computer programs can be executed entirely on the machine, partially on the machine, as a stand-alone software package, partially on the machine and partially on a remote machine, or entirely on a remote machine or server.

[0147] In the context of the present application, a computer-readable storage medium can be a tangible medium that can contain or store a computer program for use by or in connection with an instruction execution system, apparatus, or device. A computer-readable storage medium can include, but is not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. Alternatively, a computer-readable storage medium can be a machine-readable signal medium. More specific examples of a machine-readable storage medium will include one or more lines of a program of instructions in a transitory signal, a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.

[0148] To provide for interaction with a user, the systems and techniques described here can be implemented on an electronic device having a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the user and a keyboard and a pointing device (e.g., a mouse or a trackball) by which the user can provide input to the electronic device. Other kinds of devices can be used to provide for interaction with a user as well; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form, including acoustic, speech, or tactile input.

[0149] The systems and techniques described here can be implemented in a computing system that includes a back end component (e.g., as a data server), or that includes a middleware component (e.g., an application server), or that includes a front end component (e.g., a user computer having a graphical user interface or a Web browser through which a user can interact with an implementation of the systems and techniques described here), or any combination of such back end, middleware, or front end components. The components of the system can be interconnected by any form or medium of digital data communication (e.g., a communication network). Examples of communication networks include a local area network (LAN), a wide area network (WAN), blockchain network, and the Internet.

[0150] A computing system may include clients and servers. The clients and servers are typically remote from each other and typically interact via a communication network. This client-server relationship arises through computer programs running on the respective computers, creating a client-server relationship. The server may be a cloud server, also known as a cloud computing server or cloud host. This server is a hosting product within the cloud computing service ecosystem that addresses the management difficulties and limited scalability of traditional physical hosting and VPS services.

[0151] Example 5

[0152] An embodiment of the present invention further provides a computer program product, including a computer program, which, when executed by a processor, implements the database testing method provided in any embodiment of the present application.

[0153] During implementation, the computer program product may be written in one or more programming languages ​​or a combination thereof to perform the operations of the present invention. The programming languages ​​include object-oriented programming languages ​​such as Java, Smalltalk, C++, and conventional procedural programming languages ​​such as "C" or similar programming languages. The program code may be executed entirely on the user's computer, partially on the user's computer, as a stand-alone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving a remote computer, the remote computer may be connected to the user's computer via any type of network, including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0154] It should be understood that the various forms of the processes shown above can be used to reorder, add, or delete steps. For example, the steps described in the present invention can be performed in parallel, sequentially, or in a different order, as long as the desired results of the technical solution of the present invention can be achieved. This is not limited herein.

[0155] The above specific embodiments do not limit the scope of protection of the present invention. Those skilled in the art will appreciate that various modifications, combinations, sub-combinations, and substitutions may be made based on design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of the present invention are intended to be included within the scope of protection of the present invention.

Claims

1. A database testing method, characterized in that: include: Obtaining to-be-processed traffic from a target database, and determining protocol feature information corresponding to at least one data packet in the to-be-processed traffic; According to at least one protocol interaction state of the target database during use, determining state transition information between the protocol interaction states; Constructing a protocol state machine corresponding to the target database according to the state transition information; wherein the protocol state machine includes at least one communication protocol layer; For each communication protocol layer of the protocol state machine, determine at least one associated data packet associated with the current communication protocol layer, and simulate an abnormal scenario corresponding to the current communication protocol layer based on protocol feature information of the associated data packet; wherein the abnormal scenario includes at least one of delay injection, packet loss simulation, out-of-order attack, and connection pool contention under high latency; Convert the abnormal scenario into a script to obtain an abnormal script to be injected corresponding to the current communication protocol layer; Determine the communication protocol layer corresponding to each abnormal script to be injected, and inject it to obtain an abnormal test model; A test report is generated based on the comparison results of the output data of the abnormal test model and the target comparison data corresponding to the target database.

2. The method according to claim 1, characterized in that The obtaining of the to-be-processed traffic of the target database and determining protocol feature information corresponding to at least one data packet in the to-be-processed traffic includes: Capturing packets on a preset port of the target database to obtain traffic to be processed; For each data packet in the traffic to be processed, the data packet is parsed and processed based on preset detection rules to obtain protocol feature information corresponding to each data packet; wherein the protocol feature information includes at least one of the type, fixed bytes or key fields of the data packet.

3. The method according to claim 1, characterized in that The determining of the communication protocol layer corresponding to each abnormal script to be injected and injecting the protocol layer to obtain an abnormal test model includes: Determining injection information corresponding to each of the abnormal scripts to be injected, and a communication protocol layer corresponding to each of the abnormal scripts to be injected; wherein the injection information includes at least one of an injection timing, an abnormal scenario type, and an injection method corresponding to the abnormal script to be injected; The exception script to be injected is injected into the corresponding communication protocol layer to obtain an exception test model.

4. The method according to claim 1, wherein The generating of a test report according to a comparison result of the output data of the abnormal test model and the target comparison data corresponding to the target database includes: Acquire the output data of the protocol abnormality test type in real time, and acquire the output data of the target database in a normal execution state as target comparison data; The output data and the target comparison data are compared based on consistency verification rules, and a test report is generated according to the comparison results.

5. The method according to claim 4, characterized in that The comparing the output data with the target comparison data based on the consistency verification rule and generating a test report according to the comparison result includes: Determining abnormal data in the output data according to the comparison result, and determining an abnormal scenario corresponding to the abnormal data according to identification information associated with the abnormal data; If the occurrence frequency of the abnormal scenario is greater than the preset occurrence frequency, the corresponding abnormal scenario and the corresponding abnormal script to be injected are eliminated; Repeat the process of determining the communication protocol layer corresponding to each abnormal script to be injected and injecting it to obtain an abnormal test model. Generate a test report based on the comparison results of the output data of the abnormal test model and the target comparison data corresponding to the target database until the growth rate of the occurrence frequency of the abnormal scenario is less than the preset growth rate.

6. A database testing device, characterized in that: include: A traffic acquisition module, configured to acquire the to-be-processed traffic of a target database and determine protocol feature information corresponding to at least one data packet in the to-be-processed traffic; a conversion information determining subunit, configured to determine state conversion information between the protocol interaction states according to at least one protocol interaction state during use of the target database; A state machine construction subunit, configured to construct a protocol state machine corresponding to the target database according to the state transition information; wherein the protocol state machine includes at least one communication protocol layer; an abnormal scenario simulation unit, configured to determine, for each communication protocol layer of the protocol state machine, at least one associated data packet associated with the current communication protocol layer, and simulate an abnormal scenario corresponding to the current communication protocol layer based on protocol feature information of the associated data packet; wherein the abnormal scenario includes at least one of delay injection, packet loss simulation, out-of-order attack, and connection pool contention under high latency; A script generation unit, configured to convert the abnormal scenario into a script to obtain an abnormal script to be injected corresponding to the current communication protocol layer; The model generation module is used to determine the communication protocol layer corresponding to each abnormal script to be injected, and inject it to obtain an abnormal test model; The report generation module is used to generate a test report based on the comparison results of the output data of the abnormal test model and the target comparison data corresponding to the target database.

7. An electronic device, characterized in that: The electronic device comprises: at least one processor; and a memory communicatively connected to the at least one processor; wherein, The memory stores a computer program that can be executed by the at least one processor. The computer program is executed by the at least one processor to enable the at least one processor to perform the database testing method according to any one of claims 1 to 5.

8. A computer-readable storage medium, characterized in that The computer-readable storage medium stores computer instructions, and the computer instructions are used to enable a processor to implement the database testing method according to any one of claims 1 to 5 when executed.

Images