OBJECT-ORIENTED ANALYSIS AND DESIGN

Construction and Testing

UNIT III

Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak

U3. #

Learning Objectives
Construction Introduction the design model block design working with construction Testing Introduction on testing unit testing integration testing system testing the testing process

Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak

U3. #

CONSTRUCTION

Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak

U3. #

Learning Objectives
What is Construction Phase Why Construction Add a Dimension Artifacts for Construction Design (What, Purpose, Goals, Levels) Implementation Environemnt Traceability Interaction Diagram Block design Block Behavior Implementation
U3. #

Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak

What is Construction Phase?

All about BUILDING the system from model of analysis & requirement phase. Consists of Design and Implementation. Start from elaboration & continues to construction

Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak

U3. #

Why construction?
For seamless transition to source code; analysis model not sufficient. The actual system must implementation environment. be adapted to the

Must explore into more dimensions. To validate the analysis result.

Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak

U3. #

Add A Dimension: Analysis To Design Space

Behavior

Behavior
Implementation Environment
Design

Information
Information Presentation Presentation

Analysis Space

Design Space

Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak

U3. #

Artifacts for Construction

Requirements Model Construction Analysis Model

Design Model

Implementation Model

Input & Output Models of Construction

Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak U3. #

Design
There are two ways of constructing a software design:
make it so simple that there are obviously no deficiencies make it so complicated that there are no obvious deficiencies. - C.A.R. Hoare

Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak

U3. #

What is Design?
Specification Is about What, and Design is the start of the How Inputs to the design process Specification document, including models etc. Outputs of the design process A design document that describes how the code will be written. Includes design models! What subsystems, modules or components are used How these integrate (i.e. work together) Information allowing testing of the system

Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak

U3. #

The Purpose of System Design

Bridging the gap between desired and existing system in a manageable way Use Divide and Conquer We model the new system to be developed as a set of subsystems

Problem

New System

Existing System
Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak U3. #

Why is Design so Difficult?

Analysis: Focuses on the application domain Design: Focuses on the solution domain Design knowledge is a moving target The reasons for design decisions are changing very rapidly Halftime knowledge in software engineering

What I teach today will be out of date in 3 years

Cost of hardware rapidly sinking
Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak U3. #

Design Goals..
Qualities Of A Good Design: Correct, Complete, Changeable, Efficient, Simple Correctness: It Should Lead To A Correct Implementation Completeness: It Should Do Everything. Everything? specifications.

It should follow the

Changeable: It Should Facilitate ChangeChange Is Inevitable

Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak U3. #

Design Goals..
Efficiency It Should Not Waste Resources. But: Better A Working Slow Design Than A Fast Design That Does Not Work
Simplicity It Should Be As Understandable As Possible

Important: A design should fully describe how coders will implement the system in the next phase
Designs are blue-prints for code construction

Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak

U3. #

Levels of Design
Three possible levels: System Design, if appropriate Part of Systems Engineering High-level Software Design Architecture, architectural design Low-level Software Design Detailed Design, Module Design

Systems Engineering: Large combinations of hardware and software. Decompose system into subsystems Determine which subsystems are HW, which are SW Software Engineering activities thus become a part of a larger activity.
Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak U3. #

Develop Design Model

Create detailed plans (like blueprints) for implementation Identify the conclusions. Implementation Environment & draw

Incorporate the conclusions & develop a First approach to a design model from requirement models. Use analysis model as base & translate analysis objects to design objects in design model fit for current implementation. Why cant this be incorporated in analysis model?

Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak

U3. #

Develop Design Model

Describe how the Object Interact in each specific use case & how stimuli between objects is exchanged Create design models before coding so that we can:
Compare different possible design solutions

Evaluate efficiency, ease of modification, maintainability, etc

Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak

U3. #

Implementation Environment
Identify the actual technical constraints under which the system should be built Including: The target environment Programming language Existing products that should be used (DBMSs, etc) Strategies: n As few objects as possible should be aware of the constraints of the actual implementation environment

Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak

U3. #

Implementation Environment: Target Environment

Application Objects

File Manager

several implement ations of the file manager block

MS-DOS

UNIX

Mac-OS
U3. #

Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak

Implementation Environment
Target environment Create a new blocks that represent occurrences of the changed parts in the target environment Strategies: Specified an abstract class polymorphism The object can check the platform at run-time CASE statement in the source code Decide this when the system us delivered Provide several different modul which will be choosed later Investigate whether the target environment will execute in a distributed way on a different processors or different processes
Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak U3. #

Implementation Environment
Programming language Affect the design in translating the concepts used The basic properties of the language and its environment are fundamental for the design Inheritance and Multiple inheritance Typing Standard Portability Strategies for handling errors during run-time Exception (Ada) Assertions (Eiffel) Memory management Automatic garbage collection The use of component Component library, such as interface objects
Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak U3. #

Implementation Environment..
Using existing products DBMS UIMS (User Interface Management System) Network facilities Internally or externally developed applications that should be incorporated Products used during development Compilers Debuggers Preprocessor Other considerations Requirement for performance Limitations of memory

Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak

U3. #

Implementation Environment
Other considerations Strategies: To postpone optimizations until they are needed or you are absolutly sure that they will be needed the real bottlenecks are often missed and then new optimizations are necessary Use simulation or prototyping to investigate potential optimization problem early Extensive experiences may help to jugde at an early stage If youre not sure of the correctnessof a performance optimizations, you should not make it untill youre sure of how it should be done
Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak U3. #

Implementation Environment
The people and organization involved development could also afect the design The principal strategy: such factors should not affect the system structure. The reason: the circumtances (organizations, staffing, competence areas) that are in effect today will probably change during the systems life cycle
Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak U3. #

in

the

Traceability
refines the analysis model in light of actual implementation environment. Explicit definition of interfaces of objects, semantics of operation. Additionally, different issues like DBMS, programming language etc. can be considered. The model is composed of BLOCKS which are the design objects. One block is implemented as one class

Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak

U3. #

Traceability..
The blocks abstract actual implementation the

Traceability is extremely important aspect of the system. Changes made will be only local to a module. Provides high functional localization (high cohesion).

Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak

U3. #

Alarm

Example Recycling Machine Analysis Model

Administrator
Report Generator Alarm Device Operator Panel

