57
Slide 6.1 © The McGraw-Hill Companies, 2007 Object-Oriented and Classical Software Engineering Seventh Edition, WCB/McGraw-Hill, 2007 Stephen R. Schach [email protected]

Slide 6.1 Object-Oriented and Classical Software Engineeringwebstaff.kmutt.ac.th/~auapong.yai/ENE463/Slides/se7_ch06_v07.pdf · Object-Oriented and Classical Software Engineering

  • Upload
    others

  • View
    30

  • Download
    1

Embed Size (px)

Citation preview

Page 1: Slide 6.1 Object-Oriented and Classical Software Engineeringwebstaff.kmutt.ac.th/~auapong.yai/ENE463/Slides/se7_ch06_v07.pdf · Object-Oriented and Classical Software Engineering

Slide 6.1

© The McGraw-Hill Companies, 2007

Object-Oriented andClassical Software

Engineering

Seventh Edition, WCB/McGraw-Hill, 2007

Stephen R. [email protected]

Page 2: Slide 6.1 Object-Oriented and Classical Software Engineeringwebstaff.kmutt.ac.th/~auapong.yai/ENE463/Slides/se7_ch06_v07.pdf · Object-Oriented and Classical Software Engineering

Slide 6.2

© The McGraw-Hill Companies, 2007

CHAPTER 6

TESTING

Page 3: Slide 6.1 Object-Oriented and Classical Software Engineeringwebstaff.kmutt.ac.th/~auapong.yai/ENE463/Slides/se7_ch06_v07.pdf · Object-Oriented and Classical Software Engineering

Slide 6.3

© The McGraw-Hill Companies, 2007

Overview

Quality issues Non-execution-based testing Execution-based testing What should be tested? Testing versus correctness proofs Who should perform execution-based testing? When testing stops

Page 4: Slide 6.1 Object-Oriented and Classical Software Engineeringwebstaff.kmutt.ac.th/~auapong.yai/ENE463/Slides/se7_ch06_v07.pdf · Object-Oriented and Classical Software Engineering

Slide 6.4

© The McGraw-Hill Companies, 2007

Testing

There are two basic types of testingExecution-based testingNon-execution-based testing

Page 5: Slide 6.1 Object-Oriented and Classical Software Engineeringwebstaff.kmutt.ac.th/~auapong.yai/ENE463/Slides/se7_ch06_v07.pdf · Object-Oriented and Classical Software Engineering

Slide 6.5

© The McGraw-Hill Companies, 2007

Testing (contd)

“V & V”Verification

Determine if the workflow was completed correctly

Validation Determine if the product as a whole satisfies its requirements

Page 6: Slide 6.1 Object-Oriented and Classical Software Engineeringwebstaff.kmutt.ac.th/~auapong.yai/ENE463/Slides/se7_ch06_v07.pdf · Object-Oriented and Classical Software Engineering

Slide 6.6

© The McGraw-Hill Companies, 2007

Testing (contd)

WarningThe term “verify” is also used for all non-execution-

based testing

Page 7: Slide 6.1 Object-Oriented and Classical Software Engineeringwebstaff.kmutt.ac.th/~auapong.yai/ENE463/Slides/se7_ch06_v07.pdf · Object-Oriented and Classical Software Engineering

Slide 6.7

© The McGraw-Hill Companies, 2007

6.1 Software Quality

Not “excellence”

The extent to which software satisfies itsspecifications

Every software professional is responsible forensuring that his or her work is correctQuality must be built in from the beginning

Page 8: Slide 6.1 Object-Oriented and Classical Software Engineeringwebstaff.kmutt.ac.th/~auapong.yai/ENE463/Slides/se7_ch06_v07.pdf · Object-Oriented and Classical Software Engineering

Slide 6.8

© The McGraw-Hill Companies, 2007

6.1.1 Software Quality Assurance

The members of the SQA group must ensure thatthe developers are doing high-quality workAt the end of each workflowWhen the product is complete

