Unit -3

Integration testing, System Testing, Interaction testing

 SYLLABUS

 Integration Testing: A Closer Look at the SATM System

 Levels of Testing:
 The SATM System, Structural and Behavioural Insights.
 Decomposition-Based Integration
 Top Down Vs Bottom Up Integration,
 Sandwich Integration,
 Call Graph-Based Integration, Pair wise Integration, Neighborhood Integration, Path-
Based Integration.
 System Testing: Threads, Basic concepts for requirements specification, Finding
threads, Structural strategies and functional strategies for thread testing,
 Interaction Testing: A Taxonomy of Interactions, Static Interaction in a Single
Processor, Static Interaction in Multiple Processors, Dynamic Interaction in a Single
Processor, Dynamic Interaction in Multiple Processors, Client-Server Testing.
SHIVANJALI KESHARWANI
 Integration testing
 It involves testing the interactions between integrated units or components
to ensure they work together as expected .
 The focus is to detect interface defects and ensure that the integrated
components function correctly as a whole.
 It tests :
 Interfaces
 Interactions and
 Overall functionality

SHIVANJALI KESHARWANI
 Features of Integration Testing
 Interaction Testing- It focuses on the communication between the different modules
or components ,how they work well together
 Interface Validation- It effectively validates the interfaces between the modules. This
involves checking data exchange, method calls and communication protocols
 Dependency management –It ensures that changes in one module does not impact
the other interconnected modules adversely
 Incremental approach – It proceeds in an incremental fashion starting from
individual units and gradually integrating them to form larger components which
helps to detect the integration issues early.
 Types of integration – Each type of integration testing (top-down,bottom-up etc. )
focuses on a integrating components in a specific order.

SHIVANJALI KESHARWANI
 Features of Integration Testing

 Fault detection – It aims to detect faults that may arise due to

integrating of different modules .It simulates real interactions and
helps in early detection of bugs which may not be detected
apparently.
 Automation – Automation tools used for the testing helps in
streamlining the testing process in an effective manner
 System Behaviour Validation – It validates the overall behaviour and
performance of the software system by testing the integrated
systems as whole.

SHIVANJALI KESHARWANI
Types of Integration testing

Integration
testing

Decomposition Call – Graph

Based Path Based
Based

Top- Down Bottom- up Sandwich Pairwise Neighbourhood

Integration Integration Integration integration Integration

SHIVANJALI KESHARWANI
 1. Decomposition based Integration
 Decomposition-based integration testing is an approach used to test the interfaces among
separately tested units. In this view of integration, all the units are compiled together and tested
at once. They are of following types :
1. Top-Down Integration: This approach starts with the highest-level modules and progressively
integrates lower-level modules. It’s like building a pyramid from the top down.
2. Bottom-Up Integration: Here, we begin with the lowest-level modules and gradually integrate
higher-level modules. It’s akin to constructing a pyramid from the bottom up.
3. Sandwich Integration: This combines elements of both top-down and bottom-up approaches. It
integrates some high-level modules, then adds lower-level modules, creating a “sandwich” effect.

SHIVANJALI KESHARWANI
1.1 Top-Down Integration testing

 In this strategy ,the focus is on integrating and testing the main control
modules or components first followed by the integration of subordinate
modules .
 The top-down testing strategy deals with the process in which higher level modules are
tested with lower level modules until the successful completion of testing of all the
modules.
 Major design flaws can be detected and fixed early because critical modules tested first. In
this type of method, we will add the modules incrementally or one by one and check the
data flow in the same order.

SHIVANJALI KESHARWANI
 1.1 Top-Down Integration testing -
Working

Start with Subordinate Continue

Incremental
Main module Using stubs testing
Integration
module integration downwards

SHIVANJALI KESHARWANI
1.1 Top-Down Integration testing-
Example
 Suppose we have an online banking application with the following modules:
1. Authorization Module: Responsible for user authentication and authorization.
2. Personal Cabinet Module: Displays user account information, transaction history, and
other personal details.
 Integration Testing Objective:
 Our goal is to ensure correct integration between the “Authorization” module and the
“Personal Cabinet” module. Specifically, we want to verify that user data is displayed
accurately in the personal cabinet after successful authorization

SHIVANJALI KESHARWANI
1.1 Top-Down Integration testing-
Example
 Steps for Top-Down Integration Testing:
1. Start from the Top Module (Authorization):
1. Begin by performing unit testing on the “Authorization” module alone.
2. Ensure that user login, session management, and access control work as expected.
2. Integrate Lower Modules (Personal Cabinet):
1. Next, integrate the “Personal Cabinet” module with the “Authorization” module.
2. Verify that user data (such as account balances, transaction history, and profile details) is
correctly retrieved and displayed in the personal cabinet.

SHIVANJALI KESHARWANI
1.1 Top-Down Integration testing-
Example
3. Stubs and Drivers:
1. During integration, use dummy programs called stubs and drivers.
2. Stubs simulate the behavior of unintegrated lower-level modules, producing
the same output as the actual components.
3. The main module (in this case, the “Authorization” module) serves as the test
driver, while stubs replace components directly under its control.
4. Gradually replace stubs with actual components to complete the integration.

SHIVANJALI KESHARWANI
1.1 Top-Down Integration testing-
Example
What Are Stubs and Drivers?
•Stubs:
• Act as temporary replacements for lower-level modules (modules
that are called by the module under test).
• They simulate the behavior of the actual module by returning
hardcoded or expected outputs.
• Used in top-down integration testing.
•Drivers:
• Used to call and test a lower-level module when the higher-level
modules (which would normally call it) are not yet available.
• Essentially serve as a temporary caller or “main” function.
• Used in bottom-up integration testing.

SHIVANJALI KESHARWANI
1.1 Top-Down Integration testing

 Advantages:
• Identification of defect is difficult.
• An early prototype is possible.
 Disadvantages:
• Due to the high number of stubs, it gets quite complicated.
• Lower level modules are tested inadequately.
• Critical Modules are tested first so that fewer chances of defects.

SHIVANJALI KESHARWANI
1.2 Bottom –up Integration Testing

• Bottom-up testing involves testing individual components or modules of a program

independently.
• These tested modules are then progressively combined to form larger, more complex
parts until the entire system is tested as a whole
• In this the focus is on lowel-level modules to be integrated and tested first and then
towards integrating higher-level modules (that depend on already tested lower level ones)
• Drivers are used to simulate the behavior of higher leve lmodules that are not yet
developed and integrated.

SHIVANJALI KESHARWANI
1.2 Bottom –up Integration Testing-
Working

Start with Higher level Continue

Incremental
Lowest Level Module Using Drivers testing
Integration
Module Integration upwards

SHIVANJALI KESHARWANI
1.2 Bottom –up Integration Testing-
Example
E-commerce application :
• Lowest Level modules : Payment processing,Inventory management
• Higher level module : order fulfillment
1. Lowest Level module testing :
 Testing the Payment processing module responsible for payment transactions ,functionality like
payment validation ,processing with bank is verified and tested
 Inventory management that tracks the product availability is checked.
2. Higher- Level Module testing :
 Integrating the Inventory management module with payment processing module
 Drivers are used to simulate the Order Fulfillment (higher level module)module’s behavior
 Inventory management and Payment processing are tested in conjunction

SHIVANJALI KESHARWANI
1.2 Bottom –up Integration Testing-
Example
3. Further Integration : The order fulfillment is integrated with Payment processing and Inventory
management modules .
 Drivers are replaced with actual modules as they become available
 Order processing and shipment handling are tested in integrated system
