4 Test Environment

3GPP51.013Release 17Test specification for Subscriber Identity Module (SIM) Application Programming Interface (API) for Java CardTS

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

This clause specifies requirements that shall be met and the testing rules that shall be followed during the test procedure.

4.1 Applicability

The tests defined in the present document shall be performed taking into account the services supported by the card as specified in the EF_SST file.

The test defined in the present document are applicable to cards implementing 3GPP TS 43.019 [7] unless otherwise stated.

The tests defined in the present document require that the card support the concatenation process with 2 concatenated SMS. Therefore the envelope handler shall support 280 bytes of data.

4.2 Test environment description

The general architecture for the test environment is.

NOTE: Figure 4.2 shows the test architecture required to test interoperability at both API and bytcode level. The latter is currently not included in the current specification. The diagram is for information.

Figure 4.2

4.3 Tests format

4.3.1 Test Area Reference

Each test area is referenced as follows:

API Testing:: ‘API_[package name]_[classname]_[methodname]’ where

package name:

sim.access package: ‘1’

sim.toolkit package: ‘2’

class name:

yyy: 3 letters for each class.

See Annex A for full classes acronyms list.

method name:

zzzz[input parameters]:

See Annex A for full methods name acronyms list.

FWK: framework testing

Chapter name:

xxx: 3 letters for each chapter

See annex F for full chapter acronyms list

Subchapter name

yyyy: : 4 letters for each subchapter

See annex F for full subchapter acronyms list

LDR: loader testing

[TBD]

4.3.1.1 Conformance requirements

The conformance requirements are expressed in the following way:

– Method prototype as listed in 3GPP TS 43.019 [7].

– Normal execution:

– Contains normal execution and correct parameters limit values, each referenced as a Conformance Requirement Reference Normal (CRRN).

– Parameters error:

– Contains parameter errors and incorrect parameter limit values, each referenced as a Conformance Requirement Reference Parameter Error (CRRP).

– Context error:

– Contains errors due to the context the method is used in, each referenced as a Conformance Requirement Reference Context Error (CRRC).

4.3.1.2 Test Area files

The files included in the Test Area use the following naming convention:

– Test Script: [Test Area Reference]_[Test script number].scr

– Test Applet: [Test Area Reference]_[Test applet number].java

– Load Script: [Test Area Reference]_[Load Script number].ldr

– Cleanup Script: [Test Area Reference]_[Cleanup Script number].clr

– Parameter File: [Test Area Reference]_[Parameter File number].par

The test script, applet, installation parameters, load script, cleanup script and conversion parameters numbers start from ‘1’.

The test script, load script and cleanup script shall share a common syntax and format (see Annex B).

The parameter file has an own syntax (see annex G) and contains parameters to be used for CAP-file conversion and loading/cleanup script generation.

Scripts file shall be run in the following order:

[Test Area Reference]_1.ldr

[Test Area Reference]_1.scr

[Test Area Reference]_1.clr

[Test Area Reference]_2.ldr

[Test Area Reference]_2.scr

[Test Area Reference]_2.clr

….

[Test Area Reference]_n.ldr

[Test Area Reference]_n.scr

[Test Area Reference]_n.clr

In case that one of the files is not needed, it shall be skipped during the tests execution.

4.3.1.3 Test Procedure

Each test procedure contains a table to indicate the expected responses form the API and/or the APDU level as follows:

Test Case
Id	Description	API Expectation	APDU Expectation
	Test Case detailed description	API expected behaviour.	Expected response at APDU level.

4.3.1.4 Test Coverage

The table at the end of each test procedure indicates the correspondence between the Conformance Requirements Reference (CRR) and the different test cases.

4.4 Initial Conditions

The Initial Conditions are a set of general prerequisites for the SIM prior to the execution of testing. For each test procedure described in the present document, the following rules apply to the Initial Conditions:

– unless otherwise stated, the file system and the files’ content shall fulfil the requirements described in annex C;

– unless otherwise stated, before installing the applet(s) relevant to the current test procedure, all packages specific to other test procedures shall not be present.

When both statements apply, a test procedure is said to be in the "Default Initial Conditions" state.

4.5 Package name

Java packages integrating this Test Suite shall follow this naming convention:

sim.test.access.[Test Area Reference]: Java Card packages containing Test Area References for the 3GPP TS 43.019 [7] sim.access package.

sim.test.framework.[Test Area Reference]: Java Card packages containing Test Area References for the 3GPP TS 43.019 [7] framework.

sim.test.util: for the Test util package defined in this Test Suite.

sim.test.toolkit.[Test Area Reference]: Java Card packages containing Test Area References for the 3GPP TS 43.019 [7] sim.toolkit package.

