Use the Command Mode test activity when you want total control of session activity. With the Command Mode test activity, you can run a test in a totally manual mode by controlling the test sessions via the On Demand Commands. The Command Mode test activity is available in several test cases - see full list in Command Mode Test Activity topic.
The Command Mode test activity (when executed) assigns the test servers and initializes the resources required for the test and waits for you to manually control the test via the Command button (for example, define session activation rate to establish test sessions).
|
NOTE: When configuring a Command Mode test activity, the activation/deactivation rates are not available (on the Mobile Subscribers tab) as you control these manually via the On Demand Commands available when the tests are running. |
After you specify the command operation and the rate, the test begins establishing sessions at the activation rate you define. The test system continues to establish sessions until the number of sessions you selected has been reached or until you stop the test.
The test system keeps the sessions active for the duration of the test session, or until the test is stopped manually or with Automation Control, and then begins deactivating the sessions at your defined deactivation rate.
When sending commands to a running Test Session that ultimately ends up going through to the Test Server, it is possible that you may need to retry that command due to 3 possible reasons. The types of commands this applies to includes ODCs (execute procedures), Updates (parameter changes), TC Commands (init/start/stop/cleanup), UE Info Query (from GUI only). See this diagram.
The three command errors that indicate a retry should be attempted:
#1. TS is busy handling another command --> Each TS-Process can only support one blocking-for-response command at a time, instead of BLOCKING for X seconds, we respond to the caller immediately and let them decide when to retry.
#2. ERROR: Last command have not finished yet!!! --> The Test Case single control thread for ODCs is currently busy executing previous command, instead of queuing up this request we respond to the caller immediately and let them decide when to retry.
#3. UDP Command Timed Out --> RE: Network issues or TS temporarily unresponsive.
#4. TS recycled --> This can occur if the TS is recycling, and TAS knows it is waiting for Registration and/or the first READY Status
#5. TS IP Address not established --> This can occur if the DHCP mode TS is not resolved/registered yet
When using Automation, look for these error strings as the cue for standard retry logic. A simple wrapper function that ultimately sends the request to the TAS can handle the responses and look for these errors and decide when to retry and how many times to retry, etc...This design gives users the most control. The callers, i.e. the automation, designers of the automation, must make their own choices with how to deal with contention on TS being used by multiple users or for multiple purposes. If you run multiple tests on same TS-Process (i.e. vTS), the command execution must be shared.
|
NOTE: Setting Up Command Mode Tests The Command Mode test activity allows configuration of all the available test options for the test case. The only requirements for a successful Test are that the emulators used in the test can communicate with the SUT, and that the control protocol parameters are configured in a manner that is compatible with the SUT. |