Embedded database compatibility test method and apparatus

By dynamically instrumenting embedded databases using eBPF technology to obtain their call information and generate a test case library, the problem of long testing cycles and low efficiency in embedded database compatibility testing is solved, achieving efficient compatibility testing and reducing replacement costs.

CN118860851BActive Publication Date: 2026-03-31粤港澳大湾区(广东)国创中心
View PDF 2 Cites 0 Cited by

Patent Information

Authority / Receiving Office
CN · China
Patent Type
Patents(China)
Current Assignee / Owner
Filing Date
2024-06-21
Publication Date
2026-03-31

AI Technical Summary

Technical Problem

In existing technologies, the embedded database compatibility testing process is time-consuming and inefficient, and cannot efficiently cover all SQL syntax and API interfaces used in the application, resulting in high replacement costs.

Method used

A tracing tool based on eBPF technology is used to insert stubs into the target application's program files through dynamic instrumentation, obtain call information, generate a test case library that matches the new database, and run the test case library in the new database to perform compatibility testing.

Benefits of technology

It reduces the workload and cost of compatibility testing, improves testing efficiency, avoids the workload of modifying application and original database code, and ensures test coverage and efficiency.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN118860851B_ABST
    Figure CN118860851B_ABST
Patent Text Reader

Abstract

The application provides an embedded database compatibility test method and device, the method comprises the following steps: inserting a plurality of stub points into the program file of the original database used by the target application program in a dynamic stubbing manner by using a tracking tool based on eBPF technology; acquiring the calling information of the plurality of stub points of the target application program within a preset running time; generating a test case library matched with the new database based on the calling information by using a preset test library generation program; running all the test cases in the test case library in the new database, and outputting the compatibility test result of the new database; the tracking tool based on eBPF technology is used to capture the related information of the SQL syntax and API interface called by the embedded database to the target application program, meanwhile, the compatibility test case library is generated, and the SQL syntax, API interface compatibility test, performance test and data consistency test of the new database are directly performed, so that the compatibility test efficiency can be effectively improved, and the database replacement cost can be reduced.
Need to check novelty before this filing date? Find Prior Art

Description

TECHNICAL FIELD

[0001] The application belongs to the technical field of database testing, and particularly relates to an embedded database compatibility testing method and device. BACKGROUND

[0002] A database is a structured data storage system used to effectively organize, store and manage large amounts of data. It is one of the most important infrastructures in the field of information technology, widely used in various fields, including but not limited to e-commerce, finance, medicine, education and scientific research.

[0003] With the continuous development of technology, database technology is also evolving. Although traditional database systems perform well in many aspects, in some cases, replacing existing databases may be necessary as technology rapidly evolves. Here are some reasons that may lead to the replacement of database technology: such as the improvement of storage device performance, the improvement of performance requirements, big data and real-time data processing, cloud-native and containerization trends, new data storage requirements, security and compliance requirements, etc.

[0004] Replacing a database is a complex and important task, and compatibility testing plays a crucial role. Compatibility testing aims to ensure that the new database system can work with existing systems and applications, while maintaining data consistency, integrity and security. Here are some key reasons for conducting compatibility testing:

[0005] 1. Data migration and conversion: When replacing a database, existing data usually needs to be migrated to the new system. Compatibility testing can verify the accuracy and integrity of the data migration process, ensuring that data is not lost or damaged during the conversion process.

[0006] 2. Application adaptation: Many enterprise applications are designed and developed for specific database systems. When replacing a database, it must be ensured that the new system is compatible with existing applications and does not negatively affect the functionality and performance of the application. Compatibility testing can help identify and resolve issues related to application integration.

[0007] 3. SQL syntax and API interface compatibility: Different database systems may have different SQL syntax and API interface designs. When replacing a database, it must be ensured that the new system supports the SQL syntax and API interface used in the existing system to ensure compatibility of queries and operations. Compatibility testing can verify whether the SQL syntax and functionality of the new system are consistent with the existing system.

[0008] 4. Performance and scalability testing: Replacing the database can have an impact on system performance and scalability. Compatibility testing can evaluate the performance of the new system in handling large-scale data or high concurrency access, and determine whether it meets business requirements. In addition, compatibility testing can also evaluate the scalability of the new system to ensure stable performance as business grows and data volume increases.

