TCAP Testing

The TCAP specification is found in ITU Q.787 [93]. The purpose of the tests is to ensure validation and compatibility of an SP's TCAP protocol according to ITU Q.771–775 [82–86], to a reasonable but not exhaustive degree.

The tests are split into the TC Transaction sublayer (TSL) test specification and the TC Component sublayer (CSL) test specification. These test categories along with the tests that they contain are shown below in Tables 16-6 and 16-7.

Table 16-6. Transaction Sublayer Test Categories and Test Numbers Found in Q.787

Category	Test Number(s)	Total
Valid function
Unstructured dialogue	1.1.1.1–1.1.1.2	2
Structured dialogue	1.1.2.1.1.1–1.1.2.1.2, 1.1.2.1.2.1–1.1.2.1.2.2, 1.1.2.2.1.1.1–1.1.2.2.1.1.3, 1.1.2.2.1.2.1–1.1.2.2.1.2.3, 1.1.2.2.2.1.1–1.1.2.2.2.1.3, 1.1.2.2.2.2.1–1.1.2.2.2.2.3, 1.1.2.3–1.1.2.5	25
Encoding and value variations	1.1.3.1.1.1.1–1.1.3.1.1.1.2, 1.1.3.1.1.2.1, 1.1.3.1.1.3, 1.1.3.2.1.1–1.1.3.2.1.2	6
Syntactically invalid behavior
Invalid values for information elements	1.2.1.1.1–1.2.1.1.2, 1.2.1.2.1, 1.2.1.3.1, 1.2.1.4.1, 1.2.1.5.1–1.2.1.5.2	7
Invalid structure	1.2.2.1.1, 1.2.2.2.1–1.2.2.2.2, 1.2.2.3.1–1.2.2.3.5, 1.2.2.4.1–1.2.2.4.2, 1.2.2.5.1, 1.2.2.6.1, 1.2.2.7.1–1.2.2.7.3, 1.2.3.1.1, 1.2.3.2.1	17
Inopportune messages	1.3.1.1, 1.3.2.1, 1.3.3.1	3
Multiple transaction encoding	1.4.1.1–1.4.1.2, 1.4.2.1–1.4.2.2	4
	Totals	64

Table 16-7. Component Sublayer Tests

Category	Test Number(s)	Total
Valid function
Invoke component, unlinked operations	2.1.1.1.1–2.1.1.1.5, 2.1.1.2.1–2.1.1.2.2, 2.1.1.3.1–2.1.1.3.2, 2.1.1.4.1	10
Invoke component, linked operations	2.1.2.1.1–2.1.2.1.4, 2.1.2.2.1–2.1.2.2.2,	6
Remote reject	2.1.3.1.1–2.1.3.1.4, 2.1.3.2.1 –2.1.3.2.3, 2.1.3.3.1–2.1.3.3.4	11
Reception of component leading to TC-User reject	2.1.4.1.1–2.1.4.1.4, 2.1.4.2.1, 2.1.4.3.1–2.1.4.3.3,	8
Segmentation for return result	2.1.5.1.1–2.1.5.1.2, 2.1.5.2.1	3
User cancel	2.1.6	1
Encoding variations	2.1.7.1–2.1.7.3, 2.1.7.4.1.1–2.1.7.4.1.2, 2.1.7.4.2	6
Multiple components grouping	2.1.8.1–2.1.8.3	3
Dialogue portion	2.1.9.1.1–2.1.9.1.3, 2.1.9.2.1–2.1.9.2.2, 2.1.9.3, 2.1.9.4, 2.1.9.5.1–2.1.9.5.4, 2.1.9.6, 2.1.9.7.1–2.1.9.7.4	16
Syntactically invalid behaviour
Invalid values for information elements	2.2.1.1–2.2.1.2	2
Invalid structure	2.2.2.1.1, 2.2.2.1.2, 2.2.2.2.1–2.2.2.2.3, 2.2.2.3.1, 2.2.2.3.2, 2.2.2.4.1, 2.2.2.4.2, 2.2.2.5.1–2.2.2.5.8	17
Invalid encoding for invoke component	2.2.3.1–2.2.3.3	3
Inopportune behaviour
Inopportune invoke component	2.3.1.1	1
Unrecognized invoke ID	2.3.2.1–2.3.2.4	4
Unexpected components	2.3.3.1–2.3.3.6	6
Dialogue portion, unexpected APDUs	2.3.4.1–2.3.4.8	8
	Totals	105

The remainder of this section explains three of these tests: 1.1.2.1.1 (1), 1.2.3.3 (1), and 2.3.2.4 (1). These numbers refer to the test numbers allocated in Q.787.

Test Configuration

A single test configuration is used for TCAP testing. This configuration is the same one configuration 1 used in SCCP testing.

Example 1: Clearing Before Subsequent Message; Valid Clearing from Initiating Side; Prearranged Ending, Test 1.1.2.1.1 (1)

This test verifies that the DUT is able to correctly send a begin message and then terminate the transaction locally using the "prearranged end" method. It is used for both validation and compatibility testing purposes.

The DUT should send a begin message to the Tester; however, so that the Tester does not have a chance to reply, TR-END request primitive (prearranged) destined for the TSL at the DUT should follow immediately.

Figure 16-29 shows the expected primitive and message sequence for this test.

The transaction ID should be released at SP A. Consider the test passed if the DUT sends the begin message, but does not send an end message.

Example 2: First Continue Message; OTID Absent, Test 1.2.2.3 (1)

This test is to check that the DUT discards a corrupt continue message. It is used for validation testing purposes only.

Both SP A (DUT TSL) and SP B (Tester TSL) should be in the idle state before testing commences.

The DUT should send a begin message to the Tester, and the Tester should respond with a corrupt continue message. The continue should have a syntax error and an OTID that is not deliverable. Figure 16-30 shows the expected primitive and message sequence for this test.

Consider the test passed if the DUT sends the begin message, does not inform the TR-User of the continue, and does not respond to the continue.

Example 3: Inopportune Reject Component, Test 2.3.2.4 (1)

This test is to check that the DUT does not affect any active invocation(s) if it receives a Reject component with an Invoke ID that does not correspond to any active invocation. It is used for validation testing purposes only.

Both SP A (DUT TSL) and SP B (Tester TSL) should be in the idle state before testing commences.

The DUT should initiate an operation invocation (send an Invoke component Class 1 or 2) to the Tester, which should respond with a Reject component that has an invalid Invoke ID.

Figure 16-31 below shows the expected primitive and message sequence for this test.