In addition, quality assurance must be applied toThe process itself

Example: Standards

Page 9: Slide 6.1 Object-Oriented and Classical Software Engineeringwebstaff.kmutt.ac.th/~auapong.yai/ENE463/Slides/se7_ch06_v07.pdf · Object-Oriented and Classical Software Engineering

Slide 6.9

© The McGraw-Hill Companies, 2007

6.1.2 Managerial Independence

There must be managerial independence betweenThe development groupThe SQA group

Neither group should have power over the other

Page 10: Slide 6.1 Object-Oriented and Classical Software Engineeringwebstaff.kmutt.ac.th/~auapong.yai/ENE463/Slides/se7_ch06_v07.pdf · Object-Oriented and Classical Software Engineering

Slide 6.10

© The McGraw-Hill Companies, 2007

Managerial Independence (contd)

More senior management must decide whether toDeliver the product on time but with faults, orTest further and deliver the product late

The decision must take into account the interestsof the client and the development organization

Page 11: Slide 6.1 Object-Oriented and Classical Software Engineeringwebstaff.kmutt.ac.th/~auapong.yai/ENE463/Slides/se7_ch06_v07.pdf · Object-Oriented and Classical Software Engineering

Slide 6.11

© The McGraw-Hill Companies, 2007

6.2 Non-Execution-Based Testing

Underlying principlesWe should not review our own workGroup synergy

Page 12: Slide 6.1 Object-Oriented and Classical Software Engineeringwebstaff.kmutt.ac.th/~auapong.yai/ENE463/Slides/se7_ch06_v07.pdf · Object-Oriented and Classical Software Engineering

Slide 6.12

© The McGraw-Hill Companies, 2007

6.2.1 Walkthroughs

A walkthrough team consists of from four to sixmembers

It includes representatives ofThe team responsible for the current workflowThe team responsible for the next workflowThe SQA group

The walkthrough is preceded by preparationLists of items

Items not understood Items that appear to be incorrect

Page 13: Slide 6.1 Object-Oriented and Classical Software Engineeringwebstaff.kmutt.ac.th/~auapong.yai/ENE463/Slides/se7_ch06_v07.pdf · Object-Oriented and Classical Software Engineering

Slide 6.13

© The McGraw-Hill Companies, 2007

6.2.2 Managing Walkthroughs

The walkthrough team is chaired by the SQArepresentative

In a walkthrough we detect faults, not correct themA correction produced by a committee is likely to be of

low qualityThe cost of a committee correction is too highNot all items flagged are actually incorrectA walkthrough should not last longer than 2 hoursThere is no time to correct faults as well

Page 14: Slide 6.1 Object-Oriented and Classical Software Engineeringwebstaff.kmutt.ac.th/~auapong.yai/ENE463/Slides/se7_ch06_v07.pdf · Object-Oriented and Classical Software Engineering

Slide 6.14

© The McGraw-Hill Companies, 2007

Managing Walkthroughs (contd)

A walkthrough must be document-driven, ratherthan participant-driven

Verbalization leads to fault finding

A walkthrough should never be used forperformance appraisal

Page 15: Slide 6.1 Object-Oriented and Classical Software Engineeringwebstaff.kmutt.ac.th/~auapong.yai/ENE463/Slides/se7_ch06_v07.pdf · Object-Oriented and Classical Software Engineering

Slide 6.15

© The McGraw-Hill Companies, 2007

6.2.3 Inspections

An inspection has five formal stepsOverviewPreparation, aided by statistics of fault typesInspectionReworkFollow-up

Page 16: Slide 6.1 Object-Oriented and Classical Software Engineeringwebstaff.kmutt.ac.th/~auapong.yai/ENE463/Slides/se7_ch06_v07.pdf · Object-Oriented and Classical Software Engineering

Slide 6.16

© The McGraw-Hill Companies, 2007

Inspections (contd)