Alarmist

Deposit

extends

Deposit item receiver Customer panel Receipt basis

Receipt printer

Deposit items Can Crate

U3. #

Bottle

Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak

Example Recycling Machine Analysis Model

Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak

U3. #

Example Recycling Machine Design Model

Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak

U3. #

Working with the Design Model

Changes can and should occur, but all changes should be justified and documented (for robustness reason) We may have to change the design model in various way: To introduce new blocks which dont have any representation in the analysis model To delete blocks from the design model To change blocks in the design model (splitting and joining existing blocks)

To change the associations between the blocks in the design model

Use the component
Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak U3. #

Change in Environment
Changing the associations between the blocks in the design model. extensions to stimuli inheritance to delegation

Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak

U3. #

Interaction Diagrams
Describe how the blocks are to communicate by designing the use case The main purpose of the use case design is to define the protocols of the blocks The interaction diagram describes how each usecase is offered by communicating objects The diagram shows how the participating objects realize

the use case through their interaction The blocks send stimuli between one another All stimuli are defined including their parameters For each concrete use case, draw an interaction diagram
Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak U3. #

Sequence Diagram (Contd)

Syntax and Semantics

message

Distinguishing a system and the outside world (RationalRose: Use Actors )

Blocks life line (showing life cycle) Events occurring within a block feedback signal

Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak

U3. #

Building an Interaction Diagram

Identify blocks Draw skeleton, consist of: System border Bars for each block that participates

Describes the sequences

Structured text or pseudo-code Mark the bar to which operations belongs with a rectangle representing operation Define a stimulus
Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak U3. #

Building an Interaction Diagram..

Draw a stimulus as a horizontal arrow Start: bar of the sending block End: bar of the receiving block

Structure the interaction diagram

Fork diagram

Stair diagram

Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak

U3. #

The Skeleton for the Interaction Diagram

Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak

U3. #

Example Interaction Diagram for Use Case Returning Item

Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak

U3. #

Example Interaction Diagram for Use Case Returning Item

Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak

U3. #

Sequence Diagram
Events (when the customer presses receipt button):

Print Logo and date; for (all types of items) { Find name and number for a type of item; Find deposit value for a type of item; Sum; Print sum; } Ready for the next customer;

Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak

U3. #

Sequence Diagram
Events (when a customer insert an item):

If (customer is new) { Create a new account; } Do { If (returned item is acceptable == true) { Classify; Increment items; Increment values; } else reject; }
U3. #

Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak

Sequence Diagram

Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak

U3. #

Rational Rose Collaboration Diagram

Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak

U3. #

Advance Interaction Diagrams

Synchronous and asynchronous
A synchronous message/signal is a control which has to wait for an answer before continuing. the sender passes the control to the receiver and cannot do anything until the receiver sends the control back. An asynchronous message is a control which does not need to

wait before continuing.

the sender actually does not pass the control to the receiver. The sender and the receiver carry on their work concurrently.

Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak

U3. #

Synchronous & Asynchronous

here there

Simple (unspecified) synchronous

asynchronous

Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak

U3. #

Recursion in SD
Syntax:

Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak

U3. #

Use Case with Extension

Described by a probe position in the interaction diagram The probe position indicates a position in the use case to be extended
Often accompanied by a condition which indicates under what circumstances the extension should take placed

Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak

U3. #

Example Probe position

Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak

U3. #

Homogenization
In parallel design process, several stimuli with the same purpose or meaning are defined by several designers. These stimuli should be consolidated to obtain as few stimuli as possible.
Called homogenization.

Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak

U3. #

Example - Homogenization
What_is_your_phone_number? Where_do_you_live? Get_address Get_address_and_phone_number Homogenized into: Get_address Get_phone_number

Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak

U3. #

Structure of SD
Centralised structure -- Fork: Everything is handled and controlled by the left-most block.

Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak

U3. #

Structure of SD
Decentralised structure -- Stair: There is no central control
block.

Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak

U3. #

Structure of SD
decentralized structure is appropriate: If the sub-event phases are tightly coupled. This will be the case if the participating objects: Form a part-of or consists-of hierarchy, such as Country - State - City; Form an information hierarchy, such as CEO - Division Manager - Section Manager; Represent a fixed chronological progression (the sequence of sub-event phases will always be performed in the same order), such as Advertisement - Order - Invoice -Delivery - Payment; or Form a conceptual inheritance hierarchy, such as Animal Mammal - Cat.

Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak

U3. #

 Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak

U3. #

Structure of SD
A centralized structure is appropriate:

If the order in which the sub-event phases will be

performed is likely to change.

If you expect to insert new sub-event phases.

If you want to keep parts of the functionality reusable as separate piec

Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak

U3. #

Structure of SD

Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak

U3. #

Structure of SD..
Fork indicates a centralized structure and is characterized by the fact that it is an object controls the other objects interacted with it. This structure is appropriate when:

The operations can change order

New operations could be inserted

Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak

U3. #

Structure of SD.
Stair indicates decentralized structure and is characterized by delegated responsibility. Each object only knows a few of the other objects and knows which objects can help with a specific behavior. This structure is appropriate when: The operation have a strong connection. Strong connection exists if the objects: form a consist-of hierarchy form an information hierarchy form a fixed temporal relationship form a (conceptual) inheritance relationship The operation will always be performed in the same order
Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak U3. #

Structural Control in Sequence Diagram

Optional Execution Conditional Execution Parallel Execution Loop Execution Nested

Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak

U3. #

Block Design
Block design can start when all use cases for a specific block have been designed. The implementation (code) for the block can start when the interfaces are stable and are frozen. Ancestor objects (classes) should be designed

before descendant. Look at all interaction diagrams where a block participates, and

extract all the operations defined for it, yielding a complete

picture of the interface.
Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak U3. #

 Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak

U3. #

Block Design...
From the interaction diagram for Returning Item: The interface for Deposit Item:

exists, incr, getName, getValue The interface for Receipt Basis:

insertItem(item), printOn(ostream), delete

When writing the class interface for a block in OOP language, may need additional classes, that are not seen by other blocks

Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak

U3. #

Block Design Comments

The description of the operation is extracted from the

text to the left of the diagram.

Can work in parallel once interfaces are frozen (recall the open closed principle).

Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak

