Methods and Systems

Abstract

This invention provides a method and system for identifying one or more frontier branches in software testing. [Solution] A method to shorten the time required for testing involves receiving a branch of the software code under test provided by a father associated with the processing system, determining whether the status of two endpoints is processed or unprocessed based on the corresponding key information, performing predetermined operations on the unprocessed and processed endpoints according to the determination result, determining the status of the child blocks based on the basic block information of the second endpoint, determining the status of the sibling blocks based on the basic block information of the first endpoint, and determining the frontier branch based on the status of these child and sibling blocks.

Description

Technical Field

[0001] The present disclosure relates to the field of software testing. In particular, the present disclosure relates to a method and system for identifying one or more frontier branches in software testing.

Background Art

[0002] In the software industry, testing is conducted before release to ensure software integrity, with particular emphasis on evaluating security and non-functional risks in compiled software. Software testing is performed using software testing tools. Fuzz testing, or fuzzing, is a type of software testing that involves providing automatically generated input to the program / software under test and recording and observing any abnormal or unusual behavior in response to that input. In some cases, the input to the program / software under test may be induced by the tester. The fuzzer needs to execute all branches of the machine code to detect abnormal or unusual behavior. There may be cases where the fuzzer cannot generate input that satisfies a particular branch block (condition), or where external factors in the software prevent the input from progressing in the code area before reaching a particular branch. As a result, there may be branches in the software code under test that are not executed even with various inputs. These unexecuted branches are called "frontier branches," and their end blocks are called "frontier blocks." If a frontier branch remains unexecuted for an extended period, it can block critical parts of the software code, and such long-standing frontier branches are called "loadblocks." Generally, when the code size or input area is large, or when the source code is unavailable, it is difficult for testers to identify and prioritize frontier branches and loadblocks. Furthermore, if frontier branches / loadblocks are not identified in real time, testers cannot provide the father with the appropriate input to execute them. Traditional systems involve rerunning the software multiple times to execute frontier branches, which requires significant processing, increases software testing time, and consequently raises testing costs. Attempts to rerun that fail reduce test efficiency.Furthermore, traditional systems lack a mechanism for prioritizing numerous frontier branches. Additionally, if testing stalls after executing an unconditional branch within the software, traditional systems cannot identify all frontier branches. Therefore, it is necessary to identify frontier branches in real time during software testing.

[0003] The information contained in the background section of this disclosure is intended to enhance the understanding of the general background of the invention and should not be construed as indicating or suggesting that such information is prior art known to those skilled in the art. [Overview of the project]

[0004] Disclosed herein is a method for determining (identifying) one or more frontier branches during software testing. The method includes a processing system receiving a branch of the software code under test from a father associated with the processing system. The branch includes key information associated with two endpoints, each characterized as a first endpoint and a second endpoint. The key information includes the endpoint's address, a first list position indicating the location of file information related to the endpoint in a first list of a lookup database, and a second list position indicating the location of basic block information related to the endpoint in a second list of a lookup database. Furthermore, the method includes determining the status of each of the two endpoints as "processed" or "unprocessed" based on the corresponding key information. Subsequently, based on the determination of the status of the two endpoints, the method includes, for endpoints determined to be "unprocessed," either determining the first and second list positions of the endpoint from a lookup database for the endpoint, or retrieving basic block information related to the endpoint using the determined first and second list positions. The method includes obtaining the basic block information of an endpoint whose status has been determined to be "processed" using the updated location information of the endpoint at the first list location in the key information and the updated location information of the basic block information at the second list location. Furthermore, the method includes determining the status of at least one child block of the second endpoint based on the basic block information of the second endpoint and at least one sibling block of the second endpoint based on the basic block information of the first endpoint. Finally, the method includes determining (identifying) one or more frontier branches based on the determined status of at least one of the child blocks and sibling blocks.

[0005] Furthermore, disclosed herein is a processing system for determining (identifying) one or more frontier branches during software testing. The processing system comprises a processor and memory. The memory is communicably connected to the processor and stores processor-executable instructions. When these instructions are executed, the processor receives a branch of the software code under test from a father associated with the processing system. Each branch includes key information associated with two endpoints, each characterized as a first endpoint and a second endpoint. The key information includes the endpoint's address, a first list position indicating the location of file information related to the endpoint in a first list of a lookup database, and a second list position indicating the location of basic block information related to the endpoint in a second list of a lookup database. Furthermore, the processor determines the status of each of the two endpoints as "processed" or "unprocessed" based on the corresponding key information. Subsequently, based on the determination of the status of the two endpoints, for endpoints determined to be "unprocessed," the processor either determines the first and second list positions of the endpoint from a lookup database for the endpoint, or retrieves basic block information related to the endpoint using the determined first and second list positions. For endpoints whose status is determined to be "processed," the processor obtains the basic block information of the endpoint using the updated location information of the endpoint at the first list position in the key information and the updated location information of the basic block information at the second list position. Furthermore, the processor determines at least one state of one or more child blocks of the second endpoint based on the basic block information of the second endpoint, and the state of one or more sibling blocks of the second endpoint based on the basic block information of the first endpoint. Finally, the processor determines (identifies) one or more frontier branches based on the determined state of at least one of the one or more child blocks and one or more sibling blocks.

[0006] The above summary is for illustrative purposes only and is not intended to limit it in any way. In addition to the exemplary aspects, embodiments, and features described above, further aspects, embodiments, and features will become apparent by referring to the drawings and the detailed description below.

[0007] The accompanying drawings constitute part of this disclosure and illustrate exemplary embodiments, illustrating the principles disclosed in conjunction with the description. In the drawings, the leftmost number of a reference numeral indicates the drawing in which that reference numeral first appears. The same number is used throughout the drawings to refer to similar features and components. Several embodiments of systems and / or methods relating to the subject matter of this disclosure are described below with reference to the accompanying drawings for illustrative purposes only. [Brief explanation of the drawing]

[0008] [Figure 1A] Figure 1A shows an exemplary diagram of a control flow graph of software code according to some embodiments of the present disclosure. [Figure 1B] Figure 1B shows an exemplary architecture for determining (identifying) one or more frontier branches during software testing using the proposed processing system, according to some embodiments of the present disclosure. [Figure 1C] Figure 1C shows an exemplary lookup database according to some embodiments of the present disclosure. [Figure 1D] Figure 1D shows an exemplary lookup database according to some embodiments of the present disclosure. [Figure 1E] Figure 1E is a flowchart illustrating an exemplary method for determining basic block information according to some embodiments of the present disclosure. [Figure 1F] Figure 1F is a flowchart illustrating an exemplary method for performing a lookup operation in a lookup table according to some embodiments of the present disclosure. [Figure 1G]Figure 1G is a flowchart illustrating exemplary methods for adding and removing frontier branches according to some embodiments of the present disclosure. [Figure 2] Figure 2 shows a detailed block diagram of a processing system according to some embodiments of the present disclosure. [Figure 3] Figure 3 is a flowchart illustrating a method for determining (identifying) one or more frontier branches during software testing, according to some embodiments of the present disclosure. [Figure 4] Figure 4 shows a block diagram of an exemplary computer system for implementing an embodiment consistent with the present disclosure. [Modes for carrying out the invention]

