Ooad Unit III

7/29/2019 Ooad Unit III

1/215

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

OBJECT-ORIENTED

ANALYSIS AND DESIGNConstruction and Testing

UNIT III


2/215


Learning ObjectivesConstruction Introduction the design model block design working with constructionTesting

Introduction on testing unit testing integration testing system testing

the testing process


3/215


CONSTRUCTION


4/215


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


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

What is Construction Phase?

All about BUILDINGthe system from model of analysis & requirement phase.

Consists of Design and Implementation.

Start from elaboration & continues to construction


6/215 Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi -63, by Nitish PathakU3.#

Why construction?

For seamless transition to source code; analysis model

not sufficient.

The actual system must be adapted to theimplementation environment.

Must explore into more dimensions.

To validate the analysis result.


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

#

Add A Dimension: Analysis To Design Space

Design

Behavior

Information

Presentation

Behavior

InformationPresentation

Analysis Space Design Space

ImplementationEnvironment


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

#

Artifacts for Construction

RequirementsModel

ImplementationModel

Analysis

Model

DesignModel

Construction

Input & Output Models of Construction


9/215


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


10/215


What is Design?

Specification Is about What, and Design is the start of the

How Inputs to the design processSpecification document, including models etc.

Outputs of the design process A design document that describes how the code will bewritten. Includes design models!

What subsystems, modules or components areusedHow these integrate (i.e. work together)

Information allowing testing of the system


11/215


The Purpose of System Design

Bridging the gap betweendesired and existing system ina manageable way

Use Divide and Conquer

We model the new systemto be developed as a set of subsystems

Problem

Existing System

NewSystem


12/215


Why is Design so Difficult? Analysis: Focuses on the application domain

Design: Focuses on the solution domain

Design knowledge is a moving targetThe 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


13/215


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? It should follow thespecifications.

Changeable :It Should Facilitate Change Change Is Inevitable


14/215


Efficiency

It Should Not Waste Resources. But:Better A Working Slow Design Than A Fast Design ThatDoes Not Work

SimplicityIt Should Be As Understandable As Possible

Important: A design should fully describe how coders willimplement the system in the next phase

Designs are blue-prints for code construction

Design Goals..


15/215


Levels of DesignThree possible levels:

System Design, if appropriatePart of Systems Engineering

High-level Software DesignArchitecture, architectural design

Low-level Software DesignDetailed Design, Module Design

Systems Engineering: Large combinations of hardware andsoftware.

Decompose system into subsystemsDetermine which subsystems are HW, which are SWSoftware Engineering activities thus become a partof a larger activity.

l d l


16/215


Develop Design Model

Create detailed plans (like blueprints) for implementation

Identify the Implementation Environment & drawconclusions.

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

D l D i M d l


17/215


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 wecan:

Compare different possible design solutions

Evaluate efficiency, ease of modification, maintainability,etc

I l i E i


18/215


Implementation Environment

Identify the actual technical constraints under which the systemshould be built

Including:The target environment

Programming languageExisting products that should be used (DBMSs, etc)

Strategies:

n As few objects as possible should be aware of theconstraints of the actual implementation environment


19/215


File Manager

Application Objects

MS-DOS Mac-OSUNIX

Implementation Environment: Target Environment

severalimplementations of the filemanagerblock

I l t ti E i t


20/215


Implementation EnvironmentTarget environment

Create a new blocks that represent occurrences of thechanged parts in the target environment

Strategies:Specified an abstract class

polymorphismThe object can check the platform at run-time

CASE statement in the source codeDecide this when the system us delivered

Provide several different modul which will be choosed later

Investigate whether the target environment will execute in adistributed wayon a different processors or different processes

I l t ti E i t


21/215


Implementation EnvironmentProgramming language

Affect the design in translating the concepts usedThe basic properties of the language and its environment

are fundamental for the designInheritance and Multiple inheritanceTypingStandardPortabilityStrategies for handling errors during run-time

Exception (Ada)Assertions (Eiffel)

Memory managementAutomatic garbage collection

The use of componentComponent library, such as interface objects



22/215


Implementation Environment..

Using existing productsDBMSUIMS (User Interface Management System)Network facilitiesInternally or externally developed applications that should beincorporatedProducts used during development

CompilersDebuggersPreprocessor

Other considerationsRequirement for performanceLimitations of memory



23/215



Other considerations

Strategies:To postpone optimizations until they are needed or you areabsolutly sure that they will be needed

the real bottlenecks are often missed and then newoptimizations are necessary

