Applications

Overview

Login Enterprise enables testing of Applications installed on Target Windows hosts, focusing on critical metrics such as Application launch times and the performance of specific actions. These Applications serve as Workload files that the Virtual Appliance Target Engine executes, simulating Virtual User interactions.

Multiple Application Workloads can be organized into collections called Application Groups, which are assigned to Test scenarios. This structure allows for comprehensive and structured testing, ensuring that various Application sequences are effectively evaluated during each Test run.

This section allows you to customize action scripts for applications and advanced system utilities. 

Adding a new Application

In the Login Enterprise sidebar menu, navigate to Configuration > Applications, and click the green "+" on the top right to add a new application.

mceclip0.png

Filling in the Application details

Complete the fields in the dialog to define your application.

Adding an application here will automatically configure an Application Start Timer.

Application Groups

Application Groups allow you to run multiple specified applications together. You can attach these created Application Groups to Continuous Tests, Load Tests, or Application Tests.

Adding an Application Group

In the Login Enterprise sidebar menu, navigate to Applications and find Application Groups.

In Application Groups, click the green "+" to create a new Application Group.

mceclip1.png

Give the application group a name and optionally a description.

mceclip1.png

Click Add actions and select either the applications you want or a wait.

mceclip0.png

Configuration: leave running and run once

There are two possible configuration options for Application behavior:

  • This can be configured at the Test level for single Tests.
  • This can also be set within Application Groups.

However, the configuration is not available for a single Application in the Application settings.

Effectively managing application behavior is essential for simulating real-world scenarios with accuracy. The "Leave Application Running" feature enables applications to remain active in the background between script executions, replicating user behavior where applications are left open rather than closed after use.

This feature does not apply to web scripts; it is only applicable to application scripts.

This article provides essential guidelines for leveraging the "Leave Application Running" option within your testing environment. Learn how to ensure precise application identification, optimize script configurations, handle multiple instances of the same application, and manage resource usage effectively. 

Run once

The "Run once" option is intended for executing tasks that are only required once, such as configuring registry keys or performing specific automation setups at the beginning of a test.

Load Test

In a Load Test scenario, you may attach multiple application scripts such as Excel and Word. For Excel, you can enable the "Run once" option, while Word follows its default behavior.

Frame 471.png

During user sessions, actions will initiate with Excel first, followed by a 10-second pause, then Word. This sequence repeats until the user logs off.

Continuous Test

In a Continuous Test, enabling "Run once" is effective only when "Repeat all steps above" is configured to 2 or higher.

Frame 472.png

If disabled or set to 1, "Run once" has no effect, as the default behavior runs everything once. When enabled with a setting of 2 or higher, in a continuous test setup with Excel set to "Run once" and Word set to default, the behavior is as follows:

Frame 473.png

The user logs on, runs Excel once, waits 10 seconds, runs Word, waits 10 seconds, runs Word again, and then logs off.

Application Test

In Application testing, there is no "Run once" option for applications. Application tests execute each application once and do not repeat.

Leave running

The "Leave Application Running" option ensures that the application specified in the configured application script continues to run in the background as Login Enterprise moves to the next application script. This behavior mimics real user interactions where applications are often left open rather than closed after use. This feature operates consistently across all use cases of Login Enterprise. Here are some important considerations for successful use:

Application title

Each command sent to an application within Login Enterprise scripts requires identification of the application. Typically, this identification is based on the application's title. When using "Leave Application Running," it is crucial that the title of the focused action within a script is as unique as possible. This prevents commands from being sent to the wrong application inadvertently open in the background.

Repeat cycle

In Continuous Testing, there is an option to repeat steps, while in load testing, all actions are repeated by default. When "Leave Application Running" is enabled for an application script, it may result in the same script (e.g., Excel) running multiple times without closing. Therefore, it's essential that the script is designed to handle subsequent runs seamlessly. For instance, if the first action in an Excel script is to open a file, ensure this action can be repeated at the script's end.

Process started vs process running

Sometimes, the process you start, e.g. "start.exe" differs from the process that is running, e.g. "App.exe". If an application is left running and the script is rerun, the script may attempt to start the initial process again, potentially causing unintended behavior.

Multiple Application scripts of the same app