[0009] Those skilled in the art should understand that the block diagrams described herein represent a conceptual view of an exemplary system embodying the principles of the subject matter. Similarly, flowcharts, flow diagrams, state transition diagrams, pseudocode, etc., represent various processes that can be substantially represented in a computer-readable medium and executed by a computer or processor, regardless of whether such a computer or processor is explicitly illustrated.

[0010] In this book, the term "exemplary" is used to mean "functioning as an example, case study, or illustration." Embodiments or implementations of the subject matter described as "exemplary" should not be construed as being preferable or advantageous compared to other embodiments.

[0011] While this disclosure allows for various modifications and alternative forms, specific embodiments are illustrated in the drawings and described in detail below. However, it should be understood that this disclosure is not intended to limit itself to any specific form disclosed, but rather to encompass all modifications, equivalents, and alternatives that fall within the scope of this disclosure.

[0012] The terms “comprises,” “comprising,” “includes,” or variations thereof, mean non-exclusive inclusion and, if a configuration, apparatus, or method includes a list of components or steps, it does not mean that it includes only those components or steps, but rather that it may include other components or steps that are not explicitly listed or that are specific to the configuration, apparatus, or method. In other words, one or more elements of a system or apparatus following “comprises… a” do not preclude the presence of additional or other elements.

[0013] The following definitions of key terms used in this disclosure are provided to ensure a proper understanding of the descriptions, including the various embodiments of this disclosure.

[0014] Basic block: A basic block is the fundamental unit of software code, containing a sequence of instructions that are executed in a specific order. Blocks 101-109 shown in Figure 1A are sometimes referred to as basic blocks.

[0015] Branch: A branch refers to a connection between basic blocks. In the context of this disclosure, each branch contains key information associated with two endpoints, characterized as the first endpoint and the second endpoint. In the context of this disclosure, “113” in Figure 1A refers to the branch connecting basic blocks 101 and 103. Similarly, in Figure 1A, branch 115 connects basic blocks 101 and 105, branch 117 connects basic blocks 103 and 107, and branch 119 connects basic blocks 103 and 109.

[0016] End-point: An end-point refers to a basic block that contains one or more addresses. As shown in Figure 1A, basic blocks 101 and 103 can be end-points connected by branch 113. The first end-point is 101, and the second end-point is 103. Further, the address of an end-point may refer to the first address within that basic block. For example, the address of end-point 101 is a1 shown in Figure 1A.

[0017] First list position: Indicates the position of file information related to an end-point within the first list of the lookup database.

[0018] Second list position: Indicates the position of basic block information related to an end-point within the second list of the lookup database.

[0019] Frontier branch: During software testing, a branch that has not been executed in the software code being tested may be called a frontier branch. Generally, the subsequent basic block of a frontier branch is not executed, but the basic block before the frontier branch has been executed. Referring to Figure 1A, branch 117 may be called a frontier branch. In this case, the subsequent basic block 107 of branch 117 is not executed, but the basic block 103 before branch 117 has been executed.

[0020] As outlined in the background technology section, the technical challenge lies in the lack of a system for identifying one or more frontier branches in the software code under test in real time. Before the start of the software testing process, the processing system may generate a lookup database using the software code under test. The generated lookup database has a configuration that includes, but is not limited to, a first list, a first list binary search tree, a second list, a second list binary search tree, a third list, and a fourth list, and allows access to information related to each basic block of the software code under test, the details of which are described in the detailed explanation section below. After the lookup database is generated, the processing system may receive a branch of the software code under test from a father associated with the processing system. The branch contains key information related to two endpoints, each characterized as the first endpoint and the second endpoint. The key information includes the endpoint address, the first list position indicating the location of the file information related to that endpoint in the first list of the lookup database, and the second list position indicating the location of the basic block information related to that endpoint in the second list of the lookup database.

[0021] When a branch is received, the processing system may determine the status of each of the two endpoints as "processed" or "unprocessed" based on the corresponding key information. For endpoints whose status is determined to be "unprocessed," the processing system may determine the first and second list locations of the endpoint from the lookup database and use the determined first and second list locations to obtain the basic block information associated with the endpoint. The process of determining the first and second list locations will be described in detail in the detailed explanation below. For endpoints whose status is determined to be "processed," the processing system may use the updated location information of the endpoint at the first list location and the updated location information of the basic block information at the second list location from the endpoint's key information to obtain the basic block information of the endpoint. After determining the basic block information, the processing system may determine at least one of the following based on the basic block information of the second endpoint: the status of one or more child blocks, and the status of one or more sibling blocks based on the basic block information of the first endpoint. Finally, the processing system may determine (identify) one or more frontier branches based on the determined status of at least one of the one or more child blocks and one or more sibling blocks. One or more frontier branches may be displayed on a display device associated with the processing system.

[0022] The present disclosure generates a lookup database before the start of software testing. The lookup database stores basic block information for each basic block within the software code to be tested. The processing system may determine one or more frontier branches in real time based on the state of at least one of one or more sibling blocks and one or more child blocks, without individually executing the one or more sibling blocks or the one or more child blocks. The basic block information of an endpoint includes one or more child pointers indicating the first list position and the second list position of one or more child blocks of the endpoint within the lookup database, thereby helping to obtain the basic block information of the one or more child blocks. The basic block information of the one or more child blocks helps to determine the flag state of the one or more child blocks indicating whether the one or more child blocks have been executed in the past. Additionally, the processing system updates the first list position in the key information with the position information in the first list of the endpoint and updates the second list position with the position information in the second list of the endpoint's basic block information, thereby avoiding additional processing to search for the first list position and the second list position when the same endpoint reappears, thus contributing to shortening the test time. Further, instead of re-executing the software, the processing system determines (identifies) one or more frontier branches based on the flag state within the basic block information. The one or more frontier branches are displayed on a display device in real time, and the software tester can correspond to the frontier branches in real time without stopping the test process.

[0023] In the following detailed description of embodiments of the present disclosure, reference is made to the accompanying drawings that form a part hereof, in which are shown, by way of illustration, specific embodiments in which the disclosure may be practiced. These embodiments are described in sufficient detail to enable those skilled in the art to practice the disclosure, but other embodiments may be utilized and changes may be made without departing from the scope of the disclosure. It should be understood, therefore, that the following description should not be construed in a limiting sense.

[0024] Figure 1B shows an exemplary architecture for determining (identifying) one or more frontier branches during software testing using a processing system proposed according to some embodiments of this disclosure.

