Method for calculating PL / pgSQL function statement coverage in database and storage medium

Abstract

This invention provides a method for calculating PL / pgSQL function statement coverage in a database and a computer-readable storage medium. The method for calculating PL / pgSQL function statement coverage includes: inserting execution hooks into the critical execution path of the PL / pgSQL function executor to capture statement execution information; marking a bitmap array based on the statement execution information; and counting the number of executed statements based on the bitmap array to calculate the PL / pgSQL function statement coverage. This invention achieves accurate and real-time statement coverage acquisition through kernel-level execution hooks and bitmap marking, filling a technical gap in PL / pgSQL function coverage detection; it has extremely low performance overhead, supports concurrent and persistent storage, and efficiently completes coverage calculation without affecting database operation.

Description

Technical Field

[0001] This invention relates to the field of database technology, and in particular to a method for calculating the coverage of PL / pgSQL function statements in a database and a computer-readable storage medium. Background Technology

[0002] Code coverage in databases is an important metric for measuring test completeness. It indicates what percentage of the source code was executed during test execution. Common code coverage metrics include: a. Statement coverage: whether every statement in the code was executed; b. Branch coverage: whether every control flow branch such as if-else and switch was executed; c. Function coverage: whether every function was called.

[0003] Code coverage testing can identify untested code, such as code that is completely untouched by tests or code areas that are difficult to cover due to logical complexity. At the same time, code coverage testing helps improve code quality, encourages developers to write more comprehensive unit tests and regression test cases, helps them discover potential bugs that may exist due to a lack of testing, and thus promotes better code design.

[0004] Currently, besides PL / pgSQL, programming languages ​​such as C, Java, and Python all have corresponding code coverage tools, and their implementation principles are largely similar. This section will use a C language code coverage tool as an example. C language code coverage is primarily achieved through instrumentation, which involves inserting additional statistical code at key locations in the code to record execution details. Common locations include function entry points, branches of conditional statements, and the beginning of basic blocks. Common tools include gcov and lcov.

[0005] Unlike C, Java, and Python, PL / pgSQL functions run inside the database server, while C, Java, and Python programs run in independent processes. This fundamental difference leads to a fundamental difference in code coverage calculations. More importantly, PL / pgSQL functions run within the query executor, and the entire process occurs within a single database connection session, making it impossible for external tools to inject probes. Therefore, currently, there are no industry-standard tools for code coverage testing of PL / pgSQL functions. Summary of the Invention

[0006] One object of the present invention is to provide a method for calculating the coverage of PL / pgSQL function statements in a database that can solve any of the above problems.

[0007] A further objective of this invention is to fill the technical gap in PL / pgSQL function code coverage detection and to achieve statement-level coverage statistics for PL / pgSQL functions within the database.

[0008] Another further objective of this invention is to efficiently and with low resource consumption complete the calculation of PL / pgSQL function statement coverage and the persistence of results by accurately collecting execution information at the database kernel layer.

[0009] Specifically, the present invention provides a method for calculating the statement coverage of PL / pgSQL functions in a database, comprising: inserting execution hooks in the critical execution path of the PL / pgSQL function executor to capture statement execution information through the execution hooks; marking a bitmap array based on the statement execution information; and counting the number of executed statements according to the bitmap array and calculating the statement coverage of the PL / pgSQL functions.

[0010] Optionally, before inserting execution hooks in the critical execution path of the PL / pgSQL function executor, the method further includes: after the PL / pgSQL function is compiled, extracting the total number of statements from the compiled function structure and initializing the bitmap array based on the line number range.

[0011] Optionally, the step of initializing the bitmap array includes: initializing the elements in the bitmap array to an unexecuted state.

[0012] Optionally, the steps for calculating the statement coverage of PL / pgSQL functions include: counting the number of elements marked as executed in the bitmap array, and using the ratio of the number of executed statements to the total number of statements as the statement coverage.

[0013] Optionally, the critical execution path is the execution path of the exec_stmt function.

[0014] Optionally, before the exec_stmt function is executed, the bitmap array position of the corresponding statement is marked as executed by an execution hook.

[0015] Optionally, after calculating the statement coverage of PL / pgSQL functions, the method further includes storing the relevant data of the statement coverage in a local memory hash table.

