Page272
Traceability Matrix
A Traceability Matrix (sometimes called a Requirements Traceability Matrix, or RTM) can be used to map customers’ requirements to the software testing plan: it “traces” the “requirements,” and ensures that they are being met. It does this by mapping customer use cases to test cases. Table 7.2 shows a sample Requirements Traceability Matrix.
Table 7.2 Sample Requirements Traceability Matrix [9].
| Requirement ID | Requirements Tested | Use Case 1.1 | Use Case 1.2 | Use Case 1.3 | ... |
|---|---|---|---|---|---|
| Test cases | 34 | 2 | 4 | 7 | |
| TC1.1.1 | 2 | X | X | ||
| TC1.1.2 | 1 | ||||
| TC1.2.1 | 3 | X | X | ||
| TC1.2.2 | 1 | X | |||
| TC1.2.3 | 2 | X | |||
| ... |
Misuse Case Testing
Synthetic transactions are designed to simulate normal behavior; misuse case testing is designed to simulate abnormal user behavior. Use cases for applications spell out how various functionality is going to be leveraged within an application. Formal use cases are typically built as a flow diagram, written in UML (Unified Modeling Language), and are created to help model expected behavior and functionality.
The idea of misuse case testing is to formally model, again most likely using UML, how security impact could be realized by an adversary abusing the application. This can be seen simply as a different type of use case, but the reason for calling out misuse case testing specifically is to highlight the general lack of considering attacks against the application.
Test Coverage Analysis
Test or code coverage analysis seeks to determine the percentage of an application that has been tested. The goal is to ensure there are no significant gaps where a lack of testing could allow for bugs or security issues to be present that otherwise should have been discovered.
Interface Testing
Traditional interface testing within applications is primarily concerned with appropriate functionality being exposed across all the ways users can interact with the application. From a security-oriented vantage point, the goal is to ensure that security is uniformly applied across the various interfaces. Effectively, this type of testing considers varied potential attack vectors an adversary could leverage.
A simplified example of this might be a web application that uses Adobe Flash when a client presents with that capability but will present an alternative view to clients that lack support for Adobe Flash. If testing was only performed with a desktop browser that had built-in Flash support, then security flaws that are present in the mobile version of the application presented to iPhones might well be missed. While interface testing encompasses more than just desktop vs. mobile browser, the concept still applies. An application’s security requirements must be implemented regardless of how a person or machine is interfacing with the code.