U3. #

UML Class Diagram

a collection of classes and interfaces, along with the

collaborations and relationships among classes and

interfaces

Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak

U3. #

How to Build Class Diagram

Identify the main members of the family
Determine how they are related to each other Identify the characteristics of each family member

Find relations among family members

Decide the inheritance of personal traits and characters Class Syntax

Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak

U3. #

Syntax Class Diagram

Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak

U3. #

Composition

Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak

U3. #

Aggregation

Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak

U3. #

Association

Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak

U3. #

Inheritance

Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak

U3. #

Realization

Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak

U3. #

Multiplicity Notation

1 *

Class Class Class Class Class

exactly one many (zero or more) optional (zero or more) numerically specified ordered

0..1 m..n
{ordered} *

Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak

U3. #

Attributes Structural Features

An attribute describes a property as a line of text within the class box Syntax
visibility name: type multiplicity = default {property-string} {+,-, { [1], {Integer, {0, { readOnly, #,`} [n] Boolean, foo, ordered,
String, Date, Money, } [0..1], [m..n], [*], [1..*], [n..*]} 12-05-06, 100 , } nonunique, unique, bag, set }

Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak

U3. #

Class Diagram

Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak

U3. #

Object Behavior
An intermediate level of object internal behavior may be described using a state machine. The input alphabet is the set of stimuli. State represent modes of operation of the object.

The state machine specifies possible orders of stimuli, that will

later be expressed in preconditions. This is particularly important in reactive systems

Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak

U3. #

Object Behavior...
To provide a simplified description that increases

understanding of the block without having to go down to

source code Less dependant on programming language

Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak

U3. #

Textual Notation
Machine stack State init input createinstance next state empty otherwise error; State empty input push do store on top next state loaded print stack is empty otherwise error; .. endmachine
Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak U3. #

Object Behavior...
Stimulus control object
An object that perform the same operation independent of state when a certain stimulus is received. Entity objects

Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak

U3. #

Object Behavior...
state-controlled objects
Objects that select operations not only from the stimulus received, but also from the current state Control object

Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak

U3. #

Notation used for State Transition Diagram

Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak

U3. #

 Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak

U3. #

Operation

Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak

U3. #

STD

Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak

U3. #

STD for Deposit Item

Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak

U3. #

STD for Deposit Item Receiver

Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak

U3. #

State Diagram in UML

show the different states of an entity also how an entity

responds to various events by changing from one state

to another

Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak

U3. #

State
A condition or situation during the life of an object during which it satisfies some condition, performs some activities or wait for some events.

Several Parts
Name Entry/exit effects Internal Transitions Substates Orthogonal (concurrently active) Nonorthogonal (Sequential active)
Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak U3. #

State Diagram in UML..

Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak

U3. #

State Diagram in UML..

Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak

U3. #

State Diagram in UML..

Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak

U3. #

Internal Block Structure

In case of OOPL object-module becomes classes

otherwise module unit

Generally more classes than object split class when required 5-10 times longer to design a component class than an ordinary class

Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak

U3. #

Implementation
Now, need to write code for each block. Implementation strategy depends on the programming language. In an OOP language, the implementation of a block starts with one class. Sometimes there is a need for additional classes, that are not seen by other blocks.

Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak

U3. #

Mapping
Analysis Analysis objects Behavior in objects Design Block Operations Source code C++ 1..N classes Member functions

Attributes(class) Attributes(instance)

Attributes(class) Attributes(instance)

Static variables Instance variables

Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak

U3. #

Mapping..
Analysis Acquuaintance ass. Design Acquuaintance ass. Source code C++ Instance variables

Communication ass.
Interaction between objects Usecase

Communication ass.
Stimulus

Reference to a function
Call to a functiom

Designed usecase Sequence of calls

subsystem

Subsystem

File
U3. #

Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak

Implementation Environment
Everything that does not come from analysis phase, including performance requirements. Design must be adapted to implementation environment. Use of existing products must be decided. Includes

previous version of the system.

To use an existing product we must adapt our design. Tradeoff - less development vs. more complex architecture. Also consider testing costs.

Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak

U3. #

Other Considerations in the Construction Phase

Subsystems defined in analysis phase are used to guide the construction phase. Developed separately as much as possible. Incremental development - start construction phase in parallel

with analysis phase - to identify implementation environment.

How much refinement to do in analysis phase? (How early/late to move from analysis to design) - decided in each project

Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak

U3. #

What we learnt
What is Construction Phase Why Construction Add a Dimension Artifacts for Construction Design (What, Purpose, Goals, Levels) Implementation Environemnt Traceability Interaction Diagram Block design Block Behavior Implementation
Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak U3. #

Object Oriented Testing Concepts

Testing Techniques Testing Regression Test Verification Testing Focuses Validation Operation test Debugging Full-scale test Certification Clean Room Software Engineering Stress test Overload test Error Negative test Fault Test based on requirements Failure Ergonomic tests Testing Level Testing of the user Unit testing documentation Integration Testing Acceptance testing System Testing

Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak

U3. #

Object Oriented Testing Concepts..

Stubs Drivers Test bed Equivalence set Equivalence partitioning Automatic Testing
Test data

Test program

Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak

U3. #

Object Oriented Testing Concepts..

When the testing activities must be commence? Justify the statement More the testing is integrated with software development phases it will be better. Why the most important aspect of testing is actually the attitude adopted toward it?

Why testing must be planned in the same manner as analysis and construction?
Why it is not possible to arrive at high quality software just by testing and debugging? How testing can be done on analysis and design documents?

Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak

U3. #

Object Oriented Testing Concepts..

Why reviews and inspections should also be performed in parallel to validation

Why reviews and inspections consider as costly method?

How reviews and inspections produce high quality code? Justify the statement Defect avoidance is more powerful than defect removal. Discuss testing strategy. Why bottom up testing strategy is better than top down testing strategy. Discuss the principle of automatic testing Compare test program with test data Why interface simulator is use in automatic testing?
U3. #

Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak

Object Oriented Testing Concepts..

Whether the test programs are part of the tested product or they are a separate product?

Why unit test of object-oriented code is more complex than testing ordinary (procedural) code?
What is difference between ordinary (procedural) unit testing and object oriented unit testing? Describe state-based testing. What do you mean by state matrix for testing? Describe test coverage. How polymorphism impact the test coverage?
U3. #

Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak

Object Oriented Testing Concepts..

How inheritance effect the structural testing? If we test all units extensively, is there a need for integration testing, since all units will be correct as they are? What are test for a usecase? What are the different tests can be done during system test? Why? What are the different activities in testing process? Why we need to kept test log during the entire test process? What is the purpose of test specification?

Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak

U3. #

Object Oriented Testing Concepts..

Why we need to prepare test reports while writing test specifications?

When a test is done what are the different reasons of detected failure?
What we need to do when testing has been completed?

Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak

U3. #

UNIT III Learnings

Construction Introduction the design model block design working with construction

Testing Introduction on testing unit testing integration testing system testing the testing process
Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak U3. #

Phases of SDLC

SOFTWARE DEVELOPMENT LIFE CYCLE (SDLC)

Requirement Specification and Analysis Design Coding Testing Implementation Maintenance

Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak

Srihari Techsoft

U3. #

The Design process

Breaking down the product into independent modules to arrive at micro levels. 2 different approaches followed in designing
Top Down Approach Bottom Up Approach

Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak

Srihari Techsoft

U3. #

Top-down approach

Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak

Srihari Techsoft

U3. #

Bottom-Up Approach

Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak

Srihari Techsoft

U3. #

Most Common Software problems

Incorrect calculation Incorrect data edits & ineffective data edits Incorrect matching and merging of data Data searches that yields incorrect results Incorrect processing of data relationship Incorrect coding / implementation of business rules software performance
Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak

Srihari Techsoft

U3. #

 Confusing or misleading data Software usability by end users Inconsistent processing Unreliable results or performance Incorrect interfaces with other systems Inadequate performance and security Incorrect file handling

controls

Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak

Srihari Techsoft

U3. #

 Software testing can be stated as the process of validating and verifying that a software program/application/product: meets the requirements that guided its design and development;works as expected; Software testing, depending on the testing method employed, can be implemented at any time in the development process. However, most of the test effort occurs after the requirements have been defined and the coding process has been completed.

Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak

U3. #

 A primary purpose of testing is to detect software failures so that defects may be discovered and corrected. Testing cannot establish that a product functions properly under all conditions but can only establish that it does not function properly under specific conditions

Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak

U3. #

Testing takes creativity

Testing often viewed as dirty work. To develop an effective test, one must have:
Detailed understanding of the system Knowledge of the testing techniques Skill to apply these techniques in an effective and efficient manner

Testing is done best by independent testers

We often develop a certain mental attitude that the program should in a certain way when in fact it does not.

Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak

U3. #

Objectives of testing
Executing a program with the goal of finding an error. To check if the system meets the requirements and be executed successfully in the planned environment. To check if the system is Fit for purpose. To check if the system does what it is expected to do.

Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak

Srihari Techsoft

U3. #

Objectives of testing A good test case is one that has a probability of finding undiscovered error. A good test is not redundant. A good test should be best of type. A good test should neither be too simple nor too complex.

Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak

Srihari Techsoft

U3. #

Objective of a Software Tester Find bugs as early as possible and make sure they get fixed. To understand the application well. Study the functionality in detail to find where the bugs are likely to occur. Study the code to ensure that each and every line of code is tested. Create test cases in such a way that testing is done to uncover the hidden bugs and also ensure that the software is usable and reliable
Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak

Srihari Techsoft

U3. #

VERIFICATION & VALIDATION

Verification - typically involves reviews and meeting to evaluate documents, plans, code, requirements, and specifications. This can be done with checklists, issues lists, and inspection meeting.
Validation - typically involves actual testing and takes place after verifications are completed. Validation and Verification process continue in a cycle till the software becomes defects free.
Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak

Srihari Techsoft

U3. #

Software Development Process Cycle

Plan

Action

Do

Check

Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak

Srihari Techsoft

U3. #

PLAN (P): Device a plan. Define your objective and determine the strategy and supporting methods required to achieve that objective. DO (D): Execute the plan. Create the conditions and perform the necessary training to execute the plan. CHECK (C): Check the results. Check to determine whether work is progressing according to the plan and whether the results are obtained. ACTION (A): Take the necessary and appropriate action if checkup tells that the work is not being performed according to plan or not as expected.

Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak

Srihari Techsoft

U3. #

SOFTWARE TESTING LIFECYCLE - PHASES

Requirements study Test Case Design and Development Test Execution Test conclusion

Test Process Analysis

Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak

Srihari Techsoft

U3. #

Requirements study
Testing Cycle starts with the study of clients requirements.

Understanding of the requirements is very essential for testing the product.

Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak

Srihari Techsoft

U3. #

Analysis & Planning

Test objective and coverage Overall schedule Standards and Methodologies Resources required, including necessary training Roles and responsibilities of the team members Tools used
Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak

Srihari Techsoft

U3. #

Test Case Design and Development Component Identification Test Specification Design Test Specification Review Test Execution Code Review Test execution and evaluation Performance and simulation
Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak

Srihari Techsoft

U3. #

Test Closure

Test summary report Project Documentation

Test Process Analysis Analysis done on the reports and improving the applications performance by implementing new technology and additional features.

Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak

Srihari Techsoft

U3. #

Testing Levels
Unit testing Integration testing System testing Acceptance testing

Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak

U3. #

Types of Testing
Unit Testing:
Individual subsystem Carried out by developers Goal: Confirm that subsystems is correctly coded and carries out the intended functionality

Integration Testing:
Groups of subsystems (collection of classes) and eventually the entire system Carried out by developers Goal: Test the interface among the subsystem

Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak

U3. #

System Testing
System Testing:
The entire system Carried out by developers Goal: Determine if the system meets the requirements (functional and global)

Acceptance Testing:
Evaluates the system delivered by developers Carried out by the client. May involve executing typical transactions on site on a trial basis Goal: Demonstrate that the system meets customer requirements and is ready to use

Implementation (Coding) and testing go hand in hand

Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak U3. #

Testing Activities
Subsystem Code Subsystem Code

Unit Test
Tested Subsystem

System Design Document

Requirements Analysis Document

Unit Test
Tested Subsystem

User Manual

Integration Test

Functional Test Integrated Subsystems

Functioning System

Tested Subsystem

Subsystem Code

Unit Test
All tests by developer

Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak

U3. #

Testing Activities continued

Global Requirements
Clients Understanding of Requirements

User Environment

Accepted Validated Functioning System Performance System Acceptance System Installation Test Test Test
Tests by client Tests by developer Users understanding

Usable System

System in Use
Tests (?) by user
Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak U3. #

Unit testing
The most micro scale of testing. Tests done on particular functions or code modules. Requires knowledge of the internal program design and code. Done by Programmers (not by testers).

Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak

Srihari Techsoft

U3. #

Unit testing
Objectives

To test the function of a program or unit of code such as a program or module To test internal logic To verify internal design To test path & conditions coverage To test exception conditions & error handling After modules are coded Internal Application Design Unit Test Plan Unit Test Report
Srihari Techsoft
U3. #

When Input Output

Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak

Who Methods Tools

Developer

White

Box testing techniques

Debug Re-structure Code Analyzers Path/statement coverage Testing Methodology Effective use of tools

tools

Education

Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak

Srihari Techsoft

U3. #

Incremental integration testing

Continuous testing of an application as and when a new functionality is added. Applications functionality aspects are required to be independent enough to work separately before completion of development.
Done by programmers or testers.
Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak

Srihari Techsoft

U3. #

Integration Testing

Testing of combined parts of an application to determine their functional correctness.

Parts can be code modules individual applications client/server applications on a network.
Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak

Srihari Techsoft

U3. #

Types of Integration Testing

Big Bang testing
Top Down Integration testing Bottom Up Integration testing

Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak

Srihari Techsoft

U3. #

Integration testing Objectives

To technically verify proper interfacing between modules, and within sub-systems After modules are unit tested Internal & External Application Design Integration Test Plan Integration Test report
Srihari Techsoft
U3. #

When Input

Output

Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak

Who Methods

Developers White

Tools

Education

and Black Box techniques Problem / Configuration Management Debug Re-structure Code Analyzers Testing Methodology Effective use of tools
Srihari Techsoft
U3. #

Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak

Integration Testing Strategy

The entire system is viewed as a collection of subsystems (sets of classes) determined during the system and object design. The order in which the subsystems are selected for testing and integration determines the testing strategy
Big bang integration (Nonincremental) Bottom up integration Top down integration Sandwich testing Variations of the above

For the selection use the system decomposition from the System Design
Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak U3. #

Example: Three Layer Call Hierarchy

A

Layer I

Layer II

Layer III

Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak

U3. #

Integration Testing: Big-Bang Approach

Unit Test A Unit Test B Unit Test C Unit Test D Unit Test E Unit Test F

Dont try this!

System Test

Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak

U3. #

Bottom-up Testing Strategy

The subsystem in the lowest layer of the call hierarchy are tested individually Then the next subsystems are tested that call the previously tested subsystems This is done repeatedly until all subsystems are included in the testing

Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak

U3. #

Bottom-up Integration
A Layer I

Test E Test B, E, F Test F Test C

E

Layer II

Layer III

Test A, B, C, D, E, F, G

Test D,G Test G

Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak

U3. #

Pros and Cons of bottom up integration testing

Bad for functionally decomposed systems:

Tests the most important subsystem (UI) last

Useful for integrating the following systems

Object-oriented systems real-time systems systems with strict performance requirements

Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak

U3. #

Top-down Testing Strategy

Test the top layer or the controlling subsystem first Then combine all the subsystems that are called by the tested subsystems and test the resulting collection of subsystems Do this until all subsystems are incorporated into the test

Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak

U3. #

Top-down Integration Testing

A Layer I B C D Layer II

Layer III

Test A Layer I

Test A, B, C, D

Test A, B, C, D, E, F, G

Layer I + II
All Layers

Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak

U3. #

Sandwich Testing Strategy

Combines top-down strategy with bottom-up strategy The system is view as having three layers
A target layer in the middle A layer above the target A layer below the target Testing converges at the target layer

How do you select the target layer if there are more than 3 layers?
Heuristic: Try to minimize the number of stubs and drivers

Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak

U3. #

Sandwich Testing Strategy

A Layer I

Test E
E

Layer II

Layer III

Bottom Layer Tests

Test B, E, F Test F Test A, B, C, D, E, F, G

Test D,G Test G Test A,B,C, D

Top Layer Tests

Test A

Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak

U3. #

Pros and Cons of Sandwich Testing

Top and Bottom Layer Tests can be done in parallel Does not test the individual subsystems thoroughly before integration Solution: Modified sandwich testing strategy

Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak

U3. #

Modified Sandwich Testing Strategy

Test in parallel:
Middle layer with drivers and stubs Top layer with stubs Bottom layer with drivers

Test in parallel:
Top layer accessing middle layer (top layer replaces drivers) Bottom accessed by middle layer (bottom layer replaces stubs)

Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak

U3. #

Modified Sandwich Testing Strategy

A

Double Test I
Layer I C D Layer II

Test B
B

Test E Triple Test I Test F Double Test II Test B, E, F Triple Test I

E

Layer III

Double Test II Test A, B, C, D, E, F, G

Test D Test D,G Test G Test A,C

Test A

Double I Applications and Management, New Delhi-63, by Nitish Pathak Bharati Vidyapeeths InstituteTest of Computer

Test C

U3. #

Steps in Integration-Testing
1. Based on the integration strategy, select a component to be tested. Unit test all the classes in the component. . 2. Put selected component together; do any preliminary fix-up necessary to make the integration test operational (drivers, stubs) 3. Do functional testing: Define test cases that exercise all uses cases with the selected component 4. Do structural testing: Define test cases that exercise the selected component 5. Execute performance tests 6. Keep records of the test cases and testing activities. 7. Repeat steps 1 to 7 until the full system is tested. The primary goal of integration testing is to identify errors in the (current) component configuration.

Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak

U3. #

System Testing
Functional Testing Structure Testing Performance Testing Acceptance Testing Installation Testing
The more explicit the requirements, the easier they are to test. Quality of use cases determines the ease of functional testing Quality of subsystem decomposition determines the ease of structure testing Quality of nonfunctional requirements and constraints determines the ease of performance tests:
Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak U3. #

Impact of requirements on system testing:

Structure Testing
Essentially the same as white box testing. Goal: Cover all paths in the system design
Exercise all input and output parameters of each component. Exercise all components and all calls (each component is called at least once and every component is called by all possible callers.) Use conditional and iteration testing as in unit testing.

Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak

U3. #

Functional Testing
Essentially the same as black box testing . Goal: Test functionality of system Test cases are designed from the requirements analysis document (better: user manual) and centered around requirements and key functions (use cases) The system is treated as black box. Unit test .cases can be reused, but in end user oriented new test cases have to be developed as well.

Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak

U3. #

Performance Testing
Stress Testing
Stress limits of system (maximum # of users, peak demands, extended operation)

Timing testing
Evaluate response times and time to perform a function

Environmental test
Test tolerances for heat, humidity, motion, portability

Volume testing
Test what happens if large amounts of data are handled

Quality testing
Test reliability, maintain- ability & availability of the system

Configuration testing
Test the various software and hardware configurations

Recovery testing
Tests systems response to presence of errors or loss of data.

Compatibility test
Test backward compatibility with existing systems

Human factors testing

Tests user interface with user

Security testing
Try to violate security requirements

Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak

U3. #

Acceptance Testing
Goal: Demonstrate system is ready for operational use
Choice of tests is made by client/sponsor Many tests can be taken from integration testing Acceptance test is performed by the client, not by the developer. Majority of all bugs in software is typically found by the client after the system is in use, not by the developers or testers. Therefore two kinds of additional tests:

Alpha test:
Sponsor uses the software at the developers site. Software used in a controlled setting, with the developer always ready to fix bugs.

Beta test:
Conducted at sponsors site (developer is not present) Software gets a realistic workout in target environ- ment Potential customer might get discouraged

Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak

U3. #

Testing has its own Life Cycle

Establish the test objectives Design the test cases Write the test cases Test the test cases

Execute the tests

Evaluate the test results Change the system Do regression testing
Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak U3. #

Test Team
Professional Tester
Programmer too familiar with code

Analyst

User

Test Team

System Designer

Configuration Management Specialist

Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak U3. #

System Testing

Objectives

When Input

To verify that the system components perform control functions To perform inter-system test To demonstrate that the system performs both functionally and operationally as specified To perform appropriate types of tests relating to Transaction Flow, Installation, Reliability etc. After Integration Testing
Detailed Requirements & External Application Design Master Test Plan System Test Plan System Test Report Srihari Techsoft
U3. #

Output

Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak

Who

Development Team

and Users

Methods

Problem

/ Configuration Management

Tools

Recommended

set of tools

Education

Testing Methodology Effective use of tools

Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak

Srihari Techsoft

U3. #

Systems Integration Testing

Objectives

When Input Output

To test the co-existence of products and applications that are required to perform together in the production-like operational environment (hardware, software, network) To ensure that the system functions together with all the components of its environment as a total system To ensure that the system releases can be deployed in the current environment After system testing Often performed outside of project life-cycle Test Strategy Master Test Plan Systems Integration Test Plan Systems Integration Test report Srihari Techsoft
U3. #

Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak

Who Methods

System Testers White

Tools
Education

and Black Box techniques Problem / Configuration Management Recommended set of tools
Testing

Methodology Effective use of tools

Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak

Srihari Techsoft

U3. #

Acceptance Testing Objectives When Input

Output

To verify that the system meets the user requirements After System Testing Business Needs & Detailed Requirements Master Test Plan User Acceptance Test Plan User Acceptance Test report
Srihari Techsoft
U3. #

Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak

Who Methods

Users / End Users

Black Box techniques Problem / Configuration

Management
Tools Education Compare, keystroke capture & playback, regression testing
Testing Methodology Effective use of tools Product knowledge Business Release Strategy

Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak

Srihari Techsoft

U3. #

TESTING METHODOLOGIES AND TYPES

Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak

Srihari Techsoft

U3. #

Testing methodologies
Black box testing
White box testing Incremental testing

Thread testing

Black box testing

No knowledge of internal design or code required. Tests are based on requirements and functionality
White box testing Knowledge of the internal program design and code required. Tests are based on coverage of code statements,branches,paths,conditions.

Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak

Srihari Techsoft

U3. #

Black box / Functional testing Based on requirements and functionality Not based on any knowledge of internal design or code Covers all combined parts of a system Tests are data driven

Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak

Srihari Techsoft

U3. #

Black-box Testing
Focus: I/O behavior. If for any given input, we can predict the output, then the module passes the test.
Almost always impossible to generate all possible inputs ("test cases")

Goal: Reduce number of test cases by equivalence partitioning:

Divide input conditions into equivalence classes Choose test cases for each equivalence class. (Example: If an object is supposed to accept a negative number, testing one negative number is enough)

Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak

U3. #

White box testing / Structural testing

Based on knowledge of internal logic of an application's code

Based on coverage of code statements, branches, paths, conditions Tests are logic driven

Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak

Srihari Techsoft

U3. #

White-box Testing
Focus: Thoroughness (Coverage). Every statement in the component is executed at least once. Four types of white-box testing
Statement Testing Loop Testing Path Testing Branch Testing

Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak

U3. #

 Statement Testing (Algebraic Testing): Test single statements (Choice of operators in polynomials, etc) Loop Testing:
Cause execution of the loop to be skipped completely. (Exception: Repeat loops) Loop to be executed exactly once Loop to be executed more than once

White-box Testing (Continued)

Path testing:
Make sure all paths in the program are executed

Branch Testing (Conditional Testing): Make sure that each possible outcome from a condition is tested at least once
if ( i = TRUE) printf("YES\n"); else printf("NO\n"); Test cases: 1) i = TRUE; 2) i = FALSE

Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak

