Unit 3 - Software Testing and Maintenance

UNIT III - SOFTWARE TESTING
AND MAINTENANCE
Unit III – Software Testing
and Maintenance
• Software Testing Fundamentals –
Software testing strategies – Black Box
Testing – White Box Testing – System
Testing – Object Orientation Testing –
State-based Testing - Testing Tools –
Test Case Management – Software
Maintenance Organization – Maintenance
Report – Types of Maintenance – Case
Study for Testing Techniques.
Software Testing Fundamentals
Goals of Testing
a) Finding errors
b) Designing good tests that gives a high
probability of finding errors
c) Designing a product having the
“testability” quality in mind
d) Finding maximum number of errors with
minimum test effort
e) Testing is carried out by the developer
along with the ITG(Independent Test
Group)
Figure : The Testing Process

Test Test Test Test

cases data results reports
Design test Prepare test Run program Compare results

cases data with test data to test cases
Figure : The Testing Process

Note:
• The software testing strategy is an
important part of the Software
Development Life Cycle.
• Software Testing Strategy forms part of

the functional requirements for
developing an integrated software
development plan.
Software Testing
Static Dynamic
Structural Functional
White Box Black Box
Only Logical Errors Nothing else but functioning
Using a test case
- A test case is a set of variables under
which a tester will determine whether a
software if working correctly or not.
- Generating the right blend of test cases
that enable the application to work
defect-free should be met.
Software Development Life Cycle

Software Concepts Requirements Analysis Design Coding & Debugging Systems Testing Deployment
Software Testing Life Cycle
• White Box Testing

• Black / Grey Box Testing
Unit Integration System Acceptance

Testing Testing
Testing Testing
Definition : Testability (James Bach)
“Software testability is simply how easily
[a computer program] can be tested”.
Characteristics of Testability
1) Operability
2) Observability
3) Controllability
4) Decomposability
5) Simplicity
6) Stability &
7) Understandability
Characteristics of a Good Test
a) A good test has a high probability of
finding an error
b) A good test is not redundant
c) A good test should be “best of breed”
d) A good test should be neither too
simple nor too complex
Software Testing Strategies
White-box testing
- Checks the software design
- Testing the basic program structure
- Tests the following at least once
a) Statement coverage
b) Decision coverage
c) Condition coverage
d) Multiple condition coverage
Objectives of White-box testing
(Structural testing or Glass Box
testing)
• Tests the code
• Internal program logic is checked
• Status of the program is examined
• All independent paths within a module is
tested
• Applied in the early stage of testing process
White-box testing
Test data
Tests Derives
Component Test
code outputs
White-box testing techniques
a)Basis path testing
- Testing the logical complexity of all
the different paths from one module
to the other module
Types of Basis path testing
1)Flow Graph Notation or Program
Graph Notation
- Understanding the logical flow of data
from one module to the other
• Each structured construct has a
corresponding symbol
• A flowchart is used to depict program
control structure
• Flowchart is converted to flow graph
• Condition nodes are called predicate
nodes
• Nodes are statements or objects
• Connections are links or edges.
2) Independent Program Paths
- An independent path is any path
through the program that introduces
at least one new set of processing
statements or a new condition.
- Discussion on Cyclomatic Complexity
3) Deriving test cases
- Finding out the possible basis sets by
using the following steps
a) Using the design or code as a
foundation, draw a corresponding flow
graph
b) Determine the cyclomatic complexity of
the resultant flow graph
c) Determine a basis set of linearly
independent paths
D) Prepare test cases that will force
execution of each path in the basis set
4) Graph Matrices
- A data structure
- A square matrix or order n, where n is
the number of nodes
- A tabular representation of a flow
graph
- Matrix entries corresponds to
connection between nodes
• If there is a connection, link weight is 1
otherwise 0
• Otherwise called as a connection matrix
• Each row with two or more entries

