TAILIEUCHUNG - Lecture Software testing and analysis: Chapter 12 - Mauro Pezzè, Michal Young

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 • .

• Sáng kiến kinh nghiệm
• Software testing
• Software analysis
• Software testing and analysis
• Software product
• Software processes
• Structural testing
• Software process
• Testing object oriented software
• Component based software testing
• Lecture Software testing and quality assurance
• Lecture Software testing
• Quality assurance
• Web Base application testing
• Performance testing
• Coverage testing
• Functional testing
• Combinatorial testing
• Data flow testing
• Model based testing
• Fault based testing
• System testing
• A testing workbench
• Kiểm thử beta
• Software qualities
• Software reliability engineering testing
• Assessing program qualities
• Phân hoạch tương đương
• Software Engineering
• Defect testing
• Testing process goals
• Assertion based Testing
• Model of program testing
• Quality process
• A Software Testing Primer
• Software Testing Primer
• Concepts of testing
• Non functional testing
• Test planning