This preview shows page 1. Sign up to view the full content.
Unformatted text preview: e to fix all
– The Pareto Principle defines “the vital few, the trivial many”
• Bugs are uneven in frequency – a vital few contribute the majority of
the program failures. Fix these first.
Embedded Systems 7 Software Development Stages and Testing
– System goals: what it will do and why
Requirements: what must be done
Functional definition: list of features and functionality
Testing during Planning: do these make sense? – External design: user’s view of the system
• User interface inputs and outputs; System behavior given inputs
Internal design: how the system will be implemented
• Structural design: how work is divided among pieces of code
• Data design: what data the code will work with (data structures)
• Logic design: how the code will work (algorithms)
Testing during Design
• Does the design meet requirements?
• Is the design complete? Does it specify how data is passed
between modules, what to do in exceptional circumstances, and
what starting states should be?
• How well does the design support error handling? Are all
remotely plausible errors handled? Are errors handled at the
appropriate level in the design? 2. Design
– – Embedded Systems 8 Software Development Stages
3. Coding and Documentation
– Good practices interleave documentation and testing with coding
• Document the function as you write it, or once you finish it
• Test the function as you build it. More on this later
4. Black Box Testing and Fixing
– After coding is “finished” the testing group beats on the code,
sends bug reports to developers. Repeat.
5. Post-Release Maintenance and Enhancement
• 42% of total software development budget spent on userrequested enhancements
• 25% adapting program to work with new hardware or other
• 20% fixing errors
• 6% fixing documentation
• 4% improving performance
Embedded Systems 9 Development and Testing Approach: Incremental vs. Big Bang Testing
– Code a function and then test it (module/unit/element testing)
– Then test a few working functions together (integration testing)
• Continue enlarging the scope of tests as you write new functions
– Incremental testing requires extra code for the test harness
• A driver function calls the function to be tested
• A stub function might be needed to simulate a function called by
the function under test, and which returns or modifies data.
• The test harness can automate the testing of individual functions to
detect later bugs Big Bang Testing
– Code up all of the functions to create the system
– Test the complete system
• Plug and pray Embedded Systems 10 Why Test Incrementally?
Finding out what failed is much easier
– With BB, since no function has been thoroughly...
View Full Document
- Spring '14
- Software engineering