0% found this document useful (0 votes)
4 views30 pages

Lecture - 4

The document discusses software testing, focusing on test case design, white-box testing, and black-box testing. It emphasizes the importance of testing in software development, highlighting the costs associated with inadequate testing and various methodologies such as equivalence partitioning and boundary value analysis. Additionally, it covers techniques like cause-effect graphing to identify test cases and improve software quality.
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
4 views30 pages

Lecture - 4

The document discusses software testing, focusing on test case design, white-box testing, and black-box testing. It emphasizes the importance of testing in software development, highlighting the costs associated with inadequate testing and various methodologies such as equivalence partitioning and boundary value analysis. Additionally, it covers techniques like cause-effect graphing to identify test cases and improve software quality.
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 30

Software Testing

Lecture - 4

1
Outline

• Test Case Design

• White-Box Testing

• Black-Box Testing

2
Cost of Not Testing

Poor Program Managers might say:


“Testing is too expensive.”

Testing is the most time consuming and expensive part of software


development

Not testing is even more expensive

If we put little testing effort early, the cost of testing increases

Planning for testing after development is prohibitively expensive

3
Cost of Late Testing
60
Assume $1000 unit cost, per fault, 100 faults 0K
50 $25
$3
40 6 0K
Fault origin (%)
30
$2 $10
0K 0K Fault detection (%)
20 $1
3K
$6 Unit cost (X)
10 K

0
t s g n st t t t
en si T e e s e s en
m De it T T ym
ire n io
n
em lo
q u U t t e p
/ a s
Re og e gr S y - D
Pr t st
In Po

Software Engineering Institute; Carnegie Mellon University; Handbook CMU/SEI-96-HB-002


Why Do We Test Software ?

A tester’s goal is to eliminate


faults as early as possible

❖ Improve quality
❖ Reduce cost
❖ Preserve customer satisfaction

5
Why Do We Test Software ?

What subset of all possible test


cases has the highest probability of
detecting the most errors?

❖ A most common but least effective methodology of all is


random-input testing
▪ It has little chance of being an optimal solution

6
Black-Box Testing

❖ Black-box testing is based on program specifications. The


goal is to find areas wherein the program does not behave
according to its specifications.
▪ Equivalence partitioning
▪ Boundary value analysis
▪ Cause-effect graphing
▪ Error guessing

7
Equivalence Partitioning

▪ An exhaustive input test of a program is impossible.

▪ We are limited to a small subset of all possible inputs.

▪ We want to select the ‘‘right’’ subset, that is, the subset with the
highest probability of finding the most errors.

8
Equivalence Partitioning

9
Equivalence Partitioning

Test-case design by equivalence partitioning proceeds in two


steps:

(1) Identifying the equivalence classes


(2) Defining the test cases

10
Identifying the Equivalence Classes

Guidelines for constructing equivalence classes

▪ If an input condition specifies a range of values, identify one valid


equivalence class and two invalid equivalence classes
▪ If an input condition specifies the number of values, identify one
valid equivalence class and two invalid equivalence classes
▪ If an input condition specifies a set of input values that the program
handles each differently, identify a valid equivalence class for each
and one invalid equivalence class
▪ If an input condition specifies a ‘‘must-be’’ situation, such as ‘‘first
character of the identifier must be a letter,’’ identify one valid
equivalence class (it is a letter) and one invalid equivalence class (it
is not a letter).
11
Identifying the Test Cases

Using the equivalence classes to identify the test cases


1. Assign a unique number to each equivalence class.
2. Until all valid equivalence classes have been covered by test
cases, write a new test case covering as many of the uncovered
valid equivalence classes as possible.
3. Until the test cases cover all invalid equivalence classes, write a
test case that covers one, and only one, of the uncovered invalid
equivalence classes.

12
Practice

13
Practice

14
Boundary Value Analysis

❖ Boundary conditions are those situations directly on, above, and


