Skip to main content

Advanced Group Test Topics

The following are recommendations to make your Group Tests more successful. You can do things such as hold your connection information in one file, stagger your Worker starts, have a policy that starts or stops your test, and log how long certain activities took.

Environment.feature​

To make things easier to change server connection strings you can store all of your connection and login information in one Feature File. Then you can import this Feature File in each one of your Group’s Feature Files. This allows each one of the Workers to use the same Terminal Login Scenario as well as verify you only need to change things in one place if you need to use them multiple times.

Staggered start​

In order to support a large number of Workers you must stagger the start of the emulators. You can perform this task within Cycle by adding an “rf_wait_time” variable to your CSV files. You can increase this value by X for every Worker.

  • How To: In your Feature File you can say “I wait $rf_wait_time ms” and each Worker would wait the set amount of seconds and would stagger the login.

Policy to start and stop Feature File​

In order to support a large number of Workers starting and stopping work at the same time, you can use a database record to determine if the entire test should start or end.

These entries are useful to gracefully end a process by allowing the current activity to complete and prevent incomplete processes.

  • With your Feature File in a loop, you can check if the start flag has been set, if so, jump into the loop.
  • With your Feature File in a loop, you can check the end flag at the end of every loop. If that is set, jump out of the loop and end the test.

Logging of start and stop timestamps per activity​

Since you can run sql statements from within Cycle, you can create your own custom logging Scenarios to track the time elapsed for each activity.

  • At the beginning of each loop, insert a record into a table with a distinct activity code and transaction id with the sysdate as the start date.
  • At the end of the loop, you can update that record, using the transaction id, to set the end date as the current sysdate.

This allows you to create custom reporting to track how long each activity was taking as the test progressed

You can use the same Feature File for both single terminal mode and Group Test mode.

The best way to go about this is to use the logic below for each variable that you define in your csvs. This will check to see if the variable is defined; if so it will use it (Group Test). If it is not defined, you define it there (single terminal test).

If I verify variable "devcod" is assigned Then I echo $devcod Else I assign value "CYCLE001" to unassigned variable "devcod"

Recommendations for Group Testing​

  • Create all new devices (locmst, rf_term_mst, devmst, rftmst)
  • Create a user for each device code
    • Can cause issues when receiving if multiple people are logged in as the same user
  • Name your device codes and users the same (i.e., CYCLE001)