EXAMPLE: The package ../sim.test.access.[Test Area Reference] creates the following directory structure ../sim/test/access/[Test Area Reference]/API_1_…_[1..n].*, where ‘API_1_…_[1..n].*’ are the different test applets Java source files used in [Test Area Reference].

4.6 AID Coding

The AID coding for the Test Packages, Applet classes and Applet shall be as specified in TS 101 220 [14]. In addition, the following TAR values are defined for use within the present document:

TAR Coding (3 bytes/ 24 bits):

b21

b22

b23

b24

Specific Test Applet Name

Test Package Identifier

Test package Identifier( bits b1-b3):

000: reserved (as TAR= ‘00.00.00’ is reserved for Card Manager)

001: API

010: Framework

011: Loader

111: sim.test.util

other values are RFU

Application Provider specific data (1 byte):

’00’: for Package

’01’: for Applet class

’02’: for Applet Instance

EXAMPLE: The AID of Package sim.test.util is ‘A0 00 00 00 09 00 02 FF FF FF FF 89 E0 00 00 00’.

4.6.1 Specific Test Applet Name for API

Specific applet test name (bits b4-b24):

b10

b11

b12

b13

b14

b15

b16

b17

b18

b19

b20

b21

b22

b23

b24

Applet instance Number

Applet Class Number

Method

Class

API Test Package

for API Test Package(3 bits)

001 sim.access

010 sim.toolkit

other are RFU

Class (5 bits): need to be assigned specification order see Annex A for the full list

Method (6 bits): need to be assigned specification order see Annex A for the full list

Applet Class Number (5 bits): linked to Test Area, it shall start with 1 for classes and shall be 0 for package.

Applet Instance Number (2 bits) defined in the test procedure it shall start with 01 for applet instance and shall be 00 for package and class.

4.6.2 Specific Test Applet Name for Framework

Specific applet test name (bits b4-b24):

b10

b11

b12

b13

b14

b15

b16

b17

b18

b19

b20

b21

b22

b23

b24

RFU ( set to 0 )

Applet instance Number

Applet Class Number

Test Area within the chapter

Chapter

for Chapter (5 bits)

00001 Toolkit Installation Parameters

00010 Minimum Handler Availability

00011 Handler Integrity

00100 Applet Triggering

00101 Proactive Command Sending

00110 Framework Security

00111 Envelope Response Posting

01000 File System Context

01001 Exception Handling

01010 Other parts transferred to framework from API

01011 Concatenation processing

other are RFU

Test Area within the chapter (6 bits): values are defined in Annex F

Applet Class number (5 bits): linked to Test Area, it shall start with 1 for classes and shall be 0 for package.

Applet Instance number (3 bits) defined in the test procedure it shall start with 01 for applet instance and shall be 00 for package and class.

4.7 Test Equipment

These clauses recommend a minimum specification for each of the items of test equipment referenced in the tests.

4.7.1 APDU tool

This test tool shall meet the following requirements:

– be able to send command to the card TPDU;

– be able to check none, only a part, or all of the data returned;

– be able to check none, only part, or all of the status returned;

– be able to accept all valid status codes returned;

– be able to support Reader commands;

– be able to generate a log file for each test execution.

– if more data is returned than defined in the test specification, the tool shall continue;

– if less data is returned than defined in the test specification, the tool shall aborts and return an error;

– if there is an error in data or status returned, the tool shall abort and return an error.

The log file produced by the test tool shall include the following information:

– all commands issued;

– all data returned;

– all status returned;

– all errors codes;

– expected data and status in case of error;

– comments from the scripts;

– a log message to report success or failure of the test.

4.7.2 Util package

Annex D includes java source code for the sim.test.util package as well as loading , testing and cleaning script examples.

4.7.3 Applet installation parameters

4.7.3.1 Security parameters

Loading scripts shall use the following security parameters as stated in 3GPP TS 23.048 [8] for applet installation:

Parameter	Value in hexadecimal
SPI	0A 00
KIC	00
KID	Value as described in the TS 23.048[8] (recommended value: 15)
TAR	00 00 00
CNTR	00 00 00 00 01
PCNTR	00
Key	Corresponding to KID (recommended value: 01 23 45 67 89 AB CD EF EF CD AB 89 67 45 23 01)

4.7.3.2 Loading components

Cap files in loading scripts shall not include the descriptor component as described in Java Card 2.1 VM Architecture Specification [13].

4.8 Testing methodology

4.8.1 Test interfaces and facilities

The SIM-ME interface provides the main transport interface for the purpose of performing conformance tests.

The SIM API interface provides the main test interface for the purpose of performing conformance tests.