JNTU COLLEGE OF ENGINEERING, PULIVENDULA

COMPUTER SCIENCE AND ENGINEERING DEPARTMENT

IV-I B.Tech
Course File Software Testing
Course Description:
Software testing is an integral and important activity in every software development
environment. Software seems to have has permeated almost every equipment that we use in our
daily lives. Companies that produce embedded systems for use in health care, transportation, and
other critical segments of our society have embraced model based software testing by integrating
them into their development environments
Course Objectives:
This course is designed to enable a clear understanding and knowledge of the
foundations, techniques, and tools in the area of software testing and its practice in the industry.
The course will prepare students to be leaders in software testing. Whether you are a developer
or a tester, you must test software. This course is a unique opportunity to learn strengths and
weaknesses of a variety of software testing techniques
Learning Outcomes:
Where will this subject help?
(a) Test process and continuous quality improvement
(b) Test generation from requirements
(c) Modelling techniques: UML: FSM and State charts, Combinatorial design; and others.
(d) Test generation from models.
(e) Test adequacy assessment.
(f) Industrial applications

Syllabus:

UNIT I:
Introduction : Purpose of testing, Dichotomies, model for testing, consequences of bugs,
taxonomy of bugs
UNIT II:
Flow graphs and Path testing : Basics concepts of path testing, predicates, path predicates and
achievable paths, path sensitizing, path instrumentation, application of path testing.
UNIT III:
Transaction Flow Testing : Transaction flows, transaction flow testing techniques. Dataflow
testing:-Basics of dataflow testing, strategies in dataflow testing, application of dataflow testing.
UNIT IV :
Domain Testing:-domains and paths, Nice & ugly domains, domain testing, domains and
interfaces testing, domain and interface testing, domains and testability.
UNIT V :
Paths, Path products and Regular expressions : Path products & path expression, reduction
procedure, applications, regular expressions & flow anomaly detection.
UNIT VI :
Logic Based Testing : Overview, decision tables, path expressions, kv charts, specifications.
UNIT VII :
State, State Graphs and Transition testing : State graphs, good & bad state graphs, state testing,
Testability tips.

UNIT VIII :
Graph Matrices and Application : Motivational overview, matrix of graph, relations, power of a
matrix, node reduction algorithm, building tools.
Usage of JMeter and Winrunner tools for functional / Regression testing, creation of test script
for unattended testing, synchronization of test case, Rapid testing, Performance testing of a data
base application and HTTP connection for website access.
TEXT BOOKS :
1. Software Testing techniques Baris Beizer, Dreamtech, second edition.
2. Software Testing Tools Dr.K.V.K.K.Prasad, Dreamtech.
REFERENCES :
1. The craft of software testing Brian Marick, Pearson Education.
2. Software Testing Techniques SPD(Oreille)
3. Software Testing in the Real World Edward Kit, Pearson.
4. Effective methods of Software Testing, Perry, John Wiley.
5. Art of Software Testing Meyers, John Wiley.

Lesson Plan:
Topic Details
Unit I:
Introduction:
Purpose of testing
Dichotomies
model for testing
consequences of bugs
taxonomy of Bus

UNIT-II
Flow Graphs and Path Testing:
Basics concepts of path testing,
predicates,
Path predicates and achievable paths
Path sensitization,
path instrumentation
application of path testing.
UNIT-III
Transaction Flow Testing:
Transaction flows,
transaction flow testing Techniques.
Dataflow Testing:Basics of dataflow testing,
Strategies in dataflow testing,
application of dataflow testing.

Unit-IV
Domain Testing:-domains and
paths,
Nice & ugly domains,
domain testing,
domain and interface testing,

Hours
Required
For topic
1
2
2
2
2

No of
Hours
Required

Methodology

Lectures

Observation of student
understanding

Test process and

continuous quality
improvement

Test
3
2

11

Lecture,
Assignment

generation

from

requirements

