Course Code: CSE-3319
Lecture 7
Test Cases
Test case : unit of testing activity
Test cases have 3 parts :-
Goal
Aspect of the system being tested
Input and system state
Data provided to the system under stated condition
Expected behavior
The output or action the system should take according to
its requirements
Black Box Testing
Derived from program specification
Functional testing of a component of a system
Examine behaviour through inputs & the corresponding
outputs
Input is properly accepted, output is correctly produced
Disregard internal logical structure
Black Box Testing (Continued)
Attempts to find the following errors:
Incorrect or missing functions
Interface errors
Errors in data structures or external database access
Performance errors
Initialisation and termination errors
Black Box Testing
Techniques
Graph Based Testing Methods
Equivalence Partitioning
Boundary Value Analysis
Comparison Testing
Orthogonal Array Testing
Discussion on Black Box
Testing
Advantages
Find missing functionality
Independent from code size and functionality
Find some coding errors
Constraints
No systematic search for low level errors
Specification errors not found
Unit Testing
Verification of the smallest unit in software - the module
White box oriented
Can be conducted in parallel for multiple modules
Unit test cases designed based on source code - examine
likely causes for errors
Test environment includes driver and/or stubs
Unit Test Environment
Driver
Module to
be tested
…..
Stub Stub
Unit Testing
Considerations
Interface - tested to ensure that information properly flows
into and out of the unit
Local data structures - examined to ensure that data stored
temporarily maintains its integrity in an algorithm’s
execution
Boundary conditions - tested to ensure that module operates
properly at boundaries
Unit Testing
Considerations (Continued)
Independent paths - to ensure all statements in a
module executed at least once
Error-handling paths
clear and correct messages/descriptions
correct processing of errors
not interrupted by system
sufficient information to locate cause of error
Unit Test Environment
•Act as main program
•Accept test data
•Past to the component to
be tested
Driver
•Print results
Interface
Module to Local data structures
be tested Boundary conditions
Independent path
RESULTS Error Handling path
Stub Stub
•Replace module that are subordinate (called by)
component to be tested Notes :
•Use subordinates module interface •Driver and stub are Test cases
•Do minimal data manipulation software that must be
•Print verification entry written.
•Return control to the module •Both are not delivered
with final product
Regression Testing
New module or major changes in software.
Helps to ensure changes does not introduce
Unintended behavior
Additional errors
Re-execute the subset of all test cases
Most advised : Use automated capture-play back
tools
This tool enable the software engineer to capture test
cases and results for subsequent playback and
comparison.
Validation Testing
A series of black box tests that demonstrate conformity
with requirements
Test that software functions as expected by customer
Test plan and details can be based on software
requirements specification
Alpha Test
Conducted at developer’s site by customer
Software is used in a natural setting with the
developer “looking over the shoulder”
Errors and usage problems recorded, correction can
possibly be done quickly
Test conducted in a controlled environment
Beta Test
Conducted at one or more customer sites by end user(s)
Developer generally not present
“Live” application of software in uncontrolled
environment
Customer records all problems and reports them to
developer at regular intervals
Software modified based on problems reported before
final release to customers
System Testing
A series of tests to fully exercise a computer-based
system
Verify that all system elements have been properly
integrated and perform allocated functions
Software is one element to be integrated
Software engineer to anticipate potential interfacing
problems
Recovery Testing
Force the software to fail in a variety of ways
Verify that recovery is properly performed
If recovery is automatic, re-initialisation,
checkpointing mechanisms, data recovery, and
restart are evaluated for correctness
If recovery requires human intervention, mean time
to repair is evaluated
Security Testing
Verify that protection mechanisms built into the
system will protect it from improper penetration
Tester plays the role(s) of individual who desires to
penetrate the system
System designer to make penetration cost greater
than the value of information obtained
Stress & Performance
Testing
Stress Testing
Execute system in a manner that demands resources in
abnormal quantity, frequency or volume
Performance Testing
Test run-time performance of software within context
of an integrated system