[0016] Optionally, after storing the relevant data of the statement coverage in a local memory hash table, the method further includes: flushing the relevant data in the local memory hash table to shared memory, and / or dumping it to a system table for persistent storage.

[0017] Optionally, the step of executing information by executing hook capture statements includes: executing start and / or end information of the execution of hook capture statements.

[0018] According to another aspect of the present invention, a computer-readable storage medium is also provided, on which a computer program is stored, wherein the computer program, when executed by a processor, implements the steps of the method for calculating the coverage of PL / pgSQL function statements in a database as described above.

[0019] The method for calculating PL / pgSQL function statement coverage in the database of the present invention deeply integrates the PL / pgSQL executor and kernel hook mechanism to collect coverage information in real time during statement execution. It does not require external probes or inter-process communication, can accurately capture the execution path, and significantly improves the accuracy and reliability of coverage statistics.

[0020] Furthermore, the method for calculating the coverage of PL / pgSQL function statements in the database of the present invention adopts a bitmap array marking and local memory hash table storage design, which completes the execution status marking and data reading and writing in O(1) time complexity, with very low performance loss to the original database, and supports concurrent access and result persistence. While ensuring efficient calculation, it realizes stable storage and query of coverage data.

[0021] The above and other objects, advantages and features of the present invention will become more apparent to those skilled in the art from the following detailed description of specific embodiments of the invention in conjunction with the accompanying drawings. Attached Figure Description

[0022] The following sections will describe some specific embodiments of the invention in detail by way of example and not limitation, with reference to the accompanying drawings. The same reference numerals in the drawings denote the same or similar parts or portions. Those skilled in the art should understand that these drawings are not necessarily drawn to scale. In the drawings: Figure 1 This is a flowchart illustrating the calculation of C language code coverage in existing technologies; Figure 2 This is a schematic diagram of the counting rules for PL / pgSQL statements in a method for calculating the coverage of PL / pgSQL function statements in a database according to an embodiment of the present invention. Figure 3 This is a schematic flowchart of a method for calculating the coverage of PL / pgSQL function statements in a database according to an embodiment of the present invention; Figure 4 This is a detailed flowchart of a method for calculating PL / pgSQL function statement coverage in a database according to an embodiment of the present invention; Figure 5 This is a schematic diagram of a computer program product according to an embodiment of the present invention; Figure 6 This is a schematic diagram of a computer-readable storage medium according to an embodiment of the present invention; and Figure 7 This is a schematic diagram of a computer device according to an embodiment of the present invention. Detailed Implementation

[0023] Those skilled in the art should understand that the embodiments described below are merely a part of the embodiments of the present invention, and not all of the embodiments of the present invention. These partial embodiments are intended to explain the technical principles of the present invention and are not intended to limit the scope of protection of the present invention. Based on the embodiments provided by the present invention, all other embodiments obtained by those skilled in the art without creative effort should still fall within the scope of protection of the present invention.

[0024] It should be noted that the logic and / or steps represented in the flowchart or otherwise described herein, for example, can be considered as a sequenced list of executable instructions for implementing logical functions, and can be specifically implemented in any computer-readable medium for use by, or in conjunction with, an instruction execution system, apparatus or device (such as a computer-based system, a processor-included system or other system that can fetch and execute instructions from, an instruction execution system, apparatus or device).

[0025] Figure 1 This is a flowchart illustrating the calculation of C language code coverage in existing technologies. Specifically, Figure 1 This demonstrates the complete process of achieving code coverage statistics using existing general-purpose programming languages, such as C, through compile-time instrumentation. It highlights the characteristics of traditional code coverage tools, which rely on external processes, compile-time instrumentation, and offline report generation.

[0026] However, as mentioned earlier, unlike C, Java, and Python, PL / pgSQL functions run inside the database server, while C, Java, and Python programs run in independent processes. This leads to a fundamental difference in code coverage calculations. More importantly, PL / pgSQL functions run within the query executor, and the entire process occurs within a single database connection session, making it impossible for external tools to inject probes. Currently, there are no industry-standard tools for code coverage testing of PL / pgSQL functions.