[0025] An exemplary architecture includes a software binary file 120, a test system 121, a lookup database 127, and a visualizer 129. The test system 121 may include a father 125 and a processing system 123, the father 125 communicating with the processing system 123, and the processing system 123 being associated with the lookup database 127. In one embodiment, the test system 121 may receive the software binary file 120 from a user / tester. The software binary file 120 may be a software file to be tested by the test system 121. In one embodiment, the test system 121 may be associated with a visualizer 129, which may be a display device used to display the frontier branch. Details regarding the display of the frontier branch are described in subsequent sections of this disclosure. In one embodiment, the test system 121 may be configured as a computing device. For example, the computing device includes, but is not limited to, any device used by the user, such as a mobile phone, smartphone, laptop, or personal computer (PC). In some embodiments, the processing system 123 may be external to the father 125 and be associated with the father 125 via a communication network (not shown). For example, the communication network may be a wired communication network, a wireless communication network, or a combination of both. In one embodiment, the father 125 may be a software testing tool that runs the software multiple times and uses different inputs each time to detect abnormal behavior in the software. The father 125 may include a dynamic instrumentation module that receives information related to the location of blocks executed during execution. For example, the father 125 may include, but is not limited to, AFL++, HongFuzz, AFLSmart, and LibFuzzer.

[0026] In one embodiment, the lookup database 127 may be generated before the start of the software testing process using the software binary file 120 of the software under test. In one embodiment, the software binary file 120 may be preprocessed and compiled before testing using a preprocessor (not shown) to generate the lookup database 127. The software under test may include one or more basic blocks and one or more branches connecting the corresponding basic blocks, which may form a control flow graph (CFG). A branch is a logical connection between two basic blocks. Figure 1A shows an exemplary CFG including basic blocks 101-109 and branches 113-119. For example, branch 113 may connect basic blocks 101 and 103.

[0027] As shown in Figure 1C, the lookup database 127 in Figure 1C may have a configuration including, but is not limited to, a first list 131, a first list binary search tree 133, a third list 135, a second list 137, a second list binary search tree 139, and a fourth list 141. The first list 131 may store information related to the endpoints of each branch of the software code under test. Figure 1D shows an exemplary lookup database 127 with components similar to those in Figure 1C. In the context of this disclosure, the file information of an endpoint may be determined in real time when the endpoint is detected or discovered during software testing. The file information may include the location of the endpoint's basic block information in the second list 137 of the lookup database 127. The second list 137 may store basic block information for one or more basic blocks. The basic block information may include, but is not limited to, a coverage gain value indicating the total number of subsequent blocks associated with the endpoint, a flag value indicating whether the endpoint has been executed before, and one or more child pointers indicating the first and second list locations of one or more child blocks of the endpoint.

[0028] The first list binary search tree 133 may store multiple address ranges, which may map to multiple corresponding locations in the endpoint file information within the first list 131. The third list 135 may contain filenames and locations in the endpoint file information within the first list 131. In one embodiment, the third list 135 may be a pre-generated list created before the start of the software testing process. For example, the third list 135 may be a lookup table. The fourth list 141 may store a list of files loaded into the lookup database 127 during software testing. The fourth list 141 may be used to avoid reloading files that already exist in the lookup database 127. In one embodiment, the lookup database 127 may be used to determine basic block information related to an endpoint during software testing. In one implementation, when a user submits a list of software binary files 120 for testing, the second list 137, the second list binary search tree 139, and the third list 135 may be generated in the lookup database 127. In some embodiments, the first list 131, the first list binary search tree 133, and the fourth list 141 of the lookup database 127 may be dynamically updated during the software testing process.

[0029] In one embodiment, the processing system 123 may be configured to receive a branch of the software code under test, i.e., the software binary file 120, from a father 125 associated with the processing system 123 (see step 151 in Figure 1E). The branch may contain key information associated with two endpoints, each characterized as a first endpoint and a second endpoint. The key information may include, but is not limited to, the endpoint's address, a first list position indicating the location of the file information associated with the endpoint in the first list 131 of the lookup database 127, and a second list position indicating the location of the basic block information associated with the endpoint in the second list 137 of the lookup database 127. As shown in Figure 1A, branch 113 may connect basic blocks 101 and 103, and the branch may contain two endpoints characterized as a first endpoint 101 and a second endpoint 103. In some embodiments, the key information may include a file boundary. File boundaries will be described in more detail in subsequent parts of this disclosure.

[0030] In one embodiment, upon receiving a branch, the processing system 123 may be configured to determine the status of each of the two endpoints as either "processed" or "unprocessed" based on the corresponding key information (see step 153 in Figure 1E). In one embodiment, an endpoint may be determined to be "processed" if the first list position is updated with the endpoint's location information in the first list 131 and the second list position is updated with the endpoint's basic block information location in the second list 137. In some embodiments, after processing an endpoint, the processing system 123 may not be able to find the endpoint's location information in the first list 131 and the endpoint's basic block information location in the second list 137 in order to update the first and second list positions in the key information. In such cases, the first and second list positions may be updated with invalid values. For example, the invalid value may be "-1", which may indicate that the endpoint is processed, but the first and second list positions cannot be found even after performing a lookup operation. In one embodiment, an endpoint may be determined to be "unprocessed" if the first and second list positions contain values ​​indicating that the endpoint is not set. For example, if the values ​​for the first and second list positions are "-2", this indicates that the first and second list positions are not set. In other words, the value "-2" may indicate that the endpoint is unprocessed. In some embodiments, the state of both endpoints may be "unprocessed". In other embodiments, the state of one endpoint may be "processed" and the state of the other endpoint may be "unprocessed". In yet another embodiment, the state of both endpoints may be "processed".

[0031] If both endpoints are determined to be processed in step 153, the method proceeds to step 155 with "Yes". If both endpoints are determined to be "not processed" in step 153, the method proceeds to step 157 with "No". In step 157 of Figure 1E, the method includes checking whether the first list position of the endpoint is set or not. If the first list position is set, the method proceeds to step 153 with "Yes" as described above. If the first list position is not set, the method proceeds to step 159 with "No". In step 159, the processing system 123 may perform lookup operations on the first and second list positions using the endpoint addresses, which will be further described and illustrated in Figure 1F. After performing the lookup operations, the basic block information of the endpoint is returned to the father 125 (step 161). The first list position in the key information may be updated with the endpoint's position information in the first list, and the second list position in the key information may be updated with the position information of the endpoint's basic block information in the second list. This avoids having to perform the lookup operation again if the same endpoint reappears. After returning the basic block information of the endpoint to father 125, the method returns to step 153 to determine if both endpoints of the branch have been processed. If both endpoints have been processed, the processing system 123 may wait for a new branch to be received. However, if a first list position has been set, the process may return to step 153 because the first list position already exists in father 125.

[0032] Furthermore, the method for performing a lookup operation in the lookup table shown in step 159 is further illustrated by Figure 1F. In step 171 of Figure 1F, the processing system 123 may determine the address range to which the endpoint's address belongs from among several address ranges stored in the first list binary search tree 133 of the lookup database 127. Each of the multiple address ranges is mapped to a corresponding position in the first list 131. After determining the address range, the processing system 123 may determine the first list position of the endpoint at a position in the first list 131 corresponding to the determined address range. In other words, the processing system 123 may determine whether an entry exists in the first list binary search tree 133 (see step 173 in Figure 1F). If an entry exists, the method proceeds to step 187 shown in Figure 1F. If an entry does not exist, the method proceeds to step 175 shown in Figure 1F. In step 187, the processing system 123 may set the first list position with the value of the found entry and the endpoint file boundary with the key of the found entry (see step 187 in Figure 1F). The value of the found entry indicates a position in the first list 131, and the key of the found entry may be an address range indicating the endpoint file boundary. In some embodiments, the processing system 123 may update the endpoint file boundary to the father 125. The father 125 may make the branch public, i.e., provide it to the processing system 123, only if the branch belongs to a file that exists in a user-provided software binary file. For example, Libc is a C standard library that is usually packaged with the operating system, and Libc is unrelated to user-provided software binary files. Therefore, the user may choose to avoid scanning for bugs in the Libc binary file.To verify whether the latest branch, i.e., the branch following the current branch, resides in an invalid file, Father 125 may check whether the branch belongs to the file boundary of the previous branch and whether invalid values ​​exist in the first and second list positions. If the latest branch resides in an invalid file, Father 125 may not send that branch to the processing system 123 in order to determine the first and second list positions of the endpoint associated with the latest branch. This avoids additional processing if the latest branch resides in an invalid file.

