Browse Prior Art Database

Method for Detecting Covered Code through Program State Information

IP.com Disclosure Number: IPCOM000241192D
Publication Date: 2015-Apr-02
Document File: 5 page(s) / 118K

Publishing Venue

The IP.com Prior Art Database

Abstract

Disclosed is a method to monitor the machine instruction stores that are part of a given line of code or routine; if the line stores the same value to an address as already exists at that address, then the line is not marked as covered on that encounter. For a line to be marked as covered, some store must result in a changed value.

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

Page 01 of 5

Method for Detecting Covered Code through Program State Information

Coverage tools can be run to determine the lines of code that a particular test program causes to execute. Many classifications of coverage information exist. Line or statement coverage tells the user if a line or statement was executed during one or more runs. Condition coverage tells the user if a condition encountered was, true, false, or both during a series of runs. Multi-conditional coverage tracks each of the conditions in a conditional expression. For example in "if ( a

2 )", then two conditions are present. For this line to be completely covered from a multi-conditional perspective, "a

2".

Coverage tools can also use a count to try to ensure that the user has adequately exercised the program. For example, if a statement has not been encountered at least so many times, then it is not considered covered. While this might help to ensure the program is better exercised, it is really an arbitrary way to accomplish this goal with no guarantee that the additional coverage did any good at all.

Coverage tools do not attempt to assess whether the execution actually affected the program state. For example, consider the simple case:

if ( target_pass == pass ) variable = false;

Existing coverage tools verify that the statement was executed and was true, false, or both. The tools can also verify that "variable = false;" was executed. The current tools do NOT verify that "variable = false;" was executed in a way that mattered. For instance, if "variable" was already false when the statement was executed, perhaps the "if" was not executed in the context for which it was added because executing it did not

change the program state. If this is the case, then the test cases used did not really cause this statement to be covered.

The novel contribution is a method to monitor the machine instruction stores that are part of a given line of code or routine; if the line stores the same value to an address as already exists at that address, then the line is not marked as covered on that encounter. For a line to be marked as covered, some store must result in a changed value.

For a routine to be marked as covered, it must in some way change the program state. This can be done by modifying non-local storage or calling a system routine that changes the external state of the system in some way.

The method marks lines or routines that change program state as covered. The method marks lines that are executed but do not change the program state as executed.

Basic Embodiment

This method provides additional features to a coverage tool that uses object code

1


Page 02 of 5

insertion to track whether a line really changed program state. To do this, the stores are also instrumented to determine if the state of the program is changed by this execution. This instrumentation obtains control before the store is performed, retrieves the data at this address, and then compares it to the data to be...