0% found this document useful (0 votes)
5 views

Lesson 3.1 - Unit Testing Basics

Uploaded by

vinhnqda180069
Copyright
© © All Rights Reserved
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
5 views

Lesson 3.1 - Unit Testing Basics

Uploaded by

vinhnqda180069
Copyright
© © All Rights Reserved
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
You are on page 1/ 28

Unit Testing Basics

Code: N/A
Authors: HaiPT1
Course: <Course-Name>
Conductor: <Acc> –
<Unit>

© FPT SOFTWARE – TRAINING MATERIAL 1 04e-BM/DT/HDCV/FSOFT v2.2


Introduction

Agenda(90 minutes)
 Unit Test - What and Who?
 Unit Test - Why?
 Unit Test - How? (method, technique)
 Unit Test - Practice (3-5 labs) + Answer

Purpose: Practical Guide to Software Unit


Testing

© FPT SOFTWARE – TRAINING MATERIAL 2 04e-BM/DT/HDCV/FSOFT v2.2


Objectives

The course helps attendees understand:


 Unit Test Fundamentals: Answer the question of what,
why, when and how to do unit test
 Unit Test Technique: Introduce approaches and techniques
to do unit test

© FPT SOFTWARE – TRAINING MATERIAL 3 04e-BM/DT/HDCV/FSOFT v2.2


Unit Test – What and Who ?

 Unit Testing Actions:


• Validate that individual units of software program are
working properly
• A unit is the smallest testable part of an application (In
procedural programming a unit may be an individual
program, function, procedure, etc., while in object-oriented
programming, the smallest unit is always a method)
• Units are distinguished from modules in that modules are
typically made up of units

 Unit Testing Deliverables:


• Tested software units
• Related documents (Unit Test case, Unit Test Report)

 Unit Testing Conductor: Development team

© FPT SOFTWARE – TRAINING MATERIAL 4 04e-BM/DT/HDCV/FSOFT v2.2


Unit Test – Why ?

 Ensure quality of software unit


 Detect defects and issues early
 Reduce the Quality Effort & Correction Cost

© FPT SOFTWARE – TRAINING MATERIAL 5 04e-BM/DT/HDCV/FSOFT v2.2


Cost of bugs

$14,000

85% % Defects
Percentage of Bugs

Introduced in
this phase

% Defects
found in
in this phase
$1000
$ Cost to

$25 $130 $250 repair defect


in this phase

Coding Unit Funct Field Post


Test Test Test Release
Source: Applied Software
Measurement,
Capers Jones, 1996

© FPT SOFTWARE – TRAINING MATERIAL 6 04e-BM/DT/HDCV/FSOFT v2.2


Unit Test – When ?

 After Coding
 Before Integration Test

© FPT SOFTWARE – TRAINING MATERIAL 7 04e-BM/DT/HDCV/FSOFT v2.2


Unit Test – How ?(1) Methodologies

 UT processes
 Follow the UT process defined in FSOFT UT Guidelines

© FPT SOFTWARE – TRAINING MATERIAL 8 04e-BM/DT/HDCV/FSOFT v2.2


Unit Test – How ?(2) Methodologies

 Black-box testing
 Functional testing: ensure each unit acts right as its design
 Business testing: ensure the software program acts right as
user requirement

© FPT SOFTWARE – TRAINING MATERIAL 9 04e-BM/DT/HDCV/FSOFT v2.2


Unit Test – How ?(3) Methodologies

 White-box testing
 Developer does himself
• Check syntax of code by compiler to avoid syntax errors
• Run code in debug mode, line by line, through all independent paths of
program to ensure that all statement of codes has been executed at least
one time
• Examine local data structure to ensure that data stored temporarily
maintains its integrity during all all steps of code execution
• Check boundary conditions to ensure that code will run properly at the
boundaries established as requirements
• Review all error handling paths
 Apply WB Test techniques
• See next slides

© FPT SOFTWARE – TRAINING MATERIAL 10 04e-BM/DT/HDCV/FSOFT v2.2


Unit Test – How ? Techniques

 Black box test (Functional)


 Specification derived tests
 Equivalence partitioning
 Boundary value analysis
 White box (Structural)
 Statement coverage
 Decision (branch) coverage
 Path coverage

© FPT SOFTWARE – TRAINING MATERIAL 11 04e-BM/DT/HDCV/FSOFT v2.2


Black box test – Specification derived test

 You can choose all or some statements in the


specification of software
 Create test cases for each statements of
specification
 Execute test cases to check test result will output
as the specification

© FPT SOFTWARE – TRAINING MATERIAL 12 04e-BM/DT/HDCV/FSOFT v2.2


Example Specification

 Input - real number


 Output - real number

 When given an input of 0 or greater, the positive


square root of the input shall be returned.
 When given an input of less than 0, the error
message "Square root error - illegal negative input"
shall be displayed and a value of 0 returned.

© FPT SOFTWARE – TRAINING MATERIAL 13 04e-BM/DT/HDCV/FSOFT v2.2


Example Test Cases

 Test Case 1: Input 4, Return 2


