Test Automation API for Host Device Farms

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Traditional testing systems lack the ability to provide robust testing of applications on actual computing devices, as owning and maintaining various devices with different hardware and operating systems is expensive and cumbersome, and simulators offer incomplete testing, while manual provisioning is time and resource intensive.

Innovation Solution

A system and method using an Application Programming Interface (API) to facilitate automatic testing of applications on multiple actual computing devices, including re-signing applications for testing, patching out signature verification, and configuring devices for parallel testing across various frameworks.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Loss of energy

If simulators are used for application testing, then testing cost is reduced, but testing completeness deteriorates

Engineering Contradiction:
Improvetesting costVSAvoidtesting completeness
Core Design Contradiction:
Loss of energyVSReliability

Solution Approach 1:

The patent uses actual physical devices as test targets instead of simulators, eliminating the need for expensive device farms while maintaining high-fidelity testing. The build server automatically provisions and manages real devices, achieving both cost reduction and testing completeness.

Inventive Principle:
Principle #26Copying

2Adaptability or versatility

If manual device provisioning is used, then device configuration flexibility is improved, but time consumption increases

Engineering Contradiction:
Improvedevice configuration flexibilityVSAvoidtime consumption
Core Design Contradiction:
Adaptability or versatilityVSLoss of time

Solution Approach 1:

The system implements automated device provisioning where the build server automatically configures and manages test devices without manual intervention. The system self-manages the entire testing workflow from device selection to test execution and result collection, eliminating time-consuming manual operations while maintaining configuration flexibility.

Inventive Principle:
Principle #25Self-service

3Measurement precision

If multiple actual devices are maintained for testing, then testing accuracy is improved, but maintenance cost increases

Engineering Contradiction:
Improvetesting accuracyVSAvoidmaintenance cost
Core Design Contradiction:
Measurement precisionVSLoss of energy

Solution Approach 1:

The build server acts as a universal platform that can manage multiple different device types and testing frameworks through a single interface. This multi-functional system eliminates the need for separate maintenance procedures for each device, reducing overall maintenance costs while preserving testing accuracy across diverse hardware platforms.

Inventive Principle:
Principle #6Universality (Multi-functionality)

4Reliability

If comprehensive testing across multiple frameworks is performed, then application quality is improved, but testing complexity increases

Engineering Contradiction:
Improveapplication qualityVSAvoidtesting complexity
Core Design Contradiction:
ReliabilityVSDevice complexity

Solution Approach 1:

The build server serves as an intermediary layer between the application under test and multiple testing frameworks. It abstracts the complexity of coordinating different frameworks (UI automation, performance testing, security testing) into a unified automated workflow, enabling comprehensive quality assurance while simplifying the testing process for developers.

Inventive Principle:
Principle #24Intermediary (Mediator)

Data Source

PatentUS9021443B1Test automation API for host devices
Publication Date: 2015.04.28 GOOGLE LLC
  • US9021443B1 patent drawing
  • US9021443B1 patent drawing
  • US9021443B1 patent drawing

AI summary

A system is described for testing an application on one or more host devices in a host device farm using an application programming interface (“API”) to send a test package containing an application to a test server. The sending may be initiated by a single action such as a click on a control in a user interface, or may be automatic such as on completion of a build. The test server may then execute and test the application across one or more host devices using one or more testing frameworks. Test results based at least in part on the type of testing framework used in the application may then be provided to a client device.