Unit Testing

KPIT Technologies Ltd.
Confidential Proprietary Information

Distribution Limited
Do Not Copy Without Prior Permission
UNIT TESTING
Document Identifier: UNIT TESTING

AUTOSAR Release Referred: R4.2 Rev1
Document Version: 1.0.0
Date: 25-Jun-2015
Prepared By:
Products Group
KPIT
India
Test Strategy document for Unit, Module and Integration Testing

Document Identifier: ASRKPITBSW421_TestStrategy
Version: 1.0.0, Dated: 17-April-2015
Page: 1 of 23
KPIT Technologies Ltd. Confidential Proprietary Information
1. UNIT TESTING
Unit testing is performed to identify the deviations present in the AUTOSAR BSW modules code
with respect to design. The Unit is the smallest testable part of the software, which is a function
(API). The unit will be tested individually by providing inputs and validating the outputs from that
function. The unit testing activity goes hand by hand with development activity and unit testing will
be performed by developer.
1.1 SCOPE OF UNIT TESTING
1.1.1 SCOPE INCLUSION

 To verify whether code meets the Design.
 Verify 100% statement coverage (C0).
 Verify 100% Path coverage.
 Verify 100% Modified Condition Decision Coverage (MCDC). (C2)
 Higher order coverage (Loops).
 Analysis of equivalence classes
 Analysis of boundary values for global variables, global pointers (Min, Mid, Max). Assumption is
that all the local variables mapped to global variables and detailed Design document should
provide the Engineering value for Global Variable.
 To identify un-executable paths.
 Verification of return type function calls or nested function calls
 Stub details is available, while generating script in RTRT. Here, stub means function
present in other .c files of same module.
 If function call or nested function calls present in the same .c file, RTRT will not provide
any details.
Manual analyzation is required and path of calling function should be covered.
 Typecasting related testing are followed in unit testing but not for void.
1.1.2 SCOPE EXCLUSION

 RTRT does not allow testing of assembly routines.
Overcome: Comment assembly routines while testing (Ex: __asm).
 Compiler directives like #pragma.
Overcome: Comment the particular line while testing.
 _ _inline are not supported by RTRT.

Overcome: Make changes in TDP Editor Path: Testing ->Parser Settings ->Runtime analysis features
for C. Here we need to add #pragma attol accept “inline".
 If RTRT generates a huge executable code, then sometimes it may not be possible to debug due

Page: 2 of 23
to the size limit of the debugger.

Overcome: Execute the test scripts by grouping minimum number of APIs.
 Array out of bound checking are not done in unit testing if it happens it will throw some
Warning (out of range) in unit testing. If warning comes, report generation cannot be done. If the
array index comes in the loop more than once, coverage will not be 100%.
Overcome: Verification has to be done manually.
1.2 INPUTS TO UNIT TESTING
TDP (Target Deployment Port):
 RTRT TDP Qualification Sheet (Contains the information of compiler/compiler

flags,Debugger,Linker/Linker flags and Target).
 TDP has to be selected based on the test environment.
1.3 UNIT TESTING WORK PRODUCTS
 Test cases (UTP)

 Test driver (script) file (PTU)
 Test results file (RTR Tool generated)
 Coverage report (RTRT Tool generated)
 Test Summary Report (RTRT Tool generated)
 Test plan report (UTR)
 TR checklists (UTP & UTR)
1.4 UNIT TESTING PROCEDURE
To test each unit function, a set of input variables are passed on to the testing sub-module and the
result is compared against the expected result after executing the software in a controlled
environment.
Unit test plan approach will be as below:
Stage 1: Create Equivalence sheet & unit test plan with ESDD (HLD+LLD+Flow chart) as inputs.
 Derive the functional test plan for all possible scenarios(path)

Page: 3 of 23
Stage 2: Update the same unit test plan once the source code is available to achieve 100%
coverage (MCDC, statement, path, loops, boundary values, equivalence class)
 Dependency parameter values like global to local variable mapping
 (API inputs), Function calls, Global variable updation, Return value, Stub calls
Unit testing involves the following steps:
Analysis of ESDD ( HLD + LLD + Flow Chart). & Preparation of