Use simulation or prototyping to investigate potentialoptimization 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 itshould be done



24/215



The people and organization involved in the

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 todaywill probably change during the systems life cycle

Traceability


25/215


Traceability

refines the analysis model in light of actual implementationenvironment.

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 designobjects.

One block is implemented as one class

Traceability


26/215


The blocks abstract theactual implementation

Traceability is extremelyimportant aspect of thesystem.

Changes made will beonly local to a module.Provides high functionallocalization (high

cohesion).

Traceability..

Example Recycling Machine Analysis Model


27/215


Receipt printer

Customer panel

Receipt basisDeposit items

Deposit item receiver Deposit

Report Generator

Operator Panel

Administrator Alarmist

Alarm Device

Alarm

extends

Can Bottle Crate




28/215



Example Recycling Machine Design Model


29/215


Example Recycling Machine Design Model

Working with the Design Model


30/215


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 representationin the analysis model

To delete blocks from the design modelTo change blocks in the design model (splitting and joiningexisting blocks)

To change the associations between the blocks in the designmodel

Use the component

Change in Environment


31/215


Change in Environment

Changing the associations between the blocks inthe design model.

extensions to stimuli

inheritance to delegation

Interaction Diagrams


32/215


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

te act o ag a s

Sequence Diagram (Contd)


33/215


Syntax and Semantics

Distinguishing asystem and theoutside world(RationalRose: Use

Actors )

Blocks life line(showing lifecycle)

Events occurringwithin a block

message

feedbacksignal

Sequence Diagram (Cont d)

Building an Interaction Diagram


34/215


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

Building an Interaction Diagram..


35/215


u d g a te act o ag a ..

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

The Skeleton for the Interaction Diagram


36/215


g

Example Interaction Diagram for Use Case Returning Item


37/215


Example Interaction Diagram for Use Case Returning Item


38/215


Sequence Diagram


39/215


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;

q g

Sequence Diagram


40/215


Events (when acustomer 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;}

q g

Sequence Diagram


41/215


Rational Rose Collaboration Diagram


42/215


Advance Interaction Diagrams


43/215


Synchronous and asynchronous

A synchronous message/signal is a control which has to waitfor 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.

g

Synchronous & Asynchronous


44/215


here there

Simple(unspecified)

synchronous

asynchronous

Recursion in SD


45/215


Syntax:

Use Case with Extension


46/215


Described by a probe position in the interaction diagram

The probe position indicates a position in the use caseto be extended

Often accompanied by a condition which indicates under whatcircumstances the extension should take placed

Example Probe position


47/215


Homogenization


48/215


In parallel design process, several stimuli with the samepurpose or meaning are defined by several designers.

These stimuli should be consolidated to obtain as fewstimuli as possible.

Called homogenization .

Example - Homogenization


49/215


What_is_your_phone_number?

Where_do_you_live?Get_addressGet_address_and_phone_number

Homogenized into:Get_addressGet_phone_number

Structure of SD


50/215


Centralised structure -- Fork: Everything is handled andcontrolled by the left-most block.

Structure of SD


51/215


Decentralised structure -- Stair: There is no central controlblock.

Structure of SD


52/215


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.


53/215


Structure of SD


54/215


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

Structure of SD


55/215


Structure of SD..


56/215


F o r k

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

Structure of SD.


57/215


Stair indicates decentralized structure and is characterized by

delegated responsibility.Each object only knows a few of the other objects and knowswhich objects can help with a specific behavior.This structure is appropriate when:The operation have a strong connection. Strong connectionexists if the objects:

form a consist -of hierarchyform an information hierarchyform a fixed temporal relationshipform a (conceptual) inheritance relationship

The operation will always be performed in the same order

Structural Control in Sequence Diagram


58/215


Optional Execution

Conditional Execution Parallel Execution Loop Execution Nested

Block Design


59/215


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 designedbefore 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.


60/215


Block Design...


61/215


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

Block Design Comments


62/215


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).

UML Class Diagram


63/215


a collection of classes and interfaces, along with the

collaborations and relationships among classes and

interfaces

How to Build Class Diagram


64/215


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

Syntax Class Diagram


65/215


Composition


66/215


Aggregation


67/215


Association


68/215


Inheritance


69/215


Realization


70/215


Multiplicity Notation


71/215


1Class exactly one

* Class many (zero or more)

0..1 Class optional (zero or more)

m..nClass numerically specified

{ordered} *Class ordered

Attributes Structural Features