When multiple application scripts use the same application and "Leave Application Running" is enabled, Login Enterprise may struggle to differentiate between application instances. For example, if a script starts Word and another script attempts to start Word again, the appliance may recognize that "word.exe" is already running and refrain from starting a new instance. Leaving multiple instances running concurrently can lead to unpredictable behavior. Consider launching the application using a specific file, e.g. starting Word using a Word document to manage instances effectively.

Resource usage

Leaving applications open consumes more resources during testing compared to closing them. Be mindful of resource utilization when opting to keep applications running after a script completes. Make sure you do not end up in a situation where you have 5 apps open that each take 25% of your memory.

Downloading and editing scripts

To edit a script, you need to download the script to a file, make the necessary updates, and then upload the modified file back to the Virtual Appliance.

  • After adding the application, download the script using the download button. This serves as a backup and allows you to edit the script to include new timers and application functions.
  • Use the edit function to reconfigure the application. You can also upload and download scripts from this interface.

Importing Application scripts

We've introduced a new workflow for adding applications and browser applications. The script now automates the application creation process in the Login Enterprise appliance, eliminating the need for manual details entry. This enhancement significantly simplifies the process of creating new applications.

In the Login Enterprise sidebar menu, navigate to Configuration > Applications.

In Applications, click the green "+" on the right, and then click Import Application.

1.png

After clicking Import Application and completing the process, you'll see a 'Validating...' pop-up message. This indicates that your script is undergoing validation.

2.png

When uploading a browser script, the system will automatically prefill the specific browser and, if available, the target URL.

3.png

You can also configure additional settings, such as:

4.png

And, optionally, Application credentials. For more information, see the Scripting secure Application credentials section.

5.png

Scripting secure Application credentials

Login Enterprise lets you configure encrypted passwords for Applications. This password is encrypted and saved in a variable to be used in the Application scripts. 

Configuring the credentials

1. In the Login Enterprise sidebar menu, navigate to Configuration> Applications.

2. To add the password, click on the pencil button on the right side of each application (The Application Properties window will open).

Frame 329.png

3. In Application Properties, expand the downward arrow next to Application Credentials (the Application Credentials menu will open).

Frame 330.png

4. Fill in the username and password that you want to use in your application script. Click Save to apply the settings. 

Frame 331.png

Using the credentials in an Application script

The credentials are transformed into a variable that can be used during scripting. There are two variables that you can use in the script:

  • ApplicationUser
  • ApplicationPassword

To use this, you can use the following command when you want to type it into a window. We assume that the user is called Login VSI and the password is Password!

Type(ApplicationUser,hideInLogging:true);
Type("{Enter}")
Type(ApplicationPassword,hideInLogging:true);

The result would be:

User

Password!

The option hideInLogging is best used when using passwords as this function hides it from logging so there is no potential security breach. 

Script Editor

The Login Enterprise Script Editor is a tool designed to assist administrators in creating custom application workflows. These workflows can be seamlessly incorporated into various testing scenarios, including Application, Load, and Continuous Tests. By leveraging the Script Editor, administrators can streamline test creation and execution, ensuring comprehensive and efficient testing processes tailored to specific application requirements.

  • For more details on the Script Editor, its benefits, use cases, and more, see the Script Editor.
  • The Script Editor comes with v1 of the Script Recorder, capable of recording WinApps. To learn more about the Script Recorder, see the Script Recorder.

Frame 320.png

While you may still prefer using Visual Studio Code (VSCode), the Login Enterprise Script Editor is designed to provide a more integrated and supported experience. Although you can still use VSCode for scripting, it is not officially supported, and continued functionality is not guaranteed. For those who wish to use VSCode, see Installing prerequisites for application scripting. However, we recommend using the Script Editor for the best results.

Editing in Visual Studio

  • Application scripts can be edited using Visual Studio. Ensure you have the necessary software:
    • Visual Studio with .NET Core support
    • Script Toolset for code snippets, example workflows, and syntax highlighting
  • Open Visual Studio and navigate to the extracted folder of the Script Toolset for customization. For detailed instructions, see the Applications and workload customizations.

Frame 319.png

Uploading scripts

After editing, upload the .CS script back to Login Enterprise.

Login Enterprise checks scripts for syntax errors before uploading. Error messages provide clues for debugging.

Login Enterprise script uploading will only support built-in scripting functions. For more information, see the Scripting functions

Additional resources

For troubleshooting Application failures, see Troubleshooting Application failures.