• Use the first statement in the specification
• ("When given an input of 0 or greater, the positive square root of the
input shall be returned.").

 Test Case 2: Input -10, Return 0, Output "Square root error - illegal negative
input“
• Use the second and third statements in the specification
• ("When given an input of less than 0, the error message "Square root
error - illegal negative input" shall be displayed and a value of 0
returned.”).

© FPT SOFTWARE – TRAINING MATERIAL 14 04e-BM/DT/HDCV/FSOFT v2.2


Black box test: Equivalence
partitioning

 Divide the input of a program into classes of data from which test
cases can be derived. This might help you to reduce number of test
cases that must be developed.
 Behavior of software is equivalent for any value within particular
partition
 A limited number of representative test cases should be chosen from
each partition

Invalid inputs

Outputs
System
Valid inputs

© FPT SOFTWARE – TRAINING MATERIAL 15 04e-BM/DT/HDCV/FSOFT v2.2


Example Test Cases

Input partitions Output partitions

1 >= 0 a >= 0

2 <0 b Error

 Test Case 1: Input 4, Return 2


• Use the >=0 input partition (1)
• Use the >=0 output partition (a)

 Test Case 2: Input -10, Return 0, Output "Square root error - illegal negative input“
• Use the < 0 input partition (2)
• Use the “Error” output partition (b)

© FPT SOFTWARE – TRAINING MATERIAL 16 04e-BM/DT/HDCV/FSOFT v2.2


Black box test: Boundary value
analysis

 It is similar to equivalence partitioning, is a


selection of test cases, test input that check
bounding values
 Anticipate that errors are most likely to exist at the
boundaries between partitions
 Test the software at either side of boundary values

© FPT SOFTWARE – TRAINING MATERIAL 17 04e-BM/DT/HDCV/FSOFT v2.2


Example Test Cases

Input partitions Output partitions

1 >= 0 a >= 0

2 <0 b Error

Input
Partitions (1) (2)
- 0 +

1 2 3 4 5
Boundaries and test cases

© FPT SOFTWARE – TRAINING MATERIAL 18 04e-BM/DT/HDCV/FSOFT v2.2


White box test : Node
Example:
buy(dress, bag) {
A if dress already in bag
A
B display “already bought it”
else B C
C if bag is full
D display “bag is full” D E
else

E
buy dress F
display “buy successful”
F end if
G end if G
}

© FPT SOFTWARE – TRAINING MATERIAL 19 19


04e-BM/DT/HDCV/FSOFT v2.2
White box test: Statement
coverage
Total Nodes = 7;
A

C Test case ABG covers 3 = 43%


B
+
D E Test case ACDFG

F Now covers 6/7 = 86%


Need 1 more for 100%
statement coverage – ACEFG
G

© FPT SOFTWARE – TRAINING MATERIAL 20 04e-BM/DT/HDCV/FSOFT v2.2


White box test: Decision (branch)
coverage

A What branch coverage is


achieved by ABG, ACDFG,
B C ACEFG?

D E
4 in total.
F

4 covered
G

So 4/4 = 100% branch


coverage
© FPT SOFTWARE – TRAINING MATERIAL 21 04e-BM/DT/HDCV/FSOFT v2.2
White box test: Path coverage

A What path coverage is


achieved by ABG, ACDFG,
B C ACEFG?

D E
3 in total.
F

3 covered
G

So 3/3 = 100% path coverage

© FPT SOFTWARE – TRAINING MATERIAL 22 04e-BM/DT/HDCV/FSOFT v2.2


Example: White box test case

 Test cases covering ABDEG and ACDFG


cover 4/4 branches (100%) and 7/7
statements (100%)

 They, however, only cover 2/4 paths


(50%).

 2 more tests are required to achieve


100% path coverage
 ABDFG
 ACDEG

© FPT SOFTWARE – TRAINING MATERIAL 23 04e-BM/DT/HDCV/FSOFT v2.2


White box test: Comparison

© FPT SOFTWARE – TRAINING MATERIAL 24 04e-BM/DT/HDCV/FSOFT v2.2


Practice 1

public bool ValidPassword(string password)


{
bool validPassword = false;
// Check valid password length
if(IsValidLength(password, minLength, maxLength))
{
validPassword = true;
// Check valid password mix between lowcase and upcase
if(!IsMixedCase(password))
return false;
// Check valid password mix between alpha & numeric
if(!IsAphaNumeric(password))
return false;
}
return validPassword;
}

How many unit test cases you must do to check this


function?

© FPT SOFTWARE – TRAINING MATERIAL 25 04e-BM/DT/HDCV/FSOFT v2.2


result

6: There are 4 cases:


1. Test (ValidPasswordLength)
2.Test (ValidPasswordAlphaNumeric)
3.Test (ValidPasswordMixedCase)
4.Test với điều kiện đúng của 3
trường hợp trên
(ValidPasswordLengthAlphaNumericMixe
dCase)

© FPT SOFTWARE – TRAINING MATERIAL 26 04e-BM/DT/HDCV/FSOFT v2.2


Discussion

 You find bugs while coding, is it unit test activity?


Why?
 Which cases we apply Black-box and White-box
testing?
 What are the result if we do not perform Unit test?
 As your opinion, What is the most difficult in Unit
test activity?
 What are the products of Unit test activity?
 (Good question from student)

© FPT SOFTWARE – TRAINING MATERIAL 27 04e-BM/DT/HDCV/FSOFT v2.2


Q&A

© FPT SOFTWARE – TRAINING MATERIAL 28 04e-BM/DT/HDCV/FSOFT v2.2

You might also like