Software engineering

1. Software Testing Fundamentals.
OBJECTIVE: To understand about various testing techniques
• Software testing is a critical element of software quality assurance and
represents the ultimate review of specification, design, and code
generation.
• Once source code has been generated, software must be tested to
uncover (and correct) as many errors as possible before delivery to
your customer.
• During early stages of testing, a software engineer performs all tests.
• However, as the testing process progresses, testing specialists may
become involved.

2. Testing Objectives: Rules that can serve well as testing objectives:
1. Testing is a process of executing a program with the intent of finding an error.
2. A good test case is one that has a high probability of finding an as-yet
undiscovered error.
3. A successful test is one that uncovers an as-yet-undiscovered error.
Testing Principles:
1. All tests should be traceable to customer requirements.
2. Tests should be planned long before testing begins.
3. Pareto principle implies that 80 percent of all errors uncovered during testing will
likely be traceable to 20 percent of all program components.
4. Testing should begin ―in the small‖ and progress toward testing ―in the large.
5. Exhaustive testing is not possible.
6. To be most effective, testing should be conducted by an independent third
party.

3. Testability:
• Software testability is simply how easily [a computer program] can be tested. Since testing is so
profoundly difficult, it pays to know what can be done to streamline it.
• Sometimes programmers are willing to do things that will help the testing process and a checklist
of possible design points, features, etc., can be useful in negotiating with them.
Operability: The better it works, the more efficiently it can be tested.
Observability: What you see is what you test.
Controllability: The better we can control the software, the more the testing can be automated and
optimized.
Decomposability: By controlling the scope of testing, we can more quickly isolate problems and
perform smarter retesting.
Simplicity: The less there is to test, the more quickly we can test it.
Stability: The fewer the changes, the fewer the disruptions to testing.

4. Understandability:
The more information we have, the smarter we will test. Kaner,
Falk, and Nguyen suggest the following attributes of a ―good‖
test:
 A good test has a high probability of finding an error.
 A good test is not redundant. Testing time and resources are
limited.
 A good test should be ―best of breed‖.
 A good test should be neither too simple nor too complex.

5. TEST CASE DESIGN:
• The design of tests for software and other engineered products can be as
challenging as the initial design of the product itself.
• Software engineers often treat testing as an afterthought, developing 3 test
cases that may "feel right" but have little assurance of being complete.
• We must design tests that have the highest likelihood of finding the most errors
with a minimum amount of time and effort.
Any engineered product can be tested in one of two ways:
1. Knowing the specified function that a product has been designed
to perform, tests can be conducted that demonstrate each function
is fully operational while at the same time searching for errors in
each function.
2. Knowing the internal workings of a product, tests can be
conducted to ensure that "all gears mesh," that is, internal
operations are performed according to specifications and all
internal components have been adequately exercised.

6. The first test approach is called black-box testing and the second is white-box
testing.
WHITE-BOX TESTING
• White-box testing, sometimes called glass-box testing is a test case design
method that uses the control structure of the procedural design to derive test
cases.
• Using white-box testing methods, the software engineer can derive test cases
that:
• Guarantee that all independent paths within a module have been exercised at
least once.
• Exercise all logical decisions on their true and false sides.
• Execute all loops at their boundaries and within their operational bounds.
• Exercise internal data structures to ensure their validity.

7. BASIS PATH TESTING:
• Basis path testing is a white-box testing technique first proposed by Tom McCabe.
• The basis path method enables the test case designer to derive a logical complexity
measure of a procedural design and use this measure as a guide for defining a basis
set of execution paths.
Flow Graph Notation:
• The flow graph depicts logical control flow, which serves as a useful tool for
understanding control flow and illustrating the approach.
• The arrows on the flow graph, called edges or links, represent flow of control and
are analogous to flowchart arrows.
• An edge must terminate at a node, even if the node does not represent any
procedural statements.
• Areas bounded by edges and nodes are called regions. When counting regions, we
include the area outside the graph as a region.

9. Cyclomatic Complexity:
• It is software metric that
provides a quantitative
measure of the logical
complexity of a program.
• When used in the context of
the basis path testing
method, the value computed
for cyclomatic complexity
defines the number of
independent paths in the
basis set of a program and
provides us with an upper
bound for the number of
tests that must be
conducted to ensure that all
statements have been
executed at least once.
Flow Chart

10. Flow Graph

