All of the scripts invoke the service using the configured maximum, expect success.

After that, the call is repeated for maximum + 1 operations, expecting different results, depending on the script. Some expect BadOutOfRange, others BadTooManyOperations or BadEncodingLimitsExceeded and some combinations of those.

1.
This needs to be consistent for all those scripts. BadEncodingLimitsExceeded should be accepted in all cases, as this is a common service result code which might be returned by the communication stack if limits are exceeded.

2.
For protecting against malicious clients, some server implementations might return an error message (see part 6, 7.1.2.5) containing BadEncodingLimitsExceeded instead of a ServiceFault with the status. In the CTT implementation of the services, the status of the error message is returned by the session.<service>() call and stored in the this.UaStatus variable. This is only checked for Good/Bad and an error is thrown if Bad. Instead, this.UaStatus should be matched against the ExpectedAndAcceptedResults and no error should be thrown on match.

3.
If a server sends an error message, it will close the TransportConnection to the client. After that, no service calls are possible anymore on the used SecureChannel. This has to be considered in the test scripts.