Troubleshooting Scripts

Using TrueLog Explorer

Test runs often fail due to the appearance of unexpected dialogs, causing scripts to lose focus on the windows they are working on. It is therefore recommended that you enable the TrueLog On Error feature in Silk Performer before you execute tests. Then, if an error occurs, you will be able to visually track it down in TrueLog Explorer.

Clearing Terminal Server Sessions

After a failed test execution, ensure that you reset all terminal server sessions before you execute the test again, otherwise your script will likely fail.

Handling Application Errors

During tests, your application is likely to throw errors due to generated load. Adding event handlers to your script that can handle and report such errors is very helpful.

Here is an example of an event handler that continuously watches for a window with the name Program Error Intercepted and executes an ALT-C to close any such window that appears. The event handler also generates an error message whenever such an error occurs.

dclevent 
  handler Handler1 <EVENT_CITRIXINTERRUPT>
  var
    nInterrupt, nWindow : number;
    nStyle              : number;
    sWindowCaption      : string;
    begin
      CitrixGetActInterrupt(nInterrupt, nWindow);
      ErrorAdd(FACILITY_CITRIXENGINE, 47, SEVERITY_INFORMATIONAL);
      print(string(nWindow));
      CitrixGetWindowCaption(nWindow, sWindowCaption);
      if sWindowCaption = "Program Error Intercepted" then
        CitrixKey(67, MOD_Alt); // 'c'        
      end;
      ErrorRemove(FACILITY_CITRIXENGINE, 47);
    end Handler1;

Avoiding Think Times

While it may be tempting to use Wait() or ThinkTime statements to avoid having scripts overrun applications under test, this practice is not recommended for two reasons:

• When load generation increases, application processing speed may slow considerably. The wait statement may eventually be too short and the problem of overrunning the application will again present itself.
• If you are measuring the response times of window, text, or screen synchronizations, the time in the Wait() statement will artificially bloat response times.

The solution is to use synchronizations.

Re-recording Portions of a Script

Sometimes changes in application behavior result in portions of a recorded script becoming obsolete. Re-recording a portion of a use case is an option, but beware that the recorder may not be able to track the handles of the existing windows, resulting in incorrect window handle numbers. These issues can make the process of integrating newly recorded script with an original script quite tedious. When a use case is small, it is recommended that you re-record the entire use case. Otherwise, follow the process outlined below to integrate a new script with an outdated script:

1. Comment out the section of code that is to be re-recorded.
2. Match the location of the code section requiring replacement with the corresponding section in the use case.
3. Bring a terminal services session up to the corresponding point in the use case.
4. Begin recording the open terminal services session.
5. Perform the actions of the use case that require replacement.
6. Stop the recorder (a script from the recording is then produced).
7. Replace the window handle variables in the newly recorded script with the respective handles of the original script. You may use functions such as CitrixSearchWindow() to locate correct window handles.
8. Copy the edited code into the original script.