11. 1. Cyclomatic complexity has a foundation in graph theory and provides us
with extremely useful software metric. Complexity is computed in one of
three ways:
2. The number of regions of the flow graph corresponds to the cyclomatic
complexity.
3. Cyclomatic complexity, V (G), for a flow graph, G, is defined as V (G) = E -
N + 2, where E is the number of flow graph edges; N is the number of flow
graph nodes.
4. Cyclomatic complexity, V (G), for a flow graph, G, is also defined as V (G) =
P + 1, where P is the number of predicate nodes contained in the flow
graph G.
5. Referring once more to the flow graph in Figure, the cyclomatic
complexity can be computed using each of the algorithms just noted:
a. The flow graph has four regions.
b. V (G) = 11 edges - 9 nodes + 2 = 4.
c. V (G) = 3 predicate nodes + 1 = 4.

12. Deriving Test Cases
The following steps can be applied to derive the basis set:
1. Using the design or code as a foundation, draw a corresponding flow graph.
2. Determine the cyclomatic complexity of the resultant flow graph.
3. Determine a basis set of linearly independent paths.
4. Prepare test cases that will force execution of each path in the basis set.

13. Graph Matrices
• A graph matrix is a square matrix whose size (i.e., number of rows and columns) is equal
to the number of nodes on the flow graph.
• Each row and column corresponds to an identified node, and matrix entries correspond
to connections (an edge) between nodes.
• The graph matrix is nothing more than a tabular representation of a flow graph.
• The link weight provides additional information about control flow.
• In its simplest form, the link 6 weight is 1 (a connection exists) or 0 (a connection does
not exist).

14. But link weights can be assigned other, more interesting properties:
1. The probability that a link (edge) will be executed.
2. The processing time expended during traversal of a link.
3. The memory required during traversal of a link.
4. The resources required during traversal of a link.

16. Control Structure Testing
Condition Testing:
• Condition testing is a test case design method that exercises the logical conditions
contained in a program module.
• A simple condition is a Boolean variable or a relational expression, possibly
preceded with one NOT (¬) operator.
• A relational expression takes the form E1 <relational operator> E2, where E1 and E2
are arithmetic expressions and <relational operator> is one of the following:
<,<=,=,=/(non equality),> or ≥.
• A compound condition is composed of two or more simple conditions, Boolean
operators, and parentheses.
• We assume that Boolean operators allowed in a compound condition include OR
(|), AND (&) and NOT (¬).
• A condition without relational expressions is referred to as a Boolean expression.
• If a condition is incorrect, then at least one component of the condition is incorrect.

17. Therefore, types of errors in a condition include the following:
1. Boolean operator error (incorrect/missing/extra Boolean operators).
2. Boolean variable error.
3. Boolean parenthesis error.
4. Relational operator error.
5. Arithmetic expression error.
• Domain testing requires three or four tests to be derived for a relational expression.
• For a relational expression of the form E1 <relational operator> E2, three tests are
required to make the value of
• E1 greater than, equal to, or less than that of E2.
• If <relational operator> is incorrect and E1 and E2 are correct, then these three tests
guarantee the detection of the relational operator error.
• To detect errors in E1 and E2, a test that makes the value of E1 greater or less than that
of E2 should make the difference between these two values as small as possible.

18. Data Flow Testing:
• The data flow testing method selects test paths of a program according to the
locations of definitions and uses of variables in the program.
• To illustrate the data flow testing approach, assume that each statement in a
program is assigned a unique statement number and that each function does not
modify its parameters or global variables.
• For a statement with S as its statement number, DEF(S) = {X | statement S
contains a definition of X}. USE(S) = {X | statement S contains a use of X}.
• 8 If statement S is an if or loop statement, its DEF set is empty and its USE set is
based on the condition of statement S.
• The definition of variable X at statement S is said to be live at statement S' if there
exists a path from statement S to statement S' that contains no other definition of
X.
• Data flow testing strategies are useful for selecting test paths of a program
containing nested if and loop statements.

19. Loop Testing
• Loop testing is a white-box testing technique that focuses exclusively on
the validity of loop constructs.
• Four different classes of loops can be defined: simple loops,
concatenated loops, nested loops, and unstructured loops.
Simple loops: The following set of tests can be applied to simple loops,
where n is the maximum number of allowable passes through the loop.
1. Skip the loop entirely.
2. Only one pass through the loop.
3. Two passes through the loop.
4. m passes through the loop where m < n. 5. n _1, n, n + 1 passes through
the loop

21. BLACK-BOXTESTING
• Black-box testing, also called behavioral testing, focuses on the
functional requirements of the software.
• That is, black-box testing enables the software engineer to derive
sets of input conditions that will fully exercise all functional
requirements for a program.
• Black-box testing attempts to find errors in the following
categories:
1. Incorrect or missing functions,
2. Interface errors,
3. Errors in data structures or external data base access,
4. Behavior or performance errors,
5. Initialization and termination errors.