4. Complete System Testing :
 Once all the modules are integrated ,end-to-end testing is performed to ensure that the entire
e-commerce application functions correctly.
 Data flow ,error handling and system performance are evaluated as a whole.

SHIVANJALI KESHARWANI
1.2 Bottom –up Integration Testing

1. Advantages:
1. Early Detection: Bottom-up testing identifies issues at the component level, allowing early
detection of defects.
2. Parallel Development: Developers can work on individual modules simultaneously.
3. Focused Testing: Each module is thoroughly tested before integration, ensuring robustness.
2. Disadvantages:
1. Stubs Required: Stubs (dummy programs) are needed for untested modules during integration.
2. Complexity: Assembling the entire system from the bottom up can be complex.
3. Integration Effort: The effort required for integration increases as more components are added

SHIVANJALI KESHARWANI
1.3 Sandwich integration testing
 Testing begins by integrating and testing main control modules at the top
level and individual modules are the bottom level in parallel.
 As testing progresses, integration moves towards middle layer,where both
components are integrated.
 Such integration is tested for interactions between the top and bottom
layer.
 Integration is then done incrementally maintaining the interactions go
smoothly and finally a comprehensive test ,checks for the entire system
integrity

Simultaneous Middle Layer Validation and Incremental Comprehensive

Integration Integration Verification Approach Testing

SHIVANJALI KESHARWANI
 1.3 Sandwich integration testing-
Example
 Social Media Platform

1. Top-Down Testing Approach User

•Start by validating the user interface (UI) layer. Test how users Interface
interact with the new UGC feature.
•Verify that users can create, edit, and delete posts, comments,
and media (images, videos). Business
•Ensure the UI components (buttons, forms, etc.) behave as Logic
expected.
•Stub out the lower layers (business logic and data access) to
simulate interactions with the backend. Data access
layer (Database)
SHIVANJALI KESHARWANI
1.3 Sandwich integration testing

 Advantages:
• Fault localization is easier. If a fault is found during testing, it is easier to localize because it
is likely to be caused by a top-level module or a lower-level module that has already been
tested.
• Time- savings. Testing can start earlier because you don't have to wait until all modules
are developed.
• Critical modules are tested in priority order. This can help identify and fix critical bugs
early in development when fixing them is easier.
 Disadvantages:
• More stubs and drivers are required.
• Lower-level modules may not be tested adequately.

SHIVANJALI KESHARWANI
 2.Call Graph Based Testing
Call Graph-based Integration Testing is an approach that uses the call graph to analyze the relationships
between different modules or components in a software system to guide integration testing.
By examining the call graph,testers can identify the flow of control and data between components .This helps
in identifying the priorities for integration testing based on dependencies.
• The call graph is a directed, labeled graph that shows how a module or function calls each other.
• Each module or function is a node or Vertex
• Vertices represent program units (e.g., methods or functions).
• Directed edges connect calling vertices to called vertices.
• It captures the calling relationships between different program units.
• It avoids the effort of development of stubs and drivers.

• Example if a node A calls node B ,there will be an edge between A and B .

SHIVANJALI KESHARWANI
Call Graph Based Testing –
Characteristics
 Call graph generation-illustrates the relationships between the modules or
functions in the software system.
 Identifying dependencies-analysis of call graphs to identify the
dependencies between the components like function calls ,data
exchange, control flow
 Prioritizing Integration Testing- priorities are set based on dependencies and
interactions to focus on critical paths and interactions between modules.
 Testing scenarios – Test cases are developed to cover interactions identifies
in call graph.
 Regressing testing- when changes are made to the software, testing helps
in identifying potential regression issues.

SHIVANJALI KESHARWANI
Call-graph Based Integration testing

Advantages Disadvantages
 Dependency visualization  Complexity
 Focused Testing  Dynamic environments
 Early issue detection  Tool dependency
 Efficient testing

SHIVANJALI KESHARWANI
Example-Call Graph Based Integration
testing

SHIVANJALI KESHARWANI
Call graph testing-Types

1. Pair-wise Integration Testing:

1. Tests all pairs of units that call each other.
2. Ensures that interactions between units are correct.
2. Neighborhood Integration Testing:
1. Focuses on testing within units and their neighboring call units.
2. Matches well with development and builds.


SHIVANJALI KESHARWANI
2.1 Pairwise Integration Testing

 It is a systematic testing technique that focuses on testing interaction

between pairs of modules or components in a software system.
 It's based on the idea that most defects are caused by interactions
between two parameters, not all.
 This saves time ,as various combination of pairs of modules are tested in
parallel
 this creates minimum test cases, reduces testing efforts and cover
maximum area of test cases.
 If the test fails in a pair, the fault must be in one of the pair of nodes.

SHIVANJALI KESHARWANI
Example

SHIVANJALI KESHARWANI
Example : Searching a you tube video
based on different filters
Upload
Type Duration Features Sort By
date

Under 4
Last hour Video Live Relevance
min

Upload
Today Channel 4-20 min 3D
date

Above 20 360
This week Playlist Rating ..
min degree

Last hour Movie ..

SHIVANJALI KESHARWANI
Example -explanation

 Instead of testing every possible combination of all 5 parameters (which would

be huge — 3×4×3×4×3 = 432 combinations), pairwise testing reduces the test set
by ensuring each pair of parameter values is covered at least once.
For example:
• A test case with:
• Upload date = "Today"
• Type = "Video"
• Duration = "Under 4 min"
• Features = "Live"
• Sort By = "Upload date“
might be chosen because it covers the value pair: (Type = Video, Duration = Under 4
min), and (Upload date = Today, Sort by = Upload date), and so on.

SHIVANJALI KESHARWANI
 Example continues (PTI)

T.ID Upload time(A,B) Types (M,N) Duration(X,Y)

 After applying 4-5 filters,there can be various permutation and
1 A
combinations M in 100-200 test Xcases
of filters.This results
2 A
 Pairwise M
testing induces less number Y
of test cases
3 A N X
4 A N Y
5 B M X
6 B M Y
7 B N X
8 B N Y

If there is a bug with test case 1 ,for (A,M) and test case 6 (M,Y) ,we can
discard test case 2 ,as the same has been tested in test case 2
SHIVANJALI KESHARWANI
Characteristics –Pairwise Testing

 Pair Selection-based on their dependencies and interactions

 Testing Scenarios- designed covering interactions between each pair of
modules
 Isolation of Pairs- Each pair tested separately to identify integration issues
 Combinatorial testing – all possible combination of interactions to cover
comprehensively
 Error detection- helping in early issue detection

SHIVANJALI KESHARWANI
Working-

2.Design test 4.Combinatorial

1.Select Pairs 3. Pairs Isolation
cases testing

5.Execute and 6.Issue 7. Re-testing to

analyse all the identification identify and
test cases and Resolution resolve issues

SHIVANJALI KESHARWANI
Pairwise Integration testing

Advantages Disadvantages
 Efficient coverage  Dependency identification can
be challenging
 Focuses testing
 Test case design complexity
 Early issue identification
 Dynamic systems
 Reduced test effort
 Limited scope
 Optimized testing
 Maintenance overhead

SHIVANJALI KESHARWANI
 2.2 Neighbourhood Integration testing
 The neighbourhood of a node is the node that is one edge away from the
node
 This testing focuses on testing the interactions and integration between
modules or components under test and its neighbouring modules or
components within a software system .
 It ensures smooth functioning and integration with neighbouring modules .

