WO2014173211A1

WO2014173211A1 - Code coverage testing method, device and system

Info

Publication number: WO2014173211A1
Application number: PCT/CN2014/073758
Authority: WO
Inventors: Wen Tan
Original assignee: Tencent Technology (Shenzhen) Company Limited
Priority date: 2013-04-23
Filing date: 2014-03-20
Publication date: 2014-10-30
Also published as: CN104123218B; CN104123218A

Abstract

The embodiments of the invention disclose a code coverage testing method, device and system. In an embodiment of the invention, a binary file and a symbol table generated after source codes are complied are acquired; the binary file is parsed by using the symbol table to determine a position of function defined by each source code; then when the binary file is loaded into a memory and not yet executed, a debug point is set for a map of the binary file that is loaded into the memory according to the position of the function; a code basic block that has been executed is determined according to the debug point, and relevant information of the code basic block that has been executed is recorded in the memory; finally, the relevant information of the code basic block is converted into code line information by using the symbol table, to obtain code lines that the test covers. This solution can improve reliability of test.

Description

CODE COVERAGE TESTING METHOD, DEVICE AND SYSTEM

[0001] This application claims priority to Chinese patent application No. 201310143177.2 titled "Code coverage testing method, device and system" and filed with the State Intellectual Property Office on April 23, 2013, which is incorporated herein by reference in its entirety.

FIELD OF THE INVENTION

[0002] The invention relates to the field of communication technology, and particularly to a code coverage testing method, device and system.

BACKGROUND OF THE INVENTION

[0003] Code coverage testing refers to a code testing method in which codes are executed in a test way and codes which are monitored to have been executed (i.e. being covered) are counted in the test. The purpose is to ensure that the test can cover codes as much as possible, so as to improve reliability of test. There are a variety of evaluation methods for code coverage, and code line coverage is one of them, that is to say, a good code coverage testing method should ensure that the test can cover code lines as much as possible and can clearly learn code lines that have been covered and code lines that have not been covered.

SUMMARY OF THE INVENTION

[0004] Embodiment of the invention provides a code coverage testing method, device and system, which can improve reliability of test and are applicable not only to normal application programs, but also to operate system kernel programs including driver programs, so as to avoid situations of blue screen and crash in testing. [0005] There is provided a code coverage testing method, including:

[0006] acquiring a binary file and a symbol table generated after source codes are compiled;

[0007] parsing the binary file according to the symbol table to determine a position of each function defined by each source code;

[0008] setting, when the binary file is loaded into a memory and not yet executed, a debug point for a map of the binary file that is loaded into the memory, according to the position of the function;

[0009] determining, according to the debug point, a code basic block that has been executed, and recording relevant information of the code basic block that has been executed in the memory; and

[0010] converting the relevant information of the code basic block into code line information by using the symbol table, to obtain code lines that the test covers.

[0011] There is provided a code coverage testing device, including:

[0012] an acquiring unit, configured to acquire a binary file and a symbol table generated after source codes are compiled;

[0013] a parsing unit, configured to parse the binary file according to the symbol table to determine a position of each function defined by each source code;

[0014] a setting unit, configured to set, when the binary file is loaded into a memory and not yet executed, a debug point for a map of the binary file that is loaded into the memory, according to the position of the function;

[0015] a processing unit, configured to determine, according to the debug point, a code basic block that has been executed, and record relevant information of the code basic block that has been executed in the memory; and

[0016] a converting unit, configured to convert the relevant information of the code basic block into code line information by using the symbol table, to obtain code lines that the test covers.

[0017] There is provided a communication system including any one of the code coverage testing devices provided by the embodiments of the invention.

[0018] In the embodiments of the invention, a binary file and a symbol table generated after source code is compiled are acquired, the binary file is parsed according to the symbol table to determine a position of each function defined by the source code, then when the binary file is loaded into the memory and not yet executed, a debug point is set for a map of the binary file that is loaded into the memory according to the position of the function, a code basic block that has been executed is determined according to the debug point, and relevant information of the code basic block that has been executed is recorded in the memory, and finally the relevant information of the code basic block is converted into code line information by using the symbol table, to obtain code lines that the test covers. In the solution, the debug point is set only for the map of the binary file that is loaded into the memory, without giving a substantive change to the binary file itself. Therefore, it can ensure that the binary file obtained by compiling the actual release codes is the same file as the binary file used in the test, thereby reliability of the test is greatly improved, and because the object being set is the debug point, the real impact on the execution of codes is very small.

BRIEF DESCRIPTION OF THE DRAWINGS

[0019] In order to more clearly illustrate the technical solutions in the embodiments of the invention, drawings to be used in the descriptions of the embodiments will be introduced briefly hereinafter. Apparently, the drawings described below are merely some embodiments of the invention, and for those skilled in the art, other drawing can also be obtained from these drawings without any creative work. [0020] Figure 1 is a flow chart of a code coverage testing method provided by an embodiment of the invention;

[0021] Figure 2 is another flow chart of a code coverage testing method provided by an embodiment of the invention;

[0022] Figure 3 is a schematic structural diagram of a code coverage testing device provided by an embodiment of the invention; and

[0023] Figure 4 is a schematic structural diagram of a terminal provided by an embodiment of the invention.

DETAILED DESCRIPTION OF THE INVENTION

[0024] In the following, the technical solutions in the embodiments of the invention will be described clearly and completely in conjunction with the drawings. Apparently, the embodiments described are merely a part of the embodiments of the invention, rather than all embodiments. Other embodiments obtained based on the embodiments of the invention by those skilled in the art without any creative work are all belong to the scope of protection of the invention. [0025] The embodiments of the invention provide a code coverage testing method, device and system. The detailed illustration is made hereinafter.

[0026] First embodiment

[0027] In the embodiment of the invention, the description is made from the perspective of a code coverage testing device, the code coverage testing device can be integrated into a terminal, and the terminal may be smart mobile phones, tablets, e-readers, MP3 (Moving Picture Experts Group Audio Layer III) players, MP4 (Moving Picture Experts Group Audio Layer IV) players, portable laptop computers, desktop computers and so on.