22. Graph-Based Testing Methods:
• Software testing begins by creating a graph of important objects and their
relationships and then devising a series of tests that will cover the graph so
that each object and relationship is exercised and errors are uncovered.
• A graph is a collection of nodes that represent objects; links hat represent the
relationships between objects; node weights that describe the properties of a
node (e.g., a specific data value or state behavior);
• and link weights that describe some characteristic of a link.
• In symbolic representation Nodes are represented as circles connected by
links that take a number of different forms.
• A directed link (represented by an arrow) indicates that a relationship moves
in only one direction.
• A bidirectional link, also called a symmetric link, implies that the relationship
applies 11 in both directions.
• Parallel links are used when a number of different relationships are established
between graph nodes

24. • As a simple example, consider a portion of a graph for a word-processing
application where
Object #1 = new file menu select
Object #2 = document window
Object #3 = document text
• Referring to the figure, a menu select on new file generates a document window.
• The node weight of document window provides a list of the window attributes
that are to be expected when the window is generated.
• The link weight indicates that the window must be generated in less than 1.0
second.
• An undirected link establishes a symmetric relationship between the new file menu
select and document text, and parallel links indicate relationships between
document window and document text.

25. Equivalence Partitioning
• Equivalence partitioning is a black-box testing method that divides the input
domain of a program into classes of data from which test cases can be derived.
• Equivalence partitioning strives to define a test case that uncovers classes of
errors, thereby reducing the total number of test cases that must be developed.
Equivalence classes may be defined according to the following guidelines:
1. If an input condition specifies a range, one valid and two invalid equivalence
classes are defined.
2. If an input condition requires a specific value, one valid and two invalid
equivalence classes are defined.
3. If an input condition specifies a member of a set, one valid and one invalid
equivalence class are defined.
4. If an input condition is Boolean, one valid and one invalid class are defined.

26. • As an example, consider data maintained as part of an automated
banking application.
• The user can access the bank using a personal computer, provide a
six-digit password, and follow with a series of typed commands
that trigger various banking functions.
During the log-on sequence, the software supplied for the banking
application accepts data in the form:
1. Area code—blank or three-digit number.
2. Prefix—three-digit number not beginning with 0 or 1.
3. Suffix—four-digit number.
4. Password—six digit alphanumeric string.
5. Commands—check, deposit, bill pay, and the like.

27. The input conditions associated with each data element for the banking
application can be specified as:
1. Area code: Input condition, Boolean—the area code may or may not be
present.
2. Input condition, range—values defined between 200 and 999, with specific
exceptions.
3. prefix: Input condition, range—specified value >200, Input condition, value—
four-digit length
4. Password: Input condition, Boolean—a password may or may not be present.
Input condition, value—six-character string.
5. Command: Input condition, set—containing commands noted previously.
Applying the guidelines for the derivation of equivalence classes, test cases for
each input domain data item can be developed and executed

28. What is Path Testing?
• Path testing is a structural testing method that involves using the source code
of a program in order to find every possible executable path. It helps to
determine all faults lying within a piece of code.
• This method is designed to execute all or selected path through a computer
program.
• Any software program includes, multiple entry and exit points.
• Testing each of these points is a challenging as well as time-consuming.
• In order to reduce the redundant tests and to achieve maximum test coverage,
basis path testing is used.
Basis PathTesting

29. Basis Path Testing in Software Engineering
• Basis Path Testing in software engineering is a White Box
Testing method in which test cases are defined based on flows or
logical paths that can be taken through the program.
• The objective of basis path testing is to define the number of
independent paths, so the number of test cases needed can be defined
explicitly to maximize test coverage.
• In software engineering, Basis path testing involves execution of all
possible blocks in a program and achieves maximum path coverage
with the least number of test cases.
• It is a hybrid method of branch testing and path testing methods.

30. Here we will take a simple example, to get a better idea
what is basis path testing include
In this example, we can see there are few
conditional statements that is executed depending
on what condition it suffice.
Here there are 3 paths or condition that need to be
tested to get the output,
•Path 1: 1,2,3,5,6, 7
•Path 2: 1,2,4,5,6, 7
•Path 3: 1, 6, 7

31. Steps for Basis Path testing
The basic steps involved in basis path testing include
•Draw a control graph (to determine different program paths)
•Calculate Cyclomatic complexity (metrics to determine the number of
independent paths)
•Find a basis set of paths
•Generate test cases to exercise each path
Advantages of Basic Path Testing
•It helps to reduce the redundant tests
•It focuses attention on program logic
•It helps facilitates analytical versus arbitrary case design
•Test cases which exercise basis set will execute every statement in a program
at least once

