SOFTWVARE ENGINEERING Material

SOFTWARE ENGINEERING

UNIT-Iy
Astrategic Approach for Software testing
Software Testing
One of the important phasesof software developnnent
Testing is the process of execution
Involves 40°% of total project cost of a program with the intentionof finding errors
Testing Strategy
A road map that
incorporates test planning, test case design, test execution and
collection and execution
Validation refers to adifferent set of activities that ensures that resultant data
requirements. the software is traceable to the
V&V encompasses a wide customer
Perform Fomal Technical aray of Software Quality Assurance
reviews(FTR) to
Begin testing at component level anduncover move
errors during software development
Adopt testing outward to integration of entire
component based system.
Testing can betechniques relevant to stages of testing
done by software developer and
Testing and debugging are different activities. independent testing group
Low level tests verifies sall Debugging follows ttesting
High level tests validate majorcode segments.
system functions against customer
requirements
Testing Strategies for Conventional
Software l)Unit Testing
2) Integration Testing
3)Validation Testing and
4)System Testing

Spiral Representation for

ConventionalSoftware
ystem tesing
Validation lesting
Integyatign teshing
Unit testing

Code

Desigo
Requirements
Systen ei yineering

Criteria for completion of software testing

Nobody is absolutelycertain that software willnot fail
Based on statistical modeling and software reliability models
Page 7
OFTWARE ENGINEERING - Material
SOFTWAREENGINEERING hours of failure free operation is at least O9s
o5 nercent confidence(probability) that 1000 CPU

Software Testing
Two major categories of software testing
Black box testing
White box testing

Black box testing

can be determined by studying its
input and related
as black box whose behavior
Treats the system
internal structure of the program
output Not concerned with the

Black Box Testing

requirements of the software ie it enables the sw engineer to derive
It focuses on the functional exercise all the functional requirements for that prograrn.
that fully
a set of inputconditions
implementation
Concerned with functionality and
) Graphbased testing method
2) Equivalence partitioning
Graph based testing
relations
Draw a graph of objects and each object and its relation ship exercised.
graph such that
Devisetest casestuncover the
SOFTWARE ENGINEERING Material
SOFTWARE ENGINEERING

Directed
Object link Object
#1 #2e

Node
Undirected weight
link
Parallel Links
object
#3

Equivalence partitioning
Divides allpossible inputs into classes such that there are a finite equivalence classes.
Equivalence class
Set of objects that can be linked by relationship
Reduces the cost of testing
Example
Input consists of 1 to 10
Then classes are n<l, 1<=n<=10,n>10
Choose one valid class with value within the allowed range and two invalid classes where
values are greater than maximum value and smaller than minimum value.
Boundary Value analysis
Select input from equivalence classes such that the input lies at the edge of
the equivalence classes
Set of data lies on the edge or boundary of a class of input data or generates the data that lies at
the boundary of a class of output data
Example
If0.0<=X<=1.0
Then test cases (0.0,1.0) for valid input and (-0.1 and1.1) for invalid
input Orthogonal array Testing
To problems in which input domain is relatively small but too large for
exhaustive testing
Example
Three inputs A,B,Ceach having three values will require 27 test cases
L9 orthogonal testing will reduce the number of test case to 9 as
shown below
A B

2 2
3
2 3
2 2 3
2 3
3 3
SOFTWARE ENGINEERING

2
3 3 2

White Box testing

Also called glass boOx testing
Involves knowing the internal working of a program
Guarantees that all independent paths will be exercised at least once.
Exercises all logical decisions on their true and false sides
Executes all loops
Exercises all data structures for their validity
White box testing techniques
Basis path testing
Control structure testing

Basis path testing