72/215


An attribute describes a property as a line of textwithin the class box

Syntaxvisibility name: type multiplicity = default {property-string}

{+,-, {Integer, { [1], {0, { readOnly,#,`} Boolean, [n] foo, ordered,String, [0..1], 12-05-06, nonunique,Date, [m..n], 100 , unique,Money, [*], } bag,} [1..*], set

[n..*]} }

Class Diagram


73/215


Object Behavior


74/215


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 willlater be expressed in preconditions.

This is particularly important in reactive systems

Object Behavior...


75/215


To provide a simplified description that increases

understanding of the block without having to go down to

source code

Less dependant on programming language

Machine stack

Textual Notation


76/215


Machine stackState init

input createinstancenext state emptyotherwise error;

State empty

input pushdo store on top

next state loadedprint stackis empty

otherwise error;..endmachine

Object Behavior...


77/215


Stimulus control object

An object that perform the same operation independent of

state when a certain stimulus is received.

Entity objects

Object Behavior...


78/215


state-controlled objects

Objects that select operations not only from the stimulus

received, but also from the current state

Control object

Notation used for State Transition Diagram


79/215



80/215


Operation


81/215


STD


82/215


STD for Deposit Item


83/215


STD for Deposit Item Receiver


84/215


State Diagram in UML


85/215


show the different states of an entity also how an entity

responds to various events by changing from one state

to another

State A condition or situation during the life of an object during


86/215


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)

State Diagram in UML..


87/215




88/215




89/215


Internal Block Structure In case of OOPL object-module becomes classes


90/215


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

Implementation Now, need to write code for each block.


91/215


,

Implementation strategy depends on the programminglanguage.

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.

Mapping


92/215


Analysis Design Source code C++

Analysis objects Block 1..N classes

Behavior in objects Operations Member functions

Attributes(class) Attributes(class) Static variables

Attributes(instance) Attributes(instance) Instance variables

Analysis Design Source code C++Mapping..


93/215


Acquuaintanceass. Acquuaintanceass. Instance variables

Communicationass.

Communicationass.

Reference to afunction

Interactionbetween objects

Stimulus Call to a functiom

Usecase Designed usecase Sequence of calls

subsystem Subsystem File

Implementation EnvironmentEverything that does not come from analysis phase, including


94/215


y g y p , g

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.

Other Considerations in the Construction Phase

Subsystems defined in analysis phase are used to guide the


95/215


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

What we learntWhat is Construction Phase

h C i


96/215


Why Construction

Add a Dimension Artifacts for ConstructionDesign (What, Purpose, Goals, Levels)Implementation EnvironemntTraceabilityInteraction DiagramBlock design

Block Behavior Implementation

Object Oriented Testing Concepts Testing Verification

Testing TechniquesRegression Test


97/215


Verification Validation Debugging Certification Clean Room Software Engineering Error

Fault Failure Testing Level

Unit testingIntegration Testing

System Testing

Testing Focuses

Operation testFull-scale testStress testOverload test Negative testTest based on requirementsErgonomic testsTesting of the user documentationAcceptance testing

Stubs

Object Oriented Testing Concepts..


98/215


Drivers Test bed Equivalence set Equivalence partitioning

Automatic TestingTest data

Test program

When the testing activities must be commence?



99/215


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 attitudeadopted toward it?

Why testing must be planned in the same manner as analysisand construction?

Why it is not possible to arrive at high quality software just bytesting and debugging?

How testing can be done on analysis and design documents?

Why reviews and inspections should also be performed inll l t lid ti



100/215


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 thandefect removal .

Discuss testing strategy. Why bottom up testing strategy isbetter 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?

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



101/215


are a separate product?

Why unit test of object-oriented code is more complex thantesting ordinary (procedural) code?

What is difference between ordinary (procedural) unit testingand 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?

How inheritance effect the structural testing?

If ll i i l i h d f i i



102/215


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?

Why we need to prepare test reports while writing testspecifications?



103/215


specifications?

When a test is done what are the different reasons of detectedfailure?

What we need to do when testing has been completed?

UNIT III Learnings Construction

Introduction


104/215


the design modelblock designworking with construction

TestingIntroductionon testingunit testingintegration testingsystem testing

the testingprocess

SOFTWARE DEVELOPMENT LIFE CYCLE(SDLC)


105/215


Srihari Techsoft

Phases of SDLC

Requirement Specification and Analysis Design Coding Testing Implementation Maintenance

(SDLC)

The Design process


106/215


Srihari Techsoft

Breaking down the product into independentmodules to arrive at micro levels.

2 different approaches followed in designing

Top Down ApproachBottom Up Approach

Top-down approach


107/215


Srihari Techsoft

Bottom-Up Approach


108/215


Srihari Techsoft

Most Common Software problems


109/215


Srihari Techsoft

Incorrect calculationIncorrect data edits & ineffective data editsIncorrect matching and merging of dataData searches that yields incorrect resultsIncorrect processing of data relationshipIncorrect coding / implementation of businessrules

software performance

Confusing or misleading dataS ft bilit b d


110/215


Srihari Techsoft

Software usability by end usersInconsistent processingUnreliable results or performance

Incorrect interfaces with other systemsInadequate performance and security controlsIncorrect file handling

Software testing can be stated as the process of validating and verifying that a software


111/215


g y g

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 thedevelopment process. However, most of the test effortoccurs after the requirements have been defined andthe coding process has been completed.

A primary purpose of testing is to detect softwarefailures so that defects may be discovered and


112/215


y

corrected. Testing cannot establish that a productfunctions properly under all conditions but can onlyestablish that it does not function properly under specificconditions

Testing takes creativity Testing often viewed as dirty work. To develop an effective test, one must have:


113/215


Detailed understanding of the systemKnowledge of the testing techniquesSkill to apply these techniques in an effective and efficient manner

Testing is done best by independent testersWe often develop a certain mental attitude that the program should in acertain way when in fact it does not.

Objectives of testingE i i h h l f fi di


114/215


Srihari Techsoft

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.

Objectives of testing A good test case is one that has a probability of finding


115/215


Srihari Techsoft

g p y g

undiscovered error. A good test is not redundant. A good test should be bestof type . A good test should neither be too simple nor too

complex.

Objective of a Software Tester Find bugs as early as possible and make sure they get


116/215


Srihari Techsoft

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 touncover the hidden bugs and also ensure that thesoftware is usable and reliable

VERIFICATION & VALIDATION


117/215


Srihari Techsoft

Verification - typically involves reviews and meeting toevaluate documents, plans, code, requirements, andspecifications. This can be done with checklists, issueslists, and inspection meeting.

Validation - typically involves actual testing and takesplace after verifications are completed.

Validation and Verification process continue in acycle till the software becomes defects free.

Software Development Process Cycle


118/215


Srihari Techsoft

Plan

Do

Check

Action

PLAN (P): Device a plan. Define your objective anddetermine the strategy and supporting methods required toachieve that objective.


119/215


Srihari Techsoft

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 theresults are obtained.

ACTION (A): Take the necessary and appropriate action if checkup tells that the work is not being performedaccording to plan or not as expected.

SOFTWARE TESTING LIFECYCLE - PHASES

Requirements study


120/215


Srihari Techsoft

Requirements study

Test Case Design and Development

Test Execution

Test conclusion

Test Process Analysis

Requirements study


121/215


Srihari Techsoft

Testing Cycle starts with the study of clients requirements.

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

Analysis & Planning


122/215


Srihari Techsoft

Test objective and coverageOverall scheduleStandards and Methodologies

Resources required, including necessarytrainingRoles and responsibilities of the teammembersTools used

Test Case Design and Development


123/215


Srihari Techsoft

Component Identification Test Specification Design Test Specification Review

Test Execution Code Review Test execution and evaluation Performance and simulation

Test Closure


124/215


Srihari Techsoft

Test summary report Project Documentation

Test Process Analysis

Analysis done on the reports and improving theapplications performance by implementing new technologyand additional features.

Testing Levels


125/215


Unit testing Integration testing

System testing Acceptance testing

Types of Testing Unit Testing:

Individual subsystem


126/215


Carried out by developersGoal: Confirm that subsystems is correctly coded andcarries out the intended functionality

Integration Testing:Groups of subsystems (collection of classes) andeventually the entire systemCarried out by developersGoal: Test the interface among the subsystem

System Testing System Testing:

The entire system


127/215


Carried out by developersGoal: Determine if the system meets the requirements(functional and global)

Acceptance Testing:

Evaluates the system delivered by developersCarried out by the client. May involve executing typicaltransactions on site on a trial basisGoal: Demonstrate that the system meets customer requirements and is ready to use

Implementation (Coding) and testing go hand in hand

Testing Activities

Tested

RequirementsAnalysis

Document

SystemDesign

Document

UnitTest

User

RequirementsAnalysis

Document

SubsystemCode


128/215


Subsystem

SubsystemCode

FunctionalIntegration

Unit

TestedSubsystem

Tested Subsystem

Test Test

Test

UnitTest

ManualSubsystemCode

All tests by developer

Functioning

SystemIntegrated

Subsystems

GlobalRequirements

Testing Activities continuedClients

Understandingof Requirements

UserEnvironment


129/215


Users understanding Tests by developer

Performance AcceptanceTest

FunctioningSystem

TestInstallation

Test

System inUse

UsableSystem

ValidatedSystem

AcceptedSystem

Tests (?) by user

Tests by client

Unit testingThe most micro scale of testing.


130/215


Srihari Techsoft

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

Unit testingObjectives To test the function of a program or unit of code

such as a program or module


131/215


Srihari Techsoft

To test internal logicTo verify internal designTo test path & conditions coverageTo test exception conditions & error handling

When After modules are coded

Input Internal Application DesignUnit Test Plan

Output Unit Test Report

Who Developer


132/215


Srihari Techsoft

Methods White Box testing techniques

Tools Debug

Re-structureCode AnalyzersPath/statement coverage tools

Education Testing MethodologyEffective use of tools

Incremental integration testing


133/215


Srihari Techsoft

Continuous testing of an application as and when anew functionality is added.

Applications functionality aspects are required to be independent enough to work separately beforecompletion of development.

Done by programmers or testers.

Integration Testing


134/215


Srihari Techsoft

Testing of combined parts of an application todetermine their functional correctness.

Parts can becode modulesindividual applications

client/server applications on a network.

Types of Integration Testing


135/215


Srihari Techsoft

Big Bang testing

Top Down Integration testing

Bottom Up Integration testing

Integration testing Objectives To technically verify proper

interfacing between modules, and


136/215


Srihari Techsoft

within sub-systemsWhen After modules are unit tested

Input Internal & External Application

DesignIntegration Test Plan

Output Integration Test report

Who Developers

Methods White and Black Box


137/215


Srihari Techsoft

techniquesProblem / ConfigurationManagement

Tools DebugRe-structureCode Analyzers

Education Testing Methodology

Effective use of tools

Integration Testing Strategy The entire system is viewed as a collection of

subsystems (sets of classes) determined during thesystem and object design.


138/215


The order in which the subsystems are selected for testing and integration determines the testing strategy

Big bang integration (Nonincremental)

Bottom up integrationTop down integrationSandwich testingVariations of the above

For the selection use the system decomposition fromthe System Design

Example: Three Layer Call Hierarchy

A Layer I


139/215


B C D

GFE

Layer II

Layer III

Integration Testing: Big-Bang Approach

U i T

Unit TestA

Dont try this!


140/215


Unit Test

F

Unit TestE

Unit TestD

Unit TestC

Unit TestB

System Test

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

b


141/215


subsystems This is done repeatedly until all subsystems are included in the

testing

Bottom-up IntegrationA

B C D

Layer I

Layer IITest E


142/215


GFE Layer III

Test F

Test G

Test C

Test D,G

Test B, E, F

Test

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

Pros and Cons of bottom up integration testing

Bad for functionally decomposed systems:T t th t i t t b t (UI) l t


143/215


Tests the most important subsystem (UI) last

Useful for integrating the following systemsObject-oriented systemsreal-time systemssystems with strict performance requirements

Top-down Testing Strategy Test the top layer or the controlling subsystem first Then combine all the subsystems that are called by

th t t d b t d t t th lti ll ti


144/215


the tested subsystems and test the resulting collectionof subsystems

Do this until all subsystems are incorporated into thetest

Top-down Integration TestingA

B C D

Layer I

Layer II


145/215


GFE Layer III

Test A

Layer I

Test A, B, C, D

Layer I + II

TestA, B, C, D,

E, F, G

All Layers

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


146/215


A target layer in the middle A layer above the target A layer below the targetTesting converges at the target layer

How do you select the target layer if there are more than3 layers?

Heuristic: Try to minimize the number of stubs and drivers

Sandwich Testing StrategyA

B C D

GFE

Layer I

Layer II

Layer III

Test E


147/215


y

Test D,G

Test B, E, F

TestA, B, C, D,

E, F, G

Test F

Test G

Test A

BottomLayerTests

TopLayerTests

Test A,B,C, D

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


148/215


before integration Solution: Modified sandwich testing strategy

Modified Sandwich Testing Strategy Test in parallel:

Middle layer with drivers and stubsTop layer with stubs


149/215


Bottom layer with drivers

Test in parallel:Top layer accessing middle layer (top layer replaces drivers)

Bottom accessed by middle layer (bottom layer replacesstubs)

Modified Sandwich Testing StrategyA

B C D

GFE

Layer I

Layer II

Layer III

Test E

Test B

Triple

Triple

DoubleTest I


150/215


Test F

Test G

Test D

Test A

Test C

Test B, E, FTripleTest ITriple

Test I

Test D,G

DoubleTest II

DoubleTest II

DoubleTest I

Test A,C

Test

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


151/215

System Testing Functional Testing Structure Testing Performance Testing Acceptance Testing


152/215


Acceptance Testing Installation Testing

Impact of requirements on system testing:

The more explicit the requirements, the easier they are to test.Quality of use cases determines the ease of functional testingQuality of subsystem decomposition determines the ease of structure testingQuality of nonfunctional requirements and constraints

determines the ease of performance tests:


153/215

Functional Testing.

Essentially the same as black box testing Goal: Test functionality of system

Test cases are designed from the requirements analysis


154/215


.

Test cases are designed from the requirements analysisdocument (better: user manual) and centered aroundrequirements and key functions (use cases)

The system is treated as black box.

Unit test cases can be reused, but in end user orientednew test cases have to be developed as well.

Performance Testing Stress Testing

Stress limits of system (maximum # of users, peak demands, extended

operation )V l i

Timing testingEvaluate response times and timeto perform a function

Environmental testT l f h h idi


155/215


) Volume testing

Test what happens if large amounts of data are handled

Configuration testingTest the various software and hardwareconfigurations

Compatibility testTest backward compatibility withexisting systems

Security testingTry to violate security requirements

Test tolerances for heat, humidity,motion, portability

Quality testingTest reliability, maintainability &availability of the system

Recovery testingTests systems response topresence of errors or loss of data.

Human factors testingTests user interface with user

Acceptance Testing

Goal: Demonstrate systemis ready for operational use

Choice of tests is made byclient/sponsor

Alpha test: Sponsor uses the software at

the developers site. Software used in a controlled


156/215


client/sponsor Many tests can be taken fromintegration testing

Acceptance test is performedby the client, not by thedeveloper.

Majority of all bugs in software istypically found by the client after the system is in use, not by thedevelopers or testers. Therefore

two kinds of additional tests:

Software used in a controlledsetting, with the developer always ready to fix bugs.

Beta test:

Conducted at sponsors site(developer is not present)Software gets a realistic workoutin target environ- mentPotential customer might getdiscouraged

Testing has its own Life Cycle

Establish the test objectives

Design the test cases


157/215


gWrite the test cases

Test the test cases

Execute the testsEvaluate the test results

Change the system

Do regression testing

Test Team

AnalystProgrammer

too familiar with code

ProfessionalTester


158/215


TestTeamUser

ConfigurationManagement

Specialist

SystemDesigner

System Testing

Objectives To verify that the system components perform controlfunctionsTo perform inter-system test

To demonstrate that the system performs bothfunctionally and operationally as specified


159/215


Srihari Techsoft

functionally and operationally as specifiedTo perform appropriate types of tests relating toTransaction Flow, Installation, Reliability etc.

When After Integration Testing

Input Detailed Requirements & External ApplicationDesignMaster Test PlanSystem Test Plan

Output System Test Report

Who Development Team and Users

Methods Problem / Configuration Management


160/215


Srihari Techsoft

g g

Tools Recommended set of tools


Systems Integration Testing

Objectives To test the co-existence of products and applicationsthat are required to perform together in the

production-like operational environment (hardware,software, network)

To ensure that the system functions together with allh f l


161/215


Srihari Techsoft

the components of its environment as a total systemTo ensure that the system releases can be deployedin the current environment

When After system testingOften performed outside of project life-cycle

Input Test StrategyMaster Test PlanSystems Integration Test Plan

Output Systems Integration Test report

Who System Testers

Methods White and Black Box techniquesP bl / C fi i


162/215


Srihari Techsoft

qProblem / Configuration

ManagementTools Recommended set of tools


Acceptance Testing

Objectives To verify that the system meets the

user requirements


163/215


Srihari Techsoft

qWhen After System Testing

Input Business Needs & Detailed

RequirementsMaster Test PlanUser Acceptance Test Plan

Output User Acceptance Test report

Who Users / End Users

Methods Black Box techniques

Problem / ConfigurationManagement


164/215


Srihari Techsoft

Management

Tools Compare, keystroke capture & playback,regression testing

Education Testing MethodologyEffective use of toolsProduct knowledge

Business Release Strategy

TESTING METHODOLOGIES AND


165/215


Srihari Techsoft

TESTING METHODOLOGIES ANDTYPES

Testing methodologies

Black box testing


166/215

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


167/215


Srihari Techsoft

g

Knowledge of the internal program design and code required. Tests are based on coverage of code

statements,branches,paths,conditions.

Black box / Functional testing

Based on requirements and functionality

Not based on any knowledge of internal


168/215


Srihari Techsoft

Not based on any knowledge of internaldesign or code

Covers all combined parts of a system

Tests are data driven

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 ("testcases")


169/215


Goal: Reduce number of test cases by equivalencepartitioning:

Divide input conditions into equivalence classesChoose test cases for each equivalence class. (Example: If anobject is supposed to accept a negative number, testing onenegative number is enough)

White box testing / Structural testing

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


170/215


Srihari Techsoft

Based on coverage of code statements, branches, paths,conditions

Tests are logic driven

White-box Testing Focus: Thoroughness (Coverage). Every statement in the component isexecuted at least once.

Four types of white-box testingStatement TestingLoop TestingPath TestingBranch Testing


171/215


Branch Testing

White-box Testing (Continued) Statement Testing (Algebraic Testing): Test singlestatements (Choice of operators in polynomials, etc)

Loop Testing:

Cause execution of the loop to be skipped completely.(Exception: Repeat loops)L b d l


172/215


if ( i = TRUE) printf("YES\n"); else printf("NO\n");Test cases: 1) i = TRUE; 2) i = FALSE

