model based software testing preliminaries l.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Model Based Software Testing Preliminaries PowerPoint Presentation
Download Presentation
Model Based Software Testing Preliminaries

Loading in 2 Seconds...

play fullscreen
1 / 91

Model Based Software Testing Preliminaries - PowerPoint PPT Presentation


  • 195 Views
  • Uploaded on

Model Based Software Testing Preliminaries. Aditya P. Mathur Purdue University Fall 2005. Last update: August 18, 2005. Learning Objectives: This course. Methods for test generation. Methods for test assessment. The coverage principle and the saturation effect. Software test process.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

Model Based Software Testing Preliminaries


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
model based software testing preliminaries

Model Based Software TestingPreliminaries

Aditya P. Mathur

Purdue University

Fall 2005

Last update: August 18, 2005

learning objectives this course
Learning Objectives: This course
  • Methods for test generation
  • Methods for test assessment
  • The coverage principle and the saturation effect
  • Software test process
  • Tools:
  • AETG: Test generation
  • xSUDS: Test assessment , enhancement, minimization, debugging
  • CodeTest: Test assessment, performance monitoring
  • VisualTest: GUI testing
  • Test RealTime: Test assessment, performance monitoring
  • Ballista: Robustness testing

Software Testing and Reliability Aditya P. Mathur 2003

learning objectives
Learning Objectives
  • What is model-based testing? How does it differ from (formal) verification?
  • How and why does testing improve our confidence in program correctness?
  • What is coverage and what role does it play in testing?
  • What are the different types of testing?
  • What are the formalisms for specification and design used as source for test and oracle generation?

Software Testing and Reliability Aditya P. Mathur 2003

testing preliminaries
Testing: Preliminaries
  • What is testing?
  • The act of checking if a part or a product performs as expected.
  • Why test?
  • Gain confidence in the correctness of a part or a product.
  • Check if there are any errors in a part or a product.

Software Testing and Reliability Aditya P. Mathur 2003

what to test
What to test?
  • During software lifecycle several products are generated.
  • Examples:
  • Requirements document
  • Design document
  • Software subsystems
  • Software system

Software Testing and Reliability Aditya P. Mathur 2003

test all
Test all!
  • Each of these products needs testing.
  • Methods for testing various products are different.
  • Examples:
  • Test a requirements document using scenario construction and simulation.
  • Test a design document using simulation.
  • Test a subsystem using functional testing.

Software Testing and Reliability Aditya P. Mathur 2003

what is our focus
What is our focus?
  • We focus on testing programs using formal models.
  • Programs may be subsystems or complete systems.
  • These are written in a formal programming language.
  • There is a large collection of techniques and tools to test programs.

Software Testing and Reliability Aditya P. Mathur 2003

an abstraction of the mbt process

Source of Tests

Develop/Add Tests

Test

adequate?

Run Tests

Debug and remove

defects

No

Yes

Proceed to the next step

An Abstraction of the MBT Process

Raw requirements

Formal specifications

Tests

Finite State Machines

Behavior

State Charts

Sequence Diagrams

Code, etc.

Modified document

Software Testing and Reliability Aditya P. Mathur 2003

a few terms
A Few Terms
  • Program:
  • A collection of functions, as in C, or a collection of classes as in java.
  • Specification:
  • Description of requirements for a program. This might be formal or informal.

Software Testing and Reliability Aditya P. Mathur 2003

few terms contd
Few Terms (contd.)
  • A set of values of input variables of a program. Values of environment variables are also included.
  • Test case or test input
  • Test set
  • Set of test inputs
  • Program execution
  • Execution of a program on a test input.

Software Testing and Reliability Aditya P. Mathur 2003

few terms contd11
Few Terms (contd.)
  • Oracle
    • A function that determines whether or not the results of executing a program under test is as per the program’s specifications.
  • Verification
    • Human examination of a product, such as design document, code, user manual, etc., to check for correctness. Inspections an walkthroughs are the generally used methods for verification.
  • Validation
    • The process of evaluating a system or a subsystem to determine whether or not it satisfies the specified requirements.

Software Testing and Reliability Aditya P. Mathur 2003

