Browse Prior Art Database

Code Path Test Coverage Maximizer Disclosure Number: IPCOM000174174D
Original Publication Date: 2008-Aug-30
Included in the Prior Art Database: 2008-Aug-30
Document File: 2 page(s) / 25K

Publishing Venue



This article describes a way to use a code path analyzer to force different paths to take place. The user can set up a table of external variables, and what internal variables these relate to. We then analyze the code paths. Using a path taken by an existing test case, we alter the test case using the external variables to cause the execution of a different test path. Once that new test case is run, the process is repeated, and the next condition that checks a an external variable is used to alter the external variables, and generate another new test case with new code path coverage.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 52% of the total text.

Page 1 of 2

Code Path Test Coverage Maximizer

Plaguing every software application is its vulnerability to errors. As programs grow larger and larger, it becomes more difficult to remove errors before code is shipped to clients. Design and code reviews help eliminate some number of bugs. The different types of testing help insure more defects are removed before general availability. However, due to the complexities of code and the vast numbers of code paths it is virtually impossible to test every code path using manual techniques. A better methodology is needed to ensure complete code path testing.

A need is present for a programmatic approach to developing test scenarios as to eliminate previously unreached code paths. We can do this by analyzing the source code itself and examining each path a request can take. Mapping these routes and noting which code paths are not taken with current test beds, we can adjust input parameters that may allow these code paths to be exploited. Once this has completed and code paths have still not ran, adjustment of environmental variables may be used to force certain code paths after analysis of the decision statements.

Initial analysis will involve review of each branch type statement in the machine code and create a bit map that will act as a checklist as to whether that particular branch was hit and if each choice was taken (often the decision to branch or not to branch). In other words, each branch will have two bits assigned to it. One for each possible outcome of the condition check. Initially all bits are on. As a conditional path is taken, the appropriate bit will be turned off. After execution of current test buckets, our map will give us a clear picture of which branches were not hit and choices that were not selected. Some variables in the code path can be set by external keywords, other variables are set due to type of data being processed, and finally other variables are set on events such as error conditions. As we scan through the code and identify code paths that are not being executed, a report of the key variables which need to be altered is provided to the user. The user then must determine which type of category these variables fit in.

In the case of variables that can be set via external keywords, the user will merely identify which keyword will provide the desired setting. The user identifies the external variable in a table with any internal variables that relate to that external variable. We then take an existi...