Chap 3 - Software Engineering and Testing

8/9/2019 Chap 3 - Software Engineering and Testing

1/56

Software Engineering and Testing

Main Menu 1 of 56

Software Engineering andTesting


2/56


Main Menu 2 of 56

Objective

To be able to understand testing

principles and techniques and softwareengineering concepts.


3/56


Main Menu 3 of 56

Scope

Software System Lifecycle models

Waterfall

V model Prototyping

Incremental

Spiral


4/56


Main Menu 4 of 56

Scope

Verification and Validation

Testing principles

Testing techniques

Testing strategies

Test completion criteria

The Engineering Approach to Software

Development CASE technology

Analysis model


5/56


Main Menu 5 of 56

Software Engineering

Software is a collection of computer

programs, procedures, rules and associated

documentation and data.

Software Engineering is the systematic

approach to the development, operation,

maintenance, and retirement of software.


6/56


Main Menu 6 of 56

Software System Life-cycle Models

It is a convenient way of dividing a project

into phases.

Each phase represents a distinct stage inthe software development.

Life cycle activities transform user needs

into a software product that satisfies theneeds.


7/56


Main Menu 7 of 56

Stages in a software development life cycle

Requirements

Design

Construction Operation and Maintenance


8/56


Main Menu 8 of 56

Requirements

The requirement phase translates the

needs of the client into a formal document,

bringing the client and the supplier to an

agreement on what the product will

provide.


9/56


Main Menu 9 of 56

Requirements (Definition)

A condition of capability needed by a user

to solve a problem or achieve an objective.

A condition or capability that must be metor possessed by a system to satisfy a

contract, standard, specification, or other

formally imposed document.


10/56


Main Menu 10 of 56

Requirements

The output of this phase is the Software

Requirements Specification (SRS)

document.

SRS is the document that will say what the

proposed system will do without going into

how it will be done.


11/56


Main Menu 11 of 56

Requirements

The SRS should include the followinginformation.

Functionally, what the program is to do.

What the input will be like, such as the form. Format, datatypes and units for input.

The form, format, data types and units for the output.

How exceptions, errors and deviations are to be handled.

For scientific computations, the numerical method or atleast the required accuracy of the solution.

The computer environment required or assumed, e.g. themachine, operating system and implementation language.


12/56


Main Menu 12 of 56

Design

The design activity begins when the

requirement document for the software to

be developed is available.

It is the first step in coming to a solution.

Design is essentially the blueprint for the

solution.


13/56


Main Menu 13 of 56

Design

Requirements and design documents

together should describe the problem to be

solved and organization of the solution.

It should give a clear idea to the reader

without resorting to code reading.


14/56


Main Menu 14 of 56

Design

The information that should be included in thedesign document is:

Principle data structures should be specified since the waykey data are organized frequently shapes the structure ofthe entire program.

Functions, algorithms, heuristics or special techniquesused for processing should be recorded.

The basic program organization should be stated.

Subdivisions, modularisation, internal and externalinterfaces should be specified.

Project specific information.


15/56


Main Menu 15 of 56

Design

The design process for software systems

has two levels

System design

Detailed design


16/56


Main Menu 16 of 56

Construction

The construction or coding and testing

stage is what most people think of when

speaking of programming.

If requirements and design are done

carefully and correctly, coding is

straightforward, almost mechanical.


17/56


Main Menu 17 of 56

Construction

The first step in verification during

construction stage is to determine if the

code is consistent with design.

Code and design should both exhibit the

same modular structure and have the same

module interfaces.


18/56


Main Menu 18 of 56

Construction

Code inspections or reviews are a very

useful tool and can considerably enhance

reliability and reduce effort during testing.

Testing should be performed in a

systematic manner.

The actual execution of the program using

the test data must also be performed in an

orderly manner.

S f d


19/56


Main Menu 19 of 56

Operation and maintenance

Typical functions performed are:

Identification and correction of previously existent errors,

faults or failures which were undetected during either

initial development and test or maintenance and test Modifications to improve system performance without

adding new performance capabilities, e.g., changes to

account for system hardware enhancements or shortfalls,

or to improve user interfaces Enhancements to add new performance capabilities. All

these are just different forms of software development

activities.

S f E i i d T i


20/56


Main Menu 20 of 56

Waterfall ModelSystem

FeasibilityValidation

Req. Analysis& Project

PlanningValidation

System

DesignVerification

Detailed

DesignVerification

Coding

Verification

Testing and

Integration