beneath the edges of equivalence classes.
❖ General Guidelines:
➢ If an input condition specifies a range of values, write test cases for the
ends of the range, and invalid-input test cases for situations just
beyond the ends.
➢ If an input condition specifies a number of values, write test cases for
the minimum and maximum number of values and one beneath and
beyond these values.
➢ Use guideline 1 for each output condition.
➢ Use guideline 2 for each output condition.
➢ If the input or output of a program is an ordered set, focus attention on
the first and last elements of the set.
➢ In addition, use your ingenuity to search for other boundary conditions.

15
Example
For example, say a program specification states that the program
accepts 4 to 8 inputs which are five-digit integers greater than
10,000. You use this information to identify the input partitions and
possible test input values.

16
Limitation

● Boundary value analysis and equivalence partitioning do not


explore combinations of input circumstances.

● The number of combinations are usually astronomical.

● Selecting an arbitrary subset of conditions may lead to an


ineffective test

17
Cause-Effect Graphing

● Cause Effect Graphing is a black box testing technique


technique in which a graph is used to represent the
combinations of input conditions.
● It graphically illustrates the relationship between a given
outcome and all the factors that influence the outcome.
● The graph is then converted to a decision table to obtain the
test cases.
● It is a formal language into which a natural-language
specification is translated

18
Circumstances - under which Cause-Effect
Diagram used

To Identify the possible root causes, the reasons for a specific


effect, problem, or outcome.

To Relate the interactions of the system among the factors


affecting a particular process or effect.

To Analyze the existing problems so that corrective action can be


taken at the earliest.

19
Steps used in deriving test cases

● Division of specification:
○ The specifications are divided into small workable pieces and then
converted into cause-effect graphs separately.

● Identification of cause and effects:


○ This involves identifying the causes(distinct input conditions) and
effects(output conditions) in the specification.

● Transforming the specifications into a cause-effect graph:


■ The causes and effects are linked together using Boolean
expressions to obtain a cause-effect graph. Constraints are also
added between causes and effects if possible.

20
Steps used in deriving test cases

● Conversion into decision table:


○ The cause-effect graph is then converted into a limited entry decision
table.

● Deriving test cases:


○ Each column of the decision-table is converted into a test case.

21
Basic Notations used in Cause-effect graph:

● Here c represents cause and e represents effect.

● Identity Function: if c is 1, then e is 1. Else e is 0.


● NOT Function: if c is 1, then e is 0. Else e is 1.
● OR Function: if c1 or c2 or c3 is 1, then e is 1. Else e is 0
● AND Function: if both c1 and c2 and c3 is 1, then e is 1.
Else e is 0

The latter two functions (or and and) are allowed to have any
number of inputs

22
Basic Notations used in Cause-effect graph:

23
Example

There are two columns: col1 and col2. The characters in col1 are ‘A’ or ‘B’.
The characters in col2 are digits. In this situation, the file update is made. If
the first character is incorrect, message X12 is issued. If the second character
is not a digit, message X13 is issued. Draw the cause-effect graph for the
given problem.
The causes are:
1—character in column 1 is ‘‘A’’
2—character in column 1 is ‘‘B’’
3—character in column 2 is a digit
The effects are:
70—update made
71—message X12 is issued
72—message X13 is issued 24
Example

25
Constraints used in Cause-effect graph:

● To represent some impossible combinations of causes or


impossible combinations of effects, constraints are used.

○ Exclusive constraint or E-constraint: It states that either a or b can


be 1, i.e., a and b cannot be 1 simultaneously.
○ Inclusive constraint or I-constraint: It states that atleast one of a, b
and c must always be 1, i.e., a, b and c cannot be 0 simultaneously.
○ One and Only One constraint or O-constraint: It states that one
and only one of a and b must be 1.
○ Requires constraint or R-constraint: It states that for a to be 1, b
must be 1. It is impossible for a to be 1 and b to be 0.

26
Constraints Notations:

27
Example

28
Example

29
Benefits

It Helps us to determine the root causes of a problem or quality using


a structured approach.
It Uses an orderly, easy-to-read format to diagram cause-and-effect
relationships.
It Indicates possible causes of variation in a process.
It Identifies areas, where data should be collected for further study.
It Encourages team participation and utilizes the team knowledge of
the process.
It Increases knowledge of the process by helping everyone to learn
more about the factors at work and how they relate.

30

You might also like