lecture-09-coverage-3

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

Info iconThis preview shows pages 1–4. 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 1 Spring 2010 CSci 5802 Structural Coverage Criteria Chapters 12 and 13 procedure Search (Key : ELEM ; T: ELEM_ARRAY; Found : in out BOOLEAN; L: in out ELEM_INDEX) ; Pre-condition -- the array has at least one element T FIRST <= T LAST Search Routine Specification T.FIRST <= T.LAST Post-condition -- the element is found and is referenced by L ( 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 )) ht Aims for Today Understand rationale for structural testing Recognize and distinguish characteristics of common structural criteria Understand practical uses and limitations of structural testing tp://www.umsec.umn.edu Spring 2010 CSci 5802 3 Understand why data flow criteria have been designed and used Recognize and distinguish basic DF criteria All DU pairs, all DU paths, all definitions Understand how and why DF criteria are often not usable
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 ht Structural Testing Sometime called white-box testing Derivation of test cases according to program structure Knowledge of the program is used to identify tp://www.umsec.umn.edu Spring 2010 CSci 5802 4 Knowledge of the program is used to identify test cases Objective is to exercise a certain percentage of statements, branches, or condition (not all path combinations) Why?? Structural testing in practice • Create functional test suite first, then measure structural coverage to identify see what is missing • 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 CSci 5802 Ch 12, slide 5 • inadequacy of specifications that do not include cases present in the implementation • coding practice that radically diverges from the specification • inadequate functional test suites • 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 CSci 5802 Ch 12, slide 6 # statements • Rationale: a fault in a statement can only be revealed by executing the faulty statement
Background image of page 2
Lecture 9 - Coverage Spring 2010 CSci 5802
Background image of page 3

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

View Full DocumentRight Arrow Icon
Image of page 4
This is the end of the preview. Sign up to access the rest of the document.

This note was uploaded on 10/21/2011 for the course CSCI 5802 taught by Professor Heimdahl,m during the Spring '08 term at Minnesota.

Page1 / 9

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

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

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