[0009] Since one database is not usually used in all SQL syntax and API interfaces in a certain application scenario, when replacing the database, the SQL syntax and API interfaces used in the current application need to be found, and these used SQL syntax and API interfaces are given priority in database replacement work. At the same time, in some complex business systems, complex SQL statements may trigger some BUGs of the new database, and only simple SQL syntax and API interface testing may not cover the compatibility of this part of the business in the new database.

[0010] For server databases such as openGauss, MySQL, and Oralce, they are run in the form of independent processes, and applications access databases through network interfaces. SQL syntax and interfaces used by application business can be captured through network packet capture or by rewriting JDBC interface functions.

[0011] For embedded databases, applications generally directly reference database program files and call API interfaces provided by program files for data operations, so the above two schemes cannot be used to capture the used SQL syntax and API interfaces. To replace the original embedded database with a new database and ensure compatibility of the application to the new database, there are the following schemes, which have a large amount of work to implement and low efficiency:

[0012] (1) The new database is compatible with all SQL syntax and API interfaces of the original database.

[0013] This scheme has a very large amount of work, and some SQL syntax and API interfaces are not used, resulting in a waste of manpower.

[0014] (2) Directly replace the original database with the new database and run in the business scenario. After the API interface error, develop and adapt.

[0015] This scheme has a long test cycle and low efficiency, and cannot guarantee that all used SQL syntax and API interfaces have been covered.

[0016] (3) Modify the original database source code, output relevant information and record when calling API interfaces, and adapt according to the output interface record after running in the business scenario.

[0017] This solution has high learning cost and operation cost, modifies and compiles a special version, replaces the original database in the application or device, and the overall solution is complex and time-consuming.

[0018] Secondly, after the new database completes compatibility development, it needs to be tested in a business scenario, including the correctness of functions and data and performance, to ensure that the replacement does not affect the correctness and running efficiency of the application. In the current solution, the original database in the application is replaced with the new database, and then the application is run in the business scenario to test the application function. After problems are found, the process of "modifying the database-updating the application-testing the application" is cycled until the application test is passed. This solution has a long cycle and low efficiency. SUMMARY

[0019] In order to overcome the shortcomings of the prior art, the present application provides an embedded database compatibility test method and device to solve the problem of long test cycle and low efficiency of the compatibility test process of the embedded database in the prior art.

[0020] One embodiment of the present application provides an embedded database compatibility test method, comprising the following steps:

[0021] A tracking tool based on eBPF technology is used to insert a plurality of stub points in the program file of the original database used by the target application program through dynamic stubbing;

[0022] Obtain the calling information of the plurality of stub points of the target application program within a preset running time;

[0023] Generate a test case library matched with the new database based on the calling information through a preset test library generation program;

[0024] Run all use cases in the test case library in the new database, and output the compatibility test result of the new database.

[0025] In this embodiment, the present application develops a tracking tool through eBPF technology to capture the relevant information of SQL syntax and API interface called by the embedded database to the target application program, avoids the workload of modifying the application and modifying the original database code, can effectively reduce the workload of compatibility testing, reduce the database replacement cost, at the same time, generates a compatibility test case library, directly tests the SQL syntax, API interface compatibility, performance and data consistency of the new database, can avoid the step of packaging the new database into the application for testing, can effectively improve the compatibility test efficiency and reduce the database replacement cost.

[0026] In one embodiment, a tracing tool based on eBPF technology is used to insert several stubs into the program file of the original database used by the target application through dynamic instrumentation, including:

[0027] The eBPF-based tracing tool generates eBPF instructions, which are then loaded into the Linux kernel.

[0028] The eBPF instructions are converted into localized instructions using a just-in-time compiler, and the localized instructions are then sent to the runtime module.

[0029] In the runtime module, the localization instructions are inserted into the API interface functions of the program file using the uprobes technique.

[0030] In one embodiment, after generating eBPF instructions using the eBPF-based tracing tool and loading the eBPF instructions into the Linux kernel, and before converting the eBPF instructions into localized instructions using a just-in-time compiler and sending the localized instructions to the runtime module, the process includes:

[0031] The eBPF instruction is sent to the verifier, and the verifier performs security verification on the eBPF instruction.

