Reproducing Crashes. Shifting Role of Testing. Shifting Role of Testing. Waterfall Model, V-Model

Size: px
Start display at page:

Download "Reproducing Crashes. Shifting Role of Testing. Shifting Role of Testing. Waterfall Model, V-Model"

Transcription

1 Reproducing Crashes Andreas Leitner Universität des Saarlandes Shifting Role of ing ing often ne towards release-time Modern development processes move testing to the center of development 2 2 Shifting Role of ing ing often ne towards release-time Modern development processes move testing to the center of development Waterfall Model, V-Model 2 2

2 Shifting Role of ing ing often ne towards release-time Modern development processes move testing to the center of development Waterfall Model, V-Model 2 Agile Methods, Driven Development 2 Shifting Role of ing Not all testing can be ne by test engineer Developers must prepare more tests s must execute more often suites must execute quickly 3 Shifting Role of ing Creating and minimizing tests Extracting tests Not all testing can be ne by test engineer Developers must prepare more tests s must execute more often suites must execute quickly 3

3 Shifting Role of ing Creating and minimizing tests Extracting tests Automated Not all testing can be ne by test engineer Developers must prepare more tests s must execute more often suites must execute quickly 3 Creating and minimizing tests Extracting tests Program is fed to Generator generates Case Leitner et. al (ASE, 2007) 4 4 Creating and minimizing tests Extracting tests Program Minimizer generates Case is fed to is fed to (smaller) Generator generates Case Leitner et. al (ASE, 2007) 4 4

4 Creating and minimizing tests Extracting s Developer plays with Program observes Extractor Leitner et al. (ESEC/FSE, 2007) 5 5 Creating and minimizing tests Extracting s Developer plays with Program Failure Extractor observes Leitner et al. (ESEC/FSE, 2007) 5 5 Creating and minimizing tests Extracting s Developer plays with Program Failure Cases extracts Extractor observes Leitner et al. (ESEC/FSE, 2007) 5 5

5 Basic Idea: Contract-Based s Precondition Routine Postcondition 6 6 Basic Idea: Contract-Based s Filter Precondition Routine Postcondition 6 6 Basic Idea: Contract-Based s Filter Precondition Routine Oracle Postcondition 6 6

