0% found this document useful (0 votes)
3 views6 pages

Introduction

The document discusses the significance of bugs in software engineering, emphasizing their impact on cost, quality, reliability, and user trust. It outlines various levels of bug consequences, path testing criteria, transaction flow, and data flow testing, highlighting the importance of these concepts in ensuring software reliability and correctness. Additionally, it details data flow anomalies and testing strategies to detect errors that may not be identified through traditional testing methods.

Uploaded by

varunkumarbandi4
Copyright
© All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
3 views6 pages

Introduction

The document discusses the significance of bugs in software engineering, emphasizing their impact on cost, quality, reliability, and user trust. It outlines various levels of bug consequences, path testing criteria, transaction flow, and data flow testing, highlighting the importance of these concepts in ensuring software reliability and correctness. Additionally, it details data flow anomalies and testing strategies to detect errors that may not be identified through traditional testing methods.

Uploaded by

varunkumarbandi4
Copyright
© All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd

1--------Introduction----In software focuses primarily on detecting and

engineering, bugs are the single most preventing bugs early.


important factor affecting cost, quality,
reliability, and user trust. Unlike 2)Introduction
hardware, software manufacturing cost is
negligible; however, the cost of bugs Bug consequences refer to the effect of a
dominates the total software cost. defect on users, systems, and
Therefore, understanding the importance organizations. These consequences vary
of bugs is essential for effective testing. from cosmetic errors to catastrophic
failures.
Importance of Bugs
Levels of Bug Consequences
1. Cost Impact
o Bugs increase development 1. Mild
cost due to detection, o Cosmetic issues like
correction, re-testing, and spelling mistakes,
redistribution. misaligned output.
o The later a bug is found, the 2. Moderate
higher the cost to fix it. o Misleading output, slow
2. Quality and Reliability performance.
o Bugs reduce system 3. Annoying
reliability and performance. o Dehumanizing behavior
o Quality of software is often (e.g., truncated names).
measured by number and 4. Disturbing
severity of bugs. o Legitimate transactions
3. User Confidence rejected (ATM not
o Frequent bugs reduce user dispensing cash).
trust. 5. Serious
o Users may abandon buggy o Loss of transaction history;
software permanently. accountability failure.
4. Safety-Critical Impact 6. Very Serious
o In systems like aviation, o Wrong transactions
banking, nuclear reactors, executed (money credited
and medical devices, bugs to wrong account).
can cause loss of life or 7. Extreme
massive financial damage. o Frequent, unpredictable
5. Maintenance Overhead failures affecting many
o Buggy software increases users.
maintenance cost and 8. Intolerable
complexity. o Long-term database
corruption.
Bug Importance Metric 9. Catastrophic
o System shutdown becomes
Bug Importance=Frequency×(Correction unavoidable.
Cost+Installation Cost+Consequential Cos 10. Infectious
t)Conclusion
 One system corrupts other systems
Thus, bugs are not minor coding mistakes; (defense, nuclear systems).
they are economic, operational, and
sometimes catastrophic risks. Testing
2========= Definition

3) What is Path and Explain Path Path sensitizing is the process of finding
Testing Criteria (15 Marks) input values that force execution of a
selected path.
Path
Steps
A path is a sequence of nodes and links in
a control flow graph from entry to exit. 1. Select a path from the control flow
graph
Path Testing 2. Identify predicates on that path
3. Express predicates in terms of
Path testing is a structural (white-box) input variables
testing technique that selects a set of 4. Combine predicates into a path
execution paths to achieve test coverage. predicate expression
5. Solve the expression
Path Testing Criteria
Achievable vs Unachievable Paths
1. Statement Coverage (C1)
 If solution exists → Achievable
 Every statement executed at least path
once.  If no solution → Unachievable
 Weakest criterion. path
 Some bugs may remain hidden.
Importance
2. Branch Coverage (C2)
 Prevents wasted testing effort
 Every decision outcome  Ensures real path execution
(TRUE/FALSE) executed.
 Stronger than statement coverage. Conclusion
 Detects control-flow bugs.
Path sensitizing bridges the gap between
3. Path Coverage (P∞) theoretical path selection and practical
execution.
 All possible paths executed.
 Theoretically strongest. 1. Transaction – Definition (2 Marks)
 Practically impossible due to loops.
A transaction is a unit of work as seen
Minimum Acceptable Testing by the user, which starts when it is created
and ends when it is completed.
C1 + C2 is mandatory for new software. A transaction represents system
functionality, not program structure.
Conclusion
A transaction has:
Path testing ensures logical correctness
and detects structural defects efficiently.  Birth (creation)
 Processing
 Death (completion)

4) Explain Path Sensitizing (15 Marks)


3==========2. Transaction Flow (4 4. PIN is verified
Marks) 5. User selects transaction
6. Account is updated
Transaction Flow represents the 7. Cash is dispensed
sequence of operations performed by a 8. Transaction is logged
system to complete a transaction. 9. Card is returned