[0032] When verification fails, a verification failure message is returned so that the tracking tool can resend the eBPF command;

[0033] When verification is successful, the verified eBPF instruction is forwarded to the just-in-time compiler through the verifier.

[0034] In one embodiment, a test case library matching the new database is generated based on the called information using a preset test library generation program, including:

[0035] Based on the called information, the SQL statements and API interface call information of the target running program to the program file of the original database within the preset running time are determined;

[0036] The preset test library generator integrates the SQL statements and API interface call information, converting them into a test case library executable by the new database.

[0037] In one embodiment, determining the SQL statements and API interface call information of the target running program to the program file of the original database within the preset running time based on the called information includes:

[0038] Obtain the localized instruction that is invoked within a preset runtime of the target running program;

[0039] Determine the API interface function where each of the localized instructions is invoked, and determine the SQL statement and API interface call information corresponding to the API interface function;

[0040] The SQL statements and API call information corresponding to the API interface functions are obtained through a tracing tool based on eBPF technology, and the SQL statements and API call information are organized and stored in the result storage unit.

[0041] In one embodiment, the SQL statement and API call information corresponding to the API interface function are obtained through a tracing tool based on eBPF technology, and the SQL statement and API call information are organized and stored in the result storage unit, including:

[0042] Based on the eBPF live module, the SQL statements and API interface call information are stored in eBPF maps;

[0043] The tracking tool based on eBPF technology retrieves the SQL statements and API interface call information from the eBPF maps at a predetermined frequency, and organizes and stores the SQL statements and API interface call information in the result storage unit.

[0044] In one embodiment, all test cases in the test case library are run in the new database, and compatibility test results for the new database are output, including:

[0045] If the compatibility test results contain SQL statements or API interfaces that are incompatible with the new database, then the incompatible SQL statements or API interfaces are modified, and the test cases are re-executed until the test report meets the preset requirements.

[0046] One embodiment of the present invention also provides an embedded database compatibility testing device, comprising:

[0047] The dynamic instrumentation module is used by a tracing tool based on eBPF technology to insert several instrumentation points into the program file of the original database used by the target application through dynamic instrumentation.

[0048] The acquisition module is used to acquire the invocation information of the target application for a number of stubs within a preset running time.

[0049] The test case generation module is used to generate a test case library that matches the new database based on the called information, through a preset test library generation program.

[0050] The testing module is used to run all test cases in the test case library in the new database and output the compatibility test results for the new database.

[0051] In this embodiment, the advantages and beneficial effects of the embedded database compatibility testing method have been described above and will not be repeated here. Furthermore, since the embedded database compatibility testing device uses the embedded database compatibility testing method, it also has the same advantages and beneficial effects.

[0052] One embodiment of the present invention also provides a readable storage medium storing a computer program, the computer program including program instructions, which, when executed by a processor of an electronic device, cause the processor to perform the steps of any of the embedded database compatibility testing methods described above.

[0053] One embodiment of the present invention also provides an electronic device, including: a processor and a memory, the memory being used to store computer program code, the computer program code including computer instructions, and when the processor executes the computer instructions, the electronic device performs the steps of any of the embedded database compatibility testing methods described above. Attached Figure Description

[0054] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on the structures shown in these drawings without creative effort.

[0055] Figure 1 This is a flowchart illustrating an embedded database compatibility testing method provided in one embodiment of the present invention.

[0056] Figure 2 for Figure 1 A schematic diagram of the sub-processes of S100;

[0057] Figure 3 This is a schematic diagram illustrating the working principle of an electronic device provided in one embodiment of the present invention. Detailed Implementation

[0058] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of the present invention, and not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of the present invention.

[0059] It should be noted that if the embodiments of the present invention involve directional indicators (such as up, down, left, right, front, back, etc.), the directional indicators are only used to explain the relative positional relationship and movement of the components in a specific posture. If the specific posture changes, the directional indicators will also change accordingly.

