When performing structural testing of the software code, the term paths refer to control flow sequences through the internal structure of the software. There are typically many possible paths between the entry and exit of a typical software application. Since there are rarely enough resources to test every path through a complex software application or even a complex individual unit of code, a tester can uses white-box code coverage techniques to systematically select the tests that are the most likely to help identify the yet undiscovered, relevant defect. This paper explains these white-box coverage techniques.
Software Verification & Validation
While the benefits of formal inspections are well documented, in reality, many projects don’t have the resources to formally peer review every work product at that level of rigor. By analyzing the probability that a work product contains defects that will escape from development into the user environment and the potential impact of those defects, developers can make strategic, risk-based trade-offs between efficiency and effectiveness in their peer review processes. These decisions include the type(s) of peer review, the level of formality, the number of participants and peer review sufficiency needed for each work product.
This paper was presented by Linda Westfall at the 4th World Congress for Software Quality in Bethesda, Maryland.
Basis path testing is a structural testing technique that identifies test cases based on the flows or logical paths that can be taken through the software. A basis path is a unique path through the software where no iterations are allowed; they’re atomic level paths, and all possible paths through the system are linear combinations of them. Basis path testing uses a Cyclomatic metric that measures the complexity of a source code unit by examining the control flow structure. Basis path testing can also be applied to integration testing when software units/components are integrated together. You’ll see how the use of the technique quantifies the integration effort involved as well as the design-level complexity.
Peer Reviews in Software, Karl Wieger, Addison-Wesley, Boston, 2002.
Software Inspections, Tom Gilb, Addison-Wesley, Wokingham, England, 1993.
Download Linda's Software Testing Bibliography below.