correctness
Correctness
  • Let P be a program (say, an integer sort program).
  • Let S denote the specification for P.
  • For sort let S be:

Software Testing and Reliability Aditya P. Mathur 2003

sample specification
Sample Specification
  • Let K denote any element of this sequence,
  • P takes as input an integer N>0 and a sequence of N integers called elements of the sequence.
  • P sorts the input sequence in descending order and prints the sorted sequence.

Software Testing and Reliability Aditya P. Mathur 2003

correctness again
Correctness again
  • P is considered correct with respect to a specification S if and only if:
  • For each valid input the output of P is in accordance with the specification S.

Software Testing and Reliability Aditya P. Mathur 2003

errors defects faults
Errors, defects, faults
  • Error: A mistake made by a programmer

Example: Misunderstood the requirements.

  • Defect/fault: Manifestation of an error in a program.

Example:

Incorrect code: if (a<b) {foo(a,b);}

Correct code: if (a>b) {foo(a,b);}

Software Testing and Reliability Aditya P. Mathur 2003

failure
Failure
  • Incorrect program behavior due to a fault in the program.
  • Failure can be determined only with respect to a set of requirement specifications.
  • A necessary condition for a failure to occur is that execution of the program force the erroneous portion of the program to be executed. What is the sufficiency condition?

Software Testing and Reliability Aditya P. Mathur 2003

errors and failure

Error-revealing

inputs cause

failure

Program

Erroneous

outputs indicate

failure

Errors and failure

Inputs

Outputs

Software Testing and Reliability Aditya P. Mathur 2003

debugging
Debugging
  • Suppose that a failure is detected during the testing of P.
  • The process of finding and removing the cause of this failure is known as debugging.
  • The word bug is slang for fault.
  • Testing usually leads to debugging
  • Testing and debugging usually happen in a cycle.

Software Testing and Reliability Aditya P. Mathur 2003

test debug cycle

Test

Failure?

Yes

No

Testing

complete?

Debug

Yes

No

Done!

Test-debug Cycle

Software Testing and Reliability Aditya P. Mathur 2003

testing and code inspection
Testing and Code Inspection
  • Code inspection is a technique whereby the source code is inspected for possible errors.
  • Code inspection is generally considered complementary to testing. Neither is more important than the other.
  • One is not likely to replace testing by code inspection or by verification.

Software Testing and Reliability Aditya P. Mathur 2003

testing for correctness
Testing for correctness?
  • Identify the input domain of P.
  • Execute P against each element of the input domain.
  • For each execution of P, check if P generates the correct output as per its specification S.

Software Testing and Reliability Aditya P. Mathur 2003

what is an input domain
What is an input domain ?
  • Input domain of a program P is the set of all validinputs that P can expect.
  • The size of an input domain is the number of elements in it.
  • An input domain could be finite or infinite.
  • Finite input domains might be very large!

Software Testing and Reliability Aditya P. Mathur 2003

identifying the input domain
Identifying the input domain
  • For the sortprogram:

N: size of the sequence, K: each element of the sequence.

  • Example: For N<3, e=3, some sequences in the input domain are:

[ ]: An empty sequence (N=0).

[0]: A sequence of size 1 (N=1)

[2 1]: A sequence of size 2 (N=2).

Software Testing and Reliability Aditya P. Mathur 2003

size of an input domain
Size of an input domain
  • Suppose that
  • The size of the input domain is the number of all sequences of size 0, 1, 2, and so on.
  • The size can be computed as:

Can you derive this formula?

Software Testing and Reliability Aditya P. Mathur 2003

testing for correctness sorry
Testing for correctness? Sorry!
  • To test for correctness P needs to be executed on all inputs.
  • For our example, it will take an exorbitant amount of time to execute the sort program on all inputs on the most powerful computers of today!

Software Testing and Reliability Aditya P. Mathur 2003

exhaustive testing
Exhaustive Testing
  • This form of testing is also known as exhaustive testing as we execute P on all elements of the input domain.
  • For most programs exhaustive testing is not feasible.
  • What is the alternative?