Proposed by Tom McCabe
Defines a basic set of execution paths based on logical complexity of a procedural design
Guarantees to execute every statement in the program at least once
Steps of Basis Path Testing
Draw the flow graph from flow chart of the program
Calculate the cyclomatic complexity of the resultant flow graph
Prepare test cases that will force execution of each path
Three methods to compute Cyclomatic complexity number
V(G-E-N+2(E is number of edges, N is number of nodes
V(G)=Number of regions
V(G= Number of predicates +1
Control Structure testing
Basis path testing issimple and effective
It is not sufficieni in itself quality of white box testing
Control structure broadens the basic test coverage and improves the
Condition Testing
Data flow Testing
Loop Testing

Condition Testing
--Exercise the logical conditions contained in a program module
--Focuses on testing each condition in the program to ensure that it does contain errors
--Simple condition
El<relation operator>E2
--Compound condition
simple condition<Boolean operator>simple condition

Data flow Testing

Selectstest paths according to the locations of definitions and use of variables in a program
Aims to ensure that the definitions of variables and subsequent use tested
Firstconstruct a definition-use graph from the control flow of a program
Loop Testing
Focuses on the validity of loop constructs
Four categories can be defined
Simple loops
Nested loops
Concatenated loops
Unstructured loops
Testing of simple loops
-- N is the maximum number of
allowable passes through the loop
OFTWARE ENGINEERING

Skip the loop entirely the loop

Onlyone pass through loop
Tso passes through the where
loop
m passes through the
m
-11.\-1 passes the loop
Vested Loops
to maximum values
Start at the innermost loop. Set all other loops
outer loops at their
Conduct simple loop test for the innermost loop while holding the
minimum iteration parameter.
keeping allother loops at
Work outwardconducting tests for the next loop but
minimum. Concatenated loops
loop is independent of other.
Follow the approach defined for simple loops. if each of the
the approach for the nested
If the loops are not independent, then follow
loops Unstructured Loops
Redesign the program to avoid unstructured
loops Validation Testing
that can be reasonably expected by
It succeeds when the software functions in a manner
the customer.
1)Validation Test Criteria
2)Configuration Review
3)Alpha And Beta Testing
System Testing
Its primary purpose is to test the complete
software. 1)Recovery Testing
2) Security Testing
3Stress Testing and
4)Performance Testing
The Art of Debugging
Debugging occurs as a consequences of successful testing.
Debugging Stratergies
1)Brute Force Method.
2)Back Tracking 3)Cause
Elimination and
4)Automated debugging
Brute force
Most common and least efficient
Applied when all else fails
Memory dumps are taken
Tries to find the cause from the load of information
Back tracking
Common debugging approach
Useful for small programs
Beginning at the system where the symptom has been uncovered, the source code
backward until the site of the cause is found. traced
 Material
SOFTWARE ENGINEERING
SOFTWARE ENGINEERING

Skip the loop entirely loop

Only one pass through the
loop
Two passes through theloop where
the
m passes through
m>NN-1,NN+1 passes the loop
Nested Loops
loop. Set all other loops to maximum values
Start at the innermost holding the outer loops at
their
innermost loop while
Conduct simple loop test for the
minimum iteration parameter.
loops at
for the next loop but keeping all other
Work outward conducting tests
minimum. Concatenated loops
of other.
approach defined for simple loops, if each of the loop is independent
Follow the
follow the approach for the nested
If theloops are not independent, then
loops Unstructured Loops
Redesign the program to avoid unstructured
loops Validation Testing
by
Itsucceeds when the software. functions in a manner that can be reasonably expected
the customer.
1)Validation Test Criteria
2)Configuration Revievw
3)Alpha And Beta Testing
System Testing
Its primary purpose is to test the complete
software. )Recovery Testing
2)Security Testing
3Stress Testing and
4)Performance Testing
The Art of Debugging
Debugging occurs as a consequences of successful testing.
Debugging Stratergies
1)Brute Force Method.
2)Back Tracking 3)Cause
Elimination and
4)Automated debugging
Brute force
Most common and least efficient
Applied when all else fails
Memory dumps are taken
Tries to find the cause from the
load of information
Back tracking
Common debugging approach
Useful for small programs
Beginning at the system where the Symptom has been uncovered, the source code traced
backward until the site of the cause is found
 Cause Elimination