[0028] There is provided a code coverage testing method, including: acquiring a binary file and a symbol table generated after source codes are compiled; parsing the binary file according to the symbol table to determine a position of each function defined by each source code; setting, when the binary file is loaded into a memory and not yet executed, a debug point is set for a map of the binary file that is loaded into the memory, according to the position of the function; determining, according to the debug point, a code basic block that has been executed, and recording relevant information of the code basic block that has been executed in the memory; and converting the relevant information of the code basic block into code line information by using the symbol table, to obtain code lines that the test covers.

[0029] As shown in Figure 1, the specific process may include steps 101-105.

[0030] 101, acquiring a binary file and a symbol table generated after source codes are compiled.

[0031] Specifically, the binary file and the symbol table can be obtained by compiling the source codes to be tested by a compiler, that is, the binary file herein refers to a binary executable file obtained after the source codes are compiled.

[0032] 102, parsing the binary file according to the symbol table acquired in step 101 to determine a position of each function defined by each source code.

[0033] 103, setting, when the binary file is loaded into a memory and not yet executed, a debug point for a map of the binary file that is loaded into the memory, according to the position of the function.

[0034] Specifically, for example, a debug interrupt instruction is inserted at a beginning position of each function in the map of the binary file that is loaded into the memory, according to the position of the function. That is, a debug point is set at each jump point, for example, a debug interrupt instruction is inserted at each jump point.

[0035] At this point, the original content at this position is stored so that it can be restored later.

[0036] 104, determining, according to the debug point, a code basic block that has been executed, and recording relevant information of the code basic block that has been executed in a memory such as a non-paged memory. For example, the specific situation is as follow.

[0037] When a debug interrupt occurs and it is determined that the interrupt is caused by a set debug point (i.e. the debug point set in the embodiment of the invention), instruction decoding is made to codes behind the debug point causing the interrupt, till a jump point is found (i.e. the first jump point behind the debug point causing the interrupt is found); codes between the debug point causing the interrupt and the jump point are determined as a code basic block that has been executed, and relevant information of the code basic block that has been executed is recorded in a basic block information table in the memory. [0038] The decoding herein refers to parsing information in the codes, and the basic block information table refers to a global table for storing the relevant information of code basic blocks in this binary file. In general, the basic block information table records only the code basic block that has been executed. However, in order to show more clearly, whether the code basic block has been executed (here refers to being decoded) can also be identified in the basic block information table. The basic block information table is stored in the memory.

[0039] It should be noted that when it is used in the kernel test, the basic block information table can be stored in a locked un-pageable memory, that is, the step "recording relevant information of the code basic block that has been executed in a basic block information table in the memory" may include: [0040] recording the relevant information of the code basic block that has been executed in a basic block information table in a non-paged memory.

[0041] For example, if in the step 103, a debug interrupt instruction has been inserted at a beginning position of each function in the map of the binary file according to the position of the function, then in this case the step "when a debug interrupt occurs and it is determined that the interrupt is caused by a set debug point, performing instruction decoding to codes behind the debug point causing the interrupt, till a jump point is found" may include:

[0042] when a debug interrupt occurs and it is determined that the interrupt is caused by a inserted debug interrupt instruction, performing instruction decoding to codes behind the debug interrupt instruction causing the interrupt, till a jump instruction is found.

[0043] wherein if the jump instruction is obtained by decoding, then after the jump instruction is found, it is also possible to determine whether the jump instruction is a direct jump instruction or an indirect jump instruction, then different treatments are performed for different situations, and an example thereof is shown as follows.

[0044] If the jump instruction is a direct jump instruction and it is determined that there is no code basic block in the basic block information table which takes the jump destination of the jump instruction as its start address, a debug interrupt instruction is inserted at a beginning position of a function corresponding to the jump instruction, i.e. the same treatment as the step 103 is performed.

[0045] But if the jump instruction is an indirect jump instruction, then the jump instruction is replaced with a debug interrupt instruction.

[0046] Herein, the direct jump instruction refers to an instruction that the jump destination address can be calculated according to only the current address of the instruction and the information in the instruction which can be decoded directly. That is, the destination address is fixed. The indirect jump instruction means that the jump destination address depends on the state of a system, such as an instruction depending on a certain value in a register and/or a certain value in a memory, and therefore when decoding, the jump destination address can not be calculated immediately, and can be calculated only after the state of the system is determined.

[0047] For the indirect jump instruction, it is unable to calculate the jump destination address, that is, it is unable to know the position of the next code basic block, therefore, the method used in the embodiment of the invention is that: the indirect jump instruction is replaced with a debug interrupt instruction. Thus, when the debug interrupt occurs again, the address where the interrupt occurs is checked, and if it is found that it is an indirect jump instruction, and because at this time all system states (such as a value in each register and/or a value in a memory unit) can be known when the system is going to perform the jump instruction, the jump destination address can be calculated, and the position of the next code basic block can be known by the jump destination address.

[0048] In addition, after the relevant information of the code basic block that has been executed is recorded in the basic block information table in the memory, the codes can also be restored to its original appearance, for example the inserted debug interrupt instruction is deleted and replaced with the original instruction. Thus, the debug interrupt will not occur when this code basic block is executed the next time. When this code basic block is restored, the system jumps to the start address of the code basic block to execute normally. That is, after the step "recording relevant information of the code basic block that has been executed in a basic block information table in the memory", the method may further include:

[0049] deleting the inserted debug interrupt instruction.

[0050] It should be noted that the operations above are part of the interrupt processing, and are not necessary to be executed in an interrupt handler. For part of complex time-consuming work which can not be implemented in the interrupt handler, it can be executed after returning from the interrupt processing, and it returns to the place where the interruption occurs after the execution is completed, which will not be described in detail herein.

[0051] 105, converting the relevant information of the code basic block into code line information by using the symbol table, to obtain code lines that the test covers.

[0052] Herein, the relevant information of the code basic block may include information such as a start address and an end address of the code basic block, i.e. the step "converting the relevant information of the code basic block into code line information by using the symbol table, to obtain code lines that the test covers" may include:

[0053] converting the start address and the end address of the code basic block into code line information by using the symbol table, to obtain code lines that the test covers.