represents predicate node
Example of a Graph Matrix
1
Graph Matrix
a
Connected to node
1 2 3 4 5
3
e 1 a
b
d 2
f
5 4 Node
3 d b
g c
4 c f
5 g e
2
Example of a Graph Matrix
Connection Matrix
Connected to node Connections
1 2 3 4 5
1 1 1-1 = 0
Node
3 1 1 2-1 = 1
4 1 1 2-1 = 1
5 1 1 2-1 = 1
3+1 = 4
b) Control Structure Testing
- Basis-path testing is one such type of
control structure testing
- Several other variants of testing apart
from basis-path testing is highlighted
here
- Helps the improve the quality of
white-box testing
a)Condition testing
- Testing each logical condition in a
program module
- Types of condition testing
1) Decision coverage testing
2) Condition coverage testing
3) Multiple condition coverage testing
4) Path coverage testing
b) Data Flow Testing
- Testing the flow of data(locations of
definition and using variables) from
one module to different module(s).
- Testing the statements that carry
data
- Testing the definitions of variables
and verifying its usage
c) Loop Testing
- Testing the validity of the looping
constructs
- Three different classes of loops
a) Simple
b) Nested
c) Concatenated &
d) Unstructured
Loop Testing
Black-box testing
- Also called as behavioral testing
- Focuses on the functional requirements
of the software
Advantages of black box testing
- Helps in finding errors in the following
areas of software development
a) Incorrect or missing functions
b) Interface errors
c) Data structures or external database
access
d) Behaviour or performance errors &
e) Initialization and Termination errors
Note :
White-box testing is done at the early
stages where as black-box is done at the
later stages of software development
What does the black box tests do ?
a) How is the functional validity tested ?
b) How are system behaviour and
performance tested ?
c) What classes of input will make good
test cases ?
d) Is the system particularly sensitive to
certain input values ?
e) How are the boundaries of a data class
isolated ?
f) What data rates and data volume can
the system tolerate ?
g) What effect will specific combinations of
data have on system operation ?
Black-box testing techniques
a) Graph-based testing methods
b) Equivalence Partitioning
c) Boundary Value Analysis
d) Orthogonal Array testing
e) Comparison testing
a)Graph-based testing techniques
- Every application is considered to be a
collection of objects
- Identifying objects and building a
graph(object graph)
- From the object graph, each object
relationship with other objects is
identified
- Writing test cases accordingly to
discover errors
b) Equivalence Partitioning
- A software testing technique that
divides the input and/or output data of
a software unit into partitions of data
from which test cases can be derived.
- The equivalence partitions are usually
derived from the requirements
specification for input attributes that
influence the processing of the test
object.
- Test cases are designed to cover each
partition at least once.
Invalid inputs Valid inputs
System
Outputs
What can equivalence partitioning do?
- Equivalence partitioning technique
uncovers classes of errors.
- Testing uncovers sets of inputs that

causes errors or failures, not just
individual inputs.
What can be partitioned ?
- Usually it is the input data that is
partitioned.
- However, depending on the software unit
to be tested, output data can be
partitioned as well.
- Each partition shall contain a set or range
of values, chosen such that all the values
can reasonably be expected to be treated
by the component in the same way (i.e.
they may be considered ‘equivalent’).
Example
- Example of a function which takes a
parameter “month”.
- The valid range for the month is 1 to 12,
representing January to December. This
valid range is called a partition.
- In this example there are two further
partitions of invalid ranges.
x<1 1 ≤ x ≤ 12 12 < x
Example Contd…
- Test cases are chosen so that each
partition would be tested.
-2 5 17
x<1 1 ≤ x ≤ 12 12 < x
c) Boundary-Value Analysis
• Equivalence partitioning is not a stand
alone method to determine test cases. It
is usually supplemented by boundary
value analysis.
• Boundary value analysis focuses on
values on the edge of an equivalence
partition or at the smallest value on
either side of an edge.
Equivalence Partitioning with
Boundary Value Analysis
• Taking the same example as before.
• Test cases are supplemented with
boundary values.
-2 1 5 12 17
0 2 11 13
x<1 1 ≤ x ≤ 12 12 < x
d) Orthogonal Array Testing
- Created by Dr. Genichi Taguchi
- Used to test pair-wise interactions
- A small subset of all possible
combinations
- Consists of factors and levels
- Factors means variables under study
and levels are the different values the
factors can take
- OA provides a reduced subset of the
total combinations while assuring better
coverage than typical test cases
Sample Program : To find out the largest
of three numbers
• No. of Factors : 3 (a,b,c)
• No. of Levels : 3 (number takes three
values )
• No. of Combinations : 27
• No. of OA combinations : 9
A B C
1 1 1 3
2 1 2 2
3 Parameters – A,B,C 3 1 3 1
4 2 1 2
3 Values – 1,2,3
5 2 2 1
6 2 3 3
All possible cases 7 3 1 1
involving 3 8 3 2 3
parameters: 9 3 3 2
3*3*3 = 27 cases TABLE1 Sample Array using OA
Total cases = 9 which cover all pair-wise combinations
of the 3 variables.
e) Comparison testing
- Comparing a software product’s
strengths and weaknesses with other
software
- Primarily used to check the
competitiveness for end users before
releasing it to the market i.e. to
check whether a product can be
marketable or not
System Testing
• Security Testing
•Attempts to verify that protection mechanisms
built into a system are working properly
• Stress Testing
•Executes a system in a manner that demands
resources in abnormal quantity, frequency or
volume. A product that will work under heavy
load (e.g, on-line banking system) should be
tested under increasing load - much heavier
than expected.
Performance testing
- Designed to test the run-time performance of
software within the context of an integrated
system
Recovery Testing
- Forces the system to fail in a variety of ways and
verifies that recovery is properly performed
Software Development Life Cycle
Software Concepts Requirements Analysis Design Coding & Debugging Systems Testing Deployment
Software Testing Life Cycle

