UNCC-EmbeddedSystems-Software_Testing

Less finger pointing happier team its clear who made

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: tested, most probably have bugs – Now the question is “Which bug in which module causes the failure I see?” – Errors in one module can make it difficult to test another module • If the round-robin scheduler ISR doesn’t always run tasks when it should, it will be hard to debug your tasks! Less finger pointing = happier team – It’s clear who made the mistake, and it’s clear who needs to fix it Better automation – Drivers and stubs initially require time to develop, but save time for future testing Embedded Systems 11 Development Tasks Development = Σ(coding + testing) Task dependency graph shows an overview of the sequence of – What software must be written – When and how it is tested Nodes represent work – Ellipse = code, Box = test Arrows indicate order Embedded Systems 12 Overview Big Picture – What testing is and isn’t – When to test in the project development schedule – Incremental vs. Big Bang How to test – Bug reports – Clear box vs. black box testing – Writing test harnesses • Software only • Software and hardware – Test plan and selecting test cases • What code to test • What data to provide Embedded Systems 13 Bug Report Goal: provide information to get bug fixed – Explain how to reproduce the problem – Analyze the error so it can be described in as few steps as possible – Write report which is complete, easy to understand, and non-antagonistic Sections – – – – – – – – – Program version number Date of bug discovery Bug number Type: coding error, design issue, suggestion, documentation conflict, hardware problem, query Severity of bug: minor, serious, fatal Can you reproduce the bug? If so, describe how to reproduce it Optional suggested fix Problem summary (one or two lines) Embedded Systems 14 Clear Box (White Box) Testing How? – Exercise code based on knowledge of how program is written – Performed during Coding stage Subcategories – Condition Testing • Test a variation of each condition in a function – True/False condition requires two tests – Comparison condition requires three tests » A>B? A < B, A == B, A > B • Compound conditions – E.g. (n>3) && (n != 343) – Loop Testing • Ensure code works regardless of number of loop iterations • Design test cases so loop executes 0, 1 or maximum number of times • Loop nesting or dependence requires more cases Embedded Systems 15 Black Box Testing Complement to white box testing Goal is to find – – – – – Incorrect or missing functions Interface errors Errors in data structures or external database access Behavioral or performance errors Initialization and termination errors Want each test to – Reduce the number of additional tests needed for reasonable testing – Tell us about presence or absence of a class of errors Embedded Systems 16 Comparing Clear Box and Black Box Testing Clear box – We know what is inside the box, so we test to find internal components misbehaving – Large number of pos...
View Full Document

Ask a homework question - tutors are online