Software Testing - R.S. Pressman & Associates, Inc

SOFTWARE TESTING

SONALI CHAUHANSYBSC IT

UDIT

Software Engineering: A Practitioner's Approach-R.S. Pressman & Associates, Inc.

Software Testing Sonali C. 2

INTRODUCTION It is critical element of s/w quality

assurance. S/w must be tested to uncover as

many as errors before delivery to customer.

This is where s/w testing technique comes into picture.


Technique provides systematic guidance for designing test: Exercise internal logic of software components Exercise the i/p, o/p domain of program to

uncover errors in program function, behavior and performance

S/w is tested in 2 perspective: Internal logic of software components is

exercise “WHITEBOX” test case technique S/w requirement are exercised using

“BLACKBOX” test case technique

CONT…


In both the cases, the intend is to find maximum number of error with minimum amount of effort and time.

CONT…


WHO TEST THE SOFTWARE???

Understands the system, but will test “gently” and, is driven by “delivery”

Must learn about system but, will attempt to break it and, is driven by quality

independent testerindependent testerdeveloperdeveloper


TESTIBILITY FEATURE OPERABILITY OBSERVABILITY CONTROLABILITY DECOMPOSABILITY SIMPLICITY STABILITY UNDERSTANDABILITY


TESTING OBJECTIVE Testing is a process of executing a program

with the intent of finding an error. A good test case is one which has high

probability to find an as-yet-undiscovered error.

A successful test is one that uncovers as-yet-undiscovered errors.

Our objective is to design test that systematically uncover different classes of errors and to do so in minimum amount of time and efforts.

If testing is conducted successfully it will uncover errors in s/w.


PRINCIPLE OF TESTING Testability

All tests should be traceable to customer requirement.

Planning Tests should be planed long before

testing begins. Execution

Should begin in small and progress towards in the large.


Pareto The pareto principle: implies that 80%

of all the errors uncovered during testing will likely be traceable to 20% of all programs components

Exhaustive testing Exhaustive testing is not possible

Moderation To be more effective testing should be

conducted by a independent third party.

CONT…


TEST CASE DESIGN Designing a test is difficult Recalling, test should be find max

error in min efforts n time


Whitebox testing: Knowing the internal working of the

product, tests can be conducted to ensure that “all gears mesh”, i.e,internal operation are adequately exercised.

Blackbox testing Knowing the specified function that a

product has been designed to performed, tests can be conducted that demonstrate each function

CONT…


WHITEBOX TESTING Close examination of procedural details. Goal is to ensure that all the conditions

and statements are been executed at least once in loop.

It is also known as ‘‘GLASS BOX TESTING’’


Software engineers can drive test cases that: guarantee that all independent paths are within

a module have been exercised at least once. Exercise all logical decision on their true and

false sides Execute all loops at their boundaries and within

their operational bound Exercise internal data structures to ensure their

validity

CONT…


WHY WHITEBOX TESTING? logic errors and incorrect

assumptions are inversely proportional to a path's execution probability.

we often believe that a logical path is not likely to be executed; in fact, it may be executed on a regular basis.

Typographical errors are random; it's likely that untested paths will contain some


I.BASIC PATH TESTING Basic path testing is white box

testing It enables the test case design to

derive a logical complexity basic of procedural design

It contains following types Flow graph notation Cyclomatic complexity Deriving test case

CONT…


1.Flow Graph Notation It depicts the logical control flow of

program


2.CYCLOMATIC COMPLEXITY Determines no of region of flow chart

corresponds to CYCLOMATIC COMPLEXITY

Cyclomatic complexity V(G)=E-N+2 E = no of flow graph edges N = number of flow graph nodes

V(G) = P+1 P=no of predicate node


3.DERIVING TES CASE Draw flow chart Determine CC Determine a basis set of linear

independent path Prepare test cases which will execute

each path in basic set.


II. GRAPH MATRICES A graph matrix is a square matrix whose size

(i.e., number of rows and columns) is equal to the number of nodes on a flow graph