[0033] For example, suppose the address range is "1200~1800", which maps to position "300" in the first list 131, and the endpoint address in the key information is "1300", which is within the range of 1200~1800 and maps to position "300" in the first list 131. In this case, the first list position may be "300", which includes the base address of the endpoint. The file boundary may be the range "1200~1800" within the first list binary search tree 133. After determining the first list position, in step 189, the processing system 123 may determine whether or not an invalid value exists at the first list position. As explained in the previous section, in some scenarios, the processing system 123 may not be able to determine the first list position even after performing a lookup operation. For example, if the user does not want to test a particular file, the first list position may not be found in such a scenario. In that case, the process terminates (see step 195 in Figure 1F).

[0034] In one embodiment, if a valid value exists at the first list position, the method proceeds to step 191 in Figure 1F, where the processing system 123 may obtain the endpoint offset based on the difference between the endpoint address and the corresponding endpoint base address. Considering the example above, the endpoint address is "1300", and the endpoint base address at the first list position "300" is "800". The offset obtained by performing a subtraction operation between the endpoint address and the base address is "500". In one embodiment, after obtaining the offset, the processing system 123 may determine the offset range to which the endpoint offset belongs from a plurality of offset ranges stored in the second list binary search tree 139 of the lookup database 127. Each of the plurality of offset ranges is mapped to a plurality of corresponding positions in the second list 137. Furthermore, the processing system 123 may determine the second list position of the endpoint from a plurality of positions in the second list corresponding to the determined offset range (see step 193 in Figure 1F).

[0035] Returning to step 173, in one embodiment, if no entry exists in the first list binary search tree 133, the method proceeds to step 175. In step 175, the processing system 123 may find the memory-mapped address range of the endpoint from the process map for files not loaded in the fourth list 141 (see step 175 in Figure 1F). Subsequently, if the processing system 123 determines that a new file that was not previously loaded into the first list binary search tree 133 exists in the fourth list 141, the processing system 123 may look up the location of the new file in the third list 137 using the file name (see steps 177 and 179 in Figure 1F). In one embodiment, if no new file exists, the process returns to step 189 and may determine whether the value of the first list location is valid or invalid as described above. After performing the lookup operation in the third list 137, the processing system 123 determines whether the address of the endpoint is within the range of the file (see step 181 in Figure 1F). The processing system 123 may update the first list binary search tree 133 with the address range and the base address corresponding to the looked-up position, i.e., the first list position and the first list position within the first list 131 (see step 183 in Figure 1F). The process then returns to step 177, and the second list position may be identified as described above.

[0036] In one embodiment, after determining the first list position and the second list position for an endpoint, the processing system 123 may use the determined first list position and the second list position to obtain basic block information related to the endpoint. In one embodiment, when the processing system 123 obtains the basic block information, it may update the flag state in the endpoint's basic block information. For example, the processing system 123 may update the flag state from "0" to "1" to indicate that the endpoint has been processed / visited (see step 201 in Figure 1G). In one embodiment, the processing system 123 may update the first list position in the corresponding endpoint's key information with the endpoint's position information in the first list 131, and update the second list position with the endpoint's position information in the basic block information of the endpoint in the second list 137.

[0037] In one embodiment, for an endpoint whose status is determined to be "processed," the processing system 123 may obtain the basic block information of the endpoint using the updated location information of the endpoint at the first list position in the endpoint's key information and the updated location information of the endpoint's basic block information at the second list position (see step 207 in Figure 1G). As described above, if either of the two endpoints is processed, the processing system 123 may obtain the basic block information by directly using the first and second list positions updated in the key information of the endpoint processed in the previous iteration. This avoids the need for additional processing to re-determine the first and second list positions for an endpoint that has already been processed.

[0038] In one embodiment, after obtaining basic block information associated with an endpoint, the processing system 123 may determine whether the endpoint has one or more child pointers (see step 209 in Figure 1G). In other words, the processing system 123 may determine whether the first endpoint and the second endpoint have one or more child blocks. In some embodiments, the processing system 123 may determine at least one state of one or more child blocks based on the basic block information of the second endpoint among the branch endpoints, and at least one sibling block of the second endpoint based on the basic block information of the first endpoint (see step 211 in Figure 1G). In this context, one or more sibling blocks of the second endpoint may also be referred to as one or more child blocks of the first endpoint. Consider an exemplary scenario in the exemplary CFG shown in Figure 1A, where branch 113 is received for testing and branch 113 has a first endpoint 101 and a second endpoint 103. Basic blocks 107 and 109 are child blocks of the second endpoint 103, and basic block 105 is a sibling block of the second endpoint.

[0039] In one embodiment, after determining the state of at least one of the child blocks and sibling blocks of the second endpoint, the processing system 123 may determine (identify) one or more frontier branches based on at least one of the determined states of the child blocks and sibling blocks. In one embodiment, the processing system 123 may determine (identify) one or more frontier branches based on flag values ​​in the basic block information. For example, if the flag value of a child block is "0", it indicates that the child block is not executed / not visited. Similarly, if the flag value of a sibling block is "0", it indicates that the sibling block is not executed / not visited. Conversely, if the flag value of a child block is "1", it indicates that the child block has been executed / visited. Similarly, if the flag value of a sibling block is "1", it indicates that the sibling block has been executed / visited. In one embodiment, if the subsequent basic block of a branch is not executed and the basic block preceding the branch has been executed, the branch may be called a frontier branch. Referring to Figure 1A, branch 117 is sometimes called a frontier branch. In this case, the subsequent base block 107 of branch 117 is not yet executed, but the base block 103 that precedes branch 117 has been executed.

[0040] The processing system 123 may instruct the display device associated with the processing system 123 (also called the visualizer 129) to display one or more frontier branches in real time. Furthermore, the processing system 123 may instruct the visualizer 129 to remove one or more frontier branches in real time when the flag value changes from "0" to "1" (see step 213 in Figure 1G). Referring to Figure 1A, if the subsequent base block 107 of branch 117 is executed, branch 117 is no longer considered a frontier branch. When step 213 is executed, the processing system 123 may remove child pointers from the second list 137. This eliminates the need to re-determine the state of the same child block that has already been visited / covered. In this way, child pointers corresponding to visited / covered child blocks are removed from the second list 137. Depending on the change in the flag value, one or more frontier branches are added / removed from the display device in real time. Referring to step 217 in Figure 1G, the processing system 123 may instruct the visualizer 129 to add a frontier branch if one or more child blocks are not covered. Furthermore, the processing system 123 may update the visualizer lookup key in the child pointer if a visualizer lookup key is available (see step 219 in Figure 1G). In some embodiments, if a visualizer lookup key is not available, the method may return to step 209 after instructing the visualizer 129 to add a frontier branch (see step 217 in Figure 1). Also in some embodiments, the base block information may be updated to include a visualizer lookup key, which is a key for locating one or more frontier branches in the display device. The visualizer lookup key is used to update one or more frontier branches displayed in the display device in real time.