Loop to be executed exactly onceLoop to be executed more than once

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 testedat least once

Constructing the Logic Flow DiagramStart

2

1

F

T


173/215


3

4 5

6

7

8 9

Exit

T F

T F

T

Comparison of White & Black-box Testing

White-box Testing:Potentially infinite number of pathshave to be testedWhite-box testing often tests what is

done, instead of what should be doneCannot detect missing use cases

Both types of testing are needed White-box testing and black box

testing are the extreme ends of atesting continuum.

Any choice of test case lies inbetween and depends on the


174/215


Black-box Testing:Potential combinatorial explosion of test cases (valid & invalid data)Often not clear whether the selectedtest cases uncover a particular error Does not discover extraneous usecases ("features")

pfollowing:

Number of possible logical pathsNature of input data

Amount of computationComplexity of algorithms and datastructures

Functional testingBlack box type testing geared to functional requirements of anapplication.

Done by testers.S t t ti g


175/215


Srihari Techsoft

System testingBlack box type testing that is based on overall requirementsspecifications; covering all combined parts of the system.

End-to-end testingSimilar to system testing; involves testing of a complete applicationenvironment in a situation that copies real-world use.

Regression testing

Re-testing after fixes or modifications of thesoftware or its environment.


176/215


Srihari Techsoft