U3. #

Constructing the Logic Flow Diagram

Start 1 F T 3 T 4 6 7 T 8 Exit
Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak U3. #

F 5

F 9

Comparison of White & Black-box Testing

White-box Testing: Both types of testing are needed Potentially infinite number of paths White-box testing and black box have to be tested testing are the extreme ends of a White-box testing often tests what is testing continuum. done, instead of what should be done Any choice of test case lies in Cannot detect missing use cases between and depends on the Black-box Testing: following:
Potential combinatorial explosion of test cases (valid & invalid data) Often not clear whether the selected test cases uncover a particular error Does not discover extraneous use cases ("features") Number of possible logical paths Nature of input data Amount of computation Complexity of algorithms and data structures

Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak

U3. #

Functional testing
Black box type testing geared to functional requirements of an application. Done by testers.

System testing
Black box type testing that is based on overall requirements specifications; covering all combined parts of the system.

End-to-end testing
Similar to system testing; involves testing of a complete application environment in a situation that copies real-world use.

Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak

Srihari Techsoft

U3. #

Regression testing

Re-testing after fixes or modifications of the software or its environment.

Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak

Srihari Techsoft

U3. #

Acceptance testing

Final testing based on specifications of the enduser or customer

Load testing

Testing an application under heavy loads. Eg. Testing of a web site under a range of loads to determine, when the system response time degraded or fails.
Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak

