Lecture IntegrationTesting

7/30/2019 Lecture IntegrationTesting

1/44

CIS 4932 Special Topics

Software TestingFall 2001

Integration Testing 2001, Dr. E.L. Jones


2/44

11/2001 Integration Testing 2

Purpose

This course prepares a

developer to practice unit

testing on a project by applyingthe concepts covered in the

Software Unit Test Concepts

course.


3/44


Purpose

This course prepares the development

team to plan and carry out an orderly

process of assembling the system fromtested units, and certifying the system

ready for formal system test. Use of a

controlled test environment ensures thevalidity of test results and facilitates

transition to formal test.


4/44


Agenda

An Example of Integration

More on Architecture

What is Integration?

Proposed Integration Test Process

Putting it All Together

Integration Test Approaches

Products & Deliverables


5/44



The process of combiningindividually developed

components into a system.

A BC

AB

System

ABC


6/44


What is A Component?

A component is a system building block.

The smallest component is a (composite) unit

A component may be formed by combining

other components

Top level components are identified in thesoftware architecture


7/44


The Software Architecture

Architecture defines components and

connections

Architecture depends on technology

Standard architectures exist

The software architecture is a design

product


8/44


Software Architecture

Building blocks and their connections

System

A B C

D

Interface

Shared

component


9/44


What is An Interface?

An interface is a set of connections between

components

Activated by a software call

Involves the flow of data in either direction

Connection may be transient or persistent

A connection is called an interface operation

Each interface (operation)is a unit


10/44


Interface Operations

One interface may have many operations.

System

A B NetComm

D

ftp

telnet

email


11/44


Agenda









12/44


An Example of Integration --

the aboutproduct.com Website

Simple site

Two action buttons

Refer a Friend -- send an email to a third pary

Click to Order -- accept responses to a survey

and store in a database

Accesses the corporate global database

Uses communication services


13/44


Integration -- Connecting The Parts

FormX

Net Comm

Bus Logic

SoftLogin

GDBAccess

GlobalDB

Applic

DB

email


14/44


Interfaces Between Components

Forms

Form

BusinessLogic NetComm

SoftLogin

BusinessLogic GDB

GDBAccess

Business Logic

Form

SoftLogin AppDB

NetComm

GDBAccess SoftLogin

GDB


15/44


Form Action Buttons

Click to Order

Form (Survey)

BusinessLogic

SoftLogin

AppDB GDBAccess

GDB

Refer a Friend

Form (Refer)

SoftLogin

BusinessLogic

AppDB NetComm

Action buttons connect paths through the system.


16/44


Interfaces -- CLICK TO ORDER

Home

page

Info

page

NetComm

BusLogic

SoftLogin

GDBAccess

GlobalDB

ApplicDB

email

SurveyData

Field Fixes

Survey

Form

SubmitN/E (Name, email)

SurveyData

N/E

N/E

N/E

click

click


17/44


What Can Go Wrong DuringIntegration?

Form accepts erroneous data

Form does not accept valid survey data Business logic accepts invalid data

SoftLogin can not access global database

Business logic does not store survey data

etc.


18/44


Getting to the Bottom of Failures

BRUTE FORCE: Individually check each

connection in the system

Set up in-flows to interface operation

Activate the interface operation

Verify out-flows from interface operation

BETTER: Incrementally integrate andtest, progressively expanding the number

of interfaces that have been tested.


19/44


Making the Connection I

Diagnosing integration problems is hard

many interface operations

many possible invocation sequences

difficulty reproducing the problem

An orderly, managed approach avoids chaos

and reduces the overall effort

Integration Testing approach should be

based on the architecture.


20/44


Agenda









21/44


What is Integration Testing?

Testing all connections within the software

in a controlled physical environment?

A Series of Unit Tests!

Enough to ensure each interface has been tested

These tests should already exist as unit tests

Selected ones should be applied (e.g., user

operation action buttons)


22/44


Usage Driven Integration Test

Test end-to-end operations -- use case or

user operation

Advantages Higher level test, fewer tests to run

Allows incremental development for high

priority user operations

Disadvantages

