Reproducing Crashes. Shifting Role of Testing. Shifting Role of Testing. Waterfall Model, V-Model
|
|
- Evan Jacobs
- 6 years ago
- Views:
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
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 informationReplaying 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 informationReferences: 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 informationAutomatic 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 informationReasoning 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 informationLast 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 informationAssertions, 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 informationAutomatic 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 informationIntroduction 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 informationProgramming 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 informationWhat 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 information17. 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 informationSystem 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 informationAdvances 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 informationTest-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 informationEiffelStudio 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 informationSoftwaretechnik. 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 informationSoftwaretechnik. 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 information17. 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 informationIntegrating 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 informationJML 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 informationLecture 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 informationCatching 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 informationBinding 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 informationJava: 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 informationAutomated 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 informationStatic 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 informationEiffel 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 informationMSO 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 informationDesign-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 informationSystem 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 informationObject 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 informationC#: 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 informationhwu-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 informationLecture 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 informationG 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 informationUsing 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 informationCode 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 informationLearning 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 informationA 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 informationAmbientes 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 informationProgram 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 informationEXAMINATIONS 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 information0/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 informationSemantic 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 informationBuffer 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 informationComputer 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 informationOverview 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 informationCSE 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 informationAssignment 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 informationVerification 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 informationTesting, 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 information2/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 informationThe 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 informationAgenda. 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 informationSubprograms, 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 informationA 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 informationKorat: 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 informationSoftware 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 informationCS-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 informationHigh-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 informationLecture 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 informationCSCD 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 informationETHZ 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 informationCS 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 informationFinding 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 informationJAVA 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 informationRecursion. 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 informationCOMP 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 informationStatic 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 informationOOPLs - 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 informationCSE332: 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 informationClient, 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 informationIntroduction 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 informationMock 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 informationAdvances 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 informationFaults 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 informationSoftware 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 informationCOMP-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 informationFormale 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 informationAssertions & 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 informationUndefined 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 informationIntroduction 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 informationAbstraction 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 informationAdding 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 informationCS-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 informationRegression 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 informationCSCD 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 informationARTOO: 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 informationLecture 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 informationCS31: 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 informationCommands, 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 informationAutomatic 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 informationReCrash: 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 informationThe 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 informationA 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 informationSelf-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 informationContract 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 informationSoftware 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 informationCSE 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