Srihari Techsoft

U3. #

Stress Testing

Testing under unusually heavy loads, heavy repetition of certain actions or inputs, input of large numerical values, large complex queries to a database etc. Term often used interchangeably with load and performance testing.
Performance testing

Testing how well an application complies to performance requirements.

Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak

Srihari Techsoft

U3. #

Install/uninstall testing

Testing of full, partial or upgrade install/uninstall process.

Recovery testing

Testing how well a system recovers from crashes, HW failures or other problems.
Compatibility testing

Testing how well software performs in a particular HW/SW/OS/NW environment.

Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak

Srihari Techsoft

U3. #

Exploratory testing / ad-hoc testing

Informal SW test that is not based on formal test plans or test cases; testers will be learning the SW in totality as they test it.

Comparison testing
Comparing SW strengths and weakness to competing products.

Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak

Srihari Techsoft

U3. #

Alpha testing Testing done when development is nearing completion; minor design changes may still be made as a result of such testing.

Beta-testing Testing when development and testing are essentially completed and final bugs and problems need to be found before release.
Srihari Techsoft

Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak

U3. #

White Box - testing technique

All independent paths within a module have been exercised at least once Exercise all logical decisions on their true and false sides Execute all loops at their boundaries and within their operational bounds

Exercise internal data structures to ensure their validity

Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak

Srihari Techsoft

U3. #

Loop Testing
This white box technique focuses on the validity of loop constructs. different classes of loops can be defined

simple loops nested loops

Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak

Srihari Techsoft

U3. #

Other White Box Techniques

Statement Coverage execute all statements at least once Decision Coverage execute each decision direction at least once Condition Coverage execute each decision with all possible outcomes at least once Decision / Condition coverage execute all possible combinations of condition outcomes in each decision.

Multiple condition Coverage Invokes each point of entry at least once.

Examples

Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak

Srihari Techsoft

U3. #

Statement Coverage Examples

Eg. A + B

If (A = 3) Then B=X+Y End-If

While (A > 0) Do Read (X) A=A-1 End-While-Do

Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak

Srihari Techsoft

U3. #

Decision Coverage - Example

If A < 10 or A > 20 Then B=X+Y

Condition Coverage Example

A=X If (A > 3) or (A < B) Then B=X+Y End-If-Then While (A > 0) and (Not EOF) Do Read (X) A=A-1 End-While-Do
Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak

Srihari Techsoft

U3. #

Incremental Testing
A disciplined method of testing the interfaces between unittested programs as well as between system components. Involves adding unit-testing program module or component one by one, and testing each result and combination.

Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak

Srihari Techsoft

U3. #