Installation Operations

and

Maintenance

FeasibilityReport

Requirements Document

And Project Plan

System DesignDocument

Detailed

Design Document

Programs

Test Plan,

Test Report

And Manuals

Installatio

n Report

S f E i i d T i


21/56


Main Menu 21 of 56

V-Shaped Model

The V-shaped model is similar to the

waterfall model except that it emphasizes

the importance of considering the testing

activities up front instead of later in the

lifecycle.

S f E i i d T i


22/56


Main Menu 22 of 56

V-Shaped Model

In the V-shaped model, each test phase is

considered in its matching development

phase, as given below.

Requirements == Acceptance test

High level design == System/Integration test

Detailed design == Unit test

S ft E i i d T ti


23/56


Main Menu 23 of 56

Prototyping Model

This model is generally used to develop a quick

implementation of the software prior to or during

the software requirements phase.

The customer uses the prototype and providesfeedback to the software development team as to

its strength and weaknesses.

Based on this feedback the prototype is refined orchanged to meet the real needs of the customer.

S ft E i i d T ti


24/56


Main Menu 24 of 56

Prototyping Model

Requirements Analysis

Design

Construction

Design Construction

S ft E i i d T ti


25/56


Main Menu 25 of 56

Incremental Model

The incremental model allows a project to

construct the software in incremental

stages where each stage adds additional

functionality.

Each stage consists of design, code and unit

test, integration test and delivery.

S ft E i i d T ti


26/56


Main Menu 26 of 56

Incremental Model

Design (0) Implement (0) Analysis (0)

Design (1) Implement (1) Analysis (1)

Design (n) Implement (n) Analysis (n)



27/56


Main Menu 27 of 56

Spiral Model

This model provides a risk oriented

software lifecycle.

The activities in this model can beorganized like a spiral that has many

cycles.



28/56


Main Menu 28 of 56

Spiral Model

Fig. 1.4 Spiral Model

Risk

Analysis

Risk

Analysis

Risk

Analysis

Proto

type 1

Proto

type 2

Proto

type 3

Operational

Prototype

Evaluate alternatives, identify, resolve

risks

Determine objectives, alternatives,

constraints

Risk

Analysis

Requirements Plan

Life cycle plan

Development Plan

Integration and Test

Plan

Plan next phase

Commitment

PartitionReview

Impleme-

ntation

Acceptance Test

Integration and

test

Unit

test

Code

Concept of

Operation

Requirements

Validation

Software

Requirements

S/w product design

Design Validation and

verification

Develop, verify next level

product

Simulations, models, benchmarking

Progress

through

steps


29/56



30/56


Main Menu 30 of 56


A walkthrough is an informal meeting for

evaluation of the software.

A small set of paper test cases is preparedand each test case is mentally exercised.

The test data is walked through the logic of

the program and the state of the program

is monitored on paper.



31/56


Main Menu 31 of 56


In inspection, a checklist is used to read the

program and find the errors.

If checklists are properly designed theerrors can be found very easily.

An inspection can be held for any technical

product, which may include requirements

specifications, system design document,

detailed design, code and test plan.



32/56


Main Menu 32 of 56

Testing Principles

Software testing verifies that the software

meets the requirements.

It involves the operation of a system orapplication under controlled conditions

and evaluating the results.



33/56


Main Menu 33 of 56

Reasons for software errors

Miscommunication or no communication

Software complexity

Programming errors

Changing requirements

Time pressures

Egos

Poorly documented code

Software development tools



34/56


Main Menu 34 of 56

Testing

The goal of a testing methodology is to reduce apotentially infinite exhaustive testing process to afinite testing process.

A subset of the domain used in a testing process iscalled a test data set.

The most crucial part of the testing problem isfinding an adequate test data set that covers the

domain but is small enough to use. This activity must be planned and carried out in

each life cycle stage.



35/56


Main Menu 35 of 56

Criteria for the selection of test data

The test data should reflect special properties of

the domain such as extremal or singularities.

The test data should reflect special properties of

the function that the program is supposed toimplement such as domain values leading to

extremal function values.

The test data should exercise the program in a

specific manner e.g. causing all branches to be

executed or all statements to be executed.



36/56


Main Menu 36 of 56

Testing Principles

Testing should be done in accordance with plans

and procedures.

Generate test data at all stages, in particular

earlier stages of the lifecycle.

Develop a means for calculating the expected

values for test data to compare with test results.

Be systematic in the approach to testing Test pieces then aggregate.