Based on the concept of Binary partitioning
Alist of all possible causes is developed and tests are
conducted to eliminate each
Software Quality
Conformance to explicitly stated functional andperformance requirements, explicitly
documented development standards, and implicit characteristics that are expected of all
professionally developed software.
Factors that affect software quality can be categorized in two broad groups:
Factors that can be directly measured (e.g. defects uncovered during testing)
2. Factors that can be measured only indirectly (e.g. usability or maintainability)
McCall's quality factors
Product operation
Correctness
Reliability
Efficiency
Integrity
Usability
Product Revision
Maintainability
Flexibility
Testability
Product Transition
Portability
Reusability
Interoperability
ISO 9126 Quality
Factors 1.Functionality 2.
Reliability
3.Usability
4.Efficiency
5.Maintainability
6.Portability
FTWAREENGINEERING
OFTWARE ENGINEERING

Portabil y
Maintainabliy Reusab liy
Flexibilty Interoperability
Testobility
PRODUCT TRANSITION
PRODUCT REVISION

PRODUCT OPERATION

Usabilty Efficiency
Correctness Integrity
Reliability
helps us to assess quality. attribute
Product metrics computer software or size of
some
Product metris for dimension, capacity
Measure of the extent, amount,
quantitative indication possess agiven
attribute
Provides a or process
or process93 definition)
Metric(IEEE component
of aproduct which a systen,
software process, a software project
degree to
of the
quantitative measure insightintothe
A that provide
combination of metrics
Indicator
a
A metric or
itself analysis,Design,Test and
maintenance
product
or a for Analysis model
Product Metrics metricsfor the
Product
Function point Metric
by Albrecht by the systemn
First proposed
the
functionality delivered
parameters
Measures following
from the inputs(EIS)
FP computed
external
Numberof
Number external outputs(EOS)
Inquiries(EQS)
Number of external Logical Files(ILE)
Number of Internal interface files(EIFS)
Number of external complex and weights are assigned as
follows
parameter is classified as simple, average or
Fach
"Information Domain Count Simple avg Complex
3 4
EIS
7
EOS
3 4 6
EQS
ILFS 10
EIFS 5 7 10

FP-Count total *[0.65+0.01*E(Fi))

Metrics for Design Model
sOFTWARE ENGINEERING - Material
SOFTWARE ENGINEERING

DSQI(Design Structure Quality Index)

US air force has designed the DSQI
Compute sl to s7 from data and architectural design
S1:Total number of modules
S2:Number of modules whose correct function depends on the data input
S3:Number of modules whose function depends on prior processing
S4:Number of data base items
S5:Number of unique database items
S6: Number of database segments
S7:Number of modules with single entry and exit
Calculate Dl to D6 from sl to s7 as follows:
DI=0
D|=lif standard design is followed otherwise
D2(module independence)-(1-(s2/s1 )
D3(module not depending on prior processing)=(1-(s3/sl))
D4(Data base size)=(1-(s5/s4)
DS(Database compartmentalization)=(1-(s6/s4)
D6(Module entry/exit characteristics)=(1-(s7/s1)
DSQI=sigma of WiDi
i=lto 6,Wi is weight assigned to Di 0.167
are equal to
If sigma of wi is 1 then all weights with past DSQI. IfDSQI is significantly lower than
DSQI of present design be compared
and review are indicated
the average, further design work
METRICFOR SOURCE CODE
HSS(Halstead Software science) estimated once design
after the code is generated or
Primitive measure that may be derived
iscomplete that appear in a program
n1 =the number of distinct operators in a program
n2 = the number of distinct operands that appear
Ni=the total number of operator occurren ces.
N2= the total number of operand occurren ce.
Overali program length N can be computed:
N=nlog2 n1+ n2log2 n2
V=Nlog2 (n1 +n2)
METRICFOR TESTING
n1= the number of distinct operators that appear in a program
n2= the number of distinct operands that appear in a program
N= the total number of operator Occurrences.
N2= the total number of operand occurrence.
Program Level and Effort
PL= 1/[(n1/ 2) x (N2/ nz 1)]
e= V/PL

METRICS FOR MAINTENANCE

M= the number of modules in the current release
Fe= the number of modules in the current release that have been changed
Fa= the number of modules in the current release that have been added.
Fa= the number of modules from the preceding release that were deleted in the current release
The Software Maturity Index, SMI, is defined as:
SMI = [MI-Fe+ FaFay M]
METRICS FOR PROCESS AND PROJECTS
SOFTWARE MEASUREMENT
Software measurement can be categorized in two ways.
Direct measures of the software engineering process include cost and effort applied. Direct
measures of the product include lines of code (LOC) produced, execution speed, memory size,
and defects reported over some set period of time.
SOFTWARE ENGINEERING

Indirect mneasures of the product includefunctionality, quality, complexity, efficiency.

reliability, maintainability, and many other " abilities"
Size-Oriented Metrics
Size-oriented software metricsare derived by normalizing quality andor productivity measures
by considering the size of the software that has been produced.
Todevelop metrics that can be assimilated with similar metrics from other projects, we choose lines of
code as our normalization value. From the rudimentary data contained in the table, a set of simple size
oriented metrics can be developed for each project:
Errors per KLOC (thousand lines of code).
Defects per KLOC.
Sper LOC.
Page of documentation per KLOC.
In addition,other interesting metrics can be computed:
Errors per person-month.
LOC per person-month.
S per page of documentation.

Function-Oriented Metrics
Function-oriented software metrics use ameasure of the functionality delivered by the application as a
normalization value. Since functionality" cannot be measured directly, it must be deri vedindirectly using other
direct measures. Function-oriented metrics were first proposed by Albrecht, who suggested a measure called the
function point. Functionpoints are derived using an empiricalrelationship based on countable (direct)
measures of software's information domain and assessments of software complexity.
Proponents claim that FP is programming language independent, making it ideal for application
using conventional and nonprocedural languages,
to be known early in the evolution of a project,and that it is based on data that are more likely
making FP more attractive as an estimation
approach.
Opponents clain that the method requires some sleight of hand l in th¡t
basedsubjective rather than objective data, that counts of the information domain van computation is
to collecÉ after :he fct, and that FP has no direct physical neaning- it's just a number. be difficult
Typical Function-Oriented Metries:
errors per FP (thousand lines of code)
FerFp
defects
S per
pages of documentation per FP
FP per person-month

1.3) Reconciling Different Metrics

The relationship between lines Approaches
of code and
programming language that is used to implemnent thefunction points depend upon the
Function points and LOC based metrics have been software and the quality of the design.
software development effort and cost. found to be relatively accurate
predictors of
1.4) Object Oriented Metrics:
Conventional software project metrics (LOC or FP) can be used to
oriented software projects. estimate object
Number of scenarioLorenz and Kidd suggest the
scripts: A following set of metrics for O0
projects:
interation between the user and sçenario script is a detailed sequence of' steps that
the application.
Number of key classes: Key classes are the -highly independent
describes the
objec-oriented analysis.
Number of support classes: Support classes are components that are defined early in
immediately related to the problem domain. required to implement the system but are not
Average
key class number of supportclasses per
key class: Of the average
were known
and Kidd suggest that for agiven problem domain number of
applications with a GUI haveestimation
support classes as key classes. would be much support classes per
simplified.
between two and three times Lorenz
the number of
SOFT WARE - Material
ENGINEERING
SOFTWARE ENGINEERING
Asubsystem is an aggregation of classes that support a function that isa
Number of subsystems: subsystems are identificd, it is easier to lay out
end-user of a system. Once project staff.
schedulein ehic work on subsystems is partitioned among
Visible to the
reasonable

Metrics system.
I.5) Use-Case Oriented
describe user-visible functions and features that are basic requirements for a
number of use-cases
proportional to the size of the application in LOC and to the cases that will have
Use-cases
The use-cases is directly application in LOC and to the number of test
tothe size of the
is directly proportionalexercise the application.
to be designed to fully can be created at vastly different levels of abstraction, there is no standard size
Because use-cases normalization measure
Without a standard measure of what a use-case is, its application as a
tor a use-case.
is suspect.
Metrics
1.6) Web Engineering Project
engineering projects is to build a Web application that delivers a
combination
The objective of all web
of content and functionalityto the end-user. and generally require
low relative complexity
These pages representmeasures
Number of static Web pages: pages. This provides an indication of the overall
less effort to construct than dynamic to develop it.
size of theapplication and the effort :required
Web pages with dynamic contentmany are essential in all e
Number of dynamic Web pages:engines, financial application, and other Web App
commerce applications, search higher relative complexity and require more effort to construct
categories. These pages represent the application and the
an indication of the overall size of
than static pages. This measure provides
effort required to develop it. the degree of
are pointers that provide an indication of
link: Internal page links
Number of internal page App.
architectural coupling within the Web complexity of the Web
persistent data objects; As the number of persistent data objects grows, the
Number of implement it increases proportionally.
App alsO grows, and effort to interfacing grows, system complexity and
Number of external systems interfaced: As the requirement for
effort also increase. encompass static text- based, graphical, video.
developmen
Number static content objects: Static content objects
incorporated within theWeb App.
animation, and audio information that are Dynamic content objects are generated based on end-user
Number of dynamic content obËects: graphical, vidfo, animation, and audio
actions and encompass interrally generated text-based,
App.
information that are incorporatei within the Web
function provides some computational service to
Number of executable functions: An executable
functions increases, modeling and construction effort
the end-user. As the number of executable
also increase.

2) METRICS FOR SOFTVWARE QUALITY

