Use Case Testing Bin Ma – u4446201 Ji Zhang - ANU

jetmorebrisketΛογισμικό & κατασκευή λογ/κού

15 Αυγ 2012 (πριν από 5 χρόνια και 2 μήνες)

225 εμφανίσεις

USE CASE TESTING



BIN
MA


U4446201


JI

ZHANG


U2580936

LAVANYA



U4441325


USE CASE REQUIREMENTS


Definition of use case


A use case is a sequence of actions performed by a system, which combined
produce a result of value to a system user.



Use

cases

are

a

type

of

process

flow

model,

so

they

are

similar

in

concept

(and

in

how

to

test

them),

to

classic

flow

models

like

data

flow

diagrams

and

cause
-
effect

graphs
.



Use cases capture requirements in a readable,
refutable format.



Relationship between use cases and
requirements

REQUIREMENT REVIEW PROCESS



Identify alternative course in RRP


Brainstorming, Checklist, Fault tree, Functional and non
-

functional requirement



Participants


stakeholders drawn from different backgrounds


domain expert and an end
-
user


Project Manager, Analyst, System Designer, Programmer, End
User

DEVELOPING METHOD FROM USE CASE TO TEST CASE


The test case(s) verifies that the system does
in fact perform this function as expected
which described by the use case


Path
-
Based Test Cases


Input
-
Based (Domain) Test Cases


Boundary Value Test Cases


Feature Interaction Test Cases

Automation tools


Requirement management tools:


CaliberRM Borland


IBM Rational RequisitePro IBM


DOORS Telelogic


Automatically generate test case:


NetBeans 3.6, Eclipse Java IDE


Visual Test IBM


Test::LectroTest Perl

From: http://www.ibm.com/developerworks/rational/library/04/r
-
3217/

Finding scenarios in a use case

NON
-
FUNCTIONAL REQUIREMENTS


Typical non
-
functional requirements:


Performance, Scalability, Capacity, Availability, Reliability, etc.


Cover non
-
functional requirements in use
case testing:


Add the non
-
functional requirements to the use case
document.


Identify the use case specify

PRO AND CON OF USE CASE TESTING


Advantages:


focus attention on the user, rather than on the actions the
system performs.


incorporated with OOA/D methodologies and widely accepted.


a systematic approach to developing the information
necessary for test design.


Disadvantages:


no agreement on appropriate methodology.


not typically used to specify performance, fault
-
tolerance, etc.