There are two types of incremental testing

Top-down testing form the top of the module hierarchy and work down to the bottom. Modules are added in descending hierarchical order. Bottom-up testing from the bottom of the hierarchy and works up to the top. Modules are added in ascending hierarchical order.

Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak

Srihari Techsoft

U3. #

Testing Levels/ White Techniques Box Unit Testing

Integration Testing System Testing
X

Black Box

Incremental

Thread

X
X X X Srihari Techsoft
U3. #

Acceptance Testing

Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak

TEST PLAN
Objectives

To create a set of testing tasks.

Assign resources to each testing task.

Estimate completion time for each testing task.

Document testing standards.

Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak

Srihari Techsoft

U3. #

A document that describes the

scope approach resources schedule

of intended test activities. Identifies the

test items features to be tested testing tasks task allotment risks requiring emergency planning.

Purpose of preparing a Test Plan Validate the acceptability of a software product. Help the people outside the test group to understand why and how of product validation. A Test Plan should be
thorough enough (Overall coverage of test to be conducted) useful and understandable by the people inside and outside the test group.

Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak

Srihari Techsoft

U3. #

Test Approach Details on how the testing is to be performed. Any specific strategy is to be followed for testing (including configuration management).

Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak

Srihari Techsoft

U3. #

Entry Criteria
Various steps to be performed before the start of a test i.e. fundamentals. E.g.
Timely environment set up Starting the web server/app server Successful implementation of the latest build etc.

Resources
List of the people involved in the project and their designation etc.
Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak

Srihari Techsoft

U3. #

Tasks/Responsibilities
Tasks to be performed and responsibilities assigned to the various team members.

Exit Criteria
Contains tasks like Bringing down the system / server Restoring system to pre-test environment Database refresh etc.

Schedule / Milestones
Deals with the final delivery date and the various milestones dates.

Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak

Srihari Techsoft

U3. #

Hardware / Software Requirements

Details of PCs / servers required to install the application or perform the testing Specific software to get the application running or to connect to the database etc.

Risks & improvement Plans

List out the possible risks during testing improvement plans to implement incase the risk actually turns into a reality.

Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak

Srihari Techsoft

U3. #

Tools to be used List the testing tools or utilities Eg.WinRunner, LoadRunner, Test Director, Rational Robot, QTP. Deliverables Various deliverables due to the client at various points of time i.e. Daily / weekly / start of the project end of the project etc. These include test plans, test procedures, test metric, status reports, test scripts etc.

Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak

Srihari Techsoft

U3. #

Good Test Plans

Developed and Reviewed early. Clear, Complete and Specific Specifies tangible deliverables that can be inspected. Staff knows what to expect and when to expect it.

Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak

Srihari Techsoft

U3. #

Good Test Plans

Realistic quality levels for goals Includes time for planning Can be monitored and updated Includes user responsibilities