Each row and column corresponds to an identified node, and matrix entries correspond to connections (an edge) between nodes.

By adding a link weight to each matrix entry, the graph matrix can become a powerful tool for evaluating program control structure during testing


III. CONTROL STRUCTURE TESTING

Condition testing — a test case design method that exercises the logical conditions contained in a program module

Data flow testing — selects test paths of a program according to the locations of definitions and uses of variables in the program


IV. LOOP TESTING

Nested Nested LoopsLoops

ConcatenatedConcatenated Loops Loops Unstructured Unstructured

LoopsLoops

Simple Simple looploop


LOOP TESTING:SIMPLE LOOPS Minimum conditions—Simple LoopsMinimum conditions—Simple Loops

skip the loop entirelyskip the loop entirely only one pass through the looponly one pass through the loop two passes through the looptwo passes through the loop m passes through the loop m < nm passes through the loop m < n (n-1), n, and (n+1) passes through the (n-1), n, and (n+1) passes through the

looploop where n is the maximum number of where n is the maximum number of

allowable passesallowable passes


LOOP TESTING:NESTED LOOPS Nested Loop:

Start at the innermost loop. Set all outer Start at the innermost loop. Set all outer loops to their minimum iteration loops to their minimum iteration parameter values.parameter values.

Test the min+1, typical, max-1 and max Test the min+1, typical, max-1 and max for the innermost loop, while holding the for the innermost loop, while holding the outer loops at their minimum values.outer loops at their minimum values.

Move out one loop and set it up as in step Move out one loop and set it up as in step 2, holding all other loops at typical 2, holding all other loops at typical values. Continue this step until the values. Continue this step until the outermost loop has been testedoutermost loop has been tested..


Concatenated Loops If the loops are independent of one

another then treat each as a

simple loop else* treat as nested loops

endif*


BLACK BOX TESTING Also called as Behavioral Testing Focuses on the functional

requirements of S/W It is complimentary to whitebox

testing that uncovers errors


Black-Box attempts to fin errors in following categories: Incorrect or missing function Interface errors Errors in data structures or external

data base access Behavior or performance errors Initialization and termination error

CONT…


Black Box are designed to answer: How is functional validity tested? How is system behavior and performance

tested? What classes of input will make good test cases? Is the system particularly sensitive to certain

input values? How are the boundaries of a data class isolated? What data rates and data volume can the system

tolerate? What effect will specific combinations of data

have on system operation?

CONT…


To understand the objects that are To understand the objects that are modeled in software and the modeled in software and the relationships that connect these relationships that connect these objectsobjects

Software testing begins by creating Software testing begins by creating graph of object and relation among graph of object and relation among them to uncover errors.them to uncover errors.

Graph is collection of nodes,links.Graph is collection of nodes,links.

CONT…

GRAPH BASE TESTING METHOD


CONT…

newfile

menu select generates

(generation time 1.0 sec)document

window

documenttex

t

is represented as

contains

Attributes:

background color: whitetext color: default color

or preferences

(b)

object#1

Directed link

(link weight)object

#2

object#3

Undirected link

Parallel links

Node weight(value

)

(a)

allows editingof


EQUIVALENCE PARTITIONING Focuses on the test case for input condition

If as input condition specifies a range, 1-valid and 2-invalid equivalence class are define

If as input condition specifies a value, 1-valid and 2-invalid equivalence class are define

If as input condition specifies a number of a set, 1-valid and 1-invalid equivalence class are define

If input condition is Boolean ,1 valid and one invalid class are define


BOUNDARY VALUE ANALYSIS

It selects test case at the edges of the class

it focuses on input as well as output domain

Guidelines for BVA are:


If the input condition specified a range bounded by values a and b, test case should be just above a and just below b.

If the input condition specified a number of values, test case should be maximum and minimum

Apply guideline 1 and 2 for output domain

If internal program data structure have prescribed boundaries, design test case for data structure as its boundaries

CONT…