An inspection team has four membersModeratorA member of the team performing the current workflowA member of the team performing the next workflowA member of the SQA group

Special roles are played by theModeratorReaderRecorder

Page 17: Slide 6.1 Object-Oriented and Classical Software Engineeringwebstaff.kmutt.ac.th/~auapong.yai/ENE463/Slides/se7_ch06_v07.pdf · Object-Oriented and Classical Software Engineering

Slide 6.17

© The McGraw-Hill Companies, 2007

Fault Statistics

Faults are recorded by severityExample:

Major or minor

Faults are recorded by fault typeExamples of design faults:

Not all specification items have been addressed Actual and formal arguments do not correspond

Page 18: Slide 6.1 Object-Oriented and Classical Software Engineeringwebstaff.kmutt.ac.th/~auapong.yai/ENE463/Slides/se7_ch06_v07.pdf · Object-Oriented and Classical Software Engineering

Slide 6.18

© The McGraw-Hill Companies, 2007

Fault Statistics (contd)

For a given workflow, we compare current faultrates with those of previous products

We take action if there are a disproportionatenumber of faults in an artifactRedesigning from scratch is a good alternative

We carry forward fault statistics to the nextworkflowWe may not detect all faults of a particular type in the

current inspection

Page 19: Slide 6.1 Object-Oriented and Classical Software Engineeringwebstaff.kmutt.ac.th/~auapong.yai/ENE463/Slides/se7_ch06_v07.pdf · Object-Oriented and Classical Software Engineering

Slide 6.19

© The McGraw-Hill Companies, 2007

Statistics on Inspections

IBM inspections showed up82% of all detected faults (1976)70% of all detected faults (1978)93% of all detected faults (1986)

Switching system90% decrease in the cost of detecting faults (1986)

JPLFour major faults, 14 minor faults per 2 hours (1990)Savings of $25,000 per inspectionThe number of faults decreased exponentially by phase

(1992)

Page 20: Slide 6.1 Object-Oriented and Classical Software Engineeringwebstaff.kmutt.ac.th/~auapong.yai/ENE463/Slides/se7_ch06_v07.pdf · Object-Oriented and Classical Software Engineering

Slide 6.20

© The McGraw-Hill Companies, 2007

Statistics on Inspections (contd)

Warning

Fault statistics should never be used forperformance appraisal“Killing the goose that lays the golden eggs”

Page 21: Slide 6.1 Object-Oriented and Classical Software Engineeringwebstaff.kmutt.ac.th/~auapong.yai/ENE463/Slides/se7_ch06_v07.pdf · Object-Oriented and Classical Software Engineering

Slide 6.21

© The McGraw-Hill Companies, 2007

6.2.4 Comparison of Inspections and Walkthroughs

InspectionTwo-step, informal process

Preparation Analysis

WalkthroughFive-step, formal process

Overview Preparation Inspection Rework Follow-up

Page 22: Slide 6.1 Object-Oriented and Classical Software Engineeringwebstaff.kmutt.ac.th/~auapong.yai/ENE463/Slides/se7_ch06_v07.pdf · Object-Oriented and Classical Software Engineering

Slide 6.22

© The McGraw-Hill Companies, 2007

6.2.5 Strengths and Weaknesses of Reviews

Reviews can be effectiveFaults are detected early in the process

Reviews are less effective if the process isinadequateLarge-scale software should consist of smaller, largely

independent piecesThe documentation of the previous workflows has to be

complete and available online

Page 23: Slide 6.1 Object-Oriented and Classical Software Engineeringwebstaff.kmutt.ac.th/~auapong.yai/ENE463/Slides/se7_ch06_v07.pdf · Object-Oriented and Classical Software Engineering

Slide 6.23

© The McGraw-Hill Companies, 2007

6.2.6 Metrics for Inspections

Inspection rate (e.g., design pages inspected perhour)

Fault density (e.g., faults per KLOC inspected)