[0054] It can be seen from the above that, in the embodiment of the invention, a binary file and a symbol table generated after source code is compiled are acquired, the binary file is parsed according to the symbol table to determine a position of each function defined by the source code, then when the binary file is loaded into the memory and not yet executed, a debug point is set for a map of the binary file that is loaded into the memory according to the position of the function, a code basic block that has been executed is determined according to the debug point, and relevant information of the code basic block that has been executed is recorded in the memory, and finally the relevant information of the code basic block is converted into code line information by using the symbol table, to obtain code lines that the test covers. In the solution, the debug point is set only for the map of the binary file that is loaded into the memory, without making a substantive change to the binary file itself. Therefore, it can ensure that the binary file obtained by compiling the actual release codes is the same file as the binary file used in the test, thereby the reliability of test is greatly improved, and because the object to be set is the debug point, the real impact on the execution of codes is minimal.

[0055] Moreover, in the prior art, the coverage information of the codes is generally recorded by a method of directly writing a certain file. However, in the operating system kernel program (such as driver programs of the Window system or Linux system), not all occasions are suitable to read and write files. In addition, reading or writing a file itself is a call operation of the system, which will cause the behavior of the driver program itself to become different. Therefore, generally, the existing two solutions are not applicable to the driver program, and are prone to cause blue screen and crash of a system during actual tests. However, instead of depending on file operations to record the code coverage degree, this solution records the code coverage degree in the memory, and can record the code coverage degree in a non-pageable memory if necessary, and since operating the un-pageable memory is an extremely safe operation and can be performed in almost all execution occasions of the system, the impact on the system is minimal, so it is applicable to the driver program, thereby situations of blue screen and crash of the system caused by the test are avoided.

[0056] Second embodiment

[0057] In the following, the method described according to the first embodiment will be illustrated in detail by examples.

[0058] As shown in Figure 2, there is provided a code coverage testing method including steps 201-206.

[0059] 201, the code coverage testing device acquires a binary file and a symbol table generated after source codes are compiled.

[0060] Specifically, the binary file and the symbol table can be obtained by compiling the source codes to be test by a compiler.

[0061] 202, the code coverage testing device parses the binary file according to the acquired symbol table to determine a position of a function defined by each source code in the binary file.

[0062] Specifically, the position of the function refers to an actual position of the function after compiling.

[0063] 203, the code coverage testing device monitors the loading of each binary file into the operating system; and when the binary file is loaded into the memory but not yet executed, the code coverage testing device inserts, according to the position of the function, a debug interrupt instruction at a beginning position of each function in the map of the binary file that is loaded into the memory.

[0064] At this point, the original content at this position can be stored so that it can be restored later.

[0065] 204, when a debug interrupt occurs, the code coverage testing device determines whether the interrupt is caused by an inserted debug interrupt instruction, and if the interrupt is caused by an inserted debug interrupt instruction, the code coverage testing device decodes codes behind the debug interrupt instruction causing the interrupt, until a jump instruction is found (this equals to the fact that another code basic block is found and the address of the jump instruction is a start address of the another code basic block).

[0066] If the jump instruction is obtained by decoding, then after the jump instruction is found, it is also possible to determine whether the jump instruction is a direct jump instruction or an indirect jump instruction, then different treatments are performed for different situations, and an example thereof is shown as follows.

[0067] If the jump instruction is a direct jump instruction, it is determined whether there is a code basic block in the basic block information table which takes the jump destination of the jump instruction as its start address, and if there is a code basic block in the basic block information table which takes the jump destination of the jump instruction as its start address, it indicates that the code basic block has been executed, no treatment will be made, and if there is no code basic block in the basic block information table which takes the jump destination of the jump instruction as its start address, it indicates that the code basic block has not been executed, therefore a debug interrupt instruction can be inserted at a beginning position of a function corresponding to the jump instruction, i.e. the same treatment as the step 203 is performed, and the treatment thereafter is the same as that of other inserted debug interrupt instruction. [0068] And if the jump instruction is an indirect jump instruction, it is unable to determine its jump destination. In this case, the jump instruction is directly replaced with a debug interrupt instruction, and the treatment thereafter is the same as that of other inserted debug interrupt instruction. And when a debug interrupt actually occurs, the same treatment as other direct jump instruction is performed after the state of the system has been obtained and the jump destination has been calculated.

[0069] In addition, if the occurrence of the interrupt is not due to the debug interrupt instruction, the treatment is performed according to the present treatment process.

[0070] 205, the code coverage testing device determines codes between the debug point causing the interrupt and the jump point as a code basic block that has been executed, and records relevant information of the code basic block that has been executed in a basic block information table in the memory, such as a basic block information table in a non-paged memory, and marks that the code basic block has been executed.

[0071] Herein, the basic block information table refers to a global table for storing the relevant information of code basic blocks in this binary file, and the relevant information of the code basic block may include information such as a start address and an end address of the code basic block. In this basic block information table, it is also possible to mark whether the code basic block has been executed. The basic block information table is stored in the memory.

[0072] In addition, after the relevant information of the code basic block that has been executed is recorded to the basic block information table in the memory, the codes can also be restored to its original appearance, for example the inserted debug interrupt instruction is deleted. Thus, the debug interrupt will not occur when this code basic block is executed the next time. When this code basic block is restored, the system jumps to the start address of the code basic block to execute normally. [0073] It should be noted that the operations in the steps 204 and 205 are part of the interrupt processing, and are not necessary to be executed in an interrupt handler. For part of complex time-consuming work which can not be implemented in the interrupt handler, it can be executed after returning from the interrupt processing returns, and it returns to the place where the interruption occurs after the execution is completed, which will not be described in detail herein. [0074] 206, finally a basic block information table is formed in the test process. When the tester ends the test and needs to get the test report, the code coverage testing device can output the basic block information table and convert the relevant information of the code basic block in the basic block information table into code line information by using the previously-acquired symbol table. In this way, the code lines that the test covers can be obtained. [0075] It can be seen from the above that, in the embodiment of the invention, a binary file and a symbol table generated after source codes are compiled are acquired, the binary file is parsed according to the symbol table to determine a position of a function defined by the each source code, then when the binary file is loaded into the memory and not yet executed, a debug interruption instruction is inserted to beginning position of each function in a map of the binary file that is loaded into the memory according to the position of the function, a code basic block that has been executed is determined according to the debug interruption instruction, and relevant information of the code basic block that has been executed is recorded in the memory, and finally the relevant information of the code basic block is converted into code line information by using the symbol table, to obtain code lines that the test covers. In the solution, since the debug interruption instruction is only inserted to beginning position of each function in the map of the binary file that is loaded into the memory, without making a substantive change to the binary file itself. Therefore, it can ensure that the binary file obtained by compiling the actual release codes is the same file with the binary file used in the test, thereby the reliability of test is greatly improved, and because the inserted object is only a debug interruption instruction, the real impact on the execution of codes is minimal.