[0041] Figure 2 shows a detailed block diagram of a processing system 123 according to some embodiments of the present disclosure.

[0042] In some implementations, the processing system 123 may include an I / O interface 301, a processor 303, and a memory 305. In one embodiment, the memory 305 may be communicatively connected to the processor 303. The processor 303 may be configured to perform one or more functions of the processing system 123 for detecting unexecuted code blocks during software testing, using data 307 and one or more modules 309 of the processing system 123. In one embodiment, the memory 305 may store data 307.

[0043] In one embodiment, the data 307 stored in memory 305 may include, but are not limited to, location data 311, frontier branch data 313, and other data 315. In some implementations, the data 307 may be stored in memory 305 in the form of various data structures. Furthermore, the data 307 may be configured using a data model such as a relational or hierarchical data model. The other data 315 may include various temporary data and files generated by one or more modules 309.

[0044] In one embodiment, location data 311 may store updated location information of the endpoint at the first list location and updated location information of the base block information of the endpoint at the second list location. Location data 311 may be updated in father 125. Location data 311 may be used by processing system 123 to determine the base block information of the endpoint in the second list 137.

[0045] In one embodiment, the frontier branch data 313 may store the current / active frontier branch in the software under software testing. In one embodiment, a branch may be called a frontier branch if its subsequent base blocks have not yet been executed and its preceding base blocks have been executed. In one embodiment, one or more frontier branches may be displayed to the user in real time. In one embodiment, the frontier branch data 313 may be updated in real time. For example, if a subsequent base block of a frontier branch is executed, that branch is no longer a frontier branch. Branches that are no longer frontier branches are removed from the frontier branch data 313.

[0046] In one embodiment, the data 307 may be processed by one or more modules 309 of the processing system 123. In some implementations, one or more modules 309 may be communicatively connected to the processor 303 to perform one or more functions of the processing system 123. In one implementation, one or more modules 309 may include, but are not limited to, a transceiver module 317, a decision module 319, and other modules 223.

[0047] As used herein, the term “module” may refer to an application-specific integrated circuit (ASIC), an electronic circuit, a hardware processor 303 (shared, dedicated, or grouped), and a memory, combinational logic circuit, and / or other appropriate component that runs one or more software or firmware programs and provides the functions described herein. In one implementation, one or more modules 309 may be configured as standalone hardware computing units. In one embodiment, other modules 223 may be used to perform various auxiliary functions on the processing system 123. As those skilled in the art will understand, these one or more modules 309 may be represented as a single module or as a combination of different modules.

[0048] In one embodiment, the transceiver module 317 may be configured to receive a branch of the software code under test from a father 125 associated with the processing system 123. The branch includes key information associated with two endpoints, each characterized as a first endpoint and a second endpoint. The key information includes the endpoint address, a first list position indicating the location of file information related to the endpoint in the first list of the lookup database, and a second list position indicating the location of basic block information related to the endpoint in the second list of the lookup database. For example, before testing, the first and second list positions may hold the value "-2", which indicates that the endpoint is untouched. The lookup database may include at least one of the following: first list 131, first list binary search tree 133, third list 135, second list 137, second list binary search tree 139, and fourth list 141.

[0049] In one embodiment, the determination module 319 may be configured to determine the status of each of two endpoints as "processed" or "unprocessed" based on corresponding key information. In one embodiment, for an endpoint whose status is determined to be "unprocessed," the determination module 319 may determine the first list position and second list position of the endpoint from the endpoint lookup database. An endpoint is determined to be "unprocessed" if the first list position and second list position contain unset values. In some embodiments, after processing an endpoint, the determination module 319 may not be able to find the endpoint's position information in the first list 131 and the position information of the basic block information in the second list 137 in order to update the first list position and second list position in the key information. In such cases, the first list position and second list position may be updated with invalid values. For example, an invalid value is "-1," which indicates that the endpoint is processed, but the first list position and second list position cannot be found even after performing the lookup operation. In one embodiment, an endpoint may be determined to be "unprocessed" if the first list position and second list position contain values ​​that indicate the endpoint is unset. For example, if the values ​​for the first and second list positions are "-2", this indicates that the first and second list positions are not set. In other words, the value "-2" indicates that the endpoint is unprocessed.

[0050] In one embodiment, the determination module 319 may determine the address range to which the endpoint's address belongs from among multiple address ranges stored in the first list binary search tree 133 of the lookup database. Each of the multiple address ranges is mapped to a corresponding position in the first list 131. Furthermore, the determination module 319 may determine the first list position of the endpoint at one of the positions in the first list 131 corresponding to the determined address range. For example, referring to Figure 1D, the address range "a1~a2" corresponds to position P1 in the first list 131. Similarly, the address range "a3~a4" corresponds to position P3. Therefore, if the endpoint's address is included in the range "a1~a2", the first list position may be P1. After determining the first list position, the determination module 319 may perform a predetermined operation to obtain the endpoint's offset using the endpoint's address and the base address of the first list position. For example, the predetermined operation is a subtraction operation. The determination module 319 may obtain the corresponding offset by subtracting the base address from the endpoint's address. After obtaining the offset, the determination module 319 may determine the offset range to which the endpoint's offset belongs from among multiple offset ranges stored in the second list binary search tree 139 of the lookup database. Each of the multiple offset ranges is mapped to a corresponding position in the second list 137. Furthermore, the determination module 319 may determine the second list position of the endpoint from among the multiple positions in the second list 137 corresponding to the determined offset range. For example, referring to Figure 1D, the offset range "o1~o2" corresponds to position P1 in the second list 137. Similarly, the offset range "o5~o6" corresponds to position P8. Therefore, if the endpoint's offset is included in the range "o1~o2", the second list position may be P1. Subsequently, the determination module 319 may use the second list position to obtain basic block information related to the endpoint.In one embodiment, the determination module 319 may update the first list position in the key information with the position information of the endpoint in the first list 131, and update the second list position with the position information of the basic block information of the endpoint in the second list 137.

[0051] In one embodiment, for an endpoint whose status is determined to be "processed," the determination module 319 may be configured to obtain the basic block information of the endpoint using the updated location information of the endpoint at the first list position in the key information and the updated location information of the endpoint's basic block information at the second list position. An endpoint is determined to be "processed" if the first list position in the key information is updated with the location information of the endpoint in the first list 131, and the second list position is updated with the location information of the endpoint's basic block information in the second list 137. In some embodiments, the determination module 319 may determine whether the first list position is invalid based on an invalid value present at the first list position. As described above, in some scenarios, the determination module 319 may not be able to determine the first list position even after performing a lookup operation. For example, if the user does not want to test a particular file, the first list position may not be found in such a scenario. In that case, the lookup process for that endpoint terminates.

