McGill ECE 321

Introduction to Software Engineering

Testing Document
Slides 1
Introduction to Software Engineering
ECE 321A

Fall, 2001
Muhua Li

Testing Document
McGill ECE 321
Introduction to Software Engineering
Testing Document
Slides 2
Testing Document
What should be included:
Test Plan
Focuses on managerial aspects(scope, approach, resources,
schedule, and so on)
Test Case Specifications
Documents each test, including its inputs, drivers, stubs, and
expected outputs
Test Incident Report
Documents executions of each test, including the actual results
and differences from the expected output
Test Summary Report
Lists all failures discovered in testing or to be investigated
Failures should be traceable (can be reproduced)
McGill ECE 321
Introduction to Software Engineering
Testing Document
Slides 3
Test Plan (1)
Template refer to P365
Clarify its relationship to other documents
SRS,SDD and ODD (refer to P335, Fig9-2)
Define granularity of tested components and
their dependencies
What are to be tested and what are not
Specify pass/fail criteria
McGill ECE 321
Introduction to Software Engineering
Testing Document
Slides 4
Test Plan (2)
What testing approach to be used
Describes testing approach (black-box or white-box)
and the reasons for the selected integration testing
strategy(bottom-up, top-down, sandwich)
Provides a UML diagram if needed
Refer to P356 Fig9-18 and P357 Fig9-19
McGill ECE 321
Introduction to Software Engineering
Testing Document
Slides 5
Test Plan (3)
Define test cases
Lists all test cases in the testing
Grouped by unit testing, integration testing and
system testing
Be consistent with the selected integration strategy
Testing schedule
Specifies responsibilities, the test schedule and so on
Refer to P364 Fig9-24
McGill ECE 321
Introduction to Software Engineering
Testing Document
Slides 6
Test Case Specification (1)
Describes in detail of each test case used
A set of input data and expected results
MUST BE PRECISELY SPECIFIED
Important points:
For each method that has pre-conditions, add one input that
does not satisfy the pre-condition (BE CONSISTENT WITH DD)
Boundary testing each test case may be performed under both
normal and boundary conditions
Whats a test stub: a partial implementation of components on
which the tested component depends
Whats a test driver: a partial implementation of a component that
depends on the tested component
McGill ECE 321
Introduction to Software Engineering
Testing Document
Slides 7
Test Case Specification (2)
Outline of a Test Case Specification
Test case specification identifier
Name of the test case, to identify from other test cases
Better naming from tested component and its tested features
Should be easily referred to the corresponding test item
Test items
Lists the components and the features to be tested
Input specifications (or Entry condition, Flow of
events)
Lists inputs for the test case
Or list the flow of events that happens in the test case, can be
interactive
McGill ECE 321
Introduction to Software Engineering
Testing Document
Slides 8
Test Case Specification (3)
Output specifications (or Exit condition)
Lists expected outputs for the test case
Environmental needs
Lists hardware and software platform needed, including test
drivers and stubs
Special procedural requirements
Lists any constraints(timing, load, operator intervention, and so
on)
Intercase dependencies
Lists the dependencies with other test cases if it has
McGill ECE 321
Introduction to Software Engineering
Testing Document
Slides 9
Example 1
Test case identifier: TestSTMConstructor_Normal
Test item: ScheduleTableModel class constructor with normal initial values
Input specifications: A vector of data values with {{false,U2, McGill, 2000/07/12
7:30pm}, {false, Spice girls,Molson center, 2000/07/13
7:30pm}}; a vector of columnNames with {checked,Band Name,
Location, Time}; a Schedule object mySchedule
Output specifications:The ScheduleTableModel object has been assigned values for its data and
columnNames vectors:
data = {{false,U2, McGill, 2000/07/12 7:30pm}, {false, Spice
girls,Molson center, 2000/07/13 7:30pm}};
columnNames = {checked,Band Name,Location, Time};
parent = mySchedul
Environmental needs: A test driver is needed to instantiate a ScheduleTableModel object and a
Schedule object mySchedule
Special procedural requirements: None
Intercase dependencies: None
McGill ECE 321
Introduction to Software Engineering
Testing Document
Slides 10
Test case identifier: TestSTMConstructor_Null
Test item: ScheduleTableModel class constructor with null
initial values
Input specifications: null
Output specifications: data = null
columnNames = null
parent = null
Environmental needs: A test driver is needed to instantiate a
ScheduleTableModel object
Special procedural requirements: None
Intercase dependencies: None
Example 2
McGill ECE 321
Introduction to Software Engineering
Testing Document
Slides 11
Example 3
Test case identifier: TestDBLoadSchedule_Normal
Test item: DB class loadSchedule () method with
existing file
Input specifications: The file name FestInfo.dat where
the DB data stores
Output specifications: A vector of Show objects is returned
Environmental needs: A test driver is needed to instantiate a
DB object with the input file name,
call its loadSchedule () method and
print out the content of the returned
show object vector
Special procedural requirements: None
Intercase dependencies: TestShowConstructor has been tested
McGill ECE 321
Introduction to Software Engineering
Testing Document
Slides 12
Example 4
Test case identifier: TestDBLoadSchedule_Unnormal
Test item: DB class loadSchedule () method that cannot
access the file as specified
Input specifications: The file name FestInfo.txt that has no
matching file existed
Output specifications: An exception thrown out with message File
not exist
Environmental needs: A test driver is needed to instantiate a DB
object with the input file name, call its
loadSchedule () method
Special procedural requirements: None
Intercase dependencies: TestShowConstructor has been tested

McGill ECE 321
Introduction to Software Engineering
Testing Document
Slides 13
Example 5

Test case name CustomizePersonalSchedule_CommonCase
Entry condition 1. A full show schedule with five show items is
displayed
Flow of events 2. The Tourist selects a favorite show by clicking the
Check option before the first show item
3. The first item is checked
4. The Tourist selects another favorite show by clicking
the Check option before the third show item
5. The third item is checked
6. The Tourist presses ViewPersonalSchedule button
Exit condition 7. The Server displays the personal schedule table with
the first and the third items that the Tourist selects
McGill ECE 321
Introduction to Software Engineering
Testing Document
Slides 14
Example 6

Test case name CustomizePersonalSchedule_EmptyCase
Entry condition 1. A full show schedule is displayed
Flow of events 2. The Tourist presses the ViewPersonalSchdule button
Exit condition 3. The Server displays an empty schedule table

McGill ECE 321
Introduction to Software Engineering
Testing Document
Slides 15
How to perform a test
Testing Manually
Using test harness
Each test case can be a class, performs a certain
test that specified in its test case specification;
A test harness(a program or a script) runs all
the test cases
How about the Rational Robot?