32. Metrics
• Metrics has come from Measurements
• It is a measure of software characteristics which are qualifiable and
countable
• It helps to Software developers and Team Leaders
These are considered while measuring
1. Software performance
2. Planning work items
3. Measuring productivity
4. Error solving (debugging)
5. Estimating Cost

33. Characteristics:
• It is simple and countable
• Consistent and unambiguous
• Independent of programming languages
Example:
Measurements Metrics:
1. Function point 1. Function point/person hour
2. LOC (lines of code) 2. cost/story point
3. Cost estimation 3. km/hr
4. Kilometer

34. Software metrics is divided into three categories
1. Product Metrics: Size, complexity,design features,performance
and Product quality
2. Process Metrics : Here we have different stages like based on
performance of any company. It allows project manager to
perform . Example, access the status of ongoing project , track
the potential risks and adjust the task
3. Project Metrics: Regarding project.The first application of project
metrics occurs through the estimation. Product Metrics are
collected from the previous projects. The time and effort are
compared to original estimation

35. Metrics for Analysis model:
• Metrics for the analysis model are useful in estimating the project
• These metrics examine the analysis model with the intent of predicating the
size of the resultant system
Function based metrics/Functional Point (FP)
• It measures software size
• It is a unit of measurement to express the amount of business functionality
• To measure the standard worth of the software, as a unit of software worth
Functional Point was developed
• It is mainly used to give a solution to the size measurement problems
• Two types of techniques are used
1. Functional Point Analysis (FPA) Data function ,,, Transaction
2. Functional Point Count(FPC)

36. Elementary process.
According to these two data function and transaction functions is decomposed
Into 5 functional units
1. Input – information entering to the system
2. Output – information leaving from the system
3. Enquiries – requests for instant access for the information
4. Internal logical file – information held within the system
5. External logical (interface) files – information held by the other sytems that is
used by the sytem being analysed
Data Function
ILF EIF
Transactiom
EI EQ
EO

37. There are 5 different Functional Units:
1. Internal logic Files (ILF): The control information or logically related
data that is present within the system
2. External Interface Files(EIF): The control data referenced by the
system but present in another system
3. External Input(EI): Data control information that come from outside
our system
4. External Output(EO): Data that goes of the system after generation
5. External enquired(EQ): Combination of input and output resulting
data retrieval

43. Metrics for design model
Design Metric:
• Design Metrics are useful in measuring the complexity and
“goodness” of a design
• Performance
• Progress
• Process

44. Architectural design metrics:
• It focus on characteristics of the program architecture
and effiectiveness of modules (or) components within
the architecture
• Card and Glass defines three software design
complexity measures:
1.Structural Complexity
2.Data Complexity
3.System Complexity

45. Structural Complexity:
• Structural complexity of module is defined in manner as :
Where fout is the fan-out module of i
S(i) = 𝑓2 out(i)

46. Data Complexity:
• It provides an indication of the complexity in the internal interface for a
module I and is defined as:
• V[i] – No. of input/output variables that are passed to and from module i
D[i]=
𝑉[𝑖]
𝐹𝑜𝑢𝑡 𝑖 +1

47. System Complexity:
• It is defined as the sum of the structural and data complexity specified as:
• Where S[i] – Structural complexity
• D[i] – Data complexity
C[i] = S[i] + D[i]

48. Fenton
• It suggest a number of simple morphology (shape) metrics that
enable different program architecture to be compared using a set of
straight forward dimensions
n – No. of nodes
a – No. of arcs
Size = n + a

49. n-=17
A=18
Size= 17+18=35
Ratio=a/n
Design structure
quality index
DSQI=ƩWiDi
Where I ranges
from 1 to 6

50. Metrics For Source code
𝑛1= No. of distinct operators that appear in the program
𝑛2 = No. of distinct operands that appear in the program
𝑁1 = Total number operator occurrences
𝑁2 =Total number of Operand occurrences
Length of the program:
N = 𝑛1 log2 𝑛1 + 𝑛2 log2 𝑛2
Program volume:
V=Nlog2(𝑛1+𝑛2)
Where V= Volume of Information in bits required to specify a program
V varies directly with the program

51. Volume Ratio
L=
2
𝑛1
𝑥
𝑛2
𝑁2
Potential minimum volume of a program
Actual volume of a program (no. of bits required)
Progarm level can be calculated ( a measure of software complexity)
Development time, effort
No. of faults