Installation and configuration best practices

This section details best practices for installation and configuration

OpenText Functional Testing Lab can be installed as a full installation (where there is no previous installation) or as an upgrade on top of an existing installation. The installer checks which files are already installed and installs or updates the relevant files.

General deployment considerations

A distributed architecture is supported, in which different test clients can interact with the same server instance.

OpenText Functional Testing Lab deployment has several components.

Component	Function
Server	This is a single web server that can be installed on a physical or virtual environment. It serves to: Mediate between the testing-tool client calls to mobile devices and provide a user interface within the testing tool for recording and running tests on real mobile devices. Accept apps for testing and manage app versions. Provide a user interface (Lab Management console) for administrators to: Manage users. Manage apps and view their properties such as OS and version. Control devices: restart, unlock or open a device remotely. View and manage connectors. Configure settings for users such as proxy definitions and packaging services. Enable extended services such as security scans, production usage, crowd testing, and SDK compliance. Note: When you install the server, you have the option to install an embedded connector if you want to connect devices directly to the OpenText Functional Testing Lab server instance
PostgreSQL database	You can choose either to connect OpenText Functional Testing Lab to an existing external PostgreSQL database, or use the database that is embedded in the server installation. You specify this option during installation. For details, see Windows Installation or Linux Installation.
Connector	The connector is designed as a lightweight piece of software for connecting devices to the lab and can be installed as a standalone component. You can install the connector on multiple machines in distributed locations, or on your testing-tool machine. The connector can be installed on a Windows, Linux, or Mac machine. The connector is designed as a lightweight piece of software for connecting devices to the lab and can be installed as a standalone component. You can install the connector on multiple machines in distributed locations, or on your testing-tool machine. The connector can be installed on a Windows, Linux, or Mac machine
High Availability	You can configure high availability in an active-passive configuration using multiple servers. In this mode, there is one active OpenText Functional Testing Lab server, to which the load balancer routes all the requests, and another passive server ready to take over in case the active server fails. For details, see High Availability support .
File Storage System	Applications are no longer stored in the database but are saved to the file system. When installing or upgrading, you can select a destination folder for storing applications uploaded to OpenText Functional Testing Lab. You can also control the number of uploads per application and choose to automatically delete old uploads of an application. This makes it easier for the administrator to manage the number of application uploads that need to be maintained and reduces the load on the file storage system. For details, see the section on configuring application file storage in Windows Installation and the section Limit application uploads under General Administration settings.

Deployment scenarios

The decision point for the OpenText Functional Testing Labdeployment scenario varies according to customer requirements.

Scenario	Description	Advantages
All-in-one	Single box deployment for OpenText Functional Testing Lab server, database, and embedded connector.	Simplicity. Ideal for proof of concept and local installations.
3-Tier deployment	Separate web and data layers by installing OpenText Functional Testing Lab server and databases on different locations.	Scalability of web and database layers. Supports local IT best practices for web and database management.

For the deployment of connectors/devices, the following scenarios can be considered.

Scenario	Description	Advantages
Central device hub	A central lab of devices connected to the connector on the OpenText Functional Testing Lab server machine.	Efficiency. Avoids duplication of tasks for setting up and managing devices
Distributed device hubs	Connectors installed on machines in multiple locations (on-site/offsite/globally dispersed).	Scalable. New labs can be added as needed.
Bring your own device	Connector installed on a developer's/testing engineer's machine.	Supports hands-on testing of the app on the device.

Hardware requirements

The full list of hardware requirements is available in the Support matrix.

When planning hardware resources, consider the following parameters.

Component	Memory	CPU	Disk Space
Server	The OpenText Functional Testing Lab server is a Java application. Therefore, it uses a predefined amount of host memory. The amount of consumed memory is impacted by the number of simulation sessions (user sessions). The minimal memory requirement is 8 GB. We recommend 8 GB for medium deployment (<30 devices), and 16 GB for large deployment (>30 devices). * Based on your machine memory we recommend you increase the maximum heap size for the Java virtual machine (JVM) when installing, upgrading, or modifying the server for example: if the machine had 8 GB you can increase the Java heap size to 4GB.	Server CPU consumption is dependent on the number of requests that are processed. The minimal requirement is an x64 processor, 2.2 GHz	Disk space usage on the server depends on several factors such as logs generated, packaged applications, and processes. We recommend at least 20 GB: 15 GB for general installation and 5 GB for the temporary folder. Please note that in versions 3.5 and above, you can specify a temporary folder different than TMP/TEMP. An additional 1 GB of free disk space is required on the system disk.
PostgreSQL DB	PostgreSQL memory consumption is impacted by SQL queries that it is required to execute. The minimal requirement for memory is 2 GB. We strongly recommend at least 8 GB for medium deployment (<30 devices), and 16 GB for large deployment (>30 devices).	PostgreSQL is process-based. The minimal requirement is a dual-core CPU, 2.2 GHz.	Disk space usage on PostgreSQL depends on the data size. On Windows, PostgreSQL is installed on the C: drive, so disk space must be allocated there.
Connector	The OpenText Functional Testing Lab connector is a Java application. Hence, it uses a predefined amount of host memory. The amount of consumed memory is impacted by the number of simulated sessions (user sessions). The minimal requirement is 4 GB. * We recommend at least 8 GB for standard deployments (8-10 devices per connector), and 16 GB for large deployments (12-25 devices).	The guidelines for the connector are the same as for the server. Remote access to the device increases the CPU consumption and must be considered. The connector hardware must be planned according to the expected concurrent sessions on mobile devices. It differs slightly between Windows, Linux, and Mac connectors. The rule of thumb is to allocate one-half of the CPU Core for each remote device session	The disk space usage on the connector depends on a number of factors, such as the number of logs generated, and the number of application files cached on the connector. We recommend at least 10 GB.

