claus brabrand, itu, denmark feb 02, 2010testing førsteårsprojekt (f2010) claus brabrand [...

Claus Brabrand, ITU, Denmark Feb 02, 2010TESTING

Førsteårsprojekt(F2010)

Claus Brabrand[ [email protected] ]

IT University of Copenhagen

[ 2 ]Claus Brabrand, ITU, Denmark TESTING Feb 02, 2010

Agenda (Feb 2, 2010)

Introduction to the course & project Groups Surprise (educational technology) Introduction to testing Control-flow White-box testing


Danmarkskort (krak data)

Danmarkskort: Visualisering Naviagation Søgning Ruteplanlægning ...

”Danmarkskort: Visualisering, Navigation, Søgning og Ruteplanlægning”


Proces: Konstitution

Konstitution:

A constitution is a system for government, often codified as a written document, that establishes the rules and principles of an autonomous [political] entity.


Proces: Dokumenter

1) Personlige notater: alle tager notater!

2) Projekt-dagbog: normer, aftaler, idéer, møde-referater,

beslutninger, beslutnings-grundlag og -form, eksterne samtaler

3) Arbejdsblade: til enhver tid sammenfatte fælles faglige resultater

4) Projekt-rapport: formidler projektets resultater (fra 'analyse' til 'konklusion')

5) Proces-beskrivelse: formidler erfaringer med + egen vurdering af arbejdsproces

-- v2.1--

(grundlag for komm. med selv+gruppen)

(grundlag for pæd. vejledning)

(grundlag for faglig vejledning)

(grundlag for evaluering af produkt)

(grundlag for eval. af proces)

weekly submission!


Groups

FAAP’09 Project Groups


Considerations (Group Formation)

Considerations; e.g.: a) Balance Introverts and Extroverts:

Too many intros few discussions / limited exchange Too many extros Blah blah blah…

b) Avoid ”strategist-strategist” clashes: More likely to ”clash”

c) Balance heterogeneously wrt. ”MBTI” Many different inputs

d) Avoid ”old group mates” in same group Learn to work with ”new people” Avoid sub-groups (aka, cliques)


Groups (MBTI Types)

ISTJ( Inspector )

ISTP( Crafter )

ESTP( Promoter )

ESTJ( Supervisor )

ISFJ( Protector )

ISFP( Composer )

ESFP( Performer )

ESFJ( Provider )

INFJ( Counselor )

INFP( Healer )

ENFP( Champion )

ENFJ( Teacher )

INTJ( Mastermind )

INTP( Architect )

ENTP( Inventor )

ENTJ( Fieldmarshal )

S N

T F T

I

E

P

J

J


White:

Tomas L. Anders Ø. Nikolaj Aa. Nicolai S. Ahmad S.

Yellow:

Sune A. Nicklas W. Martin K. Thomas D. Marc F.

Orange:

Liv T. Martin D. Jonas J. Thorkil B. Søren N.

Red:

Christian V. Jeppe T. Christian H. Anne D.P. Mads C.

Green:

Nicolai D. Benjamin M. Patrick A. Nicolai T. Niels J.

Blue:

Jonathan R. Anders M. Lasse C.Aa. Anders H.K. Michael B.M

Brown:

Signe M.H. Thomas T.H Hildur F. Niklas J. Asger S.

Black:

Jesper R. Kristian S.A. Morten H. Peter Ø. Kristian S.

Groups:

Gray:

Mikkel H. Jason S. Christoffer A Søren E. Kasper A.

Purple:

Emil B.M. Mark A. Mischa S. Benjamin H. Martin J.L.


Clickers !

:-)


What is the average rainfall of the Amazon basin?A. 20 mm/yearB. 200 mm/yearC. 2000 mm/yearD. 20000 mm/year

A

B

C

D

E

F

Copenhagen:587 mm/year


What is the fourth most populous nation in the world?A. PakistanB. BrazilC. IndonesiaD. NigeriaE. Russia

A

C

E

TOP 3:• China (1,338 mio)• India (1,166 mio)• USA (307 mio)