[0060] Furthermore, if the embodiments of this invention involve descriptions such as "first" or "second," these descriptions are for descriptive purposes only and should not be construed as indicating or implying their relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined with "first" or "second" may explicitly or implicitly include at least one of those features. Additionally, the use of "and / or" or "and / or" throughout the text includes three parallel solutions. For example, "A and / or B" includes solution A, solution B, or a solution where both A and B are satisfied simultaneously. Furthermore, the technical solutions of the various embodiments can be combined with each other, but this must be based on the ability of those skilled in the art to implement them. When the combination of technical solutions is contradictory or impossible to implement, it should be considered that such a combination of technical solutions does not exist and is not within the scope of protection claimed by this invention.

[0061] As technology continues to advance, database technology is also constantly evolving. While traditional database systems perform excellently in many ways, in some cases, rapid technological advancements necessitate replacing existing databases. Replacing a database is a complex and crucial task, where compatibility testing plays a vital role. Compatibility testing aims to ensure that the new database system can work seamlessly with existing systems and applications, while maintaining data consistency, integrity, and security. However, existing database replacement solutions are labor-intensive and inefficient, resulting in excessively high replacement costs.

[0062] This invention utilizes eBPF technology to develop a tracing tool that captures information about the SQL syntax and API interfaces called by the target application from the embedded database. This avoids the workload of modifying the application and the original database code, effectively reducing the workload of compatibility testing and the cost of database replacement. Simultaneously, it generates a compatibility test case library, allowing direct testing of the new database's SQL syntax, API interface compatibility, performance, and data consistency. This avoids the need to package the new database into the application for testing, effectively improving compatibility testing efficiency and reducing database replacement costs.

[0063] Please see Figures 1-3 One embodiment of the present invention provides an embedded database compatibility testing method, comprising the following steps:

[0064] S100 uses a tracing tool based on eBPF technology to insert several stubs into the program file of the original database used by the target application through dynamic instrumentation.

[0065] In this embodiment, eBPF (Extended Berkeley Packet Filter) technology is a technique used in Linux.

[0066] eBPF, a virtual machine technology running within the kernel, provides a flexible and secure way to extend kernel functionality. Originally designed for efficient network packet filtering, it has now expanded to other areas such as security monitoring, performance analysis, and system tracing. This technology allows users to extend kernel functionality by loading and executing custom eBPF programs without modifying the kernel source code. These eBPF programs interact with the kernel through a hook mechanism, filtering and processing events entering and leaving the kernel to achieve functions such as network packet monitoring, performance statistics, and security auditing.

[0067] In this embodiment, the tracing tool using eBPF technology can insert several stubs into the program files of the original database that the target application needs to use, without modifying the kernel source code of the original database. Dynamic instrumentation means that before the target application calls the corresponding program file, the program file is instrumented according to the actual situation of the original database to obtain several stubs. Dynamic instrumentation can effectively reduce the number of stubs required. It can be understood that, without considering the cost of use or in specific application scenarios, stubs can be inserted at the entry point of each API function in the program file.

[0068] In this embodiment, each stub can act as a probe to investigate the call status of the target application. Therefore, based on eBPF technology, dynamic instrumentation can be used to dynamically analyze the original database without modifying it, which reduces testing costs and improves testing efficiency.

[0069] In one embodiment, such as Figure 2 As shown, a tracing tool based on eBPF technology is used to insert several stubs into the program file of the original database used by the target application through dynamic instrumentation, including:

[0070] Step S110: Generate eBPF instructions using the eBPF-based tracing tool and load the eBPF instructions into the Linux kernel;

[0071] Step S120: The eBPF instructions are converted into localized instructions based on the just-in-time compiler, and the localized instructions are sent to the runtime module.

[0072] Step S130: In the runtime module, the localization instructions are inserted into the API interface functions of the program file using the uprobes technique.

[0073] In this embodiment, an eBPF-based tracing tool can generate eBPF instructions and load them into the Linux kernel. A just-in-time (JIT) compiler can then convert these eBPF instructions into localized instructions. These localized instructions are transmitted to a runtime module, where uprobes are used to insert them into the API interface functions of the program file. This allows for program file instrumentation without modifying the original database source code. Each stub is the location where an eBPF instruction is inserted into an API interface function.