COMPARISON TESTING Used only in situations in which the

reliability of software is absolutely critical (e.g., human-rated systems) Separate software engineering teams develop

independent versions of an application using the same specification

Each version can be tested with the same test data to ensure that all provide identical output

Then all versions are executed in parallel with real-time comparison of results to ensure consistency


ORTHOGANAL ARRAY TESTING Used when the number of input

parameters is small and the values that each of the parameters may take are clearly bounded


TESTING STRATEGY We begin by ‘We begin by ‘testing-in-the-smalltesting-in-the-small’’ and move and move

toward ‘toward ‘testing-in-the-largetesting-in-the-large’’ For conventional softwareFor conventional software

The module (component) is our initial focusThe module (component) is our initial focus Integration of modules followsIntegration of modules follows

For OO softwareFor OO software our focus when “testing in the small” changes our focus when “testing in the small” changes

from an individual module (the conventional from an individual module (the conventional view) to an OO class that encompasses view) to an OO class that encompasses attributes and operations and implies attributes and operations and implies communication and collaborationcommunication and collaboration


TESTING STRATEGY

unit testunit test integrationintegrationtesttest

validationvalidationtesttest

systemsystemtesttest

CONT…


VALIDATION AND VERIFICATION

Software testing is one type of a broader domain that is known as verification and validation (V&V).

Verification related to a set of operations that the software correctly implements a particular function.

Validation related to a different set of activities that ensures that the software that has been produced is traceable to customer needs.


UNIT TESTING

modulemoduleto beto betestedtested

test casestest cases

resultsresults

softwaresoftwareengineerengineer


UNIT TESTINGCONT…

Unit testing concentrates verification on the smallest element of the program.

Control paths are tested to uncover errors within the boundary of module.

Is whitebox oriented.


UNIT TESTINGCONT…

……

MODULE……

……

MODULE……

Interface

Local Data Structure

Boundary Condition

Independent Paths

Error Handling Paths

Interface


Boundary Condition

Independent Paths


TEST CASESTEST CASES


UNIT TESTINGCONT…

Module interface is tested to ensure that information properly flows into and out of the program unit being tested.

Local data structure is tested to ensure that data stored temporarily maintains its integrity for all stages in an algorithm’s execution.

Boundary conditions are tested to ensure that the modules perform correctly at boundaries created to limit or restrict processing.

All independent paths through the control structure are exercised to ensure that all statements in been executed once.

Finally, all error-handling paths are examined.


UNIT TESTING-EnvironmentCONT…

Driver

Modules

Stubs Stubs

Result

Interface


Boundary Condition

Independent Paths


Interface


Boundary Condition

Independent Paths


TEST CASESTEST CASES


UNIT TESTING-ProcedureCONT…

Once source code has been produced, reviewed, and verified for correct syntax, unit test case design can start.

As a module is not a stand-alone program, driver and/stub software must be produced for each test units.

Drivers are nothing more than “main program” that accepts test case, passes such information to the component (to be tested), and print relevant results.

Stubs is “dummy subprogram” uses subordinate module interface ,may do minimal data manipulation, print verification of entry and returns controls to the modules undergoing testing. Stubs replaces modules.


INTEGRATION TESTING Once all the modules has been unit tested,

Integration testing is performed. Next problem is Interfacing Data may lost across interface, one module may

not have an adverse impact on another and a function is may not performed correctly when combined.

IT is systematic testing. Produce tests to identify errors associated with

interfacing.


INTEGRATION TESTING The “big bang” approach. An entire program is tested as a whole

creates a problem. An incremental construction strategy

CONT…


INTEGRATION TESTING-Top Down Testing

Top-down integration is an incremental approach.

Modules are integrated by moving downwards through the control hierarchy, starting with the main control module.

Modules subordinate to the main control module are included into the structure in either a depth-first or breadth-first manner.

CONT…



For instance in depth-first integration, selecting the left-hand path, modules M1, M2, M5 would be integrated first.

Next M8 or M6 would be integrated. Then the central and right-hand control paths are