Difficult with unreliable components


23/44


Our Turn -- Usage Test Design

Discuss a process for identifying interfaces

used during a usage driven test.

Consider how the concept of coverage used

in white-box testing can be applied to

minimize the number of usage-driven testcases.


24/44


Agenda









25/44


Architecture May Reflect aDivision of Labor

Components are work assignments

System

A B C

D

Joe

Moe

All of Us

Larry

Curly


26/44


Object-Oriented ArchitectureUML Sequence Diagrams

Sequence of methods required to implement(test) a use case

Methods are explicit, but not every methodis an interface

May be incomplete if interfaces to non-OO

portions of system are not included Sequence Diagram good for internal

integration based on the OO model.


27/44


A Layered System ArchitectureModel

User-Visible -- GUI

Business Logic

Service -- Database, Comm1

2

3

Components vary in

distance from user.User operation triggers

thread of activity across

many levels.


28/44


Agenda









29/44


Rationale

Integration testing is driven by project size

and architecture. Simple projects can be

tested using a subset of the end-to-end tests

used for system testing. More complex

systems may require a combination of top-

down, bottom-up and sandwich integration,

tested by selected unit tests.


30/44


Integration Strategy

Test Drivers

Services Components

User-Visible Components

Calls to business logic ...

form tests buttontests

Business Logic


31/44



0. Define system architecture

1. Define the integration test environment

2. Associate components with layers3. Identify interfaces to layer components

4. Bottom-up test services layer interfaces

5. Top-down test user layer components

6. Sandwich test business logic components


32/44


0. Define System Architecture

Architecture should already exist

Refine to reflect components built, bought or

reused for the system Each component can be viewed as collection

of callable functions and shared data, along

with internal functions and private data Specify the physical environment in which

testing will occur.


33/44


1. Integration Test Environment

Test results depend on test environment

Different tests need different set-ups

Repeatability of results requires controlof test environment

Hardware platforms

Native software suite and versions Data sets

Version of software under test


34/44


2. Map Components To Layers

Logically associate software with layers

user-visible -- UI, navigation, user operations

business logic -- data flow, processing, output services -- standard, reusable (comm, database)

Each layer contains one or more components

composite units like classes groups of units/components


35/44


3. Identify Layer Interfaces

Interface provides access to layer

calls with data passing

global or shared data (database)

Identify interfaces actually used by system

Record these in the IT Worksheet

Each interface must be covered during testing


36/44


4. Bottom-Up Test Service Interfaces

Service component provides set of related

functions/data

Refine/Develop test drivers for servicecomponent

This should have been done at unit test time

Driver depends on the physical test environment

Manual or automated set-up may be required

Run tests and verify expected results


37/44


5. Top-Down Test User Components

Verify presentation, navigation

Accomplished during unit test of forms/UI

Repeat tests within integration environment

Verify calls to business logic, services

triggered by action buttons

(Development): Verify interface calls compile

(Testing): Usage-driven test

Can be done in parallel with services testing


38/44


6. Sandwich Test Business Logic

User-layer functions call business logic,

which calls tested services

The sandwich test is an end-to-end test ofsystem

This test reveals business logic errors

Top-down test verified that the right calls made Services have been tested

Errors caused by business logic


39/44


Agenda









40/44


RECOMMENDED PRACTICE

Analysis

Design

Implementation

Execution

Evaluation

Architecture

Diagram IT Strategy

Interface List

Services Drivers

UserOp Scripts

IT Environment

#Incidents,

Incidents List

Test Worksheet

IT Test Cases


41/44


Agenda









42/44


Putting It All Together

Nail down the physical test environment

and institute change control

Integrate trusted components

Devise strategy based on architecture

Exploit unit testing for integration testing

Automate testing of service components


43/44


Summary

The key to integration testing is theuse of unit tested components. The

architecture of the system drives the

sequence of integration and test

activities. With proper planning,

integration testing leverages unit

testing, resulting in a smooth and

efficient integration test effort.


44/44

SOLUTIONS TO EXERCISES

Lecture IntegrationTesting

Documents

Transcript of Lecture IntegrationTesting