Last Monday of
may in US
memorialDay
celebrated in has
memory of US
military personnel
neighbour as
isMonday
A day which is
Friday and has
date 13
considered as
unlucky in US SHIVANJALI KESHARWANI
Characteristics

 Testing directly dependent module neighbours

 Clustered testing
 Inter-module communication
 Dependency validation
 Functional cohesion (all work together for a common functionality)

SHIVANJALI KESHARWANI
Working

1. Identify the 2.Define the 3. Design Test 4.Integration

clusters test scope cases testing

8.Collaborative 7.Regression 5. Boundary

6.Error handling
issue resolution testing testing

SHIVANJALI KESHARWANI
 Ecommerce
Example
1. Cluster Identification :
All modules due to their
dependencies, are identified User Product
as neighbourhood clusters Shopping cart
Authentication Catalogue

2. Define the test scope: User login, Product display, Adding/removin

Limit the testing for these authentication, Product g items to/from
clusters session information, cart, calculate
management search totals and
3. Desing test cases : functionalities manage
Case 1 : Verify the logged in
shopping cart
user can add items from
state
product catalogue to shopping
cart
Case 2 : Shopping cart items
are updated ? When items are
added or removed
Case 3 : Verify whether
authenticated user
SHIVANJALI can access
KESHARWANI

the shopping cart?

 Ecommerce
Example
4. Integration testing
Execute the test scenarios to User Product
ensure proper integration Shopping cart
Authentication Catalogue
5. Boundary testing
In case large number of items are User login, Product display, Adding/removing
added in the cart authentication, Product items to/from cart,
session information, calculate totals
6. Error handling : management search and manage
Validate incorrect login
functionalities shopping cart
credentials, out-of-stock products
or invalid cart operations state
7. Regression testing :
Performance testing after any
updates
8. Collaboration issues handling :
Collaborate with developers for
handling any integration issues
identifies SHIVANJALI KESHARWANI
Neighbouring Integration testing

Advantages Disadvantages
 Focused testing  Limited scope
 Early issue detection  Dependency risks
 Improved collaboration  Integration gaps
 Efficient testing  Complexity management
 Enhanced stability  Maintenance challenges

SHIVANJALI KESHARWANI
 3. Path Based Integration Testing

 It is a testing approach that focuses on validating the flow of data and

sequence
control between interconnected modules or components within a software
system along specific paths or sequences .
 It verifies the correct execution of certain critical paths ensuring correct
data processing and control transfer
 It focuses on interaction between the units rather than testing the separate
units
 It consists of Source node (main node) and sink node (end nodes) without
If-then-else any intervening nodes.
 It is mostly applicable to units and modules ,but not flow in the complete
system

SHIVANJALI KESHARWANI
Characteristics- PB testing
Path
Identification

Path
selection

Data flow
validation

Control flow
verification

Error handling
testing

Integration
SHIVANJALI KESHARWANI
point testing
Working- PB Testing

2.Select the 3. Design Test

1.Identify Paths
critical paths cases

6.
4.Path 5.Result
execution analysis Issue
Resolution

SHIVANJALI KESHARWANI
 Example- PB Testing
1. Identify Paths : User
All Paths for fund transfer Authentic
ation
2. Path Selection Updating
Select the critical path for fund a/c Selecting
transfer balances & transfer
Send option
3. Design test cases : notification

Funds
Transfer
Processing Entering
the transfer
transfer option

Verifying
transactio
SHIVANJALI KESHARWANI n
Path-1 :All valid
 User Authentication → Select Transfer Option → Enter Details → Verify → Process → Update &
Notify
 Test Case: All correct inputs
Expected Result: Transfer success, notification sent
Path-2 :(Authentication Failed):
 User Authentication → [Fail] → Terminate
Expected Result: Show error, stop process
Path-3 (Invalid Transfer Option):
 User Authentication → Select Transfer Option → [Invalid Entry] → Terminate
Expected Result: Show input error, stop process
Path-4 (Verification failed)
 User Authentication → Select Transfer Option → Enter Details → Verify → [Fail] → Terminate
 Expected Result: Verification failure message, no funds transferred
Path-5 (Transfer Process Error):
 User Authentication → Select Transfer Option → Enter Details → Verify → Process → [Fail] →
Terminate
Expected Result: Processing error, rollback initiated
SHIVANJALI KESHARWANI
Levels of Testing

 Unit Testing
 Integration testing
 System testing

SHIVANJALI KESHARWANI
 Waterfall model

The waterfall model is a software development

model used in the context of large, complex projects,
typically in the field of information technology. It is
characterized by a structured, sequential approach
to project management and software development.

1. It follows a sequential model ,hence requires accurate

planning and efforts before it is actually executed
2. It is inflexible model,hence changes once done cannot
be reverted ,it done ,requires cost overheads

SHIVANJALI KESHARWANI
 Waterfall Model

Requirement System testing

Specifications

Preliminary design Integration Testing

Detailed design Unit Testing

SHIVANJALI KESHARWANI
Coding
 Alternative life cycle methods

 New alternative models have been devised to replace the existing drawbacks of e
 Shifting from functional decomposition to composition models
 Functional decomposition is fit for Top-don and bottom-up -> This requires complete knowledge
of the requirement before itself .

 This results in a big gap between the requirement specification to completed system
 Alternative to this is COMPOSITION is closer to how people work actually
 Composition means gradually
 adding units
 development
 increment
 evolving units
 This is like a big bang development where every phase runs in parallel together. It reuires removing
unwanted andKESHARWANI
SHIVANJALI adding the required ones
Waterfall Spin offs

 There are three main derivatives of waterfall model

1. Incremental model
2.Evolutionary model
3.Spiral model
 Each of these involves a series of increments or builds.
 Here the system testing is divided into two types :
 Regression testing - It confirms that things that worked correctly in the earlier
build still work with newly added code
 Progressing testing – It assumes that regression testing was successful and that
the new functionality can be testd

SHIVANJALI KESHARWANI
 Requirement
Detailed design specification

Preliminary Design
Coding

Series Build
Unit testing

Integration testing

SHIVANJALI KESHARWANI
Regressing testing
Progressing Testing
Other models

SHIVANJALI KESHARWANI
SATM System
Simple Automated Teller Machines
 It is designed as a teaching tools or simplified version of a commercial ATM
system containing only the essential features required to perform basic ATM
functions like transactions and user interactions.
 SATM system consists of two components :
 Screens and Terminal Layouts : The screen illustrates the user interface flow, that
demonstrates how the users interact with the system through various screens. For
example : entering PIN,selecting transaction type,receiveing notificaitons etc.
 The SATM terminal : It details the physical components of the ATM such as the
ATM such as the keyboard for input, a screen for display,a card reader,receipt
printer and cash dispensing units.This is crucial in understandin user interactions
with the system and planning the physical security measures and usability testing.

SHIVANJALI KESHARWANI
SATM System
Simple Automated Teller Machines
 To understand the SATM system, we use three complementary models:
• Functional Model: Represented using dataflow diagrams.
• Data Model: Utilizes the Entity-Relationship (E/R) model.
• Control Model: Modeled as a finite state machine

SHIVANJALI KESHARWANI
1.Functional Model :
•Context Diagram: Provides an overview of the SATM system’s interactions with external entities.
•Level 1 Data Flow Diagram: Breaks down the system’s processes and data flows

SHIVANJALI KESHARWANI
1.Functional Model :
•Level 1 Data Flow Diagram: Breaks down the system’s processes and data flows