[0052] Furthermore, the determination module 319 may determine the state of at least one child block based on the basic block information of the second endpoint, and at least one sibling block of the second endpoint based on the basic block information of the first endpoint. Subsequently, the determination module 319 may determine (identify) one or more frontier branches based on the determined state of at least one child block and one or more sibling blocks. The determined (identified) one or more frontier branches may be displayed in the visualizer 129 associated with the processing system 123.

[0053] Figure 3 is a flowchart illustrating a method for determining (identifying) one or more frontier branches during software testing, according to some embodiments of the present disclosure.

[0054] As shown in Figure 3, Method 300 may include several blocks that demonstrate how to determine (identify) one or more frontier branches during software testing using the processing system 123 shown in Figure 2. Method 300 may be described in the general context of computer executable instructions. Generally, computer executable instructions may include routines, programs, objects, components, data structures, procedures, modules, and functions that perform a specific function or implement a specific abstract data type.

[0055] The order in which Method 300 is described is not intended to be construed as a restriction, and any number of the described Method blocks can be combined in any order to implement the Method. Furthermore, individual blocks can be removed from the Method without departing from the scope of the subject matter described herein. In addition, the Method can be implemented with appropriate hardware, software, firmware, or a combination thereof.

[0056] In step 301, method 300 includes receiving a branch of the software code under test from a father associated with the processing system by the processor 303 of the processing system 123. The branch may include, but is not limited to, key information associated with two endpoints, each characterized as a first endpoint and a second endpoint. The key information may include, but is not limited to, the endpoint address, a first list position indicating the location of file information related to the endpoint in the first list 131 of the lookup database 127, and a second list position indicating the location of basic block information related to the endpoint in the second list 137 of the lookup database 127. The lookup database 127 may include, but is not limited to, at least one of the first list 131, the second list 137, the third list 135, the fourth list 141, the first list binary search tree 133, and the second list binary search tree 139.

[0057] In step 303, method 300 includes the processor 303 determining the status of each of the two endpoints as "processed" or "unprocessed" based on the corresponding key information. In one embodiment, if the first list position in the key information is updated with the endpoint's position information in the first list 131, and the second list position in the key information is updated with the endpoint's basic block information position in the second list 137, the endpoint is determined to be "processed". In one embodiment, if the first list position and the second list position include unset values, the endpoint is determined to be "unprocessed".

[0058] In block 305, based on the determination of the status of each of the two endpoints, method 300 includes, for endpoints whose status is determined to be "unprocessed" by the processor 303, either determining the first list position and second list position of the endpoint from the lookup database 127, or obtaining basic block information related to the endpoint using the determined first list position and second list position. For endpoints whose status is determined to be "processed", basic block information of the endpoint is obtained using the updated position information of the endpoint at the first list position in the endpoint's key information and the updated position information of the endpoint's basic block information at the second list position. The basic block information is not limited to but may include at least one of the following: a coverage gain value indicating the total number of subsequent blocks related to the endpoint, a flag value indicating whether the endpoint has been executed before, and one or more child pointers indicating the first list position and second list position of one or more child blocks of the second endpoint. In one embodiment, the processor may determine the address range to which the endpoint's address belongs from a plurality of address ranges stored in the first list binary search tree 133 of the lookup database 127. Multiple address ranges are mapped to corresponding positions within the first list 131. Furthermore, the processor may determine the first list position of the endpoint at the positions within the first list 131 corresponding to the determined address ranges. After determining the first list position, the processor may perform a predetermined operation to obtain the endpoint's offset using the endpoint's address and the base address of the first list position. The processor may obtain the corresponding offset by subtracting the base address from the endpoint's address. After obtaining the offset, the processor may determine the offset range to which the endpoint's offset belongs from a set of offset ranges stored in the second list binary search tree 139 of the lookup database 127.Multiple offset ranges are mapped to corresponding positions within the second list 137. Furthermore, the processor may determine the second list position of the endpoint from the positions within the second list 137 corresponding to the determined offset ranges. In one embodiment, the processor may update the first list position in the key information with the endpoint's position information in the first list 131, and update the second list position with the endpoint's position information in the second list 137.

[0059] In step 307, method 300 includes the processor 303 determining the state of at least one child block based on the basic block information of the second endpoint and at least one sibling block of the second endpoint based on the basic block information of the first endpoint.

[0060] In block 309, method 300 includes the processor 303 determining (identifying) one or more frontier branches based on the determined state of at least one of the one or more child blocks and one or more sibling blocks. In one embodiment, the processor 303 may instruct a display device associated with the processing system 123 to display the one or more frontier branches.

[0061] (Computer system) Figure 4 shows a block diagram of an exemplary computer system 400 for implementing an embodiment consistent with the present disclosure. In one embodiment, the computer system 400 may be the processing system 123 shown in Figures 1B and 2. The computer system 400 may include a central processing unit ("CPU" or "processor" or "memory controller") 402. The processor 402 may include at least one data processor that executes program components for performing business processes generated by a user or system. The user may include a network administrator, application developer, programmer, organization, or any system / subsystem operating in parallel with the computer system 400. The processor 402 may include specialized processing units such as an integrated system (bus) controller, a memory controller / memory management control unit, a floating-point arithmetic unit, a graphics processing unit, and a digital signal processing unit.

[0062] The processor 402 may be configured to communicate with one or more input / output (I / O) devices (411 and 412) via the I / O interface 401. The I / O interface 401 may employ, but is not limited to, communication protocols / methods such as audio, analog, digital, stereo, IEEE®-1394, serial bus, Universal Serial Bus (USB), infrared, PS / 2, BNC, coaxial, component, composite, Digital Visual Interface (DVI), High Definition Multimedia Interface (HDMI®), radio frequency (RF) antenna, S-Video, Video Graphics Array (VGA), IEEE® 802.n / b / g / n / x, Bluetooth, and cellular (e.g., Code-Division Multiple Access (CDMA), High-Speed ​​Packet Access (HSPA+), Global System For Mobile Communications (GSM), Long-Term Evolution (LTE), etc.). By using the I / O interface 401, the computer system 400 can communicate with one or more I / O devices 411 and 412.

[0063] In some embodiments, the processor 402 may be configured to communicate with the network 409 via a network interface 403. The network interface 403 may communicate with the network 409. The network interface 403 may employ, but is not limited to, direct connection, Ethernet (e.g., twisted-pair 10 / 100 / 1000 Base T), Transmission Control Protocol / Internet Protocol (TCP / IP), Token Ring, or IEEE® 802.11a / b / g / n / x connection protocols.

[0064] In one implementation, the preferred network 409 may be implemented as one of several types of networks within an organization, such as an intranet or a local area network (LAN). The preferred network 409 may be either a dedicated network or a shared network, which may represent a collection of several types of networks that use various protocols to communicate with each other, such as Hypertext Transfer Protocol (HTTP), Transmission Control Protocol / Internet Protocol (TCP / IP), and Wireless Application Protocol (WAP). Furthermore, network 409 may include various network devices, such as routers, bridges, transceiver systems, computing devices, and storage devices. Using network interface 403 and network 409, the computer system 400 can communicate with the father 125 and lookup database 127 of the test system 121.