produced. Breath-first integration includes all modules directly

subordinate at each level, moving across the structure horizontally.

From the figure modules M2, M3 and M4 would be integrated first.

The next control level, M5, M6 etc., follows.

CONT…



CONT…

M1

M7 M8

M9

M6M5

M3 M4M2

Top module is tested with stub

stubs are replaced stubs are replaced one at a time, one at a time, "depth first""depth first"

as new modules are integrated, as new modules are integrated, some subset of tests is re-runsome subset of tests is re-run



The integration process is performed in a series of five stages:

The main control module is used as a test driver and stubs are substituted for all modules directly subordinate to the main control module.

Depending on the integration technique chosen, subordinate stubs are replaced one at a time with actual modules.

Tests are conducted as each module is integrated. On the completion of each group of tests, another stub

is replaced with the real module. Regression testing may be performed to ensure that

new errors have been introduced.

CONT…



Problem on Top Down Processing at low levels in the hierarchy is

required to test upper level Solution Delay test until stubs are replaced with actual

module Difficult to determine cause of errors

Develop stubs that perform limited functions to simulate actual module

Overhead, as stubs become more compels. Integrate software from bottom of the hierarchy

CONT…


INTEGRATION TESTING-Bottom Up Testing

CONT…

Begins testing with the modules at the lowest level (atomic modules).

As modules are integrated bottom up, processing required for modules subordinates to a given level is always available and the need for stubs is eliminated.



CONT…

A bottom-up integration strategy may be implemented with the following steps:

Low-level modules are combined into clusters that perform a particular software subfunction.

A driver is written to coordinate test cases input and output.

The cluster is tested. Drivers are removed and clusters are combined

moving upward in the program structure.



CONT…


REGRESSION TESTING Any time changes are made at any level, all

previous testing must be considered invalid can do regression testing at unit, integration,

and system level this means tests must be re-run to ensure the

software still passes re-running previous tests is regression

testing particularly problematic for user interface

software


SMOKE TESTING A common approach for creating “daily builds”

for product software. Smoke testing steps:


SMOKE TESTING Software components that have been translated into

code are integrated into a “build.” A build includes all data files, libraries, reusable

modules, and engineered components that are required to implement one or more product functions.

A series of tests is designed to expose errors that will keep the build from properly performing its function. The intent should be to uncover “show stopper”

errors that have the highest likelihood of throwing the software project behind schedule.

The build is integrated with other builds and the entire product (in its current form) is smoke tested daily. The integration approach may be top down or bottom

up.


VALIDATION TESTING Software is completely assembled as a

package, interfacing errors have been identified and corrected, and a final set of software tests validation testing are started.

Validation can be defined in various ways, but a basic one is valid succeeds when the software functions in a fashion that can reasonably expected by the customer.


VALIDATION TESTING Validation Test Criteria Configuration review Alpha and Beta testing

CONT…


SYSTEM TESTING System testing is a series of different tests

whose main aim is to fully exercise the computer-based system

Although each test has a different role, all work should verify that all system elements have been properly integrated and form allocated functions.

Below we consider various system tests for computer-based systems.


SYSTEM TESTING Recovery Testing

Recovery testing is a system test that forces the software to fail in various ways and verifies the recovery is performed correctly.

Security Testing Security testing tries to verify that protection

approaches built into a system will protect it from improper penetration.

Stress Testing Stress testing executes a system in the

demands resources in abnormal quantity

CONT…


Example of Stress testing most systems have requirements for performance

under load, e.g., 100 hits per second 500 ambulances dispatched per day all data processed using 70% processor capacity

while operating in flight mode with all sensors live systems with load requirements must be tested

under load simulated load scenarios must be designed and

supported frequently requires significant test code and

equipment to adequately support


PERFORMANCE TESTING Test the runtime performance of the s/w

within he context of integrated system.

Thank YouAny Doubt, question, query????

Documents

Software Testing - R.S. Pressman & Associates, Inc