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:
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. |
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. The device is connected using a USB cable, which provides constant charging and communication (connector to agent). As the number of USB ports is usually limited, use a USB self-powered hub to support the required scalability. The hub is powered by an external power supply and can therefore provide full power to every port. Charging requirements for mobile devices vary from 500 to 5,000 mA (from Android and iOS phones to tablets and iPads). We strongly recommend that you ensure the power hub can deliver the required power to all USB ports.
Consider, for example, a powered 7-port USB hub of 60 W has specs of 12V and 5A (12x5=60). A smart hub dynamically splits the 5A among 7 ports, giving each port ~714 mA, which is sufficient for small/older mobile phones. However, if an iPad is connected to that hub, it will consume 2100 mA, leaving the remaining 2900 mA to be split among 6 ports (~480 mA each); this might be an issue even for mobile phones since the power allotment is less than the required 500 mA.
The following table lists the most popular devices and their power requirement for sync and charge.
iOS Devices |
mA |
Android Devices |
mA |
---|---|---|---|
iPad Pro 12.9 inch (4th generation) |
3000 |
Samsung S9/S9+ |
2000 |
iPad Pro 12.9 inch (3rd generation) |
3000 |
Samsung Note8 |
2100 |
iPad Pro 11-inch (2nd generation) |
3000 |
LG G4 |
1800 |
iPad Pro 11-inch |
3000 |
Google Pixel 2 |
2000 |
iPad Retina |
2400 |
Samsung S9/S9+ |
2000 |
iPad 2 |
2100 |
Samsung Note8 |
2100 |
iPad Air and iPad Air 2 |
2100 |
LG G4 |
1800 |
iPad Mini 2 and 3 |
2100 |
Google Pixel 2 |
2000 |
iPad Mini |
1000 |
Huawei Mate 9 |
2000 |
iPhone 5s |
500 |
Lenovo K8 |
1000 |
iPhone 6/7 and iPhone 6/7 Plus |
1000 |
Motorola Nexus 6 |
2000 |
iPhone X and iPhone XS |
1000 |
Xiaomi Mi 5 |
1000 |
iPhone 8 and iPhone 8 Plus |
1000 |
Samsung S20/S20+ |
4000 |
iPhone XS Max |
1000 |
Samsung S21 Ultra |
5000 |
iPhone XR |
1000 |
Samsung S21/S21+ |
4000/4800 |
iPhone 11 |
2000 |
Google Pixel 4a |
3140 |
iPhone 11 Pro |
2000 |
Google Pixel 5 |
2800 |
iPhone 11 Pro Max |
2000 |
Motorola One 5G |
5000 |
iPhone 12 |
2815 |
Samsung S22 Ultra |
5000 |
iPhone 12 Pro |
2815 |
Google Pixel 6 Pro |
5000 |
iPhone 12 Pro Max |
3687 |
Samsung Galaxy Z Flip 3 |
3300 |
iPhone 13 |
3227 |
Oppo Find X5 Pro |
5000 |
iPhone 13 Pro |
3095 |
Samsung S22+ |
4500 |
iPhone 13 Pro Max |
4352 |
OnePlus Nord 2 |
4500 |
iPad mini 6 |
8827 |
OnePlus 10 Pro |
5000 |
|
|
Xiaomi Redmi Note 10 Pro |
5020 |
|
|
Xiaomi Mi 11 |
4600 |
We recommend that you plan and calculate power requirements in advance to avoid device disconnections due to power issues. In addition, we recommend that you use powered USB hubs that comply with the BC 1.2 standard. Here are some examples of products recommended:
-
16-Port USB 2.0 hub 200W multiple USB port hub - USB charging splitter 5V 40A
-
16-Port USB Charging Station with Syncing, 230V, 5V 40A (200W) USB Charger Output, 2U Rack-Mount
-
SuperSync15 – Cambrionix Multideck
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 |
|
Android devices |
|
iOS (Apple) devices |
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:
You can also block iOS automatic updates by blocking the following domains on the Wi-Fi router:
Additional items to consider:
|
Additional admin best practices
For best practices for lab maintenance operations, monitoring, upgrades, and packaging services, see Additional admin best practices.