[0076] In addition, instead of depending on file operations to record the code coverage degree, this solution records the code coverage degree in the memory, and can record the code coverage degree in a non-pageable memory if necessary, and since operating the un-pageable memory is an extremely safe operation and can be performed in almost all execution occasions of the system, the impact on the system is minimal, therefore, it is applicable to the driver program, to situations of blue screen and crash caused by the test are avoided.

[0077] Third embodiment

[0078] The methods described in the first embodiment and the second embodiment will be illustrated hereinafter by taking the test of a Windows driver program under the Windows system as an example. It should be understood that the embodiments of the invention can also be applied to other hardware platforms, other operating systems and other programs, which will not be described in detail herein.

[0079] In the embodiment of the invention, the code coverage testing device may include a driving part module and a user mode console command-line tool module, abbreviated as a command-line tool module. Wherein the driving part module can be installed on a test machine, and the command-line tool module can be directly copied to the test machine. The specific function of these two modules may be as follows.

[0080] (1) The driving part module can perform the following function:

[0081] In the Windows kernel, the user can specify a test-driven binary file and a test-driven function entry address list (i.e. the symbol table) to the drive part module. If it is not specified, then the driving part module does not make any treatment.

[0082] Once the binary file of the driver program to be tested is specified, the driving part module will monitor the loading of the binary file of the driver program to be tested (hereinafter referred to as a tested driver program). If the loading of the tested driver program is found, the driver part module will modify the map of the tested driver program in the kernel, and replace all function entries with an int 3 instruction, wherein the int 3 instruction is a debug instruction under the x86 hardware platform, and its machine code is Oxcc, this int 3 instruction will cause a debug interrupt.

[0083] Since the driving part module has taken over the debug interrupt in the Windows system, so once a debug interrupt occurs, the driving part module will be executed at first, and it is determined whether the interrupt is caused by the inserted int 3 instruction, and if the interrupt is caused by the inserted int 3 instruction, then instruction decoding is made to codes behind the int 3 instruction causing this interrupt, until a jump instruction is found, and when a jump instruction is found, the instruction at the jump destination address is replaced with the int 3 instruction, and the int 3 instruction at the previous position is restored to the original code, so that the system operation is continued. Wherein, for the direct jump instruction and the indirection jump instruction, the treatment methods are different, and for the specific details, one can refer to the embodiments described previously, which will not be described in detail herein.

[0084] Because the int 3 instruction newly added later will continue to cause occurrence of an interrupt, the same execution will continue, and the driving part module will record the start position and the end (jump away) position of each execution, i.e. the start address and the end address (i.e. relevant information of a code basic block) of each code basic block can be obtained, so the relevant information of these code basic blocks is recorded to a basic block information table in a non-pageable memory.

[0085] (2) the command-line tool module performs the following functions: [0086] The command-line tool module can acquire the binary file (hereinafter referred to as a tested driver program) and the symbol table of the driver program to be tested, and can parse the tested driver program according to the acquired symbol table to determine a position of function defined by each source code in the tested driver program, and transfers the positions of the functions to the driving part module.

[0087] After the end of the test, the relevant information of the code basic block in the basic block information table is converted into code line information by the command-line tool module. In this way, the code lines that the test covers can be obtained.

[0088] It should be noted that the described above is merely an example of the embodiments of the invention. It should be understood that in the specific implementation, a variety of methods can be used, such as using more showing methods to show test results, which will not be described in detail herein.

[0089] It can be seen from the above that in the embodiment of the invention, a tested driver program and a symbol table are acquired, the tested driver program is parsed according to the symbol table to determine a position of a function defined by each source code, then when the binary file is loaded into the memory and not yet executed, an int 3 instruction is inserted at a beginning position of each function in the map of the tested driver program that is loaded into the memory according to the position of the function, and the code basic block that has been executed is determined according to the int 3 instruction, and relevant information of the code basic block that has been executed is recorded in a non-pageable memory, and finally the relevant information of the code basic block is converted into code line information by using the symbol table, to obtain code lines that the test covers. In the solution, the int 3 instruction is only inserted at the beginning position of each function in the map of the tested driver program that is loaded into the memory, without making a substantial change to the binary file itself. Therefore, it can ensure that the actual release driver program is the same file as the tested driver program, thereby reliability of test is greatly improved, and because the inserted object is an int 3 instruction, the real impact on the execution of codes is minimal. In addition, instead of depending on file operations to record the code coverage degree, this solution records the code coverage degree in the memory, and can record the code coverage degree in a non-pageable memory if necessary, and since execution of the un-pageable memory is an extremely safe operation and can be performed in all execution occasions of the system, the impact on the system is minimal, therefore, it is applicable to the driver program, to avoid situations of blue screen and crash of the system caused by the test

[0090] Fourth embodiment

[0091] Accordingly, the embodiments of the invention also provide a code coverage testing device shown in Figure 3, the code coverage testing device may include an acquiring unit 301, a parsing unit 302, a setting unit 303, a processing unit 304 and a converting unit 305.

[0092] The acquiring unit 301 is configured to acquire a binary file and a symbol table generated after source codes are compiled.

[0093] Specifically, the binary file and the symbol table can be obtained by compiling the source codes to be tested by a compiler. [0094] The parsing unit 302 is configured to parse the binary file according to the symbol table to determine a position of a function defined by the each source code.

[0095] The setting unit 303 is configured to set, when the binary file is loaded into a memory and not yet executed, a debug point for a map of the binary file that is loaded into the memory, according to the position of the function. [0096] The processing unit 304 is configured to determine, according to the debug point, a code basic block that has been executed, and record relevant information of the code basic block that has been executed in the memory.

