lecture-09-coverage-2

lecture-09-coverage-2 - Lecture 9 - Coverage Spring 2010...

Info iconThis preview shows pages 1–5. Sign up to view the full content.

View Full Document Right Arrow Icon
Lecture 9 - Coverage Spring 2010 CSci 5802 1 CSci 5802 Software Engineering II Structural Coverage Criteria Chapters 12 and 13 1 Spring 2010 CSci 5802 procedure Search (Key : ELEM ; T: ELEM_ARRAY; Found : in out BOOLEAN; L: in out ELEM_INDEX) ; Search Routine Specification Pre-condition -- the array has at least one element T.FIRST <= T.LAST Post-condition -- the element is found and is referenced by L ( Found and T (L) = Key) ( Found and T (L) = Key) or -- the element is not in the array ( not Found and not ( exists i, T.FIRST >= i <= T.LAST, T (i) = Key ))
Background image of page 1

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full DocumentRight Arrow Icon
Lecture 9 - Coverage Spring 2010 CSci 5802 2 Aims for Today Understand rationale for structural testing Recognize and distinguish characteristics of http://www common structural criteria Understand practical uses and limitations of structural testing Understand why data flow criteria have been designed and used Recognize and distinguish basic DF criteria .umsec.umn.edu Spring 2010 CSci 5802 3 All DU pairs, all DU paths, all definitions Understand how and why DF criteria are often not usable Structural Testing Sometime called white-box testing Di t i f tt d i t Derivation of test cases according to program structure Knowledge of the program is used to identify test cases Objective is to exercise a certain percentage Spring 2010 CSci 5802 4 of statements, branches, or condition (not all path combinations) Why??
Background image of page 2
Lecture 9 - Coverage Spring 2010 CSci 5802 3 Structural testing in practice • Create functional test suite first, then measure structural coverage to identify see what is missing • Interpret unexecuted element • Interpret unexecuted elements – may be due to natural differences between specification and implementation – or may reveal flaws of the software or its development process • inadequacy of specifications that do not include cases present in the implementation • coding practice that radically diverges from the specification • inadequate functional test suites CSci 5802 Ch 12, slide 5 • Attractive because automated – coverage measurements are convenient progress indicators – sometimes used as a criterion of completion • use with caution: does not ensure effective test suites Statement testing • Adequacy criterion: each statement (or node in the CFG) must be executed at least once • Coverage: # executed statements # statements • Rationale: a fault in a statement can only be revealed by executing the faulty statemen CSci 5802 Ch 12, slide 6 revealed by executing the faulty statement
Background image of page 3

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full DocumentRight Arrow Icon
Lecture 9 - Coverage Spring 2010 CSci 5802 4 Statements or blocks?
Background image of page 4
Image of page 5
This is the end of the preview. Sign up to access the rest of the document.

Page1 / 13

lecture-09-coverage-2 - Lecture 9 - Coverage Spring 2010...

This preview shows document pages 1 - 5. Sign up to view the full document.

View Full Document Right Arrow Icon
Ask a homework question - tutors are online