Euiqvalance Sheeet
Stage1: Create Unit Test Plan
Verification of ESDD with source code
Generation of configuration (K-SAR EDITOR tool)
Stage2: Update Unit Test Plan, once source code is available
Selection of the TDP (RTRT tool)
Generation of PTU file from the Source code (RTRT tool)
Execute Test scripts & Report generation (RTRT tool)
Unit Test Report Preparation
Technical Review, Screen and Store of UTP and UTR

Page: 4 of 23
2. MODULE TESTING (EMBEDDED)
Module testing is used to verify behaviour of the BSW module against functional requirements from
AUTOSAR <MSN> SRS. Test cases are derived for all the functional requirements for BSW module.
Different test groups shall be created based on the features.
2.1 SCOPE OF MODULE EMBEDDED TESTING
2.1.1 Scope Inclusion

 100% functional requirement coverage (Requirements with category “Requirement on
Module Behaviour”).
 Verification of functionality against Min – Max values for configuration parameters.
(For the max value of configuration parameter, we need to check with the integration teams
for max values/multiplicity, and after the approval from the Architect, the same need to be
used)
 Verification of functionality against for all possible values for Enumeration type and Boolean
type parameters.
 Verification of APIs for DET functionality to identify overflow / underflow.
2.1.2 Scope Exclusions

 Performance testing, memory /timing measurement shall not covered.
2.2 INPUTS FOR MODULE EMBEDDED TESTING
 KPIT AUTOSAR <MSN> SRS

 Embedded source code.
 Module parameter definition file (PDF)
 Module tool generator (Template based generator)
2.3 MODULE TESTING WORK PRODUCTS
 System Test Specification (STS) document.

 Test application
 Test configuration (arxml file)
 Stub code files
 Test report (STR) for x86 platform
 Test report (STR) for porting

Page: 5 of 23
2.4 MODULE EMBEDDED TESTING PROCEDURE
To test each functional requirement (Requirement with category “Requirement on Module

Behaviour”), different test cases are derived. Different test cases shall be grouped based on the
similar functionality and it is termed as Test group. For 100% requirement coverage, different test
groups shall be created and each test group shall have test cases covering similar functionality.
Each test group shall have separate test configuration and Key configuration parameters shall be
identified which can impact the functionality under test. Provide Min – Max values for the key
parameters and create different set of configuration values. Each test case shall refer one of the
configuration set.
Folder structure and Make environment shall be created for the module testing with consideration
of compiler specific Generic header files. Test application shall be created for each test group. All
test cases from test group shall be covered under respective test application. Coding guideline shall
be followed while creating test application. Module Test configuration shall be created for each test
group using K-SAR tool.
Generate configuration using generation tool and build test application using generated test
configuration files. For x86 platform, Run generated executable (.exe) file and verify the result.
For porting, load executable (.out / .elf) in the debugger and run test application and verify result.
Create Test report in the STR template based on the result from the above step. If any test case is
not tested or failed, provide justification for the same.

Page: 6 of 23
Module testing involves the following steps:
Analyze Module SRS and Create test plan covering all requirements with category
“Requirement on Module Behavior”
Identify different Test groups based on functionalities / group of functionalities

which shall be tested using one set of configuration
Identify Key configuration parameter for each test group
For each test group, Identify Default conditions and commonly used macros which
shall be used to pass values as argument and verify out parameter
For each test case, provide unique and sequential test case id with proper title.
Provide requirement reference in “Tested functionality” and applicable
configuration set in “Configuration Test Id”
Identify precondition specific to test case and provide it in “Pre-condition”
In test description, provide test steps like invocation of module provided APIs, test
APIs and stub functions
In Expected result, verify return value, OUT parameter for the APIs invoked in test
description
Technical review and screen of module test plan document

Page: 7 of 23
Prepare Make environment for the module testing with consideration of compiler
specific Generic header files
Create test application based on the module test plan. Add stub code for
dependent modules. Follow coding guideline while creating test application
Create test configuration for each test group using K-SAR tool
Generate test configuration and build test application using make commands
Run test application executable (.exe/.out/.elf) using debugger
Create module test report manually as per STR template. If test case is failed or
not tested, then provide proper justification
Technical review and screen of module STR document
Figure: Module testing procedure workflow

