UNCC-EmbeddedSystems-Software_Testing

Fix these first embedded systems 7 software

Info iconThis preview shows page 1. Sign up to view the full content.

View Full Document Right Arrow Icon
This is the end of the preview. Sign up to access the rest of the document.

Unformatted text preview: e to fix all of them – 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 1. Planning – – – – 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 programs • 20% fixing errors • 6% fixing documentation • 4% improving performance Embedded Systems 9 Development and Testing Approach: Incremental vs. Big Bang Testing Incremental 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

Ask a homework question - tutors are online