[0097] For example, the relevant information of the code basic block that has been executed can be recorded in a non-pageable memory. [0098] The converting unit 305 is configured to convert the relevant information of the code basic block into code line information by using the symbol table, to obtain code lines that the test covers.

[0099] Specifically, the relevant information of the code basic block may include information such as a start address and an end address of the code basic block, namely: [00100] the converting unit 305 can convert the start address and the end address of the code basic block into code line information by using the symbol table, to obtain code lines that the test covers.

[00101] Optionally, the processing unit 304 may include a testing sub-unit and a recording sub-unit.

[00102] The testing sub-unit is configured to, when a debug interrupt occurs and it is determined that the interrupt is caused by a set debug point (i.e. a debug point set by the setting unit 303), perform instruction decoding to codes behind the debug point causing the interrupt, until a jump point is found, (i.e. the first jump point behind the debug point causing the interrupt is found);

[00103] The recording sub-unit is configured to determine codes between the debug point causing the interrupt and the jump point as a code basic block that has been executed, and record relevant information of the code basic block that has been executed to a basic block information table in the memory. For example, the relevant information of the code basic block that has been executed can be recorded in a basic block information table in a non-pageable memory.

[00104] The decoding herein refers to parsing information in the codes, and the basic block information table refers to a global table for storing the relevant information of code basic blocks in this binary file. In general, the basic block information table records only the code basic block that has been executed. However, in order to show more clearly, whether the code basic block has been executed is also recorded in the basic block information table. The basic block information table is stored in the memory.

[00105] For example, the setting unit 302 is configured to insert, according to the position of the function, a debug interrupt instruction at a beginning position of each function in the map of the binary file that is loaded into the memory.

[00106] In this case, the testing sub-unit is configured to, when a debug interrupt occurs and it is determined that the interrupt is caused by a debug interrupt instruction, performing instruction decoding to codes behind the debug interrupt instruction causing the interrupt, till a jump point is found.

[00107] If the jump instruction is obtained by decoding, then after the jump instruction is found, it is also possible to determine whether the jump instruction is a direct jump instruction or an indirect jump instruction, then different treatments are performed for different situations, and an example thereof is shown as follows.

[00108] The setting unit 302 can also be configured to: when it is determined that the jump instruction is obtained by decoding, determine whether the jump instruction is a direct jump instruction or an indirect jump instruction; and if the jump instruction is a direct jump instruction and it is determined that there is no code basic block in the basic block information table which takes the jump destination of the jump instruction as its start address, insert a debug interrupt instruction at a beginning position of a function corresponding to the jump instruction; and if the jump instruction is an indirect jump instruction, replace the jump instruction with a debug interrupt instruction.

[00109] In addition, after the relevant information of the code basic block that has been executed is recorded in the basic block information table in the memory, the codes can also be restored to its original appearance, for example the inserted debug interrupt instruction is deleted. Thus, the debug interrupt will not occur when this code basic block is executed the next time. After this code basic block is restored, the system jumps to the start address of the code basic block to execute normally. That is, the processing unit 304 may also include a deleting sub-unit.

[00110] The deleting sub-unit is configured to delete the inserted debug interrupt instruction.

[00111] In the specific implementation, the above units can be implemented as a separate entity, and can also be combined arbitrarily to be implemented as one or several entities, for example, they can be achieved by the driving part module and the command-line tool module in the third embodiment. For the implementation of each of the above units, one can refer to the previous embodiments, which will not be described in detail herein.

[00112] Specifically, the code coverage testing device can be integrated into a terminal, and the terminal may be smart mobile phones, tablets, e-readers, MP3 players, MP4 players, laptops, portable computers, desktop computers and so on. [00113] It can be seen from the above that, in the code coverage testing device of the embodiment, the acquiring unit 301 can acquire a binary file and a symbol table generated after source codes are compiled, the parsing unit 302 parses the binary file by using the symbol table to determine a position of function defined by each source code, then when the binary file is loaded into the memory and not yet executed, the setting unit 303 sets, according to the position of the function, a debug point to the map of the binary file that is loaded into the memory, the processing unit 304 determines, according to the debug point, a code basic block that has been executed, and records relevant information of the code basic block in the memory, finally, the converting unit 305 converts the relevant information of the code basic block into code line information by using the symbol table, to obtain code lines that the test covers. In the solution, the debug point is set only for the map of the binary file that is loaded into the memory, without making a substantial change to the binary file itself. Therefore, it can ensure that the binary file obtained by compiling the actual release codes is the same file with the binary file used in the test, thereby the reliability of test is greatly improved, and because the set object is the debug point, the real impact on the execution of codes is minimal.

[00114] In addition, instead of depending on file operations to record the code coverage degree, this solution records the code coverage degree in the memory, and can record the code coverage degree in a non-pageable memory if necessary, and since execution of the un-pageable memory is an extremely safe operation and can be performed in almost all execution occasions of the system, the impact on the system is minimal, and therefore, it is applicable to the driver program, to avoid situations of blue screen and crash caused by the test.

[00115] Fifth embodiment

[00116] Accordingly, the embodiments of the invention also provide a communication system including any one of the code coverage testing devices provided by the embodiments of the invention, and for the specific situation of the code coverage testing device, one can refer to the fourth embodiment. Specifically,

[00117] the code coverage testing device is configured to: acquire a binary file and a symbol table generated after source codes are compiled; parse the binary file according to the symbol table to determine a position of function defined by each source code; set, when the binary file is loaded into a memory and not yet executed, a debug point for a map of the binary file that is loaded into the memory, according to the position of the function; determine, according to the debug point, a code basic block that has been executed, and recording relevant information of the code basic block that has been executed in the memory; and convert the relevant information of the code basic block into code line information by using the symbol table, to obtain code lines that the test covers. For the specific contents, one can refer to the embodiments described previously, which will not be described in detail herein.

[00118] Specifically, the code coverage testing device can be integrated into a terminal, and the terminal may be smart mobile phones, tablets, e-readers, MP3 players, MP4 players, laptops, portable computers, desktop computers and so on.

[00119] The communication system can achieve the same beneficial effect as a browser page data filtering device provided by the embodiments of the invention, which will not be described in detail herein.

[00120] Sixth embodiment

