About the Test Session Window

Use the Test Session window to manage all aspects of the test definition, the test operation, and the test results, and to monitor test operations.

Test Session window components:

The window is labeled with the session name if the session has been saved, and the Run ID (RID) if the session is executing.
Use the test session menu to work with logs and reports.
A session status bar displays the state of a test session during and after execution. The time remaining in the test is displayed if a test duration is defined. When Automation Control is used (shown in the example above), the status bar displays either the time remaining in the current step, or the condition on which the current step is dependent.
Use the session control buttons to manually control the test operation, save the test session, and close the window.
Use the Network Browser tab to browse available networks and create a test session..
Use the Session Builder tab to define the test duration and manage the test cases, and to monitor the progress of each test case during test operations.
Use the Automation Control tab to define and order the test events, and to monitor the progression of the steps during test operations.
Use the Pass/Fail tab to define the test criteria.
Use the Port Capture tab to configure PCAP Captures from within the test session.
Use the Reports tab to view test measurements.
Use the Favorites tab to view the customized test measurements.
Use the Logs tab to view the test logs.
Use the Graph tab to display measurements in a graph.
Use the Info tab to monitor and "live-view" individual UE States/Information.
Use the Data Tuning tab to be able to adjust (attach / detach) the number of sessions established (mobile or UE) during a running test.
Capture a snapshot of the window by pressing F9 to copy the snapshot to your clipboard. Save the snapshot with the Shift-F9 key combination.
Use the File option (click Test Session window > File>) to perform one of the following tasks:

Click to Close the test session.

Save As Tcl

You may save the Test Session displayed in the Test Session window as a Tcl file:

Press Shift+Alt+A or click File> Save as Tcl to display the Save Session as Tcl window.
Click the Save to File button to save as Tcl file.

Save As JSON

You may save the Test Session displayed in the Test Session window as a JSON file:

Press Shift+Alt+j or click File> Save as JSON to display the Save Session as JSON window.
Click the Save to File button to save as JSON file.

NOTE: The Abort after any TS recycles and Abort after all TSs recycle options are not available and greyed when a Test Session is running.

Use the Settings option (click Test Session window > Settings >) to perform one of the following tasks:

Remote Test, Auto TS Mode	Note : This option is no longer supported. Select to configure a limited (see limitations below) function single test server test session to be scheduled to run many times remotely on a test server, without the TAS sequencing the test sessions themselves. If the TAS and TS lose connectivity between each other, the tests will continue to run on schedule. When the connectivity is re-established, the TAS will catch up and retrieve the test results for any tests that completed while disconnected. You must enable this option in the "Test Server Configuration" - Enable "Remote Test/ Auto TS Mode". See additional details below - Remote Test, Auto TS Mode Additional details.
Use Gratuitous ARP	Select to send a G-ARP (Gratuitous ARP) or Neighbor Advertisement from emulated network device.
Do not delete temp files	Select to not delete the temporary files that are created on the TAS and Test Server during test session execution. Otherwise, the temporary files will be deleted (Default) after the test session stops.
Abort after any TS recycles	Indicates, the normal/default behavior, that the entire test session is aborted when any Test Server recycles.
Abort after all TSs recycle	Indicates that only the Test Cases associated with the recycled Test Server are ignored and the rest of the Test Case in the Test Session continues to run. Only useful when there are more than one Test Servers in the Test Session. When enabled, and a Test Server recycles, error, warning, and informational messages are logged in the Run Log to indicate the Test Servers that recycled, and the Test Cases affected. All Test Cases on the recycled Test Server are set to UNINITALIZED/VOID state, and are ignored for the rest of the test duration. (That is, for example, if the test expects a Test Case to be in a certain state, the TAS skips the check, and does not send any commands to the Test Case's recycled Test Server.) The TAS will release the Test Server lock on any recycled Test Server so that another test can be started using the now free resources, potentially even the partial set of Test Cases that were affected.
ETH initialization warning as info/logs	Select to have all sessions that do not complete to be reported as INFO Logs - Unchecked will report as WARNINGs In addition - See new options in Client Settings
Remote TS Control Messaging	Enabling this option will force the TAS to confirm each control message and to retransmit up to two more times to confirm it is received by the Test Server. This will slow down tests that may have run commands in parallel before, as the TAS will wait for each command to ACK before sending the next command, but it will nearly guarantee that each control command is received by the Test Server. When this checkbox is enabled and when a session is running, the TAS and TS will use reliable messages to communicate.
Set Auto-Delete Timeout	Automatically delete completed test sessions after a timeout period, defaulted to 24 hours. With tests started from our APIs, once a test session completes, the API user must manually delete the test session object from the TAS or else it will stay in memory. With this feature, the user can specify a timeout to do this automatically in case they forget to delete it. This timeout also applies to tests started from the GUI, that you leave connected in the Client. So when you run a test from the GUI that completes while you are connected to it, that test session is kept in memory on the TAS until you close the test session window, or now, until the timeout expires. Keeping a test session window open for longer than the timeout period, may cause you to no longer be able to query new charts or report intervals, as that is the primary purpose of keeping the completed tests in memory. The actual deletion of the test sessions is done anytime another test is started or completed, all expired tests are deleted. Therefore, at any given time, there might be up to 1 test session in memory that is past its delete timeout time (the last one to trigger the delete of all the rest). As always, ultimately the TAS will automatically delete completed test sessions when it runs out of Run IDs or memory, regardless of this feature. When the timeout is set to 0, the TAS will delete tests as they complete, and users would just have access to the test results on website. There would be no guaranteed way to use API to query to get results file list. One use case for this mode might be if you are starting tests from API for Visionworks, since results are automatically handled. For normal cases for APIs, maybe a timeout of a few minutes is reasonable, assuming the API just needs to query the final completed results once, and be done. Once the Test is deleted, the GUI will no longer be able to view the Report intervals, and you will get the “Test Session no longer available” error dialog:
Show Graphs 3-5 on Separate Tabs	Select to show Charts/Graphs 3 through 5 on separate tabs. This mode is saved with the test session and it can be switched on the fly. Example :
Delete PCAPs if Test Criteria State is not Failed	Flag to enable deleting PCAP files when criteriaStatus is not FAILED. Select to discard the PCAP and not to save it in TAS results if the test case PASS/FAIL criteria are all passed. Attribute "DeletePcapsWhenNotFailed' added to REST (Swagger) and Tcl API and reported in xls, csv, meas.db and .html reports.
Test All TC dependencies (Dev)	Development environment only!
Force reload of network browser	Select to force a reload of network browser.

Remote Test, Auto TS Mode :

Remote Test, Auto TS Mode - additional details

Note : This option is no longer supported.

Used to configure a limited (see limitations below) function single test server test session to be scheduled to run many times remotely on a test server, without the TAS sequencing the test sessions themselves. If the TAS and TS lose connectivity between each other, the tests will continue to run on schedule. When the connectivity is re-established the TAS will catch up and retrieve the test results for any tests that completed while disconnected. You must enable this option in the "Test Server Configuration" - Enable "Remote Test/ Auto TS Mode". Limitations:

One test server per test session
No automation control
Nothing reported live from the test session except indication that an iteration is running or not.
- No live Reports/Measurements, no Reports, Charts, Favorites, etc.
- No UE-Info Live reporting
- No live Run Logs from the test session, run logs will show higher level information about each iteration of the test session executed on the TS
- No commanding the test session
  - No Wait/Continues allowed
  - No CommandMode
  - No Updates (Manual Redirect)
  - No directly commanding the TCs
  - No ad-hoc generating per-session reports
  - No starting/stopping/retrieving PCAPs
  - No anything else I forgot that has to do with user sending commands to test
Single-process test session
- You can use Process Reservation, but it must be only 1 TS-process in the test.
No Pass/Fail Criteria
- End of test, UE-Info Pass/Fail Criteria may work. TBD.
Only use ACTS Port Captures.

What does work:

TS-Generated End of Test Results
- Per-Session Results
- UE-Info Report
VisionWorks output
Multiple test sessions per TS, but once the remote "scheduled" test is running on the TS it counts as a running test even if it is not actually running a test iteration
Port Reservation and/or Overridden Ports
- Once the remote test is running, no other test can be run using those ports
Multiple test cases in a test ( without Automation control )
All test cases and all test case configurations except for Command Mode test activities
- Sync Points in Test Case Command Sequencer won't work
- Anything that requires sync between Test Cases that the TAS would normally do will not work

Once you enable this option in the "Test Server Configuration" - Enable "Remote Test/ Auto TS Mode". and select Remote Test, Auto TS Mode in the Test Session:

When you select the "Schedule" tab, you will get a new screen where you can set the repeat schedule for the test:

Our example will execute every 10 minutes, starting as soon as we click Run, and the test will be "force stopped" at the 8 minute mark elapsed time.

Also see in upper right we have a Quicklist support for the schedule so you can easily copy it to another test session or keep schedule templates in your client.

As you run the test, it will be assigned RUN ID, like any other test, but then each test execution, i.e. iteration, will be given an iteration number.

Test results will be indicated with a RUN ID + Iteration ID.

The actual Run Log you see in the GUI will indicate information about how the TS is executing the tests and when the TAS is retrieving results:

log: 12/08 05:12:00.456:TAS: Received new Test Status Notification: Test_1_STARTED

log: 12/08 05:12:00.457:TAS: Switching to step Test_1_STARTED : Updating Test (test status)

test_progress: 100:#1: Test_1_STARTED

test_state:Test_1_STARTED:12/08 05:12:00.457:Test_1_STARTED

log: 12/08 05:12:00.498:TAS: Switching to step Test_1_VOID : Updating Test (via TS-Status)

test_progress: 100:#1: Test_1_VOID

test_state:Test_1_VOID:12/08 05:12:00.499:Test_1_VOID

warning: 12/08 05:12:29.617:ts0:p(0)7: WARNING: One or More Ethernet Ports not ready [ eth2 ]

log: 12/08 05:12:39.618:TAS: Switching to step Test_1_INITIALIZED : Updating Test (via TS-Status)

test_progress: 100:#1: Test_1_INITIALIZED

test_state:Test_1_INITIALIZED:12/08 05:12:39.618:Test_1_INITIALIZED

log: 12/08 05:14:07.063:TAS: Received new Test Status Notification: Test_1_COMPLETE

log: 12/08 05:14:07.063:TAS: Switching to step Test_1_COMPLETE : Updating Test (test status)

test_progress: 100:#1: Test_1_COMPLETE

test_state:Test_1_COMPLETE:12/08 05:14:07.063:Test_1_COMPLETE

warning: 12/08 05:14:09.376:TAS: New Test Iteration 1

log: 12/08 05:14:09.376:TAS: Switching to step WAITING : Updating Test (via TS-Status)

test_progress: 100:#2: WAITING

test_state:WAITING:12/08 05:14:09.376:WAITING

log: 12/08 05:14:09.379:TAS: Retrieving Results for Iteration 1

log: 12/08 05:14:09.379:TAS: First one: 1:2018-12-07__21-12-00

log: 12/08 05:14:09.381:TAS: Checking for Test Case Generated Reports for 1 iterations...

log: 12/08 05:14:09.381:TAS: Checking for files on ts0

log: 12/08 05:14:15.762:TAS: Transferring files from ts0

log: 12/08 05:14:15.770:TAS: Transferred file 18-12-08_05.12.00__RID-7-1__ts0_notify_log.txt.gz to results area

log: 12/08 05:14:17.772:TAS: TC Generated Reports should be available now.

log: 12/08 05:14:17.772:TAS: Results for Iteration 1 Completed

log: 12/08 05:16:00.452:TAS: Received new Test Status Notification: Test_2_STARTED

log: 12/08 05:16:00.453:TAS: Switching to step Test_2_STARTED : Updating Test (test status)

test_progress: 100:#2: Test_2_STARTED

test_state:Test_2_STARTED:12/08 05:16:00.453:Test_2_STARTED

End of test results might look like this:

The final log.txt file is the normal run log from TAS perspective for the entire remote test.

The individual test iterations are IDed with RID-<ID>-<ITERATION> prefix.

ts0_notify_log.txt.gz is a tarball of the Run Log from the actual test iteration run, i.e. what a normal test run log contains.

When you have other output files and VisionWorks Conversion files you will see them with an iteration indicator too:

You can see the info_report, per-session, and VisionWorks files for iteration 1 of RID 7.

When the TAS and TS lose communications, you will see a message in the Run Log, and when it re-establishes you will see another message and the TAS will attempt to retrieve any test results that are pending.

Learn how to: