The structure of the software itself is a valuable source of information for selecting test cases and determining whether a set of test cases has been sufficiently thorough. Learning objectives of this chapter: Understand rationale for structural testing, recognize and distinguish basic terms, recognize and distinguish characteristics of common structural criteria, understand practical uses and limitations of structural testing. | Structural Testing (c) 2007 Mauro Pezzè & Michal Young Ch 12, slide 1 Learning objectives • Understand rationale for structural testing – How structural (code-based or glass-box) testing complements functional (black-box) testing • Recognize and distinguish basic terms – Adequacy, coverage • Recognize and distinguish characteristics of common structural criteria • Understand practical uses and limitations of structural testing (c) 2007 Mauro Pezzè & Michal Young Ch 12, slide 2 “Structural” testing • Judging test suite thoroughness based on the structure of the program itself – Also known as “white-box”, “glass-box”, or “codebased” testing – To distinguish from functional (requirements-based, “black-box” testing) – “Structural” testing is still testing product functionality against its specification. Only the measure of thoroughness has changed. (c) 2007 Mauro Pezzè & Michal Young Ch 12, slide 3 Why structural (code-based) testing? • One way of answering the question “What is missing in our test suite?” – If part of a program is not executed by any test case in the suite, faults in that part cannot be exposed – But what’s a “part”? • Typically, a control flow element or combination: • Statements (or CFG nodes), Branches (or CFG edges) • Fragments and combinations: Conditions, paths • Complements functional testing: Another way to recognize cases that are treated differently – Recall fundamental rationale: Prefer test cases that are treated differently over cases treated the same (c) 2007 Mauro Pezzè & Michal Young Ch 12, slide 4 No guarantees • Executing all control flow elements does not guarantee finding all faults – Execution of a faulty statement may not always result in a failure • The state may not be corrupted when the statement is executed with some data values • Corrupt state may not propagate through execution to eventually lead to failure • What is the value of structural coverage? – Increases confidence in thoroughness of testing • .