[0027] This embodiment provides a method for calculating PL / pgSQL function statement coverage in a database. It achieves accurate and real-time statement coverage collection through kernel-level execution hooks and bitmap markers, filling the technical gap in PL / pgSQL function coverage detection. It has extremely low performance overhead, supports concurrency and persistent storage, and efficiently completes coverage calculation without affecting database operation. Figure 2This is a schematic diagram of the counting rules for PL / pgSQL statements in a method for calculating the coverage of PL / pgSQL function statements in a database according to an embodiment of the present invention.

[0028] Statements are the basic units of database parsing, planning, and execution. Figure 2 The counting rules for PL / pgSQL statements are shown in detail. For example... Figure 2 As shown, the entire IF block is one statement, and the two cases within the IF block, namely statement 1 and statement 2, constitute two statements. In one execution, if statement 1 is executed, then for the entire execution flow, the IF block is executed first, followed by the statement; ultimately, two statements are executed, resulting in a statement coverage rate of 66%.

[0029] Figure 3 This is a schematic flowchart illustrating a method for calculating PL / pgSQL function statement coverage in a database according to an embodiment of the present invention. Figure 3 As shown, the method for calculating PL / pgSQL function statement coverage in a database generally includes the following steps: Step S302: Insert execution hooks in the critical execution path of the PL / pgSQL function executor to capture statement execution information.

[0030] Step S304: Mark the bitmap array based on the statement execution information.

[0031] Step S306: Count the number of executed statements based on the bitmap array and calculate the statement coverage of PL / pgSQL functions.

[0032] Specifically, the information executed by executing the hook capture statement in step S302 may include: start and / or end information of the execution of the hook capture statement.

[0033] Specifically, the key execution path in step S302 is the execution path of the exec_stmt function. Furthermore, before the exec_stmt function executes, the bitmap array position of the corresponding statement is marked as executed using an execution hook.

[0034] Specifically, before inserting the execution hook in the critical execution path of the PL / pgSQL function executor in step S302, the method may further include: after the PL / pgSQL function is compiled, extracting the total number of statements from the compiled function structure and initializing the bitmap array based on the line number range. Furthermore, the step of initializing the bitmap array may specifically include: initializing the elements in the bitmap array to an unexecuted state.

[0035] The statement coverage of PL / pgSQL functions calculated in step S306 may specifically include: counting the number of elements marked as executed in the bitmap array, and using the ratio of the number of executed statements to the total number of statements as the statement coverage.

[0036] Specifically, after calculating the statement coverage of the PL / pgSQL function in step S306, the process may further include: storing the relevant data of the statement coverage in a local memory hash table. Furthermore, after storing the relevant data of the statement coverage in the local memory hash table, the process may further include: flushing the relevant data in the local memory hash table to shared memory, and / or dumping it to a system table for persistent storage.

[0037] Figure 4 This is a detailed flowchart of a method for calculating PL / pgSQL function statement coverage in a database according to an embodiment of the present invention. This embodiment is based on the PL / pgSQL procedural language extension mechanism of the database, and achieves dynamic acquisition of statement-level coverage by intercepting the function execution path. The system consists of three core modules: a parser layer, an executor layer, and a data acquisition layer.

[0038] The data structure for function statement coverage is shown in Table 1: Table 1 Specifically, regarding the parser layer, the following steps are performed: syntax tree extraction: after the PL / pgSQL function is compiled, the structure of the compiled function is obtained; and metadata collection: from the compiled function structure, the total number of statements of the function is extracted and assigned to function_stats_total_statements; based on the line number range information, space is allocated for the bitmap array coverage_map and initialized to false.

[0039] Regarding the executor layer, execute hook injection: Modify the executor to insert two coverage sampling points at the beginning and end of the critical execution path exec_stmt function.

[0040] Regarding data collection, before executing exec_stmt, set coverage_map[lineno]=true.

[0041] Regarding the calculation of the result, after the function finishes execution, the number of values ​​in coverage_map that are true is counted and assigned to executed_statements. Then, executed_statements / total_statements * 100% is assigned to coverage.

[0042] To support concurrency, the `function_stats` structure is stored in a local in-memory hash table, with the key being the database's `oid` and the function's `oid`. It is then manually refreshed by the user or periodically refreshed to shared memory. Simultaneously, for persistent storage, the data in shared memory is periodically dumped to system tables.

[0043] Taking the sys_kwr plugin for the database as an example, Table 2 shows the completed effect of this embodiment.