Alpha
& Beta
Thread Testing
• Bottom Up Testing
Incremental Testing
• Top Down Testing
Unit System Acceptance

Integration
Testing Testing Testing Testing
Recovery
Security
Regression Testing Stress
Performance
ALPHA TESTING BETA TESTING
1. Performed by developers at Performed by customers at their
the developer site own site
2. Conducted by an independent Conducted by users
test team
3. Not open to the public Open to the public
4. Performed in a virtual Performed in a real-time
environment environment
5. Comes under both categories Only black-box testing
i.e. white-box and black-box
testing
6. Not known by any other name Other wise called as Field testing
• Object Orientation Testing
How to test?
class
to be
tested
results
software
engineer test cases Why a loop?
Class Testing Process
• SYSTEM
– Same as Traditional ones
– Still based on Requirements Specs
• UNIT
– Two Common Structures Used
• Method
• Class
– Same as Traditional software (Drivers and
Stubs)
Fig : Drivers and Stubs in Integration testing

OO testing need to be done for
a) Syntactic behaviours &
- UML and ADT notations expressed
wisely
a) Semantic behaviours
- Does the model reflect the real world
problem ?
- Is the UML used as intended by its
designers ?
Class tests Integration

tests
System Validation
tests
tests
CLASS A CLASS C
METHOD METHOD
USES USES
CLASS B
METHOD
F
OBJECT CLASS A
METHOD
METHOD 1
METHOD 2 E
METHOD
B C D
METHOD METHOD METHOD