Page: 8 of 23
2.5 TEST SETUP
The test environment consists of the Integrated Development Environment (IDE) for building the BSW that
has to be tested and test setup for x86 or other specified platform.
Figure: Test Setup for Module testing
Build environment for module testing consists make environment which uses Test application, Module
code, module test configuration and test stub code for building complete test group. Test applications are
developed for each test group based on the test plan and stub code shall be created for all the
dependent modules. Sample test application and stub code are provided in the example below. Test
application will invoke functions of Module under test which is provided in the test description column of

Page: 9 of 23
test case. Module shall invoke APIs of dependency module, so stub code shall be provided. Test
configuration and Generic header files are included in the module and shall require for building test
application.
Respective make command shall be used to build the test application. Executable shall be generated once
build is successful without any compilation or linking warning. Run executable using debugger and verify
result for all test cases covered in the test group. Create module test report based on the result from all
test groups.
Test environment used for testing on x86 platform is listed below:
Sl. No. Environment Details

1 Platform x86
2 Device id --
3 Evaluation Board name (external clock used) --
4 IDE Name and Version <MinGW Developer Studio Version 2.0.5>
5 Compiler GCC
6 Linker GCC
7 GNU Make Version 3.80
Similarly, test environment for porting shall be provided for respective platform in the porting STR .
2.6 EXAMPLE
2.6.1 Diagnostic Session Control Test Group
2.6.1.1 Test Strategy

The purpose of the test cases in this section is to test the processing of the DiagnosticSessionControl
service in different protocols by the DSP layer.
Scope of the Test Cases in this section is to check all possible functionalities which could be achieved via a
DiagnosticSessionControl service. The positive and negative response transmission by the DSP layer for
the DiagnosticSessionControl is also tested in this section.
2.6.1.2 Default Condition:

DCM Module should be fully initialized and should be in Full Communication Mode before the reception
of Request.
2.6.1.3 Key Configuration Details:

1. Configuration arxml file name: App_Dcm_DspDiagnosticSessionCtrl.arxml
2. Configuration parameters details:

Page: 10 of 23
2.6.1.4 Commonly used macros:

Below listed macros used for Diagnostic session control
Sl Macro Name Value Macro Description

No and its useage
1 PHY_UDS_ON_CAN_RXPDUID 0 NA
2 FUN_UDS_ON_CAN_RXPDUID 1 NA
3 UDS_ON_CAN_TXPDUID 2 NA
4 DCM_TPNSDU_LENGTH_2 2 NA
2.6.1.5 Sequence Diagram:

NA
2.6.1.6 DCM_ETC_143: Changing Session from Default To Extended Diagnostic

Session For The Protocol Id (Dcm_Uds_On_Can)
Test case ID DCM_ETC_143
Test case version: 1.0
Test case date: 11-Mar-2015
Test purpose: Requirement Test
Configuration Test Id 4
1. If the actual diagnostic session is changed into a session different
than the default session (initiated by UDS Service
DiagnosticSessionControl), the DCM shall call
ComM_DCM_ActiveDiagnostic () to inform the ComM module about
the need to stay in Full Communication Mode.
{Dcm167}
Tested functionality:
2. The sent confirmation function shall do the mode switch of the
ModeDeclarationGroupPrototype DcmDiagnosticSessionControl by
calling
SchM_Switch_Dcm_<vendorApiInfix>_DcmDiagnosticSessionControl()
with the new diagnostic session type (see Dcm778).
{Dcm311b}