Acceptance testing

Final testing based on specifications of the end-user or customer


177/215


Srihari Techsoft

Load testing

Testing an application under heavy loads.Eg. Testing of a web site under a range of loads todetermine, when the system response timedegraded or fails.

Stress Testing

Testing under unusually heavy loads, heavyrepetition of certain actions or inputs, input of

large numerical values, large complex queries to adatabase etc.


178/215


Srihari Techsoft

database etc.

Term often used interchangeably with load and

performance testing. Performance testing

Testing how well an application complies to performance requirements.

Install/uninstall testing

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

Recovery testing


179/215


Srihari Techsoft

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.

Exploratory testing / ad-hoc testingInformal SW test that is not based on formal test plans or test cases; testers will be learning the SW in totality as they testit.


180/215


Srihari Techsoft

Comparison testingComparing SW strengths and weakness to competing

products .

Alpha testingTesting done when development is nearing

completion; minor design changes may still bemade as a result of such testing.


181/215


Srihari Techsoft

Beta-testing

Testing when development and testing areessentially completed and final bugs and problemsneed to be found before release.

White Box - testing techniqueAll independent paths within a module have been exercised

at least once

Exercise all logical decisions on their true and false sides


182/215


Srihari Techsoft

g

Execute all loops at their boundaries and within their