Software Testing and Reliability Aditya P. Mathur 2003

formal verification
Formal Verification
  • Formal verification (for correctness) is different from testing for correctness.
  • There are techniques for formal verification of programs that we do not plan to discuss.

Software Testing and Reliability Aditya P. Mathur 2003

partition testing
Partition Testing
  • In this form of testing the input domain is partitioned into a finite number of sub-domains.
  • P is then executed on a few elements of each sub-domain.
  • Let us return to the sort program.

Software Testing and Reliability Aditya P. Mathur 2003

sub domains

1

9

3

Sub-domains
  • Suppose that 0<=N<=2 and e=3. The size of the partitions is:
  • We can divide the input domain into three sub-domains as shown.

Software Testing and Reliability Aditya P. Mathur 2003

fewer test inputs
Fewer test inputs
  • Now sort can be tested on one element selected from each domain.
  • For example, one set of three inputs is:

[ ] Empty sequence from sub-domain 1.

[2] Sequence from sub-domain 2.

[2 0] Sequence from sub-domain 3.

  • We have thus reduced the number of inputs used for testing from 13 to 3!

Software Testing and Reliability Aditya P. Mathur 2003

confidence
Confidence
  • Confidence is a measure of one’s belief in the correctness of the program.
  • Correctness is often not measured in binary terms: a correct or an incorrect program.
  • Instead, it is measured as the probability of correct operation of a program when used in various scenarios.

Software Testing and Reliability Aditya P. Mathur 2003

measures of confidence
Measures of Confidence
  • Reliability: Probability that a program will function correctly in a given environment over a certain number of executions.
  • Test completeness: The extent to which a program has been tested and errors found have been removed.

Software Testing and Reliability Aditya P. Mathur 2003

example increase in confidence
Example: Increase in Confidence
  • We consider a non-programming example to illustrate what is meant by “increase in confidence.”
  • Example: A rectangular field has been prepared to certain specifications.
  • One item in the specifications is:

“There should be no stones remaining in the field.”

Software Testing and Reliability Aditya P. Mathur 2003

rectangular field

W

Y

0

L

X

Rectangular Field

Search for stones inside a rectangular field.

Software Testing and Reliability Aditya P. Mathur 2003

testing the rectangular field
Testing the Rectangular Field
  • The field has been prepared and our task is to test it to make sure that it has no stones.
  • How should we organize our search?

Software Testing and Reliability Aditya P. Mathur 2003

partitioning the field
Partitioning the field
  • We divide the entire field into smaller search rectangles.
  • The length and breadth of each search rectangle is one half the expected length and breadth of the smallest stone one expects to find in the field.

Software Testing and Reliability Aditya P. Mathur 2003

partitioning into search rectangles

Stone

8

Width

7

Another Stone

6

5

Y

4

3

A tiny stone

2

1

1

2

3

4

5

6

7

Two stones inside

one rectangle

Length

X

Partitioning into search rectangles

Software Testing and Reliability Aditya P. Mathur 2003

input domain
Input Domain
  • Input domain is the set of all possible valid inputs to the search process.
  • In our example this is the set of all points in the field. Thus, the input domain is infinite!
  • To reduce the size of the input domain we partition the field into finite size rectangles.

Software Testing and Reliability Aditya P. Mathur 2003

rectangle size
Rectangle size
  • The length and breadth of each search rectangle is one half that of the smallest stone.
  • This is an attempt to ensure that each stone covers at least one rectangle. (Is this always true?)

Software Testing and Reliability Aditya P. Mathur 2003

constraints
Constraints
  • Testing must be completed in less than H hours.
  • Any stone found during testing is removed.
  • Upon completion of testing the probability of finding a stone must be less than p.

Software Testing and Reliability Aditya P. Mathur 2003

number of search rectangles
Number of search rectangles
  • Let

L: Length of the field

W: Width of the field

l: Expected length of the smallest stone

w: Expected width of the smallest stone

  • Size of each rectangle: l/2 x w/2
  • Number of search rectangles (R)=(L/l)*(W/w)*4
  • Assume that L/l and W/w are integers.

Software Testing and Reliability Aditya P. Mathur 2003