What is the following expression: "A B" logically equivalent to?A. A BB. A BC. (A B)D. (A B)E. (A B)F. (A B)A

C

E


Introduction to Testing


( First-year Project Course, ITU, Denmark )


Outline

Motivation: Why bother with testing?

The Psychology of Testing: What is the goal of testing?

The Testing Process: What is relation to other programming-related tasks?

Bugs: Important properties of bugs

Implementation vs. Specification: Formal definition of a bug


Learning & Exam Goals

”Product”:

”Oral Exam”:


Software Errors

Therac-25 Radiation Therapy ’85-’87

Massive overdoses (6 deaths / amputations)!

Patriot Missile Guidance System ’91 (Gulf War 1.0)

Accumulating rounding errors deaths

Ariane V ’96 (one of the most expensive bugs, ever)

Conversion from 64-bit float to 16-bit signed int


zzzz

Software Errors (cont’d)

Train Control System ’98 (Berlin)

Train cancellations

Mars Pathfinder July ’97

Periodic resets

Win95/98 w/ 3rd-Party Device Drivers late ’90es

Dysfunction (“blue screen of death”)!

...on mars!


Software Errors (cont’d)

Mobile Phones ’00-…

Freeze and odd behaviors (really annoying)!

Cruise Control System Model ’86 (Grady Booch)

Accellerated after car ignition car crashes

Baggage Handling System ’94-’95 (at Denver Int’l Airport)

$ 360,000,000 USD


…and what about?!

Surgical Laser Control System

Eye damage (blindness)!

Air Plane Control System

Dysfunction (plane crash)!

Nuclear Powerplant Control System

Core melt-down (“China-syndrome”)!


Outline







Testing: Incomplete Process

A program has: many possible valid inputs many possible invalid inputs

Hence:

88

Testing can never prove absence of errors!

Testing is an incomplete process!


The Psychology of Testing

X

Goal: test a program to "show that it works" Homo Sapiens are ”goal oriented” (steer towards goal)!

…we might as well stop before we even start! :-(

”Testing is the process of demonstrating that errors are not present.”

”The purpose of testing is to show that a program performs its intended functions correctly.”

[cf. ”The Art of Software Testing” (Chap. 2), Glenford J. Myers, 1979]

”Testing is the process of establishing confidence that a program does what it is supposed to do.”


successfultest case

unsuccessfultest case

Problematic terminology:

successfultest case

unsuccessfultest case

Much better terminology:

Psychology of Testing (cont’d)

Goal: find as many errors as possible Note: realistically assumes errors are present

Constructive goal (actually destructive)

”Testing is the process of executing a program with the intent of finding errors.”

vs



Constructive vs. DestructiveThinking Constructive thinking:

(e.g., programming) ”Test-to-pass”

Often not a good idea to ”test” your own code :-(

Destructive thinking:(e.g., testing) ”Test-to-fail”

Often better to test/break someone else’s code :-)

Recommendation: Have another group help you test/break your group ”product”


Tester’s Goal

The goal of a software tester is:

Testers (therefore) often aren’t the most popular members of a project team :-)

- 1) “to find bugs”; - 2) “find them as early as possible”; and - 3) “make sure they get fixed”

[R.Patton, “Software Testing”, p. 19]

[cf. ”Software Testing”, R.Patton, p.19]


Outline







ISO9126

Maintainability

ReliabilityUsability

Portability

How robust is the SW wrt.external network failures, ’^C’, ...?

How easy is the SW to understand?…and use?

How easy is it to transfer and adapt SW to new environment / platform?How easy is it to modify the SW?

And fix errors?

Software QualityInternational evaluation standard

Functionality Efficiency

ISO 9126

Does the SW do what it’s supposed to?

Does it work as intended?

How much time/memory/space/- bandwidth/… does the SW consume?


Testing vs. Debugging?

Testing vs. Debugging?:

Functionality: Efficiency:

Quality Assurance:(Functionality)

Testing(Performance)

Testing

Diagnosis: Profiling

Purpose:

Regarding:

Debugging


Testing vs. Debugging (cont’d)