3
2
1
Lecture
2
3
2
2
2

Modelling
techniques:FSM and
State charts,
Combinatorial design;
and others

11

2
8
2
2

Lecture

Test generation from

models.

domains and testability.

2
Lectures,
Assignment

Unit-V
8
Paths, Path Products and Regular
Expressions: Path products &
path expression,
reduction procedure,
applications,
regular expressions & flow
anomaly detection

generation

from

requirements

2
2
2
2

Unit-VI
Logic Based Testing: Overview,
decision tables,
path expressions,
kv charts, specifications.

1
2
1
2

Unit-VII
State, State Graphs and
Transition Testing: State graphs,
good & bad state graphs,
state testing,
Testability tips

1
2
2
1

Unit-VIII
Graph Matrices and
Applications: Motivational
overview,
matrix of graph,
relations,
power of a matrix,
node reduction algorithm,
building tools. (Student should be
given an exposure to a tool like
JMeter or Winrunner).

Test

2
1
1
1
1

How to devlop
decision tables and
reduction of
expressions

Lecture

How to create test

cases for state cgraphs

Lecture

How to develop graph

metrics

Lecture

Total No. of Instructional periods available for the course: 66

Course Meaterial:
Observations about Testing:
Testing is the process of executing a program with the intention of finding
errors. Myers
Testing can show the presence of bugs but never their absence. - Dijkstra
Good Testing Practices
A good test case is one that has a high probability of detecting an undiscovered defect,
not one that shows that the program works correctly
It is impossible to test your own program
A necessary part of every test case is a description of the expected result
Good Testing Practices (contd)
Avoid nonreproducible or on-the-fly testing
Write test cases for valid as well as invalid input conditions.
Thoroughly inspect the results of each test
As the number of detected defects in a piece of software increases, the probability of the
existence of more undetected defects also increases
Levels of Testing
Unit Testing

Integration Testing
Validation Testing
Regression Testing
Alpha Testing
Beta Testing
Acceptance Testing
Unit Testing
Algorithms and logic
Data structures (global and local)
Interfaces
Independent paths
Boundary conditions
Error handling
Why Integration Testing Is Necessary
One module can have an adverse effect on another
Subfunctions, when combined, may not produce the desired major function
Individually acceptable imprecision in calculations may be magnified to unacceptable levels
Why Integration Testing Is Necessary (contd)
Interfacing errors not detected in unit testing may appear
Timing problems (in real-time systems) are not detectable by unit testing
Resource contention problems are not detectable by unit testing
Top-Down Integration
1.
2. The main control module is used as a driver, and stubs are substituted for all modules
directly subordinate to the main module.
3. Depending on the integration approach selected (depth or breadth first), subordinate stubs
are replaced by modules one at a time.
Top-Down Integration (contd)
3. Tests are run as each individual module is integrated.
4. On the successful completion of a set of tests, another stub is replaced with a real module

5. Regression testing is performed to ensure that errors have not developed as result of
integrating new modules

Problems with Top-Down Integration

Many times, calculations are performed in the modules at the bottom of the hierarchy
Stubs typically do not pass data up to the higher modules
Delaying testing until lower-level modules are ready usually results in integrating many
modules at the same time rather than one at a time
Developing stubs that can pass data up is almost as much work as developing the actual
module
Bottom-Up Integration
Integration begins with the lowest-level modules, which are combined into clusters, or
builds, that perform a specific software subfunction
Drivers (control programs developed as stubs) are written to coordinate test case input and
output
The cluster is tested
Drivers are removed and clusters are combined moving upward in the program structure
Problems with Bottom-Up Integration
The whole program does not exist until the last module is integrated
Timing and resource contention problems are not found until late in the process
Validation Testing
Determine if the software meets all of the requirements defined in the SRS
Having written requirements is essential
Regression testing is performed to determine if the software still meets all of its requirements
in light of changes and modifications to the software
Regression testing involves selectively repeating existing validation tests, not developing
new tests
Alpha and Beta Testing

