Local Agent is a software component that communicates with ACCELQ server to take up test execution assignments and runs tests in your local application environment. It enables the cloud-based ACCELQ server to run tests remotely in your local network, thereby avoiding the need to expose the test application to the internet.
Depending on your requirement, you can configure Local Agent for various attributes. These attributes are found in agent.properties file stored in your Agent installation folder.
View / Update Agent Properties
If you are using the Agent Command Center portal, you will view/set Agent properties by clicking on "Edit Configuration" for your Agent.
# to view Agent properties
$ acc properties --agent <name>
# to update a property in Agent.properties
$ acc properties --agent <name> --set <property_name>=<value>
Agent Details
agent_name
Agent name is the reference name used in the ACCELQ application for the given Agent. This name is displayed in the Resources > Local Agents tab, and in the Run modal when running automation tests. This name must be unique across all projects in your Tenant and can only contain alphabets, numbers, and "_" (underscore) characters.
You can go up to 32 characters long.
agent_port
Port number on which the Agent should run. If left blank, the port number will be assigned dynamically during Agent startup, based on available ports on the machine.
Agent Authentication
Agent Authentication information includes ACCELQ server URL, your username on ACCELQ, and the API key. You can find this information in the profile menu under the "Auth properties" once you log in to ACCELQ.
accelq_server_url
ACCELQ server URL along with the port number (if applicable). For example, "https://app.accelq.io".
user_id
User ID which you use for login to your ACCELQ instance. For example, "john.todd@acme.com".
api_key
API Key is available in the profile menu under the auth properties once you log in to your ACCELQ instance.
Agent Visibility
You can configure your Local Agent to be visible at the User, Project, or Tenant level based on your requirement. You can use an Agent for test executions where the Agent is visible.
agent_type
Scope of the agent, which defines the visibility of the agent at the User, Project, or Tenant levels.
- User level visibility: This agent is visible only to the user which is specified in the Authentication information in the Agent properties. The Agent will be visible to this User on any Project he/she is working on.
- Project level visibility: With Project level visibility, you can set up the names of the Projects for which this Agent should be available. Any user logging into one of these projects will have this Agent available for test execution.
- Tenant level visibility: This Agent will be available for test execution for any user belonging to your Tenant, working on any Project.
project_code
This attribute should be filled when the agent_type is set to "Project". Provide the project codes where this Agent should be visible, separated with a comma. The project code is visible in the Profile menu when you log in to your ACCELQ instance.
For example, "QBRegression,AcmeAdminStore".
Provider Type Information
Provider type indicates where the browser or mobile device should be provisioned for test execution. By default, the browser and mobile device are invoked locally on the machine where the Agent is running. However, if you are using cloud infrastructure from a third-party cloud provider, you may furnish that information here.
Currently supported cloud providers include - BrowserStack, Sauce Labs, Perfecto, LambdaTest, HeadSpin and Digital.ai.
Various attributes in this section are applicable based on the cloud provider you are using.
web_provider_type / mobile_provider_type
It indicates the type of cloud provider configured to execute the tests. Applicable to both Web and Mobile testing. Allowed values ["Local", "Browser Stack", "Sauce Labs", "Perfecto", "LambdaTest", "HeadSpin", "Digital.ai"]
Based on each provider type, you may configure the following properties:
For web automation testing:
| Property Name | Applicable To |
| web_provider_username | Browser Stack, Sauce Labs, LambdaTest |
| web_provider_password | Browser Stack, Sauce Labs, LambdaTest, HeadSpin, Digital.ai |
| web_provider_cloud_name | Perfecto |
| web_provider_security_token | Perfecto |
| web_provider_serverUrl | Digital.ai |
| web_provider_hostname | Sauce Labs |
| web_provider_port | Sauce Labs |
| web_provider_data_center_endpoint | Sauce Labs |
For mobile automation testing
| Property Name | Applicable To |
| mobile_provider_username | Browser Stack, Sauce Labs, LambdaTest |
| mobile_provider_password | Browser Stack, Sauce Labs, LambdaTest, HeadSpin, Digital.ai |
| mobile_provider_cloud_name | Perfecto |
| mobile_provider_security_token | Perfecto |
| mobile_provider_serverUrl | Digital.ai |
| mobile_provider_hostname | Sauce Labs |
| mobile_provider_port | Sauce Labs |
| mobile_provider_data_center_endpoint | Sauce Labs |
Refer to the links below for information required from each cloud provider
BrowserStack Local Settings
In addition to the above properties, if you are using BrowserStack Local feature, you are required to set up some extra properties. BrowserStack Local is a tunneling feature that establishes a secure connection between your Agent machine and the BrowserStack Cloud. Refer to BrowserStack documentation for further details.
auto_start_bs_local
This flag is to indicate if the Agent should make an attempt to automatically start the BrowserStack Local Service when needed. Set this flag to "false" in case you are starting the Browser Stack Local Service manually.
browserstack_local_key
BrowserStack Access key, which you can find in your BrowserStack account settings and will be used by the BrowserStack Local Service to establish a secure connection between the Agent machine and the BrowserStack Cloud.
Execution Concurrency
Execution concurrency determines how many test executions are allowed concurrently on this Agent. If the execution requests exceed these settings, requests get queued up. It is important to size up your Local Agent hardware based on the expected execution concurrency.
num_concurrent_jobs
This attribute indicates the maximum number of independent test jobs that can be kicked off at a time on this Agent.
num_parallel_tc_per_job
This attribute indicates the parallel-threads execution setting that can be used within a given job. A job will invoke multiple threads to concurrently run test cases based on this setting. By default, each job only invokes one execution thread.
Agent hardware requirement is based on the product of Job Count and the Thread Count.
Proxy Settings
Proxy information that includes both HTTP and HTTPS. This is necessary in case outgoing traffic from the Agent machine requires so.
HTTP proxy settings
- http_proxy_host
- http_proxy_port
- http_proxy_user
- http_proxy_password
- http_proxy_nonproxyhosts
HTTPS proxy settings
- https_proxy_host
- https_proxy_port
- https_proxy_user
- https_proxy_password
- https_proxy_nonproxyhosts
SSL Certificate Verification
ssl_cert_verification
This flag is to indicate if the Agent should make an attempt to verify the SSL Certificates.
Appium URL
Appium is an open-source test automation framework used by ACCELQ for automating mobile native, hybrid, or web apps. By default, ACCELQ Agent installation includes the Appium install and is accessed from the URL: "http://localhost:4723". But if you are manually starting Appium and need to use the Appium server running on a custom location, this attribute must point to the custom location.
appium_url
Appium server URL along with the port number (if applicable).
Terminal Emulator Settings
These attributes are applicable when you are running automation for Terminal Emulator (mainframe) applications.
te_start_server
This flag is to indicate if the Agent should start the Terminal Emulator Automation service. Values ["true", "false"]
te_server_port
Port number on which the Terminal Emulator Automation service should run. This setting is mandatory if "te_start_server" is set to "true".
Web Driver Auto-Update
With changing Browser version numbers, you may need to update the Web Drivers provided by respective Browser vendors to support test execution. Local Agents may automatically update these Drivers for you.
web_driver_auto_update
This flag enables the local agent to periodically check the web driver's version compatibility with the web browser version running on your machine. The Web driver is automatically updated in case of incompatibility. Values ["local", "server_side", "off"]
- local: Fetch driver jars by directly connecting to the download site managed by the Browser vendor, from the Agent machine.
- server_side: Fetch driver jars by connecting to the vendor site from the ACCELQ server. You can use this option if there are firewall restrictions from the Agent machine connecting to the download site. This option is slower compared to the "local" option.
- off: Do not auto-update the driver jars. Note, you will need to manually update the Web Drivers when needed. Place the driver file under the folder: <path_to_agent_home>/web_drivers/<windows_linux_or_mac>/
Virtualization Server Ports
virtualization_ports_range
If you are using API mocking in your test automation logic, a Virtualisation Server will be started on the Agent host. By default, the virtualization server uses available ports on the Agent machine. If required, you may indicate a specific port numbers range using this attribute. Provide the lower and upper limits of the port number range with comma separation. e.g., 9000, 10000.
Note, the number of available ports on the Agent machine should be at least twice the number of concurrent threads you are using for test execution.
Comments
0 comments
Please sign in to leave a comment.