[0074] In this embodiment, uprobes are an important feature of the eBPF subsystem. They allow us to dynamically insert probe points into user-space applications to trace function calls or instruction execution for performance analysis and debugging. The implementation of uprobes relies on the ftrace framework in the kernel, which utilizes a mechanism similar to kprobes in kernel space, but specifically for user space. Uprobes replaces the entry point instructions of the target function with breakpoint instructions in the memory of the user-space program and captures relevant information, such as the current value of the program counter (PC) and function parameters. This information can be accessed and analyzed through mechanisms such as perf_events in the eBPF program to identify application performance bottlenecks or errors.

[0075] In one embodiment, after generating eBPF instructions using the eBPF-based tracing tool and loading the eBPF instructions into the Linux kernel, and before converting the eBPF instructions into localized instructions using a just-in-time compiler and sending the localized instructions to the runtime module, the process includes:

[0076] Step S140: Send the eBPF instruction to the verifier and perform security verification on the eBPF instruction through the verifier.

[0077] Step S150: When verification fails, return verification failure information so that the tracking tool can resend the eBPF command;

[0078] Step S160: When the verification is successful, the verified eBPF instruction is forwarded to the just-in-time compiler through the verifier.

[0079] In this embodiment, to ensure that the eBPF instructions themselves do not crash or damage the kernel, the generated eBPF instructions need to be security verified. After the eBPF-based tracing tool generates the eBPF instructions, they are first sent to the verifier, which verifies their security. If the verification is successful, the verifier forwards them to the compiler for localization instruction conversion. If the verification fails, a verification failure message, such as an alarm signal, can be sent to alert staff that there is a problem with the eBPF instructions so that they can be investigated in time. After the cause of the eBPF instruction anomaly is investigated, the eBPF-based tracing tool resends the eBPF instructions to the verifier.

[0080] S200: Obtain the invocation information of the target application's several stubs within a preset running time.

[0081] In this embodiment, the eBPF-based tracing tool is run for a period of time in the actual running environment of the target application. At this time, the call status of each stub in the target application within the preset running time is selected to generate call information. In order to ensure the accuracy of the call information, the preset running time should be as long as possible, and not less than a certain preset time value, so as to ensure that enough call status of each stub can be obtained.

[0082] S300. A test case library matching the new database is generated based on the called information by a preset test library generation program.

[0083] In this embodiment, a compatibility test case library can be generated by using a tracing tool and a preset test library generator. This allows for direct testing of the new database's SQL syntax, API interface compatibility, performance, and data consistency. This avoids the need to package the new database into the application for testing, effectively improving compatibility testing efficiency and reducing database replacement costs.

[0084] In one embodiment, a test case library matching the new database is generated based on the called information using a preset test library generation program, including:

[0085] Step S310: Based on the called information, determine the SQL statements and API interface call information of the target running program to the program file of the original database within the preset running time.

[0086] Step S320: The SQL statements and API interface call information are integrated by the preset test library generation program and converted into a test case library executable by the new database.

[0087] In this embodiment, since eBPF instructions are dynamically instrumented into the program file, the eBPF instructions will be invoked before the target program calls the required SQL statements and API interfaces within the preset runtime. Therefore, based on the eBPF instruction invocation information, the SQL statements and API interface invocation information of the original database program file can be known. Then, by generating a program through a preset test library, the SQL statements and API interface invocation information are integrated and converted into a test case library executable for the new database. Through the test case library, SQL syntax, API interface compatibility testing, performance testing, and data consistency testing can be performed directly on the new database, avoiding the step of having to package the new database into the application for testing.

[0088] In one embodiment, determining the SQL statements and API interface call information of the target running program to the program file of the original database within the preset running time based on the called information includes:

[0089] Obtain the localized instruction that is invoked within a preset runtime of the target running program;

[0090] Determine the API interface function where each of the localized instructions is invoked, and determine the SQL statement and API interface call information corresponding to the API interface function;

[0091] The SQL statements and API call information corresponding to the API interface functions are obtained through a tracing tool based on eBPF technology, and the SQL statements and API call information are organized and stored in the result storage unit.

[0092] In this embodiment, the invoked localized instruction is actually an eBPF instruction. Since the eBPF instruction has been converted into a localized instruction in the previous steps, the invoked localized instruction is obtained, and the insertion position of the invoked localized instruction is determined. Then, its corresponding API interface function is determined, and the required SQL statement and API interface call information are obtained according to the API interface function. The call information includes, but is not limited to, API interface name, number of calls, call time, call parameters, and SQL statements executed.