The overriding goal of software engineering is to produce a high-quality system, application, or
nroduct within atimeframe that satisfies a market need. To achieve this goal, software engineers must apply
effective methods coupled with modern tools within the context of amature software process.

2.1 Measuring Quality

The measures of software quality are correctness, maintainability, integrity, and usability. These
measures will provide useful indicators for the project team.
Correctness. Correctness is the degree to which the software performs its required function. The
lack ofcommon
most measure for correctness is defects per KLOC. wherea defect is defined as a verified
conformance to requirements.
Maintainability. Maintainability is the ease with which a program can be corrected if an erros
encountered, adapted if its environment changes, or enhanced if the customer desires a change n
requirements. A simple time-oriented metric is mean-time-toclhange (MTTC), the time it takes
analyze the change request, design an appropriate modification,
distribute the change to all users. implement the change, test lt, ala
Integrity. Atlacks can be made on all three components of software:
programs, data, and documets
 Material
SOFTWARE ENGINEERING
SOFTWARE ENGINEERING

defined: threat and security. Threat is the

additional attributes mnust be aspecific
To measure integrity. two derived from empirical evidence) that an attack of derived trc
probability (which an be estimated orSecuritv is the probability (which canbe estimated or
time.
type willoccur within agivenattack of aspecific typc will be repelled. The integrity of
empirical evidence) that the
defined as
asystem can then be
integrity =[1-(threat x (1|-security)))
user-friendliness and can be measured in terms of four
quantify
Usability: Usability is an attemptto
characteristics:

Defect Removal Efficiency removal

provides benefit at both the project and process level is defect
A quality metric that of the filtering ability of quality assurance and
DRE is a measure
efficiency (DRE). Inessence,
activities as they are applied throughout all process framework activities.
control whole, DRE is defined in the following
When considered for a project as a
manner: DRE =F EI(E+ D)
number of errors found before delivery of the software tothe end-user
where E is the delivery.
and D is the number of defects found after review of
the
the analysis model are passed on to as
not found during the
Those errorsthat are this context, we redefine DRE
task (where they may or may not be found). When used in
design
DRE,= E/(E+Ei+1)
errors found during software engineering activity i and
Eis the number of
software engineering activity i+1 that are traceable to errors
during
E- isthe number of errors found engineering activity i.
that were not discovered in software an individual software engineer) is to achieve DRE that
software team (or
Aquality objective for a before they are passed on to the next activity.
filtered out
approaches 1. That is, errors should be