Page: 11 of 23
Pre-conditions: None
Test description: Expected test result:
1. Dcm_StartOfReception should return
1. Invoke Dcm_StartOfReception
BUFREQ_OK
(PHY_UDS_ON_CAN_RXPDUID,
2. RxBufferSizePtr should be updated with
DCM_TPNSDU_LENGTH_2, &RxBufferSizePtr)
available buffer size as 0x08
2. Invoke Dcm_CopyRxData
(PHY_UDS_ON_CAN_RXPDUID, &PduInfoPtr, 3. Dcm_CopyRxData should return
&RxBufferSizePtr) BUFREQ_OK
4. RxBufferSizePtr should be updated with
Hint: PduInfoPtr.SduLength = 0x02 buffer size as 0x06
PduInfoPtr.SduDataPtr = 0x10, 0x03
3. Invoke Simulate_Dcm_SessionControl() with
NA
SessionLevel as 3 (Extended Session)
5. PduR_DcmTransmit(UDS_ON_CAN_TXPDUI
4. Invoke
D, &PduInfoPtr) should be invoked
Dcm_TpRxIndication(PHY_UDS_ON_CAN_RXPDUI
D, NTFRSLT_OK)
Hint: PduInfoPtr.SduLength = 0x06
6. Dcm_CopyTxData should return
5. Invoke BUFREQ_OK
Dcm_CopyTxData(UDS_ON_CAN_TXPDUID, 7. PduInfoPtr.SduDataPtr should be updated
&PduInfoPtr, NULL_PTR, &TxDataCntPtr) with the values 0x50, 0x03, 0x00, 0x32,
0x00, 0x05
Hint: PduInfoPtr.SduLength = 0x06 {DCM_SRS_006}
8. TxDataCntPtr should be updated with 0x00
9. ComM_DCM_ActiveDiagnostic(0x04) should
be invoked
6. Invoke Dcm_TpTxConfirmation {Dcm167}
(UDS_ON_CAN_TXPDUID, NTFRSLT_OK) 10. SchM_Switch_Dcm_DcmDiagnosticSessionC
ontrol(0x03) should be invoked
{Dcm311b}
11. Dcm_GetSesCtrlType should return E_OK
7. Invoke Dcm_GetSesCtrlType(&SesCtrlValue) 12. SesCtrlValue should be
0x03(EXTENDED_DIAGNOSTIC_SESSION)
Comments: None
Please refer attached test template and guideline documents for more information.

Page: 12 of 23
2.6.2 Test Application and dependency module stub:

Sample Test application for the above mentioned test case:
To build above test application, stub shall be provided for the dependent modules. Following example
shows the sample stub file for PduR module.
Similarly test execution is carried on for different test cases.
2.6.3 Module Embedded STR

Below is sample Module STR for Dcm module

Page: 13 of 23
Test Log shall be stored at separate folder and reference is provided in Test report.
Please refer Module STR template for more details.
2.7 PROPOSED ENHANCEMENT:
 Automation for auto generation of Test report for all modules.
 Provide solution to identify and correct test description when there is any change in sequence
diagram when it is provided.

Page: 14 of 23
3. MODULE TESTING (TOOL)
Purpose of module tool testing is to verify correctness of generation of configuration. It

consists verification of configuration parameters for valid range, valid multiplicity,
boundary analysis, pre-conditions for parameter configuration is verified.
3.1 SCOPE OF MODULE TOOL TESTING
 To verify configuration parameters for valid ranges

 To verify Configuration parameter for valid multiplicity
 To perform boundary analysis
 To verify pre-conditions for parameter configuration
 To verify cosistency checks based on various dependencies on parameters
 To verify the generation of output files based on commandline inputs
 To verify the generation of structures, RAM / ROM arrays
 To verify the generation of Pre-compile option, Macros and Set handles
 To verify the generation of file inclusions
 To verify S-record tool generation
 To verify Ma.template validation
 To verify the generation of Typedefs
 To verify version information
 To verify the generation of functions
 To verify the generation of extern declarations
 To verify the generation of type definitions
 For all above all possible combinations of configuration which will affect the generation
of object in output files shall be verified with separate test case(e.g. for Generation of
macro with STD_ON/STD_OFF 2 separate test cases should be identified, if there are any
precompile conditions for any structure field then separate test cases shall be identified
for all possible combinations of structure fields)
3.2 INPUTS FOR MODULE TOOL TESTING
 Tool Exe(<Ma>.exe)
 Parameter Definition File (Module PDF)
 Module Template file(<Ma>.template)
 BSW Module Description Template file(<Ma>BSWMDT.arxml)
 Generation Tool SRS (GTSRS)
 Generation Tool Design(GTSDD)
 Module Descrition file(Ma.arxml) and Dependent Module Descrition files(if applicable).
 Generation Tool STP(GTSTP)
 Common Generation Tool STP
 Common Generation Tool Design
 Any other pre-configured configuration(if required)