[00121] Accordingly, the invention also provides a terminal, as shown in Figure 4, the terminal may include a radio frequency (RF) circuit 401, a memory 402 including one or more computer-readable storage mediums, an input unit 403, a display unit 404, a sensor 405, an audio circuit 406, a wireless fidelity (WiFi) module 407, a processor 408 including one or more processing cores, a power supply 409 and other components. Its should be understood by those skilled in the art that, the terminal structure shown in Figure 4 does not constitute a limitation of the terminal and may include more or less components compared with the illustrated components in the figure, or include a combination of some of the components, or has a different component arrangement.

[00122] The RF circuit 401 can be used to receive or send a signal in an information receiving and sending process or a calling process. Specifically, the RF circuit 401 receives downlink information from a base station, and delivers the information to one or more processors 408 to process; in addition, the RF circuit 401 sends uplink data to the base station. Normally, the RF circuit 401 includes but not limited to an antenna, at least one amplifier, a tuner, one or more oscillators, a Subscriber Identity Module (SIM) card, a transceiver, a coupler, a Low Noise Amplifier (LNA), a duplexer and so on. Furthermore, the RF circuit 401 can also communicate with a network or other devices via a wireless communication. The wireless communication can employ any communication standard or protocol, including but not limited to a Global System of Mobile communication (GSM), a General Packet Radio Service (GPRS), a Code Division Multiple Access (CDMA), a Wideband Code Division Multiple Access (WCDMA), a Long Term Evolution (LTE), an e-mail, a Short Messaging Service (SMS) and so on.

[00123] The memory 402 can be used to store software programs and modules, and the processor 408 performs various function applications and data processing by executing the software programs or modules stored in the memory 402. The memory 402 can mainly include a program memory area and a data memory area. Specifically, the program memory area can store an operating system, an application program required by at least one function (such as a sound playing function, an image playing function) and so on; the data memory area can store data (such as audio data, a phone book) created according to terminal utilization, and so on. Furthermore, the memory 402 may be a high speed random access memory, and may also be a nonvolatile memory such as at least one magnetic disk memory device, a flash memory device or other volatile solid state memory device. Accordingly, the memory 402 may further include a memory controller for providing access of the processor 408 and the input unit 403 to the memory 402.

[00124] The input unit 403 can be used to receive digital information or character information that is input, and generate a keyboard signal input, a mouse signal input, a joystick signal input or a trackball signal input related to user settings and function control. Specifically, in a specific embodiment, the input unit 403 can include a touch-sensitive surface and other input devices. The touch-sensitive surface, also referred to as a touch display screen or a touch panel, can collect touch operations (such as operations on the touch-sensitive surface or in the vicinity of the touch-sensitive surface which are made by the user using any suitable object or accessory such as a finger, a touch pen) thereon or in the vicinity thereof by a user, and then drive a corresponding connection device according to a program set in advance. Optionally, the touch-sensitive surface can include a touch detection device and a touch controller. Specifically, the touch detection device detects the touch orientation of the user and a signal generated by the touch operation, and transmits the signal to the touch controller; the touch controller receives the touch information from the touch detection device, and converts the information into contact coordinates, then communicates the contact coordinates to the processor 408, and receives a command sent from the processor 408 to perform. Furthermore, the touch-sensitive surface can be realized by multiple types such as a resistive type, a capacitive type, an infrared type and a surface acoustic wave type. In addition to the touch-sensitive surface, the input unit 403 may also include other input devices. Specifically, the other input devices may include but not limited to one or more of a physical keyboard, a function key (such as a volume control button, a switch button), a trackball, a mouse, a joystick and so on.

[00125] The display unit 404 can be used to display information input by the user, information provided to the user, or various graphic user interfaces of the terminal, and these graphic user interfaces can be composed by a graphic, a text, an icon, a video and any other combination thereof. The display unit 404 may include a display panel, and optionally, the display panel can be configured as for example a Liquid Crystal Display (LCD) form or an Organic Light-Emitting Diode (OLED) form. Furthermore, the touch-sensitive surface can cover the display panel. When a touch operation is detected on the touch-sensitive surface or in the vicinity of the touch-sensitive surface, the touch-sensitive surface sends the touch operation to the processor 408 to determine a type of the touch event; the processor 408 then provides a corresponding visual output on the display panel according to the type of the touch event. Although in Figure 4 the touch-sensitive surface and the display panel are shown as two separate components to realize the input function and the output function, the touch-sensitive surface and the display panel can be integrated together to realize the input function and the output function in some embodiments.

[00126] The terminal may further include at least one sensor 405 such as a light sensor, a motion sensor and other sensors. Specifically, the light sensor may include an ambient light sensor and a proximity sensor, in which, the ambient light sensor can adjust brightness of the display panel according to the shading degree of ambient light, and the proximity sensor can turn off the display panel and/or a backlight when the terminal is moved to the user's ear. As one of the motion sensors, a gravity acceleration sensor can detect an acceleration value in each direction (generally, there are three axes), and detect a gravity value and a direction in a stationary state, and can be applied to an application (such as switching between landscape screen and portrait screen, related games, magnetometer attitude calibration) for identifying the attitude of a mobile phone, a function related to vibration identification (such as a pedometer, a tap) and so on. Other sensors such as a gyroscope, a barometer, a hygrometer, a thermometer, an infrared sensor, which can be equipped to the terminal, will not be described here any more.

[00127] An audio interface between the user and the terminal can be provided by the audio circuit 406, a loudspeaker and a microphone. The audio circuit 406 can convert the received audio data into an electrical signal and transmit the electrical signal to the loudspeaker, and the loudspeaker converts the electrical signal into a sound signal to output; on the other hand, the microphone converts the collected sound signal into an electrical signal and sends the electrical signal to the audio circuit 406, and the audio circuit 406 converts the received electrical signal into audio data and outputs the audio data to the processor 408 to process, the processed audio data is then sent to for example another terminal via the RF circuit 401 or output to the memory 402 for further process. The audio circuit 406 may also include an earphone jack to provide communication between a peripheral headphone and the terminal.

[00128] The WiFi is a short range wireless transmission technology, the terminal can assist the user in sending and receiving e-mails, browsing a webpage and accessing a streaming media and so on via the WiFi module 407, and the WiFi module 407 provides a wireless broadband internet access to the user. Although the WiFi module 407 is illustrated in Figure 4, it can be understood that the WiFi module 407 is not necessary in the terminal, and can be omitted according to needs without changing the scope of essence of the invention.