Its best to provide customers with an outline of the things that you would like them to focus
on and specific test scenarios for them to execute.
Provide with customers who are actively involved with a commitment to fix defects that they
discover

What is testing?
Testing is the process of evaluating a system or its component(s) with the intent to find that
whether it satisfies the specified requirements or not. This activity results in the actual, expected
and difference between their results. In simple words testing is executing a system in order to
identify any gaps, errors or missing requirements in contrary to the actual desire or requirements.
According to ANSI/IEEE 1059 standard, Testing can be defined as A process of analyzing
a software item to detect the differences between existing and required conditions (that
is defects/errors/bugs) and to evaluate the features of the software item.
Who does testing?
It depends on the process and the associated stakeholders of the project(s). In the IT
industry, large companies have a team with responsibilities to evaluate the developed
software in the context of the given requirements. Moreover, developers also conduct
testing which is called Unit Testing. In most cases, following professionals are involved in
testing of a system within their respective capacities:
Software Tester
Software Developer
Project Lead/Manager
End User
Different companies have difference designations for people who test the software on the
basis of their experience and knowledge such as Software Tester, Software Quality Assurance
Engineer, and QA Analyst etc. It is not possible to test the software at any time during its cycle.
The next two sections state when testing should be started and when to end it during the SDLC.

i. When to Start Testing An early start to testing reduces the cost, time to rework and error free
software that is delivered to the client. However in Software Development Life Cycle (SDLC)
testing can be started from the Requirements Gathering phase and lasts till the deployment of the
software.

However it also depends on the development model that is being used. For example in
Water fall model formal testing is conducted in the Testing phase, but in incremental model,
testing is performed at the end of every increment/iteration and at the end the whole application
is tested. Testing is done in different forms at every phase of SDLC like during Requirement
gathering phase, the analysis and verifications of requirements are also considered testing.
Reviewing the design in the design phase with intent to improve the design is also considered as
testing. Testing performed by a developer on completion of the code is also categorized as Unit
type of testing.ii. When to Stop Testing Unlike when to start testing it is difficult to determine
when to stop testing, as testing is a never ending process and no one can say that any software is
100% tested. Following are the aspects which should be considered to stop the testing:
Testing Deadlines.
Completion of test case execution.
Completion of Functional and code coverage to a certain point.
Bug rate falls below a certain level and no high priority bugs are identified.
Management decision.
Difference between Verification & Validation
These two terms are very confusing for people, who use them interchangeably. Lets
discuss about them briefly.
Verification
Are you building it right?
Ensure that the software system meets all
the functionality.
Verification takes place first and includes
the checking for documentation, code etc.
Done by developers.
Have static activities as it includes the

Validation
Are you building the right thing?
Ensure that functionalities meet the
intended behavior.
Validation occurs after verification
and mainly involves the checking of the
overall product.
Done by Testers.

reviews, walkthroughs, and inspections to

verify that software is correct or not.
It is an objective process and no subjective
decision should be needed to verify the
Software.

Have dynamic activities as it includes

executing the software against the
requirements.
It is a subjective process and involves
subjective decisions on how well the
Software works.

Assignment / Questions
Unit-I
1. Why is it impossible for a tester to find all the bugs in a system? Why might
it not be necessary for a program to be completely free of defects before it is
delivered to its customers?
2. To what extent can testing be used to validate that the program is fit for its
purpose. Discuss?
3. What is meant by integration testing? Goals of Integration Testing? 4 .
Explain white-box testing and behavioural testing?
5. State and explain various dichotomies in software testing?
6. Discuss about requirements, features and functionality bugs.
7. What are control and sequence bugs? How they can be caught?
Unit-II
1. Consider the following flow - graph? Select optimal number of
paths to achieve C1+C2 (statement coverage + branch coverage).

2) Explain various loops with an example?