6 Basic Idea: Contract-Based s Filter Precondition Invariant Routine Oracle Postcondition Invariant 6 6 Basic Idea: Contract-Based s Filter Precondition Invariant Routine Oracle Postcondition Invariant Null-pointer dereference, division by zero, assert, Contracts in Eiffel class BANK_ACCOUNT feature balance: INTEGER... ( INTEGER withdraw (v: (v > 0) and (balance - v >= 0) balance := balance - v balance = old balance - v invariant balance >= 0 7 7

7 Comparison: Unit s class BANK_ACCOUNT feature balance: INTEGER ( INTEGER deposit (v: balance := balance - v class TEST_BANK_ACCOUNT inherit TEST_CASE feature test_deposit local ba: BANK_ACCOUNT create ba ba.deposit (30) ( 30 = (ba.balance assert 8 8 Bank Account Demo class MAIN_WINDOW feature ba: BANK_ACCOUNT f: TEXT_FIELD on_withdraw local v: INTEGER v := f.as_integer ( v ) ba.withdraw 9 9 Contracts and Inheritance C A foo alpha beta 10

8 Contracts and Inheritance C bar (a: A) if a.alpha then a.foo A foo alpha beta 10 Contracts and Inheritance C bar (a: A) if a.alpha then a.foo A foo alpha beta B foo gamma delta 10 Contracts and Inheritance C bar (a: A) if a.alpha then a.foo alpha delta = = gamma beta A foo alpha beta B foo gamma delta 10

9 alpha delta = = gamma beta A foo alpha beta B foo gamma delta foo (n: INTEGER): STRING 11 alpha delta = = gamma beta A foo alpha beta foo (n: INTEGER): STRING n > 10 Result /= Void B foo gamma delta foo (n: INTEGER): STRING 11 alpha delta = = gamma beta alpha n > 10 beta Result /= Void A foo alpha beta foo (n: INTEGER): STRING n > 10 Result /= Void B foo gamma delta foo (n: INTEGER): STRING 11

10 alpha delta = = gamma beta alpha n > 10 beta Result /= Void A foo alpha beta foo (n: INTEGER): STRING n > 10 Result /= Void B foo gamma delta foo (n: INTEGER): STRING else n < -10 then not Result.is_empty foo (n: INTEGER): STRING 11 alpha delta = = gamma beta alpha n > 10 beta Result /= Void A foo alpha beta foo (n: INTEGER): STRING n > 10 Result /= Void B gamma delta (n > 10) or (n < -10) (Result /= Void) and (not Result.is_empty) foo gamma delta foo (n: INTEGER): STRING foo (n: INTEGER): STRING else n < -10 then not Result.is_empty 11 Contracts in Java/JML class BankAccount { protected int balance; // invariant balance >= 0; /*@ s (v > 0) && (balance - v >= s balance == \old(balance) - void withdraw(int v) { balance = balance - v; } /*@ s \result == int getbalance() { return balance; } } 12

11 Contracts in Spec# class BankAccount { protected int Balance; invariant Balance >= 0; void Withdraw(int v) s (v > 0) && (Balance - v >= 0); s Balance == old(balance) - v; { Balance = Balance - v; } int GetBalance() s result == Balance; { return Balance; } } Contracts in.net using System.Diagnostics; class BankAccount { protected int Balance; void Withdraw(int v) { Contract.Requires((v > 0) && (Balanace - v >= 0)); Contract.Ensures(Balance = Contract.OldValue(Balance) - v); Balance = Balance - v; } int GetBalance() { Contract.Ensures(Contract.Result<int>() == Balance); return Balance; } void ObjectInvariant() { Contract.Invariant( Balance >= 0 ); } } void Withdraw(int v) { Contract.Requires((v > 0) && (Balanace - v >= 0)); Contract.Ensures(Balance = Contract.OldValue(Balance) - v); Balance = Balance - v; } Contracts as a Library (?) using System.Diagnost ics; string GetDescription(i nt x) { Contract.Requir Contracts as a Library (?) using System.Diagnost ics; string GetDescription(i nt x) { Contract.Requir Contracts as a Library (?) using System.Diagnost ics; string GetDescription(i nt x) { Contract.Requir

12 void Withdraw(int v) { Contract.Requires((v > 0) && (Balanace - v >= 0)); Contract.Ensures(Balance = Contract.OldValue(Balance) - v); Balance = Balance - v; } Release compile to byte code void Withdraw(int v) { Contract.Requires((v > 0) && (Balanace - v >= 0)); Contract.Ensures(Balance = Contract.OldValue(Balance) - v); Balance = Balance - v; } Release Debug compile to byte code void Withdraw(int v) { Contract.Requires((v > 0) && (Balanace - v >= 0)); Contract.Ensures(Balance = Contract.OldValue(Balance) - v); Balance = Balance - v; } Release Debug compile to byte code rewrite Runtime Checking Contracts as a Library (?) using System.Diagnost ics; string GetDescription(i nt x) { Contract.Requir Contracts as a Library (?) using System.Diagnost ics; string GetDescription(i nt x) { Contract.Requir Contracts as a Library (?) using System.Diagnost ics; string GetDescription(i nt x) { Contract.Requir

13 Extracting s Developer plays with Program observes Extractor Extracting s Developer plays with Program Failure Extractor observes Extracting s Developer plays with Program Failure Cases extracts Extractor observes 16 16

14 Net Capture and Replay File System Database Program (Code + Data) (Code + User Net File System Database Program (Code + Data) (Code + User Capture and Replay Save state periodically Log events Restore state Simulate events Net File System Database Program (Code + Data) (Code + User Capture and Replay Save state periodically Log events Run-time overhead Restore state Simulate events 17 17

15 Net File System Database Program (Code + Data) (Code + User Extraction: Ignores events Several tests per failure No overhead Capture and Replay Save state periodically Log events Run-time overhead Restore state Simulate events Selective Capture and Replay Net File System Database Program Program Subset User (Burger et al., Elbaum et al., Ernst et al., Orso et al. ) State-Based Extraction Heap: Stack: main 19 19

16 State-Based Extraction Heap: Stack: dispatch_events main State-Based Extraction Heap: Stack: dispatch_events main State-Based Extraction Heap: Stack: on_withdraw dispatch_events main 19 19

17 Stack: withdraw on_withdraw dispatch_events main State-Based Extraction Heap: Stack: Failure withdraw on_withdraw dispatch_events main State-Based Extraction Heap: One test per routine: Stack: Failure withdraw on_withdraw dispatch_events main State-Based Extraction Heap: 19 19

18 One test per routine: Stack: Failure withdraw on_withdraw dispatch_events main State-Based Extraction Heap: One test per routine: Stack: Failure withdraw on_withdraw dispatch_events main State-Based Extraction Heap: One test per routine: Stack: Failure withdraw on_withdraw dispatch_events main State-Based Extraction Heap: 19 19

19 One test per routine: Stack: Failure withdraw on_withdraw dispatch_events main State-Based Extraction Heap: State-Based Extraction Extracting a test Executing a test Remember routine Save arguments + state Restore state Invoke routine with arguments When to Save State Invocation state extraction Artzi, et. al (ECOOP, 2008) Save state when routine is invoked Must capture often 21 21

20 When to Save State Invocation state extraction Artzi, et. al (ECOOP, 2008) Save state when routine is invoked Must capture often When to Save State Invocation state extraction Artzi, et. al (ECOOP, 2008) Save state when routine is invoked Must capture often Studied failures from Eclipse, SVNKit,... 10/11 failures reproducible Slowwn: x120 - x When to Save State Invocation state extraction Artzi, et. al (ECOOP, 2008) Failure state extraction Leitner, et. al (ESEC/FSE, 2007) Save state when routine is invoked Must capture often Save state when failure occurs Capture only once s may not reproduce failure 21 21

21 Example I Code ( INTEGER withdraw (v: (v > 0) and (balance - v >= 0) balance := balance + v balance = old balance - v invariant balance >= 0 State v 30 balance Example I Code ( INTEGER withdraw (v: (v > 0) and (balance - v >= 0) balance := balance + v balance = old balance - v invariant balance >= 0 State v 30 balance Example I Code ( INTEGER withdraw (v: (v > 0) and (balance - v >= 0) balance := balance + v balance = old balance - v invariant balance >= 0 State v 30 balance

22 Example I Code ( INTEGER withdraw (v: (v > 0) and (balance - v >= 0) balance := balance + v balance = old balance - v invariant balance >= 0 State v 30 balance Example I Code ( INTEGER withdraw (v: (v > 0) and (balance - v >= 0) balance := balance + v balance = old balance - v invariant balance >= 0 State v balance Example I Code ( INTEGER withdraw (v: (v > 0) and (balance - v >= 0) balance := balance + v balance = old balance - v invariant balance >= 0 State v balance

23 Example I Code State ( INTEGER withdraw (v: (v > 0) and (balance - v >= 0) balance := balance + v balance = old balance - v invariant balance >= 0 22 v balance test ( BANK_ACCOUNT ) ba := create_object ( 330 balance, set_field (ba, ba.withdraw (30) 22 Code Example I Failure state reproduces failure State ( INTEGER withdraw (v: (v > 0) and (balance - v >= 0) balance := balance + v balance = old balance - v invariant balance >= 0 22 v balance test ( BANK_ACCOUNT ) ba := create_object ( 330 balance, set_field (ba, ba.withdraw (30) 22 Example II Code ( INTEGER withdraw (v: v > 0 balance := balance - v balance = old balance - v invariant balance >= 0 State v balance

24 Example II Code ( INTEGER withdraw (v: v > 0 balance := balance - v balance = old balance - v invariant balance >= 0 State v balance Example II Code ( INTEGER withdraw (v: v > 0 balance := balance - v balance = old balance - v invariant balance >= 0 State v balance Example II Code ( INTEGER withdraw (v: v > 0 balance := balance - v balance = old balance - v invariant balance >= 0 State v balance

25 Example II Code ( INTEGER withdraw (v: v > 0 balance := balance - v balance = old balance - v invariant balance >= 0 State v balance Example II Code ( INTEGER withdraw (v: v > 0 balance := balance - v balance = old balance - v invariant balance >= 0 State v balance Example II Code ( INTEGER withdraw (v: v > 0 balance := balance - v balance = old balance - v invariant balance >= 0 State v balance

26 Example II Code State ( INTEGER withdraw (v: v > 0 balance := balance - v balance = old balance - v invariant balance >= 0 23 v balance test ( BANK_ACCOUNT ) ba := create_object ( 20 - balance, set_field (ba, ba.withdraw (30) 23 Example II Failure state esn t reproduce failure Code State ( INTEGER withdraw (v: v > 0 balance := balance - v balance = old balance - v invariant balance >= 0 23 v balance test ( BANK_ACCOUNT ) ba := create_object ( 20 - balance, set_field (ba, ba.withdraw (30) 23 Example III Stack: main 24 24

27 Example III Stack: withdraw (0) on_withdraw dispatch_events main Example III Stack: withdraw (0) on_withdraw dispatch_events main v 0 balance 300 ( INTEGER withdraw (v: v > 0... balance = old balance - v invariant balance > Example III Stack: withdraw (0) on_withdraw dispatch_events main v 0 balance 300 ( INTEGER withdraw (v: v > 0... balance = old balance - v invariant balance >

28 Example III Stack: withdraw (0) on_withdraw dispatch_events main v 0 balance 300 ( INTEGER withdraw (v: v > 0... balance = old balance - v invariant balance > Example III Stack: withdraw (0) on_withdraw dispatch_events main v 0 balance 300 ( INTEGER withdraw (v: v > 0... balance = old balance - v invariant balance > Evaluation Invocation state extraction Slow Effective Failure state extraction Fast Effective? 25 25

29 Setup 59 students, 19 (7) groups (ETH, 6th semester) Developed 2 programs, each: ~3000 lines ~20 classes Setup 59 students, 19 (7) groups (ETH, 6th semester) Developed 2 programs, each: ~3000 lines ~20 classes External events: interactive user interface Setup IDE with built in extractors IDE logged failure info to file Students checked-in logs and source into SVN Students used failure-state extractor We compared it to invocation-state extractor 27 27

30 All failures All failures Not reproducible with failure state All failures Not reproducible with failure state Re-triggered 28 28

31 All failures Not reproducible with failure state From log: Exception type Time Stack trace From SVN: Revision of program Re-triggered Failure State Extraction Failures: 714 Unique Failures: 319 Extracted s: 1664 Reproducing s: 390 (23%) Reproducing Failures: 139 (44%) Failure State Extraction Failures: 714 Unique Failures: 319 (66% contracts) Extracted s: 1664 Reproducing s: 390 (23%) Reproducing Failures: 139 (44%) 29 29

32 Failure State Extraction Failures: 714 Unique Failures: 319 (66% contracts) Extracted s: 1664 Reproducing s: 390 (23%) Reproducing Failures: 139 (44%) Failure State Extraction Failures: 714 Unique Failures: 319 Extracted s: 1664 Reproducing s: 390 (23%) Reproducing Failures: 139 (44%) (66% contracts) Negative bias: 1. Extraction depth-limited 2. A few bugs All failures 30 30

33 All failures Failures from 7 groups 7/9 groups 189 / 319 failures Subset is representative All failures Failures from 7 groups 7/9 groups 189 / 319 failures Subset is representative Not reproducible with depthlimited failure state All failures Failures from 7 groups 7/9 groups 189 / 319 failures Subset is representative Not reproducible with depthlimited failure state 30 Not reproducible with unlimited failure state 30

34 All failures Failures from 7 groups 7/9 groups 189 / 319 failures Subset is representative Re-triggered Not reproducible with depthlimited failure state 30 Not reproducible with unlimited failure state 30 Failure State Extraction depth-limited unlimited Failures: Unique Failures: Extracted s: Reproducing s: 390 (23%) 419 (37%) Reproducing Failures: 139 (44%) 170 (90%) Failure State Extraction depth-limited unlimited Failures: Unique Failures: Extracted s: Reproducing s: 390 (23%) 419 (37%) Reproducing Failures: 139 (44%) 170 (90%) 31 31

35 Failure State Extraction depth-limited unlimited Failures: Unique Failures: Extracted s: Reproducing s: 390 (23%) 419 (37%) Neg. bias Reproducing Failures: 139 (44%) 170 (90%) Failure State Extraction depth-limited unlimited Failures: 714 Failure State Extraction: 410 Unique Failures: zero overhead % effective 189 Extracted s: Reproducing s: 390 (23%) 419 (37%) Neg. bias Reproducing Failures: 139 (44%) 170 (90%) Failure State Extraction depth-limited unlimited Failures: 714 Failure State Extraction: 410 Unique Failures: zero overhead % effective 189 Extracted s: Reproducing Invocation s: 390 State (23%) Extraction? 419 (37%) Neg. bias Reproducing Failures: 139 (44%) 170 (90%) 31 31

36 Invocation State Extraction Compared Failure State Extraction Invocation State Extraction Unique Failures: Reproducing Failures: 170 (90%) 177 (94%) Invocation State Extraction Compared Failure State Extraction Invocation State Extraction Unique Failures: Reproducing Failures: 170 (90%) 177 (94%) Only 4% more Invocation State Extraction Compared Failure State Extraction Invocation State Extraction Unique Failures: Reproducing Failures: 170 (90%) 177 (94%) Only 4% more Remaining 12 failures (6%) unknown 32 32

37 Failure Reproducibility Zero overhead % 94% 150 Reproducible by failure state extraction Reproducible by invocation state extraction 33 6% Unknown Unique Failures 33 Second Chance Reduces overhead of invocation-state extraction Requires failures to occur two times Artzi et. al (ECOOP, 2008) w raw ents Second Chance Initially save no states Failure occurs, mark routines on stack (n t extract tests yet) From now, save state when a marked routine is invoked If same failure occurs again, extract tests with saved state Artzi et. al (ECOOP, 2008) 35 35

38 Stack: withdraw on_withdraw dispatch_events main Heap: Second Chance Initially save no states Failure occurs, mark routines on stack (n t extract tests yet) From now, save state when a marked routine is invoked If same failure occurs again, extract tests with saved state Artzi et. al (ECOOP, 2008) Stack: withdraw on_withdraw dispatch_events main Heap: Second Chance Initially save no states Failure occurs, mark routines on stack Reduction (n t extract tests yet) From now, save From: state x120 when - x638a marked To: x1 - x474 routine is invoked If same failure occurs again, extract tests with saved state Artzi et. al (ECOOP, 2008) Failure State Extraction + Second Chance Failure occurs, extract with failure state If reproducing, ne Otherwise, mark routines on stack From now, save state when a marked routine is invoked When failure occurs, use invocation state if available, fall back to failure-state otherwise 36 36

39 Failure State Extraction + Second Chance Failure occurs, extract with failure state If reproducing, ne Otherwise, Zero overhead mark for routines most failures, on stack some for remaining ones From now, save state when a marked routine is invoked When failure occurs, use invocation state if available, fall back to failure-state otherwise Field vs. Development CDD EiffelStudio - For use during development. Needs debugger. Program unchanged. ReCrash (Artzi) - Java. For use in field. Instruments program. 37 Extracting Developer plays with Program Cases extracts Extractor observes 38 38

40 plays with Developer extracts Cases Program observes Extractor Extracting Heap: Stack: withdraw on_withdraw dispatch_events main plays with Developer extracts Cases Program observes Extractor Extracting Stack: withdraw on_withdraw dispatch_events main Heap: Failure state extraction Effective (90%), no overhead plays with Developer extracts Cases Program observes Extractor Extracting Stack: withdraw on_withdraw dispatch_events main Heap: Failure state extraction Invocation state extraction Effective (90%), no overhead Effective (94%), slow 38 38

41 plays with Developer extracts Cases Program observes Extractor Extracting Stack: withdraw on_withdraw dispatch_events main Heap: Failure state extraction Effective (90%), no overhead Invocation state extraction Effective (94%), slow Failure state extraction + second chance Effective (94%), overhead for 10% only Create New s Program Case generates is fed to Generator Ranm Generation tool auto_test system under test system.ecf 1 v_1 := Void 2 create {ANY} v_2 3 create {TWO_WAY_TREE [ANY]} v_3.make (v_2) 20 create {BINARY_TREE [ANY]} v_61.make (v_44) 21 v_61. forget_right 22 create {PRIMES} v_62 23 v_63 := v_62.is_prime (7) 24 v_64 := v_62.lower_prime ({INTEGER_32} 2) 25 create {DATE_DURATION} v_65. make_by_days ({INTEGER_32} 3) 31 v_133 := v_132.mirrored 32 create {ARRAY2 [ANY]} v_134.make ({INTEGER_32} 7, {INTEGER_32} 6) 33 v_134.enter (v_45, v_131) 34 create {RANDOM} v_135.set_seed (v_64) 35 v_136 := v_135. real_item 40 40

42 Ranm Generation tool auto_test system under test system.ecf 1 v_1 := Void 2 create {ANY} v_2 3 create {TWO_WAY_TREE [ANY]} v_3.make (v_2) 20 create {BINARY_TREE [ANY]} v_61.make (v_44) 21 v_61. forget_right 22 create {PRIMES} v_62 23 v_63 := v_62.is_prime (7) 24 v_64 := v_62.lower_prime ({INTEGER_32} 2) 25 create {DATE_DURATION} v_65. make_by_days ({INTEGER_32} 3) 31 v_133 := v_132.mirrored 32 create {ARRAY2 [ANY]} v_134.make ({INTEGER_32} 7, {INTEGER_32} 6) 33 v_134.enter (v_45, v_131) 34 create {RANDOM} v_135.set_seed (v_64) 35 v_136 := v_135. real_item Predictability of Ranm ing Experiment 27 classes from EiffelBase 1215 hours (50.6 days) of testing time 6 million failures (Ciupa et al.) 41 Predictability of Ranm ing In terms of the relative number of detected faults, ranm testing is predictable. In terms of the actual detected faults, ranm testing is rather unpredictable. (Ciupa et al.) 42

43 New faults found per time unit - inversely proportional to elapsed time Performance of Ranm ing Experiment: 1500 hours of testing 8 classes (Ciupa et al.) 43 New faults found per time unit - inversely proportional to elapsed time Performance of Ranm ing Experiment: 1500 hours of testing 8 classes (Ciupa et al.) 62% are specification faults 43 Ranm s: Long 1 v_1 := Void 2 create {ANY} v_2 3 create {TWO_WAY_TREE [ANY]} v_3.make (v_2) 20 create {BINARY_TREE [ANY]} v_61.make (v_44) 21 v_61. forget_right 22 create {PRIMES} v_62 23 v_63 := v_62.is_prime (7) 24 v_64 := v_62.lower_prime ({INTEGER_32} 2) 25 create {DATE_DURATION} v_65. make_by_days ({INTEGER_32} 3) 31 v_133 := v_132.mirrored 32 create {ARRAY2 [ANY]} v_134.make ({INTEGER_32} 7, {INTEGER_32} 6) 33 v_134.enter (v_45, v_131) 34 create {RANDOM} v_135.set_seed (v_64) 35 v_136 := v_135. real_item 44 44

44 Ranm s: Long 1 v_1 := Void 2 create {ANY} v_2 3 create {TWO_WAY_TREE [ANY]} v_3.make (v_2) 20 create {BINARY_TREE [ANY]} v_61.make (v_44) 21 v_61. forget_right 22 create {PRIMES} v_62 23 v_63 := v_62.is_prime (7) 24 v_64 := v_62.lower_prime ({INTEGER_32} 2) 25 create {DATE_DURATION} v_65. make_by_days ({INTEGER_32} 3) 31 v_133 := v_132.mirrored 32 create {ARRAY2 [ANY]} v_134.make ({INTEGER_32} 7, {INTEGER_32} 6) 33 v_134.enter (v_45, v_131) 34 create {RANDOM} v_135.set_seed (v_64) 35 v_136 := v_135. real_item Ranm s: Long Difficult to understand 1 v_1 := Void 2 create {ANY} v_2 3 create {TWO_WAY_TREE Take long [ANY]} to v_3.make execute (v_2) 20 create {BINARY_TREE [ANY]} v_61.make (v_44) 21 v_61. forget_right 22 create {PRIMES} v_62 23 v_63 := v_62.is_prime (7) 24 v_64 := v_62.lower_prime ({INTEGER_32} 2) 25 create {DATE_DURATION} v_65. make_by_days ({INTEGER_32} 3) 31 v_133 := v_132.mirrored 32 create {ARRAY2 [ANY]} v_134.make ({INTEGER_32} 7, {INTEGER_32} 6) 33 v_134.enter (v_45, v_131) 34 create {RANDOM} v_135.set_seed (v_64) 35 v_136 := v_135. real_item Minimization Program Case generates is fed to Generator 45 45

45 Minimization (smaller) Case generates Minimizer Program is fed to is fed to Case generates Generator Delta Debugging 1 v_1 := Void 2 create {ANY} v_2 3 create {TWO_WAY_TREE [ANY]} v_3.make (v_2) 20 create {BINARY_TREE [ANY]} v_61.make (v_44) 21 v_61. forget_right 22 create {PRIMES} v_62 23 v_63 := v_62.is_prime (7) 24 v_64 := v_62.lower_prime ({INTEGER_32} 2) 25 create {DATE_DURATION} v_65. make_by_days ({INTEGER_32} 3) 31 v_133 := v_132.mirrored 32 create {ARRAY2 [ANY]} v_134.make ({INTEGER_32} 7, {INTEGER_32} 6) 33 v_134.enter (v_45, v_131) 34 create {RANDOM} v_135.set_seed (v_64) 35 v_136 := v_135. real_item 46 Zeller, Hildebrandt (2002) Lei, Andrews (2005) 46 Delta Debugging 1 v_1 := Void 2 create {ANY} v_2 3 create {TWO_WAY_TREE [ANY]} v_3.make (v_2) 20 create {BINARY_TREE [ANY]} v_61.make (v_44) 21 v_61. forget_right 22 create {PRIMES} v_62 23 v_63 := v_62.is_prime (7) 24 v_64 := v_62.lower_prime ({INTEGER_32} 2) 25 create {DATE_DURATION} v_65. make_by_days ({INTEGER_32} 3) 31 v_133 := v_132.mirrored 32 create {ARRAY2 [ANY]} v_134.make ({INTEGER_32} 7, {INTEGER_32} 6) 33 v_134.enter (v_45, v_131) 34 create {RANDOM} v_135.set_seed (v_64) 35 v_136 := v_135. real_item 46 Zeller, Hildebrandt (2002) Lei, Andrews (2005) 46

46 Delta Debugging 1 v_1 := Void 2 create {ANY} v_2 3 create {TWO_WAY_TREE [ANY]} v_3.make (v_2) 20 create {BINARY_TREE [ANY]} v_61.make (v_44) 21 v_61. forget_right 22 create {PRIMES} v_62 23 v_63 := v_62.is_prime (7) 24 v_64 := v_62.lower_prime ({INTEGER_32} 2) 25 create {DATE_DURATION} v_65. make_by_days ({INTEGER_32} 3) 31 v_133 := v_132.mirrored 32 create {ARRAY2 [ANY]} v_134.make ({INTEGER_32} 7, {INTEGER_32} 6) 33 v_134.enter (v_45, v_131) 34 create {RANDOM} v_135.set_seed (v_64) 35 v_136 := v_135. real_item 46 Zeller, Hildebrandt (2002) Lei, Andrews (2005) 46 Delta Debugging 1 v_1 := Void 2 create {ANY} v_2 3 create {TWO_WAY_TREE [ANY]} v_3.make (v_2) 20 create {BINARY_TREE [ANY]} v_61.make (v_44) 21 v_61. forget_right 22 create {PRIMES} v_62 23 v_63 := v_62.is_prime (7) 24 v_64 := v_62.lower_prime ({INTEGER_32} 2) 25 create {DATE_DURATION} v_65. make_by_days ({INTEGER_32} 3) 31 v_133 := v_132.mirrored 32 create {ARRAY2 [ANY]} v_134.make ({INTEGER_32} 7, {INTEGER_32} 6) 33 v_134.enter (v_45, v_131) 34 create {RANDOM} v_135.set_seed (v_64) 35 v_136 := v_135. real_item 46 Zeller, Hildebrandt (2002) Lei, Andrews (2005) 46 Delta Debugging 1 v_1 := Void 2 create {ANY} v_2 3 create {TWO_WAY_TREE [ANY]} v_3.make (v_2) 20 create {BINARY_TREE [ANY]} v_61.make (v_44) 21 v_61. forget_right 22 create {PRIMES} v_62 23 v_63 := v_62.is_prime (7) 24 v_64 := v_62.lower_prime ({INTEGER_32} 2) 25 create {DATE_DURATION} v_65. make_by_days ({INTEGER_32} 3) 31 v_133 := v_132.mirrored 32 create {ARRAY2 [ANY]} v_134.make ({INTEGER_32} 7, {INTEGER_32} 6) 33 v_134.enter (v_45, v_131) 34 create {RANDOM} v_135.set_seed (v_64) 35 v_136 := v_135. real_item 46 Zeller, Hildebrandt (2002) Lei, Andrews (2005) 46

47 Delta Debugging 1 v_1 := Void 2 create {ANY} v_2 3 create {TWO_WAY_TREE [ANY]} v_3.make (v_2) 20 create {BINARY_TREE [ANY]} v_61.make (v_44) 21 v_61. forget_right 22 create {PRIMES} v_62 23 v_63 := v_62.is_prime (7) 24 v_64 := v_62.lower_prime ({INTEGER_32} 2) 25 create {DATE_DURATION} v_65. make_by_days ({INTEGER_32} 3) 31 v_133 := v_132.mirrored 32 create {ARRAY2 [ANY]} v_134.make ({INTEGER_32} 7, {INTEGER_32} 6) 33 v_134.enter (v_45, v_131) 34 create {RANDOM} v_135.set_seed (v_64) 35 v_136 := v_135. real_item 46 Zeller, Hildebrandt (2002) Lei, Andrews (2005) 46 Faster Minimization (original) Suite (smaller) Suite Slicer (static) Ddmin (dynamic) Slicing Algorithm What slice of the program affects instruction i? What variables es i read? What statements write to these variables? What variables these statements read? (recurse) 48 48

48 What es i read? Assignment v7 := v3 source Object creation create {FOO} v2 (v1) arguments Method invocation v3.bar (v1, v2) target + arguments What es i write? Assignment v7 := v3 receiver Object creation create {FOO} v2 (v1) target Method invocation v3.bar (v1, v2) target Slicing 1 v_1 := Void 2 create {ANY} v_2 3 create {TWO_WAY_TREE [ANY]} v_3.make (v_2) 20 create {BINARY_TREE [ANY]} v_61.make (v_44) 21 v_61. forget_right 22 create {PRIMES} v_62 23 v_63 := v_62.is_prime (7) 24 v_64 := v_62.lower_prime ({INTEGER_32} 2) 25 create {DATE_DURATION} v_65. make_by_days ({INTEGER_32} 3) 31 v_133 := v_132.mirrored 32 create {ARRAY2 [ANY]} v_134.make ({INTEGER_32} 7, {INTEGER_32} 6) 33 v_134.enter (v_45, v_131) 34 create {RANDOM} v_135.set_seed (v_64) 35 v_136 := v_135. real_item 51 51

49 Slicing 1 v_1 := Void 2 create {ANY} v_2 3 create {TWO_WAY_TREE [ANY]} v_3.make (v_2) 20 create {BINARY_TREE [ANY]} v_61.make (v_44) 21 v_61. forget_right 22 create {PRIMES} v_62 23 v_63 := v_62.is_prime (7) 24 v_64 := v_62.lower_prime ({INTEGER_32} 2) 25 create {DATE_DURATION} v_65. make_by_days ({INTEGER_32} 3) 31 v_133 := v_132.mirrored 32 create {ARRAY2 [ANY]} v_134.make ({INTEGER_32} 7, {INTEGER_32} 6) 33 v_134.enter (v_45, v_131) 34 create {RANDOM} v_135.set_seed (v_64) 35 v_136 := v_135. real_item Slicing v_135 1 v_1 := Void 2 create {ANY} v_2 3 create {TWO_WAY_TREE [ANY]} v_3.make (v_2) 20 create {BINARY_TREE [ANY]} v_61.make (v_44) 21 v_61. forget_right 22 create {PRIMES} v_62 23 v_63 := v_62.is_prime (7) 24 v_64 := v_62.lower_prime ({INTEGER_32} 2) 25 create {DATE_DURATION} v_65. make_by_days ({INTEGER_32} 3) 31 v_133 := v_132.mirrored 32 create {ARRAY2 [ANY]} v_134.make ({INTEGER_32} 7, {INTEGER_32} 6) 33 v_134.enter (v_45, v_131) 34 create {RANDOM} v_135.set_seed (v_64) 35 v_136 := v_135. real_item Slicing v_135 1 v_1 := Void 2 create {ANY} v_2 3 create {TWO_WAY_TREE [ANY]} v_3.make (v_2) 20 create {BINARY_TREE [ANY]} v_61.make (v_44) 21 v_61. forget_right 22 create {PRIMES} v_62 23 v_63 := v_62.is_prime (7) 24 v_64 := v_62.lower_prime ({INTEGER_32} 2) 25 create {DATE_DURATION} v_65. make_by_days ({INTEGER_32} 3) 31 v_133 := v_132.mirrored 32 create {ARRAY2 [ANY]} v_134.make ({INTEGER_32} 7, {INTEGER_32} 6) 33 v_134.enter (v_45, v_131) 34 create {RANDOM} v_135.set_seed (v_64) 35 v_136 := v_135. real_item 51 51

50 Slicing v_135 v_64 1 v_1 := Void 2 create {ANY} v_2 3 create {TWO_WAY_TREE [ANY]} v_3.make (v_2) 20 create {BINARY_TREE [ANY]} v_61.make (v_44) 21 v_61. forget_right 22 create {PRIMES} v_62 23 v_63 := v_62.is_prime (7) 24 v_64 := v_62.lower_prime ({INTEGER_32} 2) 25 create {DATE_DURATION} v_65. make_by_days ({INTEGER_32} 3) 31 v_133 := v_132.mirrored 32 create {ARRAY2 [ANY]} v_134.make ({INTEGER_32} 7, {INTEGER_32} 6) 33 v_134.enter (v_45, v_131) 34 create {RANDOM} v_135.set_seed (v_64) 35 v_136 := v_135. real_item Slicing v_64 1 v_1 := Void 2 create {ANY} v_2 3 create {TWO_WAY_TREE [ANY]} v_3.make (v_2) 20 create {BINARY_TREE [ANY]} v_61.make (v_44) 21 v_61. forget_right 22 create {PRIMES} v_62 23 v_63 := v_62.is_prime (7) 24 v_64 := v_62.lower_prime ({INTEGER_32} 2) 25 create {DATE_DURATION} v_65. make_by_days ({INTEGER_32} 3) 31 v_133 := v_132.mirrored 32 create {ARRAY2 [ANY]} v_134.make ({INTEGER_32} 7, {INTEGER_32} 6) 33 v_134.enter (v_45, v_131) 34 create {RANDOM} v_135.set_seed (v_64) 35 v_136 := v_135. real_item Slicing v_64 1 v_1 := Void 2 create {ANY} v_2 3 create {TWO_WAY_TREE [ANY]} v_3.make (v_2) 20 create {BINARY_TREE [ANY]} v_61.make (v_44) 21 v_61. forget_right 22 create {PRIMES} v_62 23 v_63 := v_62.is_prime (7) 24 v_64 := v_62.lower_prime ({INTEGER_32} 2) 25 create {DATE_DURATION} v_65. make_by_days ({INTEGER_32} 3) 31 v_133 := v_132.mirrored 32 create {ARRAY2 [ANY]} v_134.make ({INTEGER_32} 7, {INTEGER_32} 6) 33 v_134.enter (v_45, v_131) 34 create {RANDOM} v_135.set_seed (v_64) 35 v_136 := v_135. real_item 51 51

51 Slicing v_64 v_62 1 v_1 := Void 2 create {ANY} v_2 3 create {TWO_WAY_TREE [ANY]} v_3.make (v_2) 20 create {BINARY_TREE [ANY]} v_61.make (v_44) 21 v_61. forget_right 22 create {PRIMES} v_62 23 v_63 := v_62.is_prime (7) 24 v_64 := v_62.lower_prime ({INTEGER_32} 2) 25 create {DATE_DURATION} v_65. make_by_days ({INTEGER_32} 3) 31 v_133 := v_132.mirrored 32 create {ARRAY2 [ANY]} v_134.make ({INTEGER_32} 7, {INTEGER_32} 6) 33 v_134.enter (v_45, v_131) 34 create {RANDOM} v_135.set_seed (v_64) 35 v_136 := v_135. real_item Slicing v_62 1 v_1 := Void 2 create {ANY} v_2 3 create {TWO_WAY_TREE [ANY]} v_3.make (v_2) 20 create {BINARY_TREE [ANY]} v_61.make (v_44) 21 v_61. forget_right 22 create {PRIMES} v_62 23 v_63 := v_62.is_prime (7) 24 v_64 := v_62.lower_prime ({INTEGER_32} 2) 25 create {DATE_DURATION} v_65. make_by_days ({INTEGER_32} 3) 31 v_133 := v_132.mirrored 32 create {ARRAY2 [ANY]} v_134.make ({INTEGER_32} 7, {INTEGER_32} 6) 33 v_134.enter (v_45, v_131) 34 create {RANDOM} v_135.set_seed (v_64) 35 v_136 := v_135. real_item Slicing v_62 1 v_1 := Void 2 create {ANY} v_2 3 create {TWO_WAY_TREE [ANY]} v_3.make (v_2) 20 create {BINARY_TREE [ANY]} v_61.make (v_44) 21 v_61. forget_right 22 create {PRIMES} v_62 23 v_63 := v_62.is_prime (7) 24 v_64 := v_62.lower_prime ({INTEGER_32} 2) 25 create {DATE_DURATION} v_65. make_by_days ({INTEGER_32} 3) 31 v_133 := v_132.mirrored 32 create {ARRAY2 [ANY]} v_134.make ({INTEGER_32} 7, {INTEGER_32} 6) 33 v_134.enter (v_45, v_131) 34 create {RANDOM} v_135.set_seed (v_64) 35 v_136 := v_135. real_item 51 51

52 Slicing v_62 1 v_1 := Void 2 create {ANY} v_2 3 create {TWO_WAY_TREE [ANY]} v_3.make (v_2) 20 create {BINARY_TREE [ANY]} v_61.make (v_44) 21 v_61. forget_right 22 create {PRIMES} v_62 23 v_63 := v_62.is_prime (7) 24 v_64 := v_62.lower_prime ({INTEGER_32} 2) 25 create {DATE_DURATION} v_65. make_by_days ({INTEGER_32} 3) 31 v_133 := v_132.mirrored 32 create {ARRAY2 [ANY]} v_134.make ({INTEGER_32} 7, {INTEGER_32} 6) 33 v_134.enter (v_45, v_131) 34 create {RANDOM} v_135.set_seed (v_64) 35 v_136 := v_135. real_item Slicing 1 v_1 := Void 2 create {ANY} v_2 3 create {TWO_WAY_TREE [ANY]} v_3.make (v_2) 20 create {BINARY_TREE [ANY]} v_61.make (v_44) 21 v_61. forget_right 22 create {PRIMES} v_62 23 v_63 := v_62.is_prime (7) 24 v_64 := v_62.lower_prime ({INTEGER_32} 2) 25 create {DATE_DURATION} v_65. make_by_days ({INTEGER_32} 3) 31 v_133 := v_132.mirrored 32 create {ARRAY2 [ANY]} v_134.make ({INTEGER_32} 7, {INTEGER_32} 6) 33 v_134.enter (v_45, v_131) 34 create {RANDOM} v_135.set_seed (v_64) 35 v_136 := v_135. real_item Unsound, but Fast No control flow in test case Does not look at subroutine calls May cut out relevant instructions May include irrelevant instructions execution necessary to filter invalid minimization But it is fast! 52 52

53 Unsound, but Fast No control flow in test case Does not look at subroutine calls May cut out relevant instructions May include irrelevant instructions execution necessary to filter invalid minimization But it is fast! Linear in instructions Constant in executions How much faster? Avg. Instructions / Case (inst.) 35,29 original 1,62 slicing 1,42 ddmin 1,42 slicing+ ddmin How much faster? Avg. Instructions / Case (inst.) Time for activities (min) 35,29 77,4 original 1,62 slicing 1,42 ddmin 1,42 slicing+ ddmin 53 20,0 testing ddmin 1,5 6,8 slicing slicing+ ddmin 53

54 How much faster? Avg. Instructions / Case (inst.) Time for activities (min) 35,29 reduced by 96% 77,4 original 1,62 slicing 1,42 ddmin 1,42 slicing+ ddmin 53 20,0 testing ddmin 1,5 6,8 slicing slicing+ ddmin 53 How much faster? Avg. Instructions / Case (inst.) Time for activities (min) 35,29 original reduced by 96% 1,62 slicing 1,42 ddmin 1,42 slicing+ ddmin 53 20,0 testing 77,4 ddmin x 50 1,5 6,8 slicing slicing+ ddmin 53 How much faster? Avg. Instructions / Case (inst.) Time for activities (min) 35,29 original reduced by 96% 1,62 slicing 1,42 ddmin 1,42 slicing+ ddmin 53 20,0 testing 77,4 ddmin x 50 x 11 1,5 6,8 slicing slicing+ ddmin 53

55 How much faster? Avg. Instructions / Case (inst.) Time for activities (min) 35,29 original reduced by 96% 1,62 slicing 1,42 ddmin 1,42 slicing+ ddmin 53 20,0 testing 77,4 ddmin Slicing pays off: 1st re-exectution Slicing+ddmin: ~30 re-executions x 50 x 11 1,5 6,8 slicing slicing+ ddmin 53 Create New s: Summary (smaller) Suite generates Minimizer Program Suite is fed to generates is fed to Generator (smaller) Suite generates Minimizer Suite Create New s: Program is fed to Summary is fed to generates Generator Automated ranm testing finds many bugs Generated tests are large Minimization through delta debugging effective, but slow Slicing x50 faster, comparable results Slicing + delta debugging as effective, x11 faster 54 54

Assertions. Assertions - Example

Assertions. Assertions - Example References: internet notes; Bertrand Meyer, Object-Oriented Software Construction; 11/13/2003 1 Assertions Statements about input to a routine or state of a class Have two primary roles As documentation,

More information

Replaying and Isolating Failing Multi-Object Interactions. Martin Burger Andreas Zeller Saarland University

Replaying and Isolating Failing Multi-Object Interactions. Martin Burger Andreas Zeller Saarland University Replaying and Isolating Failing Multi-Object Interactions Martin Burger Andreas Zeller Saarland University e-mail client written in Java 100,200 LOC ~ 1,600 Java classes 17 developers Actively developed

More information

References: internet notes; Bertrand Meyer, Object-Oriented Software Construction; 10/14/2004 1

References: internet notes; Bertrand Meyer, Object-Oriented Software Construction; 10/14/2004 1 References: internet notes; Bertrand Meyer, Object-Oriented Software Construction; 10/14/2004 1 Assertions Statements about input to a routine or state of a class Have two primary roles As documentation,

More information

Automatic Verification of Computer Programs

Automatic Verification of Computer Programs Chair of Software Engineering Automatic Verification of Computer Programs these slides contain advanced material and are optional What is verification Check correctness of the implementation given the

More information

Reasoning about programs

Reasoning about programs Reasoning about programs Last time Coming up This Thursday, Nov 30: 4 th in-class exercise sign up for group on moodle bring laptop to class Final projects: final project presentations: Tue Dec 12, in

More information

Last time. Reasoning about programs. Coming up. Project Final Presentations. This Thursday, Nov 30: 4 th in-class exercise

Last time. Reasoning about programs. Coming up. Project Final Presentations. This Thursday, Nov 30: 4 th in-class exercise Last time Reasoning about programs Coming up This Thursday, Nov 30: 4 th in-class exercise sign up for group on moodle bring laptop to class Final projects: final project presentations: Tue Dec 12, in

More information

Assertions, pre/postconditions

Assertions, pre/postconditions Programming as a contract Assertions, pre/postconditions Assertions: Section 4.2 in Savitch (p. 239) Specifying what each method does q Specify it in a comment before method's header Precondition q What

More information

Automatic Testing Based on Design by Contract

Automatic Testing Based on Design by Contract Automatic Testing Based on Design by Contract Ilinca Ciupa Andreas Leitner, ETH Zürich (Swiss Federal Institute of Technology Zurich) SOQUA Developer Track 2005 September 22, 2005 The important things

More information

Introduction to Eiffel

Introduction to Eiffel Introduction to Eiffel Martin Nordio, Christian Estler ETH Zurich Distributed Software Engineering Lab 1 Overview Part 1: Language Constructs Ø Basics: definition, if then else, expressions, loops and

More information

Programming with Contracts. Juan Pablo Galeotti, Alessandra Gorla Saarland University, Germany

Programming with Contracts. Juan Pablo Galeotti, Alessandra Gorla Saarland University, Germany Programming with Contracts Juan Pablo Galeotti, Alessandra Gorla Saarland University, Germany Contract A (formal) agreement between Method M (callee) Callers of M Rights Responsabilities Rights Responsabilities

More information

What This Course Is About Design-by-Contract (DbC)

What This Course Is About Design-by-Contract (DbC) What This Course Is About Design-by-Contract (DbC) Readings: OOSC2 Chapter 11 EECS3311 A: Software Design Fall 2018 CHEN-WEI WANG Focus is design Architecture: (many) inter-related modules Specification:

More information

17. Assertions. Outline. Built-in tests. Built-in tests 3/29/11. Jelle Slowack, Bart Smets, Glenn Van Loon, Tom Verheyen

17. Assertions. Outline. Built-in tests. Built-in tests 3/29/11. Jelle Slowack, Bart Smets, Glenn Van Loon, Tom Verheyen 17. Assertions Jelle Slowack, Bart Smets, Glenn Van Loon, Tom Verheyen Outline Introduction (BIT, assertion, executable assertion, why?) Implementation-based vs responsability-based assertions Implementation

More information

System Software Assignment 1 Runtime Support for Procedures

System Software Assignment 1 Runtime Support for Procedures System Software Assignment 1 Runtime Support for Procedures Exercise 1: Nested procedures Some programming languages like Oberon and Pascal support nested procedures. 1. Find a run-time structure for such

More information

Advances in Programming Languages

Advances in Programming Languages O T Y H Advances in Programming Languages APL8: ESC/Java2 David Aspinall (including slides by Ian Stark and material adapted from ESC/Java2 tutorial by David Cok, Joe Kiniry and Erik Poll) School of Informatics

More information

Test-Driven Development (TDD)

Test-Driven Development (TDD) Test-Driven Development (TDD) EECS3311 A: Software Design Fall 2018 CHEN-WEI WANG DbC: Supplier DbC is supported natively in Eiffel for supplier: class ACCOUNT create make feature -- Attributes owner :

More information

EiffelStudio the Eiffel IDE

EiffelStudio the Eiffel IDE EiffelStudio the Eiffel IDE Christian Estler ETH Zurich christian.estler@inf.ethz.ch Distributed and Outsourced Software Engineering - ETH course, Fall 2012 1 EiffelStudio an Overview EiffelStudio (ES)

More information

Softwaretechnik. Lecture 08: Testing and Debugging Overview. Peter Thiemann SS University of Freiburg, Germany

Softwaretechnik. Lecture 08: Testing and Debugging Overview. Peter Thiemann SS University of Freiburg, Germany Softwaretechnik Lecture 08: Testing and Debugging Overview Peter Thiemann University of Freiburg, Germany SS 2012 Literature Essential Reading Why Programs Fail: A Guide to Systematic Debugging, A Zeller

More information

Softwaretechnik. Lecture 08: Testing and Debugging Overview. Peter Thiemann SS University of Freiburg, Germany

Softwaretechnik. Lecture 08: Testing and Debugging Overview. Peter Thiemann SS University of Freiburg, Germany Softwaretechnik Lecture 08: Testing and Debugging Overview Peter Thiemann University of Freiburg, Germany SS 2012 Literature Essential Reading Why Programs Fail: A Guide to Systematic Debugging, A Zeller

More information

17. Assertions. Jelle Slowack, Bart Smets, Glenn Van Loon, Tom Verheyen

17. Assertions. Jelle Slowack, Bart Smets, Glenn Van Loon, Tom Verheyen 17. Assertions Jelle Slowack, Bart Smets, Glenn Van Loon, Tom Verheyen Outline Introduction (BIT, assertion, executable assertion, why?) Implementation-based vs responsability-based assertions Implementation

More information

Integrating verification in programming languages

Integrating verification in programming languages Integrating verification in programming languages Thomas Jensen, INRIA Seminar INRIA Rennes, 04/11/2015 Collège de France Chaire Algorithmes, machines et langages x / y Types For division to make sense,

More information

JML tool-supported specification for Java Erik Poll Radboud University Nijmegen

JML tool-supported specification for Java Erik Poll Radboud University Nijmegen JML tool-supported specification for Java Erik Poll Radboud University Nijmegen Erik Poll - JML p.1/41 Overview The specification language JML Tools for JML, in particular runtime assertion checking using

More information

Lecture 10 Design by Contract

Lecture 10 Design by Contract CS 5959 Writing Solid Code Fall 2015 Nov-23 Lecture 10 Design by Contract Zvonimir Rakamarić University of Utah Design by Contract Also called assume-guarantee reasoning Developers annotate software components

More information

Catching Defects: Design or Implementation Phase? Design-by-Contract (Dbc) Test-Driven Development (TDD) Motivation of this Course

Catching Defects: Design or Implementation Phase? Design-by-Contract (Dbc) Test-Driven Development (TDD) Motivation of this Course Design-by-Contract (Dbc) Test-Driven Development (TDD) Readings: OOSC2 Chapter 11 Catching Defects: Design or Implementation Phase? To minimize development costs, minimize software defects. The cost of

More information

Binding and Storage. COMP 524: Programming Language Concepts Björn B. Brandenburg. The University of North Carolina at Chapel Hill

Binding and Storage. COMP 524: Programming Language Concepts Björn B. Brandenburg. The University of North Carolina at Chapel Hill Binding and Storage Björn B. Brandenburg The University of North Carolina at Chapel Hill Based in part on slides and notes by S. Olivier, A. Block, N. Fisher, F. Hernandez-Campos, and D. Stotts. What s

More information

Java: advanced object-oriented features

Java: advanced object-oriented features Chair of Software Engineering Carlo A. Furia, Marco Piccioni, Bertrand Meyer Java: advanced object-oriented features Chair of Software Engineering Carlo A. Furia, Marco Piccioni, Bertrand Meyer Packages

More information

Automated Fixing of Programs with Contracts

Automated Fixing of Programs with Contracts Automated Fixing of Programs with Contracts Yi Wei, Yu Pei, Carlo A. Furia, Lucas S. Silva, Stefan Buchholz, Bertrand Meyer and Andreas Zeller Chair of Software Engineering, ETH Zürich Software Engineering

More information

Static program checking and verification

Static program checking and verification Chair of Software Engineering Software Engineering Prof. Dr. Bertrand Meyer March 2007 June 2007 Slides: Based on KSE06 With kind permission of Peter Müller Static program checking and verification Correctness

More information

Eiffel as a Framework for Verification

Eiffel as a Framework for Verification Eiffel as a Framework for Verification Bertrand Meyer ETH Zurich http://se.inf.ethz.ch Eiffel Software www.eiffel.com Abstract. The Eiffel method and language integrate a number of ideas originating from

More information

MSO Lecture Design by Contract"

MSO Lecture Design by Contract 1 MSO Lecture Design by Contract" Wouter Swierstra (adapted by HP, AL) October 8, 2018 2 MSO SO FAR Recap Abstract Classes UP & Requirements Analysis & UML OO & GRASP principles Design Patterns (Facade,

More information

Design-by-Contract (Dbc) Test-Driven Development (TDD)

Design-by-Contract (Dbc) Test-Driven Development (TDD) Design-by-Contract (Dbc) Test-Driven Development (TDD) Readings: OOSC2 Chapter 11 EECS3311: Software Design Fall 2017 CHEN-WEI WANG Terminology: Contract, Client, Supplier A supplier implements/provides

More information

System Assertions. Your Submissions. Oral Exams FEBRUARY FEBRUARY FEBRUARY

System Assertions. Your Submissions. Oral Exams FEBRUARY FEBRUARY FEBRUARY System Assertions Andreas Zeller 1 Your Submissions Program must behave exactly as specified (i.e., input, output, flags, etc.) Program must use recent Python 2 version (i.e., Python 2.6 installed in CIP

More information

Object Oriented Programming: In this course we began an introduction to programming from an object-oriented approach.

Object Oriented Programming: In this course we began an introduction to programming from an object-oriented approach. CMSC 131: Chapter 28 Final Review: What you learned this semester The Big Picture Object Oriented Programming: In this course we began an introduction to programming from an object-oriented approach. Java

More information

C#: advanced object-oriented features

C#: advanced object-oriented features Chair of Software Engineering Carlo A. Furia, Marco Piccioni, Bertrand Meyer C#: advanced object-oriented features Chair of Software Engineering Carlo A. Furia, Marco Piccioni, Bertrand Meyer Namespaces

More information

hwu-logo.png 1 class Rational { 2 int numerator ; int denominator ; 4 public Rational ( int numerator, int denominator ) {

hwu-logo.png 1 class Rational { 2 int numerator ; int denominator ; 4 public Rational ( int numerator, int denominator ) { Code Contracts in C# Hans-Wolfgang Loidl School of Mathematical and Computer Sciences, Heriot-Watt University, Edinburgh Semester 1 2017/18 Motivation Debugging programs is time-consuming

More information

Lecture Notes on Memory Layout

Lecture Notes on Memory Layout Lecture Notes on Memory Layout 15-122: Principles of Imperative Computation Frank Pfenning André Platzer Lecture 11 1 Introduction In order to understand how programs work, we can consider the functions,

More information

G Programming Languages - Fall 2012

G Programming Languages - Fall 2012 G22.2110-003 Programming Languages - Fall 2012 Lecture 4 Thomas Wies New York University Review Last week Control Structures Selection Loops Adding Invariants Outline Subprograms Calling Sequences Parameter

More information

Using a debugger. Segmentation fault? GDB to the rescue!

Using a debugger. Segmentation fault? GDB to the rescue! Using a debugger Segmentation fault? GDB to the rescue! But first... Let's talk about the quiz Let's talk about the previous homework assignment Let's talk about the current homework assignment K findkey(v

More information

Code Contracts in C#

Code Contracts in C# Code Contracts in C# Hans-Wolfgang Loidl School of Mathematical and Computer Sciences, Heriot-Watt University, Edinburgh Semester 1 2018/19 H-W. Loidl (Heriot-Watt Univ) F20SC/F21SC

More information

Learning from Executions

Learning from Executions Learning from Executions Dynamic analysis for program understanding and software engineering Michael D. Ernst and Jeff H. Perkins November 7, 2005 Tutorial at ASE 2005 Outline What is dynamic analysis?

More information

A Practical Approach to Programming With Assertions

A Practical Approach to Programming With Assertions A Practical Approach to Programming With Assertions Ken Bell Christian-Albrechts Universität Kiel Department of Computer Science and Applied Mathematics Real-Time Systems and Embedded Systems Group July

More information

Ambientes de Desenvolvimento Avançados

Ambientes de Desenvolvimento Avançados Ambientes de Desenvolvimento Avançados http://www.dei.isep.ipp.pt/~jtavares/adav/adav.htm Aula 6 Engenharia Informática 2006/2007 José António Tavares jrt@isep.ipp.pt 1 Components and Interfaces Part 2

More information

Program Verification (6EC version only)

Program Verification (6EC version only) Program Verification (6EC version only) Erik Poll Digital Security Radboud University Nijmegen Overview Program Verification using Verification Condition Generators JML a formal specification language

More information

EXAMINATIONS 2012 END-OF-YEAR SWEN222. Software Design. Question Topic Marks 1. Design Quality Design Patterns Design by Contract 12

EXAMINATIONS 2012 END-OF-YEAR SWEN222. Software Design. Question Topic Marks 1. Design Quality Design Patterns Design by Contract 12 T E W H A R E W Ā N A N G A O T E Ū P O K O O T E I K A A M Ā U I VUW V I C T O R I A UNIVERSITY OF WELLINGTON Student ID:..................... EXAMINATIONS 2012 END-OF-YEAR SWEN222 Software Design Time

More information

0/38. Detecting Invariants. Andreas Zeller + Andreas Gross. Lehrstuhl Softwaretechnik Universität des Saarlandes, Saarbrücken

0/38. Detecting Invariants. Andreas Zeller + Andreas Gross. Lehrstuhl Softwaretechnik Universität des Saarlandes, Saarbrücken 0/38 Detecting Invariants Andreas Zeller + Andreas Gross Lehrstuhl Softwaretechnik Universität des Saarlandes, Saarbrücken Exam 1/38 on Tuesday, 2003-02-18, 11:15 in lecture room 45/001 (here) Written

More information

Semantic Analysis and Type Checking

Semantic Analysis and Type Checking Semantic Analysis and Type Checking The compilation process is driven by the syntactic structure of the program as discovered by the parser Semantic routines: interpret meaning of the program based on

More information

Buffer overflow prevention, and other attacks

Buffer overflow prevention, and other attacks Buffer prevention, and other attacks Comp Sci 3600 Security Outline 1 2 Two approaches to buffer defense Aim to harden programs to resist attacks in new programs Run time Aim to detect and abort attacks

More information

Computer Components. Software{ User Programs. Operating System. Hardware

Computer Components. Software{ User Programs. Operating System. Hardware Computer Components Software{ User Programs Operating System Hardware What are Programs? Programs provide instructions for computers Similar to giving directions to a person who is trying to get from point

More information

Overview The Java Modeling Language (Part 1) Related Work

Overview The Java Modeling Language (Part 1) Related Work Overview The Java Modeling Language (Part 1) Wolfgang Schreiner Wolfgang.Schreiner@risc.jku.at Research Institute for Symbolic Computation (RISC) Johannes Kepler University, Linz, Austria http://www.risc.jku.at

More information

CSE 332: Data Structures & Parallelism Lecture 17: Shared-Memory Concurrency & Mutual Exclusion. Ruth Anderson Winter 2019

CSE 332: Data Structures & Parallelism Lecture 17: Shared-Memory Concurrency & Mutual Exclusion. Ruth Anderson Winter 2019 CSE 332: Data Structures & Parallelism Lecture 17: Shared-Memory Concurrency & Mutual Exclusion Ruth Anderson Winter 2019 Toward sharing resources (memory) So far, we have been studying parallel algorithms

More information

Assignment 2 - Specifications and Modeling

Assignment 2 - Specifications and Modeling Assignment 2 - Specifications and Modeling Exercise 1 A way to document the code is to use contracts. For this exercise, you will have to consider: preconditions: the conditions the caller of a method

More information

Verification and Validation

Verification and Validation Chapter 5 Verification and Validation Chapter Revision History Revision 0 Revision 1 Revision 2 Revision 3 Revision 4 original 94/03/23 by Fred Popowich modified 94/11/09 by Fred Popowich reorganization

More information

Testing, Debugging, and Verification

Testing, Debugging, and Verification Testing, Debugging, and Verification Formal Specification, Part II Srinivas Pinisetty 23 November 2017 Introduction Today: Introduction to Dafny: An imperative language with integrated support for formal

More information

2/12/2018. Recall Why ISAs Define Calling Conventions. ECE 220: Computer Systems & Programming. Recall the Structure of the LC-3 Stack Frame

2/12/2018. Recall Why ISAs Define Calling Conventions. ECE 220: Computer Systems & Programming. Recall the Structure of the LC-3 Stack Frame University of Illinois at Urbana-Champaign Dept. of Electrical and Computer Engineering ECE 220: Computer Systems & Programming Stack Frames Revisited Recall Why ISAs Define Calling Conventions A compiler

More information

The Eiffel language. Slides partly based on :

The Eiffel language. Slides partly based on : The Eiffel language Slides partly based on : http://se.inf.ethz.ch/courses/2015b_fall/eprog/english_index.html Eiffel, in brief Procedural, object-oriented programming language created by Bertrand Meyer

More information

Agenda. CSE P 501 Compilers. Java Implementation Overview. JVM Architecture. JVM Runtime Data Areas (1) JVM Data Types. CSE P 501 Su04 T-1

Agenda. CSE P 501 Compilers. Java Implementation Overview. JVM Architecture. JVM Runtime Data Areas (1) JVM Data Types. CSE P 501 Su04 T-1 Agenda CSE P 501 Compilers Java Implementation JVMs, JITs &c Hal Perkins Summer 2004 Java virtual machine architecture.class files Class loading Execution engines Interpreters & JITs various strategies

More information

Subprograms, Subroutines, and Functions

Subprograms, Subroutines, and Functions Subprograms, Subroutines, and Functions Subprograms are also called subroutines, functions, procedures and methods. A function is just a subprogram that returns a value; say Y = SIN(X). In general, the

More information

A Class-Level Unit Testing Tool for Java

A Class-Level Unit Testing Tool for Java A Class-Level Unit Testing Tool for Java Tz-Fan Hu and Nai-Wei Lin Department of Computer Science and Information Engineering National Chung Cheng University Chiayi 621, Taiwan, R.O.C. Email: {htf97m,naiwei}@cs.ccu.edu.tw

More information

Korat: Automated Testing Based on Java Predicates. Jeff Stuckman

Korat: Automated Testing Based on Java Predicates. Jeff Stuckman Korat: Automated Testing Based on Java Predicates Jeff Stuckman Korat Korat is a specification-based automated testing tool ideal for testing data structures Korat generates synthetic test data based on

More information

Software Engineering Testing and Debugging Testing

Software Engineering Testing and Debugging Testing Software Engineering Testing and Debugging Testing Prof. Dr. Peter Thiemann Universitt Freiburg 08.06.2011 Recap Testing detect the presence of bugs by observing failures Debugging find the bug causing

More information

CS-140 Fall 2017 Test 1 Version Practice Practie for Sept. 27, Name:

CS-140 Fall 2017 Test 1 Version Practice Practie for Sept. 27, Name: CS-140 Fall 2017 Test 1 Version Practice Practie for Sept. 27, 2017 Name: 1. (10 points) For the following, Check T if the statement is true, the F if the statement is false. (a) T F : In mathematics,

More information

High-performance computing and programming Intro to C on Unix/Linux. Uppsala universitet

High-performance computing and programming Intro to C on Unix/Linux. Uppsala universitet High-performance computing and programming Intro to C on Unix/Linux IT Uppsala universitet What is C? An old imperative language that remains rooted close to the hardware C is relatively small and easy

More information

Lecture 3: C Programm

Lecture 3: C Programm 0 3 E CS 1 Lecture 3: C Programm ing Reading Quiz Note the intimidating red border! 2 A variable is: A. an area in memory that is reserved at run time to hold a value of particular type B. an area in memory

More information

CSCD 330 Network Programming

CSCD 330 Network Programming CSCD 330 Network Programming Lecture 12 More Client-Server Programming Winter 2016 Reading: References at end of Lecture 1 Introduction So far, Looked at client-server programs with Java Sockets TCP and

More information

ETHZ D-INFK Final Exam Booklet

ETHZ D-INFK Final Exam Booklet ETHZ D-INFK Booklet Date: 15 December 2009 Surname, first name:... Student number:... I confirm with my signature, that I was able to take this exam under regular circumstances and that I have read and

More information

CS 315 Software Design Homework 3 Preconditions, Postconditions, Invariants Due: Sept. 29, 11:30 PM

CS 315 Software Design Homework 3 Preconditions, Postconditions, Invariants Due: Sept. 29, 11:30 PM CS 315 Software Design Homework 3 Preconditions, Postconditions, Invariants Due: Sept. 29, 11:30 PM Objectives Defining a wellformed method to check class invariants Using assert statements to check preconditions,

More information

Finding Failure Causes through Automated Testing

Finding Failure Causes through Automated Testing Finding Failure Causes through Automated Testing Holger Cleve Universität Passau Lehrstuhl Software-Systeme Innstraße 33 94032 Passau, Germany +49 851 509-3094 cleve@fmi.uni-passau.de Andreas Zeller Universität

More information

JAVA BASICS II. Example: FIFO

JAVA BASICS II. Example: FIFO JAVA BASICS II Example: FIFO To show how simple data structures are built without pointers, we ll build a doubly-linked list ListItem class has some user data first refers to that ListItem object at the

More information

Recursion. What is Recursion? Simple Example. Repeatedly Reduce the Problem Into Smaller Problems to Solve the Big Problem

Recursion. What is Recursion? Simple Example. Repeatedly Reduce the Problem Into Smaller Problems to Solve the Big Problem Recursion Repeatedly Reduce the Problem Into Smaller Problems to Solve the Big Problem What is Recursion? A problem is decomposed into smaller sub-problems, one or more of which are simpler versions of

More information

COMP 202 Recursion. CONTENTS: Recursion. COMP Recursion 1

COMP 202 Recursion. CONTENTS: Recursion. COMP Recursion 1 COMP 202 Recursion CONTENTS: Recursion COMP 202 - Recursion 1 Recursive Thinking A recursive definition is one which uses the word or concept being defined in the definition itself COMP 202 - Recursion

More information

Static and dynamic analysis: synergy and duality

Static and dynamic analysis: synergy and duality Static and dynamic analysis: synergy and duality Michael Ernst MIT Computer Science & Artificial Intelligence Lab http://pag.csail.mit.edu/~mernst/ PASTE June 7, 2004 Michael Ernst, page 1 Goals Theme:

More information

OOPLs - call graph construction. Example executed calls

OOPLs - call graph construction. Example executed calls OOPLs - call graph construction Compile-time analysis of reference variables and fields Problem: how to resolve virtual function calls? Need to determine to which objects (or types of objects) a reference

More information

CSE332: Data Abstractions Lecture 22: Shared-Memory Concurrency and Mutual Exclusion. Tyler Robison Summer 2010

CSE332: Data Abstractions Lecture 22: Shared-Memory Concurrency and Mutual Exclusion. Tyler Robison Summer 2010 CSE332: Data Abstractions Lecture 22: Shared-Memory Concurrency and Mutual Exclusion Tyler Robison Summer 2010 1 Toward sharing resources (memory) So far we ve looked at parallel algorithms using fork-join

More information

Client, Supplier, Contract in OOP (1) Design-by-Contract (Dbc) Test-Driven Development (TDD) Terminology: Contract, Client, Supplier

Client, Supplier, Contract in OOP (1) Design-by-Contract (Dbc) Test-Driven Development (TDD) Terminology: Contract, Client, Supplier Design-by-Contract (Dbc) Test-Driven Development (TDD) Readings: OOSC2 Chapter 11 EECS3311: Software Design Fall 2017 CHEN-WEI WANG Client, Supplier, Contract in OOP (1) class Microwave { private boolean

More information

Introduction to JML David Cok, Joe Kiniry, and Erik Poll Eastman Kodak Company, University College Dublin, and Radboud University Nijmegen

Introduction to JML David Cok, Joe Kiniry, and Erik Poll Eastman Kodak Company, University College Dublin, and Radboud University Nijmegen Introduction to JML David Cok, Joe Kiniry, and Erik Poll Eastman Kodak Company, University College Dublin, and Radboud University Nijmegen David Cok, Joe Kiniry & Erik Poll - ESC/Java2 & JML Tutorial p.1/30

More information

Mock exam 1. ETH Zurich. Date: 9./10. November 2009

Mock exam 1. ETH Zurich. Date: 9./10. November 2009 Mock exam 1 ETH Zurich Date: 9./10. November 2009 Name: Group: 1 Terminology (8 points) Put checkmarks in the checkboxes corresponding to the correct answers. Multiple correct answers are possible; there

More information

Advances in Programming Languages

Advances in Programming Languages Advances in Programming Languages Lecture 12: Practical Tools for Java Correctness Ian Stark School of Informatics The University of Edinburgh Friday 31 November 2014 Semester 1 Week 7 http://www.inf.ed.ac.uk/teaching/courses/apl

More information

Faults Found by Random Testing. WanChi Chio Justin Molinyawe

Faults Found by Random Testing. WanChi Chio Justin Molinyawe Faults Found by Random Testing WanChi Chio Justin Molinyawe Introduction Why apply random testing to object oriented software? Cost-efficient in terms of implementation effort and execution time. Introduction

More information

Software Quality. Debugging " Martin Glinz. Chapter 4. Department of Informatics!

Software Quality. Debugging  Martin Glinz. Chapter 4. Department of Informatics! Department of Informatics! Martin Glinz Software Quality Chapter 4 Debugging " 2014 Martin Glinz. All rights reserved. Making digital or hard copies of all or part of this work for educational, non-commercial

More information

COMP-202. Recursion. COMP Recursion, 2011 Jörg Kienzle and others

COMP-202. Recursion. COMP Recursion, 2011 Jörg Kienzle and others COMP-202 Recursion Recursion Recursive Definitions Run-time Stacks Recursive Programming Recursion vs. Iteration Indirect Recursion Lecture Outline 2 Recursive Definitions (1) A recursive definition is

More information

Formale Entwicklung objektorientierter Software

Formale Entwicklung objektorientierter Software Formale Entwicklung objektorientierter Software Praktikum im Wintersemester 2008/2009 Prof. P. H. Schmitt Christian Engel, Benjamin Weiß Institut für Theoretische Informatik Universität Karlsruhe 5. November

More information

Assertions & Design-by-Contract using JML Erik Poll University of Nijmegen

Assertions & Design-by-Contract using JML Erik Poll University of Nijmegen Assertions & Design-by-Contract using JML Erik Poll University of Nijmegen Erik Poll - JML p.1/39 Overview Assertions Design-by-Contract for Java using JML Contracts and Inheritance Tools for JML Demo

More information

Undefined Behaviour in C

Undefined Behaviour in C Undefined Behaviour in C Report Field of work: Scientific Computing Field: Computer Science Faculty for Mathematics, Computer Science and Natural Sciences University of Hamburg Presented by: Dennis Sobczak

More information

Introduction to Programming Using Java (98-388)

Introduction to Programming Using Java (98-388) Introduction to Programming Using Java (98-388) Understand Java fundamentals Describe the use of main in a Java application Signature of main, why it is static; how to consume an instance of your own class;

More information

Abstraction and Specification

Abstraction and Specification Abstraction and Specification Prof. Clarkson Fall 2017 Today s music: "A Fifth of Beethoven" by Walter Murphy Review Previously in 3110: Language features for modularity Some familiar data structures Today:

More information

Adding Contracts to C#

Adding Contracts to C# Adding Contracts to C# Peter Lagace ABSTRACT Design by contract is a software engineering technique used to promote software reliability. In order to use design by contract the selected programming language

More information

CS-140 Fall 2017 Test 1 Version Practice Practie for Sept. 27, Name:

CS-140 Fall 2017 Test 1 Version Practice Practie for Sept. 27, Name: CS-140 Fall 2017 Test 1 Version Practice Practie for Sept. 27, 2017 Name: 1. (10 points) For the following, Check T if the statement is true, the F if the statement is false. (a) T F : In mathematics,

More information

Regression testing. Whenever you find a bug. Why is this a good idea?

Regression testing. Whenever you find a bug. Why is this a good idea? Regression testing Whenever you find a bug Reproduce it (before you fix it!) Store input that elicited that bug Store correct output Put into test suite Then, fix it and verify the fix Why is this a good

More information

CSCD 330 Network Programming

CSCD 330 Network Programming CSCD 330 Network Programming Lecture 12 More Client-Server Programming Winter 2019 Reading: References at end of Lecture 1 Introduction So far, Looked at client-server programs with Java Sockets TCP and

More information

ARTOO: Adaptive Random Testing for Object-Oriented Software

ARTOO: Adaptive Random Testing for Object-Oriented Software ARTOO: Adaptive Random Testing for Object-Oriented Software Ilinca Ciupa, Andreas Leitner, Manuel Oriol, Bertrand Meyer Chair of Software Engineering ETH Zurich, Switzerland {firstname.lastname}@inf.ethz.ch

More information

Lecture 7: Data Abstractions

Lecture 7: Data Abstractions Lecture 7: Data Abstractions Abstract Data Types Data Abstractions How to define them Implementation issues Abstraction functions and invariants Adequacy (and some requirements analysis) Towards Object

More information

CS31: Introduction to Computer Science I Spring 2011

CS31: Introduction to Computer Science I Spring 2011 Final Practice TA: Brian Choi (schoi@cs.ucla.edu) Section Webpage: http://www.cs.ucla.edu/~schoi/cs31 1. Assume the following variable declarations: int foo = 0; int *ptr = &foo; Which of the following

More information

Commands, and Queries, and Features. Syntax of Eiffel: a Brief Overview. Escape Sequences. Naming Conventions

Commands, and Queries, and Features. Syntax of Eiffel: a Brief Overview. Escape Sequences. Naming Conventions Commands, and Queries, and Features Syntax of Eiffel: a Brief Overview EECS3311 A: Software Design Fall 2018 CHEN-WEI WANG In a Java class: Attributes: Data Mutators: Methods that change attributes without

More information

Automatic testing of object-oriented software

Automatic testing of object-oriented software Automatic testing of object-oriented software Bertrand Meyer, Ilinca Ciupa, Andreas Leitner, Lisa (Ling) Liu Chair of Software Engineering, ETH Zurich, Switzerland http://se.ethz.ch {Firstname.Lastname}@inf.ethz.ch

More information

ReCrash: Making Crashes Reproducible Sunghun Kim, Shay Artzi, and Michael D. Ernst

ReCrash: Making Crashes Reproducible Sunghun Kim, Shay Artzi, and Michael D. Ernst Computer Science and Artificial Intelligence Laboratory Technical Report MIT-CSAIL-TR-2007-054 November 20, 2007 ReCrash: Making Crashes Reproducible Sunghun Kim, Shay Artzi, and Michael D. Ernst massachusetts

More information

The Procedure Abstraction

The Procedure Abstraction The Procedure Abstraction Procedure Abstraction Begins Chapter 6 in EAC The compiler must deal with interface between compile time and run time Most of the tricky issues arise in implementing procedures

More information

A Fitness Function to Find Feasible Sequences of Method Calls for Evolutionary Testing of Object-Oriented Programs

A Fitness Function to Find Feasible Sequences of Method Calls for Evolutionary Testing of Object-Oriented Programs A Fitness Function to Find Feasible Sequences of Method Calls for Evolutionary Testing of Object-Oriented Programs Myoung Yee Kim and Yoonsik Cheon TR #7-57 November 7; revised January Keywords: fitness

More information

Self-checking software insert specifications about the intent of a system

Self-checking software insert specifications about the intent of a system Assertions Reading assignment A. J. Offutt, A Practical System for Mutation Testing: Help for the Common Programmer, Proceedings of the 12th International Conference on Testing Computer Software, Washington,

More information

Contract Driven Development = Test Driven Development - Writing Test-Cases

Contract Driven Development = Test Driven Development - Writing Test-Cases Contract Driven Development = Test Driven Development - Writing Test-Cases ABSTRACT Andreas Leitner, Ilinca Ciupa, Manuel Oriol, Bertrand Meyer Chair of Software Engineering ETH Zurich, Switzerland firstname.lastname@inf.ethz.ch

More information

Software Engineering

Software Engineering Software Engineering Lecture 13: Testing and Debugging Testing Peter Thiemann University of Freiburg, Germany SS 2014 Recap Recap Testing detect the presence of bugs by observing failures Recap Testing

More information

CSE P 501 Compilers. Java Implementation JVMs, JITs &c Hal Perkins Winter /11/ Hal Perkins & UW CSE V-1

CSE P 501 Compilers. Java Implementation JVMs, JITs &c Hal Perkins Winter /11/ Hal Perkins & UW CSE V-1 CSE P 501 Compilers Java Implementation JVMs, JITs &c Hal Perkins Winter 2008 3/11/2008 2002-08 Hal Perkins & UW CSE V-1 Agenda Java virtual machine architecture.class files Class loading Execution engines

More information