| Client and server perspective in testing [message #1739597] |
Wed, 03 August 2016 08:10 |
|
Dear all,
most of the time we are testing servers, and there's a good reason for it:
servers are large, complex and we need to know if their services are accessible
according to the interface specifications (conformance), availability expectations (performance ) etc.
(I will not try to scientifically define the notion of client and server here;
I will simply assume that the client is the party that initiates communication.
Being client or server is more a role than an immutable property: a node can act both as server and client,
and can change its behaviour over time, according to the circumstances.
Client and server can have different names depending on context; in some standards they are called requestor and responder;
in OneM2M for instance the are named AE-Application Entity, and CSE-Common Server Entity; but hey, don't get confused,
it's all the same old client and server we know.)
The setup for testing a server is quite straightforward:
+-----------------------------+ +----------------------------+
| | 1 | |
| +----------> |
| | | |
| Test System | 2 | SUT(Server) |
| <----------+ |
| | | |
| | | |
+-----------------------------+ +----------------------------+
The test system opens the dialogue with message 1, and expects message 2 in response within a certain amount of time.
(of course more complex dialogues are possible, but they all can be broken down into simple sequences as this).
If message 2 is received , verdict is set to pass.
If the timer expires, or a different message/content is received, verdict is set to fail.
The TTCN-3 code describing this behaviour will look something like this:
:
timer T.start;
messagePort.send(message1);
alt {
[] messagePort.receive(message2) {
setverdict(pass);
}
[] messagePort.receive {
setverdict(fail);
}
[] T.timeout {
setverdict(fail);
}
:
:
There are however scenarios when client behaviour is to be tested and this requires a different layout.
The main difference is that the test system will have to assume a more passive responder role and wait for the client to open communication.
One way to do this is to use a human operator that interacts with the client.
+--------------------------+
| |
| |
| |
| Operator <-------------------------+
| | |
| | |
| | |
+-----------+--------------+ |
| |
| |
|2 | 1
| |
| |
+------------v--------------+ +------------+------------+
| | | |
| | 3 | |
| +------------> |
| SUT(Client) | | Test System |
| <------------+ |
| | 4 | |
| | | |
+---------------------------+ +-------------------------+
The sequence of events looks like below:
1. The test system alerts the operator that a certain action is to be taken ("push the red button on the left" or "send me messageX" ).
2. The operator triggers the event in the client
3. The client sends message 3
4. If message 3 is received the test system sends message 4 in response and sets the verdict to pass;
else, if the timer expired or a different message was received, verdict is set to false.
The corresponding TTCN-3 code is something like:
:
timer T.start;
action("Operator, please make client to send message3!");
alt {
[] messagePort.receive(message3) {
messagePort.send(message3);
setverdict(pass);
}
[] messagePort.receive {
setverdict(fail);
}
[] T.timeout {
setverdict(fail);
}
:
:
So this is what the action statement is for. Now you know it, there can be no excuse.
Instead of the action statement, external functions can be used that alert the operator somehow( light a bulb, sound a buzzer, you name it)
:
timer T.start;
fx_soundAlarmToWakeUpOperator();
alt {
[] messagePort.receive(message3) {
messagePort.send(message3);
setverdict(pass);
}
[] messagePort.receive {
setverdict(fail);
}
[] T.timeout {
setverdict(fail);
}
:
:
OK , all is good , but this setup is pretty lame; the tests cannot be automated, and besides the human operator is slow, falls asleep, complains all the time that the job is boring.
So we need to replace him (sorry about that; you can still keep him as a tester to supervise the tests) with something automated.
And this something is called Upper Tester in ETSI terminology; there is a server side and a client side to it and consists of two pieces of code
that interact with the test system and the client respectively.
The two parts of the Upper Tester communicate over a channel separate from the client-server messaging.
UDP is usually good enough as transport so this channel is often over UDP.
+----------------------------+ +-----------------------------+
| | | |
| | | |
| | 2 | |
| Upper Tester-C <---------+ Upper Tester-S |
| | | |
| | | |
| | | |
+------------+---------------+ +-------------^---------------+
| |
| |
| 3 | 1
| |
| |
+------------v---------------+ +-------------+----------------+
| | | |
| | | |
| | 4 | |
| SUT(Client) +---------> Test System |
| | | |
| <---------+ |
| | 5 | |
+----------------------------+ +------------------------------+
Now , the sequence of events changes to:
1. The test system requests an action from the UT-S
2. The request is conveyed across to UT-C
3. The UT-C triggers the client action
4. Message 4 is sent to the server
5. If message 4 is rightly received the test system sends message 5 in response and sets the verdict to pass;
else, if the timer expired or a different message was received, verdict is set to false.
and the corresponding code to:
:
timer T.start;
UTPort.send("trigger message 4");
alt {
[] messagePort.receive(message4) {
messagePort.send(message5);
setverdict(pass);
}
[] messagePort.receive {
setverdict(fail);
}
[] T.timeout {
setverdict(fail);
}
:
:
It turns out that the fully automated solution of testing client behaviour is surprisingly complex compared to the server test scenario and it requires additional code, and possibly modifications to the client to accommodate the Upper Tester.
However , a step-by-step approach is always possible: implement the human operator setup first and then, when the UT code is ready, migrate to the automated setup.
Best regards
Elemer
|
|
|
Powered by
FUDForum. Page generated in 0.03151 seconds
] 
Search
Help
Register
Login
Home