Save, organize and annotate test runs.



37/56


Main Menu 37 of 56

Testing Principles

Test cases must be written for invalid and

unexpected as well as valid and expected input

conditions.

Concentrate testing on modules that exhibit themost errors and on their interfaces.

Retest when modifications are made.

Discover and use available tools for testing. Resolution of all non-conformances should take

place prior to delivery.



38/56


Main Menu 38 of 56

Testing techniques

Black box tests White box tests

Boundary Value analysis Statement coverage

Equivalence partitioning Decision coverage

Cause effect graphing Condition coverage

Error guessing Decision/Condition coverage

Multiple condition coverage



39/56


Main Menu 39 of 56

Unit Testing

This is the testing at the simplest level, to

test particular functions or code modules.

Typically done by the programmer and not

the testers, as it requires detailed

knowledge of the internal program or

design.


40/56



41/56


Main Menu 41 of 56

Incremental Integration Testing

It conducts the testing on small segments,

where errors are easier to isolate and

correct instead of testing the entire

program as a whole.

It involves the continuous testing of an

application as new functionality is added.

Two incremental testing strategies are top-

down and bottom-up testing.



42/56


Main Menu 42 of 56

Functional testing

It provides final assurance that the

software meets all functional and

behavioral requirements.



43/56

f g g g

Main Menu 43 of 56

System testing

It verifies that all elements of the whole

computer system (hardware, people,

databases, software etc) mesh properly and

that the overall system function and

performance is achieved.



44/56

f g g g

Main Menu 44 of 56

Acceptance testing

Itis the final testing based on specifications

of the end user or customer, or based on

use by end users over some limited time

period.

It is sometimes performed with realistic

data of the client to demonstrate that the

software is working satisfactorily.



45/56

f g g g

Main Menu 45 of 56

Regression testing

It is performed when some changes are

made to the existing system.

All portions of the program affected by the

modifications must be re-tested.



46/56

f g g g

Main Menu 46 of 56

Test Completion Criteria

Stop when scheduled time for testing

expires.

Stop when all test cases execute without

detecting errors.

However, if you have run your complete

test set and found no errors, it does not

necessarily follow that the program is error

free.



47/56

f g g g

Main Menu 47 of 56

Test Completion Criteria

Using statistical modeling and dynamic

analysis tools, the test coverage can be

measured and failures as a function of

execution time can be developed.

Also the number of errors to be detected

can be roughly estimated to determine the

required testing time.



48/56

f g g g

Main Menu 48 of 56

Ways in testability to be built into a design

Paths

Loops

Logic-based Syntax

Interfaces

Integration Specifications



49/56

f g g g

Main Menu 49 of 56

Engineering Approach to Software Development

The initial engineering approaches to

system development were called system

development methodologies (SDM).

It broke the development into component

parts and then described how to do those

parts in a systematic manner.



50/56

Main Menu 50 of 56

CASE Technology

CASE is an acronym that stands for

Computer Aided Software Engineering.

It is a tool which aids a software engineer

to maintain and develop software, much

like a mechanic who uses the aid of his

tools to maintain / develop vehicles.



51/56

Main Menu 51 of 56

Effective installation of CASE technology

Standardize the environment

Automate an individual component of a

process

Integrate the various CASE tools



52/56

Main Menu 52 of 56

Benefits of CASE tools

Speeds up the developmental process.

Reduces cost, especially maintenance.

Improves software quality. Encourages an interactive and workstation

environment.

Repeatable precision. Increased productivity.



53/56

Main Menu 53 of 56

Analysis Model

The analysis model primarily aims at

Describing what the customer wants

Establishing a basis for the creation of software

Clearly define the requirements, to be validated

once software is built



54/56

Main Menu 54 of 56

Analysis Model

Data Dictionary

State-Transition

Diagram

DFDERD

Data Object Description Process Specification

Control Specification

Fig. 1.5 Structure of the Analysis Model



55/56

Main Menu 55 of 56

Summary

Stages in SDLC

Requirements

Design

Construction

Operation and Maintenance

Software System Lifecycle models

Waterfall

V model Prototyping

Incremental

Spiral



56/56

Summary

Verification and validation provides themanagement foundation for assessing the truth abouta systems performance in support of decisionmaking process.

There are two types of testing techniques: Black BoxTests and White Box tests.

Testing is planned and conducted at various stages

of life cycle. CASE is a tool that helps s/w engineer to maintain

and develop s/w.

Documents

Chap 3 - Software Engineering and Testing