Mapping the Software Testing Deliverable to the RTM Test Metrics

J.E.D.I

6.7 Mapping the Software Testing Deliverable to the RTM

Once a component is implemented, the test specification and test cases must be developed. We need to keep track of it, and at the same time, assure that each test is traced to a requirement. Additional RTM components are added. The following list the recommended elements for software testing in the RTM. RTM Software Testing Components Description Test Specification The filename of the document that contains the plan on how to test the software component. Test Cases The filename that contains the test cases to be performed as part of the test specification. Table 32: Software Testing RTM Elements These components should be related to a software component defined in the RTM. Software Engineering 300 J.E.D.I

6.8 Test Metrics

The metrics used for object-oriented design quality mentioned in Design Engineering can also provide an indication of the amount of testing effort is need to test object-oriented software. Additionally, other metrics can be considered for encapsulation and inheritance. Example of such metrics are listed below. 1. Lack of Cohesion in Methods LCOM. If the value of LCOM is high, the more states of the class needs to be tested. 2. Percent Public and Protected PAP. This is a measure of the percentage of class attributes that are public or protected. If the value of PAP is high, it increases the likelihood of side effects among classes because it leads to high coupling. 3. Public Access To Data Members PAD. This is a measure of the number of classes or methods that an access another class’s attributes. If the value of PAD is high, it could lead to many side effects. 4. Number of Root Classes NOR. As the number of root classes increases, testing effort also increases. 5. Number of Children NOC and Depth of the Inheritance Tree DIT. Superclass methods should be re-tested for every subclass. Software Engineering 301 J.E.D.I

6.9 Exercises