time to test
Time to Test
  • Let tbe the time to peek inside one search rectangle. No rectangle is examined more than once.
  • Let o be the overhead incurred in moving from one search rectangle to another.
  • Total time to search T=R*t+(R-1)*o
  • Testing with R rectangles is feasible only if T<H.

Software Testing and Reliability Aditya P. Mathur 2003

partitioning the input domain
Partitioning the input domain
  • This set consists of all search rectangles (R).
  • Number of partitions of the input domain is finite (=R).
  • However, if T>H then the number of partitions is too large and scanning each rectangle once is infeasible.
  • What should we do in such a situation?

Software Testing and Reliability Aditya P. Mathur 2003

option 1 do a limited search
Option 1: Do a limited search
  • Of the R search rectangles we examine only r whereris such that (t*r+o*(r-1)) < H.
  • This limited search will satisfy the time constraint.
  • Will it satisfy the probabilityconstraint?

Question:

What do the probability and time constraints correspond to in a commercial test ?

Software Testing and Reliability Aditya P. Mathur 2003

distribution of stones
Distribution of Stones
  • To satisfy the probability constraint we must scan enough search rectangles so that the probability of finding a stone, after testing, remains less than p.
  • Let us assume that
  • there are Si stones remaining after i test cycles.

Software Testing and Reliability Aditya P. Mathur 2003

distribution of stones46
Distribution of Stones
  • There are Risearch rectangles remaining after itest cycles.
  • Stones are distributed uniformlyover the field.
  • An estimate of the probability of finding a stone in a randomly selected remaining search rectangle is pi = si / Ri .

Software Testing and Reliability Aditya P. Mathur 2003

probability constraint
Probability Constraint
  • We will stop looking into rectangles if

pi <= p

  • Can we really apply this test method in practice?

Software Testing and Reliability Aditya P. Mathur 2003

confidence48
Confidence
  • Number of stones in the field is not known in advance.
  • Hence we cannot compute the probability of finding a stone after a certain number of rectangles have been examined.
  • The best we can do is to scan as many rectangles as we can and remove the stones found.

Software Testing and Reliability Aditya P. Mathur 2003

coverage
Coverage
  • Suppose that r rectangles have been scanned from a total of R. Then we say that the (rectangle) coverage isr/R.
  • After a rectangle has been scanned for a stone and any stone found has been removed, we say that the rectangle has been covered.

Software Testing and Reliability Aditya P. Mathur 2003

coverage and confidence
Coverage and Confidence
  • What happens when coverage increases?

As coverage increases (and stones found are removed) so does our confidence in a “stone-free” field.

  • In this example, when the coverage reaches 100%, (almost) all stones have been found and removed. Can you think of situations when this might not be true?

Software Testing and Reliability Aditya P. Mathur 2003

option 2 reduce number of partitions
Option 2: Reduce number of partitions
  • If the number of rectangles to scan is too large, we can increase the size of a rectangle. This reduces the number of rectangles.
  • Increasing the size of a rectangle also implies that there might be more than one stone within a rectangle.

Is this good for a tester?

Software Testing and Reliability Aditya P. Mathur 2003

rectangle size52
Rectangle Size
  • As a stone may now be smaller than a rectangle, detecting a stone inside a rectangle is not guaranteed.
  • Despite this fact our confidence in a “stone-free” field increases with coverage.
  • However, when the coverage reaches 100% we cannot guarantee a “stone-free” field.

Software Testing and Reliability Aditya P. Mathur 2003

coverage vs confidence

Does not imply that the field

is “stone-free”.

1

Confidence

0

Coverage

1(=100%)

Coverage vs. Confidence

Software Testing and Reliability Aditya P. Mathur 2003

rectangle size again

t, p

small

large

Rectangle size

Rectangle Size (again!)

p=Probability of detecting a stone inside a rectangle, given that the stone is there.

t=time to complete a test.

Software Testing and Reliability Aditya P. Mathur 2003

analogy
Analogy

Field: Program

Stone: Error

Scan a rectangle: Test program on one input

Remove stone: Remove error