Component

Memory

CPU

Disk Space

Server

The OpenText Functional Testing Lab server is a Java application. Therefore, it uses a predefined amount of host memory. The amount of consumed memory is impacted by the number of simulation sessions (user sessions). The minimal memory requirement is 8 GB. We recommend 8 GB for medium deployment (<30 devices), and 16 GB for large deployment (>30 devices).

* Based on your machine memory we recommend you increase the maximum heap size for the Java virtual machine (JVM) when installing, upgrading, or modifying the server for example: if the machine had 8 GB you can increase the Java heap size to 4GB.

Server CPU consumption is dependent on the number of requests that are processed. The minimal requirement is an x64 processor, 2.2 GHz

Disk space usage on the server depends on several factors such as logs generated, packaged applications, and processes.

We recommend at least 20 GB: 15 GB for general installation and 5 GB for the temporary folder. Please note that in versions 3.5 and above, you can specify a temporary folder different than TMP/TEMP.

An additional 1 GB of free disk space is required on the system disk.

PostgreSQL DB

PostgreSQL memory consumption is impacted by SQL queries that it is required to execute. The minimal requirement for memory is 2 GB. We strongly recommend at least 8 GB for medium deployment (<30 devices), and 16 GB for large deployment (>30 devices).

PostgreSQL is process-based. The minimal requirement is a dual-core CPU, 2.2 GHz.

Disk space usage on PostgreSQL depends on the data size. On Windows, PostgreSQL is installed on the C: drive, so disk space must be allocated there.

Connector

The OpenText Functional Testing Lab connector is a Java application. Hence, it uses a predefined amount of host memory.

The amount of consumed memory is impacted by the number of simulated sessions (user sessions). The minimal requirement is 4 GB.

* We recommend at least 8 GB for standard deployments (8-10 devices per connector), and 16 GB for large deployments (12-25 devices).

The guidelines for the connector are the same as for the server.

Remote access to the device increases the CPU consumption and must be considered. The connector hardware must be planned according to the expected concurrent sessions on mobile devices. It differs slightly between Windows, Linux, and Mac connectors. The rule of thumb is to allocate one-half of the CPU Core for each remote device session

The disk space usage on the connector depends on a number of factors, such as the number of logs generated, and the number of application files cached on the connector.

We recommend at least 10 GB.

Network requirements

OpenText Functional Testing Lab provides straightforward network requirements. For more details, see Architecture.

Network latency

OpenText Functional Testing Lab is designed for resiliency over the network (WAN), by using REST API communication over the HTTP/S protocol. However, there is also a communication channel that leverages the WebSocket protocol. Communication through this protocol may present some limitations that need to be considered. In general, if network latency is less than 100 ms, communication issues are unlikely when the lab server and connectors are using the public Internet, MPLS, VPN, or any other method. A latency greater than 200 ms will introduce connectivity challenges. To work on a device in remote view, we recommend a network bandwidth of 1 Mbps or higher.

SSL

By default, an SSL configuration is used to communicate between the OpenText Functional Testing Labserver and connectors. This isachieved by generating a self-signed SSL certificate during the installation.

For production usage, we strongly recommend using CA certificates (certificate issued by Certification Authority as opposed to self-signed), which will remove security warnings in browsers as well as streamline connectivity of testing tools. We also recommend using a CA certificate together with a CA Root certificate, to avoid any recognition issues on the client machine. For more information, see SSL and certificates.

Using SSL is also beneficial from a networking perspective, as it eliminates any internal security blockages by IPS or other security gateways.

Ports

The OpenText Functional Testing Lab server (Web front end) utilizes a single port. The port is configured during the installation of the server. The connector also utilizes a single port for connectivity with the OpenText Functional Testing Lab server and the end-user (client). Internally, the connector utilizes a reverse proxy (Nginx) to route the requests to relevant mobile devices. Therefore, from the networking perspective, a single port should be accessible (ingress) for the server and connector.

Regarding protocols used, there is a requirement for HTTP/HTTPS and WebSocket/WebSocket Secure (WS/WSS) protocols.

Client tools connectivity

Common client tools are UFT One, LoadRunner, Sprinter, BPM, UFT Developer, and Appium scripts.

Testing-tool clients connect to the OpenText Functional Testing Lab server for the following:

