Statement Testing and Coverage

Profile picture for user devraj
Submitted by devraj on

Statement testing is a type of white-box testing that involves executing potential executable statements within source code. This technique aims to ensure that all lines of code are covered by the tests at least once. Statement coverage is sometimes referred to as line coverage or segment coverage.

Table of Contents

  1. Statement Test Coverage Measurement
  2. Statement Coverage Testing Example
  3. The Value of Statement Testing
  4. Benefits of Statement Coverage
  5. Limitations of Statement Coverage
  6. Video Tutorial

Statement Test Coverage Measurement

Coverage is measured as the number of statements executed by the tests divided by the total number of executable statements in the test object, generally expressed as a percentage.

Statement Coverage Testing Example

Let us consider an example of a function that determines the greater of two numbers. Two test cases are executed to assess the statement coverage of this function.

Read X
Read Y
if X > Y
    Print "X is greater than Y"
    Print "Y is greater than X"

Total no of statements in the source code: 7

Test Case 1: If X = 20, Y = 10

  • No of statements Executed: 5
  • Statement coverage =5 / 7 * 100 = 71.00 %

Test Case 2: If X = 10, Y = 20

  • No of statements Executed: 6
  • Statement coverage =6 / 7 * 100 = 85.20 %

Since all the statements are covered in both test cases, we can conclude that overall coverage is 100%. 

The Value of Statement Testing

Achieving 100% statement coverage is an essential goal in software testing, ensuring that all executable statements in the code have been exercised at least once. However, achieving 100% statement coverage does not guarantee that all decision logic has been tested.

Decision testing, which involves testing all possible outcomes of a decision point, may provide higher coverage than statement testing alone. Nonetheless, statement coverage is still valuable, as it can reveal code defects that other tests may have missed.

It is important to note that achieving 100% decision coverage guarantees 100% statement coverage, but the opposite is not necessarily true. Decision coverage requires testing all possible outcomes of decision points in the code, ensuring that all statements have been executed. Therefore, achieving 100% decision coverage implies 100% statement coverage, while achieving 100% statement coverage alone does not guarantee 100% decision coverage.

Benefits of Statement Coverage

Statement coverage provides several benefits in software testing.

  • Improve Code Quality: One of its primary advantages is its ability to improve the quality of the tested code. By covering unused statements, dead code, unused branches, and missing statements, statement coverage helps to identify potential defects and weaknesses in the code. This information can be used to improve the code and reduce the risk of errors or failures.
  • Identify Functional Gaps: In addition to improving code quality, statement coverage can help identify functional gaps in the tested program. By checking the flow of different paths in the code and ensuring that those paths are tested, statement coverage can verify that the code behaves as expected and meets the functional requirements specified by the client. By characterizing the functional parts of the statements and comparing them to the client's requirements documentation, developers and testers can identify areas where the code may not meet the client's needs and make improvements as necessary.

Limitations of Statement Coverage

Statement coverage has several limitations that can affect its effectiveness in identifying defects in software code.

  • Can not test false condition: One limitation of statement coverage is that it cannot test false conditions. This means that even if all executable statements in the code are covered, false condition scenarios may still be untested.
  • Limited Coverage: Another limitation is that statement coverage may provide less coverage than other testing techniques when identifying bugs related to control flow constructs in the code, such as compound conditions or consecutive switch labels. Achieving 100% statement coverage does not guarantee 100% decision coverage, which involves testing all possible outcomes of decision points in the code. Therefore, it is important to complement statement coverage with other testing techniques to achieve comprehensive testing and ensure high-quality software.