SHIVANJALI KESHARWANI
1.Functional Model :
 Simple ATM System : Central to the diagram is the ATM machine that
 External Entities and interactions :
 Terminal Keys : users input data like PIN, transaction choices ,which are processed by the ATM
system.
 Terminal Screen : Displays transaction information ,instructions and prompts to the user controlled
by the ATM system based on the user inputs and transaction status.
 Terminal Slots and doors : for card inputs,money dispensing,receipt printing .The ATM system sends
commands based on user requests and transaction requirements.
 Data flows :
 Keystrokes to system: data from user inputs to ATM for processing
 Information to screen : data from ATM system to the screen
 Commands to slots/doors : control commands for mechanical actions like closing and opening
doors/slots for money dispensing,card accesing etc.
 Integration with Central Bank : ATM communication to central bank for
▪ Authenticate transactions
▪ Check balance
▪ Account updates
SHIVANJALI KESHARWANI

▪ Ensure secure and accurate banking transactions

2. Data Model (Entity/Relationship Diagram):
The data model uses an Entity/Relationship (E/R) diagram to depict the major data structures
within the SATM system.
Key entities include customers, accounts, terminals, and transactions

SHIVANJALI KESHARWANI
 2. Data Model (Entity/Relationship Diagram):

Entities and their Attributes : (CASTT)

• Customer – Identified by Customer Id and PAN (Personal Accont Number)
• Account - AcctNumber,Balance,Type,PIN
• Transaction- Transtype,TimeofDay,Amount,ATMNumber.
• Terminal- ATMid,Status,CasonHand

Relationships :
• Has –
• Uses-
• Occurs-
• Session-

SHIVANJALI KESHARWANI
3. Control Model (Finite State Machine):
While dataflow and E/R models focus on structure, the control model addresses system
behavior.
The SATM system’s behavior is captured using a finite state machine.
Finite state machines can be hierarchically decomposed to represent different system
states and transitions . The following example is for PIN entry process

SHIVANJALI KESHARWANI
3. Control Model (Finite State Machine):

1. States :
1. Idle
2. Legitimate card Display Screen S2
3. Awaiting First PIN try
4. Awaiting Second PIN try and Awaiting Third PIN try
5. Correct PIN Display Screen S5
6. Awaiting Transaction choice
2. Transitions :
1. From Idle to legitimate card
2. Incorrect PIN
3. Correct PIN

3. Error Handling : Wrong card Display Screen S1 ,Eject card

4. Conditions : Limited PIN attempts to three,enhances user experiences by
providing immediate feedback on PIN entry status,transiton to Await Transaction
choice after a correct PIN entry helps connect user authentication to transaction
operations smoothly.
5. Use in Testing : Each transition and state can be explicitly tested to ensure the
ATM’s software handles all possible scenario correctly ensuring robust handling of
SHIVANJALI KESHARWANI

user’s inputs and errors.

SHIVANJALI KESHARWANI
Unit -3 (Part-2)
System Testing & Interaction testing
 SYLLABUS

 System Testing: Threads, Basic concepts for requirements specification, Finding

threads, Structural strategies and functional strategies for thread testing,
 Interaction Testing: A Taxonomy of Interactions, Static Interaction in a Single
Processor, Static Interaction in Multiple Processors, Dynamic Interaction in a
Single Processor, Dynamic Interaction in Multiple Processors, Client-Server Testing.

MADE BY SHIVANJALI KESHARWANI

System Testing

 There are three levels of testing amongst which System testing focuses
on customer’s expectations based on his requirements.
 It doesn’t focuses on finding faults but to demonstrate performance
 The testing has an approach towards testing performance and
functional attributes rather than structural aspects.

“System testing is the phase in the software testing process where the
complete integrated system is evaluated to ensure that it meets specified
requirements”.

MADE BY SHIVANJALI KESHARWANI

Atomic System Function (ASF)

“An Atomic System Function (ASF) is smallest unit of functionality within a

system that can be independently tested .Each ASF represents a single
indivisible operation that the system can perform”.
 These operations contribute directly to the overall behaviour and
functionality of the system.
 The ASFs are self-contained meaning they do not need to be decomposed
further for the purpose of testing.

MADE BY SHIVANJALI KESHARWANI

 Characteristics of ASF
 Granularity –smallest units of functionality
 Independence-they operate independently without relying on other functions
 Specificity -focus on specific actions or functions
 Self-contained -they have all the necessary logic and data to perform their
function
 Re-usability – can be reused across the entire system
 Clarity – have clear and concise definitions and purpose
 Modularity – each ASF represent a distinct module that can be tested ,maintained
 Testability- their granular and specific nature makes them straightforward to test
 Documentation – can be documented with all its attributes and functionality
 Interoperability- though they are independent ,they can interact seamlessly with
other units
MADE BY SHIVANJALI KESHARWANI
Understanding ASF :
Example ––Withdrawal function in ATM
List of Interconnected ASFs :
 Insert card
ASF
 Enter PIN
 Select withdrawal amount
 Verify Account Balance
 Dispense cash

MADE BY SHIVANJALI KESHARWANI

Example ––Withdrawal function in ATM

 Characteristics :
 Granularity- taking and verifying PIN
 Independence- entering PIN can be tested independently
 Specificity- has clear ,concise purpose- accepting and verifying PIN
 Self-contained – This function includes all the logic needed to accept user input and
verify the PIN against stored data
 Test Scenarios :
 Correct PIN
 Precondition : stored PIN is 1234
 Test input : user enters 1234
 Expected outcome : PIN is verified successfully and the system proceeds to the next
steps
MADE BY SHIVANJALI KESHARWANI
Example ––Withdrawal function in ATM

 Incorrect PIN :
 Precondition : stored PIN is 1234
 Test input : user enters 4231
 Expected outcome : PIN verification fails and the system prompts the user to re-
enter the PIN
 Maximum attempts exceeded :
 Precondition : stored PIN is 1234,the user has already entered incorrect PIN twice
 Test input : user enters 4231
 Expected outcome : PIN verification fails ,the system locks the card ,and the user
is prompted to contact their bank.

MADE BY SHIVANJALI KESHARWANI

 Concept of Threads

“A thread in system testing is a sequence of interconnected ASFs that together

accomplish a specific user task or workflow in a system”.
 It includes all the steps a user takes to achieve a particular outcome to ensure that
the system correctly executes the complete sequence of operations required.
 Example : Withdrawal of cash -> Thread name
 List of ASFs in the thread :
1. Insert card
2. Enter PIN
3. Select withdrawal amount
4. Verify Ac balance
5. Dispense cash
6. Print Receipt
7. Eject card
MADE BY SHIVANJALI KESHARWANI
 Concept of threads Aid to Memory :SSS-BI-MAS

 We view system testing in terms of threads of system level behaviours

 Many possible views of a thread :
 A scenario of normal usage (multithreading, UI, parallel processing, resource sharing)
 A system level test case
 A stimulus/response pair
 Behaviour that results from a sequence of system level inputs
 An interleaved sequence of object messages and method execution (MM path)
 A sequence of machine instructions.
 A sequence of source instructions.
 A sequence of atomic system functions .

MADE BY SHIVANJALI KESHARWANI

Different levels of threads

 A UNIT LEVEL thread is usually understood as an execution-time path of

source instruction or alternatively as a sequence of DD path.
 An INTEGRATION LEVEL thread is an MM path –that is an alternating
sequence of module execution paths and messages.
 A SYSTEM-LEVEL THREAD is a sequence of atomic system functions

(MM path- feasible path of execution)

 A unit testing tests individual functions
 An integration test examines interaction among units
 System testing examines interactions among atomic system functions.