Evaluate test resultsFix problem(reprogram)

FunctionalityTesting

Quality assurance:

Perform (functionality) test

Debugging

Diagnosis:

Determine problem?

01101021Program:

01101011

(greater confidence!)

SYSTEMATIC

Document test results

(confidence?!?)

Re-

01101011

2

1


Performance Testing vs. Profiling

Evaluate test resultsImprove program(reprogram)

Performance Testing

Quality assurance:

Perform (efficiency) test

Profiling

Diagnosis:

Determine problem?

01101021Program:

(confidence?!?)

Re-

SYSTEMATIC

01101011

01101011

(greater confidence!)Document test results


Testing vs. Debugging (cont’d)

Evaluate test resultsFix problem(reprogram)

FunctionalityTesting

Quality assurance:

Perform (functionality) test

Debugging

Diagnosis:

Determine problem?

01101021Program:

01101011

(greater confidence!)

SYSTEMATIC

Document test results

(confidence?!?)

Re-

01101011

2

1


White-box vs. Black-box Test

White-box Testing: (aka., ”structural testing”) (aka., ”internal testing”)

Test focus: source code

Black-box Testing: (aka., ”behavioral testing”) (aka., ”external testing”) (aka., ”input-ouput testing”)

Test focus: specification (or intention)

Complementary Approaches!!!

n = in();

n = n/2;

odd(n)

n = 3*n+1;

out(n);

tt ff ~?program spec


Exercise: which is (usually) ”best” - and why?

A) white-box testing ; black-box testing ; (i.e., white-box testing first)

B) black-box testing ; white-box testing ; (i.e., black-box testing first)

Answer: ’B’ Settle overall impl ~ spec problems first Before zooming in on details of impl

Exercise

…or…


Outline







Definition: ”bug”Main entry: 2bug

Pronunciation: /’bəg/

Function: noun

Etymology: origin unknown

Date: 16221 a: an insect or other creeping or crawling invertebrate (as a spider or centipede)

b: any of several insects (as the bedbug or cockroach) commonly considered obnoxious

c: any of an order (Hemiptera and especially its suborder Heteroptera) of insects that have sucking mouthparts, forewings thickened at the base, and incomplete metamorphosis and are often economic pests —called also true bug

2: an unexpected defect, fault, flaw, or imperfection <e.g., “the software was full of bugs”>

3 a: a germ or microorganism especially when causing disease b: an unspecified or nonspecific sickness usually presumed due to a bug

4: a sudden enthusiasm

5: enthusiast <a camera bug>

6: a prominent person

7: a crazy person

8: a concealed listening device

9: a weight allowance given apprentice jockeys


”The Harvard Mark II Bug”

Photo of firstactual ”bug”:

“The first documented computer bug was a moth found trapped between points at Relay # 70, Panel F, of the Mark II Aiken Relay Calculator while it was being tested”

Harvard University, Sep. 9, 1947


Example of a Bug :-)

Hej Claus,

A propos test og datoberegninger:

Fredag morgen mente min PDA kalender (Microsoft Windows CE) at vi skrev lørdag 1. marts. Jeg stillede selvfølgelig tålmodigt uret tilbage til fredag 29. februar 2008 (dette fandt sted på et møde hos Microsoft i Vedbæk ;-) Lørdag formiddag startede den så med at vise min (ret tomme) kalender for august 2049. Det indbyggede ur stod på 1. januar 1601. Ahem.

Peter


Terminology (for ’Bugs’)

”Severe conditions”: Fault Failure Defect

”Unintended operation”: Anomaly Incident Variance Feature (sounds intended)

”Generic terms”: Problem Error Bug

Typically imply blame; as in:- ”it was his fault”

Famous quote:- ”It’s not a bug, it’s a feature”

we’ll use these terms


Bugs

Bugs often occur in groups: If you find one, chances are there are more nearby This property useful when testing program parts:

i.e., figuring out where to concentrate testing efforts

Not all bugs will be fixed: Too costly? Too risky? Not ”cost-effective”? Cause unknown?