[0093] The issued eBPF commands are tracked in real time using a tracking tool based on eBPF technology. The SQL statements and API interface call information at the eBPF insertion position are obtained and the SQL statements and API interface call information are organized and stored in the result storage unit.

[0094] In one embodiment, the SQL statement and API call information corresponding to the API interface function are obtained through a tracing tool based on eBPF technology, and the SQL statement and API call information are organized and stored in the result storage unit, including:

[0095] Based on the eBPF live module, the SQL statements and API interface call information are stored in eBPF maps;

[0096] The tracking tool based on eBPF technology retrieves the SQL statements and API interface call information from the eBPF maps at a predetermined frequency, and organizes and stores the SQL statements and API interface call information in the result storage unit.

[0097] In this embodiment, by using the eBPF instructions developed in the tracing tool, we can capture key information such as the interface name, SQL statement, parameters, return value, and interface call time of the business code calling the original embedded database API interface in the target application. The eBPF runtime module will store this captured information in eBPF maps6, and the tracing tool 1 can obtain data from eBPF maps in a timely manner, organize it, and store it in the results storage.

[0098] By following the steps above, it is possible to capture the SQL statements executed in the database and the relevant information of the called interfaces through tracing tools without modifying the original application and the original embedded database.

[0099] S400. Run all test cases in the test case library in the new database and output the compatibility test results for the new database.

[0100] In this embodiment, all test cases from the test case library are run directly in the new database, and compatibility is corrected based on the test results, without having to package the new database into the application for testing. This can effectively improve the efficiency of compatibility testing and reduce the cost of database replacement.

[0101] In one embodiment, all test cases in the test case library are run in the new database, and compatibility test results for the new database are output, including:

[0102] If the compatibility test results contain SQL statements or API interfaces that are incompatible with the new database, then the incompatible SQL statements or API interfaces are modified, and the test cases are re-executed until the test report meets the preset requirements.

[0103] In this embodiment, all test cases in the test case library are run on the new database, and corresponding test reports are generated. Users can modify incompatible SQL statements and API interfaces based on the results, re-execute the test cases until the test report meets the replacement requirements, and then deploy them to the application for final testing. This approach eliminates the need to update the application after each modification and then test the application, while also ensuring consistent test coverage with application testing.

[0104] In summary, this solution has the following advantages:

[0105] 1. It can identify all SQL syntax and API interfaces used by the original database in the application without modifying the application and the original embedded database, thereby avoiding the learning, development and debugging costs caused by modifying the program and database code.

[0106] This application utilizes eBPF technology to develop a tracing tool on a Linux system. This tool dynamically instrumentes the application files of the original database used by the application, inserting call event stubs at the entry points of all API interface functions. When the application calls an API interface, eBPF technology can trace the call event's call time, interface name, interface parameters, and call duration. When the interface function returns, its return time and return value information can also be traced. The tracing tool stores this information and, after the application has run for a period, outputs call information such as the names, number of calls, call times, call parameters, and executed SQL statements of the API interfaces called by the database within the application during that period. By running this tracing tool in the actual application runtime environment for a period, or during a full application test, it can output the actual SQL statements and API call information of the original database during that period, without requiring any modifications to the application or the original database.

[0107] 2. It can generate a complete test library based on business scenarios and directly test the interface compatibility, performance and data consistency of the new database at the interface level, avoiding the process of "modifying the database - updating the application - testing the application", improving development efficiency and reducing development costs.

[0108] This application utilizes a tracing tool developed based on eBPF technology, running within the application's runtime environment to record all SQL statements and API calls executed by the source database during runtime. A test library generator is developed to integrate these records and transform them into a test case library executable on the new database. Running all test cases from this library on the new database generates corresponding test reports. Users can modify incompatible SQL statements and APIs based on the results, re-execute the test cases until the test report meets the replacement requirements, and then deploy the application for final testing. This approach eliminates the need for updating the application after each modification and then testing the application, while also ensuring consistent test coverage with the application testing.

[0109] One embodiment of the present invention also provides an embedded database compatibility testing device, comprising:

[0110] The dynamic instrumentation module is used by a tracing tool based on eBPF technology to insert several instrumentation points into the program file of the original database used by the target application through dynamic instrumentation.

[0111] The acquisition module is used to acquire the invocation information of the target application for a number of stubs within a preset running time.

[0112] The test case generation module is used to generate a test case library that matches the new database based on the called information, through a preset test library generation program.

[0113] The testing module is used to run all test cases in the test case library in the new database and output the compatibility test results for the new database.

[0114] One embodiment of the present invention also provides a readable storage medium storing a computer program, the computer program including program instructions, which, when executed by a processor of an electronic device, cause the processor to perform the steps of any of the embedded database compatibility testing methods described above.

[0115] One embodiment of the present invention also provides an electronic device, including: a processor and a memory, the memory being used to store computer program code, the computer program code including computer instructions, and when the processor executes the computer instructions, the electronic device performs the steps of any of the embedded database compatibility testing methods described above.

[0116] Please see Figure 3 , Figure 3 This is a schematic diagram of the hardware structure of an electronic device provided in an embodiment of the present invention.

[0117] The electronic device 2 includes a processor 21, a memory 22, an input device 23, and an output device 24. The processor 21, memory 22, input device 23, and output device 24 are coupled together via connectors, which may include various interfaces, transmission lines, or buses, etc., and are not limited in this embodiment of the invention. It should be understood that in various embodiments of the invention, coupling refers to mutual connection through a specific method, including direct connection or indirect connection through other devices, such as through various interfaces, transmission lines, buses, etc.

[0118] Processor 21 can be one or more graphics processing units (GPUs). If processor 21 is a GPU, the GPU can be a single-core GPU or a multi-core GPU. Optionally, processor 21 can be a processor group composed of multiple GPUs, with the multiple processors coupled to each other via one or more buses. Optionally, the processor can also be other types of processors, etc., and this embodiment of the invention is not limited thereto.

[0119] The memory 22 can be used to store computer program instructions, as well as various types of computer program code, including program code for executing the present invention. Optionally, the memory includes, but is not limited to, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), or compact disc read-only memory (CD-ROM), which is used for related instructions and data.

[0120] Input device 23 is used to input data and / or signals, and output device 24 is used to output data and / or signals. Output device 23 and input device 24 can be independent devices or an integrated device.

[0121] It is understood that in this embodiment of the invention, the memory 22 can be used not only to store related instructions, but also the specific data stored in the memory is not limited.

[0122] Understandable, Figure 3 This is merely a simplified design of an electronic device. In practical applications, the electronic device may also include other necessary components, including, but not limited to, any number of input / output devices, processors, memory, etc., and all video analysis devices that can implement embodiments of the present invention are within the protection scope of the present invention.

[0123] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementations should not be considered beyond the scope of this invention.

[0124] Those skilled in the art will readily understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here. Those skilled in the art will also readily understand that the various embodiments of the present invention have different focuses, and for the sake of convenience and brevity, the same or similar parts may not be repeated in different embodiments. Therefore, parts not described or not described in detail in one embodiment can be referred to in other embodiments.

[0125] In the embodiments provided by this invention, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between devices or units may be electrical, mechanical, or other forms.

[0126] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0127] In addition, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0128] In the above embodiments, implementation can be achieved entirely or partially through software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented entirely or partially as a computer program to be sealed. The computer program to be sealed includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the process or function described in the embodiments of the present invention is generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted through the computer-readable storage medium. The computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available media may be magnetic media (e.g., floppy disks, hard disks, magnetic tapes), optical media (e.g., digital versatile discs (DVDs)), or semiconductor media (e.g., solid-state disks (SSDs)).

[0129] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. This program can be stored in a computer-readable storage medium, and when executed, it can include the processes described in the above method embodiments. The aforementioned storage medium includes various media capable of storing program code, such as read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0130] The above description is merely a preferred embodiment of the present invention and does not limit the patent scope of the present invention. Any equivalent structural transformations made using the contents of the present invention's specification and drawings under the inventive concept of the present invention, or direct / indirect applications in other related technical fields, are included within the patent protection scope of the present invention.

Claims