MADE BY SHIVANJALI KESHARWANI

MADE BY SHIVANJALI KESHARWANI
 Different Types of Threads

1. Unit level Threads : Smallest testable parts of a system like individual functions or
methods within a module.
Eg .
Function: add(a, b)
• Thread: Test the function with different pairs of numbers to ensure it returns
the correct sum.
• Test Cases: add(2,3), add(-l, 5), add(0,0]
Validation Function:
• Function: isValidEmail(email)
Thread: Check the function with different email formats to ensure proper
validation.
Test Cases-. isValidEmail[”[email protected]“)->true ___________
isValidEmail["ss@gmaii")
MADE BY SHIVANJALI KESHARWANI -> false
 Different Types of Threads
2. Integration level Threads :focus on interactions between different modules or components to
ensure they work together correctly.
Database Interaction
Scenario: Test the interaction between a data access module and the database.
Thread: Verify that data is correctly retrieved, inserted, updated, and deleted.
Test Cases ; Retrieve user data, insert a new record, update an existing record, delete a record.
(CRUD)
3. System level Threads :System-level threads involve testing the complete and integrated
system to ensure it meets the specified requirements. These threads simulate real-world
usage scenarios.
E-commerce Checkout Process
Scenario: Test the entire checkout process in an e-commerce application.
Thread ; Simulate a user selecting items, adding them to the cart, entering shipping information,
making a payment, and receiving an order confirmation.
Test Cases: Add items to cart, proceed to checkout, enter shipping details, select payment
method, complete payment,
MADE BY SHIVANJALI verify order confirmation
KESHARWANI
 Thread possibilities
 The endpoints of threads needs to be defined as in where they start and where they
end.
 This is done using graph theory based definitions.
 In graph theory, the threads can be viewed as series of nodes interconnecting each
other with a definite start and end points .
 By working backward from the outcome, we can trace the entire user journey through
the system
 Here there are four candidate threads in our SATM system
 Entry of a digit - simplest ,granular thread representing Min ASF – Port input,Port output –
Stimulus /response pair
 Entry of PIN – common ASF ,which acts as a bridge b/w integration Testing and system testing
 A simple transaction : ATM card entry,PIN entry ,select transaction ,present account details, and
reports the results -
 An ATM session containing two or more simple transactions

MADE BY SHIVANJALI KESHARWANI

 Thread possibilities
Thread candidates :
1. Enter a digit - > Simplest and most granular -Minimal ASF
 It begins with
 a port input (digit keystroke) and ends with
 a port output event (the screen digit echo)
so it is a good example of stimulus/response pair
2. PIN entry -> it is the starting point of the system testing. Good example of ASF. It is the bridge between the
integration testing and system testing.
1. Screen Request: A prompt requesting PIN digits.
2. User Input: An interleaved sequence of digit keystrokes.
3. System Feedback: Screen responses echoing the digits.
4. Cancellation Option : The possibility for the user to cancel the operation before completing the PIN entry.
5. System Disposition:
Correct PIN : After a correct PIN is entered within three attempts, the system displays a screen requesting
the transaction type.
Incorrect PIN : If the PIN is incorrect after three attempts, the system advises the customer that the ATM
card will not beBYreturned,
MADE and access to ATM functions is denied.
SHIVANJALI KESHARWANI
 Thread possibilities

3. The simple transaction – This thread represents a complete, end-to-end user transaction
commonly executed by customers.
Sequence:
1. Card Entry: User inserts ATM card.
2. PIN Entry: User enters their PIN.
3. Transaction Selection : User selects the transaction type (e.g., deposit or withdrawal).
4. Account Details: User provides account details (checking or savings, amount).
5. Conduct Operation: The system processes the transaction.
6. Report Results: The system reports the transaction results and returns the card.
This is a good example of a system-level thread involving the interaction of several ASFs. It ensures
the end-to-end completion of a transaction, making it an ideal candidate for system testing.
MADE BY SHIVANJALI KESHARWANI
 Basic concepts for requirements
specification
 Every system can be modeled in terms of some five
fundamental concepts and every requirements
specification model uses some combination of these.
Data
 Each concept plays a crucial role in defining how a
system operates and how it can be tested effectively.

Threads Action

Requirement
Specifications

MADE BY SHIVANJALI KESHARWANI

Devices Events
 Basic concepts for requirements
specification
 .
DATA
Information used and created by system

• Includes variables, data structures, fields,

records, data stores, and files
• ER models – relationships between data entities
• CRUD operations

Example : In the SATM system, data includes account information, such as

Account Number, Account Type, PINs, and account balances. For instance,
each account might have a data structure with the account type. Expected
PIN,BYand
MADE current
SHIVANJALI KESHARWANIbalance. As ATM transactions occur, the system updates this

data
 Basic concepts for requirements
specification

ACTION
operations performed by the system
• transforms, processes, activities, tasks, methods, or
services.
• Actions have inputs and outputs, which can be data
or events.
• They can be decomposed into lower-level actions,
particularly in methodologies like Structured Analysis
with data flow diagrams.

Example : An action in the SATM system could be the process of verifying a

PIN. This action takes the entered PIN as input, compares it with the stored
PIN, and produces an output indicating whether the PIN is correct or
incorrect.
MADE BY SHIVANJALI KESHARWANI
Basic concepts for requirements
specification
Devices
Devices, or ports, are the
sources and destinations of
system-level inputs and outputs.

keyboards, screens, and card readers, which

translate physical actions (like keystrokes) into
logical events and vice versa

Example: The SATM system includes devices such as the keypad for
entering PINs, the display screen for showing prompts and transaction
results,
MADE the
BY SHIVANJALI card reader for reading ATM cards, and the cash dispenser
KESHARWANI

for dispensing money

Basic concepts for requirements
specification
Events
system-level inputs or outputs
that occur at port devices.

discrete (like keystrokes) or continuous (like

temperature readings). Events translate real-
world actions into logical actions within the
system and vice versa.

Example : In the SATM system, pressing a key on the keypad generates

an event. For instance, pressing the "1" key sends a digit entry event to
the
MADE system,
BY SHIVANJALI which then processes this input to display the digit on the
KESHARWANI

screen or use it as part of the PIN.

 Basic concepts for requirements
