Transcript 13-testingDebugging.ppt

Testing and Debugging
Testing Fundamentals
• Test as you develop
– Easier to find bugs early rather than later
– Prototyping helps identify problems early
• Categories of bugs
– software crashes or data corruption
– failure to meet or satisfy the specification
– poor or unacceptable performance
– hard or difficult to use
Testing fundamentals
• Impossible to test a program
completely
• Three distinct paths through the
program
• If the loop executes 20 times,
there are 320 different sequences
of executions
Reviews and inspections
• Inspections
– Formal process of reviewing code
– First employed by IBM in 1976
– Early work showed that design and review inspections
remove 60 percent of the bugs in a product
Reviews and inspections
• Roles of participants
– Moderator
• Runs the inspection
• Ensure that the process moves along
• Referees the discussion
• Ensures action items done
– Inspector
• Someone other than author
• Some interest in the code
• Carefully review code before inspection meeting
– Author
• Minor role
• May answer questions about code
Reviews and inspections
• Roles of participants
– Scribe
• Record all errors detected
• Keep list of action items
Reviews and inspections
• Inspection process
– Planning
• Code to review chosen
• Moderator assigns task
• Checklists created
• Moderator assigns a presenter (usually one of the
inspectors)
– Overview
• Author describes high-level aspects of project that
affected the design or code
• Sometimes skipped (if all participants are knowledgeable)
Reviews and inspections
• Inspection process
– Preparation
• Working alone, each inspector reviews code noting
problems or questions
• Shouldn’t take more than a couple of hours
– Inspection meeting
• Presenter walks through the code
• Problems are discussed
• Scribe records all errors and action items
• Errors are not fixed at this time
– Inspection report
• Moderator prepares a written report
Black-box and white-box testing
• White-box testing indicates that we can “see” or examine the
code as we develop test cases
• Block-box testing indicates that we cannot examine the code as
we devise test cases
– Seeing the code can bias the test cases we create
– Forces testers to use specification rather than the code
• Complementary techniques
Black-box and white-box testing
Test boundary conditions
public static int binarySearch(char[] data, char key) {
int left = 0;
int right = data.length - 1;
while (left <= right) {
int mid = (left + right)/2;
if (data[mid] == key) {
return mid;
}
else if (data[mid] < key) {
left = mid + 1;
}
else {
right = mid - 1;
}
}
return data.length;
}
Black-box and white-box testing
Boundary conditions
// validate input
if ((year < CALENDAR_START) || (month < 1) || (month > 12)) {
System.output.println("Bad request: " + year + " "
+ month);
return;
}
Black-box and white-box testing
• Suggests the following boundary tests
Input Year
Input Month
1582
2
1583
0
1583
13
1583
1
1583
12
Black-box and white-box testing
• Path coverage or path testing—
create test cases that causes
each edge of the program’s
controlflow graph to be executed
if (x != 3)
Example
if (x != y) {
y = 5;
}
else {
z = z - z;
}
if (x > 1) {
z = z / x;
}
else {
z = 0;
}
y=5
z=z-x
if (x != 3)
y=5
y=5
Black-box and white-box testing
• Testing tips
– Test early
– Use inspections
– Test boundaries
– Test exceptional conditions
– Make testing easily repeatable
Integration and system testing
• Integration testing is done as modules or components are
assembled.
– Attempts to ensure that pieces work together correctly
– Test interfaces between modules
• System testing occurs when the whole system is put together
Debugging
• Use the scientific method
– Gather data
– Develop a hypothesis
– Perform experiments
– Predict new facts
– Perform experiments
– Prove or disprove hypothesis
Debugging
• Tips and techniques
– Simplify the problem
– Stabilize the error
– Locate the error
– Explain the bug to someone else
– Recognize common bugs
• Oversubscripting
• Dereferencing null
– Recompile everything
– Gather more information
– Pay attention to compiler warnings
– Fix bugs as you find them
– Take a break