Unit testing activities can be scheduled into five events for schedule milestones:
- Unit test planning
- Test development
- Peer review of test plans, test scripts, test drivers
- Execution of unit test cases
- Reporting unit test results
Test Coverage.
Three elements of test coverage are introduced as general guidelines to
help ensure the job is possible: statement coverage, decision or branch
coverage, and condition or logic coverage. Tools come packaged under a
variety of names, including:
- Path/coverage analyzers
- Static and dynamic metrics collections
- Automated test tools
- Robot
COTS tools can do a comprehensive job of identifying paths and assisting the software engineer during unit test.
TEST COVERAGE EXAMPLES
Input Values for Test Coverage Example. This table provides the values for each of the variables to generate the paths identified in the Figure Condition or Logic Coverage. The decision example provided two different sets of paths that would supply coverage.
Statement Coverage.
Statement coverage ensures that each statement is executed once. It does not require any detailed analysis of the condition points or exercising each decision.
Answer:
Paths: acdd, abed, and abdd
The decision points were not considered:
- Logic errors in control structures
- Dead code
- Errors at loop boundaries
- Errors in loop initializations
The individual boundary conditions.
- Test tolerances such as parameter minimums, maximums, and "just beyond" minimums and maximums
- Choose input parameters that test both input and output tolerance
Branches occur at a decision point like an "if" statement and a "case" statement in C and C++. Branch or decision coverage is to test each branch at least once. Branches are chosen and executed without detailed analysis of the condition causing the branch.
Answer:
Sets of paths
The individual boundary conditions.
- Test tolerances such as parameter minimums, maximums, and "just beyond" minimums and maximums
- Choose input parameters that test both input and output tolerance
Condition or Logic Coverage. Condition coverage ensures that every possible condition is executed at least once. The flow diagram is split out because it is easier to approach the flow at "individual" decision points. The paths for each set of decision points can then be logically grouped in the unit test cases.
For the if statement "A > 1 AND B = 0", the software engineer must first analyze the condition to determine the four possible "individual" decisions:
- A > 1 has the outcome of True
- A > 1 has the outcome of False
- B = 0 has the outcome of True
- B = 0 has the outcome of False
Condition coverage would require choosing data to cause the following:
|
Combinations |
|
|
A |
B |
|
T |
T |
|
T |
F |
|
F |
T |
|
F |
F |
Designing Unit Test Plans & Cases. This lesson section of Software Unit Test is on designing the unit test plans, unit test drivers, unit test cases, test case design guidelines, a sample test plan and a sample test case. Below is an example of a Unit Test Plan.
|
Unit Test Plan Unit ID: Version Control ID: Unit Function:
Requirements to be Validated:
Input Data:
Expected Output Data:
Test Procedures: 1. 2. 3. Analysis Procedures: 1. 2. 3.
|
Designing Unit Test Plans. There is a required set of inputs to begin test planning and provide guidance to the developers. The results of test planning is documented in a Unit Test Plan (on a per unit basis) and stored in the unit’s Software Development Folder. The unit development folder is a notebook maintained by each developer and kept at the developers’ desk. The unit test plan contains high-level objectives that will be mapped into the test cases; the types of data required for the test objectives; it identifies any drivers, tools, or special considerations. The unit test plan will be peer reviewed to ensure all unit test guidelines have been met and the test objectives address all aspects of the unit (requirements, error conditions, etc.). The Software Engineers develop the unit test plans during the design phase. Developing the unit test plan at the design phase allows the engineer to design in test hooks that relate what will be coded to the requirement specifications. These test hooks can then be applicable to unit test or later test, subsystem or integration. May be very important in certain environments: C++ (as a single example).
An actual example: A system that used 3-D position information in real-time was being tested. In able to ensure repeatability, the first time we executed a test case we used the actual hardware and used a "test hook" to go into record mode to save the 3-D data points. When the test case was re-executed, the "test hook" was set to a playback mode and invoked a simulator that used the previously recorded data.