[0065] In some embodiments, the processor 402 may be configured to communicate with memory 405 (e.g., RAM 413, ROM 414, etc., as shown in Figure 6) via a storage interface 404. The storage interface 404 may connect to memory 405, including, but is not limited to, memory drives, removable disk drives, etc., and may employ connection protocols such as Serial Advanced Technology Attachment (SATA), Integrated Drive Electronics (IDE), IEEE-1394, Universal Serial Bus (USB), Fibre Channel, Small Computer Systems Interface (SCSI), etc. The memory drive may further include drums, magnetic disk drives, magneto-optical drives, optical disk drives, Redundant Array of Independent Discs (RAID), solid-state memory devices, solid-state drives, etc.

[0066] Memory 405 may store a set of program or database components, including a user / application interface 406, an operating system 407, a web browser 408, and the like. In some embodiments, the computer system 400 may store user / application data 406, such as data, variables, and records described in the present invention. Such a database may be implemented as a fault-tolerant, relational, scalable, and secure database, such as Oracle® or Sybase®.

[0067] Operating System 407 may facilitate resource management and operation of computer system 400. Examples of operating systems include, but are not limited to, APPLE® MACINTOSH® OS X®, UNIX®, UNIX-based system distributions (e.g., BERKELEY SOFTWARE DISTRIBUTION® (BSD), FREEBSD®, NETBSD®, OPENBSD, etc.), LINUX® distributions (e.g., RED HAT®, UBUNTU®, KUBUNTU®, etc.), IBM® OS / 2®, MICROSOFT® WINDOWS® (XP®, VISTA® / 7 / 8, 10, etc.), APPLE® IOS®, and GOOGLE®. TM This includes ANDROID®, BLACKBERRY® OS, etc.

[0068] The user interface 406 may facilitate the display, execution, interaction, operation, or management of program components through text or graphical functions. For example, the user interface 406 may provide computer interaction interface elements such as cursors, icons, checkboxes, menus, scroll bars, windows, and widgets on a display system operably connected to the computer system 400. Furthermore, a graphical user interface (GUI) may be employed, which includes, but is not limited to, Aqua® from the APPLE® MACINTOSH® operating system, IBM® OS / 2®, MICROSOFT® WINDOWS® (e.g., Aero, Metro), and web interface libraries (e.g., ActiveX®, JAVA®, JAVASCRIPT®, AJAX, HTML, ADOBE® FLASH®).

[0069] Web browser 408 may be a hypertext browsing application. Secure web browsing may be provided using Secure Hypertext Transport Protocol (HTTPS), Secure Sockets Layer (SSL), Transport Layer Security (TLS), etc. Web browser 408 may utilize functions such as AJAX, DHTML, ADOBE® FLASH®, JAVASCRIPT®, JAVA®, and Application Programming Interfaces (APIs). Furthermore, computer system 400 may implement program components of a mail sending and receiving system. The mail sending and receiving system may utilize functions such as ASP, ACTIVEX®, ANSI® C++ / C#, MICROSOFT®, .NET, CGI scripting, JAVA®, JAVASCRIPT®, PERL®, PHP, PYTHON®, and WEBOBJECTS®. The email sending and receiving system may utilize communication protocols such as Internet Message Access Protocol (IMAP), Messaging Application Programming Interface (MAPI), Microsoft Exchange, Post Office Protocol (POP), and Simple Mail Transfer Protocol (SMTP). In some embodiments, the computer system 400 may implement program components for an email client. The email client may be an email viewing application such as Apple Mail, Microsoft Entourage, Microsoft Outlook, or Mozilla Thunderbird.

[0070] Furthermore, one or more computer-readable storage media may be used to implement embodiments consistent with the present invention. Computer-readable storage media refers to any type of physical memory capable of storing information or data that can be read by a processor. Thus, computer-readable storage media may store instructions to be executed by one or more processors, which may cause the processors to perform steps or stages consistent with the embodiments described herein. The term “computer-readable media” should be understood to include tangible items and exclude carrier waves and transient signals, i.e., non-transient items. Examples include random access memory (RAM), read-only memory (ROM), volatile memory, non-volatile memory, hard drives, compact disc (CD)ROMs, digital video discs (DVDs), flash drives, disks, and other known physical storage media.

[0071] In light of the technological advances provided by the method of disclosure, the steps of the claims described above are not common, conventional, or well-known in the industry, but provide solutions to technical problems that exist in the prior art. Furthermore, the steps of the claims result in a clear improvement in the functionality of the system itself by providing a technical solution to the technical problems.

[0072] The terms “an embodiment,” “embodiment,” “embodiments,” “the embodiment,” “the embodiments,” “one or more embodiments,” “some embodiments,” and “one embodiment” mean “one or more embodiments (but not all) of the present invention” unless explicitly defined otherwise.

[0073] "Including," "comprising," "having," and their variations all mean "including, but not limited to," unless explicitly defined otherwise.

[0074] The list of enumerated items does not imply that any or all of the items are mutually exclusive unless explicitly defined otherwise. Furthermore, the terms "a," "an," and "the" mean "one or more" unless explicitly defined otherwise.

[0075] The description of embodiments in which multiple components communicate with each other does not mean that all components are essential. Rather, various optional components are described to illustrate the diverse possible embodiments of the present invention.

[0076] Where a single device or article is described herein, it is clear that multiple devices or articles (whether in conjunction or not) may be used instead of the single device or article. Similarly, where multiple devices or articles are described herein (whether in conjunction or not), it is clear that a single device or article may be used instead of the multiple devices or articles, or that a different number of devices or programs than those illustrated may be used. The functions and / or features of a device may be embodied by one or more other devices not explicitly stated to have such functions / features. Therefore, other embodiments of the present invention do not necessarily have to include the device itself.

[0077] Finally, the language used herein has been selected primarily for readability and explanatory purposes, and not to limit or define the subject matter of the invention. Therefore, the scope of the invention is intended to be limited not by this detailed description, but by the claims filed thereon. Accordingly, the embodiments of the invention are illustrative, not limiting, the scope of the invention, which is defined by the following claims.

[0078] While various aspects and embodiments are disclosed herein, other aspects and embodiments will be obvious to those skilled in the art. Each aspect and embodiment disclosed herein is for illustrative purposes only and is not intended to limit, and its true scope and spirit are shown by the following claims. [Explanation of symbols]

[0079] 101-109…Basic Block, 113-119…Branch, 120…Software Binary File, 121…Test System, 123…Processing System, 125…Father, 127…Lookup Database, 129…Visualizer, 131…First List, 133…First List Binary Search Tree, 135…Third List, 137…Second List, 139…Second List Binary Search Tree, 141…Fourth List, 301…I / O Interface, 303…Processor, 305… Memory, 307…Data, 309…Modules, 311…Location Data, 313…Frontier Branch Data, 315…Other Data, 317…Transceiver Module, 319…Decision Module, 400…Computer System, 401…I / O Interface, 402…Processor, 403…Network Interface, 404…Storage Interface, 405…Memory, 407…Operating System, 408…Web Browser