Cost of (Fixing) Bugs

Cost of bugs increases exponentially (over time):

(log)

spec design code test release

$1$100

$10,000

$1,000,000

$100,000,000


cost

phase


”The Pesticide Paradox”

”The pesticide paradox”: ”The more you test a software,

the more immune it becomes to your tests”

B.Beizer, “Software Testing Techniques”, 1990


Different 'kinds' of errors

Syntactic errors: Mal-formed program:

Semantic errors: Symbol errors Type errors Other semantic errors:

(e.g. uninitialized vars)

Logical errors: Compiler: ”no errors”

int square(int x) { return x*x} *** syntax error at line 2

’;’ expected

int square(int x) { return n*n;} *** symbol error at line 2

undefined variable ”n”

int square(float x) { return x*x;}*** type error at line 2 function returns float, not int

int square(int x) { return x+x;} no errors found!!!


Outline







Definition: ”Bug”

A ”bug” is a relation between: Specification & Implementation

Whether or not specification is: Explicit or Implicit Written or Oral Formal or Informal

(e.g., ”product spec” vs. ”back-of-envellope”)

implementation(aka., ’program’)

specification(aka., ’spec’)

~bug


Specification

A spec states things an impl…: Should do! Shouldn’t do! Unspecified? (’unclear’, ’unmentioned’, or ’left open’)

Should do!

Shouldn’t do!

Unspecified?

S

Specs are often intentionally under-specified. It’s often better to not ”prematurely

commit” to a particular solution (by specifying exactly how a task should be done) –

and instead just state which overall tasks the system should do.


Formal Definition: ”Bug”

A (software) bug occurs when: 1. Impl doesn’t do sth spec says it should:

2. Impl does sth spec says it shouldn’t:

3. Impl does sth spec doesn’t mention:

4. Spec doesn’t mention sth, but should:

5. Impl is hard to understand/use by user(s):

~

~?!

(or does it incorrectly)IS

I S

S I

?!I

S


!~ideal


Which of the conditions (1-5) does this violate (if any)?A. It's not a bugB. Bug wrt. #1C. Bug wrt. #2D. Bug wrt. #3E. Bug wrt. #4F. Bug wrt. #5

5%

3%

3%

3%

28%

48%A

C

E

”Additional functionality”?e.g., a calculator which also does square root " " (but wasn’t supposed to)

' '


Which of the conditions (1-5) does this violate (if any)?A. It's not a bug B. Bug wrt. #1 C. Bug wrt. #2D. Bug wrt. #3E. Bug wrt. #4F. Bug wrt. #5A

C

E

”Easter egg”?e.g., hit [Alt+Shift+2] in Solitaire to instantly win game


Which of the conditions (1-5) does this violate (if any)?A. It's not a bug B. Bug wrt. #1C. Bug wrt. #2D. Bug wrt. #3E. Bug wrt. #4F. Bug wrt. #5A

C

E

”An (good) impl w/o a spec”?i.e., only a piece of software (no specification whatsoever)


Clicker Exercise (cont'd)

Exercise:

Ron Patton interprets as (”spec := impl”):

trivially no bugs in impl ! (according to [own] definition #1,#2,#3)

More sensible to interpret as ”no spec”: entire impl is essentially one big bug !

(…according to definition #3+#4)

”Because the software is already complete, you have the perfect specification

– the product itself” [R.Patton, ”Software Testing”, p.31]

”an impl w/o a spec” ?

bug~

[cf. ”Software Testing”, R.Patton, p.15 v. p.31]


Test Cases


Testing…:

Testing is easy: (e.g., ”random experimentation”)

Testing well is not easy; requires: A SYSTEMATIC approach Test case…:

production evaluation documentation


Representativity!

Appropriate Test Cases?

SYSTEMATICTESTING !


Myers’ 10 Testing Principles

1) expected output is part of a test case 2) avoid testing own program 3) avoid testing own (organization’s) program 4) thoroughly inspect result of each test case 5) also write ”invalid / unexpected” test cases 6) also check: doesn’t do what not supposed to 7) avoid throw-away test cases 8) never assume no errors when making test cases 9) Prob(more errors) ~ Prob(#errors already found) 10) Testing is creative+intellectually challenging task


a) destructive vs. constructive modeb) may be overall misunderstandings