A user interface (UI) for managing devices and uploading apps over HTTP/HTTPS.
API (JSON commands) for tests and management, sent over WebSocket (WS/WSS).
The remote screen viewer client sent over WebSocket (WS/WSS)

USB hubs and device power consumption

When a device is used with OpenText Functional Testing Lab, there is a need for synchronization and charging. As the number of USB ports is often limited, and the power from each port may not be sufficient for certain devices, use a powered USB hub to connect the devices.

The hub should provide a minimum power output of 5V/2.1A per port, simultaneously for all ports, and comply with the BC 1.2 standard.

The hub should be connected to the machine with a cable certified for the hub, and the devices to the hub with their original cables.

OpenText recommends the following models:

Cambrionix SuperSync15.
Tripp Lite 16-Port USB Charging Station with Syncing (200W).
Tripp Lite Multi-Device Charging Station 48 USB Ports (600W).

Device hosting

Mobile devices are constantly connected to a power source. We recommend the following to reduce the amount of heat and impact of this configuration:

• Place the devices in a non-flammable, well-ventilated enclosure

• Provide extra ventilation for the enclosure

A number of solutions are available to help you meet these requirements. For example:

Devices beam for rack-mounted installation
Extra-fan panel for rack-mounted installation
1U 16 ports USB power hub
16-device USB charging station cabinet

For additional best practices related to devices hosting, see Connect devices.

Device configuration

To help with device configurations, check the following when connecting a device to OpenText Functional Testing Lab.

Area	Details
General	No passcode configured on the device No Google Play Account/Apple Store Account configured on the device Device connected to the Wi-Fi Device screen brightness to minimum Device wallpaper set to monochrome, static
Android devices	Disable Lock device option Enable Developer option (Go to Settings → About Device →Click 7 times on Build number) Enable Stay Awake option under developer options Enable USB Debugging option under Developer options On Samsung device that run on Android 8.0 and later, make sure to add the OpenText Functional Testing Lab Agent to unmonitored applications under Battery saver menu Turn off auto-update and patches install To avoid automatic upgrades on Android devices: In Settings > System > About device > Software update, disable auto update.
iOS (Apple) devices	Copy the UDID of the device (required for re-signing the Agents) Disable the Lock device option If the device runs on iOS 12 and above configure the Auto-lock to 30 seconds Under Settings > Safari >Advanced enable JavaScript and Web Inspector. Enable UI Automation option (after first connection to OpenText Functional Testing Lab the option is displayed in the Settings) Disable the iOS auto update (Settings > General > Software Update) To avoid automatic upgrades on iOS devices: 1. Tap Settings. 2. Tap General. 3. In the section Software update, turn off the Automatic Updates option. To remove previously downloaded iOS updates: Open the Settings app. Tap General. Tap iPhone/iPad Storage. Scroll down slightly until you see a list of apps and the amount of storage they use. Look for the iOS update. Tap the update to see more details, and then select Delete Update. Tap Delete Update to confirm. You can also block iOS automatic updates by blocking the following domains on the Wi-Fi router: appldnld.apple.com mesu.apple.com Additional items to consider: Automatic dismissal of system dialogs. For details, see iOS options Automatic prevention of device lock. For details, see iOS options

Area

Details

General

No passcode configured on the device
No Google Play Account/Apple Store Account configured on the device
Device connected to the Wi-Fi
Device screen brightness to minimum
Device wallpaper set to monochrome, static

Android devices

Disable Lock device option
Enable Developer option (Go to Settings → About Device →Click 7 times on Build number)
Enable Stay Awake option under developer options
Enable USB Debugging option under Developer options
On Samsung device that run on Android 8.0 and later, make sure to add the
OpenText Functional Testing Lab Agent to unmonitored applications under Battery saver menu
Turn off auto-update and patches install
To avoid automatic upgrades on Android devices:
In Settings > System > About device > Software update, disable auto update.

iOS (Apple) devices

Copy the UDID of the device (required for re-signing the Agents)
Disable the Lock device option
If the device runs on iOS 12 and above configure the Auto-lock to 30 seconds
Under Settings > Safari >Advanced enable JavaScript and Web Inspector.
Enable UI Automation option (after first connection to OpenText Functional Testing Lab the option is displayed in the Settings)
Disable the iOS auto update (Settings > General > Software Update)

To avoid automatic upgrades on iOS devices:

1. Tap Settings.

2. Tap General.

3. In the section Software update, turn off the Automatic Updates option.

To remove previously downloaded iOS updates:

Open the Settings app.
Tap General.
Tap iPhone/iPad Storage.
Scroll down slightly until you see a list of apps and the amount of storage they use. Look for the iOS update.
Tap the update to see more details, and then select Delete Update.
Tap Delete Update to confirm.

You can also block iOS automatic updates by blocking the following domains on the Wi-Fi router:

appldnld.apple.com
mesu.apple.com

Additional items to consider:

Automatic dismissal of system dialogs. For details, see iOS options
Automatic prevention of device lock. For details, see iOS options

Additional admin best practices

For best practices for lab maintenance operations, monitoring, upgrades, and packaging services, see Additional admin best practices.