Page: 15 of 23
3.3 MODULE TOOL TESTING PROCEDURE
Module tool testing involves following steps.
Step 1: Preparation of module generation tool test plan based on the analysis of KPIT Generation
Tool SRS, Parameter Definition File (PDF) and Tool Design.
Step 2: Prepare Test Input folder structure based on the grouping of Tests (e.g. Consistency
checks, Based on each generated files (Com_Cfg_Source)) and Test scripts used for testing
(Option.txt and batch files if required).
Step 3: Prepare Test Configuration as per Test description for every test case identified in step 1
using K-SAR Editor.
Step 4: Generate Module configuration output files based on configuration for each test case in
prepared folder structure as per step 2.
Step 5: Generate Test report using Output comparator or Generation tool test suite.
3.3.1 Block for Generation tool Testing Method
3.4 SCOPE EXCLUSIONS OF MODULE TOOL TESTING
 Tool testing restricts the verification of dynamic configurations.

Page: 16 of 23
3.5 EXAMPLE
Example 1: Testing of header file generation for PduR Configuration.
 Test case Identification
Example 2: Testing of C source file generation for PduR Configuration.

Page: 17 of 23
Example 3: Testing for parameter checks for PduR Configuration
 Test Report

Page: 18 of 23
Log will be stored at separate folder and reference is provided in Test report.
Example: 4 Testing of Parameter checks for Os Configuration (57xxx Series).
 Test case Identification
 Test Report

Page: 19 of 23
4. INTEGRATION TESTING
Integration testing focuses on testing interaction across the different layers of AUTOSAR by
integrating BSW modules, RTE, OS and a sample application developed by KPIT, with third party
MCAL drivers on a target microcontroller.
4.1 SCOPE OF INTEGRATION TESTING
 To check interaction between the BSW Modules as per AUTOSAR specification.

 To test the interface between application and BSW modules via RTE.
 To calculate memory consumption for each stack.
 Time required for startup and shutdown.
 To measure time required for transmission, reception and gateway of frames.
 To measure time required write/read data for Flash/EEPROM Memory.
 To measure CPU load and Bus load.
4.2 INPUTS FOR INTEGRATION TESTING
 Integration test specification document derived from AUTOSAR SWS, AUTOSAR

acceptance test specification, PRD (Product Requirement Document) and other use
cases from Application integration team.
Page: 20 of 23
 ISO(Diagnostics and TP layer), ASAM (XCP) and SAE (J1939) documents

 Controller specific manual
 Compiler manual
 Module user manual
 Tool user manual
 Protocol specification documents
 Functional safety documents
4.3 INTEGRATION TESTING PROCEDURE
Integration testing involves following steps.
 Preparation of test Plan from integration test specification document.

 Configuration and Generation of Modules
 System level configuration: Configuration is done using K-SAR Editor. This
configuration includes the network related information (CAN, Ethernet, LIN and
Flexray) ,signals and PDUs configurations and software component configurations.
 ECU level Configuration: Configuration is done using K-SAR Editor. This includes
configurations of all related BSW modules and RTE.
 MCAL Configuration: MCAL driver configuration is done using the K-SAR tool and
tool specified by Customer (PMG).
 Generation of configuration files- Based on the configuration Generation tool will
generate the configuration files for each module.
 Preparation of test application – This Test application will be developed based on the test
plan.
 Building the stack along with Test application using specified compiler and linker.
 Executing the test cases using specified IDE/debugger and capture the logs.
 Preparation of Test report: Test report will contain the results along with reference to logs
captured.
4.4 SCOPE EXCLUSIONS OF INTEGRATION TESTING
 All AUTOSAR requirements cannot be tested at integration level (Eg: requirements related
to file structure).
 All AUTOSAR interfaces are not covered.
4.5 EXAMPLE
 Test Plan
Testing of FULL COMMUNICATION Mode

Page: 21 of 23
 Configuration
Ecu Level configuration for Above test case are attached (ComM,EcuM)
In order to execute above test case, ServiceSwComponent, ApplicationSwComponent and