3) Explain concatenated loops with an example?
4) State and explain various kinds of predicate blindness with examples?
5) What are link counters? Discuss their use in path testing?
6) Discuss Traversal marker with an example.
7) What is meant by Co - incidental Correctness with example
8) What is meant by statement testing and branch testing with an example.

9) State and explain various path selection rules.

10) What is meant by programs control flow? How is it useful for path testing?
11) Discuss various flow graph elements with their notations.
Unit-III
1. Distinguish Control Flow and Transaction flow.
2. What is meant by transaction flow testing. Discuss
itssignificance.?
3. Discuss in detail data - flow testing strategies.
4. What are data - flow anomalies? How data flow testing can explore
them
5. What are data-flow anomalies? How data flow testing can explore
them?
6. What is meant by a program slice? Discuss about static and dynamic
program slicing.
7. Explain the terms Dicing, Data-flow and Debugging.
8. What is meant by data flow model? Discuss various components of it?
9. Compare data flow and path flow testing strategies?
10. Explain data-flow testing with an example. Explain its generalizations
and limitations.
Unit-IV
1. Discuss with example the equal - span range/Doman compatibility bugs.
2. Discuss in detail about testability of Domains.
3. What is meant by Domain Dimensionality.
4. What is meant by nice - domain? Give an example for nice two
dimensional domain.
5. Discuss
i.Linear domain boundaries ii.Non linear

domain boundaries iii.Complete domain

boundaries
iv. Incomplete domain boundaries
6. Explain various properties related to Ugly-domains.
7.. State and Explain various restrictions at domain testing processes.
8. What is meant by domain testing? Discuss the various
applications of domain testing?
9. With a neat diagram, explain the schematic representation of domain
testing.
10. Explain how one-dimensional domains are tested?
11. Discuss in detail the domains and interface testing.

Unit-V
1. Explain Regular Expressions and Flow Anomaly detection.
2. Example Huangs theorem with examples
3. Reduction procedure algorithm for the following flow graph:
4. Write Short Notes on
i.Distributive Laws
ii.Absorption Rule
iii. Loops
iv. Identity elements
5.Discuss Path Sums and Path Product. Discuss in brief applications of paths
Unit-VI
1. Reduce the following functions using K-Maps
F(A,B,C,D) = P(4,5,6,7,8,12,13)+d(1,15)
2. Whether the predicates are restricted to binary truth-values or not. Explain.
3. What are decision tables? Illustrate the applications of decision tables. How is a

decision table useful in testing. Explain with an example.

4. How can we determine paths in domains in Logic based
testing?
5. How the Boolean expression can be used in test case design
6. Flow graphs are abstract representations of programs. Justify?
7. Explain prime implicant, sum of product form and product of sum form.
8. How can we form specifications into sentences? Write down different
phrases that can be used for words?
9. Explain about the ambiguities and contradictions in
specifications.?
Unit-VII
1. The behavior of a finite state machine is invariant under all encodings.Justify?
2. Write testers comments about state graphs
3. What are the types of bugs that can cause state
graphs?
4. What are the principles of state testing. Discuss
advantages and disadvantages.
5. Write the design guidelines for building finite state machine into code.
6. What are the software implementation issues in state testing? (
7. Explain about good state and bad state graphs.
8. Explain with an example how to convert specification into state-graph.
Also discuss how contradictions can come out.
9. Write short notes on:
i.

Transition Bugs

ii.

Dead States

iii. State Bugs

iv Encoding Bugs

Unit-VIII
1.

How can the graph be represented in Matrix form?

2.

Write a partition algorithm.

3.

Discuss node reduction algorithm.

4.

How can a node reduction optimization be done.

5.

What are the matrix operations in tool building.

6.

Discuss the algorithm for finding set of all paths

7.

How can a relation matrix be represented and what

are the properties of relations?

8. Explain

cross-term

reduction

and

node

term

optimization. Write about matrix powers and products

reduction