Menu
Latest
12 meetings · Prague, Jeju · 12–16 Oct
Reports
RAN1#126-bis · SA2#177

Glossary term · Other

Test procedure

Test Procedure

Other →

Test procedure is the executable sequence of actions and commands required to conduct all conformance tests for 3GPP terminals and network equipment within a defined test area.

Introduced
Rel-8
Where
User Equipment › SIM/USIM
Specifications
2 specs
Test procedure Description Purpose What changed Neighbours Specifications

Description

A Test Procedure in 3GPP terminology is defined as the sequence of actions and commands necessary to perform all the test cases defined in a test area. It represents the executable methodology that translates abstract test case definitions into concrete operational steps that a test engineer or automated test system can follow. Test procedures bridge the gap between what must be verified and how that verification is performed in practice.

The concept operates within the 3GPP conformance testing framework, which spans both terminal testing and network equipment testing. The 31.213 specification defines test procedures for user equipment (UE) conformance testing across various radio access technologies, covering the steps needed to configure the UE, establish connections, invoke specific procedures, and verify expected outcomes. The 51.013 specification addresses similar concerns for GSM/EDGE base station testing. These specifications ensure that test procedures are standardized, reproducible, and applicable across different test platforms and laboratories.

A test procedure typically includes several categories of actions. Initial conditions must be established, which may include configuring the UE in a particular state, setting up network simulator parameters, and loading specific subscriber data. The procedure then progresses through a defined sequence of commands and responses, often involving signaling exchanges, measurement requests, or data transfers. At each step, pass/fail criteria are evaluated against expected outcomes. Finally, the procedure includes teardown or reset steps to return the equipment to a known state for the next test.

The relationship between test procedures, test cases, and test areas is hierarchical. A test area represents a broad functional domain, such as radio resource control (RRC) procedures, mobility management, or session management. Within each test area, multiple test cases are defined, each targeting a specific behaviour. A test procedure provides the operational sequence for executing all test cases within a given area. This means a single test procedure may contain multiple test cases, each with its own specific configuration and verification steps, organized into a coherent execution flow.

Test procedures are implemented in test platforms through test scripts or test description languages. 3GPP specifications such as 36.523 and 38.523 use TTCN-3 (Testing and Test Control Notation version 3) to formally describe test procedures, enabling automated execution on standardized test platforms. The TTCN-3 descriptions are derived from the prose test procedures and provide a machine-executable representation. This dual representation — prose specification and formal TTCN-3 code — ensures that test procedures are both human-readable and machine-executable.

The concept has remained stable from Rel-8 through Rel-19, reflecting its fundamental role in the testing infrastructure. As technologies have evolved from LTE through 5G NR, the specific actions and commands within test procedures have changed dramatically, but the organizational concept of a procedure as a defined sequence for executing test cases has persisted. This continuity enables test laboratories to maintain consistent methodologies while adapting to new technologies.

Purpose & Motivation

The Test Procedure concept exists to solve the problem of translating abstract conformance requirements into concrete, reproducible test steps. 3GPP specifications define what behaviours equipment must exhibit, but verifying those behaviours requires precise operational sequences that can be executed consistently across different laboratories, test platforms, and geographical locations. Test procedures provide these sequences, ensuring that conformance testing is objective, repeatable, and comparable regardless of where or by whom it is performed.

Before standardized test procedures were formalized, testing was often vendor-specific or laboratory-specific, leading to inconsistencies in how requirements were verified. Two laboratories could test the same requirement and reach different conclusions because they followed different operational steps or used different initial conditions. The formalization of test procedures in specifications such as 31.213 and 51.013 addressed this problem by establishing canonical sequences that all test laboratories must follow. This standardization is essential for certification programs, where a device's compliance must be verifiable and defensible.

Test procedures also serve an automation imperative. As the volume of test cases grew with each generation, manual testing became impractical. The formalization of test procedures enabled the development of automated test platforms that could execute procedures without human intervention. The mapping of test procedures to TTCN-3 code accelerated this automation, allowing test campaigns to be executed faster and with greater consistency. This automation capability is particularly important for regression testing, where devices must be re-verified after software updates to ensure that previously passing tests continue to pass.

The concept has endured across releases because it addresses a permanent need. As long as equipment must be tested against specifications, there must be a defined way to perform that testing. The test procedure provides that definition, making it an enduring element of the 3GPP testing architecture from Rel-8 through Rel-19 and beyond.

What changed in its specifications

The latest release-to-release comparison of specifications that define Test procedure. Each summary describes the whole specification, not only this term.

TS 31.213Rel-6 → Rel-7

Rel-7 added USSD message delivery and transfer to USIM with formatted and unformatted events, concatenation processing, and conformance requirements for formatted SMS events plus test coverage for unformatted SMS and USSD events.

Full comparison in TS 31.213 →
TS 51.013Rel-4 → Rel-5

Rel-5 added new handler methods, events, channel allocation, proactive command control, and concatenation processing to the USIM toolkit.

Full comparison in TS 51.013 →

Release Timeline

Evolution Across Releases

An overview written from the defining specifications, not a verified change history. For the exact text, open the specifications listed below.

Rel-8 Initial

Introduced with the definition 'the sequence of actions/commands to perform all the test cases defined in a test area', establishing the foundational methodology for executing conformance tests in a structured manner.

Definition carried over unchanged from Rel-8.

Definition carried over unchanged.

Definition carried over unchanged.

Definition carried over unchanged.

Definition carried over unchanged.

Definition carried over unchanged.

Definition carried over unchanged.

Definition carried over unchanged.

Definition wording was reformatted to 'the sequence of actions/commands to perform all the test cases defined in a test area' on a single line, with no substantive change to the meaning.

Definition carried over unchanged from Rel-17.

Definition reverted to line-broken formatting, with no substantive change to the meaning.

Defining Specifications

3GPP specifications that define or reference Test procedure, with the latest known release. Sourced from the 3GPP document catalog — see methodology.

SpecificationTitleRelease
TS 31.213 vi50 USIM API for Java Card Test Specification Rel-18 read
TS 51.013 vj00 SIM API for Java Card Test Specification Rel-19 read