Partition: Subset of input domain

Size of stone: Size of an error

Rectangle size: Size of a partition

Software Testing and Reliability Aditya P. Mathur 2003

analogy contd

Inputs that

cause failure

due to Error 1

Inputs that cause

failure due to

Error 2.

Input domain

Analogy (contd.)

Size of an error is the number of inputs in the input domain each of which will cause a failure due to that error.

Error 1 is larger

than Error 2.

Does this imply that failures due to error 1 will occur more frequently than those due to error 2?

Software Testing and Reliability Aditya P. Mathur 2003

confidence and probability
Confidence and Probability
  • It might not increase the probability that the field is “stone-free”.
  • Increase in coverage increases our confidence in a “stone-free” field.
  • Important:Increase in confidence is NOT justified if detected stones are not guaranteed to be removed !

Software Testing and Reliability Aditya P. Mathur 2003

types of testing

Source of clues for

test input construction

Object under test

All of these methods can be

applied here.

Types of Testing

Basis for

classification

Software Testing and Reliability Aditya P. Mathur 2003

testing based on source of test inputs
Testing: Based on Source of Test Inputs
  • Functional testing/specification testing/black-box testing/conformance testing:
    • Clues for test input generation come from requirements.
  • White-box testing/coverage testing/code-based testing
    • Clues come from program text.

Software Testing and Reliability Aditya P. Mathur 2003

testing based on source of test inputs60
Testing: Based on Source of Test Inputs
  • Stress testing
    • Clues come from “load” requirements. For example, a telephone system must be able to handle 1000 calls over any 1-minute interval. What happens when the system is loaded or overloaded?

Software Testing and Reliability Aditya P. Mathur 2003

testing based on source of test inputs61
Testing: Based on Source of Test Inputs
  • Performance testing
    • Clues come from performance requirements. For example, each call must be processed in less than 5 seconds. Does the system process each call in less than 5 seconds.
  • Fault- or error- based testing
    • Clues come from the faults that are injected into the program text or are hypothesized to be in the program.

Software Testing and Reliability Aditya P. Mathur 2003

testing based on source of test inputs62
Testing: Based on Source of Test Inputs
  • Random testing
  • Clues come from requirements. Test are generated randomly using these clues.
  • Robustness is the degree to which a software component functions correctly in the presence of exceptional inputs or stressful environmental conditions.
  • Robustness testing
  • Clues come from requirements. The goal is to test a program under scenarios not stipulated in the requirements.

Software Testing and Reliability Aditya P. Mathur 2003

testing based on source of test inputs63
Testing: Based on Source of Test Inputs
  • OO testing
    • Clues come from the requirements and the design of an OO-program.
  • Protocol testing
    • Clues come from the specification of a protocol. As, for example, when testing for a communication protocol.

Software Testing and Reliability Aditya P. Mathur 2003

testing based on item under test
Testing: Based on Item Under Test
  • Unit testing

Testing of a program unit. A unitis the smallest testable piece of a program. One or more units form a subsystem.

  • Subsystem testing
    • Testing of a subsystem. A subsystem is a collection of units that cooperate to provide a part of system functionality

Software Testing and Reliability Aditya P. Mathur 2003

testing based on item under test65
Testing: Based on Item Under Test
  • Integration testing
    • Testing of subsystems that are being integrated to form a larger subsystem or a complete system.
  • System testing
    • Testing of a complete system.

Software Testing and Reliability Aditya P. Mathur 2003

testing based on item under test66
Testing: Based on Item Under Test
  • Regression testing
  • Test a subsystem or a system on a subset of the set of existing test inputs to check if it continues to function correctly after changes have been made to an older version.

And the list goes on and on!

Software Testing and Reliability Aditya P. Mathur 2003

test input construction and objects under test
Test input construction and objects under test

Requirements

Source of clues for

test inputs

Code

subsystem

unit

system

Test object

Software Testing and Reliability Aditya P. Mathur 2003

combinatorial design

Parameters:

Sample inputs:

Combinatorial Design
  • Context: A telephone switch
  • Problem: Determine what inputs to use to test the switch.

Total parameters: 4

