Loading presentation...

Present Remotely

Send the link below via email or IM

Copy

Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.

DeleteCancel

Make your likes visible on Facebook?

Connect your Facebook account to Prezi and let your likes appear on your timeline.
You can change this under Settings & Account at any time.

No, thanks

Lesson #7: Test Case Design

No description
by

Richard Shy

on 18 February 2014

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of Lesson #7: Test Case Design

What is a Test Case?
a
set of conditions or variables
under which a tester will determine whether an application or software system is working correctly.

describes an
input
,
action or event
and an
expected response
, to determine if a feature of an application is working correctly.

White Box Test Design Techniques
Control Flow
Data Flow
Integration Testing
Black Box Test Design Techniques
from Use Case
Equivalence Class Partitioning
Boundary Value Analysis
Decision Tables
Orthogonal Arrays and All Pairs
Objectives
Understand what a test case is;
Enumerate reasons why test cases are written;
Write your own test cases;
Understand and use Black Box and White Box Test Design Techniques
Parts of a Test Case
Test Case ID
Description
Expected Results
Test Data
Status
Actual Result
Remarks / Comments
Test Case Design
Why do we write Test Cases?
Documentation
Validation and Verification
Learning
Test Case ID
must be a unique identifier
establish a convention on generating IDs
examples:
TC-001
LM001
Description / Scenario
concise description of the test case
example:
Login with invalid username
Successfully save an Employee Record
Expected Result
expected behavior of the system
example:
Error Message: Please enter a valid username
Employee Record is saved, saved record is displayed; Success message: Employee record has been successfully saved
Test Data
a set of values; one for each input variable
Status
Pass or Fail
helpful if color-coded for easy reference
Actual Result
The actual behavior of the system after execution
Remarks / Comments
notes or comments that you may want to add for reference
Steps in analyzing Use Cases
1. Identify the ff:
Success Path
Alternative Path/s
Exception Path/s
Other validations
2. Identify expected results for each path
ex. Success Path --> Post-condition
3. Write a test case for
each
path identified
Equivalence Class Partitioning
a software testing technique that divides the input data of a software unit into partitions of equivalent data from which test cases can be derived

in principle, test cases are designed to cover each partition at least once

Why use this method?

to
reduce the total number
of test cases to a finite and testable set that still covers maximum requirements

consider an input box that accepts the number 1 to 1000, are we going to write 1000++ test cases just to cover valid and invalid scenarios? <--
Exhaustive Testing
Equivalence Class Partitioning
Example:

Test cases for input box accepting numbers 1 to 1000 ECP

All Valid Inputs: pick a single value from 1 to 1000
All values below lower limit (Invalid)
All values above upper limit (Invalid)

Boundary Value Analysis
technique in which tests are designed to include representatives of boundary values

test cases are selected at the edges of equivalence classes

more applications errors occur at the boundaries of input domain
Boundary Value Analysis
Example:

Test cases for input box accepting numbers 1 to 1000 using BVA

Boundaries of input domain:
1
and
1000
Values just below extreme edges of input domain:
0
and
999
Values just above extreme edges of input domain:
2
and
1001
Decision Tables
shows a table containing different combination inputs and their associated outputs

also known as cause-effect table

useful for cases in testing a business rule that involves different combinations of inputs resulting in different outputs
Decision Tables
Steps in creating a decision table:

List all conditions and actions down the left side
Each row should contain different possible values for a single variable
Each column represents a different combination of input values with their respective expected results
Decision Tables
Example #3:
Inputs:
LeBron James
Rajon Rondo
Andre Drummond
Chris Paul
Dwight Howard
Andre Iguodala
Outputs:
East/West
Position (G, F, C)
All-Star or not
Orthogonal Arrays
a systematic and statistical way of testing

used when the number of inputs are relatively small, but too large for exhaustive testing

effective in detecting region faults using a small number of tests
All Pairs
also known as Pairwise Testing

a combinatorial method of testing

for each pair of input parameters to a system, this method tests all possible discrete combinations of those parameters
Control Flow Testing
refers to the order in which the individual statements, instructions, or function calls of an imperative or declarative program are executed or evaluated.

Kinds of Control Flows
:

Unconditional Branch
or
Jump
--> continuation at a different statement
Conditional Branch
--> executing a set of statements only if some condition is met via a choice
Loop
--> executing a set of statements zero or more times until some condition is met
Sub-routines, Co-routines,
and
Continuations
--> executing a set of distant statements, after which the flow of control usually returns
Unconditional Halt
--> stopping the program, preventing any further execution
Control Flow Testing
Fundamental Path Selection criteria:

ensure every instruction in the routine has been exercised at least once
every decision (branch or case statement) has been taken in each possible direction at least once
a sufficient number of paths to achieve coverage
select short, functionally sensible paths
minimize the number of changes from path to path -- preferably only one direction changing at a time
favor more but simpler paths over fewer yet complicated paths
Data Flow Testing
Employs the concept of
Set-Use Pairs
or
Def-Use (DU) Pairs
associates a point in a program where a value is produced with a point where it is used
to test data flows, you need to cover all set-use pairs


Identify the pair of lines where:

the item is first assigned a value (SET)
the item’s value is used (USE)

Example #2:
Full transcript