[00129] The processor 408, as a control center of the terminal, is used to connect all parts of of the whole mobile phone using various interfaces and lines, and performs various functions of the terminal and data processing by running or executing the software program and/or the module stored in the memory 402 and calling data stored in the memory 402, so as to monitor the whole mobile phone. Optionally, the processor 408 may include one or more processing cores; preferably, an application processor and a modem processor can be integrated into the processor 408, in which, the application processor mainly processes the operating system, a user interface, an application program and so on, and the modem processor mainly processes wireless communication. It can be understood that the modem processor described above may not be integrated into the processor 408

[00130] The terminal may further include the power supply 409 (e.g. a battery) supplying power to each component, preferably, the power source can be logically connected to the processor 408 via a power supply management system, thus functions such as charge management, discharge management, power consumption management and so on can be achieved by the power supply management system. The power supply 409 may further include any components such as one or more DC power supplies or AC power supplies, a recharge system, a power supply fault detection system, a power supply converter or inverter, or a power supply state indicator. [00131] Although not illustrated, the terminal may also include a camera, a Bluetooth module and so on, which will not be described in detail herein. Specifically, in the embodiment, the processor 408 in the terminal will load, according to the following instructions, executable files corresponding to processes of one or more application programs into a memory 402, and the processor 408 executes the application program stored in the memory 402 to achieve a variety of functions:

[00132] Although not illustrated, the terminal may also include a camera, a Bluetooth module and so on, which will not be described in detail herein. Specifically, in the embodiment, the display unit of the terminal is a touch screen display, and the terminal further includes a storage and one or more programs, wherein the one or more programs are stored in the storage, and are configured to make one or more processors execute instructions contained in the one or more programs to perform the following operations:

[00133] acquiring a binary file and a symbol table of the source codes; parsing the binary file according to the symbol table to determine a position of each function defined by the source code; setting, when the binary file is loaded into a memory (such as a non-pageable memory) and not yet executed, a debug point for a map of the binary file that is loaded into the memory, according to the position of the function; determining, according to the debug point, a code basic block that has been executed, and recording relevant information of the code basic block that has been executed to the memory; and converting the relevant information of the code basic block into code line information by using the symbol table, to obtain code lines that the test covers.

[00134] For example, the setting a debug point to a map of the binary file that is loaded into the memory according to the position of the function may include:

[00135] inserting a debug interrupt instruction at a beginning position of each function in the map of the binary file that is loaded into the memory, according to the position of the function.

[00136] At this point, the original content at this position can be stored so that it can be restored later.

[00137] The step "determining, according to the debug point, a code basic block that has been executed, and recording relevant information of the code basic block that has been executed to the memory" may be specifically as follows.

[00138] When a debug interrupt occurs and it is determined that the interrupt is caused by a set debug point, instruction decoding is made to codes behind the debug point causing the interrupt, until a jump point is found; codes between the debug point causing the interrupt and the jump point are determined as a code basic block that has been executed, and relevant information of the code basic block that has been executed is recorded to a basic block information table in a memory (such as a non-pageable memory). The relevant information of the code basic block may include information such as a start address and an end address of the code basic block.

[00139] For example, if a debug interrupt instruction has been inserted at a beginning position of each function in the map of the binary file that is loaded into the memory according to the position of the function, then when a debug interrupt occurs and it is determined that the interrupt is caused by the debug interrupt instruction, instruction decoding can be made to codes behind the debug interrupt instruction causing the interrupt, until a jump instruction is found. [00140] If the jump instruction is obtained by decoding, then after the jump instruction is found, it is also possible to determine whether the jump instruction is a direct jump instruction or an indirect jump instruction, then different treatments are performed for different situations, and an example thereof is shown as follows:

[00141] If the jump instruction is a direct jump instruction and it is determined that there is no code basic block in the basic block information table which takes the jump destination of the jump instruction as its start address, a debug interrupt instruction is inserted at a beginning position of a function corresponding to the jump instruction, i.e. the same treatment as the step 103 is performed.

[00142] And if the jump instruction is an indirect jump instruction, then the jump instruction is replaced with a debug interrupt instruction.

[00143] In addition, after the relevant information of the code basic block that has been executed is recorded to the basic block information table in the memory, the codes can also be restored to its original appearance, for example the inserted debug interrupt instruction is deleted. Thus, the debug interrupt will not occur when this code basic block is executed the next time. That is, after the step "recording relevant information of the code basic block that has been executed to a basic block information table in the memory", it may further include:

[00144] deleting the inserted debug interrupt instruction.

[00145] Specific implementation can be found in the previous embodiments, which will not be described in detail herein. [00146] It can be seen from the above that, in the terminal of the embodiment of the invention, a binary file and a symbol table generated after source codes are compiled are acquired, the binary file is parsed according to the symbol table to determine a position of function defined by each source code, then when the binary file is loaded into the memory and not yet executed, a debug point is set for a map of the binary file that is loaded into the memory according to the position of the function, a code basic block that has been executed is determined according to the debug point, and relevant information of the code basic block that has been executed is recorded to the memory, and finally the relevant information of the code basic block is converted into code line information by using the symbol table, to obtain code lines that the test covers. In the solution, the debug point is set only for the map of the binary file that is loaded into the memory, without making a substantial change to the binary file itself. Therefore, it can ensure that the binary file obtained by compiling the actual release codes is the same file as the binary file used in the test, thereby the reliability of test is greatly improved, and because the set object is the debug point, the real impact on the execution of codes is minimal.

[00147] In addition, instead of depending on file operations to record the code coverage degree, this solution records the code coverage degree in the memory, and can record the code coverage degree in a non-pageable memory if necessary, and since execution of the un-pageable memory is an extremely safe operation and can be performed in all execution occasions of the system, the impact on the system is minimal, thereby it is applicable to the driver program, to avoid situations of blue screen and crash caused by the test. [00148] It should be understood by those skilled in the art that all or a part of steps in various methods in the embodiments described above can be implemented by instructing related hardware using a program, the program can be stored in a computer readable storage medium, the storage medium may include a Read-Only Memory (ROM), a Random Access Memory (RAM), a magnetic disk, an optical disk or the like.