[0044] Table 2 It should be noted that the method for calculating PL / pgSQL function statement coverage in this embodiment modifies the PL / pgSQL executor by inserting hooks before and after the critical execution path `exec_stmt` function. This captures the start and end information of function and statement execution, enabling monitoring of the function execution process. A bitmap array `coverage_map` is initialized at the parser layer, with its size set to the maximum range of function line numbers. During the data acquisition phase, hook functions mark the line numbers of executed statements as executed. Finally, the number of executed statements is counted based on the bitmap array, and code coverage is calculated.

[0045] The method for calculating the PL / pgSQL function statement coverage in the database in this embodiment has the advantage of deep integration. It is directly integrated with the PL / pgSQL executor, which can obtain the most accurate execution path information and record the coverage information in real time during statement execution. There is no additional inter-process communication overhead of traditional instrumentation tools. In addition, it has the advantage of performance efficiency. The coverage_map uses a memory array, and the boolean flag has a time complexity of O(1). Only the boolean value setting operation is added, which minimizes the impact on the performance of the original function and theoretically increases the overhead by <1%.

[0046] The flowcharts provided in the above embodiments are not intended to indicate that the operations of the method will be performed in any particular order, or that all operations of the method are included in all every case. Furthermore, the method may include additional operations. Within the scope of the technical concept provided by the methods in the above embodiments, additional variations can be made to the above methods.

[0047] This embodiment also provides a computer program product, a computer-readable storage medium, and a computer device. Figure 5 This is a schematic diagram of a computer program product 500 according to an embodiment of the present invention. Figure 6 This is a schematic diagram of a computer-readable storage medium 300 according to an embodiment of the present invention. Figure 7 This is a schematic diagram of a computer device 400 according to an embodiment of the present invention.

[0048] Computer program product 500 includes computer program 310, which, when executed by processor 410, implements the steps of the method for calculating the coverage of PL / pgSQL function statements in a database according to any of the above embodiments. Computer-readable storage medium 300 stores the computer program 310 thereon, which, when executed by processor 410, implements the steps of the method for calculating the coverage of PL / pgSQL function statements in a database according to any of the above embodiments. Computer device 400 may include memory 420, processor 410, and computer program 310 stored in memory 420 and running on processor 410.

[0049] The computer program 310 used to perform the operations of the present invention may be assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine-related instructions, microcode, firmware instructions, status setting data, integrated circuit configuration data, or source code or object code written in any combination of one or more programming languages ​​and procedural programming languages.

[0050] Computer program 310 may execute entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the latter case, 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).

[0051] In some embodiments, in order to perform aspects of the present invention, electronic circuits including, for example, programmable logic circuits, field-programmable gate arrays (FPGAs) or programmable logic arrays (PLAs) can execute computer-readable program instructions to personalize the electronic circuits by utilizing state information of computer-readable program instructions.

[0052] For the purposes of this embodiment, computer program product 500 is a related product containing computer program 310. For the purposes of this embodiment, computer-readable storage medium 300 is a tangible device capable of holding and storing computer program 310, and can be any device capable of containing, storing, communicating, propagating or transmitting computer program 310 for use by or in conjunction with an instruction execution system, apparatus or device.

[0053] More specific examples (a non-exhaustive list) of computer-readable storage media 300 include the following: portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), portable optical disc read-only memory (CD-ROM), digital multifunction disc (DVD), memory sticks, floppy disks, mechanical encoding devices, and any suitable combination of the foregoing.

[0054] Computer device 400 may include memory 420, processor 410, and computer program 310 stored on memory 420 and running on processor 410. When processor 410 executes computer program 310, it implements the steps of the method for calculating the coverage of PL / pgSQL function statements in the database in any of the above embodiments.

[0055] It should be noted that the logic and / or steps represented in the flowchart or otherwise described herein, for example, can be considered as a sequenced list of executable instructions for implementing logical functions, and can be specifically implemented in any machine-readable storage medium for use by, or in conjunction with, instruction execution systems, apparatuses or devices (such as computer-based systems, processor-based systems or other systems that can fetch and execute instructions from, or instruction execution systems, apparatuses or devices).

[0056] It should be understood that various parts of the present invention can be implemented using hardware, software, firmware, or a combination thereof. In the above embodiments, multiple steps or methods can be implemented using software or firmware stored in memory and executed by a suitable instruction execution system.