specification Example: A thread in the SATM
system could be the process of
withdrawing cash:
1. Insert ATM card (Device: Card
Threads Reader, Event: Card Inserted).
sequences of actions and 2. Enter PIN (Device: Keypad,
events that achieve a specific Event: PIN Entry).
3. Select withdrawal transaction
user goal [Action: Transaction Selection).
4. Enter amount to withdraw
(Device; Keypad, Event: Amount
interaction among data, events, and actions Entiy).
within the system. Threads are crucial for 5. Verify account balance (Action:
testing complete workflows from the user's Balance Verification).
perspective. 6. Dispense cash (Device: Cash
Dispenser, Event: Cash
Dispensed).
7. Print receipt (Device: Printer,
Event: Receipt Printed).
MADE BY SHIVANJALI KESHARWANI
8. Eject card (Device: Card
Reader, Event: Card Ejected)
Relationships among basic concepts

• The basis concepts are

interconnected through
many-to-many relationships.
• Data and events serve as
inputs and outputs for actions.
• Events occur on devices, and
many events can happen on
a single device.
• Actions can belong to
multiple threads, and threads
are composed of several
actions.

MADE BY SHIVANJALI KESHARWANI

 Finding threads in the system

 In system testing, threads are sequences of actions and events that represent user
interactions within the system to achieve specific goals.
 We need to define and identify these threads for comprehensive system testing.
 Solution - > Use A graph theory-based approach.
 Finite state machines (FSMs) are a powerful tool for modeling these threads, as they
capture the stages of processing and the transitions between them caused by various
events.
 States: Represent different stages in a process, each reflecting a specific condition or situation
within the system. For example, in an ATM system, states can include "Card Entry," "PIN Entry,"
and "Transaction Processing.”
 Transitions: These are the changes from one state to another, triggered by events such as user
inputs or system conditions. In the ATM example, a transition occurs when a user inserts a card,
moving from the "Idle" state to the "Card Entry" state.
MADE BY SHIVANJALI KESHARWANI
General steps for finding thread

 Step 1: Define the Scope of the SATM System

 Step 2: Identify Key User Interactions : Inserting the ATM card. Selecting a
transaction type. Receiving the card and receipt.
 Step 3: Model the System with FSMs :Entering the PIN. & Performing the
transaction.
 (a) Top-Level SATM State Machine:
 (b) PIN Entry Finite State Machine:
 (c) Detailed PIN Entry State Machine :

MADE BY SHIVANJALI KESHARWANI

 General steps for finding thread

(a)Top-Level SATM State Machine:

high-level overview of the ATM system's main
states and transitions.
The primary states include
• Card Entry
• PIN Entry and
• Await Transaction Choice
Transitions between these states are triggered by
events such as
• inserting a legitimate card,
• entering a correct or incorrect PIN, and
• selecting a transaction

MADE BY SHIVANJALI KESHARWANI

 General steps for finding thread

(b)PIN Entry Finite State Machine:

detailed view of the PIN entry process within the
SATM system
States:
• Card Entry
• First PIN Try
• Second PIN Try
• Third PIN Try
• Await Transaction Choice
• Incorrect PIN or Cancelled.
Transitions:
• Correct PIN
• Incorrect PIN
• Cancelled

MADE BY SHIVANJALI KESHARWANI

 General steps for finding thread
(c) Detailed PIN Entry State Machine : a granular
view of the digit-by-digit entry process for the PIN
within the SATM system.
States:
• 0 Digits Received
• 1 Digit Received
• 2 Digits Received
• 3 Digits Received
• 4 Digits Received
• Cancel Hit
• Correct PIN
• Incorrect PIN.

Transitions:
• Digit Entry
• Cancel
• Correct PIN
MADE BY SHIVANJALI KESHARWANI
• Incorrect PIN.
 General steps for finding thread

Step 4 : Identify the Port events :

Port Input Events:

• Digit: User entering digits on the keypad.
• Cancel; User pressing the cancel button. Port

Output Events
• Legitimate Card: Display Screen 2
• Wrong Card: Display Screen 1
• Correct PIN: Display Screen 5
• Incorrect PIN: Display Screen 4
• Cancelled: Display Screen

Step 5 : Create a hierarchy of Port Events

For detailed interactions, use lower-level FSMs like the Detailed PIN Entry
MADE BY SHIVANJALI KESHARWANI
State Machine to capture fine-grained user interactions
 General steps for finding thread

Step 6: Trace Paths Through the FSM s

Example Threads in the SATM System:

1. Thread for Successful Transaction:

Path: Card Entry-> PIN Entry (Correct PIN)-> Await Transaction Choice

2. Thread for Incorrect PIN Entry with Retry:

Path: Card Entry-> PIN Entry (Incorrect PIN)-> Retry Correct PIN -> Await
Transaction Choice

3. Thread for PIN Entry Cancellation:

Path: Card Entry-> PIN Entry (Partial Entry)-> Cancel Eject Card
MADE BY SHIVANJALI KESHARWANI
 General steps for finding thread

Step 7 :Define Test cases based on Threads Steps:

a. Insert ATM card.
Test Case 1: Successful Transaction b. Enter incorrect PIN.
c. Re-enter correct PIN.
• Preconditions: Valid ATM card, correct PIN d. Select transaction type.
• Steps: e. Complete the transaction. f. Receive
a. Insert ATM card. card and receipt.
b. Enter correct PIN.
c. Select transaction type. Test Case 3: PIN Entry Cancellation
d. Complete the transaction. • Preconditions: Valid ATM card.
e. Receive card and receipt. • Steps:
a. Insert ATM card.
Test Case 2: Incorrect PIN Entry with Retry PIN b. Start entering PIN.
• Preconditions: Valid ATM card, incorrect PIN on c. Press cancel.
first attempt, correct PIN on second attempt. d. Card is ejected
MADE BY SHIVANJALI KESHARWANI
 Structural Strategies Thread Testing

Structural strategies for thread testing focus on the system’s architecture and its underlying
state machines (FSMs). These strategies ensure that all possible paths, nodes, and edges in the
state machines are covered during testing.
The goal is to achieve comprehensive coverage by testing all possible transitions and states to
ensure that every part of the system's structure is validated.

MADE BY SHIVANJALI KESHARWANI

 For eg : A node coverage would require testing all states
such as …

1. Node coverage Metrics :

"Card Entry,"

• Node coverage is a
fundamental metric in FSM-
based testing.
• It ensures that every state in "PIN Entry,"
the state machine is visited at
least once during testing
confirming that no nodes are
skipped. ""Await Transaction
Choice"

" "Transaction Processing”

MADE BY SHIVANJALI KESHARWANI
 For eg : edge coverage would require testing transitions such as
from "Card Entry" to "PIN Entry," "PIN Entry" to "Await
Transaction Choice," "Await Transaction Choice" to
"Transaction Processing," and any error handling transitions
2. Edge coverage Metrics :

It extends the concept of node

"Card Entry,"
coverage by ensuring that the
transitions between states are also
tested.

• This metric is critical for

validating the interactions and "PIN Entry,"
sequences within the system.
• This helps identify any issues in
the flow of operations within the
system. ""Await Transaction
Choice"

" "Transaction Processing”

MADE BY SHIVANJALI KESHARWANI
 Example:
In the SATM system, start by testing the detailed digit-by-digit
PIN entry FSM.
Confirm that each digit entered transitions the system to the
next state (e.g., from '1 Digit Received" to “2 Digits Received")
2. Bottom up Testing : and that the cancel operation works correctly.
After validating the digit-by-digit FSM, integrate it with the
Bottom-up testing is a structured higher-level PIN entry FSM to test the complete PIN entry
methodology that begins with the process.
most detailed and specific
components of the system,
progressively integrating and testing
higher levels of the system hierarchy.
Higher level FSM
It ensures that all fundamental
interactions are validated before they
are integrated into more complex
workflows

Lower level FSM

MADE BY SHIVANJALI KESHARWANI
 Functional Strategies Thread testing
 Functional strategies for thread testing focus on the system's functionality
and the behavior specified by the requirements.
 These strategies ensure that the system performs as expected by testing
specific functionalities and scenarios described in the requirements.
 The goal is to validate that the system meets its functional requirements
and behaves correctly in various scenarios.
Functional
Strategies

Event Based Port Based Data Based

Testing Testing Testing
validates the handling
comprehensive coverage of input and output confirms the integrity of
of all user interactions events at each data operations
MADE BY SHIVANJALI KESHARWANI interface
Interaction Testing

 Introduction
A Taxonomy of Interactions
 Static Interaction in a Single Processor,
 Static Interaction in Multiple Processors,
 Dynamic Interaction in a Single Processor,
 Dynamic Interaction in Multiple Processors, Client-Server Testing.

MADE BY SHIVANJALI KESHARWANI

 Introduction- Interaction Testing
 Interaction testing focuses on faults and failures that occur due to
interactions within a system. These interactions are often difficult to detect
as they may remain hidden.
 Interaction faults are difficult to detect because
 they occur under specific conditions that may not be easily replicated during
standard testing procedures.
 They often involve complex dependencies and interactions between different
components of a system, making them less predictable and harder to isolate.

What is Interaction Testing ? .

“Interaction testing involves examining the interactions between various components

of a system to uncover faults that can arise from complex dependencies and
sequences of events ,not immediately noticeable”.

Interaction testing aims to identify and address these issues by focusing on how
different parts of the system interact under various conditions
MADE BY SHIVANJALI KESHARWANI
 Features or Characteristics of CC-SS-CARD

Interaction testing
1. Component Interaction Analysis: Examines how different parts of the system work together.
2. Complex Dependency Testing: Identifies and tests complex dependencies between
components.
3. Scenario-Based Testing: Uses various scenarios to simulate real-world conditions and
interactions.
4. Sequential Event Validation: Checks for issues that arise from specific sequences of events.
5. Comprehensive Coverage: Ensures all possible interactions are tested for faults.
6. Automated Test Execution: Utilizes automated tools to efficiently test numerous interaction
scenarios.
7. Risk-Based Prioritization: Focuses on interactions with the highest potential impact on
system performance.
8. Dynamic Testing: Adapts to changes in the system and tests new interactions as they arise.
MADE BY SHIVANJALI KESHARWANI
 Taxonomy of Interaction testing

Taxonomy of interactions refers to a structured classification system that categorizes different

types of interactions within a system based on specific criteria.
 The main purpose of creating a taxonomy of interactions is to systematically organize and
describe the various ways in which components of a system can interact.
 This facilitates more targeted and effective testing by providing a clear understanding of
the different types of interactions that can occur.

MADE BY SHIVANJALI KESHARWANI

 Types of Interactions in system testing

Interaction
testing criteria

Time Position

Time Single Multiple

Independent processor processor
Interactions interactions

Time
Dependent
MADE BY SHIVANJALI KESHARWANI
 Types of Interactions –Time

1. Time-Independent (Static) Interactions:

 Interactions that are not time-dependent and occur regardless of timing. For instance, interactions between two
data items that occur regardless of when they are accessed or modified.
 Example: When a user approaches the ATM, the machine displays a welcome screen. This interaction involves
the ATM's processor fetching the static welcome message stored in its memory and displaying it on the screen.
The timing of this interaction is irrelevant; the welcome message will always be the same, regardless of when it
is accessed or displayed.
2. Time-Dependent (Dynamic) Interactions:
 Interactions where the timing or sequence of operations is critical. It require specific order or timing. For
example, operations that must occur in a specific order or within a certain timeframe.
 Example : When a user requests their account balance, the ATM sends a request to the bank's server to retrieve
the most up-to-date account balance. This interaction is time- dependent because the account balance can change
with each transaction made by the user or other users. The ATM must request the balance from the bank’s server
at the exact time of the user’s inquiry to provide the current balance.
MADE BY SHIVANJALI KESHARWANI
 Types of Interactions –Position

1. Single Processor Interactions:

 Interactions that occur within a single processing unit. These interactions do not require coordination between
multiple processors and are confined to one processing environment.
 Example : After verifying the user's credentials and checking the account balance, the ATM dispenses the
requested amount of cash. This involves internal operations such as triggering the cash dispenser, updating the
local transaction log, and printing a receipt, all managed by the ATM's single processor The ATM's processor
controls the mechanical components that count and dispense the cash, update the transaction log stored in the
local memory, and print the receipt.

MADE BY SHIVANJALI KESHARWANI

 Types of Interactions –Position

2. Multiple Processors Interactions:

 Interactions that span across multiple processing units. It require synchronization and coordination
between multiple processors .These interactions are more complex due to the need for managing
communication and data consistency between processors.
 Example : When a user requests a balance inquiry, the ATM’s local processor sends a request to the
central bank's server to fetch the latest account balance. This interaction involves the ATM processor
communicating with the remote server, receiving the response, and displaying the balance to the user.
In this case, ATM's server communicates and coordinates with central bank's server and hence it is
considered as multiple processor interactions.

MADE BY SHIVANJALI KESHARWANI

 Types of Interactions in system testing

Interaction testing
criteria

Static interactions Static interactions Dynamic

Dynamic
within single within multiple interactions within
interactions within
processor processor multiple
single processor
processors

MADE BY SHIVANJALI KESHARWANI

 Types of Interactions in system testing

1. Static Interactions in a Single Processor: Interactions independent of time within a single processor.
 Example:: Accessing and displaying the ATM's welcome screen. When a user approaches the ATM the
machine's processor fetches the static welcome message stored in its local memory and displays It on the
screen. The timing of this interaction is irrelevant; the welcome message will alwaj/s be the same,
regardless of when it is accessed or displayed.
2. Static interactions in Multiple Processors: Time-independent interactions across multiple processors.
Synchronizing static data between different processors to maintain consistency
Example: Synchronizing static configuration data between the ATM and the central server For instance,
updating the list of supported languages or currencies in the ATM. The central server periodically sends
updated static data to all connected ATMs to ensure consistency This process is independent of the specific
timing of individual updates as long as the data remains consistent across the network

MADE BY SHIVANJALI KESHARWANI

 Types of Interactions in system testing

3. Dynamic Interactions in a Single Processor: Time-dependent interactions within a single processor

Executing a sequence of instructions where the order of operations is critical for correctness.
 Example: Entering and validating a user's PIN. When a user enters their PIN, the ATM’s processor
must validate the entered PIN against the stored hash of the correct PIN This mvolves reading the
PIN input, processing it, and verifying it in the correct sequence. The order ana timing are crucial to
ensure the security and correctness of the authentication process
4. Dynamic interactions in Multiple Processors: Time-dependent interactions spanning across multiple
processors. Distributed computing tasks where processes must coordinate based on timing for proper
execution
 Example: Performing a balance inquiry: When a user requests to check their account balance the
ATM’s processor sends a request to the central bank's server to retrieve the latest account
balance. This interaction involves the ATM processor communicating with the remote server,
receiving the response, and displaying the balance to the user. The timing is critical because the
account balance can change with each transaction made by the user or other users. The ATM
must request and
MADE BYdisplay the balance in real-time to ensure accuracy
SHIVANJALI KESHARWANI
Client- Server Testing

 It is indeed an important testing approach that ensures accurate and

secure exchange of data between the client and server. It also guarantees
that requests and responses are synchronized correctly. Additionally, client-
server testing involves assessing the system's performance,

MADE BY SHIVANJALI KESHARWANI

Example

 Web applications often utilize client-server architecture, with the user’s web
browser (client) sending requests to a web server for data or services. In this
scenario, client-server testing involves ensuring that web pages load
correctly and that user interactions, such as form submissions, result in
proper data transmission and server responses.
 Test Scenario 1: Simulate a user registration process on a web application.
Verify that user data entered via the client-side form is correctly transmitted
to the server, stored in the database, and retrievable upon subsequent
logins.
 Components Tested: Client, Web Server, Database

MADE BY SHIVANJALI KESHARWANI

Example

 Test Scenario 2: Test email synchronization between the email client and
the email server (e.g., IMAP). Ensure that newly received emails are
correctly displayed in the client’s inbox and that read / unread statuses are
synchronized with the server.
 Components Tested: Email Client, Email Server, Database.

MADE BY SHIVANJALI KESHARWANI

 Characteristics of client-server testing
 Functionality: Ensuring that the server correctly processes client requests and
performs the intended operations.
Importance: Functionality testing verifies that the client-server interactions work as
expected. It ensures that all functions of the software application perform as specified
in the requirements.
Example: In a banking application, functionality testing would check if the server
correctly processes a client's request to transfer money between accounts.
 Performance: Evaluating the response time and throughput of the server under
various load conditions.
Importance: Performance testing assesses how well the client-server system performs
under normal and peak conditions. It identifies bottlenecks and ensures the system
can handle expected user loads.
Example: Testing how quickly a server can process multiple simultaneous requests for
account balance inquiries from multiple clients.

MADE BY SHIVANJALI KESHARWANI

 Characteristics of client-server testing
 Security: Verifying that data transmission between the client and server is secure
and that the system can withstand potential threats.
Importance: Security testing ensures that the client-server communication is
protected against unauthorized access and vulnerabilities. It checks for data
encryption, authentication mechanisms, and other security protocols.
Example: Ensuring that user login credentials are transmitted securely using HTTPS
and that the server is protected against SQL injection attacks.
 Concurrency: Ensuring the system handles multiple simultaneous requests without
data corruption or performance degradation.
Importance: Concurrency testing checks the system's ability to handle transactions
at the same time. It ensures that the system remains stable an when accessed by
many users simultaneously application, testing the server's ability
Example: In an e-commerce users checking out their carts at the same time without
causing errors in to the management. : Ensuring that the system remains stable and
performs
MADE BY SHIVANJALI KESHARWANI
 Characteristics of client-server testing
 5. Reliability - ensuring the system remains stable and performs consistently over
time
Importance: Reliability testing assesses the system's ability to perform under
expected conditions without failure. It ensures that the system can be depended
upon for continuous operation.
Example: Testing a server's uptime and error rate over a prolonged period it can
handle continuous client requests without crashing

MADE BY SHIVANJALI KESHARWANI

Components of Client-Server Systems

 Client-server systems consist of several key components that work together

to deliver serv functionality to users. These components include:
1. Server:
Role: The server is the backbone of the client-server architecture. It hosts the
database management system (DBMS) and the application logic.
Functions: The server processes requests from clients, performs the
computations or data retrieval operations, and sends back the responses to
the client .
Example: In a banking system, the central server would handle tasks such as
process transactions, updating account balances, and maintaining customer
records.

MADE BY SHIVANJALI KESHARWANI

Components of Client-Server Systems

2. Client:
 Role: The client is the interface through which users interact with the system,
tr user interface (UI) and presentation logic.
 Functions: The client sends requests to the server (e.g., querying account
balance submitting transaction requests) and displays the server's responses
to the user
 Example: In the same banking system, the client would be the application
on a user’s smartphone or computer or ATM through which they access
their account inform and perform banking operations.

MADE BY SHIVANJALI KESHARWANI

Components of Client-Server Systems

3. Network:
Role: The network is the medium that connects the clients to the server to
communication between them.
Functions: It facilitates data transmission to ensure that requests and responses
can travel back and forth between the client and server reliably and
efficiently.
Example: The internet or a private organizational network (intranet) serves as
the network connecting clients and servers in a banking system.

MADE BY SHIVANJALI KESHARWANI

 Types of Client Server Systems

Client-server systems can be categorized based on where the majority of processing takes
place: on de client side or the server side.
1. Fat Client:
In a fat client architecture, most of the processing and computational tasks are performed
on the client side. The server's primary role is to manage data storage and handle requests
for data retrieval.
Benefits: This approach can reduce the load on the server since much of the processing is
distributed to the clients. It can also lead to faster response times for the user since the
client does not have to wait for the server to process every request.
Drawbacks: Fat clients can be more complex to maintain and update since the
application logic resides on the client devices. This can lead to inconsistencies if clients are
not uniformly updated.
Example: A graphics-intensive application where rendering and processing of images are
done on the client device, while the server stores the image files and handles data
requests.MADE BY SHIVANJALI KESHARWANI
 Types of Client Server Systems

2. Fat Server:
Description: In a fat server architecture, most of the processing is done on the server
side. The client is primarily responsible for managing the user interface and handling
input/output operations.
Benefits: This approach simplifies client devices since they only need to handle the
presentation logic. It also centralizes the application logic, making maintenance and
updates easier and more consistent.
Drawbacks: Fat server architectures can place a significant load on the server,
especially if there are many clients. This can lead to scalability issues and the need for
powerful server hardware.
Example: Web applications where the server handles all the business logic and
database operations, while the client (web browser) simply renders the user interface
and captures user input.
MADE BY SHIVANJALI KESHARWANI
 Challenges in Client-Server Testing

1.Complex Interactions: The dynamic interactions between clients and servers across
multiple processors can be difficult to predict and test.
2. Network Issues: Network latency, packet loss, and bandwidth constraints can affect
the performance and reliability of client-server communications.
3. Concurrency: Handling multiple simultaneous requests without data corruption or
performance degradation requires robust concurrency control mechanisms.
4. Security: Ensuring secure data transmission and protecting against threats such as SQL
Injection, cross-site scripting, and man-in-the-middle attack
5.Data Consistency: Ensuring that data remains consistent across the client and server,
especially in the face of concurrent updates.

MADE BY SHIVANJALI KESHARWANI

Testing Strategy

 Identify Client-Server Interactions: Determine all interactions that occur

between the client and server, including data requests, processing, and
responses Review
Example: In the SATM system, Interactions between the ATM client (user interface)
and the bank's central server ( 2. processing transactions) must be tested.
 Develop Test Cases: Create test cases that cover different scenarios of client-
server interactions, including normal operations, error handling, and edge
cases. Example: A test case where the ATM client requests a balance inquiry,
and the server processes this request and returns the current balance.
 Simulate Network Conditions: Test under various network conditions, such as
latency packet loss, and bandwidth constraints, to ensure robustness.
Example: Simulate a network delay to see how the ATM system handles slow
responses from the central server.

MADE BY SHIVANJALI KESHARWANI

 Testing Strategy
Concurrency Testing: Ensure that the system can handle multiple simultaneous requests without data
corruption or performance degradation.
Example: Multiple ATMs simultaneously requesting transaction processing from the central server
Security Testing: Ensure that data transmitted between the client and server is secure and that the
system can withstand potential security threats.
Example: Test for SQL, Injection, cross-site scripting (XSS), and secure data transmission protocols (eg,
HTTPS).Execution and Monitoring1.
Run Test Cases: Execute the test cases in a controlled environment and monitor the system's
responses.
Example: Execute a withdrawal transaction test case to verify if the server correctly deducts the
amount and updates the balance.

MADE BY SHIVANJALI KESHARWANI

Testing Strategy

Analyze Results: Analyze the test results to identify any issues or inconsistencies in
the client-server Interactions
.Example: Check if the server correctly handles multiple simultaneous balance
inquiries without causing data inconsistencies.
Fix Issues and Retest: Correct any identified issues and perform retesting to ensure
that the are solutions effective.
Example: If an issue is found in handling concurrent transactions, fix the server logic
and retest with multiple ATMs

Security Testing: Ensure that data transmitted between the client and server is
secure and that the system can withstand potential security threats.
Example: Test for SQL, Injection, cross-site scripting (XSS), and secure data
transmission protocols (eg, HTTPS).

MADE BY SHIVANJALI KESHARWANI