instead: systematic”regression testing”!

a) …b) …


Control-Flow




White-box vs. Black-box Test

White-box Testing: (aka., ”structural testing”) (aka., ”internal testing”)

Test focus: source code

Black-box Testing: (aka., ”behavioral testing”) (aka., ”external testing”) (aka., ”input-ouput testing”)

Test focus: specification (or intention)

n = in();

n = n/2;

odd(n)

n = 3*n+1;

out(n);

tt ff ~?program spec


Test Coverage?

Method coverage: Does every method run (at least once)?

Statement coverage: Does every statement run (at least once)?

Branch coverage: Does every branch run (at least once)?

Path coverage: Does every path run (at least once)?


Statement coverage

Statement coverage: Does every statement run (at least once)?

-Box ”Statement Coverage Testing” is: Efficient (fast) ! Effective (thorough) !

Good for complicated program logic(esp. ”initialization errors”)


Control Structures &Control Flow Graphs


Control Structures

Control Structures: Statements (or Expr’s) that affect ”flow of control”:

if-else:

if:

if ( Exp ) Stm1 else Stm2

if ( Exp ) Stm

Stm1

Exptrue false

Stm2

confluence

Stm

Exptrue false

confluenceThe expression must be of type boolean; if it evaluates to true, the given statement is executed, otherwise not.

The expression must be of type boolean; if it evaluates to true, Statement-1 is executed, otherwise Statement-2 is executed.

[syntax]

[semantics]

[syntax]

[semantics]


Control Structures (cont’d)

while:

for:

while ( Exp ) Stm

for (Exp1 ; Exp2 ; Exp3) Stm

Equivalent to:

The expression must be of type boolean; if it evaluates to false, the given statement is skipped, otherwise it is executed and afterwards the expression is evaluated again. If it is still true, the statement is executed again. This is continued until the expression evaluates to false.

{ Exp1; while ( Exp2 ) { Stm Exp3; }}

Stm

Exptrue false

confluence

Exp1;

Exp2true false

Stm

confluence

Exp3;

[syntax]

[semantics]

[syntax]

[semantics]


Which diagram corresponds to the "do-while" statement?A. B. C. D.

3%

10%

73%

A

C

E

A.

C. D.

B.


Example (Control-Flow Graph)

Example Program: Control-Flow Graph:

void m(int account, int rate) { account = account + 10;

if (account > 100) rate = rate * 2; else rate = rate / 2;

out(“account = ” + account + “ rate = ” + rate);}

account = account + 10;

rate *= 2; rate /= 2;

account > 100true false

out(“account = ” + …);

confluence


Exercise (groups of 2x): Make a CFG for...:public static void main ( String[] args ) { int mi, ma; if (args.length == 0) System.out.println("No numbers"); else { mi = ma = Integer.parseInt(args[0]); for (int i=1; i < args.length; i++) { int obs = Integer.parseInt(args[i]); if (obs > ma) ma = obs; else if (mi < obs) mi = obs; } System.out.println("min=" + mi + "," + "max=" + ma);}}

/* 1if-else */

/* 2for */

/* 3if-else */

/* 4if */

if

else

for

if

elseif


Swap with another group and check (correct) their CFG CFG:

int mi, ma;

System.out.println("No numbers");

args.length == 0

mi = ma = Integer.parseInt(args[0]);

int i=1;

i < args.length

i++;

System.out.println("min=" + mi + "," + "max=" + ma);

int obs = Integer.parseInt(args[i]);

obs > ma

ma = obs; mi < obs

mi = obs;

true false

true false

true false

true false

2

34

1


Group hand-in for next week