Fault detection rate (e.g., faults detected per hour)

Fault detection efficiency (e.g., number of major,minor faults detected per hour)

Page 24: Slide 6.1 Object-Oriented and Classical Software Engineeringwebstaff.kmutt.ac.th/~auapong.yai/ENE463/Slides/se7_ch06_v07.pdf · Object-Oriented and Classical Software Engineering

Slide 6.24

© The McGraw-Hill Companies, 2007

Metrics for Inspections (contd)

Does a 50% increase in the fault detection ratemean thatQuality has decreased? OrThe inspection process is more efficient?

Page 25: Slide 6.1 Object-Oriented and Classical Software Engineeringwebstaff.kmutt.ac.th/~auapong.yai/ENE463/Slides/se7_ch06_v07.pdf · Object-Oriented and Classical Software Engineering

Slide 6.25

© The McGraw-Hill Companies, 2007

6.3 Execution-Based Testing

Organizations spend up to 50% of their softwarebudget on testingBut delivered software is frequently unreliable

Dijkstra (1972)“Program testing can be a very effective way to show

the presence of bugs, but it is hopelessly inadequate forshowing their absence”

Page 26: Slide 6.1 Object-Oriented and Classical Software Engineeringwebstaff.kmutt.ac.th/~auapong.yai/ENE463/Slides/se7_ch06_v07.pdf · Object-Oriented and Classical Software Engineering

Slide 6.26

© The McGraw-Hill Companies, 2007

6.4 What Should Be Tested?

Definition of execution-based testing“The process of inferring certain behavioral properties of

the product based, in part, on the results of executingthe product in a known environment with selectedinputs”

This definition has troubling implications

Page 27: Slide 6.1 Object-Oriented and Classical Software Engineeringwebstaff.kmutt.ac.th/~auapong.yai/ENE463/Slides/se7_ch06_v07.pdf · Object-Oriented and Classical Software Engineering

Slide 6.27

© The McGraw-Hill Companies, 2007

6.4 What Should Be Tested? (contd)

“Inference”We have a fault report, the source code, and — often —

nothing else

“Known environment”We never can really know our environment

“Selected inputs”Sometimes we cannot provide the inputs we wantSimulation is needed

Page 28: Slide 6.1 Object-Oriented and Classical Software Engineeringwebstaff.kmutt.ac.th/~auapong.yai/ENE463/Slides/se7_ch06_v07.pdf · Object-Oriented and Classical Software Engineering

Slide 6.28

© The McGraw-Hill Companies, 2007

6.4 What Should Be Tested? (contd)

We need to test correctness (of course), and alsoUtilityReliabilityRobustness, andPerformance

Page 29: Slide 6.1 Object-Oriented and Classical Software Engineeringwebstaff.kmutt.ac.th/~auapong.yai/ENE463/Slides/se7_ch06_v07.pdf · Object-Oriented and Classical Software Engineering

Slide 6.29

© The McGraw-Hill Companies, 2007

6.4.1 Utility

The extent to which the product meets the user’sneedsExamples:

Ease of use Useful functions Cost effectiveness

Page 30: Slide 6.1 Object-Oriented and Classical Software Engineeringwebstaff.kmutt.ac.th/~auapong.yai/ENE463/Slides/se7_ch06_v07.pdf · Object-Oriented and Classical Software Engineering

Slide 6.30

© The McGraw-Hill Companies, 2007

6.4.2 Reliability

A measure of the frequency and criticality of failureMean time between failuresMean time to repairTime (and cost) to repair the results of a failure

Page 31: Slide 6.1 Object-Oriented and Classical Software Engineeringwebstaff.kmutt.ac.th/~auapong.yai/ENE463/Slides/se7_ch06_v07.pdf · Object-Oriented and Classical Software Engineering

Slide 6.31

© The McGraw-Hill Companies, 2007

6.4.3 Robustness

A function ofThe range of operating conditionsThe possibility of unacceptable results with valid inputThe effect of invalid input

