{[ promptMessage ]}

Bookmark it

{[ promptMessage ]}

UNCC-EmbeddedSystems-Software_Testing

UNCC-EmbeddedSystems-Software_Testing - Software Testing...

Info iconThis preview shows pages 1–8. Sign up to view the full content.

View Full Document Right Arrow Icon
1 Embedded Systems Software Testing
Background image of page 1

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full Document Right Arrow Icon
Embedded Systems 2 Suggested Reading Testing Computer Software, Cem Kaner, Jack Falk, Hung Quoc Nguyen Used as framework for much of this lecture Software Engineering: A Practitioner’s Approach, Robert Pressman Chapters 17 & 18 The Art of Designing Embedded Systems, Jack Ganssle Chapter 2: Disciplined Development Chapter 3: Stop Writing Big Programs The Mythical Man-Month , Frederick P. Brooks, Jr. The Practice of Programming, Brian Kernighan & Rob Pike Why Does Software Cost So Much? and Other Puzzles of the Information Age, Tom DeMarco
Background image of page 2
Embedded Systems 3 Overview Big Picture What testing is and isn’t When to test in the project development schedule Incremental vs. Big Bang How to test Clear box vs. black box Writing test harnesses Software only Software and hardware Selecting test cases What code to test What data to provide
Background image of page 3

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full Document Right Arrow Icon
Embedded Systems 4 Testing Brooks (MMM): Preferred time distribution – mostly planning and testing The sooner you start coding, the longer it will take to finish the program Planning 33% System Test 25% Coding 17% Compon ent Test 25%
Background image of page 4
Embedded Systems 5 Philosophy of Testing Common misconceptions “A program can be tested completely” “With this complete testing, we can ensure the program is correct” “Our mission as testers is to ensure the program is correct using complete testing” Questions to be answered What is the point of testing? What distinguishes good testing from bad testing? How much testing is enough? How can you tell when you have done enough?
Background image of page 5

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full Document Right Arrow Icon
Embedded Systems 6 Clearing up the Misconceptions Complete testing is impossible There are too many possible inputs Valid inputs Invalid inputs Different timing on inputs There are too many possible control flow paths in the program Conditionals, loops, switches, interrupts… Combinatorial explosion And you would need to retest after every bug fix Some design errors can’t be found through testing Specifications may be wrong You can’t prove programs correct using logic If the program completely matches the specification, the spec may still be wrong User interface (and design) issues are too complex
Background image of page 6
Embedded Systems 7 What is the Objective of Testing? Testing IS NOT “the process of verifying the program works correctly” You can’t verify the program works correctly The program doesn’t work correctly (in all cases), and probably won’t ever Professional programmers have 1-3 bugs per 100 lines of code after it is “done” Testers shouldn’t try to prove the program works If you want and expect your program to work, you’ll unconsciously miss failures Human beings are inherently biased The purpose of testing is to find problems Find as many problems as possible The purpose of finding problems is to fix them Then fix the most important problems, as there isn’t enough time to fix all of them
Background image of page 7

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

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

{[ snackBarMessage ]}