1. An embedded database compatibility testing method, characterized by, The method comprises the following steps: generating eBPF instructions by a tracing tool based on eBPF technology, and loading the eBPF instructions into a Linux kernel; sending the eBPF instructions to a verifier, and performing security verification on the eBPF instructions by the verifier; when the verification fails, returning verification failure information to make the tracing tool resend the eBPF instructions; when the verification succeeds, forwarding the verified eBPF instructions to a just-in-time compiler by the verifier; converting the eBPF instructions into localized instructions based on the just-in-time compiler, and sending the localized instructions to a runtime module; in the runtime module, inserting the localized instructions into API interface functions of a program file by using an uprobes technology; obtaining called information of a plurality of stub points of a target application within a preset running time; generating a test case library matched with a new database based on the called information by a preset test library generation program, comprising: obtaining the called localized instructions within the preset running time of the target running program; determining the API interface functions where each called localized instruction is located, and determining the SQL statements and API interface calling information corresponding to the API interface functions; storing the SQL statements and API interface calling information in eBPF maps based on the eBPF runtime module; obtaining the SQL statements and API interface calling information from the eBPF maps at a predetermined frequency by the tracing tool based on the eBPF technology, and storing the SQL statements and API interface calling information in a result storage unit; integrating the SQL statements and API interface calling information by the preset test library generation program, and converting the SQL statements and API interface calling information into a test case library executable by the new database; running all the test cases in the test case library in the new database, and outputting a compatibility test result of the new database, comprising: when there are SQL statements or API interfaces incompatible with the new database in the compatibility test result, modifying the SQL statements or API interfaces incompatible with the new database, and re-executing the test cases until the test report meets the preset requirements.

2. An embedded database compatibility testing apparatus, characterized by, The method comprises the following steps: a dynamic stubbing module is configured to insert a plurality of stub points into a program file of an original database used by a target application by a tracing tool based on eBPF technology in a dynamic stubbing manner, comprising: generating eBPF instructions by the tracing tool based on eBPF technology, and loading the eBPF instructions into a Linux kernel; sending the eBPF instructions to a verifier, and performing security verification on the eBPF instructions by the verifier; when the verification fails, returning verification failure information to make the tracing tool resend the eBPF instructions; when the verification succeeds, forwarding the verified eBPF instructions to a just-in-time compiler by the verifier; converting the eBPF instructions into localized instructions based on the just-in-time compiler, and sending the localized instructions to a runtime module; in the runtime module, inserting the localized instructions into API interface functions of a program file by using an uprobes technology; An acquisition module is configured to acquire called information of a plurality of probe points of a target application program within a preset running time; The test library generation module is configured to generate a test case library matched with the new database based on the called information through a preset test library generation program, including: acquiring localized instructions called within a preset running time of the target running program; determining an API interface function where each called localized instruction is located, and determining SQL statements and API interface calling information corresponding to the API interface function; storing the SQL statements and the API interface calling information in eBPF maps based on an eBPF time module; acquiring the SQL statements and the API interface calling information from the eBPF maps at a predetermined frequency through a tracking tool based on the eBPF technology, and storing the SQL statements and the API interface calling information in a result storage unit; and integrating the SQL statements and the API interface calling information through the preset test library generation program, and converting the SQL statements and the API interface calling information into a test case library executable by the new database; The test module is configured to run all test cases in the test case library in the new database, and output a compatibility test result of the new database, including: when there is an SQL statement or an API interface incompatible with the new database in the compatibility test result, modifying the SQL statement or the API interface incompatible with the new database, and re-executing the test case until the test report meets a preset requirement.

3. An electronic device comprising: A processor and a memory, characterized in that the memory is configured to store computer program code, the computer program code includes computer instructions, when the processor executes the computer instructions, the electronic device executes the steps of the embedded database compatibility test method according to claim 1.

4. A readable storage medium, wherein the readable storage medium stores a computer program, and the computer program comprises the steps of the method according to any one of claims 1-3. The computer program includes program instructions, when the program instructions are executed by the processor of the electronic device, the processor executes the steps of the embedded database compatibility test method according to claim 1.

Citation Information

Patent Citations

  • Method for determining test coverage rate of application program, electronic equipment and program product

    CN116166522A

  • Database test method and device, electronic equipment and storage medium

    CN117806965A