UNIT TESTING

Agenda
Introduction
What is unit testing?
Test types
Static testing
White box testing
Tool support

Introduction
Who am I?
►ISTQB certified
►Software testing and
development
►More than 2 years working
experience in automotive
area

Introduction
What is a unit?
►software component that contains
one or more routines
►also known as module, component
►all variables and functions from a
module may respect a naming
convention
Software system architecture

Introduction
►A module encapsulates code and data to implement a particular functionality.
MODULE FUNCTIONALITY

Introduction
► All modules together form the
software system.
► The modules communicate
with each other to fulfill the
system requirements.

► also known as unit, module or program
testing
► searches for defects in, and verifies the
functioning of, software modules, programs,
objects, classes, etc., that are separately
testable.

• lowest level of testing
• tested in isolation
• most through look at detail
• tests are written and run by software
developers

Test cases are derived from work products such as:
• specification of the component,
• software design,
• data model.

Software development process V-Model
When is unit
testing performed?

When is unit testing performed?

Unit testing vs Traditional testing
Traditional Testing
• Test the system as a whole
• Individual components rarely tested
• Errors go undetected
• Source of errors difficult to track down

Unit testing vs Traditional testing
Unit Testing
• Each part tested individually
• All components tested at least once
• Errors picked up earlier
• Scope is smaller, easier to fix errors

Benefits
• Unit testing allows the programmer to refactor code at a
later date, and make sure the module still works correctly.
• By testing the parts of a software application first and then
testing the sum of its parts, integration testing becomes
much easier.
• Unit testing provides a sort of living documentation of the
system.

Test types
A test type is focused on a particular test objective,
which could be any of the following:
►A function to be performed by the software
►A non-functional quality characteristic,
►The structure or architecture of the software,
►Change related.
Component testing include all above.

Functional testing
►is the testing of “what” the system does
►based on functions and features (described in documents or understood
by the testers) and their interoperability
►considers the external behavior of the software (black-box testing)

Functional testing
► security testing:
investigates the functions relating to detection of
threats, such as viruses, from malicious outsiders
► interoperability testing:
evaluates the capability of the software product
to interact with one or more specified
components or systems

Non-functional testing
►is the testing of “how” the system works
►describes the tests required to measure characteristics of systems and
software that can be quantified on a varying scale
►considers the external behavior of the software (black-box testing)
► resource-behavior
e.g. searching for memory leaks
► robustness testing

Structural testing
►based on the structure of code: statement, branch
►measure the thoroughness of testing through assessment of coverage of a
type of structure
►coverage is the extent that a structure has been exercised by a test suite,
expressed as a percentage of the items being covered
►statement coverage
►decision coverage

Testing related to changes
► performed:
- after a defect is detected and fixed,
- when the software, or its environment, is changed.
Regression test suites are strong candidate for automation.
Impact analysis: determine decide how much regression testing
to do

► Confirmation testing - confirming that defects have been fixed
BUG FIXED
NEW BUG
NEW BUG
NEW BUG
Re-test
to check

► Regression testing - looking for unintended changes
BUG FIXED
NEW BUG
NEW BUG
NEW BUG
Run
regression
Can’t guarantee
to find them all

Static techniques
Static testing techniques rely on the:
► manual examination (reviews)
► automated analysis (static analysis) of the
code or other project documentation
without the execution of the code

Static analysis by tools
►analyze program code (control flow and data
flow), as well as generated output such as
HTML and XML
►early detection of defects prior to test
execution
►identification of defects not easily found by
dynamic testing

Static analysis
►Techniques:
Control flow analysis Data flow analysis
Compliance to standards Calculation of code metrics

Static analysis
Typical defects discovered by static analysis:
 Referencing a variable with an undefined value,
 Variables that are never used,
 Unreachable (dead) code,
 Programming standards violations,
 Security vulnerabilities.

Static analysis
Identify the faults:

White box testing
White Box VS Black Box
Structure-based
techniques
Specification-based
techniques

White box testing
►software testing method in which the internal
structure/design/implementation of the item being tested is known to
the tester
►testing based on an analysis of the internal structure of the component
or system.
►known as clear box testing, glass box testing, transparent box testing
and structural testing
►mainly applied to unit testing

White box testing
White box concepts

White box testing
8 statements branch
branch
condition
decision
Identify the following: statements, decision, condition, branches.

White box testing techniques
►Statement testing
►Decision/branch testing
►Condition testing
►Multiple condition testing
►Condition determination testing
►Loop testing(LCSAJ)
►Path testing

1 test is necessary to achieve 100%
statement coverage
Statement testing
Statement coverage is the assessment of the
percentage of executable statements that have been
exercised by a test case suite.

Example 1 Example 2
TC Input Statement coverage

2 tests are necessary to achieve 100%
branch coverage
Decision/Branch testing
Decision coverage, related to branch testing, is the assessment of
the percentage of decision outcome s (e.g., the True and False
options of an IF statement) that have been exercised by a test case
suite.

Example
TC Input Decision coverage

? ?
3 tests are necessary to achieve 100%
path coverage
Path testing 1 2 3
►Is a technique in which test cases are designed
to ensure that every path has been traversed at
least once.

