This document provides an overview of unit testing. It defines a unit as a software component that contains one or more routines, also known as a module or component. Unit testing is testing individual software modules in isolation from the rest of the system to verify that each module functions as designed. The document discusses different types of unit tests, including functional, non-functional, and structural tests. It also covers white box testing techniques such as statement, branch, condition, and path testing. Finally, it discusses test automation tools that can be used to support unit testing.

1. Copyright © 2018 Crisan Marius Catalin

2. Agenda
Introduction
Definition of a module
Software systems
What is unit testing?
Test types
Static testing
White box testing
Tool support
Copyright © 2018 Crisan Marius Catalin

3. Introduction
Things about me…
►ISTQB certified
►Software testing and
development
►Work experience in
automotive area

4. Introduction
Let’s know each other!
►My name is…
►I work on…
►My favorite mobile app is…
►I know about unit testing…

5. 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

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

7. Module example
MATH
MATH_Addition(int a, int b)
MATH_Subtraction(int a, int b)
MATH_Multiplication(int a, int b)
MATH_Division(int a, int b)
COUNTER
COUNTER_START()
COUNTER_STOP()
COUNTER_RESET()

8. Introduction
What is a system?
►A collection of elements or components
that are organized for a common purpose.
►A set of methods, procedures and routines
created to carry out a specific activity or
solve a problem.

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

10. Software system example
ERP system
M1
M1.1
M1.2
M2
M2.1
M3
M3.1
Mobile app
M1
M1.1 M1.2 M1.3
M2
M2.1
M - Module

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

12. What is unit testing?
• lowest level of testing
• tested in isolation
• most through look at detail
• tests are written and run by software
developers

13. What is unit testing?
Test cases are derived from work
products such as:
• specification of the component,
• software design,
• data model.

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

15. What is unit testing?
When is unit testing performed?

16. What is unit testing?

17. Unit testing vsTraditional testing
TraditionalTesting
• Test the system as a whole
• Individual components rarely tested
• Errors go undetected
• Source of errors difficult to track down

18. Unit testing vsTraditional testing
UnitTesting
• Each part tested individually
• All components tested at least once
• Errors picked up earlier
• Scope is smaller, easier to fix errors

19. 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.

20. Hands on
► Develop your own
module!

21. Hands on
SETUP:
1.Download Code Blocks IDE
and “moduleX” project.
2.Develop your first module.
3.Build and run project.
Source: https://drive.google.com/open?id=1yc4N0ij1y3zY39wjZ1qFeRqRNPnOPnJ4

22. Hands on
► Develop your own
module!

23. Time to remember!
MODULE
SOFTWARE
SYSTEM
UNIT
TESTING
FUNCTIONALITY

24. Test types

25. 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.

26. 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)
Examples:
►interoperability testing
►smoke testing

27. Functional testing
Typically, functional testing involves the following steps:
1.Identify functions that the software is expected to perform.

28. Functional testing
2.Create input data based on the function’s specifications.
3.Determine the output based on the function’s specifications.

29. Functional testing
4.Execute the test case.
5.Compare the actual and expected outputs.

30. Non-functional testing
►is the testing of “how” the system works
►concern about the way a system operates, rather than specific behaviors
of that system
►considers the external behavior of the software (black-box testing)

31. Non-functional testing
Non-functional testing includes:
• load testing
• volume testing
• stress testing
• performance testing
• robustness testing

32. FunctionalVS Non-Functional
5.is performed using the functional
specification provided by the client and verifies
the system against the functional
requirements
7.is executed first
10.ManualTesting or automation
tools can be used
2.Business requirements are the inputs
6.describes what the product does
8.Easy to do Manual Testing
1.checks the Performance, reliability, scalability
and other non-functional aspects of the
software system
3.should be performed after functional testing 9.Using tools will be effective for this testing
11.Performance parameters like
speed, scalability are inputs
4.describes how good the product works
12.Tough to do Manual Testing

33. Structural testing
►is the testing of the structure of the system or component
►the testers are required to have the knowledge of the internal
implementations of the code
Examples:
►statement testing
►decision testing

34. StructuralVS Functional
1.This testing will uncover error occur
during the coding of the program.
3.It is concerned about both the result and the process
6.This testing will uncover error occurred during the
implementation of requirements and design specifications
5.is often referred as white box testing. The knowledge of code is very
much essential
2.It is concerned only about the result but not the
processing
4.is often referred as black box testing, no need to know about the coding
of the program.

35. Testing related to changes
► performed:
- after a defect is detected and fixed,
- when the software, or its environment, is changed.
► Confirmation testing
► Regression testing

36. Testing related to changes
► Confirmation testing - confirming that defects have been fixed
BUG FIXED
NEW BUG
NEW BUG
NEW BUG
Re-test
to check

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

38. Testing related to changes
► Regression testing - looking for unintended changes
Impact analysis is used to
determine decide how much
regression testing to do.
Regression test suites
are strong candidate
for automation.

39. Example
FUNCTIONAL NON FUNCTIONAL STRUCTURAL RELATED TO CHANGES
… … … …

40. Time to remember!
FUNCTIONAL
TESTING
STRUCTURAL
TESTING
NON-FUNCTIONAL
TESTING
TESTING
RELATED TO
CHANGES

