Automatic Testing » History » Version 6
laforge, 01/26/2018 09:31 AM
1 | 1 | laforge | h1. Automatic Testing |
---|---|---|---|
2 | |||
3 | This page will describe how we do automatic testing of OsmoMSC. |
||
4 | |||
5 | h2. Ideas for Testing |
||
6 | |||
7 | A collection of test ideas for osmo-msc |
||
8 | |||
9 | h3. Fuzzy M3UA |
||
10 | |||
11 | * Restart STP multiple times in a row, then test connectivity (e.g. by executing an A-Interface transaction that requires making an SCCP connection |
||
12 | * Silently vanish while performing an operation (e.g. shut down M3UA while doing a location update, call, sms etc...) |
||
13 | |||
14 | h3. Fuzzy SCCP |
||
15 | |||
16 | * Make an SCCP connection and leave the connection open (Will the MSC close it?) |
||
17 | * Make an SCCP connection perform some action (e.g. LU) but do not send a clear command, see if the MSC closes the connection. |
||
18 | 2 | laforge | * Send garbled connectionless SCCP packet |
19 | * Send garbled connectionless SCCP packet but with correct BSSMAP header |
||
20 | 1 | laforge | * Make SCCP connection, send garbeled packet |
21 | * Make SCCP connection, Send garbeled packet but with correct BSSMAP header |
||
22 | * Make SCCP connection, Send garbeled packet but with correct DTAP header |
||
23 | * Make SCCP connection and send an early clear command (this should could be done with all operations to see if this behaviour results in uncleared state) |
||
24 | * Make an SCCP connection, perform an action but do not respond to the clear command at the end. Do we still release the connection gracefully? |
||
25 | |||
26 | h3. Fuzzy BSSAP |
||
27 | |||
28 | * Make an SCCP connection with a CM Service Request, but request a service that does not exist. |
||
29 | (TC_cm_serv_req_*_reject) |
||
30 | * Perform the same action concurrently (e.g. the same location update for the same subscriber at the same time, try also with calls and SMS). |
||
31 | |||
32 | h3. Reset |
||
33 | |||
34 | * Send a BSSMAP RESET, check if responded with BSSMAP RESET ACK in time |
||
35 | * Repeat Reset procedure multiple times in a row |
||
36 | * Send another reset before MSSMAP RESET ACK is received (fast series of BSSMAP |
||
37 | RESET) |
||
38 | |||
39 | 4 | laforge | h3. Location update / Common MM Procedures |
40 | 1 | laforge | |
41 | * Perform a normal location update |
||
42 | 4 | laforge | ** with / without authentication |
43 | ** with / without TMSI allocation |
||
44 | ** with / without early classmark sending |
||
45 | *** Perform a location update but leave out TMSI Reallocation Complete message |
||
46 | *** Perform a location update that gets rejected, but send a TMSI Reallocation Complete anyway. |
||
47 | ** with / without encryption |
||
48 | *** test for cipher algorithm selection based on CM + VTY |
||
49 | *** Perform a location update but use wrong Ki (should be rejected) |
||
50 | *** Perform a location update but don't respond to Cipher mode command |
||
51 | ** using too long/short IMSI value (5..15 is legal, shorter or longer not) |
||
52 | ** using illegal MI type IMEI |
||
53 | * check if MM INFO is sent / not sent based on VTY config |
||
54 | 1 | laforge | |
55 | h3. MO-Call |
||
56 | |||
57 | * Make a call (normal) |
||
58 | 3 | laforge | * SCCP / outer protocols |
59 | ** Hard-close the SCCP connection while a call is running by sending a clear command |
||
60 | ** See what happens when using wrong KI (call should fail) |
||
61 | ** Stop after the Cipher Mode Complete message, do not send Setup. Do we run in a timeout and clear the sccp connection? |
||
62 | * L3/CC related |
||
63 | ** Make a call, but do not acknowledge the connection (Connect Acknowledge) |
||
64 | ** Leave out CALL Proceeding message. |
||
65 | ** Leave out Connect message |
||
66 | ** CC messages without mandatory IEs |
||
67 | ** CSD or CTM calls, i.e. anything beyond normal voice |
||
68 | * MGCP |
||
69 | ** Do not respond to any MGCP request (MGW down) |
||
70 | ** Fail every MGCP request |
||
71 | ** Fail one choosen MGCP transaction. Repeat this test until all MGCP transactions have been tried. |
||
72 | ** Stop responding to one choosen MGCP transaction. Repeat this test until all MGCP transactions have been tried. |
||
73 | ** Respond with garbeled MGCP messages, see what happens when the IP-Address is an empty string or is missing completely. Also check the same with the other parameters. |
||
74 | ** Try what happens when the MGW returns the same connection identifier for both connections. |
||
75 | 1 | laforge | * Check if the RTP streams are properly switched, do the RTP parameters issued by the MSC make sense? |
76 | 3 | laforge | * codec related bits |
77 | ** Make a call, but in the ASSIGNMENT COMPLETE message, respond with a choosen codec that was not on the speech codec list in the ASSIGNMENT REQUEST. |
||
78 | ** bearer capabilities without codec related octets (e.g. in MO SETUP) |
||
79 | * external MNCC side |
||
80 | ** check if modification of bearer capabilities on MNCC side (in MO case) works |
||
81 | * built-in MNCC handler |
||
82 | ** check if codec matching works in case of overlap and no overlap between bearer capabilities etc. |
||
83 | 1 | laforge | |
84 | 5 | laforge | h3. MT-Call including Paging |
85 | 1 | laforge | |
86 | (Where possible, apply the odd cases from MO-Call) |
||
87 | 5 | laforge | |
88 | 1 | laforge | * Place a call via MNCC (normal) |
89 | 5 | laforge | ** check for missing informatio nlements |
90 | 1 | laforge | * Miss out the ALERTING message |
91 | 5 | laforge | * Paging |
92 | ** by TMSI and by IMSI (if TMSI allocation disabled) |
||
93 | ** Do not respond to paging |
||
94 | ** Respond with a wrong IMSI/TMSI in PAGING RESPONSE (never paged) |
||
95 | ** verify if paging is done in correct LA (that of last LU) |
||
96 | ** double response to single paging (cloned IMSI behavior) |
||
97 | 1 | laforge | |
98 | h3. MO-SMS |
||
99 | |||
100 | * Send an SM (normal) |
||
101 | * Stop after the Cipher Mode Complete message, do we run in a timeout and clear the sccp connection? |
||
102 | * Skip CP-DATA/RP-DATA, just send an unsoliciated CP-ACK |
||
103 | * Send CP-DATA/RP-DATA twice |
||
104 | * Leave out TP-Destination-Address in CP-DATA/RP-DATA |
||
105 | * Use an invalid TP-PID in CP-DATA/RP-DATA. |
||
106 | * Use an invalid TP-DCS in CP-DATA/RP-DATA. |
||
107 | * Try coding groups other than GSM 7 bit default alphabet (do we support different ones?) |
||
108 | * Can TP-User-Data-Length exceed the allowed 160 chars? If yes we should try what happens when we exceed this limit. |
||
109 | * Try with message that has exactly 160 chars (maximum length) |
||
110 | |||
111 | h3. MT-SMS |
||
112 | |||
113 | 6 | laforge | * Initiate sending an SM via SMPP |
114 | 1 | laforge | * Skip the CP-ACK message. |
115 | * Skip the CP-DATA/RP-ACK message. |
||
116 | * Respond with DTAP/MSMS/CP-ERROR, see if the MSC trys to deliver the SM again. |
||
117 | |||
118 | h3. USSD |
||
119 | |||
120 | * Execute USSD request (*#100#) normally |
||
121 | * Use invalid ussd-DataCodingScheme parameter |
||
122 | * Try USSD string that exceeds the maximum permitted length |
||
123 | * Try USSD string that has exactly the maximum permitted length |
||
124 | * Try coding groups other than GSM 7 bit default alphabet (do we support different ones?) |
||
125 | * Try strings that violate the common USSD syntax (*/#) |
||
126 | |||
127 | |||
128 | h3. External handover |
||
129 | |||
130 | (This case requires two BSC/MGW test components) |
||
131 | * Run external handover procedure as normal. |
||
132 | * Run the procedure again, stop responding to MSC messages where possible to see if timeout mechanisms (T23) work properly. |
||
133 | * For HANDOVER REQUIRED try the procedure with the invalid changes: |
||
134 | ** Use invalid cause code in HANDOVER REQUIRED message |
||
135 | ** Send an empty Cell Identifier List |
||
136 | ** Send no Cell Identifier List |
||
137 | ** Choose channel type other than SPEECH (currently we only support SPEECH) |
||
138 | ** Send not speech version |
||
139 | ** Send no AoIP speech codec. (The MSC should recject the HANDOVER REQUIRED message with an HANDOVER REQUIRED REJECT message, check if the cause code set by the MSC makes sense) |
||
140 | * For HANDOVER REQUEST ACKNOWLEDGE try the procedure with the invalid changes: |
||
141 | ** Send no Layer 3 information |
||
142 | ** Send no AoIP Transport Layer Address |
||
143 | ** Send port number = 0 in AoIP Transport Layer Address |
||
144 | ** Send IP-Address 0.0.0.0 in AoIP Transport Layer Address |
||
145 | ** Send no Codec List |
||
146 | ** Send inconsistant Codec List |
||
147 | ** Send no Speech Version |
||
148 | ** Send no Speech Codec (The MSC should send an HANDOVER REQUIRED REJECT to the source BSC? Does the cause code make sense?) |
||
149 | * Answer the HANDOVER REQUEST message directly with an HANDOVER FAILURE message, the MSC should then HANDOVER REQUIRED REJECT to the source BSC (correct?) |
||
150 | * Skip HANDOVER DETECT and directly send HANDOVER COMPLETE message |