Example
Read A
Read B
IF A >= 2 THEN
Print A-B
ELSE
Print A+B
ENDIF
IF B < 5 THEN
Print A*B
ELSE
Print B-A
ENDIF
Minimum number of tests to achieve:
• 100% statement coverage:
• 100% branch coverage:
• 100% path coverage:
2
2
4

►Is a technique in which test cases are
designed to execute combinations of
single condition outcomes.
►It requires 𝟐 𝐧
test cases, where n is
the number of conditions, to get 100%
coverage.
2 tests are necessary to achieve 100% multiple
condition coverage
Multiple condition testing

Example
If we take the example for above:
We need 8 test cases to get 100% multiple condition coverage.
The test cases we need are:

What is a STUB?
• code that simulates the functionality of the
missing components
void functionX()
{
if(boMissingFunction())
/*do something*/
else
/*do something*/
}
....
/*STUB*/
void boMissingFunction()
{
return True;
} Copyright © 2017 Crisan Marius Catalin

void CarAlarms()
{
uint8 u8Val=0xFF;
u8Val=CheckDoors();
switch(u8Val):
{
case 0: printf(“Front door open!”); break;
case 1: printf(“Rear door open”); break;
case 2: printf(“Trunk is open!”); break;
case 3: printf(“Hood is open!”); break;
default: /*do nothing*/ break;
}
}
TESTED FUNCTION: CarAlarm()
STUB: CheckDoors()

void CarAlarms()
{
/*…*/
u8Val=CheckDoors();
/*…*/
}
bool CheckDoors()
{
return True;
}
TESTED FUNCTION: CarAlarm()
STUB: CheckDoors()

What is a DRIVER?
• software component that takes control of
the calling of a function
/*DRIVER*/
void functionThatCallsFunctionX()
{
functionX(100);
}
....
void functionX(uint8 u8Number)
{
/*do something*/
}

car
void Engine(bool boIgnition, bool boActualState)
{
if(boActualState == NOT_RUNNING)
if(boIgnition == True)
{
StartEngine();
boActualState = RUNNING;
}
else /*error 1*/
else
if(boIgnition == False)
{
StopEngine();
boActualState = NOT_RUNNING;
}
else /*error 2*/
}
TESTED FUNCTION: Engine()
DRIVER: TEST_Engine()

void Engine(bool boIgnition, bool boActualState)
{
/*…*/
}
void TEST_Engine()
{
/*…*/
boIgnition = TRUE;
boActualState = NOT_RUNNING;
Engine(boIgnition, boActualState);
CHECK(boActualState, RUNNING);
/*…*/
}
TESTED FUNCTION: Engine()
DRIVER: TEST_Engine()

Test case structure
SET INPUTS
---------------------------------------
CALL FUNCTION
---------------------------------------
CHECK OUTPUT VALUES
TEST CASE BODY
A=2;
B=3;
--------------------------------
S=Sum(A,B);
--------------------------------
CHECK(S,5);
void test_Sum()

Test case design approaches:
 Function testing
 Sequence testing
SET INPUTS
---------------------------------------
CALL FUNCTION
---------------------------------------
CHECK OUTPUT VALUES
TEST CASE BODY
SET INPUTS
---------------------------------------
CALL FUNCTION A
CALL FUNCTION B
CALL FUNCTION C
---------------------------------------
CHECK OUTPUT VALUES
TEST CASE BODY

Module specification:
• Module is responsible for the sound volume.
• 3 functions are implemented.
SOUND_ENABLE
SET_VOLUME
SOUND_DISABLE
SOUND
How is the module tested?

Tool support
► Static Analysis Tools
► Modeling Tools
► Test Harness/Unit Test Framework Tools
► Coverage Measurement Tools
► Dynamic Analysis Tools

Guidelines
► Name tests properly and provide test specification
The typical naming convention is test_[what].
e.g.: test_SaveAs(), test_DeleteProperty()
► Keep tests independent
To ensure testing robustness and simplify maintenance,
tests should never rely on other tests nor should they
depend on the ordering in which tests are executed.

Guidelines
►Unit tests should be fully automated and non-interactive
The test suite is normally executed on a regular basis and must
be fully automated to be useful. If the results require manual
inspection the tests are not proper unit tests.
►Measure the tests
Apply coverage analysis to the test runs so that it is possible to
read the exact execution coverage and investigate which parts
of the code is executed and not.

Guidelines
►Provide negative tests
Negative tests intentionally misuse the code and verify robustness and appropriate error
handling.
►Cover boundary cases
Make sure the parameter boundary cases are covered.

Conclusion
With the help of testing it is possible to measure the quality of the software.
The code can be optimized by revealing hidden errors and being able to remove these
possible defects.
Testing reduces the probability of undiscovered defects remaining in the software.

Any questions?

Continuous learning is the minimum requirement for success in any field. - Brian Tracy

References
1.ISTQB Foundation Level Syllabus 2011
http://www.istqb.org/downloads/syllabi/foundation-level-
syllabus.html
2. Foundations of Software Testing - Rex Black, Erik Van Veenendaal,
Dorothy Graham
3. Guide to Advanced Software Testing - Anne Mette Jonassen Hass
4. Advanced Software Testing(Vol. 3) - Rex Black , Jamie L. Mitchell
5. Images: https://pixabay.com/

UNIT TESTING

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to UNIT TESTING

Similar to UNIT TESTING (20)

Recently uploaded

Recently uploaded (20)

UNIT TESTING