41. Static techniques

42. Static techniques
Static testing techniques rely on the:
► manual examination (reviews)
► automated analysis (static analysis) of the
code without the execution of the code

43. Static techniques
The value of static analysis is:
 Early detection of defects prior to test execution
 Early warning about suspicious aspects of the code
or design by the calculation of metrics

44. Static techniques
 Identification of defects not easily
found by dynamic testing
 Prevention of defects, if lessons are
learned in development

45. Static techniques
QAC

46. Static analysis by tools
►The code is not executed.
►The source code we are interested in is the
input data to the tool.
►Tool analyzes program code and generates
an output report such as HTML and XML.
►The report should be analyzed in order to
fix the warnings.

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

48. 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.

49. Static analysis
Identify the faults:

50. Static analysis
Cyclomatic complexity
► software metric (measurement), used to indicate
the complexity of a program
► quantitative measure of the number of linearly
independent paths through a program's source code
► M = E − N + 2
E = the number of edges of the graph
N = the number of nodes of the graph

51. Static analysis
Cyclomatic complexity
►M = E − N + 2
E = the number of edges of the graph
N = the number of nodes of the graph
M= ?

52. Time to remember!
REVIEWS
STATIC
ANALYSIS

53. Let’s remember!
► Module/ Unit
► Software System
► Unit testing
► Types of testing
► Static techniques

54. White box test design techniques

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

56. 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

57. White box testing
White box concepts

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

59. White box testing techniques
►Statement testing
►Decision/branch testing
►Condition testing
►Multiple condition testing
►Path testing

60. White box testing techniques
1 test is necessary to achieve 100%
statement coverage
Statement testing
►is a test design technique which involves execution of
all the statements in the source code.

61. White box testing techniques
Example 1 Example 2
TC Input Statement coverage

62. White box testing techniques
2 tests are necessary to achieve 100%
branch coverage
Decision/Branch testing
►is a test design technique which involves execution of
all decision outcomes in the source code.

63. White box testing techniques
Example
TC Input Decision coverage

64. White box testing techniques
? ?
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.

65. White box testing techniques
Example
TC Input Decision coverage

66. White box testing techniques
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

67. White box testing techniques
►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

68. White box testing techniques
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:

69. White box testing techniques
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()

70. Hands on
Design tests to achieve:
► 100% statement coverage
► 100% branch coverage
► 100% path coverage

71. Hands on
Design tests to achieve:
► 100% statement coverage
► 100% branch coverage
► 100% path coverage

72. White box testing techniques
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;
}

73. White box testing techniques
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()

74. White box testing techniques
void CarAlarms()
{
/*…*/
u8Val=CheckDoors();
/*…*/
}
uint8 TEST_u8Val = 0;
u8Val CheckDoors()
{
return TEST_u8Val;
}
TESTED FUNCTION: CarAlarm()
STUB: CheckDoors()

75. White box testing techniques
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*/
}

76. White box testing techniques
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()

77. White box testing techniques
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()

78. White box testing techniques
Test case design approaches:
 Function testing
 Sequence(functional) 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

79. Let’s remember!
► Static analysis
► White box testing
► Test cases
► Coverage
► Driver, stub

80. White box testing techniques
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?

81. White box testing techniques
CAR software system
F1
F2 F3
F4
SOUND
F - Functionality

82. SOUND
SOUND_Enable()
SOUND_Disable()
SOUND_SetVolume(uint8 u8Volume)
White box testing techniques

83. White box testing techniques

84. Hands on
It’s time to develop
some tests for your
module!

85. Time to remember!
STATEMENT
COVERAGE
BRANCH
COVERAGE
STUB
DRIVER

86. Tool support

87. Tool support
Static Analysis Tools Modeling Tools
Test Harness
Unit Test
Framework Tools
Coverage
Measurement Tools
Dynamic Analysis
Tools

88. Benefits of using tools
► Repetitive work is reduced
e.g.: running regression tests, re-entering the same
test data, and checking against coding standards
► Greater consistency and repeatability
e.g.: tests executed by a tool in the same order with
the same frequency

89. Benefits of using tools
► Objective assessment
e.g.: static measures, coverage
► Ease of access to information about
tests or testing
e.g.: statistics and graphs about test
progress, incident rates and performance

90. Testing with Cantata IDE
►developed by QA Systems
►tool for unit testing, integration testing
and code coverage
►C and C++
►based on Eclipse

91. Industrial use
 The development and verification of functional safety software in many industries is
governed by international regulatory standards.
• Aerospace
• Automotive
• Energy
• Industrial Automation
• Medical Devices
• Railways
Cantata tool may be used in each of these sectors to meet the
verification requirements of the regulatory standard.

92. Testing with Cantata IDE
Cantata

93. Testing with Cantata IDE
• Test framework generation
• Test case generation
• Test execution
• Results diagnostics and report
generation

94. Instrumentation process

95. Testing with Cantata IDE
TEST SCRIPT

96. Testing with Cantata IDE
COVERAGE MEASUREMENT

97. Testing with Cantata IDE
RESULTS CHECKING

98. 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.

99. 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.

100. 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.

101. 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.

102. Any questions?

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

104. References
1. ISTQB Foundation Level Syllabus 2011
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. https://www.qa-systems.com