Values for each parameter: 3

Total number of scenarios: 34=81

Software Testing and Reliability Aditya P. Mathur 2003

reducing the input space
Reducing the Input Space
  • Suppose that 81 test is too many for the telephone switch under test.
  • An alternative is to select a default value for each parameter and then vary each parameter until all values are covered.

Software Testing and Reliability Aditya P. Mathur 2003

test plan with default parameter values
Test Plan with Default Parameter Values

Total inputs: 9

Coverage: 30 of the 54 pair wise interactions.

Software Testing and Reliability Aditya P. Mathur 2003

another test plan
Another Test Plan

Total inputs: 9

Coverage: All pair wise interactions covered

Software Testing and Reliability Aditya P. Mathur 2003

combinatorial explosion
Combinatorial Explosion
  • What if the program under test had 10 parameters each with 3 values?
  • Total parameter combinations= 310
  • Number of tests using the default value method= ?
  • Number of pair-wise combinations covered = ?
  • Number of pair-wise combinations = ?

Software Testing and Reliability Aditya P. Mathur 2003

answers to questions
Answers to Questions

For k parameters each with n possible values:

Tests with default value method=n+ (n-1) x (k-1)

Pair-wise combinations=(k x (k-1)/2) x n2

Pair-wise combinations covered=(k-1)+n*(k-1)+(n-1)*(k-1)*(k-1)

Later we shall discuss how to handle the combinatorial explosion.

Software Testing and Reliability Aditya P. Mathur 2003

finite state machines fsms
Finite State Machines (FSMs)
  • A state machine is an abstract representation of actions taken by a program or anything else that functions!
  • It is specified as a quintuple:
      • A: a finite input alphabet
      • Q: a finite set of states
      • q0: initial state which is a member of Q.

Software Testing and Reliability Aditya P. Mathur 2003

fsms contd
FSMs (contd.)
  • T: state transitions which is a mapping

Q x A--> Q

  • F: A finite set of final states, F is a subset of Q.
  • Example: Here is a finite state machine that recognizes integers ending with a carriage return character.
  • A={0,1,2,3,4,5,6,7,8,9, CR}
  • Q={q0,q1,q2}
  • q0: initial state

Software Testing and Reliability Aditya P. Mathur 2003

fsms contd76
FSMs (contd.)
  • T: {((q0,d),q1),(q1,d),q1), (q1,CR),q2)}
  • F: {q2}
  • A state diagram is an easier to understand specification of a state machine. For the above machine, the state diagram appears on the next slide.

Software Testing and Reliability Aditya P. Mathur 2003

state diagram

State transitions indicated

by labeled arrows from one state

the another (which could be

the same). Each label must be from

the alphabet. It is also known as

an event.

d

CR

d

Final state indicated

by concentric circles.

q2

q0

q1

States indicated by

circles.

State diagram

d: denotes a digit

Software Testing and Reliability Aditya P. Mathur 2003

state diagram actions

d/add 10*d to i

d/set i to d

CR/output i

q2

q0

q1

State Diagram-Actions

x/y: x is an element of

the alphabet and y is

an action.

i is initialized to d when the machine moves from state q0 to q1.

i is incremented by 10*d when the machine moves from q1 to q1.

The current value of i is output when a CR is encountered.

Can you describe what this machine computes?Can you

construct a regular expression that describes all strings

recognized by this state machine?

Software Testing and Reliability Aditya P. Mathur 2003

state machine languages
State Machine: Languages
  • Each state machine recognizes a language.
  • The language recognized by a state machine is the set S of all strings such that:
    • when any string s in S is input to the state machine the machine goes through a sequence of transitions and ends up in the final state after having scanned all elements of s.

Testing state machines? Later!

Software Testing and Reliability Aditya P. Mathur 2003

the unified modeling language
The Unified Modeling Language
  • Unified Modeling Language (UML) is a notation to express requirements and designs of software systems.
  • Requirements are represented using:
  • a collection of use cases, each use case being a representative of a collection of scenarios.
  • a collection of system sequence diagrams that explain the interaction between a user and the application for each use case.