Based on past experience

Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak

Srihari Techsoft

U3. #

TEST CASES
Test case is defined as A set of test inputs, execution conditions and expected results, developed for a particular objective. Documentation specifying inputs, predicted results and a set of execution conditions for a test item.

Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak

Srihari Techsoft

U3. #

 Specific inputs that will be tried and the procedures that will be followed when the software tested.
Sequence of one or more subtests executed as a sequence as the outcome and/or final state of one subtests is the input and/or initial state of the next. Specifies the pretest state of the AUT and its environment, the test inputs or conditions. The expected result specifies what the AUT should produce from the test inputs.

Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak

Srihari Techsoft

U3. #

Test Cases
Contents

Test plan reference id Test case Test condition Expected behavior

Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak

Srihari Techsoft

U3. #

Good Test Cases

Find Defects Have high probability of finding a new defect. Unambiguous tangible result that can be inspected.

Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak

Srihari Techsoft

U3. #

Good Test Cases

visible to requirements or design documents Execution and tracking can be automated Do not mislead Feasible

Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak

Srihari Techsoft

U3. #

Defect Log
Defect ID number Descriptive defect name and type Source of defect test case or other source Defect strictness Defect Priority Defect status (e.g. New, open, fixed, closed, reopen, reject)

Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak

Srihari Techsoft

U3. #

7. Date and time tracking for either the most recent status change, or for each change in the status. 8. Detailed description, including the steps necessary to reproduce the defect. 9. Component or program where defect was found 10. Screen prints, logs, etc. that will aid the developer in resolution process. 11. Stage of origination. 12. Person assigned to research and/or corrects the defect.

Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak

Srihari Techsoft

U3. #

Expected Vs. Actual Defects Detected

Analysis between the number of defects being generated against the expected number of defects expected from the planning stage.

Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak

Srihari Techsoft

U3. #

Defects Detected Vs. Corrected Gap

A line graph format that shows the Number of defects uncovered verses the number of defects being corrected and accepted by the testing group.

Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak

Srihari Techsoft

U3. #

Test Metrics
User Participation = User Participation test time Vs. Total test time. Path Tested = Number of path tested Vs. Total number of paths. Acceptance criteria tested = Acceptance criteria verified Vs. Total acceptance criteria.

Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak

Srihari Techsoft

U3. #

Test cost = Test cost Vs. Total system cost. Cost to locate defect = Test cost / No. of defects located in the testing. Detected production defect = No. of defects detected in production / Application system size. Test Automation = Cost of manual test effort / Total test cost.

Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak

Srihari Techsoft

U3. #

Objective Questions
Q1. Q2. Q3. Q4. Q5. Q6. Q7. Q8. Q9. Define Block Define Design model Define Verification Define negative test with example. What is association class? Give example. Differentiate message and signal with example. Define Homogenization with example. Define probe in sequential diagram. Differentiate full-scale test and overload test.

Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak

U3. #

Short Questions
Q1. What are the reasons for having construction phase in object oriented software engineering? Q2. How is Object oriented testing different than procedural testing? Q3. What are the guidelines for defining stimuli in an interaction diagram? Q4. Write short note on Testing strategies, Automatic Testing and System Testing Q5. Define and differentiate full-scale test, performance test & overload test Q6. Differentiate Object Oriented Analysis (OOA) and Object Oriented Design (OOD)? Q7. What are the consequences of implementation environment? Why analysis objects are required before design objects? Discuss with example.
Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak U3. #

Long Questions
Q1. The identification of classes and objects is the hardest part of object oriented analysis and design. Discuss with the help of an example. Q2. Explain the procedure of converting analysis model into construction model. Q3. Explain different types of System Testing Q4. What are the various testing levels in an object oriented system? Explain. Q5. Differentiate between implementation and test model of OO system. Take suitable examples. Q6. What are the limitations of State Transition Table? How are they overcome? Q7. Explain unit and integration testing in the object oriented context. Differentiate betweenthread based and use case based strategies for integration testing. Q8. How is object oriented integration testing different from structural integration testing? Q9. Compare and contrast various object oriented integration testing techniques. Q10. Discuss the state based testing and system testing. Q11. Describe the purpose of the construction phase? What are the main steps to develop design model? Q12. Describe the Activities in testing process. Q13. Discuss the structure of use cases in the interaction diagram.
Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak U3. #

Research Problems
Consider the following Library Management System(LIS) : The Librarian can create new member records by entering the member's name and address. LIS assigns a unique membership number to each new library member. The Librarian can also delete a membership by entering the membership number. LIS registers each book issued to a member. When a member returns a book, LIS deletes the book from the member's account and make the book available for future issue. When a member returns an overdue book, LIS software computes the penalty charge and prints a bill towards the fine payable by the member. A member can input either the name of a book or the name of the author of the book and query about the availability of the book. If available, LIS displays the following :
rack number in which book is located, the number of copies of books available for issue number of copies of books already issued

Perform the following. You can make suitable assumptions regarding the details of various features of LIS software but you must clearly write down the assumptions you make. a) Draw the use case diagram and give the use case description of issue and return of books. b) For implementing the LIS software identify the classes and their interrelationships and represent them in class diagram. C) Draw Sequence Diagram for Cash Withdrawal from ATM Machine.
Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak U3. #

References
Ivar Jacobson, Object Oriented Software Engineering, Pearson, 2004. Grady Booch, James Runbaugh, Ivar Jacobson, The UML User Guide, Pearson, 2004 3. R. Fairley, Software Engineering Concepts, Tata McGraw Hill, 1997. 4. P. Jalote, An Integrated approach to Software Engineering, Narosa, 1991. 5. Stephen R. Schach, Classical & Object Oriented Software Engineering, IRWIN, 1996. 6. James Peter, W Pedrycz, Software Engineering, John Wiley & Sons 7. Sommerville, Software Engineering, Addison Wesley, 1999. 8. http://www.gentleware.com/fileadmin/media/archives/userguides/poseidon_u sers_guide/userguide.html 9. http://www.gentleware.com/fileadmin/media/archives/userguides/poseidon_u sers_guide/statemachinediagram.html 10. http://www.developer.com/design/article.php/2238131/State-Diagram-inUML.htm 1. 2.

Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak

U3. #