Page 32: Slide 6.1 Object-Oriented and Classical Software Engineeringwebstaff.kmutt.ac.th/~auapong.yai/ENE463/Slides/se7_ch06_v07.pdf · Object-Oriented and Classical Software Engineering

Slide 6.32

© The McGraw-Hill Companies, 2007

6.4.4 Performance

The extent to which space and time constraintsare met

Real-time software is characterized by hard real-time constraints

If data are lost because the system is too slowThere is no way to recover those data

Page 33: Slide 6.1 Object-Oriented and Classical Software Engineeringwebstaff.kmutt.ac.th/~auapong.yai/ENE463/Slides/se7_ch06_v07.pdf · Object-Oriented and Classical Software Engineering

Slide 6.33

© The McGraw-Hill Companies, 2007

6.4.5 Correctness

A product is correct if it satisfies its specifications

Page 34: Slide 6.1 Object-Oriented and Classical Software Engineeringwebstaff.kmutt.ac.th/~auapong.yai/ENE463/Slides/se7_ch06_v07.pdf · Object-Oriented and Classical Software Engineering

Slide 6.34

© The McGraw-Hill Companies, 2007

Correctness of specifications

Incorrect specification for a sort:

Function trickSort which satisfies this specification:

Figure 6.1

Figure 6.2

Page 35: Slide 6.1 Object-Oriented and Classical Software Engineeringwebstaff.kmutt.ac.th/~auapong.yai/ENE463/Slides/se7_ch06_v07.pdf · Object-Oriented and Classical Software Engineering

Slide 6.35

© The McGraw-Hill Companies, 2007

Correctness of specifications (contd)

Incorrect specification for a sort:

Corrected specification for the sort:

Figure 6.1 (again)

Figure 6.3

Page 36: Slide 6.1 Object-Oriented and Classical Software Engineeringwebstaff.kmutt.ac.th/~auapong.yai/ENE463/Slides/se7_ch06_v07.pdf · Object-Oriented and Classical Software Engineering

Slide 6.36

© The McGraw-Hill Companies, 2007

Correctness (contd)

Technically, correctness is

Not necessaryExample: C++ compiler

Not sufficientExample: trickSort

Page 37: Slide 6.1 Object-Oriented and Classical Software Engineeringwebstaff.kmutt.ac.th/~auapong.yai/ENE463/Slides/se7_ch06_v07.pdf · Object-Oriented and Classical Software Engineering

Slide 6.37

© The McGraw-Hill Companies, 2007

6.5 Testing versus Correctness Proofs

A correctness proof is an alternative to execution-based testing

Page 38: Slide 6.1 Object-Oriented and Classical Software Engineeringwebstaff.kmutt.ac.th/~auapong.yai/ENE463/Slides/se7_ch06_v07.pdf · Object-Oriented and Classical Software Engineering

Slide 6.38

© The McGraw-Hill Companies, 2007

6.5.1 Example of a Correctness Proof

The code segment to be proven correct

Figure 6.4

Page 39: Slide 6.1 Object-Oriented and Classical Software Engineeringwebstaff.kmutt.ac.th/~auapong.yai/ENE463/Slides/se7_ch06_v07.pdf · Object-Oriented and Classical Software Engineering

Slide 6.39

© The McGraw-Hill Companies, 2007

Example of a Correctness Proof (contd)

A flowchartequivalent ofthe codesegment

Figure 6.5

Page 40: Slide 6.1 Object-Oriented and Classical Software Engineeringwebstaff.kmutt.ac.th/~auapong.yai/ENE463/Slides/se7_ch06_v07.pdf · Object-Oriented and Classical Software Engineering

Slide 6.40

© The McGraw-Hill Companies, 2007

Example of a Correctness Proof (contd)

AddInput specificationOutput specificationLoop invariantAssertions

(See next slide)