public List<Integer> merge(List<Integer> list1, List<Integer> list2){ // invariant: we ASSUME list1 and list2 are sorted!

List<Integer> list3 = new ArrayList<Integer>(); for (int i=0; i < list2.size(); i++) { for (int j=0; j < list1.size(); j++) { if (list2.get(i) > list1.get(j)) { list3.add(list1.get(j)); list1.remove(j); } } list3.add(list2.get(i)); } if (list1.size() > 0) { list3.addAll(list1); } return list3;}

Make a perfect! CFG (Control-Flow Graph) for the following program (in your groups):


Control Structures (cont’d)

”?:”; ”conditional expression”:

”&&”; ”lazy conjunction” (aka., ”short-cut ”):

”||”; ”lazy disjunction” (aka., ”short-cut ”):

switch: switch ( Exp ) { Swb* }

case Exp : Stm* break;

default : Stm* break;

Swb:

Exp1 ? Exp2 : Exp3

Exp1 && Exp2

Exp1 || Exp2


Control Structures (cont’d2)

try-catch-finally (exceptions):

return / break / continue:

”method invocation”: e.g.;

”recursive method invocation”: e.g.;

”virtual dispatching”: e.g.;

try Stm1 catch ( Exp ) Stm2 finally Stm3

f(x)

return ; return Exp ; break ; continue ;

f(x)

f(x)


White-Box Testing




White-Box Testing (usually)

if: TEST condition true and false

if-else: TEST condition true and false

while: TEST zero, one, more-than-one iterations in loop

for: TEST zero, one, more-than-one iterations in loop


White-Box Testing

”Coverage Table”:

”Expectancy Table”:

Input property

account > 90

account <= 90

Data set

A

B

Choice

1ife true

false

Data set

A

B

Input

(98,3)

(76,4)

Expected output

”a=108, r=6”

”a= 86, r=2”

Actual output

”a=108, r=6”

”a= 86, r=2”

=

void m(int account, int rate) { account = account + 10;

if (account > 100) // 1ife

rate = rate * 2; else rate = rate / 2;

out(“account = ” + account + “ rate = ” + rate);}

Testing the world famous method: ”insert-$10-then-double-rate-if-account- exceeds-$100-otherwise-halve-rate”


”Coverage Table”:

Coverage Table

Input property

No numbers

At least one number

Exactly one number

Exactly two numbers

At least three numbers

"N > current max""N current max""N cur max & N > cur min""N cur max & N cur min"

Data set

A

B

B

C

E

C

D

E (3rd num)

E (2nd num)

Choice

1ife true

false

2for zero-times

once

more-than-once

3ife true

false

4if true

falseNB: you don't (necessarily) have to "pack" into minimal data set


”Expectancy Table”:

Expectancy Table

Data set

A

B

C

D

E

Advice:Avoid expected 0’s (i.e., zeroes)

(Default value in many languages.)Advice:Avoid reusing same numbers in tests

(Data layout sometimes reuse old memory.)

Input

[17]

[27,29]

[39,37]

[49,47,48]

Expected output

”no numbers”

”min=17,max=17”

”min=27,max=29”

”min=37,max=39”

”min=47,max=49”

Actual output

”no numbers”

”min=17,max=17”

”min=27,max=29”

”min=39,max=39”

”min=49,max=49”

=


