-
Notifications
You must be signed in to change notification settings - Fork 2.1k
/
Copy pathTest_TC_IDM_1_3.yaml
390 lines (356 loc) · 20.1 KB
/
Test_TC_IDM_1_3.yaml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
# Copyright (c) 2023 Project CHIP Authors
#
# Licensed under the Apache License, Version 2.0 (the "License");
# you may not use this file except in compliance with the License.
# You may obtain a copy of the License at
#
# http://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.
# Auto-generated scripts for harness use only, please review before automation. The endpoints and cluster names are currently set to default
name:
3.1.3. [TC-IDM-1.3] Batched Commands Invoke Request Action from DUT to TH -
[{DUT_Client}]
PICS:
- MCORE.IDM.C.InvokeRequest.BatchCommands
config:
nodeId: 0x12344321
cluster: "Basic Information"
endpoint: 0
tests:
- label: "Note"
verification: |
Chip-repl commands used below are an example to verify the DUT as client test cases. For certification test, we expect DUT should have a capability or way to run the equivalent command.
disabled: true
- label:
"Step 0 (Pre-Condition 1): Commission TH Client to TH device (Server),
if not done so already."
verification: |
Ensure DUT is commissioned to TH device (Server).
disabled: true
- label:
"Step 0 (Pre-Condition 2): Commission DUT to TH device (Server), if
not done so already."
verification: |
Ensure DUT is commissioned to TH device (Server).
This likely requires opening the commissioning window with TH Client."
disabled: true
- label:
"Step 0 (Pre-Condition 3): TH Client send `FailAtFault` command to
`FaultInjection` cluster to TH device (Server)."
cluster: "FaultInjection"
command: "FailAtFault"
arguments:
values:
- name: "Type"
value: 3
- name: "Id"
value: 12
- name: "NumCallsToSkip"
value: 3
- name: "NumCallsToFail"
value: 1
- name: "TakeMutex"
value: false
verification: |
Equivalent TH Client command to run `chip-tool faultinjection fail-at-fault 3 12 3 1 false 1 0`
On TH(all-clusters-app), Verify command is successfully:
CHIP:DMG: InvokeRequestMessage =
CHIP:DMG: {
CHIP:DMG: suppressResponse = false,
CHIP:DMG: timedRequest = false,
CHIP:DMG: InvokeRequests =
CHIP:DMG: [
CHIP:DMG: CommandDataIB =
CHIP:DMG: {
CHIP:DMG: CommandPathIB =
CHIP:DMG: {
CHIP:DMG: EndpointId = 0x0,
CHIP:DMG: ClusterId = 0xfff1fc06,
CHIP:DMG: CommandId = 0x0,
CHIP:DMG: },
CHIP:DMG:
CHIP:DMG: CommandFields =
CHIP:DMG: {
CHIP:DMG: 0x0 = 3,
CHIP:DMG: 0x1 = 12,
CHIP:DMG: 0x2 = 3,
CHIP:DMG: 0x3 = 1,
CHIP:DMG: 0x4 = false,
CHIP:DMG: },
CHIP:DMG: },
CHIP:DMG:
CHIP:DMG: ],
CHIP:DMG:
CHIP:DMG: InteractionModelRevision = 11
CHIP:DMG: },
CHIP:DMG: AccessControl: checking f=1 a=c s=0x000000000001B669 t= c=0xFFF1_FC06 e=0 p=m
CHIP:DMG: AccessControl: allowed
CHIP:DMG: Received command for Endpoint=0 Cluster=0xFFF1_FC06 Command=0x0000_0000
CHIP:ZCL: FaultInjection: Configure a fault of type: 3 and Id: 12 to be triggered deterministically <--------- Verify success with this message.
disabled: true
- label:
"Step 0 (Pre-Condition 4): TH Client send `FailAtFault` command to
`FaultInjection` cluster to TH device (Server)."
cluster: "FaultInjection"
command: "FailAtFault"
arguments:
values:
- name: "Type"
value: 3
- name: "Id"
value: 13
- name: "NumCallsToSkip"
value: 2
- name: "NumCallsToFail"
value: 1
- name: "TakeMutex"
value: false
verification: |
Equivalent TH Client command to run `chip-tool faultinjection fail-at-fault 3 13 2 1 false 1 0`
On TH(all-clusters-app), Verify command is successfully:
CHIP:DMG: InvokeRequestMessage =
CHIP:DMG: {
CHIP:DMG: suppressResponse = false,
CHIP:DMG: timedRequest = false,
CHIP:DMG: InvokeRequests =
CHIP:DMG: [
CHIP:DMG: CommandDataIB =
CHIP:DMG: {
CHIP:DMG: CommandPathIB =
CHIP:DMG: {
CHIP:DMG: EndpointId = 0x0,
CHIP:DMG: ClusterId = 0xfff1fc06,
CHIP:DMG: CommandId = 0x0,
CHIP:DMG: },
CHIP:DMG:
CHIP:DMG: CommandFields =
CHIP:DMG: {
CHIP:DMG: 0x0 = 3,
CHIP:DMG: 0x1 = 13,
CHIP:DMG: 0x2 = 2,
CHIP:DMG: 0x3 = 1,
CHIP:DMG: 0x4 = false,
CHIP:DMG: },
CHIP:DMG: },
CHIP:DMG:
CHIP:DMG: ],
CHIP:DMG:
CHIP:DMG: InteractionModelRevision = 11
CHIP:DMG: },
CHIP:DMG: AccessControl: checking f=1 a=c s=0x000000000001B669 t= c=0xFFF1_FC06 e=0 p=m
CHIP:DMG: AccessControl: allowed
CHIP:DMG: Received command for Endpoint=0 Cluster=0xFFF1_FC06 Command=0x0000_0000
CHIP:ZCL: FaultInjection: Configure a fault of type: 3 and Id: 13 to be triggered deterministically <--------- Verify success with this message.
disabled: true
- label:
"Step 0 (Pre-Condition 5): TH Client send `FailAtFault` command to
`FaultInjection` cluster to TH device (Server)."
cluster: "FaultInjection"
command: "FailAtFault"
arguments:
values:
- name: "Type"
value: 3
- name: "Id"
value: 14
- name: "NumCallsToSkip"
value: 1
- name: "NumCallsToFail"
value: 1
- name: "TakeMutex"
value: false
verification: |
Equivalent TH Client command to run `chip-tool faultinjection fail-at-fault 3 14 1 1 false 1 0`
On TH(all-clusters-app), Verify command is successfully:
CHIP:DMG: InvokeRequestMessage =
CHIP:DMG: {
CHIP:DMG: suppressResponse = false,
CHIP:DMG: timedRequest = false,
CHIP:DMG: InvokeRequests =
CHIP:DMG: [
CHIP:DMG: CommandDataIB =
CHIP:DMG: {
CHIP:DMG: CommandPathIB =
CHIP:DMG: {
CHIP:DMG: EndpointId = 0x0,
CHIP:DMG: ClusterId = 0xfff1fc06,
CHIP:DMG: CommandId = 0x0,
CHIP:DMG: },
CHIP:DMG:
CHIP:DMG: CommandFields =
CHIP:DMG: {
CHIP:DMG: 0x0 = 3,
CHIP:DMG: 0x1 = 14,
CHIP:DMG: 0x2 = 1,
CHIP:DMG: 0x3 = 1,
CHIP:DMG: 0x4 = false,
CHIP:DMG: },
CHIP:DMG: },
CHIP:DMG:
CHIP:DMG: ],
CHIP:DMG:
CHIP:DMG: InteractionModelRevision = 11
CHIP:DMG: },
CHIP:DMG: AccessControl: checking f=1 a=c s=0x000000000001B669 t= c=0xFFF1_FC06 e=0 p=m
CHIP:DMG: AccessControl: allowed
CHIP:DMG: Received command for Endpoint=0 Cluster=0xFFF1_FC06 Command=0x0000_0000
CHIP:ZCL: FaultInjection: Configure a fault of type: 3 and Id: 14 to be triggered deterministically <--------- Verify success with this message.
disabled: true
- label: "Step 1: DUT sends the Invoke Request Message to the TH. The
Message should contain two valid and unique paths in the
CommandDataIBs, which has the specific Endpoints, specific Clusters
and specific Commands.
TH should be configured such that it responds to the batched commands
in a single InvokeResponseMessage, the ordering of CommandDataIBs in
the InvokeResponseMessage SHALL be in the same order as provided in
the request."
verification: |
Product maker needs to provide instructions for how to trigger the command on the DUT that is capable of fitting into a single InvokeResponseMessage. For comparison, the DUT behavior for this
test step can be simulated using chip-repl (when DUT is a commissioner/Client).
The cluster used in the below command is an example, User can use any supported chip cluster/attribute/command. Note in this example the unique path is created by using 2 different endpoints.
`await devCtrl.SendBatchCommands(0x12344321, [chip.clusters.Command.InvokeRequestInfo(1, chip.clusters.OnOff.Commands.Toggle()), chip.clusters.Command.InvokeRequestInfo(2, chip.clusters.OnOff.Commands.Toggle())])`
On TH(all-clusters-app), Verify that the EndpointIDs, CommandIDs, ClusterIDs in the InvokeRequestMessage (as below) matching with the data sent in the above command
CHIP:DMG: InvokeRequestMessage =
CHIP:DMG: {
CHIP:DMG: suppressResponse = false,
CHIP:DMG: timedRequest = true,
CHIP:DMG: InvokeRequests =
CHIP:DMG: [
CHIP:DMG: CommandDataIB =
CHIP:DMG: {
CHIP:DMG: CommandPathIB = <--------- Verifying everything in this struct matches what is provided by product maker
CHIP:DMG: {
CHIP:DMG: EndpointId = 0x1,
CHIP:DMG: ClusterId = 0x6,
CHIP:DMG: CommandId = 0x2,
CHIP:DMG: },
CHIP:DMG:
CHIP:DMG: CommandFields =
CHIP:DMG: {
CHIP:DMG: },
CHIP:DMG: Ref = 0x0,
CHIP:DMG: },
CHIP:DMG:
CHIP:DMG: CommandDataIB =
CHIP:DMG: {
CHIP:DMG: CommandPathIB = <--------- Verifying everything in this struct matches what is provided by product maker
CHIP:DMG: {
CHIP:DMG: EndpointId = 0x2,
CHIP:DMG: ClusterId = 0x6,
CHIP:DMG: CommandId = 0x2,
CHIP:DMG: },
CHIP:DMG:
CHIP:DMG: CommandFields =
CHIP:DMG: {
CHIP:DMG: },
CHIP:DMG: Ref = 0x1,
CHIP:DMG: },
CHIP:DMG:
CHIP:DMG: ],
CHIP:DMG:
CHIP:DMG: InteractionModelRevision = 11
CHIP:DMG: },
CHIP:DMG: AccessControl: checking f=1 a=c s=0x000000000001B669 t= c=0x0000_0006 e=1 p=o
CHIP:DMG: AccessControl: allowed
disabled: true
- label: "Step 2: DUT sends the Invoke Request Message to the TH. The
Message should contain two valid and unique paths in the
CommandDataIBs, which has the specific Endpoints, specific Clusters
and specific Commands.
TH should be configured such that it responds to the batched commands
over two InvokeResponseMessages. The first InvokeResponseMessage SHALL
contain a response to the first CommandDataIB in the
InvokeRequestMessage. The second InvokeReponseMessage SHALL contains a
response to the second CommandDataIB in the InvokeRequestMessage."
verification: |
Product maker needs to provide instructions for how to trigger the command this on the DUT that is capable of fitting into a single InvokeResponseMessage. For comparison, the DUT behavior for this
test step can be simulated using chip-repl (when DUT is a commissioner/Client).
The cluster used in the below command is an example, User can use any supported chip cluster/attribute/command. Note in this example the unique path is created by using 2 different endpoints.
`await devCtrl.SendBatchCommands(0x12344321, [chip.clusters.Command.InvokeRequestInfo(1, chip.clusters.OnOff.Commands.Toggle()), chip.clusters.Command.InvokeRequestInfo(2, chip.clusters.OnOff.Commands.Toggle())])`
* Verify DUT doesn't crash by seeing next step execute.
* On TH(all-clusters-app), Verify following logs are seen:
CHIP:DMG: Response to InvokeRequestMessage overridden by fault injection
CHIP:DMG: Injecting the following response:Each response will be sent in a separate InvokeResponseMessage. The order of responses will be the same as the original request.
disabled: true
- label: "Step 3: DUT sends the Invoke Request Message to the TH. The
Message should contain two valid and unique paths in the
CommandDataIBs, which has the specific Endpoints, specific Clusters
and specific Commands.
TH should be configured such that it responds to the batched commands
over two InvokeResponseMessages. The first InvokeResponseMessage SHALL
contain a response to the second CommandDataIB in the
InvokeRequestMessage. The second InvokeReponseMessage SHALL contains a
response to the first CommandDataIB in the InvokeRequestMessage."
verification: |
Product maker needs to provide instructions for how to trigger the command this on the DUT that is capable of fitting into a single InvokeResponseMessage. For comparison, the DUT behavior for this
test step can be simulated using chip-repl (when DUT is a commissioner/Client).
The cluster used in the below command is an example, User can use any supported chip cluster/attribute/command. Note in this example the unique path is created by using 2 different endpoints.
`await devCtrl.SendBatchCommands(0x12344321, [chip.clusters.Command.InvokeRequestInfo(1, chip.clusters.OnOff.Commands.Toggle()), chip.clusters.Command.InvokeRequestInfo(2, chip.clusters.OnOff.Commands.Toggle())])`
* Verify DUT doesn't crash by seeing next step execute.
* On TH(all-clusters-app), Verify following logs are seen:
CHIP:DMG: Response to InvokeRequestMessage overridden by fault injection
CHIP:DMG: Injecting the following response:Each response will be sent in a separate InvokeResponseMessage. The order of responses will be reversed from the original request.
disabled: true
- label: "Step 4: DUT sends the Invoke Request Message to the TH. The
Message should contain two valid and unique paths in the
CommandDataIBs, which has the specific Endpoints, specific Clusters
and specific Commands.
TH should be configured such that it responds incorrectly to the
batched commands in a single InvokeResponseMessages. The
InvokeResponseMessage SHALL contain a response to the first
CommandDataIB in the InvokeRequestMessage. The second response to
second CommandDataIB will intentionally be left out."
verification: |
Product maker needs to provide instructions for how to trigger the command this on the DUT that is capable of fitting into a single InvokeResponseMessage. For comparison, the DUT behavior for this
test step can be simulated using chip-repl (when DUT is a commissioner/Client).
The cluster used in the below command is an example, User can use any supported chip cluster/attribute/command. Note in this example the unique path is created by using 2 different endpoints.
`await devCtrl.SendBatchCommands(0x12344321, [chip.clusters.Command.InvokeRequestInfo(1, chip.clusters.OnOff.Commands.Toggle()), chip.clusters.Command.InvokeRequestInfo(2, chip.clusters.OnOff.Commands.Toggle())])`
* Verify DUT doesn't crash by seeing next step execute.
* On TH(all-clusters-app), Verify following logs are seen:
CHIP:DMG: Response to InvokeRequestMessage overridden by fault injection
CHIP:DMG: Injecting the following response:Single InvokeResponseMessages. Dropping response to second request
disabled: true
- label: "Step 5: DUT sends the Invoke Request Message to the TH. The
Message should contain one valid CommandDataIB, which has the specific
Endpoint, Specific Cluster and Specific Command.
TH should be configured such that it responds regularly to single
invoke request."
verification: |
Product maker needs to provide instructions for how to trigger the command this on the DUT that is capable of fitting into a single InvokeResponseMessage. For comparison, the DUT behavior for this
test step can be simulated using chip-repl (when DUT is a commissioner/Client).
The cluster used in the below command is an example, User can use any supported chip cluster/attribute/command. Note in this example the unique path is created by using 2 different endpoints.
`await devCtrl.SendCommand(0x12344321, 1, chip.clusters.OnOff.Commands.Toggle())`
On TH(all-clusters-app), Verify that we recieves an InvokeRequestMessage that contains a single InvokeRequests
CHIP:DMG: InvokeRequestMessage =
CHIP:DMG: {
CHIP:DMG: suppressResponse = false,
CHIP:DMG: timedRequest = true,
CHIP:DMG: InvokeRequests = <--------- Verify only one CommandDataIB in this structure
CHIP:DMG: [
CHIP:DMG: CommandDataIB =
CHIP:DMG: {
CHIP:DMG: CommandPathIB =
CHIP:DMG: {
CHIP:DMG: EndpointId = 0x1,
CHIP:DMG: ClusterId = 0x6,
CHIP:DMG: CommandId = 0x2,
CHIP:DMG: },
CHIP:DMG:
CHIP:DMG: CommandFields =
CHIP:DMG: {
CHIP:DMG: },
CHIP:DMG: Ref = 0x0,
CHIP:DMG: },
CHIP:DMG:
CHIP:DMG: ],
CHIP:DMG:
CHIP:DMG: InteractionModelRevision = 11
CHIP:DMG: },
CHIP:DMG: AccessControl: checking f=1 a=c s=0x000000000001B669 t= c=0x0000_0006 e=1 p=o
CHIP:DMG: AccessControl: allowed
disabled: true