OO testing activities
• Review OOA and OOD models
• Class testing after code is written
• Integration testing within subsystems
• Integration testing as subsystems are
added to the system
• Validation testing based on OOA use-
cases
What needs to be done ?
1) Assessing the CRC (Class,
Responsibility, Collaborator) cards and
the Object relationship diagram
2) Testing object model against the
object relationship network for
collaborations defined for each CRC
card
3) Reviewing detailed specifications of
algorithms used to implement
operations using conventional
inspection techniques
CRC Card example
Steps :
1. Revisit the CRC model and the object-
relationship model
2. Inspect the description of each CRC
card to determine if a delegated
responsibility is part of the
collaborator's definition
3. Invert the connection to ensure that
each collaborator that is asked for
service is receiving requests from a
responsible source
4. Using the inverted connections from
step 3, determine whether
– other classes might be required
– responsibilities are properly grouped
among classes
5. Determine whether widely requested
responsibilities might be combined into
a single responsibility
6. Steps 1 to 5 are applied iteratively to
each class and during OOA model
evaluation
Issues in OO testing
• Classes may contain operations that are
inherited from super classes
• Subclasses may contain operations that
were redefined rather than inherited
• All classes derived from a previously
tested base class need to be thoroughly
tested
• Large number of testing phases due to the
use of iterative and incremental
development processes
• No clear notion of “module” or “unit”. Too
much coupling increases the test effort
• UML models being very abstract does’nt
support test case design
• Need for more test cases when compared
with conventional software due to the
inherent complexity of OO code
State-based Testing
Concept of a state machine
- Implementation independent
specification(model) of the dynamic
behaviour of the system
What are the components ?
- States
- Events
- Actions
- Transitions
State machines are used in software
testing too …
- They become a framework for model
testing, where an executable model
(state machine) is executed or
simulated with event sequences as test
cases before starting the actual
implementation phase
- Supports the testing of the system
implementation (code) against the
system specification (state machine)
- Supports automatic generation of test
cases for the implementation
Faults that can be addressed by state
based testing
1) Missing transition
2) Incorrect transition
3) Missing or incorrect events
4) Missing or incorrect actions
5) Extra, missing or corrupt state
6) Sneak path detection
7) Trap door acceptance
Test Design Strategies for State-
based Testing
- Similar to the notion of “coverage” in
white-box testing
a) Effective test cases need to be built
for
i) All-events coverage
ii) All-states coverage
iii) All-actions coverage
iv) All-transitions
v) All n-transition sequences
vi) All round-trip paths
vii) Exhaustive coverage
Questions
Testing tools
Types of testing tools
a) Manual testing
b) Automation testing
Types of Manual testing
1) Drivers
2) Stubs
3) Dumps
4) Cause-Effect diagram
5) Check lists
Types of Automation Testing
Functional testing tools
a)Quick Test Professional
- Developed by Mercury Interactive
- Icon-based tools for testing
b) Silk Test
- Developed by Segue Software
- All e-business applications can be
tested
c) Win Runner
Load and Performance testing tools
a) LoadRunner
b) OpenSTA – OS http performance
c) Apache Jmeter – OS Load testing tool
d) NeoLoad
e) LoadUI – OS stress testing tool
f) WebLOAD – Load, stress testing for web
g) WAPT – Performance tool for websites
and intranet applications
h) Loadster i) Cloud test j) Load Storm
Performance and Functional testing
tools
a) Rational Robot
b) RFT
To manage the test processes, TEST
DIRECTOR is used
Modules in Test Director
a) Requirements b) Test Plan
c) Test Lab d) Defects
Test Case - Example
Software Maintenance
IEEE Standard 1219 defines this as
“The modification of a software product
after delivery to correct faults, to
improve performance or other attributes,
or to adapt the product to a modified
environment”
- Maintenance has been an important
concern for software since several years
and is a problem for the future
Standard problems with Maintenance
a) Different programs not written by the
users of the application i.e. the original
developers are missing
b) No proper documentation
c) Application not been designed to
accommodate futuristic changes
d) Less priority given to this activity
e) Insufficient domain knowledge
f) Unstructured Code
Why is Maintenance important ?
• Higher quality  less (corrective)
maintenance
• Anticipating changes  less
(adaptive and perfective maintenance
• Better tuning to user needs  less
(perfective) maintenance
• Less code  less maintenance
Different types of software maintenance
a)Corrective Maintenance
- Removing defects in programs
b) Adaptive Maintenance
- Modifying or changing the application
for a new set of features (hardware,
OS, programming language etc…)
c) Perfective Maintenance
- Improving the performance by paying
stress on quality parameters
d) Preventive Maintenance
- Detecting faults much ahead of time
e) Emergency Maintenance
- Sudden changes being accommodated
into the system eg: intrusion-
detection systems, real-time systems
etc…
Distribution of Maintenance Activities
corrective 21%
perfective 50%
adaptive 25%
preventive 4%
People in Maintenance
• 1975: 75,000 people (17%)
• 1990: 8,00,000 (47%)
• 2005: 2,500,000 (76%)
• 2019: ??
Steps in improving maintainability
a) Reverse Engineering and Restructuring
b) Refactoring for bad smells
c) Program comprehension
d) Using standard tools that give insight
into the design as well as code structure
(both static as well as dynamic
behaviour)
e) Tools that can track version history
Come “Reverse Engineering”
What is test case management ?
• Establish a strong and supportive testing
role.
• Re-visit your strategy and mission every
day.
• Advocate for bugs and testability.
• Maintain three lists:risks, issues, coverage
• Test with your team.
• Continuously report the status and
dynamics of testing.
Vital activities of Test Case
Management
The following are the vital activities of the
test management process
a) Creating and maintaining
release/project cycle/component
information
b) Creating and maintaining the test
artifacts specific to each release/cycle
that we have i.e. requirements, test
cases etc…
c) Establishing traceability and coverage
between the test assets
d) Test execution support - Test suite
creation, test execution status capture
etc…
e) Metric collection/report – graph
generation for analysis
f) Bug tracking / Defect Management
Software Maintenance Organization
- Five factors that drive the difficulty of
delivering software
a) Product
b) Documentation
c) End users
d) Process &
e) Environment
Important attributes to be
Considered during maintenance
a) Product age
b) Design
c) Language
d) Current failure rate &
e) Staff experience
Maintenance Organization
An organization looking for maintenance
has to identify the following things with
time
a) Input Vs Output
b) Cycle time
c) Cost/change
d) Schedule
e) Flexibility
f) Quality
Case Study for Testing Techniques

Unit 3 - Software Testing and Maintenance

Загружено:

Сведения о документе

Исходное описание:

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Unit 3 - Software Testing and Maintenance

Загружено:

Авторское право:

Доступные форматы

UNIT III - SOFTWARE TESTING

Figure : The Testing Process

Test Test Test Test

Design test Prepare test Run program Compare results

Figure : The Testing Process

• Software Testing Strategy forms part of

Software Development Life Cycle

Software Testing Life Cycle

• White Box Testing

Unit Integration System Acceptance

• Otherwise called as a connection matrix

• Each row with two or more entries

Invalid inputs Valid inputs

- Testing uncovers sets of inputs that

Software Testing Life Cycle

Unit System Acceptance

Fig : Drivers and Stubs in Integration testing

Class tests Integration

METHOD METHOD METHOD

• 1990: 8,00,000 (47%)

• 2005: 2,500,000 (76%)

Вам также может понравиться