operational bounds

Exercise internal data structures to ensure their validity

This white box technique focuses on the validity of loopconstructs.

different classes of loops can be defined

Loop Testing


183/215


Srihari Techsoft

different classes of loops can be defined

simple loops

nested loops

Other White Box Techniques Statement Coverage execute all statements at least once

Decision Coverage execute each decision direction at least onceCondition Coverage execute each decision with all possible


184/215


Srihari Techsoft

g poutcomes 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 leastonce.

Examples

Statement Coverage Examples

Eg. A + B

If (A = 3) ThenB = X + YE d If


185/215


Srihari Techsoft

End-If

While (A > 0) DoRead (X)

A = A - 1End-While-Do

Decision Coverage - ExampleIf A < 10 or A > 20 Then

B = X + Y

Condition Coverage ExampleA = X


186/215


Srihari Techsoft

If (A > 3) or (A < B) ThenB = X + Y

End-If-Then

While (A > 0) and (Not EOF) DoRead (X)A = A - 1

End-While-Do

Incremental Testing

A disciplined method of testing the interfaces between unit-tested programs as well as between system components.

Involves adding unit-testing program module or componentone by one and testing each result and combination


187/215


Srihari Techsoft

one by one, and testing each result and combination.

There are two types of incremental testingTop-down testing form the top of the module hierarchy andwork down to the bottom. Modules are added in descendinghierarchical order.


