Chapter 12
Chapter 12
Chapter 12
1
Overview of testing
2
Testing Objectives
Execute a program with the intent of finding errors to
o Determine whether system meets specifications
o Determine whether system meets user’s needs
What is defect?
o A defect is any error found by testing and reviewing activities (All
errors found by internal reviewer, external reviewer and
customer).
3
The Test Process
4
Testing Activities
Requirements
Subsystem System Analysis
Unit
Design Document
Code Test Tested
Subsystem Document
User
Subsystem Unit Manual
Code T est
Tested Integration Functional
Subsystem Test Test
Integrated
Functioning
Subsystems
System
m
Tested Subsyste
Subsystem Unit
Code T est
5 tests by developer
Cont..
Client’s
Global Understanding User
Requirements of Requirements Environment
Usable
Tests by client System
Tests by developer
User’s understanding
System in
Use
Can Tests by user
6
Testing stages
There are 4 stages of Testing:
Unit Test
Integration Test
System Test
Acceptance Test
7
Cont..
8
Unit Test
Purpose: to verify that the component/module functions properly
Check:
ointernal data structures
oLogic
oboundary conditions for input/output data
Normally: White box oriented
Doer: Development team
Metrics: Test coverage:
oStatement
oBranch
oPath
oCondition
Individual subsystem
Confirm that subsystems is correctly coded and carries out the
9
intended functionality
Integration Test
Purpose:
Combining the individual components to uncover errors
associated with interfacing
Normally: Black box oriented
Doer: independent Test team
Groups of subsystems (collection of classes) and eventually the
entire system
Test the interface among the subsystem
10
System Test
Purpose: To ensure that the system does what the
requirement specifies
Types
o Function Testing
o Performance Testing
o Installation Testing
Normally: Black box oriented
Doer: independent Test team
The entire system
Determine if the system meets the requirements
(functional and global)
11
Acceptance Test
Customer’s way to verify that what was wanted is what is built
Uncovers more than requirements discrepancies
Allows the customers to determine what they really want,
whether specified in the document or not.
Customers may decide that the problem as changed and a
different solution is needed
Normally: Black box oriented
Doer: Customer/independent Test team
Evaluates the system delivered by developers
Demonstrate that the system meets customer requirements and is
ready to use
Implementation (Coding) and testing go hand in hand
12
Testing types
Functional test
o Function testing
o User Interface testing
o Data and database integrity testing
User Interface: Layout
Performance test
o Performance profiling
o Load testing
o Stress testing
o Volume testing
Access control & Security test
13
Testing techniques
Static Analysis:
o Hand execution: Reading the source code
o Walk-Through (informal presentation to others)- is a form of
software peer review "in which a designer or programmer leads
members of the development team and other interested parties
through a software product, and the participants ask questions and
make comments about possible errors, violation of development
o Code Inspection (formal presentation to others) - the process of
reviewing the code in an application to check for defects.
o Automated Tools checking - is a type of software that allows you to
design testing tasks and then it can automate the execution of those
tests
syntactic and semantic errors
departure from coding standards
Dynamic Analysis:
Black-box testing (Test the input/output behavior)
White-box testing (Test the internal logic of the subsystem or
14
object)
Cont..
Black box testing is a software testing methodology in which the
tester analyzes the functionality of an application without a thorough
knowledge of its internal design.
White box testing, the tester is knowledgeable of the internal design
of the application and analyzes it during testing.
15
Test Case
Test environment
A test case includes:
o Action (sample: click on Add button, on a link, input birth
day…)
o Input data (valid/invalid/boundary data)
o Expected result (message, …)
Good test case:
o Structure of TC is clear and reasonable.
o Follow requirement closely.
o Cover all of cases that can occur.
o Description and test conditions is brief and easy to understand
o Procedure and expected result is a step by step process
16
17