Port Interfaces(client server interface) specified in ComM SWS will be configured at
system level.
Required MCAL modules will be configured.
Generate ComM and all required BSW, MCAL modules.
 Test Application
Pseudo code is as shown below.
Swc_Runnable()
{
Rte_Call_RPortUR000_GetCurrentComMode(&ComMode);
if(ComMode == RTE_MODE_ComMMode_COMM_NO_COMMUNICATION)
{
Rte_Call_RPortUR000_RequestComMode(RTE_MODE_ComMMode_COMM_FULL_COMMU
NICATION);
}
Rte_Call_RPortUR000_GetCurrentComMode(&ComMode);
if(ComMode == RTE_MODE_ComMMode_COMM_FULL_COMMUNICATION)
{
Result = Pass;
}
}

 Build the stack along with test application.
 Execution of test case
Below is the execution flow for above test case. Figure also shows interaction between
various modules interfaces.

Page: 22 of 23
 Test Report
Testing of FULL COMMUNICATION Mode
Note: Fields in ITR documents are still need to be discussed and decided.

Page: 23 of 23

Unit Testing

Uploaded by

Copyright:

Available Formats

Unit Testing

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Unit Testing

Uploaded by

Copyright:

Available Formats

KPIT Technologies Ltd.

Confidential Proprietary Information

Document Identifier: UNIT TESTING

Test Strategy document for Unit, Module and Integration Testing

1.1 SCOPE OF UNIT TESTING

1.1.1 SCOPE INCLUSION

1.1.2 SCOPE EXCLUSION

 _ _inline are not supported by RTRT.

Test Strategy document for Unit, Module and Integration Testing

to the size limit of the debugger.

1.2 INPUTS TO UNIT TESTING

TDP (Target Deployment Port):

 RTRT TDP Qualification Sheet (Contains the information of compiler/compiler

 TDP has to be selected based on the test environment.

1.3 UNIT TESTING WORK PRODUCTS

 Test cases (UTP)

1.4 UNIT TESTING PROCEDURE

 Derive the functional test plan for all possible scenarios(path)

Test Strategy document for Unit, Module and Integration Testing

Unit testing involves the following steps:

Analysis of ESDD ( HLD + LLD + Flow Chart). & Preparation of

Stage1: Create Unit Test Plan

Verification of ESDD with source code

Generation of configuration (K-SAR EDITOR tool)

Stage2: Update Unit Test Plan, once source code is available

Selection of the TDP (RTRT tool)

Generation of PTU file from the Source code (RTRT tool)

Execute Test scripts & Report generation (RTRT tool)

Unit Test Report Preparation

Technical Review, Screen and Store of UTP and UTR

Test Strategy document for Unit, Module and Integration Testing

2. MODULE TESTING (EMBEDDED)

2.1 SCOPE OF MODULE EMBEDDED TESTING

2.1.1 Scope Inclusion

2.1.2 Scope Exclusions

2.2 INPUTS FOR MODULE EMBEDDED TESTING

 KPIT AUTOSAR <MSN> SRS

2.3 MODULE TESTING WORK PRODUCTS

 System Test Specification (STS) document.

Test Strategy document for Unit, Module and Integration Testing

2.4 MODULE EMBEDDED TESTING PROCEDURE

To test each functional requirement (Requirement with category “Requirement on Module

Test Strategy document for Unit, Module and Integration Testing

Module testing involves the following steps:

Identify different Test groups based on functionalities / group of functionalities

Identify Key configuration parameter for each test group

Identify precondition specific to test case and provide it in “Pre-condition”

Technical review and screen of module test plan document

Test Strategy document for Unit, Module and Integration Testing

Run test application executable (.exe/.out/.elf) using debugger

Technical review and screen of module STR document

Figure: Module testing procedure workflow

Test Strategy document for Unit, Module and Integration Testing

2.5 TEST SETUP

Figure: Test Setup for Module testing

Test Strategy document for Unit, Module and Integration Testing

Test environment used for testing on x86 platform is listed below:

Sl. No. Environment Details

2.6.1 Diagnostic Session Control Test Group