[00149] The code coverage testing method, device and system in the embodiments of the invention are introduced in detail above, the principle and the embodiments of the invention have been illustrated by several specific examples, and the above description of the embodiments is merely used to assist with understanding the method and the core concept of the invention. Meanwhile, for those skilled in the art, changes can be made to the embodiments and the application scope according to the concept of the invention. Therefore, it should be understood that contents in the specification should not be deemed as limiting the invention.

Claims

1. A code coverage testing method, comprising: acquiring a binary file and a symbol table generated after source codes are compiled; parsing the binary file according to the symbol table to determine a position of a function defined by each source code; setting, when the binary file is loaded into a memory and not yet executed, a debug point for a map of the binary file that is loaded into the memory, according to the position of the function; determining, according to the debug point, a code basic block that has been executed, and recording relevant information of the code basic block that has been executed in the memory; and converting the relevant information of the code basic block into code line information by using the symbol table, to obtain code lines that the test covers.

2. The method according to claim 1, wherein the determining, according to the debug point, a code basic block that has been executed, and recording relevant information of the code basic block that has been executed in the memory comprises: when a debug interrupt occurs and it is determined that the interrupt is caused by a set debug point, performing instruction decoding to codes behind the debug point causing the interrupt, till a jump point is found; and

determining codes between the debug point causing the interrupt and the jump point as a code basic block that has been executed, and recording relevant information of the code basic block that has been executed in a basic block information table in the memory.

3. The method according to claim 1, wherein the recording relevant information of the code basic block that has been executed in a basic block information table in the memory comprises:

recording the relevant information of the code basic block that has been executed in a basic block information table in a non-paged memory.

4. The method according to claim 2 or 3, wherein the setting a debug point for a map of the binary file that is loaded into the memory, according to the position of the function comprises:

inserting, according to the position of the function, a debug interrupt instruction at a beginning position of each function in the map of the binary file that is loaded into the memory; the when a debug interrupt occurs and it is determined that the interrupt is caused by a set debug point, performing instruction decoding to codes behind the debug point causing the interrupt, till a jump point is found comprises:

when a debug interrupt occurs and it is determined that the interrupt is caused by an inserted debug interrupt instruction, performing instruction decoding to codes behind the debug interrupt instruction causing the interrupt, till a jump instruction is found.

5. The method according to claim 4, where if the jump instruction is obtained by decoding, then after the jump instruction is found, the method further comprises: if the jump instruction is a direct jump instruction and it is determined that there is no code basic block in the basic block information table which takes the jump destination of the jump instruction as its start address, inserting a debug interrupt instruction at a jump destination position corresponding to the jump instruction; and

if the jump instruction is an indirect jump instruction, replacing the jump instruction with a debug interrupt instruction.

6. The method according to claim 4, wherein after the recording relevant information of the code basic block that has been executed in a basic block information table in the memory, the method further comprises:

deleting the inserted debug interrupt instruction.

7. The method according to any one of claims 1 to 3, wherein in the case where the relevant information of the code basic block comprises a start address and an end address of the code basic block, the converting the relevant information of the code basic block into code line information by using the symbol table, to obtain code lines that the test covers comprises:

converting, by using the symbol table, the start address and the end address of the code basic block into code line information, to obtain code lines that the test covers.

8. A code coverage testing device, comprising:

an acquiring unit, configured to acquire a binary file and a symbol table generated after source codes are compiled;

a parsing unit, configured to parse the binary file according to the symbol table to determine a position of a function defined by each source code;

a setting unit, configured to set, when the binary file is loaded into a memory and not yet executed, a debug point for a map of the binary file that is loaded into the memory, according to the position of the function; a processing unit, configured to determine, according to the debug point, a code basic block that has been executed, and record relevant information of the code basic block that has been executed in the memory, and

a converting unit, configured to convert the relevant information of the code basic block into code line information by using the symbol table, to obtain code lines that the test covers.

9. The code coverage testing device according to claim 8, wherein the processing unit comprises a testing sub-unit and a recording sub-unit; the testing sub-unit is configured to, when a debug interrupt occurs and it is determined that the interrupt is caused by a set debug point, perform instruction decoding to codes behind the debug point causing the interrupt, till a jump point is found; and

the recording sub-unit is configured to determine codes between the debug point causing the interrupt and the jump point as a code basic block that has been executed, and record relevant information of the code basic block that has been executed in a basic block information table in the memory.

10. The code coverage testing device according to claim 9, wherein the recording sub-unit is configured to determine codes between the debug point causing the interrupt and the jump point as a code basic block that has been executed, and record relevant information of the code basic block that has been executed in a basic block information table in a non-paged memory.

11. The code coverage testing device according to claim 9 or 10, wherein

the setting unit is configured to insert, according to the position of the function, a debug interrupt instruction at a beginning position of each function in the map of the binary file that is loaded into the memory; and

the testing sub-unit is configured to, when a debug interrupt occurs and it is determined that the interrupt is caused by an inserted debug interrupt instruction, perform instruction decoding to codes behind the debug interrupt instruction causing the interrupt, till a jump instruction is found.

12. The code coverage testing device according to claim 11, wherein the setting unit is further configured to: when it is determined that the jump instruction is obtained by decoding, determine whether the jump instruction is a direct jump instruction or an indirect jump instruction; and if the jump instruction is a direct jump instruction and it is determined that there is no code basic block in the basic block information table which takes the jump destination of the jump instruction as its start address, insert a debug interrupt instruction at a jump destination position corresponding to the jump instruction; and if the jump instruction is an indirect jump instruction, replace the jump instruction with a debug interrupt instruction.

13. The code coverage testing device according to claim 11, wherein the processing unit further comprises a deleting sub-unit; the deleting sub-unit is configured to delete the inserted debug interrupt instruction.

14. The code coverage testing device according to any one of claims 8 to 10, wherein in the case where the relevant information of the code basic block comprises a start address and an end address of the code basic block,

the converting unit is configured to convert, by using the symbol table, the start address and the end address of the code basic block into code line information, to obtain code lines that the test covers.

15. A communication system, comprising the code coverage testing device according to any one of claims 8 to 14.