188/215


Srihari Techsoft

Bottom-up testing from the bottom of the hierarchy andworks up to the top. Modules are added in ascendinghierarchical order.

Testing Levels/Techniques

WhiteBox

Black Box

Incre-mental

Thread

Unit Testing X


189/215


Srihari Techsoft

IntegrationTesting

X XX

System Testing X

AcceptanceTesting

X

TEST PLAN Objectives

To create a set of testing tasks.

Assign resources to each testing task.


190/215


Srihari Techsoft

g g

Estimate completion time for each testing task.

Document testing standards.

A document that describes thescopeapproachresourcesschedule

of intended test activities.Id tifi th


191/215

Identifies thetest items

features to be testedtesting taskstask allotmentrisks 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 whyand how of product validation.


192/215


Srihari Techsoft

A Test Plan should bethorough enough (Overall coverage of test to be conducted)

useful and understandable by the people inside and outside thetest group.

Test Approach

Details on how the testing is to be performed.Any specific strategy is to be followed for

testing (including configuration management)


193/215


Srihari Techsoft

testing (including configuration management).

Entry CriteriaVarious steps to be performed before the start of a test i.e.fundamentals.E.g.

Timely environment set up


194/215


Srihari Techsoft

Timely environment set upStarting the web server/app server Successful implementation of the latest build etc.

