As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
# Ambiente de teste personalizado no AWS Device Farm.
O AWS Device Farm permite configurar um ambiente personalizado para testes automatizados (modo personalizado), que é a abordagem recomendada para todos os usuários do Device Farm. Para saber mais sobre ambientes no Device Farm, consulte [Test environments](https://docs.aws.amazon.com/devicefarm/latest/developerguide/test-environments.html).
Os benefícios do Modo Personalizado em oposição ao Modo Padrão incluem:
+ **Execução mais rápida end-to-end** do teste: o pacote de teste não é analisado para detectar todos os testes na suíte, evitando preprocessing/postprocessing sobrecarga.
+ **Log ao vivo e streaming de vídeo**: os log de teste e vídeo do lado do cliente são transmitidos ao vivo ao usar o modo personalizado. Esse recurso não está disponível na modalidade padrão.
+ **Captura todos os artefatos**: no host e no dispositivo, o modo personalizado permite capturar todos os artefatos de teste. Isso pode não ser possível no modo padrão.
+ **Ambiente local mais consistente e replicável**: no modo padrão, os artefatos serão fornecidos para cada teste individual separadamente, o que pode ser benéfico em determinadas circunstâncias. No entanto, seu ambiente de teste local pode se desviar da configuração original, pois o Device Farm trata cada teste executado de forma diferente.
Por outro lado, o Modo Personalizado permite que você torne seu ambiente de execução de testes do Device Farm consistentemente alinhado com seu ambiente de teste local.
Ambientes personalizados são configurados usando um arquivo de especificação de teste formatado em YAML (especificação de teste). O Device Farm fornece um arquivo de especificação de teste padrão para cada tipo de teste compatível que pode ser usado como está ou personalizado; personalizações como filtros de teste ou arquivos de configuração podem ser adicionadas à especificação de teste. As especificações de teste editadas podem ser salvas para futuros testes.
Para obter mais informações, consulte [Uploading a Custom Test Spec Using the AWS CLI](https://docs.aws.amazon.com/devicefarm/latest/developerguide/how-to-create-test-run.html#how-to-create-test-run-cli-step5) e [Criar uma execução de teste no Device Farm](how-to-create-test-run.md).
**Topics**
+ [Referência e sintaxe da especificação de teste](custom-test-environment-test-spec.md)
+ [Hosts para ambientes de teste personalizados](custom-test-environments-hosts.md)
+ [Acesse os recursos da AWS usando uma função de execução do IAM](custom-test-environments-iam-roles.md)
+ [Variáveis de ambiente para ambientes de teste personalizados](custom-test-environment-variables.md)
+ [Práticas recomendadas para execução de ambientes de teste personalizados](custom-test-environments-best-practices.md)
+ [Migrar testes de um ambiente padrão para um ambiente de teste personalizado](custom-test-environment-migration.md)
+ [Extensão de ambientes de teste personalizados no Device Farm](custom-test-environments-extending.md)
# Referência e sintaxe da especificação de teste
A especificação de teste (especificação de teste) é um arquivo que você usa para definir ambientes de teste personalizados no Device Farm.
## Fluxo de trabalho de especificações de teste
A especificação de teste do Device Farm executa as fases e seus comandos em uma ordem predeterminada, permitindo que você personalize a forma como seu ambiente é preparado e executado. Quando cada fase é executada, seus comandos são executados na ordem listada no arquivo de especificação de teste. As fases são executadas na seguinte sequência
1. `install`- É aqui que ações como baixar, instalar e configurar ferramentas devem ser definidas.
1. `pre_test`- É aqui que as ações de pré-teste, como iniciar processos em segundo plano, devem ser definidas.
1. `test`- É aqui que o comando que invoca seu teste deve ser definido.
1. `post_test`- É aqui que todas as tarefas finais que precisam ser executadas após a conclusão do teste devem ser definidas, como geração de relatórios de teste e agregação de arquivos de artefatos.
## Sintaxe da especificação de teste
A seguir está o esquema YAML para um arquivo de especificação de teste
```
version: 0.1
android_test_host: "string"
ios_test_host: "string"
phases:
install:
commands:
- "string"
- "string"
pre_test:
commands:
- "string"
- "string"
test:
commands:
- "string"
- "string"
post_test:
commands:
- "string"
- "string"
artifacts:
- "string"
- "string"
```
** `version` **
*(Obrigatório, número)*
Reflete a versão da especificação de teste compatível com o Device Farm. O número da versão atual é` 0.1`.
** `android_test_host` **
*(Opcional, string)*
O host de teste que será selecionado para execuções de teste realizadas em dispositivos Android. Esse campo é obrigatório para testes em dispositivos Android. Para obter mais informações, consulte [Hosts de teste disponíveis para ambientes de teste personalizados](custom-test-environments-hosts.md#custom-test-environments-hosts-available).
** `ios_test_host` **
*(Opcional, string)*
O host de teste que será selecionado para execuções de teste realizadas em dispositivos iOS. Esse campo é obrigatório para execuções de teste em dispositivos iOS com uma versão principal maior que 26. Para obter mais informações, consulte [Hosts de teste disponíveis para ambientes de teste personalizados](custom-test-environments-hosts.md#custom-test-environments-hosts-available).
** `phases` **
Esta seção contém grupos de comandos executados durante uma execução de teste, em que cada fase é opcional. Os nomes de fases de teste permitidos são: `install` `pre_test``test`,, `post_test` e.
+ `install`- As dependências padrão para estruturas de teste suportadas pelo Device Farm já estão instaladas. Essa fase contém comandos adicionais, se houver, que o Device Farm executa durante a instalação.
+ `pre_test`- Os comandos, se houver, executados antes do teste automatizado.
+ `test`- Os comandos executados durante a execução do teste automatizado. Se algum comando na fase de teste falhar (o que significa que ele retorna um código de saída diferente de zero), o teste é marcado como falhado
+ `post_test`- Os comandos, se houver, executados após a execução do teste automatizado. Isso será executado independentemente de seu teste na `test` fase ser bem-sucedido ou falhar.
** `commands` **
*(Opcional, Listar [string])*
Uma lista de strings a serem executadas como um comando shell durante a fase.
** `artifacts` **
*(Opcional, Listar [string])*
O Device Farm reúne artefatos como relatórios personalizados, arquivos de log e imagens de um local especificado aqui. Os caracteres curinga não são permitidos como parte de um artefato local. Dessa forma, você deve especificar um caminho válido para cada local.
Esses artefatos de teste estão disponíveis para cada dispositivo na execução de teste. Para obter informações sobre como recuperar os artefatos de teste, consulte [Baixar artefatos em um ambiente de teste personalizado](using-artifacts-custom.md).
**Importante**
Uma especificação de teste deve ser formatada como um arquivo YAML válido. Caso o recuo ou o espaçamento na especificação de teste seja inválido, a execução de teste pode falhar. As guias não são permitidas em arquivos YAML. Você pode usar um validador YAML para testar se a especificação de teste é um arquivo YAML válido. Para obter mais informações, consulte o [site da YAML](http://yaml.org/spec/1.2/spec.html).
## Exemplos de especificações de teste
Os exemplos a seguir mostram especificações de teste que podem ser executadas no Device Farm.
------
#### [ Simple Demo ]
Veja a seguir um exemplo de arquivo de especificação de teste que simplesmente é registrado `Hello world!` como um artefato de execução de teste.
```
version: 0.1
android_test_host: amazon_linux_2
ios_test_host: macos_sequoia
phases:
install:
commands:
# Setup your environment by installing and/or validating software
- devicefarm-cli use python 3.11
- python --version
pre_test:
commands:
# Setup your tests by starting background tasks or setting up
# additional environment variables.
- OUTPUT_FILE="/tmp/hello.log"
test:
commands:
# Run your tests within this phase.
- python -c 'print("Hello world!")' &> $OUTPUT_FILE
post_test:
commands:
# Perform any remaining tasks within this phase, such as copying
# artifacts to the DEVICEFARM_LOG_DIR for upload
- cp $OUTPUT_FILE $DEVICEFARM_LOG_DIR
artifacts:
# By default, Device Farm will collect your artifacts from the $DEVICEFARM_LOG_DIR directory.
- $DEVICEFARM_LOG_DIR
```
------
#### [ Appium Android ]
A seguir está um exemplo de arquivo de especificação de teste que configura um teste Appium Java TestNG executado no Android.
```
version: 0.1
# The following fields(s) allow you to select which Device Farm test host is used for your test run.
android_test_host: amazon_linux_2
phases:
# The install phase contains commands for installing dependencies to run your tests.
# Certain frequently used dependencies are preinstalled on the test host to accelerate and
# simplify your test setup. To find these dependencies, versions supported and additional
# software installation please see:
# https://docs.aws.amazon.com/devicefarm/latest/developerguide/custom-test-environments-hosts-software.html
install:
commands:
# The Appium server is written using Node.js. In order to run your desired version of Appium,
# you first need to set up a Node.js environment that is compatible with your version of Appium.
- devicefarm-cli use node 20
- node --version
# Use the devicefarm-cli to select a preinstalled major version of Appium.
- devicefarm-cli use appium 2
- appium --version
# The Device Farm service periodically updates the preinstalled Appium versions over time to
# incorporate the latest minor and patch versions for each major version. If you wish to
# select a specific version of Appium, you can use NPM to install it.
# - npm install -g appium@2.19.0
# When running Android tests with Appium version 2, the uiautomator2 driver is preinstalled using driver
# version 2.44.1 for Appium 2.5.1 If you want to install a different version of the driver,
# you can use the Appium extension CLI to uninstall the existing uiautomator2 driver
# and install your desired version:
# - |-
# if [ $DEVICEFARM_DEVICE_PLATFORM_NAME = "Android" ];
# then
# appium driver uninstall uiautomator2;
# appium driver install uiautomator2@2.34.0;
# fi;
# Based on Appium framework's recommendation, we recommend setting the Appium server's
# base path explicitly for accepting commands. If you prefer the legacy base path of /wd/hub,
# please set it here.
- export APPIUM_BASE_PATH=
# Use the devicefarm-cli to setup a Java environment, with which you can run your test suite.
- devicefarm-cli use java 17
- java -version
# The pre-test phase contains commands for setting up your test environment.
pre_test:
commands:
# Setup the CLASSPATH so that Java knows where to find your test classes.
- export CLASSPATH=$CLASSPATH:$DEVICEFARM_TEST_PACKAGE_PATH/*
- export CLASSPATH=$CLASSPATH:$DEVICEFARM_TEST_PACKAGE_PATH/dependency-jars/*
# We recommend starting the Appium server process in the background using the command below.
# The Appium server log will be written to the $DEVICEFARM_LOG_DIR directory.
# The environment variables passed as capabilities to the server will be automatically assigned
# during your test run based on your test's specific device.
# For more information about which environment variables are set and how they're set, please see
# https://docs.aws.amazon.com/devicefarm/latest/developerguide/custom-test-environment-variables.html
- |-
appium --base-path=$APPIUM_BASE_PATH --log-timestamp \
--log-no-colors --relaxed-security --default-capabilities \
"{\"appium:deviceName\": \"$DEVICEFARM_DEVICE_NAME\", \
\"platformName\": \"$DEVICEFARM_DEVICE_PLATFORM_NAME\", \
\"appium:udid\":\"$DEVICEFARM_DEVICE_UDID\", \
\"appium:platformVersion\": \"$DEVICEFARM_DEVICE_OS_VERSION\", \
\"appium:chromedriverExecutableDir\": \"$DEVICEFARM_CHROMEDRIVER_EXECUTABLE_DIR\", \
\"appium:automationName\": \"UiAutomator2\"}" \
>> $DEVICEFARM_LOG_DIR/appium.log 2>&1 &;
# This code snippet is to wait until the Appium server starts.
- |-
appium_initialization_time=0;
until curl --silent --fail "http://0.0.0.0:4723${APPIUM_BASE_PATH}/status"; do
if [[ $appium_initialization_time -gt 30 ]]; then
echo "Appium did not start within 30 seconds. Exiting...";
exit 1;
fi;
appium_initialization_time=$((appium_initialization_time + 1));
echo "Waiting for Appium to start on port 4723...";
sleep 1;
done;
# The test phase contains commands for running your tests.
test:
commands:
# Your test package is downloaded and unpackaged into the $DEVICEFARM_TEST_PACKAGE_PATH directory.
- echo "Navigate to test package directory"
- cd $DEVICEFARM_TEST_PACKAGE_PATH
- echo "Starting the Appium TestNG test"
# The following command runs your Appium Java TestNG test.
# For more information, please see TestNG's documentation here:
# https://testng.org/#_running_testng
- |-
java -Dappium.screenshots.dir=$DEVICEFARM_SCREENSHOT_PATH org.testng.TestNG -testjar *-tests.jar \
-d $DEVICEFARM_LOG_DIR/test-output -verbose 10
# To run your tests with a testng.xml file that is a part of your test package,
# use the following commands instead:
# - echo "Unzipping the tests JAR file"
# - unzip *-tests.jar
# - |-
# java -Dappium.screenshots.dir=$DEVICEFARM_SCREENSHOT_PATH org.testng.TestNG -testjar *-tests.jar \
# testng.xml -d $DEVICEFARM_LOG_DIR/test-output -verbose 10
# The post-test phase contains commands that are run after your tests have completed.
# If you need to run any commands to generating logs and reports on how your test performed,
# we recommend adding them to this section.
post_test:
commands:
# Artifacts are a list of paths on the filesystem where you can store test output and reports.
# All files in these paths will be collected by Device Farm, with certain limits (see limit details
# here: https://docs.aws.amazon.com/devicefarm/latest/developerguide/limits.html#file-limits).
# These files will be available through the ListArtifacts API as your "Customer Artifacts".
artifacts:
# By default, Device Farm will collect your artifacts from the $DEVICEFARM_LOG_DIR directory.
- $DEVICEFARM_LOG_DIR
```
------
#### [ Appium iOS ]
A seguir está um exemplo de arquivo de especificação de teste que configura um teste Appium Java TestNG executado no iOS.
```
version: 0.1
# The following fields(s) allow you to select which Device Farm test host is used for your test run.
ios_test_host: macos_sequoia
phases:
# The install phase contains commands for installing dependencies to run your tests.
# Certain frequently used dependencies are preinstalled on the test host to accelerate and
# simplify your test setup. To find these dependencies, versions supported and additional
# software installation please see:
# https://docs.aws.amazon.com/devicefarm/latest/developerguide/custom-test-environments-hosts-software.html
install:
commands:
# The Appium server is written using Node.js. In order to run your desired version of Appium,
# you first need to set up a Node.js environment that is compatible with your version of Appium.
- devicefarm-cli use node 20
- node --version
# Use the devicefarm-cli to select a preinstalled major version of Appium.
- devicefarm-cli use appium 2
- appium --version
# The Device Farm service periodically updates the preinstalled Appium versions over time to
# incorporate the latest minor and patch versions for each major version. If you wish to
# select a specific version of Appium, you can use NPM to install it.
# - npm install -g appium@2.19.0
# When running iOS tests with Appium version 2, the XCUITest driver is preinstalled using driver
# version 9.10.5 for Appium 2.5.4. If you want to install a different version of the driver,
# you can use the Appium extension CLI to uninstall the existing XCUITest driver
# and install your desired version:
# - |-
# if [ $DEVICEFARM_DEVICE_PLATFORM_NAME = "iOS" ];
# then
# appium driver uninstall xcuitest;
# appium driver install xcuitest@10.0.0;
# fi;
# Based on Appium framework's recommendation, we recommend setting the Appium server's
# base path explicitly for accepting commands. If you prefer the legacy base path of /wd/hub,
# please set it here.
- export APPIUM_BASE_PATH=
# Use the devicefarm-cli to setup a Java environment, with which you can run your test suite.
- devicefarm-cli use java 17
- java -version
# The pre-test phase contains commands for setting up your test environment.
pre_test:
commands:
# Setup the CLASSPATH so that Java knows where to find your test classes.
- export CLASSPATH=$CLASSPATH:$DEVICEFARM_TEST_PACKAGE_PATH/*
- export CLASSPATH=$CLASSPATH:$DEVICEFARM_TEST_PACKAGE_PATH/dependency-jars/*
# Device Farm provides multiple pre-built versions of WebDriverAgent (WDA), a required
# Appium dependency for iOS, where each version corresponds to the XCUITest driver version selected.
# If Device Farm cannot find a corresponding version of WDA for your XCUITest driver,
# the latest available version is selected by default.
- |-
APPIUM_DRIVER_VERSION=$(appium driver list --installed --json | jq -r ".xcuitest.version" | cut -d "." -f 1);
CORRESPONDING_APPIUM_WDA=$(env | grep "DEVICEFARM_APPIUM_WDA_DERIVED_DATA_PATH_V${APPIUM_DRIVER_VERSION}")
if [[ ! -z "$APPIUM_DRIVER_VERSION" ]] && [[ ! -z "$CORRESPONDING_APPIUM_WDA" ]]; then
echo "Using Device Farm's prebuilt WDA version ${APPIUM_DRIVER_VERSION}.x, which corresponds with your driver";
DEVICEFARM_APPIUM_WDA_DERIVED_DATA_PATH=$(echo $CORRESPONDING_APPIUM_WDA | cut -d "=" -f2)
else
LATEST_SUPPORTED_WDA_VERSION=$(env | grep "DEVICEFARM_APPIUM_WDA_DERIVED_DATA_PATH_V" | sort -V -r | head -n 1)
echo "Unknown driver version $APPIUM_DRIVER_VERSION; falling back to the Device Farm default version of $LATEST_SUPPORTED_WDA_VERSION";
DEVICEFARM_APPIUM_WDA_DERIVED_DATA_PATH=$(echo $LATEST_SUPPORTED_WDA_VERSION | cut -d "=" -f2)
fi;
# For iOS versions 16 and below only, the device unique identifier (UDID) needs to modified for Appium tests
# on Device Farm to remove the hypens.
- |-
if [ $DEVICEFARM_DEVICE_PLATFORM_NAME = "iOS" ]; then
DEVICEFARM_DEVICE_UDID_FOR_APPIUM=$DEVICEFARM_DEVICE_UDID;
if [ $(echo $DEVICEFARM_DEVICE_OS_VERSION | cut -d "." -f 1) -le 16 ]; then
DEVICEFARM_DEVICE_UDID_FOR_APPIUM=$(echo $DEVICEFARM_DEVICE_UDID | tr -d "-");
fi;
fi;
# We recommend starting the Appium server process in the background using the command below.
# The Appium server log will be written to the $DEVICEFARM_LOG_DIR directory.
# The environment variables passed as capabilities to the server will be automatically assigned
# during your test run based on your test's specific device.
# For more information about which environment variables are set and how they're set, please see
# https://docs.aws.amazon.com/devicefarm/latest/developerguide/custom-test-environment-variables.html
- |-
appium --base-path=$APPIUM_BASE_PATH --log-timestamp \
--log-no-colors --relaxed-security --default-capabilities \
"{\"appium:deviceName\": \"$DEVICEFARM_DEVICE_NAME\", \
\"platformName\": \"$DEVICEFARM_DEVICE_PLATFORM_NAME\", \
\"appium:app\": \"$DEVICEFARM_APP_PATH\", \
\"appium:udid\":\"$DEVICEFARM_DEVICE_UDID_FOR_APPIUM\", \
\"appium:platformVersion\": \"$DEVICEFARM_DEVICE_OS_VERSION\", \
\"appium:derivedDataPath\": \"$DEVICEFARM_APPIUM_WDA_DERIVED_DATA_PATH\", \
\"appium:usePrebuiltWDA\": true, \
\"appium:automationName\": \"XCUITest\"}" \
>> $DEVICEFARM_LOG_DIR/appium.log 2>&1 &
# This code snippet is to wait until the Appium server starts.
- |-
appium_initialization_time=0;
until curl --silent --fail "http://0.0.0.0:4723${APPIUM_BASE_PATH}/status"; do
if [[ $appium_initialization_time -gt 30 ]]; then
echo "Appium did not start within 30 seconds. Exiting...";
exit 1;
fi;
appium_initialization_time=$((appium_initialization_time + 1));
echo "Waiting for Appium to start on port 4723...";
sleep 1;
done;
# The test phase contains commands for running your tests.
test:
commands:
# Your test package is downloaded and unpackaged into the $DEVICEFARM_TEST_PACKAGE_PATH directory.
- echo "Navigate to test package directory"
- cd $DEVICEFARM_TEST_PACKAGE_PATH
- echo "Starting the Appium TestNG test"
# The following command runs your Appium Java TestNG test.
# For more information, please see TestNG's documentation here:
# https://testng.org/#_running_testng
- |-
java -Dappium.screenshots.dir=$DEVICEFARM_SCREENSHOT_PATH org.testng.TestNG -testjar *-tests.jar \
-d $DEVICEFARM_LOG_DIR/test-output -verbose 10
# To run your tests with a testng.xml file that is a part of your test package,
# use the following commands instead:
# - echo "Unzipping the tests JAR file"
# - unzip *-tests.jar
# - |-
# java -Dappium.screenshots.dir=$DEVICEFARM_SCREENSHOT_PATH org.testng.TestNG -testjar *-tests.jar \
# testng.xml -d $DEVICEFARM_LOG_DIR/test-output -verbose 10
# The post-test phase contains commands that are run after your tests have completed.
# If you need to run any commands to generating logs and reports on how your test performed,
# we recommend adding them to this section.
post_test:
commands:
# Artifacts are a list of paths on the filesystem where you can store test output and reports.
# All files in these paths will be collected by Device Farm, with certain limits (see limit details
# here: https://docs.aws.amazon.com/devicefarm/latest/developerguide/limits.html#file-limits).
# These files will be available through the ListArtifacts API as your "Customer Artifacts".
artifacts:
# By default, Device Farm will collect your artifacts from the $DEVICEFARM_LOG_DIR directory.
- $DEVICEFARM_LOG_DIR
```
------
#### [ Appium (Both Platforms) ]
A seguir está um exemplo de arquivo de especificação de teste que configura um teste Appium Java TestNG executado no Android e no iOS.
```
version: 0.1
# The following fields(s) allow you to select which Device Farm test host is used for your test run.
android_test_host: amazon_linux_2
ios_test_host: macos_sequoia
phases:
# The install phase contains commands for installing dependencies to run your tests.
# Certain frequently used dependencies are preinstalled on the test host to accelerate and
# simplify your test setup. To find these dependencies, versions supported and additional
# software installation please see:
# https://docs.aws.amazon.com/devicefarm/latest/developerguide/custom-test-environments-hosts-software.html
install:
commands:
# The Appium server is written using Node.js. In order to run your desired version of Appium,
# you first need to set up a Node.js environment that is compatible with your version of Appium.
- devicefarm-cli use node 20
- node --version
# Use the devicefarm-cli to select a preinstalled major version of Appium.
- devicefarm-cli use appium 2
- appium --version
# The Device Farm service periodically updates the preinstalled Appium versions over time to
# incorporate the latest minor and patch versions for each major version. If you wish to
# select a specific version of Appium, you can use NPM to install it.
# - npm install -g appium@2.19.0
# When running Android tests with Appium version 2, the uiautomator2 driver is preinstalled using driver
# version 2.44.1 for Appium 2.5.1 If you want to install a different version of the driver,
# you can use the Appium extension CLI to uninstall the existing uiautomator2 driver
# and install your desired version:
# - |-
# if [ $DEVICEFARM_DEVICE_PLATFORM_NAME = "Android" ];
# then
# appium driver uninstall uiautomator2;
# appium driver install uiautomator2@2.34.0;
# fi;
# When running iOS tests with Appium version 2, the XCUITest driver is preinstalled using driver
# version 9.10.5 for Appium 2.5.4. If you want to install a different version of the driver,
# you can use the Appium extension CLI to uninstall the existing XCUITest driver
# and install your desired version:
# - |-
# if [ $DEVICEFARM_DEVICE_PLATFORM_NAME = "iOS" ];
# then
# appium driver uninstall xcuitest;
# appium driver install xcuitest@10.0.0;
# fi;
# Based on Appium framework's recommendation, we recommend setting the Appium server's
# base path explicitly for accepting commands. If you prefer the legacy base path of /wd/hub,
# please set it here.
- export APPIUM_BASE_PATH=
# Use the devicefarm-cli to setup a Java environment, with which you can run your test suite.
- devicefarm-cli use java 17
- java -version
# The pre-test phase contains commands for setting up your test environment.
pre_test:
commands:
# Setup the CLASSPATH so that Java knows where to find your test classes.
- export CLASSPATH=$CLASSPATH:$DEVICEFARM_TEST_PACKAGE_PATH/*
- export CLASSPATH=$CLASSPATH:$DEVICEFARM_TEST_PACKAGE_PATH/dependency-jars/*
# Device Farm provides multiple pre-built versions of WebDriverAgent (WDA), a required
# Appium dependency for iOS, where each version corresponds to the XCUITest driver version selected.
# If Device Farm cannot find a corresponding version of WDA for your XCUITest driver,
# the latest available version is selected by default.
- |-
if [ $DEVICEFARM_DEVICE_PLATFORM_NAME = "iOS" ]; then
APPIUM_DRIVER_VERSION=$(appium driver list --installed --json | jq -r ".xcuitest.version" | cut -d "." -f 1);
CORRESPONDING_APPIUM_WDA=$(env | grep "DEVICEFARM_APPIUM_WDA_DERIVED_DATA_PATH_V${APPIUM_DRIVER_VERSION}")
if [[ ! -z "$APPIUM_DRIVER_VERSION" ]] && [[ ! -z "$CORRESPONDING_APPIUM_WDA" ]]; then
echo "Using Device Farm's prebuilt WDA version ${APPIUM_DRIVER_VERSION}.x, which corresponds with your driver";
DEVICEFARM_APPIUM_WDA_DERIVED_DATA_PATH=$(echo $CORRESPONDING_APPIUM_WDA | cut -d "=" -f2)
else
LATEST_SUPPORTED_WDA_VERSION=$(env | grep "DEVICEFARM_APPIUM_WDA_DERIVED_DATA_PATH_V" | sort -V -r | head -n 1)
echo "Unknown driver version $APPIUM_DRIVER_VERSION; falling back to the Device Farm default version of $LATEST_SUPPORTED_WDA_VERSION";
DEVICEFARM_APPIUM_WDA_DERIVED_DATA_PATH=$(echo $LATEST_SUPPORTED_WDA_VERSION | cut -d "=" -f2)
fi;
fi;
# For iOS versions 16 and below only, the device unique identifier (UDID) needs to modified for Appium tests
# on Device Farm to remove the hypens.
- |-
if [ $DEVICEFARM_DEVICE_PLATFORM_NAME = "iOS" ]; then
DEVICEFARM_DEVICE_UDID_FOR_APPIUM=$DEVICEFARM_DEVICE_UDID;
if [ $(echo $DEVICEFARM_DEVICE_OS_VERSION | cut -d "." -f 1) -le 16 ]; then
DEVICEFARM_DEVICE_UDID_FOR_APPIUM=$(echo $DEVICEFARM_DEVICE_UDID | tr -d "-");
fi;
fi;
# We recommend starting the Appium server process in the background using the command below.
# The Appium server log will be written to the $DEVICEFARM_LOG_DIR directory.
# The environment variables passed as capabilities to the server will be automatically assigned
# during your test run based on your test's specific device.
# For more information about which environment variables are set and how they're set, please see
# https://docs.aws.amazon.com/devicefarm/latest/developerguide/custom-test-environment-variables.html
- |-
if [ $DEVICEFARM_DEVICE_PLATFORM_NAME = "Android" ]; then
appium --base-path=$APPIUM_BASE_PATH --log-timestamp \
--log-no-colors --relaxed-security --default-capabilities \
"{\"appium:deviceName\": \"$DEVICEFARM_DEVICE_NAME\", \
\"platformName\": \"$DEVICEFARM_DEVICE_PLATFORM_NAME\", \
\"appium:udid\":\"$DEVICEFARM_DEVICE_UDID\", \
\"appium:platformVersion\": \"$DEVICEFARM_DEVICE_OS_VERSION\", \
\"appium:chromedriverExecutableDir\": \"$DEVICEFARM_CHROMEDRIVER_EXECUTABLE_DIR\", \
\"appium:automationName\": \"UiAutomator2\"}" \
>> $DEVICEFARM_LOG_DIR/appium.log 2>&1 &
else
appium --base-path=$APPIUM_BASE_PATH --log-timestamp \
--log-no-colors --relaxed-security --default-capabilities \
"{\"appium:deviceName\": \"$DEVICEFARM_DEVICE_NAME\", \
\"platformName\": \"$DEVICEFARM_DEVICE_PLATFORM_NAME\", \
\"appium:udid\":\"$DEVICEFARM_DEVICE_UDID_FOR_APPIUM\", \
\"appium:platformVersion\": \"$DEVICEFARM_DEVICE_OS_VERSION\", \
\"appium:derivedDataPath\": \"$DEVICEFARM_WDA_DERIVED_DATA_PATH\", \
\"appium:usePrebuiltWDA\": true, \
\"appium:automationName\": \"XCUITest\"}" \
>> $DEVICEFARM_LOG_DIR/appium.log 2>&1 &
fi;
# This code snippet is to wait until the Appium server starts.
- |-
appium_initialization_time=0;
until curl --silent --fail "http://0.0.0.0:4723${APPIUM_BASE_PATH}/status"; do
if [[ $appium_initialization_time -gt 30 ]]; then
echo "Appium did not start within 30 seconds. Exiting...";
exit 1;
fi;
appium_initialization_time=$((appium_initialization_time + 1));
echo "Waiting for Appium to start on port 4723...";
sleep 1;
done;
# The test phase contains commands for running your tests.
test:
commands:
# Your test package is downloaded and unpackaged into the $DEVICEFARM_TEST_PACKAGE_PATH directory.
- echo "Navigate to test package directory"
- cd $DEVICEFARM_TEST_PACKAGE_PATH
- echo "Starting the Appium TestNG test"
# The following command runs your Appium Java TestNG test.
# For more information, please see TestNG's documentation here:
# https://testng.org/#_running_testng
- |-
java -Dappium.screenshots.dir=$DEVICEFARM_SCREENSHOT_PATH org.testng.TestNG -testjar *-tests.jar \
-d $DEVICEFARM_LOG_DIR/test-output -verbose 10
# To run your tests with a testng.xml file that is a part of your test package,
# use the following commands instead:
# - echo "Unzipping the tests JAR file"
# - unzip *-tests.jar
# - |-
# java -Dappium.screenshots.dir=$DEVICEFARM_SCREENSHOT_PATH org.testng.TestNG -testjar *-tests.jar \
# testng.xml -d $DEVICEFARM_LOG_DIR/test-output -verbose 10
# The post-test phase contains commands that are run after your tests have completed.
# If you need to run any commands to generating logs and reports on how your test performed,
# we recommend adding them to this section.
post_test:
commands:
# Artifacts are a list of paths on the filesystem where you can store test output and reports.
# All files in these paths will be collected by Device Farm, with certain limits (see limit details
# here: https://docs.aws.amazon.com/devicefarm/latest/developerguide/limits.html#file-limits).
# These files will be available through the ListArtifacts API as your "Customer Artifacts".
artifacts:
# By default, Device Farm will collect your artifacts from the $DEVICEFARM_LOG_DIR directory.
- $DEVICEFARM_LOG_DIR
```
------
# Hosts para ambientes de teste personalizados
O Device Farm oferece suporte a um conjunto de sistemas operacionais com software pré-configurado por meio do uso de um ambiente de host de teste. Durante a execução do teste, o Device Farm utiliza instâncias gerenciadas pela Amazon (hosts) que se conectam dinamicamente ao dispositivo selecionado em teste. Essa instância é totalmente limpa e não é reutilizada entre as execuções e é encerrada com os artefatos gerados após a conclusão da execução do teste.
**Topics**
+ [Hosts de teste disponíveis para ambientes de teste personalizados](#custom-test-environments-hosts-available)
+ [Seleção de um host de teste para ambientes de teste personalizados](#test-host-selection)
+ [Software compatível em ambientes de teste personalizados](custom-test-environments-hosts-software.md)
+ [Ambiente de teste para dispositivos Android](custom-test-environments-hosts-android.md)
+ [Ambiente de teste para dispositivos iOS](custom-test-environments-hosts-ios.md)
## Hosts de teste disponíveis para ambientes de teste personalizados
Os hosts de teste são totalmente gerenciados pelo Device Farm. A tabela a seguir lista os hosts de teste Device Farm atualmente disponíveis e compatíveis para ambientes de teste personalizados.
| Plataforma de dispositivos | Host de teste | Sistema operacional | Arquitetura (s) | Dispositivos compatíveis |
| --- | --- | --- | --- | --- |
| Android | amazon\$1linux\$12 | Amazon Linux 2 | x86\$164 | Android6 e acima |
| iOS | macos\$1sequoia | macOS Sequoia(versão 15) | arm64 | iOS15 a 26 |
**nota**
Periodicamente, o Device Farm adiciona novos hosts de teste para uma plataforma de dispositivo para oferecer suporte às versões mais recentes do sistema operacional do dispositivo e suas dependências. Quando isso ocorre, os hosts de teste mais antigos da respectiva plataforma do dispositivo estão sujeitos ao fim do suporte.
### Versão do sistema operacional
Cada host de teste disponível usa uma versão específica do sistema operacional compatível com o Device Farm no momento. Embora tentemos usar a versão mais recente do sistema operacional, essa pode não ser a versão mais recente distribuída publicamente disponível. O Device Farm atualizará periodicamente o sistema operacional com pequenas atualizações de versão e patches de segurança.
Para saber a versão específica (incluindo a versão secundária) do sistema operacional em uso durante a execução do teste, você pode adicionar o seguinte trecho de código a qualquer uma das fases do arquivo de especificação de teste.
**Example**
```
phases:
install:
commands:
# The following example prints the instance's operating system version details
- |-
if [[ "Darwin" == "$(uname)" ]]; then
echo "$(sw_vers --productName) $(sw_vers --productVersion) ($(sw_vers --buildVersion))";
else
echo "$(. /etc/os-release && echo $PRETTY_NAME) ($(uname -r))";
fi
```
## Seleção de um host de teste para ambientes de teste personalizados
Você pode especificar o host de teste do Android e do iOS nas `ios_test_host` variáveis apropriadas `android_test_host` do seu [arquivo de especificação de teste](custom-test-environment-test-spec.md#custom-test-environment-test-spec-syntax).
Se você não especificar uma seleção de host de teste para a plataforma de dispositivo especificada, os testes serão executados no host de teste que o Device Farm definiu como padrão para o dispositivo e a configuração de teste especificados.
**Importante**
Ao testar no iOS 18 e versões anteriores, um host de teste legado será usado quando um host não for selecionado. Para obter mais informações, consulte o tópico no[Host de teste iOS antigo](custom-test-environments-hosts-ios.md#legacy-ios-host).
Como exemplo, analise o seguinte trecho de código:
**Example**
```
version: 0.1
android_test_host: amazon_linux_2
ios_test_host: macos_sequoia
phases:
# ...
```
# Software compatível em ambientes de teste personalizados
O Device Farm usa máquinas host pré-instaladas com muitas das bibliotecas de software necessárias para executar estruturas de teste suportadas em nosso serviço, fornecendo um ambiente de teste pronto para o lançamento. O Device Farm oferece suporte a vários idiomas por meio do uso de nosso mecanismo de seleção de software e atualizará periodicamente as versões dos idiomas incluídos no ambiente.
Para qualquer outro software necessário, você pode modificar o arquivo de especificação de teste para instalar pelo pacote de testes, fazer o download da Internet ou acessar origens privadas na VPC (consulte [VPC ENI](https://docs.aws.amazon.com//devicefarm/latest/developerguide/vpc-eni.html) para obter mais informações). Para obter mais informações, consulte [Exemplos de especificações de teste](custom-test-environment-test-spec.md#custom-test-environment-test-spec-example).
## Software pré-configurado
Para facilitar o teste de dispositivos em cada plataforma, as seguintes ferramentas são fornecidas no host de teste:
| Ferramentas | Plataforma (s) do dispositivo |
| --- | --- |
| Android SDK Build-Tools | Android |
| Android SDK Platform-Tools(inclui`adb`) | Android |
| Xcode | iOS |
## Software selecionável
Além do software pré-configurado no host, o Device Farm oferece uma maneira de selecionar determinadas versões do software compatível por meio das `devicefarm-cli` ferramentas.
A tabela a seguir contém o software selecionável e os hosts de teste que o contêm.
| Software/Ferramenta | Hosts que oferecem suporte a este software | Comando a ser usado em sua especificação de teste |
| --- | --- | --- |
| Java 17 | amazon\$1linux\$12 macos\$1sequoia | `devicefarm-cli use java 17` |
| Java 11 | amazon\$1linux\$12 macos\$1sequoia | `devicefarm-cli use java 11` |
| Java 8 | amazon\$1linux\$12 macos\$1sequoia | `devicefarm-cli use java 8` |
| Node.js 20 | amazon\$1linux\$12 macos\$1sequoia | `devicefarm-cli use node 20` |
| Node.js 18 | amazon\$1linux\$12 macos\$1sequoia | `devicefarm-cli use node 18` |
| Node.js 16 | amazon\$1linux\$12 | `devicefarm-cli use node 16` |
| Python 3.11 | amazon\$1linux\$12 macos\$1sequoia | `devicefarm-cli use python 3.11` |
| Python 3.10 | amazon\$1linux\$12 macos\$1sequoia | `devicefarm-cli use python 3.10` |
| Python 3.9 | amazon\$1linux\$12 macos\$1sequoia | `devicefarm-cli use python 3.9` |
| Python 3.8 | amazon\$1linux\$12 | `devicefarm-cli use python 3.8` |
| Ruby 3.2 | amazon\$1linux\$12 macos\$1sequoia | `devicefarm-cli use ruby 3.2` |
| Ruby 2.7 | amazon\$1linux\$12 | `devicefarm-cli use ruby 2.7` |
| Appium 3 | amazon\$1linux\$12 | `devicefarm-cli use appium 3` |
| Appium 2 | amazon\$1linux\$12 macos\$1sequoia | `devicefarm-cli use appium 2` |
| Appium 1 | amazon\$1linux\$12 | `devicefarm-cli use appium 1` |
| Xcode 26 | macos\$1sequoia | `devicefarm-cli use xcode 26` |
| Xcode 16 | macos\$1sequoia | `devicefarm-cli use xcode 16` |
O host de teste também inclui ferramentas de suporte comumente usadas para cada versão do software, como gerenciadores de `npm` pacotes `pip` e (incluídos no Python e no Node.js, respectivamente) e dependências (como o UIAutomator2 driver Appium) para ferramentas como o Appium. Isso garante que você tenha as ferramentas necessárias para trabalhar com as estruturas de teste compatíveis.
# Usando a ferramenta devicefarm-cli em ambientes de teste personalizados
O host de teste usa uma ferramenta padronizada de gerenciamento de versões chamada ` devicefarm-cli` para selecionar versões de software. Essa ferramenta é separada da AWS CLI e está disponível somente no host de teste do Device Farm. Com a `devicefarm-cli`, você pode alternar para qualquer versão de software pré-instalada no host de teste. Isso proporciona uma maneira direta de manter o arquivo de especificações de teste do Device Farm ao longo do tempo e oferece um mecanismo previsível para atualizar as versões do software no futuro.
**Importante**
Essa ferramenta de linha de comando não está disponível em hosts iOS antigos. Para obter mais informações, consulte o tópico no[Host de teste iOS antigo](custom-test-environments-hosts-ios.md#legacy-ios-host).
O trecho abaixo mostra a página de `help` da `devicefarm-cli`:
```
$ devicefarm-cli help
Usage: devicefarm-cli COMMAND [ARGS]
Commands:
help Prints this usage message.
list Lists all versions of software configurable
via this CLI.
use Configures the software for usage within the
current shell's environment.
```
Vamos analisar alguns exemplos usando a `devicefarm-cli`. Para usar a ferramenta para alterar a versão do Python de *3.10* para *3.9* em seu arquivo de especificação de teste, execute os seguintes comandos:
```
$ python --version
Python 3.10.12
$ devicefarm-cli use python 3.9
$ python --version
Python 3.9.17
```
Para alterar a versão do Appium de *1* para: *2*
```
$ appium --version
1.22.3
$ devicefarm-cli use appium 2
$ appium --version
2.1.2
```
**dica**
Observe que, quando você seleciona uma versão de software, a `devicefarm-cli` também alterna as ferramentas de suporte para essas linguagens, como `pip` para Python e `npm` para NodeJS.
Para obter mais informações sobre o software pré-instalado no host de teste, consulte[Software compatível em ambientes de teste personalizados](custom-test-environments-hosts-software.md).
# Ambiente de teste para dispositivos Android
O AWS Device Farm utiliza máquinas host Amazon Elastic Compute Cloud (EC2) executando o Amazon Linux 2 para executar testes do Android. Quando você agenda uma execução de teste, o Device Farm aloca um host dedicado para cada dispositivo para executar testes de forma independente. As máquinas host são encerradas após a execução do teste junto com todos os artefatos gerados.
O host Amazon Linux 2 oferece várias vantagens:
+ **Testes mais rápidos e confiáveis**: em comparação com o host antigo, o novo host de teste melhora significativamente a velocidade do teste, especialmente reduzindo os tempos de início do teste. O host Amazon Linux 2 também demonstra maior estabilidade e confiabilidade durante os testes.
+ **Acesso remoto aprimorado para testes manuais**: as atualizações para o host de teste mais recente e as melhorias resultam em menor latência e melhor desempenho de vídeo para testes manuais do Android.
+ **Seleção de versão de software padrão**: o Device Farm agora padroniza o suporte às principais linguagens de programação no host de teste, bem como nas versões de estrutura do Appium. Para linguagens compatíveis (atualmente Java, Python, Node.js e Ruby) e Appium, o novo host de teste fornece versões estáveis de longo prazo logo após o lançamento. O gerenciamento centralizado de versões por meio da ferramenta `devicefarm-cli` permite o desenvolvimento de arquivos de especificações de teste com uma experiência consistente entre as estruturas.
**Topics**
+ [Intervalos de IP aceitos para o ambiente de teste do Amazon Linux 2 no Device Farm](amazon-linux-2-ip-ranges.md)
# Intervalos de IP aceitos para o ambiente de teste do Amazon Linux 2 no Device Farm
Os clientes geralmente precisam saber o intervalo de IP do qual o tráfego do Device Farm se origina, principalmente para definir seus firewalls e configurações de segurança. Em relação aos hosts de teste do Amazon EC2, o intervalo de IP abrange toda a região `us-west-2`. Em relação aos hosts de teste do Amazon Linux 2, que é a opção padrão para novas execuções do Android, os intervalos foram restritos. O tráfego agora se origina de um conjunto específico de gateways NAT, restringindo o intervalo de IP aos seguintes endereços:
****
| Intervalos de IP |
| --- |
| **44.236.137.143** |
| **52.13.151.244** |
| **52.35.189.191** |
| **54.201.250.26** |
Para acessar mais informações sobre ambientes de teste no Device Farm, consulte [Ambiente de teste para dispositivos Android](custom-test-environments-hosts-android.md).
# Ambiente de teste para dispositivos iOS
O Device Farm utiliza instâncias macOS gerenciadas pela Amazon (hosts) que se conectam dinamicamente ao dispositivo iOS durante a execução do teste. Cada host é pré-configurado com um software que permite testar dispositivos em várias plataformas de teste populares, como XCTest UI e Appium.
A iteração atual do host de teste do iOS melhorou a experiência de teste em comparação com as versões anteriores, incluindo:
+ **Experiência consistente de sistema operacional e ferramentas do iOS 15 ao iOS 26** Antes, o host de teste era determinado pelo dispositivo em uso, resultando em um ambiente de software fragmentado ao ser executado em várias versões do iOS. A experiência atual permite uma seleção simples de hosts para permitir um ambiente consistente em todos os dispositivos. Isso permitirá que a mesma versão e ferramentas do macOS (como o Xcode) estejam disponíveis em cada dispositivo iOS.
+ **Melhorias no desempenho dos testes do iOS 15 e 16** Usando a infraestrutura atualizada, o tempo de configuração melhorou substancialmente para os testes do iOS 15 e 16.
+ **Versões padronizadas de software selecionáveis para dependências suportadas** Agora temos o sistema de seleção de `devicefarm-cli` software nos hosts de teste iOS e Android, permitindo que você selecione sua versão preferida de nossas dependências suportadas. Para dependências compatíveis (como Java, Python, Node.js, Ruby e Appium), as versões poderão ser selecionadas por meio da especificação de teste. Para ter uma ideia de como esse recurso funciona, consulte o tópico em[Software compatível em ambientes de teste personalizados](custom-test-environments-hosts-software.md).
**Importante**
Se estiver executando no iOS 18 e versões anteriores, seus testes serão executados em hosts de teste legados por padrão. Veja o tópico abaixo sobre como migrar dos hosts legados.
## Host de teste iOS antigo
Para testes existentes no iOS 18 e versões anteriores, os hosts de teste legados são selecionados por padrão para ambientes de teste personalizados. A tabela a seguir contém a versão do host de teste que é executada pela versão do dispositivo iOS.
| Sistema operacional | Arquitetura (s) | Padrão para dispositivos |
| --- | --- | --- |
| macOS Sonoma(versão 14) | arm64 | iOS 18 |
| macOS Ventura(versão 13) | arm64 | iOS 17 |
| macOS Monterey(versão 12) | x86\$164 | iOS 16e abaixo |
Para selecionar os hosts de teste mais novos, consulte o tópico relacionado[Migrando seus ambientes de teste personalizados para os novos hosts de teste do iOS](ios-host-migration.md).
## Software compatível para dispositivos iOS
Para oferecer suporte aos testes de dispositivos iOS, os hosts de teste do Device Farm para dispositivos iOS vêm pré-configurados com o Xcode e suas ferramentas de linha de comando associadas. Para outros softwares disponíveis, consulte o tópico relacionado[Software compatível em ambientes de teste personalizados](custom-test-environments-hosts-software.md).
# Migrando seus ambientes de teste personalizados para os novos hosts de teste do iOS
Para migrar os testes existentes do host legado para o novo host de teste do macOS, você precisará desenvolver novos arquivos de especificação de teste com base nos arquivos preexistentes.
A abordagem recomendada é começar com o exemplo de arquivo de especificação de teste para os tipos de teste desejados e, em seguida, migrar os comandos relevantes do arquivo de especificação de teste antigo para o novo. Isso permite que você aproveite novos recursos e otimizações da especificação de teste de exemplo para o novo host enquanto reutiliza trechos do código existente.
**Topics**
+ [Tutorial: migrando arquivos de especificações de teste do iOS com o console](#ios-host-migration-console-tutorial)
+ [Diferenças entre os hosts de teste novos e os antigos](#ios-host-migration-differences)
## Tutorial: migrando arquivos de especificações de teste do iOS com o console
Neste exemplo, o console Device Farm será usado para integrar uma especificação de teste de dispositivo iOS existente para usar o novo host de teste.
### Etapa 1: Criar novos arquivos de especificação de teste com o console
1. Faça login no [console do AWS Device Farm](https://console.aws.amazon.com/devicefarm).
1. Navegue até o projeto do Device Farm que contém seus testes de automação.
1. Faça o download de uma cópia da especificação de teste existente com a qual você deseja integrar.
1. Clique na opção “Configurações do projeto” e navegue até a guia **Uploads**.
1. Navegue até o arquivo de especificação de teste com o qual você deseja integrar.
1. Clique no botão **Download** para fazer uma cópia local desse arquivo.
1. Navegue de volta para a página do projeto e clique em **Criar execução**.
1. Preencha as opções no assistente como se fosse iniciar uma nova execução, mas pare na opção **Selecionar especificação de teste**.
1. Usando a especificação de teste do iOS selecionada por padrão, clique no botão **Criar uma especificação de teste**.
1. Modifique a especificação do teste que foi selecionada por *padrão* no editor de texto.
1. Se ainda não estiver presente, modifique o arquivo de especificação de teste para selecionar o novo host usando:
```
ios_test_host: macos_sequoia
```
1. A partir da cópia de sua especificação de teste baixada em uma etapa anterior, revise cada ` phase` uma.
1. Copie comandos das fases da especificação de teste antiga para cada fase respectiva na nova especificação de teste, ignorando os comandos relacionados à instalação ou seleção de Java, Python, Node.js, Ruby, Appium ou Xcode.
1. Insira um novo nome de arquivo na caixa de texto **Salvar como**.
1. Clique no botão **Salvar como novo** para salvar suas alterações.
Para ver um exemplo de um arquivo de especificação de teste que você pode usar como referência, consulte o exemplo fornecido em[Exemplos de especificações de teste](custom-test-environment-test-spec.md#custom-test-environment-test-spec-example).
### Etapa 2: Selecionar software pré-instalado
No novo host de teste, as versões pré-instaladas do software são selecionadas usando uma nova ferramenta padronizada de gerenciamento de versões chamada. `devicefarm-cli` Agora, esse conjunto de ferramentas é a abordagem recomendada para usar os vários softwares que fornecemos nos hosts de teste.
Como exemplo, você adicionaria a seguinte linha para usar um JDK 17 diferente em seu ambiente de teste:
```
- devicefarm-cli use java 17
```
Para obter mais informações sobre o software suportado disponível, revise:[Software compatível em ambientes de teste personalizados](custom-test-environments-hosts-software.md).
### Etapa 3: Usando o Appium e suas dependências por meio das ferramentas de seleção de software
O novo host de teste suporta apenas o Appium 2.x e superior. Selecione explicitamente a versão do Appium usando o`devicefarm-cli`, enquanto remove ferramentas legadas, como. ` avm` Por exemplo:
```
# This line using 'avm' should be removed
# - avm 2.3.1
# And the following lines should be added
- devicefarm-cli use appium 2 # Selects the version
- appium --version # Prints the version
```
A versão do Appium selecionada `devicefarm-cli` vem pré-instalada com uma versão compatível do driver XCUITest para iOS.
Além disso, você precisará atualizar sua especificação de teste para usar ` DEVICEFARM_APPIUM_WDA_DERIVED_DATA_PATH_V9` em vez de` DEVICEFARM_WDA_DERIVED_DATA_PATH`. A nova variável de ambiente aponta para uma versão pré-construída da WebDriverAgent 9.x, que é a versão mais recente compatível com os testes do Appium 2.
Para obter mais informações, revise [Seleção de uma WebDriverAgent versão para testes do iOS](test-types-appium.md#test-types-appium-select-wda) [Variáveis de ambiente para testes Appium](custom-test-environment-variables.md#custom-test-environment-variables-appium) e.
## Diferenças entre os hosts de teste novos e os antigos
Ao editar seu arquivo de especificação de teste para usar o novo host de teste do iOS e fazer a transição dos testes do host de teste legado, esteja ciente dessas principais diferenças de ambiente:
+ **Versões do Xcode:** no ambiente antigo do host de teste, a versão do Xcode disponível foi baseada na versão iOS do dispositivo usado para testes. Por exemplo, testes em dispositivos iOS 18 usaram o Xcode 16 no host legado, enquanto os testes no iOS 17 usaram o Xcode 15. No novo ambiente host, todos os dispositivos podem acessar as mesmas versões do Xcode, permitindo um ambiente consistente para testes em dispositivos com versões diferentes. Para obter uma lista das versões do Xcode atualmente disponíveis, consulte[Software compatível](custom-test-environments-hosts-software.md).
+ **Seleção de versões de software:** em muitos casos, as versões padrão do software foram alteradas. Portanto, se você não estava selecionando explicitamente sua versão de software no host de teste legado antes, talvez queira especificá-la agora no novo host de teste usando [`devicefarm-cli`](custom-test-environments-hosts-software-cli.md). Na grande maioria dos casos de uso, recomendamos que os clientes selecionem explicitamente as versões do software que usam. Ao selecionar uma versão de software, `devicefarm-cli` você terá uma experiência previsível e consistente com ela e receberá muitos avisos se a Device Farm planejar remover essa versão do host de teste.
Além disso, ferramentas de seleção de software como `nvm`, `pyenv`, ` avm` e `rvm` foram removidas em favor do novo sistema de seleção de software ` devicefarm-cli`.
+ **Versões de software disponíveis:** muitas versões do software pré-instalado anteriormente foram removidas e muitas novas versões foram adicionadas. Portanto, ao usar a `devicefarm-cli` para selecionar suas versões de software, você deve selecionar as versões que estão na [lista de versões compatíveis](custom-test-environments-hosts-software.md).
+ **O `libimobiledevice` conjunto de ferramentas foi removido** em favor de ferramentas mais novas/originais para monitorar os testes atuais de dispositivos iOS e os padrões do setor. Para o iOS 17 e versões posteriores, você pode migrar a maioria dos comandos para usar ferramentas semelhantes do Xcode, chamadas. `devicectl` Para obter informações sobre`devicectl`, você pode executar `xcrun devicectl help` a partir de uma máquina com o Xcode instalado.
+ Os **caminhos de arquivo codificados** no arquivo de especificação de teste do host legado como caminhos absolutos provavelmente não funcionarão conforme o esperado no novo host de teste e geralmente não são recomendados para o uso do arquivo de especificação de teste. Recomendamos que você use caminhos relativos e variáveis de ambiente para todo o código do arquivo de especificação de teste. Para obter mais informações, consulte o tópico em[Práticas recomendadas para execução de ambientes de teste personalizados](custom-test-environments-best-practices.md).
+ **Versão e arquitetura do sistema operacional:** os hosts de teste antigos estavam usando uma variedade de versões do macOS e arquiteturas de CPU com base no dispositivo atribuído. Como resultado, os usuários podem notar algumas diferenças nas bibliotecas de sistema disponíveis no ambiente. Para obter mais informações sobre a versão anterior do sistema operacional host, revise[Host de teste iOS antigo](custom-test-environments-hosts-ios.md#legacy-ios-host).
+ **Para usuários do Appium**, a forma de selecionar o WebDriverAgent mudou para um prefixo de variável de ambiente de uso ` DEVICEFARM_APPIUM_WDA_DERIVED_DATA_PATH_V` em vez do prefixo antigo. ` DEVICEFARM_WDA_DERIVED_DATA_PATH_V` Para obter mais informações sobre a variável atualizada, revise[Variáveis de ambiente para testes Appium](custom-test-environment-variables.md#custom-test-environment-variables-appium).
+ **Para usuários do Appium Java**, o novo host de teste não contém nenhum arquivo JAR pré-instalado em seu caminho de classe, enquanto o host anterior continha um para a estrutura TestNG (por meio de uma variável de ambiente). `$DEVICEFARM_TESTNG_JAR` Recomendamos que os clientes empacotem os arquivos JAR necessários para suas estruturas de teste dentro do pacote de teste e removam instâncias da variável `$DEVICEFARM_TESTNG_JAR` de seus arquivos de especificação de teste.
Recomendamos que entre em contato com a equipe de serviço por meio de um caso de suporte se tiver algum feedback ou dúvida sobre as diferenças entre os hosts de teste do ponto de vista do software.
# Acesse os recursos da AWS usando uma função de execução do IAM
O Device Farm suporta a especificação de uma função do IAM que será assumida pelo ambiente de execução de teste personalizado durante a execução do teste. Esse recurso permite que seus testes acessem com segurança os recursos da AWS em sua conta, como buckets do Amazon S3, tabelas do DynamoDB ou outros serviços da AWS dos quais seu aplicativo depende.
**Topics**
+ [Visão geral do](#iam-execution-role-overview)
+ [Requisitos de função do IAM](#iam-role-requirements)
+ [Configurando uma função de execução do IAM](#configuring-iam-execution-role)
+ [Práticas recomendadas](#iam-role-best-practices)
+ [Solução de problemas](#troubleshooting-iam-roles)
## Visão geral do
Quando você especifica uma função de execução do IAM, o Device Farm assume essa função durante a execução do teste, permitindo que seus testes interajam com os serviços da AWS usando as permissões definidas na função.
Os casos de uso comuns para funções de execução do IAM incluem:
+ Acessando dados de teste armazenados em buckets do Amazon S3
+ Enviando artefatos de teste para os buckets do Amazon S3
+ Recuperando a configuração do aplicativo da AWS AppConfig
+ Escrevendo registros de teste e métricas para a Amazon CloudWatch
+ Envio de resultados de testes ou mensagens de status para filas do Amazon SQS
+ Chamando funções do AWS Lambda como parte dos fluxos de trabalho de teste
## Requisitos de função do IAM
Para usar uma função de execução do IAM com o Device Farm, sua função deve atender aos seguintes requisitos:
+ **Relação de confiança**: o diretor do serviço Device Farm deve ser confiável para assumir a função. A política de confiança deve ser incluída `devicefarm.amazonaws.com` como uma entidade confiável.
+ **Permissões**: a função deve ter as permissões necessárias para acessar os recursos da AWS que seus testes exigem.
+ **Duração da sessão**: a duração máxima da sessão da função deve ser pelo menos tão longa quanto a configuração de tempo limite de trabalho do seu projeto Device Farm. Por padrão, os projetos do Device Farm têm um tempo limite de trabalho de 150 minutos, portanto, sua função deve suportar uma duração de sessão de pelo menos 150 minutos.
+ **Mesmo requisito de conta**: a função do IAM deve estar na mesma conta da AWS usada para chamar o Device Farm. A suposição de função entre contas não é suportada.
+ **PassRole permissão**: o chamador deve ser autorizado a transmitir a função do IAM por meio de uma política que permita a `iam:PassRole` ação na função de execução especificada.
### Exemplo de política de confiança
O exemplo a seguir mostra uma política de confiança que permite que o Device Farm assuma sua função de execução. Essa política de confiança só deve ser anexada à função específica do IAM que você pretende usar com o Device Farm, não a outras funções em sua conta:
**Example**
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "devicefarm.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
```
### Exemplo de política de permissões
O exemplo a seguir mostra uma política de permissões que concede acesso a serviços comuns da AWS usados em testes:
**Example**
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:PutObject",
"s3:ListBucket"
],
"Resource": [
"arn:aws:s3:::my-test-bucket",
"arn:aws:s3:::my-test-bucket/*"
]
},
{
"Effect": "Allow",
"Action": [
"appconfig:GetConfiguration",
"appconfig:StartConfigurationSession"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"logs:CreateLogGroup",
"logs:CreateLogStream",
"logs:PutLogEvents"
],
"Resource": "arn:aws:logs:*:*:log-group:/devicefarm/test-*"
},
{
"Effect": "Allow",
"Action": [
"sqs:SendMessage",
"sqs:GetQueueUrl"
],
"Resource": "arn:aws:sqs:*:*:test-results-*"
}
]
}
```
## Configurando uma função de execução do IAM
Você pode especificar uma função de execução do IAM no nível do projeto ou para execuções de teste individuais. Quando configuradas no nível do projeto, todas as execuções dentro desse projeto herdarão a função de execução. Uma função de execução configurada em uma execução substituirá qualquer função configurada em seu projeto principal.
Para obter instruções detalhadas sobre como configurar funções de execução, consulte:
+ [Criar um projeto no AWS Device Farm](how-to-create-project.md)- para configurar funções de execução no nível do projeto
+ [Criar uma execução de teste no Device Farm](how-to-create-test-run.md)- para configurar funções de execução para execuções individuais
Você também pode configurar funções de execução usando a API Device Farm. Para obter mais informações, consulte a [Device Farm API Reference](https://docs.aws.amazon.com/devicefarm/latest/APIReference/).
## Práticas recomendadas
Siga estas melhores práticas ao configurar as funções de execução do IAM para seus testes do Device Farm:
+ **Princípio do menor privilégio**: conceda somente as permissões mínimas necessárias para que seus testes funcionem. Evite usar permissões muito amplas, como `*` ações ou recursos.
+ **Use permissões específicas de recursos: quando possível, limite as permissões** a recursos específicos (por exemplo, buckets específicos do S3 ou tabelas do DynamoDB) em vez de todos os recursos de um tipo.
+ **Recursos de teste e produção separados**: use funções e recursos de teste dedicados para evitar afetar acidentalmente os sistemas de produção durante os testes.
+ **Revisão regular de funções: revise** e atualize periodicamente suas funções de execução para garantir que elas ainda atendam às suas necessidades de teste e sigam as melhores práticas de segurança.
+ **Use chaves de condição**: considere usar chaves de condição do IAM para restringir ainda mais quando e como a função pode ser usada.
## Solução de problemas
Se você encontrar problemas com as funções de execução do IAM, verifique o seguinte:
+ **Relação de confiança**: verifique se a política de confiança da função inclui `devicefarm.amazonaws.com` um serviço confiável.
+ **Permissões**: verifique se a função tem as permissões necessárias para os serviços da AWS que seus testes estão tentando acessar.
+ **Registros de teste**: revise os registros de execução do teste em busca de mensagens de erro específicas relacionadas a chamadas de API da AWS ou negações de permissão.
# Variáveis de ambiente para ambientes de teste personalizados
O Device Farm configura dinamicamente várias variáveis de ambiente para uso como parte da execução do seu ambiente de teste personalizado.
**Topics**
+ [Variáveis de ambiente personalizadas](#custom-test-environment-variables-custom)
+ [Variáveis de ambiente comuns](#custom-test-environment-variables-common)
+ [Variáveis de ambiente para testes Appium](#custom-test-environment-variables-appium)
+ [Variáveis de ambiente para XCUITest testes](#custom-test-environment-variables-xcuitest)
## Variáveis de ambiente personalizadas
O Device Farm suporta a configuração de pares de valores-chave que são aplicados como variáveis de ambiente no host de teste. Elas podem ser configuradas em um projeto Device Farm ou durante a criação da execução; qualquer variável configurada em uma execução substituirá qualquer variável que possa estar configurada em seu projeto principal. As seguintes restrições são aplicáveis:
+ Variáveis de ambiente personalizadas não são compatíveis com hosts de teste antigos do iOS. Para obter mais informações, consulte [Host de teste iOS antigo](custom-test-environments-hosts-ios.md#legacy-ios-host).
+ Os nomes das variáveis que começam com `$DEVICEFARM_` são reservados para uso interno do serviço.
+ Variáveis de ambiente personalizadas não podem ser usadas para configurar a seleção de computação do host de teste em sua especificação de teste.
## Variáveis de ambiente comuns
Esta seção descreve as variáveis de ambiente comuns a todos os testes no Device Farm.
** `$DEVICEFARM_DEVICE_NAME` **
O dispositivo no qual seus testes são executados. Ele representa o identificador exclusivo do dispositivo (UDID) do dispositivo.
** `$DEVICEFARM_DEVICE_UDID` **
O identificador exclusivo do dispositivo.
** `$DEVICEFARM_DEVICE_PLATFORM_NAME` **
O nome da plataforma do dispositivo. É `Android` ou `iOS`.
** `$DEVICEFARM_DEVICE_OS_VERSION` **
A versão do sistema operacional do dispositivo.
** `$DEVICEFARM_APP_PATH` **
*(testes de aplicativos móveis)*
O caminho do aplicativo para dispositivos móveis na máquina de host onde os testes estão sendo executados. Essa variável não está disponível durante os testes na web.
** `$DEVICEFARM_LOG_DIR` **
O caminho para o diretório padrão em que os registros, artefatos e outros arquivos desejados do cliente serão armazenados para recuperação posterior. Usando um [exemplo de especificação de teste](custom-test-environment-test-spec.md#custom-test-environment-test-spec-example), os arquivos nesse diretório são arquivados em um arquivo ZIP e disponibilizados como artefato após a execução do teste.
** `$DEVICEFARM_SCREENSHOT_PATH` **
O caminho das capturas de telas, se houver, capturadas durante a execução de teste.
** `$DEVICEFARM_PROJECT_ARN` **
O ARN do projeto principal do trabalho.
** `$DEVICEFARM_RUN_ARN` **
O ARN da execução principal do trabalho.
** `$DEVICEFARM_DEVICE_ARN` **
O ARN do dispositivo em teste.
** `$DEVICEFARM_TOTAL_JOBS` **
O número total de trabalhos associados à execução do Device Farm principal.
** `$DEVICEFARM_JOB_NUMBER` **
O número desse trabalho está dentro`$DEVICEFARM_TOTAL_JOBS`. Por exemplo, uma execução pode conter 5 trabalhos e cada um terá um intervalo `$DEVICEFARM_JOB_NUMBER` exclusivo de 0 a 4.
** `$AWS_REGION` **
A região da AWS. O serviço definirá isso para corresponder à região na qual o dispositivo em teste está localizado. Ela pode ser substituída por uma variável de ambiente personalizada, se necessário.
** `$ANDROID_HOME` **
*(Somente para Android)*
O caminho para o diretório de instalação do SDK do Android.
## Variáveis de ambiente para testes Appium
Esta seção descreve as variáveis de ambiente usadas por qualquer teste Appium em um ambiente de teste personalizado no Device Farm.
** `$DEVICEFARM_CHROMEDRIVER_EXECUTABLE_DIR` **
*(Somente para Android)*
A localização de um diretório que contém os ChromeDriver executáveis necessários para uso nos testes web e híbridos do Appium.
** `$DEVICEFARM_APPIUM_WDA_DERIVED_DATA_PATH_V` **
*(somente iOS)*
O caminho de dados derivado de uma versão WebDriverAgent criada para ser executada no Device Farm. A numeração na variável corresponderá à versão principal do WebDriverAgent. Como exemplo, `DEVICEFARM_APPIUM_WDA_DERIVED_DATA_PATH_V9` apontará para a WebDriverAgent versão 9.x. Para obter mais informações, consulte [Seleção de uma WebDriverAgent versão para testes do iOS](test-types-appium.md#test-types-appium-select-wda).
As variáveis de `$DEVICEFARM_APPIUM_WDA_DERIVED_DATA_PATH_V` ambiente só estão presentes em hosts iOS não legados. Para obter mais informações, consulte [Host de teste iOS antigo](custom-test-environments-hosts-ios.md#legacy-ios-host).
** `$DEVICEFARM_WDA_DERIVED_DATA_PATH_V9` **
*(somente iOS, obsoleto)*
O caminho de dados derivado de uma versão WebDriverAgent criada para ser executada no Device Farm. Consulte `$DEVICEFARM_APPIUM_WDA_DERIVED_DATA_PATH_V` para obter o esquema de nomenclatura de substituição.
## Variáveis de ambiente para XCUITest testes
Esta seção descreve as variáveis de ambiente usadas pelo XCUITest teste em um ambiente de teste personalizado no Device Farm.
** `$DEVICEFARM_XCUITESTRUN_FILE` **
O caminho para o `.xctestun` arquivo Device Farm. Ele é gerado com base nos pacotes de aplicativos e testes.
** `$DEVICEFARM_DERIVED_DATA_PATH` **
Caminho esperado da saída do xcodebuild do Device Farm.
** `$DEVICEFARM_XCTEST_BUILD_DIRECTORY` **
O caminho para o conteúdo descompactado do arquivo do pacote de teste.
# Práticas recomendadas para execução de ambientes de teste personalizados
Os tópicos a seguir abordam as melhores práticas recomendadas para usar a execução de testes personalizados com o Device Farm.
**Configuração da execução**
+ **Confie no software gerenciado do Device Farm e nos recursos da API para executar a configuração** sempre que possível, em vez de aplicar configurações semelhantes por meio de comandos shell no arquivo de especificação de teste. Isso inclui a configuração do host de teste e do dispositivo, pois será mais sustentável e consistente em todos os hosts e dispositivos de teste.
Embora o Device Farm incentive você a personalizar seu arquivo de especificação de teste o quanto for necessário para executar seus testes, a manutenção do arquivo de especificação de teste pode se tornar difícil com o tempo, à medida que mais comandos personalizados são adicionados a ele. Usando o software gerenciado do Device Farm (por meio de ferramentas como ` devicefarm-cli` e as ferramentas padrão disponíveis no`$PATH`) e usando recursos gerenciados (como o parâmetro de [https://docs.aws.amazon.com/devicefarm/latest/APIReference/API_ScheduleRunConfiguration.html#devicefarm-Type-ScheduleRunConfiguration-deviceProxy](https://docs.aws.amazon.com/devicefarm/latest/APIReference/API_ScheduleRunConfiguration.html#devicefarm-Type-ScheduleRunConfiguration-deviceProxy)solicitação) para simplificar o arquivo de especificação de teste, transferindo a responsabilidade da manutenção para o próprio Device Farm.
**Especificação de teste e código do pacote de teste**
+ **Não use caminhos absolutos nem confie em versões secundárias específicas** em seu arquivo de especificação de teste ou código de pacote de teste. O Device Farm aplica atualizações de rotina ao host de teste selecionado e às versões de software incluídas. Usar caminhos específicos ou absolutos (como ` /usr/local/bin/python` em vez de`python`) ou exigir versões secundárias específicas (como Node.js `20.3.1` em vez de apenas` 20`) pode fazer com que seus testes não consigam localizar o arquivo /executável necessário.
Como parte da execução personalizada do teste, o Device Farm configura várias variáveis de ambiente e a `$PATH` variável para garantir que os testes tenham uma experiência consistente em nossos ambientes dinâmicos. Consulte [Variáveis de ambiente para ambientes de teste personalizados](custom-test-environment-variables.md) e [Software compatível em ambientes de teste personalizados](custom-test-environments-hosts-software.md) para obter mais informações.
+ **Salve os arquivos gerados ou copiados no diretório temporário durante a execução do teste.** Hoje, garantimos que o diretório temporário (`/tmp`) esteja acessível ao usuário durante a execução do teste (além dos diretórios gerenciados, como o`$DEVICEFARM_LOG_DIR`). Outros diretórios aos quais o usuário tem acesso podem mudar com o tempo devido às necessidades do serviço ou do sistema operacional em uso.
+ **Salve seus registros de execução de teste em `$DEVICEFARM_LOG_DIR`**. Esse é o diretório de artefatos padrão fornecido para sua execução para adicionar logs/artefatos de execução. Cada um dos [exemplos de especificações de teste](custom-test-environment-test-spec.md#custom-test-environment-test-spec-example) que fornecemos usa esse diretório para artefatos por padrão.
+ **Certifique-se de que seus comandos retornem um código diferente de zero em caso de falha** durante a `test` fase de sua especificação de teste. Determinamos se sua execução falhou verificando se há um código de saída diferente de zero de cada comando shell invocado durante a `test` fase. Você deve garantir que sua lógica ou estrutura de teste retorne um código de saída diferente de zero para todos os cenários desejados, o que pode exigir configuração adicional.
Por exemplo, certas estruturas de teste (como JUnit5) não consideram a execução de zero testes uma falha, o que fará com que seus testes sejam detectados como tendo sido executados com êxito, mesmo que nada tenha sido executado. Usando JUnit5 como exemplo, você precisaria especificar a opção de linha de comando `--fail-if-no-tests` para garantir que esse cenário saia com um código de saída diferente de zero.
+ **Analise a compatibilidade do software** com a versão do sistema operacional do dispositivo e a versão do host de teste que você usará para a execução do teste. Por exemplo, há certos recursos nas estruturas de software de teste (por exemplo: Appium) que podem não funcionar conforme o esperado em todas as versões do sistema operacional do dispositivo que está sendo testado.
**Segurança**
+ **Evite armazenar ou registrar variáveis confidenciais (como chaves da AWS) em seu arquivo de especificação de teste.** Os arquivos da especificação de teste, os scripts gerados pela especificação de teste e os registros do script da especificação de teste são todos fornecidos como artefatos que podem ser baixados no final da execução do teste. Isso pode levar à exposição não intencional de segredos para outros usuários em sua conta com acesso de leitura ao seu teste.
# Migrar testes de um ambiente padrão para um ambiente de teste personalizado
Você pode alternar de um modo de execução de teste padrão para um modo de execução personalizado no AWS Device Farm. A migração envolve principalmente duas formas diferentes de execução:
1. **Modo padrão**: esse modo de execução de teste foi criado principalmente para fornecer aos clientes relatórios granulares e um ambiente totalmente gerenciado.
1. **Modo personalizado**: esse modo de execução de teste foi criado para diferentes casos de uso que exigem execuções de teste mais rápidas, a capacidade de mover sem alterações (lift-and-shift) e alcançar a paridade com o ambiente local e streaming de vídeo ao vivo.
Para acessar mais informações sobre os modos padrão e personalizado no Device Farm, consulte [Ambientes de teste no AWS Device Farm](test-environments.md) e [Ambiente de teste personalizado no AWS Device Farm.](custom-test-environments.md).
## Considerações ao migrar
Esta seção lista alguns dos principais casos de uso a serem considerados ao migrar para o modo personalizado:
1. **Velocidade**: no modo padrão de execução, o Device Farm analisa os metadados dos testes que você empacotou e carregou usando as instruções de empacotamento de sua estrutura específica. A análise detecta o número de testes em seu pacote. Depois disso, o Device Farm executa cada teste separadamente e apresenta os logs, vídeos e outros artefatos de resultados individualmente para cada teste. No entanto, isso aumenta constantemente o tempo total de execução do end-to-end teste, pois há o pré e o pós-processamento de testes e artefatos de resultados no final do serviço.
Por outro lado, o modo de execução personalizado não analisa seu pacote de teste; isso significa nenhum pré-processamento e um pós-processamento mínimo para testes ou artefatos de resultados. Isso resulta em tempos totais de end-to-end execução próximos à sua configuração local. Os testes são executados no mesmo formato em que seriam se fossem executados nas máquinas locais. Os resultados dos testes são os mesmos que você obtém localmente e estão disponíveis para download no final da execução do trabalho.
1. **Personalização ou flexibilidade**: o modo padrão de execução analisa seu pacote de teste para detectar o número de testes e, em seguida, executa cada teste separadamente. Observe que não há garantia de que os testes serão executados na ordem especificada. Como resultado, os testes que exigem uma sequência específica de execução podem não funcionar conforme o esperado. Além disso, não há como personalizar o ambiente da máquina host ou passar arquivos de configuração que possam ser necessários para executar seus testes de uma determinada maneira.
Por outro lado, o modo personalizado permite que você configure o ambiente da máquina host, incluindo a capacidade de instalar software adicional, passar filtros para seus testes, passar arquivos de configuração e controlar a configuração da execução do teste. Ele consegue isso por meio de um arquivo yaml (também chamado de arquivo testspec) que você pode modificar adicionando comandos shell a ele. Esse arquivo yaml é convertido em um script de shell que é executado na máquina host de teste. Você pode salvar vários arquivos yaml e escolher um dinamicamente de acordo com seus requisitos ao agendar uma execução.
1. **Vídeo ao vivo e registro em log**: os modos de execução padrão e personalizado fornecem vídeos e logs para seus testes. No entanto, no modo padrão, você obtém o vídeo e os logs predefinidos de seus testes somente após a conclusão dos testes.
Por outro lado, o modo personalizado oferece uma transmissão ao vivo do vídeo e dos logs de seus testes do lado do cliente. Além disso, você pode baixar o vídeo e outros artefatos ao final dos testes.
**dica**
Se seu caso de uso envolver pelo menos um dos fatores acima, é altamente recomendável mudar para o modo de execução personalizado.
## Etapas da migração
Para migrar do modo Padrão para o modo Personalizado, faça o seguinte:
1. Faça login Console de gerenciamento da AWS e abra o console do Device Farm em [https://console.aws.amazon.com/devicefarm/](https://console.aws.amazon.com/devicefarm/).
1. Escolha seu projeto e, em seguida, inicie uma nova execução de automação.
1. Faça upload da aplicação (ou selecione `web app`), escolha o tipo de estrutura de teste, faça upload do pacote de teste e, no parâmetro `Choose your execution environment`, escolha a opção para `Run your test in a custom environment`.
1. Por padrão, o arquivo de exemplo de especificação de teste do Device Farm aparecerá para você visualizar e editar. Esse arquivo de exemplo pode ser usado como ponto de partida para testar seus testes no [modo de ambiente personalizado](https://docs.aws.amazon.com/devicefarm/latest/developerguide/custom-test-environments.html). Depois de verificar se seus testes estão funcionando corretamente no console, você pode alterar qualquer uma de suas integrações de API, CLI e pipeline com o Device Farm para usar esse arquivo de especificação de teste como parâmetro ao programar execuções de teste. Para obter informações sobre como adicionar um arquivo de especificação de teste como parâmetro para suas execuções, consulte a seção do parâmetro `testSpecArn` da API `ScheduleRun` em nosso [Guia de API](https://docs.aws.amazon.com/devicefarm/latest/APIReference/API_ScheduleRun.html).
## Estrutura do Appium
Em um ambiente de teste personalizado, o Device Farm não insere nem substitui nenhum recurso do Appium em seus testes da estrutura do Appium. Você deve especificar os recursos do Appium do teste no arquivo YAML da especificação de teste ou no código de teste.
## Instrumentação do Android
Você não precisa fazer alterações a fim de mover os testes de instrumentação do Android para um ambiente de teste personalizado.
## iOS XCUITest
Você não precisa fazer alterações para mover seus XCUITest testes do iOS para um ambiente de teste personalizado.
# Extensão de ambientes de teste personalizados no Device Farm
O AWS Device Farm permite configurar um ambiente personalizado para testes automatizados (modo personalizado), que é a abordagem recomendada para todos os usuários do Device Farm. O modo personalizado do Device Farm permite que você execute mais do que apenas seu pacote de testes. Nesta seção, você aprenderá como estender sua suíte de testes e otimizar seus testes.
Para acessar mais informações sobre ambientes de teste personalizados no Device Farm, consulte [Ambiente de teste personalizado no AWS Device Farm.](custom-test-environments.md).
**Topics**
+ [Configurar o PIN de um dispositivo ao executar testes no Device Farm](custom-test-environments-extending-set-pin.md)
+ [Acelerar os testes baseados no Appium nos recursos desejados do Device Farm](custom-test-environments-extending-speed.md)
+ [Usando Webhooks e outros APIs após a execução dos testes no Device Farm](custom-test-environments-extending-webhooks.md)
+ [Adicionar arquivos extras ao seu pacote de teste no Device Farm](custom-test-environments-extending-files.md)
# Configurar o PIN de um dispositivo ao executar testes no Device Farm
Algumas aplicações exigem que você defina um PIN no dispositivo. O Device Farm não é compatível com a configuração nativa de um PIN em dispositivos. No entanto, isso é possível com as seguintes ressalvas:
+ O dispositivo deve estar executando o Android 8 ou superior.
+ O PIN deve ser removido após a conclusão do teste.
Para definir o PIN em seus testes, use as fases `pre_test` e `post_test` para definir e remover o PIN, conforme mostrado a seguir:
```
phases:
pre_test:
- # ... among your pre_test commands
- DEVICE_PIN_CODE="1234"
- adb shell locksettings set-pin "$DEVICE_PIN_CODE"
post_test:
- # ... Among your post_test commands
- adb shell locksettings clear --old "$DEVICE_PIN_CODE"
```
Quando o conjunto de testes é iniciado, o PIN 1234 é definido. Depois que sua suíte de testes sair, o PIN será removido.
**Atenção**
Se você não remover o PIN do dispositivo após a conclusão do teste, o dispositivo e sua conta serão colocados em quarentena.
Para conhecer mais maneiras de estender seu pacote de testes e otimizar seus testes, consulte [Extensão de ambientes de teste personalizados no Device Farm](custom-test-environments-extending.md).
# Acelerar os testes baseados no Appium nos recursos desejados do Device Farm
Ao usar o Appium, você pode descobrir que o conjunto de testes do modo padrão é muito lento. Isso ocorre porque o Device Farm aplica as configurações padrão e não faz nenhuma suposição sobre como você deseja usar o ambiente Appium. Embora esses padrões sejam criados com base nas melhores práticas do setor, eles podem não se aplicar à sua situação. Para ajustar os parâmetros do servidor Appium, você pode ajustar os recursos padrão do Appium em sua especificação de teste. Por exemplo, o seguinte define o recurso `usePrebuildWDA` como `true` em um conjunto de testes do iOS para acelerar o tempo de início inicial:
```
phases:
pre_test:
- # ... Start up Appium
- >-
appium --log-timestamp
--default-capabilities "{\"usePrebuiltWDA\": true, \"derivedDataPath\":\"$DEVICEFARM_WDA_DERIVED_DATA_PATH\",
\"deviceName\": \"$DEVICEFARM_DEVICE_NAME\", \"platformName\":\"$DEVICEFARM_DEVICE_PLATFORM_NAME\", \"app\":\"$DEVICEFARM_APP_PATH\",
\"automationName\":\"XCUITest\", \"udid\":\"$DEVICEFARM_DEVICE_UDID_FOR_APPIUM\", \"platformVersion\":\"$DEVICEFARM_DEVICE_OS_VERSION\"}"
>> $DEVICEFARM_LOG_DIR/appiumlog.txt 2>&1 &
```
Os recursos do Appium devem ser uma estrutura JSON citada e com escape de shell.
Os seguintes recursos do Appium são fontes comuns de melhorias de desempenho:
`noReset` e `fullReset`
Esses dois recursos, que são mutuamente exclusivos, descrevem o comportamento do Appium após a conclusão de cada sessão. Quando `noReset` está definido como `true`, o servidor Appium não remove dados da aplicação quando uma sessão do Appium termina, efetivamente não fazendo nenhuma limpeza. `fullReset` desinstala e limpa todos os dados da aplicação do dispositivo após o encerramento da sessão. Para obter mais informações, consulte [Reset Strategies](http://appium.io/docs/en/writing-running-appium/other/reset-strategies/) na documentação do Appium.
`ignoreUnimportantViews` (somente Android)
Instrui o Appium a compactar a hierarquia da interface do usuário do Android somente em visualizações *relevantes* para o teste, acelerando as pesquisas de determinados elementos. No entanto, isso pode interromper alguns conjuntos de testes XPath baseados porque a hierarquia do layout da interface do usuário foi alterada.
`skipUnlock` (somente Android)
Informa à Appium que não há um código PIN definido atualmente, o que acelera os testes após um evento de desligamento da tela ou outro evento de bloqueio.
`webDriverAgentUrl` (somente iOS)
Instrui o Appium a assumir que uma dependência essencial do iOS, `webDriverAgent`, já está em execução e disponível para aceitar solicitações HTTP no URL especificado. Se `webDriverAgent` ainda não estiver instalado e funcionando, o Appium pode levar algum tempo no início de um conjunto de testes para iniciar o `webDriverAgent`. Se você iniciar `webDriverAgent` por conta própria e definir `webDriverAgentUrl` como `http://localhost:8100` ao iniciar o Appium, poderá inicializar o conjunto de testes mais rapidamente. Observe que esse recurso nunca deve ser usado junto com o recurso `useNewWDA`.
Você pode usar o código a seguir para iniciar `webDriverAgent` pelo arquivo de especificação de teste na porta local `8100` do dispositivo e, depois, encaminhá-lo para a porta local `8100` do host de teste (isso permite que você defina o valor de `webDriverAgentUrl` como `http://localhost:8100`). Esse código deve ser executado durante a fase de instalação após qualquer código para configurar o Appium e a definição das variáveis de ambiente `webDriverAgent`:
```
# Start WebDriverAgent and iProxy
- >-
xcodebuild test-without-building -project /usr/local/avm/versions/$APPIUM_VERSION/node_modules/appium/node_modules/appium-webdriveragent/WebDriverAgent.xcodeproj
-scheme WebDriverAgentRunner -derivedDataPath $DEVICEFARM_WDA_DERIVED_DATA_PATH
-destination id=$DEVICEFARM_DEVICE_UDID_FOR_APPIUM IPHONEOS_DEPLOYMENT_TARGET=$DEVICEFARM_DEVICE_OS_VERSION
GCC_TREAT_WARNINGS_AS_ERRORS=0 COMPILER_INDEX_STORE_ENABLE=NO >> $DEVICEFARM_LOG_DIR/webdriveragent_log.txt 2>&1 &
iproxy 8100 8100 >> $DEVICEFARM_LOG_DIR/iproxy_log.txt 2>&1 &
```
Depois, você pode adicionar o código a seguir ao arquivo de especificação de teste para garantir que `webDriverAgent` tenha iniciado com êxito. Esse código deve ser executado no final da fase de pré-teste depois de garantir que o Appium tenha sido iniciado com sucesso:
```
# Wait for WebDriverAgent to start
- >-
start_wda_timeout=0;
while [ true ];
do
if [ $start_wda_timeout -gt 60 ];
then
echo "WebDriverAgent server never started in 60 seconds.";
exit 1;
fi;
grep -i "ServerURLHere" $DEVICEFARM_LOG_DIR/webdriveragent_log.txt >> /dev/null 2>&1;
if [ $? -eq 0 ];
then
echo "WebDriverAgent REST http interface listener started";
break;
else
echo "Waiting for WebDriverAgent server to start. Sleeping for 1 seconds";
sleep 1;
start_wda_timeout=$((start_wda_timeout+1));
fi;
done;
```
Para obter mais informações sobre os recursos compatíveis com o Appium, consulte [Appium Desired Capabilities](http://appium.io/docs/en/writing-running-appium/caps/) na documentação do Appium.
Para conhecer mais maneiras de estender seu pacote de testes e otimizar seus testes, consulte [Extensão de ambientes de teste personalizados no Device Farm](custom-test-environments-extending.md).
# Usando Webhooks e outros APIs após a execução dos testes no Device Farm
Você pode fazer com que o Device Farm chame um webhook depois que cada conjunto de testes terminar de usar **curl**. O processo para fazer isso varia de acordo com o destino e a formatação. Para seu webhook específico, consulte a documentação desse webhook. O exemplo a seguir publica uma mensagem sempre que uma suíte de testes termina em um webhook do Slack:
```
phases:
post_test:
- curl -X POST -H 'Content-type: application/json' --data '{"text":"Tests on '$DEVICEFARM_DEVICE_NAME' have finished!"}' https://hooks.slack.com/services/T00000000/B00000000/XXXXXXXXXXXXXXXXXXXXXXXX
```
Para obter mais informações sobre como usar webhooks com o Slack, consulte [Sending your first Slack message using Webhook](https://api.slack.com/tutorials/slack-apps-hello-world) na referência de API do Slack.
Para conhecer mais maneiras de estender seu pacote de testes e otimizar seus testes, consulte [Extensão de ambientes de teste personalizados no Device Farm](custom-test-environments-extending.md).
Você não está limitado a usar **curl** para chamar webhooks. Os pacotes de teste podem incluir scripts e ferramentas extras, desde que sejam compatíveis com o ambiente de execução do Device Farm. Por exemplo, seu pacote de teste pode incluir scripts auxiliares que fazem solicitações a outros APIs. Certifique-se de que todos os pacotes necessários estejam instalados junto com os requisitos da sua suíte de testes. Para adicionar um script que seja executado após a conclusão da suíte de testes, inclua o script em seu pacote de teste e adicione o seguinte à sua especificação de teste:
```
phases:
post_test:
- python post_test.py
```
**nota**
A manutenção de todas as chaves de API ou outros tokens de autenticação usados em seu pacote de teste é de sua responsabilidade. Recomendamos que você mantenha qualquer forma de credencial de segurança fora do controle de origem, use credenciais com o menor número possível de privilégios e use tokens revogáveis e de curta duração sempre que possível. Para verificar os requisitos de segurança, consulte a documentação do terceiro APIs que você usa.
Se você planeja usar AWS serviços como parte de sua suíte de execução de testes, você deve usar credenciais temporárias do IAM, geradas fora da suíte de testes e incluídas no pacote de teste. Essas credenciais devem ter o menor número de permissões concedidas e a menor vida útil possível. Para obter mais informações sobre a criação de credenciais temporárias, consulte [Requesting temporary security credentials](https://docs.aws.amazon.com//IAM/latest/UserGuide/id_credentials_temp_request.html) no *Guia do usuário do IAM*.
Para conhecer mais maneiras de estender seu pacote de testes e otimizar seus testes, consulte [Extensão de ambientes de teste personalizados no Device Farm](custom-test-environments-extending.md).
# Adicionar arquivos extras ao seu pacote de teste no Device Farm
Talvez você queira usar arquivos adicionais como parte de seus testes como arquivos extras de configuração ou dados de teste adicionais. Você pode incluir esses arquivos adicionais ao seu pacote de testes antes de carregá-lo no AWS Device Farm e acessá-los no modo de ambiente personalizado. Basicamente, todos os formatos de upload de pacotes de teste (ZIP, IPA, APK, JAR etc.) são formatos de arquivamento de pacotes compatíveis com operações ZIP padrão.
Você pode adicionar arquivos ao seu arquivo de teste antes de enviá-lo AWS Device Farm usando o seguinte comando:
```
$ zip zip-with-dependencies.zip extra_file
```
Para um diretório de arquivos extras:
```
$ zip -r zip-with-dependencies.zip extra_files/
```
Esses comandos funcionam conforme o esperado para todos os formatos de upload de pacotes de teste, exceto para arquivos IPA. Para arquivos IPA, especialmente quando usados com XCUITests, recomendamos que você coloque os arquivos extras em um local um pouco diferente devido à forma como os pacotes de teste do AWS Device Farm iOS são resignados. Ao criar seu teste do iOS, o diretório do aplicativo de teste estará localizado dentro de outro diretório chamado*Payload*.
Por exemplo, é assim que um desses diretórios de teste do iOS pode parecer:
```
$ tree
.
└── Payload
└── ADFiOSReferenceAppUITests-Runner.app
├── ADFiOSReferenceAppUITests-Runner
├── Frameworks
│ ├── XCTAutomationSupport.framework
│ │ ├── Info.plist
│ │ ├── XCTAutomationSupport
│ │ ├── _CodeSignature
│ │ │ └── CodeResources
│ │ └── version.plist
│ └── XCTest.framework
│ ├── Info.plist
│ ├── XCTest
│ ├── _CodeSignature
│ │ └── CodeResources
│ ├── en.lproj
│ │ └── InfoPlist.strings
│ └── version.plist
├── Info.plist
├── PkgInfo
├── PlugIns
│ ├── ADFiOSReferenceAppUITests.xctest
│ │ ├── ADFiOSReferenceAppUITests
│ │ ├── Info.plist
│ │ └── _CodeSignature
│ │ └── CodeResources
│ └── ADFiOSReferenceAppUITests.xctest.dSYM
│ └── Contents
│ ├── Info.plist
│ └── Resources
│ └── DWARF
│ └── ADFiOSReferenceAppUITests
├── _CodeSignature
│ └── CodeResources
└── embedded.mobileprovision
```
Para esses XCUITest pacotes, adicione qualquer arquivo extra ao diretório que termina *.app* dentro do *Payload* diretório. Por exemplo, os comandos a seguir mostram como você pode adicionar um arquivo a esse pacote de teste:
```
$ mv extra_file Payload/*.app/
$ zip -r my_xcui_tests.ipa Payload/
```
Ao adicionar um arquivo ao seu pacote de teste, você pode esperar um comportamento de interação um pouco diferente no AWS Device Farm com base no formato de upload. Se o upload usou a extensão de arquivo ZIP, AWS Device Farm descompactará automaticamente o upload antes do teste e deixará os arquivos descompactados no local com a *\$1DEVICEFARM\$1TEST\$1PACKAGE\$1PATH* variável de ambiente. (Isso significa que se você adicionasse um arquivo chamado *extra\$1file* à raiz do arquivo, como no primeiro exemplo, ele estaria localizado *\$1DEVICEFARM\$1TEST\$1PACKAGE\$1PATH/extra\$1file* durante o teste).
Para usar um exemplo mais prático, se você for um usuário do Appium TestNG que deseja incluir um *testng.xml* arquivo com seu teste, você pode incluí-lo em seu arquivo usando o seguinte comando:
```
$ zip zip-with-dependencies.zip testng.xml
```
Em seguida, você pode alterar seu comando de teste no modo de ambiente personalizado para o seguinte:
```
java -D appium.screenshots.dir=$DEVICEFARM_SCREENSHOT_PATH org.testng.TestNG -testjar *-tests.jar -d $DEVICEFARM_LOG_DIR/test-output $DEVICEFARM_TEST_PACKAGE_PATH/testng.xml
```
Se a extensão de upload do pacote de teste não for ZIP (por exemplo, arquivo APK, IPA ou JAR), o arquivo do pacote enviado em si será encontrado em*\$1DEVICEFARM\$1TEST\$1PACKAGE\$1PATH*. Como esses ainda são arquivos em formato de arquivamento, você pode descompactar o arquivo para acessar os arquivos adicionais de dentro. Por exemplo, o comando a seguir descompactará o conteúdo do pacote de teste (para arquivos APK, IPA ou JAR) no */tmp* diretório:
```
unzip $DEVICEFARM_TEST_PACKAGE_PATH -d /tmp
```
No caso de um arquivo APK ou JAR, você encontraria seus arquivos extras descompactados no */tmp* diretório (por exemplo,*/tmp/extra\$1file*). No caso de um arquivo IPA, conforme explicado anteriormente, os arquivos extras estariam em um local ligeiramente diferente dentro da pasta que termina em*.app*, que está dentro do *Payload* diretório. Por exemplo, com base no exemplo do IPA acima, o arquivo seria encontrado no local */tmp/Payload/ADFiOSReferenceAppUITests-Runner.app/extra\$1file* (referenciável como). */tmp/Payload/\$1.app/extra\$1file*
Para conhecer mais maneiras de estender seu pacote de testes e otimizar seus testes, consulte [Extensão de ambientes de teste personalizados no Device Farm](custom-test-environments-extending.md).