It shows: Transaction Flow Diagram (DRAW


THIS)
 How a transaction enters the
system Start
 How it is processed |
 How it exits the system Insert Card
|
Transaction flows are mainly used for Validate Card
functional testing and are very useful for |
online and real-time systems. Enter PIN
|
Verify PIN
|
3. Transaction Flow Graph (4 Marks) Select Transaction
|
A Transaction Flow Graph (TFG) is a Update Account
graphical representation of transaction |
processing. Dispense Cash
|
Features: Log Details
|
 Nodes represent processing steps End
 Arrows represent flow of
transaction (Boxes + arrows are enough. Neat and
 Focuses on system behavior, not simple.)
code
 Mostly linear with few loops

Transaction flow testing for system testers


is similar to path testing for
programmers.

4. Example of Transaction Flow – ATM


System (5 Marks)

ATM Transaction Example:

1. User inserts ATM card


2. System validates card
3. User enters PIN
4--------- Diagram:

5. Complications in Transaction Flow (5 T


Marks) |
Mitosis
In real systems, transaction flows are not / \
always simple. Transactions can split, T1 T2
merge, or create new transactions. These
are called transaction flow
complications. d) Transaction Mergers (Extra Point –
write if space)
Major Complications:
 Multiple transactions combine into
one
 Difficult to track and test
a) Decision (1 Mark)
Diagram:
 Transaction follows only one path
 Similar to IF–ELSE T1 T2
\/
Diagram: T

T
| 6. Importance of Transaction Flow
Decision Testing (Optional – helps marks)
/ \
Path1 Path2  Identifies missing or incorrect
functionality
 Useful for system and acceptance
b) Biosis (2 Marks) testing
 Helps test user-visible behavior
 A new transaction is created  Detects interaction and integration
 Parent transaction continues bugs
 Both run independently

Diagram:
7. Conclusion (2 Marks)
T
| Transaction flow modeling provides a
Biosis clear behavioral view of the system.
/ \ By using transaction flow graphs and
T (old) T1 (new) understanding complications such as
decision, biosis, and mitosis, testers can
effectively design test cases for complex
c) Mitosis (2 Marks) real-world systems.

 Parent transaction is destroyed


 Two new transactions are
created
5-----------------  The value of the data object is
accessed
1. Introduction (2 Marks)  Used in computation or decision
 Example: if (x > 5)
In software programs, data objects play a
crucial role in computation and control. 3. Killed (k)
Errors related to improper definition,
usage, or handling of data objects lead to  Data object is destroyed or
data flow anomalies, which are difficult deallocated
to detect using only control flow testing.  Example: freeing memory, exiting
scope
Data flow testing focuses on the lifecycle
of data objects and identifies such 4. Undefined (–)
anomalies.
 Data object exists but has no valid
value

2. Data Object – Definition (2 Diagram to Draw (VERY


Marks) IMPORTANT)

A data object is a program entity that Undefined


holds data values during program |
Define
execution. |
Use
Examples: |
Kill
 Variables
 Arrays (Just boxes and arrows — simple and neat)
 Records
 Files
 Data structures
4. Data Object Usage (4 Marks)
Each data object undergoes different states
and uses during execution. A data object can be used in three
different ways:

1. Data Used as Parameter


3. Data Object States (6 Marks)
 Passed to functions or modules
A data object can exist in the following  Example: sum(a, b)
states:
2. Data Used for Control
1. Defined (d)
 Used in decision-making
 Memory is allocated and a value is statements
assigned  Example: if (x > 0)
 Example: x = 10
3. Data Used for Information
2. Used (u)
6========== 6. Data Flow Testing (6 Marks)

 Used to store or display Definition:


information
 Example: printing values, logging Data Flow Testing is a structural testing
technique that focuses on:
Improper usage leads to data-related
bugs.  Definitions of data objects
 Uses of data objects
 Paths between definition and use
5. Data Flow Anomalies (6 Marks) It is used to detect data flow anomalies.

Definition:

A data flow anomaly occurs when a data 7. Data Flow Testing Strategies (4
object is used in an illogical or Marks)
unreasonable sequence during program
execution.
1. All-Definitions Strategy
Common Data Flow Anomalies:  Every definition of a variable is
tested at least once
1. Use Before Definition (u before
d)
o Variable is used without
2. All-Uses Strategy
initialization
 Every definition is tested against
2. Define Twice Without Use (d d)
all possible uses
o Redefining data without
using previous value
3. Define but Never Use (d without 3. All DU-Paths Strategy
u)
o Wasted memory and logic  All definition–use paths are tested
error  Strongest but expensive strategy
4. Use After Kill (u after k)
o Accessing deallocated data
5. Kill Without Use (k without u)
o Data destroyed without
8. Importance of Data Flow Testing
being used (3 Marks)

Diagram to Draw (Anomaly  Detects errors missed by path


Representation) testing
 Finds uninitialized and unused
d → d (Define twice) variables
u → d (Use before define)  Improves program reliability
k → u (Use after kill)  Essential for safety-critical systems

You might also like