Unit/Module Test Cases Template
White box testing is based on knowledge of the internal logic of an application's code. Tests are based on coverage of code statements, branches, paths and conditions.
Unit/Module tests should satisfy the design of the applications and be traceable to the design documents. We refer to unit and module test as simply unit test hereafter.
A unit (module) can be as small as a non-trivial method in a class. It can be a whole class or a whole package too.
Usually, the strategy for unit testing is structural or white-box testing based on a certain coverage criteria such as statement coverage, path coverage or decision coverage. In our case, we will use the path-coverage criteria as it is the strongest.
A set of white-box test cases should be developed to test the unit by exercising all general as well as special cases of the different constructs of the unit. For instance, boundary values analysis is an example of testing the special cases of a construct.
Number:
A unique number of the as set of unit test cases that test specific structure
Title
A title for the set of tests; normally is the same title of the unit under test.
Package Name:
This is the name of the package(s) that contain the unit under test. In modular design, a package would represent a unit that offer functionalities in its own.
Class Name:
This is name of the Class under test. If the test is concerned with a package unit, this field would be N/A
Method Name:
This is the Method under test, if the test is concerned with either a package or a class unit, this filed would be N/A
Description:
Just a brief reminder about the purpose of this unit under test.
Inputs:
Provide a brief description of the inputs to the unit under test
Outputs:
Provide a brief description of the outputs to the unit under test
Interfaces:
Identify the units that interface with this unit indicating the nature of the interface: outputs data to, receives input data from, external methods interface, etc.
UML Activity Diagram:
Provide the logic flow diagram. This is important when the testing objective is, for example, path coverage; as it is in our case. The logic flow graph is going to show the different paths to be tested. Each path would require a test case. Input values that are expected to cover the same path, are said to be of the same “equivalence class”.
Stubs:
Common Values for all test cases, which should be available from other units which are not ready yet; and are necessary for the test to execute. Note that if all other units are functioning already, there would be no need for stubs. Each test case may require some specific initial state values; these should be included in the corresponding test case, as described below.
Initial State
Common Data for all test cases, which should exist in the Database (or whatever persistent form), and are necessary for the test to execute. The initial state also includes settings of the static objects attributes. Each test case may require some specific initial state values; these should be included in the corresponding test case, as described below.
Testing Tools:
Identify any tools employed to conduct unit testing. Specify any stubs or utility programs developed or used to invoke tests. Identify names and locations of these aids for future regression testing.
Positive Test Cases:
Each use case should cover a specific equivalence class. Each test case may have some requirements with regard to the stubs and initial state. Each test case should have the components shown below:
Test Case Number:
A serial number within the set.
Equivalence Class
The objective of this test, e.g., the specific path it covers.
Stubs:
Specific Stubs requirements
Initial State
Specific Initial State
Scenario:
User Input and System Response in a tabular form.
Negative Test Cases:
Invalid data selection contains the entire negative test conditions associated with the unit. These include numeric values outside thresholds, invalid Characters, invalid or missing header/trailer record, and invalid data structures (missing required elements, unknown elements, etc. Negative test case has the same components as the Positives Test Cases, except that the negative ones may not have stubs nor initial state requirements.
Example of logic flow graphs (also called control flow graphs) that show different paths…
Number:
A unique number of the as set of unit test cases that test specific structure
Title
A title for the set of tests; normally is the same title of the unit under test.
Package Name:
This is the name of the package(s) that contain the unit under test. In modular design, a package would represent a unit that offer functionalities in its own.
Class Name:
This is name of the Class under test. If the test is concerned with a package unit, this field would be N/A
Method Name:
This is the Method under test, if the test is concerned with either a package or a class unit, this filed would be N/A
Description:
Just a brief reminder about the purpose of this unit under test.
Inputs:
Provide a brief description of the inputs to the unit under test
Outputs:
Provide a brief description of the outputs to the unit under test
Interfaces:
Identify the units that interface with this unit indicating the nature of the interface: outputs data to, receives input data from, external methods interface, etc.
UML Activity Diagram:
Provide the logic flow diagram. This is important when the testing objective is, for example, path coverage; as it is in our case. The logic flow graph is going to show the different paths to be tested. Each path would require a test case. Input values that are expected to cover the same path, are said to be of the same “equivalence class”.
Stubs:
Common Values for all test cases, which should be available from other units which are not ready yet; and are necessary for the test to execute. Note that if all other units are functioning already, there would be no need for stubs. Each test case may require some specific initial state values; these should be included in the corresponding test case, as described below.
Common Data for all test cases, which should exist in the Database (or whatever persistent form), and are necessary for the test to execute. The initial state also includes settings of the static objects attributes. Each test case may require some specific initial state values; these should be included in the corresponding test case, as described below.
Testing Tools:
Identify any tools employed to conduct unit testing. Specify any stubs or utility programs developed or used to invoke tests. Identify names and locations of these aids for future regression testing.
Positive Test Cases:
Each use case should cover a specific equivalence class. Each test case may have some requirements with regard to the stubs and initial state. Each test case should have the components shown below:
Test Case Number:
A serial number within the set.
Equivalence Class
The objective of this test, e.g., the specific path it covers.
Stubs:
Specific Stubs requirements
Scenario:
User Input and System Response in a tabular form.
Negative Test Cases:
Invalid data selection contains the entire negative test conditions associated with the unit. These include numeric values outside thresholds, invalid Characters, invalid or missing header/trailer record, and invalid data structures (missing required elements, unknown elements, etc. Negative test case has the same components as the Positives Test Cases, except that the negative ones may not have stubs nor initial state requirements.
No comments:
Post a Comment