11

Click here to load reader

Software Testing - Integration Testing

Embed Size (px)

Citation preview

Page 1: Software Testing - Integration Testing

Wednesday, April 12, 2023Ch.20 - Software Testing II 1

Software Testing

• Component testing – Testing of individual program components– Usually responsibility of developer– Tests derived from developer’s experience

• Integration testing– Testing of groups of components integrated to create

system or sub-system– Responsibility of independent testing team– Tests based on a system specification

Page 2: Software Testing - Integration Testing

Wednesday, April 12, 2023Ch.20 - Software Testing II 2

Integration Testing

• Problem: Localizing errors found

• Strategy: Incremental approach to integration and testing

• Issue: What are the increments?

Page 3: Software Testing - Integration Testing

Wednesday, April 12, 2023Ch.20 - Software Testing II 3

Incremental Integration Testing

ModuleA

ModuleB

Test 1

Test 2

Test 3

Page 4: Software Testing - Integration Testing

Wednesday, April 12, 2023Ch.20 - Software Testing II 4

ModuleA

ModuleB

ModuleC

Test 1

Test 2

Test 3

Test 4

Test 5

Incremental Integration Testing

Page 5: Software Testing - Integration Testing

Wednesday, April 12, 2023Ch.20 - Software Testing II 5

Incremental Integration Testing

ModuleA

ModuleB

Test 1

Test 2

Test 3

ModuleC

Test 4

Test 5

ModuleD

Test 6

Test 7

Page 6: Software Testing - Integration Testing

Wednesday, April 12, 2023Ch.20 - Software Testing II 6

Puncturing the Balloon

It’s never that simple!– Components/tests rarely so “partitionable”– Multiple components may need to be

incrementally added together – Tests may reveal errors in established (tested)

components that were not completely exercised before

– Bug fixes may effect multiple components

Page 7: Software Testing - Integration Testing

Wednesday, April 12, 2023Ch.20 - Software Testing II 7

Top-down Testing

1. Integrate/test high-level components, with stubs for subcomponents

2. Integrate/test next highest level, incrementally

3. Repeat until “bottom” reached

stub (n.) – Same public interface, limited functionality (“Potemkin Village”)

Page 8: Software Testing - Integration Testing

Wednesday, April 12, 2023Ch.20 - Software Testing II 8

Bottom-up Testing

1. Integrate/test low-level components, using special testing drivers written at that interface level

2. Integrate/test next highest level, writing new testing drivers for that level

3. Repeat until “top” reached

Page 9: Software Testing - Integration Testing

Wednesday, April 12, 2023Ch.20 - Software Testing II 9

Top-down vs. Bottom-up

• Top-down – more like to discover architectural design

problems early– Positive feedback from limited, but working,

system (“Bells and whistles”)

• Bottom-up– Easier to test (no need to write stubs), but…

• Test observation a problem with both

Page 10: Software Testing - Integration Testing

Wednesday, April 12, 2023Ch.20 - Software Testing II 10

Top-down vs. Bottom-up

• Reality:– Both stubs and testing drivers require extra

work– Mixture of both strategies employed

Page 11: Software Testing - Integration Testing

Wednesday, April 12, 2023Ch.20 - Software Testing II 11

Stress testing

• Exercises system beyond its maximum design load• Stressing system test failure behaviour

– Systems should not fail catastrophically

– Checks for unacceptable loss of service, data

• Particularly relevant for testing– servers

– systems distributed across network