public static void main ( String[] args ) { int mi, ma; if (args.length == 0) System.out.println("No numbers"); else { mi = ma = Integer.parseInt(args[0]); for (int i=1; i < args.length; i++) { int obs = Integer.parseInt(args[i]); if (obs > ma) ma = obs; else if (mi < obs) mi = obs; } System.out.println(”min=" + mi + "," + "max=" + ma);}}

Debugging ’ D ’ then reveals…

/* 1if-else */

/* 2for */

/* 3if-else */

/* 4if */

if

else

for

if

elseif

Should have been:

(mi > obs)


Re-Test !

…as debugging oftenintroduces new errors !

Fixed Program:Coverage Table:

Expectancy Table:

Recall: no guarantee!


Another Examplepublic static void main ( String[] args ) { int mi1 = 0, mi2 = 0; if (args.length == 0) /* 1if-else */ System.out.println("No numbers"); else { mi1 = Integer.parseInt(args[0]); if (args.length == 1) /* 2if-else */ System.out.println("Smallest = " + mi1); else { int obs = Integer.parseInt(args[1]); if (obs < mi1) /* 3if */ { mi2 = mi1; mi1 = obs; } for (int i = 2; i < args.length; i++) { /* 4for */ obs = Integer.parseInt(args[i]); if (obs < mi1) /* 5if-else */ { mi2 = mi1; mi1 = obs; } else if (obs < mi2) /* 6if */ mi2 = obs; } System.out.println("The two smallest are: " + mi1 + " and " + mi2);} } }


Coverage Table

Choice Input property Data set

1ife true No numbers

1ife false At least one number

2ife true Exactly one number

2ife false At least two numbers

3if true 2nd number ≥ 1st number

3if false 2nd number < 1st number

4for zero-times Exactly two numbers

4for once Exactly three numbers

4for more-than-once At least four numbers

5ife true 3rd number < current min

5ife false 3rd number ≥ current min

6if true 3rd ≥ cur min & 3rd < 2nd least

6if false 3rd ≥ cur min & 3rd ≥ 2nd least

A

B

B

C

C

D

D

E

H

E

F

F

G


Expectancy Table

Data set Input Expected output = Actual output

A ”no numbers” ”no numbers” B [17] ”17” ”17”

C [27,29] ”27 and 29” ”27 and 0”

D [39,37] ”37 and 39” ”37 and 39”

E [49,48,47] ”47 and 48” ”47 and 48”

F [59,57,58] ”57 and 58” ”57 and 58”

G [67,68,69] ”67 and 68” ”67 and 0”

H [77,78,79,76] ”76 and 77” ”76 and 77”

Debugging reveals that variable

”mi2” erroneously retains initialization (0).


Debuggingpublic static void main ( String[] args ) { int mi1 = 0, mi2 = 0; if (args.length == 0) /* 1if-else */ System.out.println("No numbers"); else { mi1 = Integer.parseInt(args[0]); if (args.length == 1) /* 2if-else */ System.out.println("Smallest = " + mi1); else { int obs = Integer.parseInt(args[1]); if (obs < mi1) /* 3if */ { mi2 = mi1; mi1 = obs; } for (int i = 2; i < args.length; i++) { /* 4for */ obs = Integer.parseInt(args[i]); if (obs < mi1) /* 5if-else */ { mi2 = mi1; mi1 = obs; } else if (obs < mi2) /* 6if */ mi2 = obs; } System.out.println("The two smallest are: " + mi1 + " and " + mi2);} } }

mi2 = obs;

Re-Test:


Which cases are "covered" by input "n=0"?A. if/false, while/zeroB. if/falseC. if/trueD. if/true, while/zeroE. if/true, while/zero, while/one, while/manyF. none of the above answers are correct

10%

83%

3%A

C

E

void mth(int n) { if (n!=0) {

/* if */ while (n>0) { /* while */ n--; } }}


White-Box Test Exercise

Make a systematic white-box test of the following program (iterative factorial):

i.e., you need to make: Coverage Table Expectancy Table (w/o "actual output")

int factorial(int n) throws BadUserException { if (n<0) throw BadUserException; else { int res = 1; for (int i=1; i<=n; i++) { res = res * i; } return res; }}


Group hand-in for next week

public List<Integer> merge(List<Integer> list1, List<Integer> list2) { // invariant: we ASSUME list1 and list2 are sorted!

List<Integer> list3 = new ArrayList<Integer>(); for (int i=0; i < list2.size(); i++) { for (int j=0; j < list1.size(); j++) { if (list2.get(i) > list1.get(j)) { list3.add(list1.get(j)); list1.remove(j); } } list3.add(list2.get(i)); } if (list1.size() > 0) { list3.addAll(list1); } return list3;}

Note:Do not forget toalways re-test after debugging!

Make a perfect! systematic white-box test of the following program (in your groups):


Thanks!

Get to know each other in your group – and discuss how you

would like to work together

claus brabrand, itu, denmark feb 02, 2010testing førsteårsprojekt (f2010) claus brabrand [...

Documents