Software Testing Notes
Subject – Software Testing Structural Testing
Objective: 1. Understand Concept of structural testing 2. How structural (code-based or glass-box) testing complements functional (black-box) testing 3. Recognize and distinguish basic terms • • Adequacy Coverage
4. Recognize and distinguish characteristics of common structural criteria 5. Understand practical uses and limitations of structural testing Definition: Judging test suite thoroughness based on the structure of the program itself, it is also known as “white-box”, “glass-box”, or “code-based” 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. Structural testing, just like functional (spec-based) testing, still requires program specifications of some kind to judge whether a test execution was correct. Why do we require structural 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”? Eg: 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
Eg: Sample test suites Test Suite: Test Suite is a set of test cases it follows IEEE std. T0 T1 = = { “”,”test”,”test+case % 1DAdequcay”} { “adequate+test% 0DExecution”}
T2 T3 T4
= = =
{“%3D”,”%A”,”a+b”,”test”} {“ “ ,”+%0D+%4J”} {“first+test%9Ktest%K9}
Types of Structural (or Code Based)Testing Statement Testing Branch Testing Condition Testing Path Testing Cyclomatic complexity
Statement Testing Adequacy criterion: each statement (or node in the CFG) must
Objective: 1. Understand Concept of structural testing 2. How structural (code-based or glass-box) testing complements functional (black-box) testing 3. Recognize and distinguish basic terms • • Adequacy Coverage
4. Recognize and distinguish characteristics of common structural criteria 5. Understand practical uses and limitations of structural testing Definition: Judging test suite thoroughness based on the structure of the program itself, it is also known as “white-box”, “glass-box”, or “code-based” 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. Structural testing, just like functional (spec-based) testing, still requires program specifications of some kind to judge whether a test execution was correct. Why do we require structural 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”? Eg: 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
Eg: Sample test suites Test Suite: Test Suite is a set of test cases it follows IEEE std. T0 T1 = = { “”,”test”,”test+case % 1DAdequcay”} { “adequate+test% 0DExecution”}
T2 T3 T4
= = =
{“%3D”,”%A”,”a+b”,”test”} {“ “ ,”+%0D+%4J”} {“first+test%9Ktest%K9}
Types of Structural (or Code Based)Testing Statement Testing Branch Testing Condition Testing Path Testing Cyclomatic complexity
Statement Testing Adequacy criterion: each statement (or node in the CFG) must