The user sequences cookbook is a collection of generalized recipes for common user sequence editing tasks. You can use these recipes as a guide for your own editing.
Changing a Protocol Field Value
Sometimes a message attribute or message field in the test suite will have a default value that does not suit your test target. You can change the default value in the user sequence.
In the following example, taken from the WebSocket Server test suite, we have a
string value in the payload field. The WebSocket protocol
specification does not specify that the payload field should have a particular
string value for a ping message, so we can modify that field's default value. If we
open the Websocket ping sequence in the sequence editor, we can see that the
payload field has a default value of
'ping':
<send name="ping-frame" type="control-frame" description="Ping Frame">
<store field="*.FIN">0b1</store>
<store field="*.opcode.ping"/>
<store field="*.payload">'ping'</store>
</send>
We can change that default value to something different:
<send name="ping-frame" type="control-frame" description="Ping Frame">
<store field="*.FIN">0b1</store>
<store field="*.opcode.ping"/>
<store field="*.payload">'Is this a machine that goes "ping!"?'</store>
</send>
When redefining a protocol field value, it is important to use the same format syntax as in the original message. For further details, refer to the protocol field value formats section.
Storing and Retrieving Protocol Field Values
Oftentimes a protocol field value in an outgoing message will be expected to be present in a subsequent message. You can check for the expected value by storing it from the outgoing message and then checking for it in a later message.
To store the value, in the outgoing <send> block you assign a
target message attribute or message field and accompanying value in a
<store> element block:
<send name="request-invite" type="sip-message"
description="INVITE request" >
<content file="sip-invite-0.txx" format="text"/>
. . .
<!-- Storing the CSeq number, using a rule -->
<store attribute="cseq">$cseq-number</store>
. . .
</send>
Later in the sequence, you can match the stored value in another message:
<recv name="request-cancel-valid" type="sip-message"
description="CANCEL request" anomalize="false">
<content file="sip-cancel-0.txx" format="text"/>
. . .
<!-- Checking the CSeq number from the `request-invite` message -->
<match attribute="cseq">$request-invite:cseq</match>
</recv>
There are a number of ways to obtain and cite values for message attribute and message fields. For further details, refer to the storing data from outgoing messages section.
Changing a Setting Value
In this example, we have some basic TCP settings:
<sequence name="sequence-tcp" role="client">
<setting arg="--port">80</setting>
<setting arg="--host">192.168.56.250</setting>
<setting arg="--local-port">55183</setting>
. . .
</sequence>
<setting>:<sequence name="sequence-tcp" role="client">
<!-- Same message, with port value changed -->
<setting arg="--port">8080</setting>
. . .
</sequence>