[0057] Computer device 400 can be, for example, a server, desktop computer, laptop computer, tablet computer, or smartphone. In some examples, computer device 400 can be a cloud computing node. Computer device 400 can be described in the general context of computer system executable instructions (such as program modules) executed by a computer system. Typically, program modules can include routines, programs, object programs, components, logic, data structures, etc., that perform specific tasks or implement specific abstract data types. Computer device 400 can be implemented in a distributed cloud computing environment where tasks are performed by remote processing devices linked through a communication network. In a distributed cloud computing environment, program modules can reside on local or remote computing system storage media, including storage devices.

[0058] Computer device 400 may include a processor 410 adapted to execute stored instructions and a memory 420 that provides temporary storage space for the operation of instructions during operation. The processor 410 may be a single-core processor, a multi-core processor, a computing cluster, or any other configuration. The memory 420 may include random access memory (RAM), read-only memory, flash memory, or any other suitable storage system.

[0059] The processor 410 can be connected via a system interconnect (e.g., PCI, PCI-Express, etc.) to an I / O interface (input / output interface) suitable for connecting the computer device 400 to one or more I / O devices (input / output devices). I / O devices may include, for example, a keyboard and indicating devices, where indicating devices may include a touchpad or touchscreen, etc. I / O devices may be built into the computer device 400 or may be external devices connected to the computing device.

[0060] The processor 410 may also be linked via a system interconnect to a display interface suitable for connecting the computer device 400 to a display device. The display device may include a display screen as a built-in component of the computer device 400. The display device may also include an external computer monitor, television, or projector connected to the computer device 400. Furthermore, a network interface controller (NIC) may be adapted to connect the computer device 400 to a network via a system interconnect. In some embodiments, the NIC may use any suitable interface or protocol (such as an Internet Minicomputer System Interface) to transmit data. The network may be a cellular network, a radio network, a wide area network (WAN), a local area network (LAN), or the Internet, etc. Remote devices may connect to the computing device via the network.

[0061] Therefore, those skilled in the art should recognize that although numerous exemplary embodiments of the present invention have been shown and described in detail herein, many other variations or modifications conforming to the principles of the present invention can be directly determined or derived from the disclosure of the present invention without departing from the spirit and scope of the invention. Thus, the scope of the present invention should be understood and construed as covering all such other variations or modifications.

Claims

1. A method for calculating PL / pgSQL function statement coverage in a database, comprising: Execution hooks are inserted into the critical execution paths of the PL / pgSQL function executor to capture statement execution information. The bitmap array is marked based on the statement execution information; as well as The number of executed statements is counted based on the bitmap array, and the statement coverage of PL / pgSQL functions is calculated.

2. The method according to claim 1, further comprising, before the step of inserting an execution hook in the critical execution path of the PL / pgSQL function executor: After the PL / pgSQL function is compiled, the total number of statements is extracted from the compiled function structure, and the bitmap array is initialized based on the line number range.

3. The method according to claim 2, wherein the step of initializing the bitmap array comprises: The elements in the bitmap array are initialized to an unexecuted state.

4. The method according to claim 2, wherein the step of calculating the statement coverage of PL / pgSQL functions includes: The number of elements marked as executed in the bitmap array is counted, and the ratio of the number of executed statements to the total number of statements is used as the statement coverage rate.

5. The method according to claim 1, wherein, The critical execution path is the execution path of the exec_stmt function.

6. The method according to claim 5, wherein, Before the exec_stmt function is executed, the bitmap array position of the corresponding statement is marked as executed by the execution hook.

7. The method of claim 1, further comprising, after the step of calculating the statement coverage of the PL / pgSQL function: The relevant data for the statement coverage is stored in a local memory hash table.

8. The method of claim 7, further comprising, after the step of storing the relevant data of the statement coverage in a local memory hash table: The relevant data in the local memory hash table is refreshed to shared memory and / or dumped to a system table for persistent storage.

9. The method of claim 1, wherein the step of capturing statement execution information via the execution hook comprises: The execution hook captures the start and / or end information of statement execution.

10. A computer-readable storage medium having a computer program stored thereon, the computer program being executed by a processor to implement the steps of the method for calculating the coverage of PL / pgSQL function statements in a database as described in any one of claims 1 to 9.

Images