-
Notifications
You must be signed in to change notification settings - Fork 314
/
Copy pathsample_test_hrm.xml
275 lines (228 loc) · 16.4 KB
/
sample_test_hrm.xml
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
<?xml version="1.0" encoding="UTF-8"?>
<!--~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~ Copyright (c) 2016, Nordic Semiconductor
~ All rights reserved.
~
~ Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:
~
~ 1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.
~
~ 2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the
~ documentation and/or other materials provided with the distribution.
~
~ 3. Neither the name of the copyright holder nor the names of its contributors may be used to endorse or promote products derived from this
~ software without specific prior written permission.
~
~ THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
~ LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
~ HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
~ LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON
~ ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE
~ USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~-->
<!--
Automated test script example and documentation.
This script is an example of a test suite definition which can be parsed and performed by nRF Connect application.
nRF Connect may be used in automated tests for Bluetooth Smart devices.
Should you have any comments or suggestions, please write us on [email protected].
-->
<!-- Test-Suite element defines the test suite. It MAY have a 'description' attribute. All descriptions in the script are used when creating a result file. -->
<test-suite description="Very important test">
<!--
Tests MAY be parametrized. To define a variable use the 'set' element.
You may also inject variables from the command line with -E KEY VALUE, e.g. 'test -E EXTRA_ADDRESS 00:11:22:33:44:55 example.xml'.
-->
<set name="DESC_NAME" value="[global] CCCD" />
<set name="CCCD_UUID" value="00002902-0000-1000-8000-00805f9b34fb" />
<set name="HRM_SERVICE_UUID" value="0000180D-0000-1000-8000-00805f9b34fb" />
<set name="HR_MEASUREMENT_CHAR_UUID" value="00002A37-0000-1000-8000-00805f9b34fb" />
<set name="BODY_SENSOR_LOCATION_CHAR_UUID" value="00002A38-0000-1000-8000-00805f9b34fb" />
<!-- The following file and a matching init file will be sent using 'dfu' operation. -->
<set name="FIRMWARE_PATH" value="/Nordic Semiconductor/Board/pca10028/ble_app_hrm_dfu_s110_v8_0_0_sdk_v9_0.zip" />
<!--
Define devices to test. A Target MAY have a 'name' attribute with a user friendly name and MAY have the 'address' definition with the Bluetooth Smart device address. Use 'scan-for' operation to bind a target that doesn't have the address with a scanned device.
Since version 4.3 specifying target is not required as 'scan' operation does need such.
-->
<target id="devkit" name="Dev Kit" address="${EXTRA_ADDRESS}" />
<!--
Define tests. Test MUST contain at least one operation elements. Each operation will be performed in order from top to bottom and a result will be logged in the output file.
Each test and operation MAY have a 'description' attribute and a target reference. A target MAY be specified for the test (as a default one for every included operation) and
for each operation inside, so you may connect to more than one device in a single test.
All operations in the test, except 'assert-service' (and its children) and 'dfu' may have a timeout specified using 'timeout' attribute (in milliseconds).
The default timeout is 5000 milliseconds.
-->
<test id="basics" description="Check basic connectivity of ${EXTRA_ADDRESS}" target="devkit">
<!--
First let's connect to the device. The 'description' attribute has been omitted. The tag name will be used as the description.
By setting the 'timeout' attribute to 4000 ms we ensure that the connection attempt will take no longer than that.
The 'connect' operation is followed by 1 second break to give Android some time before the next operation.
-->
<connect timeout="4000" />
<!--
Before we discover services let's make sure that the cache is clear. The services might have changed on the device. The 'refresh' operation must be called after the
device has been connected at least once (a BluetoothGatt object has been created using connectGatt(...) method).
Actually there is not need to refresh services in this sample as the 'dfu' operation in the DFU Test (check the next test definition), which is being run prior to this,
does it automatically when completed.
The 'refresh' operation is followed by 1 second break to give Android some time before the next operation as it will cause the Android-internal service discovery.
-->
<refresh />
<!--
In order to read or write something we have to discover available services.
The 'target' is set, but as it is the same as for the test, it could have been omitted.
The 'description' has not been specified and therefore it's set to a default value - "Discover-Services".
-->
<discover-services target="devkit" timeout="10000" />
<!-- Check if device has specified service. Instance id MAY be specified using instance-id="n". The default instance id value is 0. -->
<assert-service description="Check if HRM Service exists" uuid="${HRM_SERVICE_UUID}" instance-id="0">
<!-- The service should have the following characteristics. -->
<assert-characteristic description="Check Heart Rate Measurement characteristic" uuid="00002A37-0000-1000-8000-00805f9b34fb" instance-id="0" >
<!-- Let's check if the characteristic has required properties. Requirement="MANDATORY" is default and MAY be skipped. -->
<property name="NOTIFY" requirement="MANDATORY" />
<!-- It may also have some other properties (this section may be skipped as this is does not do any checking -->
<property name="READ" requirement="OPTIONAL" />
<!-- But for sure it must not have those properties -->
<property name="WRITE" requirement="EXCLUDED" />
<property name="WRITE_WITHOUT_RESPONSE" requirement="EXCLUDED" />
<!--
Property name is case-sensitive and must be one of the following:
- BROADCAST
- READ
- WRITE
- WRITE_WITHOUT_RESPONSE
- NOTIFY
- INDICATE
- SIGNED_WRITE
- EXTENDED_PROPERTIES
Requirement name is also case-sensitive and must be one of the following:
- MANDATORY (default)
- OPTIONAL
- EXCLUDED
-->
<property name="SIGNED_WRITE" requirement="EXCLUDED" />
<!-- This characteristic should have the CCCD descriptor. Attribute 'instance-id' is optional -->
<assert-descriptor description="Checking ${DESC_NAME} descriptor" uuid="${CCCD_UUID}" />
<!-- We may also check if the characteristic has Client Characteristic Configuration with assert-cccd command -->
<assert-cccd description="Another way of checking only the CCCD">
<!-- And even check the value of any descriptor, including the CCCD -->
<assert-value description="Check if notifications are disabled by default" value="0000" />
</assert-cccd>
<!--
The following descriptor should not be in this characteristic.
An 'expected' attribute may be set to all operations (except 'property' and 'sleep') to specify the expected result.
Expected result may be one of the following:
- SUCCESS - success is required to go on (default)
- SUCCESS_WARNING_ON_FAIL - a warning will be logged in the result file but the test will continue
- FAIL - a fail is required to proceed
- FAIL_WARNING_ON_SUCCESS - a fail is expected but in case of a success a warning will be logged to the result file.
-->
<assert-descriptor description="This descriptor should not be found" uuid="00002906-0000-1000-8000-00805f9b34fb" expected="FAIL" />
</assert-characteristic>
<!-- Another required characteristic. Like in assert-service the instance-id does not have to be specified if equal to 0 -->
<assert-characteristic description="Check Body Sensor Location characteristic" uuid="${BODY_SENSOR_LOCATION_CHAR_UUID}">
<!-- Read property is required. We don't care about the others -->
<property name="READ" />
<!-- Additionally we may assert the characteristic value. Here, as we have not read it yet, it will be null. -->
<assert-value description="Characteristic should have no value here" value="" />
</assert-characteristic>
</assert-service>
<!-- Read a value from characteristic. Attributes: 'service-instance-id' and 'characteristic-instance-id' are optional. -->
<read description="Read sensor location" service-uuid="${HRM_SERVICE_UUID}" service-instance-id="0" characteristic-uuid="${BODY_SENSOR_LOCATION_CHAR_UUID}" characteristic-instance-id="0">
<!-- Check if the value is what we expect to be . A value may be given in bytes using 'value' attribute or as string using 'value-string'-->
<assert-value description="Check if location equals FINGER" value="03" />
</read>
<!-- We may want to check whether the device name is equal to Some name. If not, a warning will be logged. -->
<read description="Read the device name" service-uuid="00001800-0000-1000-8000-00805f9b34fb" characteristic-uuid="00002A00-0000-1000-8000-00805f9b34fb">
<!-- Check if the value is equal to some name -->
<assert-value description="Check the name" value-string="Some name" expected="SUCCESS_WARNING_ON_FAIL" />
</read>
<!-- The script may also try to bond to the target. Bonding may take more time on several devices as full service discovery may be performed.-->
<bond timeout="10000" />
<!--
Try to write a new value to a characteristic with WRITE REQUEST (default).
Type is case-sensitive and must be one of the following:
- WRITE_REQUEST (default)
- WRITE_COMMAND
The - WRITE_SIGNED is currently not supported. // TODO
-->
<write description="Write a name" type="WRITE_REQUEST" service-uuid="00001800-0000-1000-8000-00805f9b34fb" characteristic-uuid="00002A00-0000-1000-8000-00805f9b34fb" value-string="New name" />
<!-- Read a value from the same characteristic -->
<read description="Read the new name" service-uuid="00001800-0000-1000-8000-00805f9b34fb" characteristic-uuid="00002A00-0000-1000-8000-00805f9b34fb">
<!-- Check if the value is equal to what we have written -->
<assert-value description="Check the new value" value-string="New name" />
</read>
<!--
We may enable notification by writing to the CCC descriptor.
Attributes: 'service-instance-id', 'characteristic-instance-id' or 'descriptor-instance-id' are optional.
-->
<write-descriptor description="Enable notifications" uuid="${CCCD_UUID}" service-uuid="${HRM_SERVICE_UUID}" characteristic-uuid="${HR_MEASUREMENT_CHAR_UUID}" value="0100" />
<!-- Read a value from characteristic. Attributes: 'service-instance-id', 'characteristic-instance-id' or 'descriptor-instance-id' are optional. -->
<read-descriptor description="Read descriptor value" uuid="${CCCD_UUID}" service-uuid="${HRM_SERVICE_UUID}" characteristic-uuid="${HR_MEASUREMENT_CHAR_UUID}">
<!-- Check if the value is what we expect to be -->
<assert-value description="Check if notifications are enabled" value="0100" />
</read-descriptor>
<!-- Check if the notifications or indications(!) are being sent. This tag wait up to 2000ms for incoming notification or indication. It may also assert its value. -->
<assert-notification description="Check the first notification" service-uuid="${HRM_SERVICE_UUID}" characteristic-uuid="${HR_MEASUREMENT_CHAR_UUID}" timeout="2000">
<!--
Before the notification will be received you may want to send or read a characteristic or descriptor.
By doing it here you ensure that the notification listener will be initiated before sending the value, as the reply may be too fast.
If the 'write' operation was executed before calling the 'assert-notification', the notification could have been
received before this operation was started and thous the test could fail.
The following operations may be called here: write, write-descriptor, read, read-descriptor.
Example:
-->
<!--<write description="Write notification trigger" service-uuid="some UUID" characteristic-uuid="some other UUID" value="012345" />-->
<!-- We can assert the correct notification value -->
<!-- NOTE: This tag has expected result SUCCESS_WARNING_ON_FAIL because the notifications, in our HRM sample, are randomly generated -->
<assert-value description="200 BPM, Contact detected, RR intervals" value="16C87200730074007500" expected="SUCCESS_WARNING_ON_FAIL" />
</assert-notification>
<!-- The value of the second notification/indication is irrelevant -->
<assert-notification description="Check the second notification, with any value" service-uuid="${HRM_SERVICE_UUID}" characteristic-uuid="${HR_MEASUREMENT_CHAR_UUID}" />
<!-- Disconnect from the device. This element MAY be omitted at the end of the test as every device is automatically disconnected here. -->
<disconnect />
<!-- We may want to remove the pairing after operation is complete. Unbonding will also disconnect the device, if it's connected. -->
<!--
This operation is not necessary as we will remove the bond information it in a separate test in case one of the operations above failed and aborted the test before.
-->
<!-- <unbond /> -->
</test>
<!-- The nRF Connect may also perform the DFU operation. Let's create a test that will upload a HRM firmware to the device. -->
<test id="dfu" description="DFU Test">
<!--
In order to send a firmware using DFU a device should be disconnected, as the DFU service will connect by it own.
You may upload an application, bootloader, soft device or multiple files. Use 'type=X' attribute where X may be one of the following:
* 1 - for soft device
* 2 - for bootloader
* 4 - for application
* 0 - for auto (all files from ZIP or an application in case the HEX file is used) (default)
Use the 'initFile' attribute to specify the path to the init file in case it's required (SDK 7+) and you are not using the Distribution Packets (ZIP).
-->
<dfu description="DFU operation" file="${FIRMWARE_PATH}" target="devkit" />
<!--
There is always a 2 second break after the last operation of a test before the service starts to clear the resources. The break is required for some operations to complete,
e.g. bonding. If 'bond' tag would be the last one, the service would bond and immediately started to disconnect what causes the Android to hang.
However, a custom break may ba added anywhere in the test. The default timeout is 5000ms but may be set just like for other commands, f.e. <sleep timeout="10000" />.
For example. in case of
<connect />
<bond />
<disconnect />
a 'sleep' may be required before 'disconnect' to make it work.
-->
<sleep />
</test>
<test id="unbond" description="Remove the bond information">
<!-- As this is a new test, this operation will be executed no matter if the basic test succeeded or not. -->
<unbond target="devkit" />
</test>
<!--
At last we provide test cases to be performed. Each may overwrite 'set' parameters.
To be able to perform basic tests on Heart Rate Monitor we must first use the DFU to send HRM firmware onto the device.
The DFU operation might have been specified as a part of basic test but here we have defined a designated test only for DFU testing.
-->
<run-test ref="dfu" description="Upload HRM onto the Dev Kit" />
<!-- Start basic tests. We may overwrite the global variable here. -->
<run-test ref="basics" description="Basic tests for HRM">
<!-- Parameters may be given for a single test also, Overwriting global one -->
<set name="DESC_NAME" value="[local] CCCD" />
</run-test>
<run-test ref="unbond" description="Clean up" />
</test-suite>