Claims

1. A method for determining one or more frontier branches during software testing, The processing system (123) takes a branch of the software code under test from the father (125) associated with the processing system (123), For each of the two endpoints characterized as the first endpoint and the second endpoint, key information is provided that includes the address of the endpoint, a first list position indicating the location of file information related to the endpoint in the first list (131) of the lookup database (127), and a second list position indicating the location of basic block information related to the endpoint in the second list (137) of the lookup database (127), Receiving the aforementioned branch, The processing system (123) determines the status of each of the two endpoints, whether processed or not, based on the corresponding key information. Based on the determination of the state of each of the two endpoints, For endpoints whose status is determined to be unprocessed, the processing system (123) determines the first list position and the second list position of the endpoint from the lookup database (127), and uses the determined first list position and the second list position to obtain the basic block information related to the endpoint. For the endpoint whose status has been determined to be processed, the processing system (123) obtains the basic block information of the endpoint using the updated location information of the first list position of the endpoint in the key information and the updated location information of the basic block information of the second list position, and the processing system (123) determines the status of at least one of the one or more child blocks of the second endpoint based on the basic block information of the second endpoint, and determines the status of at least one of the one or more sibling blocks of the second endpoint based on the basic block information of the first endpoint, The processing system (123) determines one or more frontier branches based on the determined state of one or more child blocks and one or more sibling blocks, A method that includes this.

2. In the method according to claim 1, A method for determining that an endpoint has been processed when the first list position of the key information is updated with the location information of the endpoint in the first list (131), and the second list position of the key information is updated with the location information of the basic block information of the endpoint in the second list (137).

3. In the method according to claim 1, A method for determining that the endpoint is unprocessed if the first list position and the second list position include unset values.

4. In the method according to claim 1, A method in which the basic block information includes at least one of a coverage gain value indicating the total number of subsequent blocks associated with the endpoint, a flag value indicating whether the endpoint has been executed before, and one or more child pointers indicating the first list position and the second list position of one or more child blocks of the second endpoint.

5. In the method according to claim 1, A method wherein the lookup database (127) includes at least one of the first list (131), the second list (137), the third list (135), the fourth list (141), the binary search tree of the first list (133), and the binary search tree of the second list (139).

6. In the method according to claim 1, Determining the first list position and the second list position of the endpoint is: The processing system (123) determines the address range to which the endpoint's address belongs from among a plurality of address ranges stored in the first list binary search tree (133) of the lookup database (127), each of which is associated with a plurality of positions in the first list (131). The processing system (123) determines the first list position of the endpoint from among a plurality of positions in the first list (131) corresponding to the address range determined by the processing system (123), The processing system (123) performs a predetermined calculation using the address of the endpoint and the first list position to obtain the offset of the endpoint, The processing system (123) determines, from the second list binary search tree (139) of the lookup database (127) which stores a plurality of offset ranges, the offset range to which the offset of the endpoint belongs, each of which is associated with a plurality of positions in the second list (137), The processing system (123) determines the second list position of the endpoint among a plurality of positions in the second list (137) corresponding to the offset range determined, The processing system (123) obtains the basic block information related to the endpoint using the second list position, A method that includes this.

7. In the method according to claim 1, Determining the first list position and the second list position is: A method further comprising updating the first list position in the key information with the position information of the endpoint in the first list (131), and updating the second list position with the position information of the basic block information of the endpoint in the second list (137).

8. In the method according to claim 1, Furthermore, the method includes the processing system (123) instructing a display device associated with the processing system (123) to display one or more frontier branches.

9. A processing system (123) for determining one or more frontier branches during software testing, Processor (301), A memory (303) is connected to the processor (301) in a communicative manner, Equipped with, The memory (303) stores instructions that the processor (301) can execute, and when such instructions are executed, The processor (301) is The processing system (123) receives from a father (125) associated with the processing system (123) a branch of the software code under test, which is associated with two endpoints characterized as a first endpoint and a second endpoint, and includes key information including the addresses of the endpoints, a first list position indicating the location of file information in the first list (131) of the lookup database (127), and a second list position indicating the location of basic block information in the second list (137) of the lookup database (127), Based on the aforementioned key information, the status of each of the two endpoints is determined to be either "processed" or "unprocessed". Based on the determination of the state of the two endpoints, Regarding the endpoint whose status is determined to be unprocessed, The processing system (123) determines the first list position and the second list position of the endpoint from the lookup database (127), Using the determined first list position and second list position, the basic block information related to the endpoint is obtained. For the endpoint whose status has been determined to be processed, Using the updated position information of the first list position and the updated position information of the second list position in the key information, the basic block information of the endpoint is obtained. Based on the basic block information of the endpoint, the state of one or more child blocks of the endpoint is determined, and further, based on the basic block information of the first endpoint, the state of one or more sibling blocks of the endpoint is determined. Based on the state of at least one of the child blocks and the sibling blocks, determine one or more frontier branches. Processing system (123).

10. In the processing system (123) according to claim 9, The processor (303) determines that the endpoint has been processed when the first list position of the key information is updated with the endpoint's location information in the first list (131), and the second list position of the key information is updated with the endpoint's basic block information in the second list (137). Processing system (123).

11. The processing system (123) according to claim 9, The processor (303) determines that the endpoint is unprocessed if the first list position and the second list position include unset values. Processing system (123).

12. The processing system (123) according to claim 9, The basic block information includes a coverage gain value indicating the total number of subsequent blocks associated with the endpoint, a flag value indicating whether the endpoint has been executed previously, and at least one of the following child pointers indicating the first list position and the second list position of one or more child blocks of the second endpoint. Processing system (123).

13. In the processing system (123) according to claim 9, The search database (127) includes at least one of the first list (131), the second list (137), the third list (135), the fourth list (141), the first list binary search tree (133), and the second list binary search tree (139). Processing system (123).

14. In the processing system (123) according to claim 9, The processor (303) determines the first list position and the second list position of the endpoint, From among the multiple address ranges stored in the first list binary search tree (133) of the lookup database (127), which are associated with multiple positions in the first list (131), the address range to which the endpoint's address belongs is determined. From among the multiple locations in the first list (131) corresponding to the determined address range, the first list location of the endpoint is determined. A predetermined operation is performed using the endpoint address and the first list position to obtain the endpoint offset. From the multiple offset ranges stored in the second list binary search tree (139) of the lookup database (127), a plurality of offset ranges to which the offset belongs and which are associated with a plurality of positions in the second list (137) are determined. From among the multiple positions in the second list corresponding to the determined offset range, the second list position of the endpoint is determined. Using the second list position, obtain the basic block information related to the endpoint. Processing system (123).

15. In the processing system (123) according to claim 9, The processor (303) determines the first list position and the second list position by updating the key information such as updating the first list position with the position information of the endpoint in the first list (131) and updating the second list position with the position information of the basic block information of the endpoint in the second list (137). Processing system (123).

16. In the processing system (123) according to claim 9, The processor (303) further instructs the display device associated with the processing system (123) to display one or more frontier branches. Processing system (123).

Images