Additional admin best practices

This sections outlines best practices for lab maintenance operations, monitoring, upgrades and packaging services.

Mobile lab inspection

Due to the nature of the setup, you must periodically perform a physical inspection of the mobile lab. The purpose of the inspection is to review the current setup, and to check for damage that may impact the system.

The following should be inspected:

  • Check that all devices are connected to Wi-Fi

  • Check each physical device for a swollen battery (When lithium-ion batteries are overheated, over-charged, or simply reach an old age, the inner cells of the battery may emit a flammable electrolyte mixture, causing the battery to swell.)

  • Check that all devices are charging and that the battery level is 100%.

  • Check that device brightness is set to minimum.

  • Check that the devices are not locked.

Back to top

Database maintenance

PostgreSQL, like any database software, requires certain tasks to be performed regularly to achieve optimum performance.

The following procedures are the most common:

  • Creation of backup copies of the data on a regular schedule

  • Periodic "vacuuming" of the database

For more information on database maintenance, see the PostgreSQL documentation

Back to top

Logs and TMP cleanup

Even though the logs remove older data, some conditions cause certain log files to grow significantly. For example, the application packager log, lab audit.log, and database audit log.

You need to monitor the size of these logs and periodically perform cleanups.

Back to top

Monitoring

Like any other production system, deployment requires monitoring for performance and availability.

The following types of monitoring are necessary:

Item Details
Hardware

Memory

CPU

disk space

Network consumption
Services process/service availability
Network availability URL monitoring
Devices Device availability
Connectors Connector availability
Database performance PostgreSQL: https://bucardo.org/check_postgres/
Log files

Monitoring log files for exceptions and errors

Various methods for effective monitoring are provided:

  • REST API reference : Any action related to the lab can be executed using REST API. REST API calls can be used in a script for monitoring purposes.

  • Embedded statistics reporting engine. The server aggregates statistics from the connector and exposes them using Prometheus reporter.

  • Lab log files are stored in the /log folder.

Back to top

Upgrade process

Because of the system’s vital business value, the upgrade process must be rolled out in an organized and robust way.

Be sure to follow these best practices:

  • Never upgrade in place. Use two environments – your current system and another, new installation running in parallel. Follow the procedure in Migrate the server .

  • Backup. Backup regularly, not only before an upgrade.Transactional data is not stored in the database, but it is still good practice to keep your data safe.

  • Compatibility check. Allow end users to rerun their tests and actions with a new system, to assure compatibility of their assets with the new version, before going live.

  • Leverage tools provided by the vendor. Do not try to modify the system manually. Use a migration tool for mobile applications, for example.

  • Plan the migration and execution. Plan your actions before, during, and after the upgrade.

For full details, see the Windows Installation.

Back to top

Packaging services

Both packaged and non-packaged mobile apps are supported. Packaging is an instrumentation method that injects the OpenText Functional Testing Lab intercept library into the application bundle and re-signs the app with proper credentials. The advantage of using packaged apps is to provide better object recognition for record/replay as well as additional sensors simulations (such as photo or fingerprint).

After you upload an app to the lab, the server automatically attempts to package the app. This gives users the option of selecting either a packaged app or the original version when running a test. To enable the functionality of automatic app packaging and signing, the administrator needs to set up the packaging and signing services.

The packaging service is also used during the upgrade process when the current app is upgraded with the latest version of the instrumentation library.

For general information about packaging services, including the manual procedure for packaging the apps, see App packaging and signing services.

Android packaging

By default, the Android packaging service is installed together with the lab server. It does not require any special configuration, but it can impact the overall performance of the server machine because the packaging service is a Java process that runs on the server.

iOS packaging

The packaging procedure for iOS apps is slightly different.

iOS applications and agents can be signed/packaged using the embedded packaging service or a remote packaging service. The maximum number of supported device types for an individual Apple Developer account is 100 iPhones and 100 iPads. If you need to sign more devices, an additional Apple Developer account is required. To use more than one Apple Developer account for packaging, the remote packaging service is required. For further information, see iOS signing service

Back to top