Software Testing and Reliability Aditya P. Mathur 2003

uml design representation
UML: Design Representation
  • Design of an application is represented in UML by a collection of diagrams of the following types (not an exhaustive list):
  • Class diagrams capture the relationships amongst classes.
  • Sequence (or collaboration) diagrams depict the sequence of actions initiated due to an external event. This sequence is depicted in terms of messages sent from one object to another.
  • Statecharts depict the relationship amongst various states of an object.

Software Testing and Reliability Aditya P. Mathur 2003

use case diagram partial

ECG Monitor

Remote Display

Physician

Display

waveforms

Capture

waveform

<<uses>>

Process

alarms

Service Personnel

Calibrate

sensors

Use Case Diagram (partial)

Software Testing and Reliability Aditya P. Mathur 2003

a sequence diagram partial

Passenger 1

Passenger 2

Elevator

Controller

Request UP elevator

Request floor 8

Light UP indicator

Request DN elevator

Queue request

Light DN indicator

Door opens

Light floor button

A Sequence Diagram (partial)

Passenger 1 is on floor 6 and 2 on floor 2.

Door closes, E moves, passes floor 2.

Arrives at floor 6.

One sequence diagram for each use case.

Software Testing and Reliability Aditya P. Mathur 2003

what else can one indicate on a sequence diagram
What else can one indicate on a sequence diagram?
  • Broadcast messages sent by one object and received by more than one.
  • Timing marks to show timing constraints m between two events.
  • Event identifiers can be attached to an event; an ID can be referenced in other parts of the diagram.
  • State marks are placed on the object timing line to indicate state changes for that object.

Software Testing and Reliability Aditya P. Mathur 2003

a state diagram

Message Ready/Trans-count=0

Idle

Transmitting

Done/Start-timer

Trans-count++

ACK

Invalid ACK

[else]/inform sender of failure

Waiting

tm (wait-time)

[Trans-count<=limit]

A State Diagram

Behavior of a Message Transaction Object

Software Testing and Reliability Aditya P. Mathur 2003

uml state charts
UML State Charts
  • Similar to state diagrams.
  • States can be nested within states. Inner states are known as substates.
  • History connector allows the specification of default initial state in a super state.

Software Testing and Reliability Aditya P. Mathur 2003

uml state charts87

S1

entry: f1()

entry: g1()

T1

S2

Y1

do: f2()

do: g2()

SS1

SS2

exit: f3()

exit: g3()

T2

T5

Y2

T4/C1 C2

[G1]

H

[G1]

S3

X1

P

Q

R

T3

History connector: SS2 is the default initial state in the absence of history, else the last active state is the default.

X3

X2

UML State Charts

Each state may have entry and exit actions as well as activities.

Entry (exit) actions are executed in the (reverse) order of nesting.

Software Testing and Reliability Aditya P. Mathur 2003

transitions in uml statecharts
Transitions in UML Statecharts

event name (parameters) [guard] / action list^ event list

  • event name: name of the event triggering the transition
  • parameters: List of parameters passed with the event signal.
  • guard: Boolean expression that must evaluate to true for the transition to take place.
  • action list: List of actions to be executed when the transition is taken.
  • event list: List of events generated, and propagated to other state machines, when the transition is taken.

Software Testing and Reliability Aditya P. Mathur 2003

summary
Summary
  • Testing and debugging
  • Specification
  • Correctness versus confidence
  • Input domain
  • Exhaustive testing and combinatorial explosion
  • UML artifacts: Use cases, FSM, State Charts, Sequence diagrams

Software Testing and Reliability Aditya P. Mathur 2003

slide90

Summary: Terms

  • Reliability
  • Coverage
  • Error, defect, fault, failure
  • Debugging, test-debug cycle
  • Types of testing, basis for classification

Software Testing and Reliability Aditya P. Mathur 2003

summary questions
Summary: Questions
  • What is the effect of reducing the partition size on probability of finding errors?
  • How does coverage effect our confidence in program correctness?
  • Does 100% coverage imply that a program is fault-free?
  • What decides the type of testing?

Software Testing and Reliability Aditya P. Mathur 2003