Page 41: Slide 6.1 Object-Oriented and Classical Software Engineeringwebstaff.kmutt.ac.th/~auapong.yai/ENE463/Slides/se7_ch06_v07.pdf · Object-Oriented and Classical Software Engineering

Slide 6.41

© The McGraw-Hill Companies, 2007

Figure 6.6

Example of a Correctness Proof (contd)

Page 42: Slide 6.1 Object-Oriented and Classical Software Engineeringwebstaff.kmutt.ac.th/~auapong.yai/ENE463/Slides/se7_ch06_v07.pdf · Object-Oriented and Classical Software Engineering

Slide 6.42

© The McGraw-Hill Companies, 2007

Example of a Correctness Proof (contd)

An informal proof (using induction) appears inSection 6.5.1

Page 43: Slide 6.1 Object-Oriented and Classical Software Engineeringwebstaff.kmutt.ac.th/~auapong.yai/ENE463/Slides/se7_ch06_v07.pdf · Object-Oriented and Classical Software Engineering

Slide 6.43

© The McGraw-Hill Companies, 2007

6.5.2 Correctness Proof Mini Case Study

Dijkstra (1972):“The programmer should let the program proof and

program grow hand in hand”

“Naur text-processing problem” (1969)

Page 44: Slide 6.1 Object-Oriented and Classical Software Engineeringwebstaff.kmutt.ac.th/~auapong.yai/ENE463/Slides/se7_ch06_v07.pdf · Object-Oriented and Classical Software Engineering

Slide 6.44

© The McGraw-Hill Companies, 2007

Naur Text-Processing Problem

Given a text consisting of words separated by ablank or by newline characters, convert it to line-by-line form in accordance with the following rules:

Line breaks must be made only where the giventext contains a blank or newline

Each line is filled as far as possible, as long as

No line will contain more than maxpos characters

Page 45: Slide 6.1 Object-Oriented and Classical Software Engineeringwebstaff.kmutt.ac.th/~auapong.yai/ENE463/Slides/se7_ch06_v07.pdf · Object-Oriented and Classical Software Engineering

Slide 6.45

© The McGraw-Hill Companies, 2007

Episode 1

Naur constructed a 25-line procedure

He informally proved its correctness

Page 46: Slide 6.1 Object-Oriented and Classical Software Engineeringwebstaff.kmutt.ac.th/~auapong.yai/ENE463/Slides/se7_ch06_v07.pdf · Object-Oriented and Classical Software Engineering

Slide 6.46

© The McGraw-Hill Companies, 2007

Episode 2

1970 — Reviewer in Computing ReviewsThe first word of the first line is preceded by a blank

unless the first word is exactly maxpos characters long

Page 47: Slide 6.1 Object-Oriented and Classical Software Engineeringwebstaff.kmutt.ac.th/~auapong.yai/ENE463/Slides/se7_ch06_v07.pdf · Object-Oriented and Classical Software Engineering

Slide 6.47

© The McGraw-Hill Companies, 2007

Episode 3

1971 — London finds 3 more faults

Including:The procedure does not terminate unless a word longer

than maxpos characters is encountered

Page 48: Slide 6.1 Object-Oriented and Classical Software Engineeringwebstaff.kmutt.ac.th/~auapong.yai/ENE463/Slides/se7_ch06_v07.pdf · Object-Oriented and Classical Software Engineering

Slide 6.48

© The McGraw-Hill Companies, 2007

Episode 4

1975 — Goodenough and Gerhart find threefurther faults

Including:The last word will not be output unless it is followed by a

blank or newline

Page 49: Slide 6.1 Object-Oriented and Classical Software Engineeringwebstaff.kmutt.ac.th/~auapong.yai/ENE463/Slides/se7_ch06_v07.pdf · Object-Oriented and Classical Software Engineering

Slide 6.49

© The McGraw-Hill Companies, 2007

Correctness Proof Mini Case Study (contd)

Lesson:

Even if a product has been proven correct, it muststill be tested

Page 50: Slide 6.1 Object-Oriented and Classical Software Engineeringwebstaff.kmutt.ac.th/~auapong.yai/ENE463/Slides/se7_ch06_v07.pdf · Object-Oriented and Classical Software Engineering

Slide 6.50

© The McGraw-Hill Companies, 2007

6.5.3 Correctness Proofs and Software Engineering

Three myths of correctness proving (see over)

Page 51: Slide 6.1 Object-Oriented and Classical Software Engineeringwebstaff.kmutt.ac.th/~auapong.yai/ENE463/Slides/se7_ch06_v07.pdf · Object-Oriented and Classical Software Engineering

Slide 6.51

© The McGraw-Hill Companies, 2007

Software engineers do not have enoughmathematics for proofsMost computer science majors either know or can learn

the mathematics needed for proofs

Proving is too expensive to be practicalEconomic viability is determined from cost–benefit

analysis

Proving is too hardMany nontrivial products have been successfully provenTools like theorem provers can assist us

Three Myths of Correctness Proving

Page 52: Slide 6.1 Object-Oriented and Classical Software Engineeringwebstaff.kmutt.ac.th/~auapong.yai/ENE463/Slides/se7_ch06_v07.pdf · Object-Oriented and Classical Software Engineering

Slide 6.52

© The McGraw-Hill Companies, 2007

Can we trust a theorem prover ?

Difficulties with Correctness Proving

Figure 6.7

Page 53: Slide 6.1 Object-Oriented and Classical Software Engineeringwebstaff.kmutt.ac.th/~auapong.yai/ENE463/Slides/se7_ch06_v07.pdf · Object-Oriented and Classical Software Engineering

Slide 6.53

© The McGraw-Hill Companies, 2007

How do we find input–output specifications, loopinvariants?

What if the specifications are wrong?

We can never be sure that specifications or averification system are correct

Difficulties with Correctness Proving (contd)

Page 54: Slide 6.1 Object-Oriented and Classical Software Engineeringwebstaff.kmutt.ac.th/~auapong.yai/ENE463/Slides/se7_ch06_v07.pdf · Object-Oriented and Classical Software Engineering

Slide 6.54

© The McGraw-Hill Companies, 2007

Correctness Proofs and Software Engineering (contd)

Correctness proofs are a vital softwareengineering tool, where appropriate:When human lives are at stakeWhen indicated by cost–benefit analysisWhen the risk of not proving is too great

Also, informal proofs can improve the quality ofthe productUse the assert statement

Page 55: Slide 6.1 Object-Oriented and Classical Software Engineeringwebstaff.kmutt.ac.th/~auapong.yai/ENE463/Slides/se7_ch06_v07.pdf · Object-Oriented and Classical Software Engineering

Slide 6.55

© The McGraw-Hill Companies, 2007

6.6 Who Should Perform Execution-Based Testing?

Programming is constructive

Testing is destructiveA successful test finds a fault

So, programmers should not test their own codeartifacts

Page 56: Slide 6.1 Object-Oriented and Classical Software Engineeringwebstaff.kmutt.ac.th/~auapong.yai/ENE463/Slides/se7_ch06_v07.pdf · Object-Oriented and Classical Software Engineering

Slide 6.56

© The McGraw-Hill Companies, 2007

Who Should Perform Execution-Based Testing? (contd)

Solution:The programmer does informal testingThe SQA group then does systematic testingThe programmer debugs the module

All test cases must bePlanned beforehand, including the expected output, andRetained afterwards

Page 57: Slide 6.1 Object-Oriented and Classical Software Engineeringwebstaff.kmutt.ac.th/~auapong.yai/ENE463/Slides/se7_ch06_v07.pdf · Object-Oriented and Classical Software Engineering

Slide 6.57

© The McGraw-Hill Companies, 2007

6.7 When Testing Stops

Only when the product has been irrevocablydiscarded