Automatic Testing » History » Version 1
laforge, 01/24/2018 12:10 PM
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 | * Send garbeled connectionless SCCP packet |
||
19 | * Send garbeled connectionless SCCP packet but with correct BSSMAP header |
||
20 | * 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 | |||
27 | h3. Fuzzy BSSAP |
||
28 | |||
29 | * Make an SCCP connection with a CM Service Request, but request a service that does not exist. |
||
30 | (TC_cm_serv_req_*_reject) |
||
31 | * 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). |
||
32 | |||
33 | h3. Reset |
||
34 | |||
35 | * Send a BSSMAP RESET, check if responded with BSSMAP RESET ACK in time |
||
36 | * Repeat Reset procedure multiple times in a row |
||
37 | * Send another reset before MSSMAP RESET ACK is received (fast series of BSSMAP |
||
38 | RESET) |
||
39 | |||
40 | h3. Location update |
||
41 | |||
42 | * Perform a normal location update |
||
43 | * Perform a location update but use wrong Ki (should be rejected) |
||
44 | * Perform a location update but leave out TMSI Reallocation Complete message |
||
45 | * Perform a location update but don't respond to Cipher mode command |
||
46 | * Perform a location update that gets rejected, but send a TMSI Reallocation Complete anyway. |
||
47 | |||
48 | |||
49 | h3. MO-Call |
||
50 | |||
51 | * Make a call (normal) |
||
52 | * Hard-close the SCCP connection while a call is running by sending a clear command |
||
53 | * Make a call, but do not acknowledge the connection (Connect Acknowledge) |
||
54 | * See what happens when using wrong KI (call should fail) |
||
55 | * Stop after the Cipher Mode Complete message, do not send Setup. Do we run in a timeout and clear the sccp connection? |
||
56 | * Leave out CALL Proceeding message. |
||
57 | * Leave out Connect message |
||
58 | * Do not respond to any MGCP request (MGW down) |
||
59 | * Fail every MGCP request |
||
60 | * Fail one choosen MGCP transaction. Repeat this test until all MGCP transactions have been tried. |
||
61 | * Stop responding to one choosen MGCP transaction. Repeat this test until all MGCP transactions have been tried. |
||
62 | * Check if the RTP streams are properly switched, do the RTP parameters issued by the MSC make sense? |
||
63 | * 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. |
||
64 | * Try what happens when the MGW returns the same connection identifier for both connections. |
||
65 | * 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. |
||
66 | |||
67 | h3. MT-Call |
||
68 | |||
69 | (Where possible, apply the odd cases from MO-Call) |
||
70 | * Place a call via MNCC (normal) |
||
71 | * Do not respond to paging |
||
72 | * Respond with a wrong IMSI in PAGING RESPONSE |
||
73 | * Miss out the ALERTING message |
||
74 | |||
75 | |||
76 | h3. MO-SMS |
||
77 | |||
78 | * Send an SM (normal) |
||
79 | * Stop after the Cipher Mode Complete message, do we run in a timeout and clear the sccp connection? |
||
80 | * Skip CP-DATA/RP-DATA, just send an unsoliciated CP-ACK |
||
81 | * Send CP-DATA/RP-DATA twice |
||
82 | * Leave out TP-Destination-Address in CP-DATA/RP-DATA |
||
83 | * Use an invalid TP-PID in CP-DATA/RP-DATA. |
||
84 | * Use an invalid TP-DCS in CP-DATA/RP-DATA. |
||
85 | * Try coding groups other than GSM 7 bit default alphabet (do we support different ones?) |
||
86 | * Can TP-User-Data-Length exceed the allowed 160 chars? If yes we should try what happens when we exceed this limit. |
||
87 | * Try with message that has exactly 160 chars (maximum length) |
||
88 | |||
89 | h3. MT-SMS |
||
90 | |||
91 | * Initiate sending an SM via GSUP |
||
92 | * Skip the CP-ACK message. |
||
93 | * Skip the CP-DATA/RP-ACK message. |
||
94 | * Respond with DTAP/MSMS/CP-ERROR, see if the MSC trys to deliver the SM again. |
||
95 | |||
96 | |||
97 | h3. USSD |
||
98 | |||
99 | * Execute USSD request (*#100#) normally |
||
100 | * Use invalid ussd-DataCodingScheme parameter |
||
101 | * Try USSD string that exceeds the maximum permitted length |
||
102 | * Try USSD string that has exactly the maximum permitted length |
||
103 | * Try coding groups other than GSM 7 bit default alphabet (do we support different ones?) |
||
104 | * Try strings that violate the common USSD syntax (*/#) |
||
105 | |||
106 | |||
107 | h3. External handover |
||
108 | |||
109 | (This case requires two BSC/MGW test components) |
||
110 | * Run external handover procedure as normal. |
||
111 | * Run the procedure again, stop responding to MSC messages where possible to see if timeout mechanisms (T23) work properly. |
||
112 | * For HANDOVER REQUIRED try the procedure with the invalid changes: |
||
113 | ** Use invalid cause code in HANDOVER REQUIRED message |
||
114 | ** Send an empty Cell Identifier List |
||
115 | ** Send no Cell Identifier List |
||
116 | ** Choose channel type other than SPEECH (currently we only support SPEECH) |
||
117 | ** Send not speech version |
||
118 | ** 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) |
||
119 | * For HANDOVER REQUEST ACKNOWLEDGE try the procedure with the invalid changes: |
||
120 | ** Send no Layer 3 information |
||
121 | ** Send no AoIP Transport Layer Address |
||
122 | ** Send port number = 0 in AoIP Transport Layer Address |
||
123 | ** Send IP-Address 0.0.0.0 in AoIP Transport Layer Address |
||
124 | ** Send no Codec List |
||
125 | ** Send inconsistant Codec List |
||
126 | ** Send no Speech Version |
||
127 | ** Send no Speech Codec (The MSC should send an HANDOVER REQUIRED REJECT to the source BSC? Does the cause code make sense?) |
||
128 | * Answer the HANDOVER REQUEST message directly with an HANDOVER FAILURE message, the MSC should then HANDOVER REQUIRED REJECT to the source BSC (correct?) |
||
129 | * Skip HANDOVER DETECT and directly send HANDOVER COMPLETE message |