ResourcesList of the people involved in the project and their designationetc.

Tasks/ResponsibilitiesTasks to be performed and responsibilities assigned to the variousteam members.

Exit CriteriaContains tasks like


195/215


Srihari Techsoft

Bringing down the system / serverRestoring system to pre-test environment

Database refresh etc.

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

Hardware / Software RequirementsDetails of PCs / servers required to install the application or performthe testingSpecific software to get the application running or to connect to thedatabase etc.


196/215


Srihari Techsoft

Risks & improvement PlansList out the possible risks during testingimprovement plans to implement incase the risk actually turns into areality.

Tools to be used

List the testing tools or utilitiesEg.WinRunner, LoadRunner, Test Director, Rational Robot,

QTP.Deliverables


197/215


Srihari Techsoft

Various deliverables due to the client at various points of timei.e. Daily / weekly / start of the project end of the project etc.These include test plans, test procedures, test metric, statusreports, test scripts etc.

Good Test Plans

Developed and Reviewed early.

Clear, Complete and Specific

Specifies tangible deliverables that can be inspected


198/215


Srihari Techsoft

Specifies tangible deliverables that can be inspected.

Staff knows what to expect and when to expect it.

Good Test Plans

Realistic quality levels for goals

Includes time for planning

Can be monitored and updatedIncludes user responsibilities


199/215


Srihari Techsoft

p

Based on past experience

TEST CASES

Test case is defined asA set of test inputs, execution conditions and expected results,

developed for a particular objective.Documentation specifying inputs, predicted results and a set of


200/215


Srihari Techsoft

p y g p pexecution conditions for a test item.

Specific inputs that will be tried and the procedures thatwill be followed when the software tested.

Sequence of one or more subtests executed as a sequenceas the outcome and/or final state of one subtests is theinput and/or initial state of

Date post:	14-Apr-2018
Category:	Documents
Upload:	shubham-gupta
View:	259 times
Download:	2 times

Ooad Unit III

Documents