Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà. # Ambienti di test personalizzati in AWS Device Farm AWS Device Farm consente di configurare un ambiente personalizzato per i test automatici (modalità personalizzata), che è l'approccio consigliato per tutti gli utenti di Device Farm. Per ulteriori informazioni sugli ambienti in Device Farm, consulta [Ambienti di test](https://docs.aws.amazon.com/devicefarm/latest/developerguide/test-environments.html). I vantaggi della modalità personalizzata rispetto alla modalità standard includono: + **Esecuzione più rapida end-to-end** dei test: il pacchetto di test non viene analizzato per rilevare tutti i test della suite, evitando il preprocessing/postprocessing sovraccarico. + **Registro live e streaming video**: i registri dei test e i video sul lato client vengono trasmessi in live streaming quando si utilizza la modalità personalizzata. Questa funzionalità non è disponibile nella modalità standard. + **Cattura tutti gli artefatti**: sull'host e sul dispositivo, la modalità personalizzata consente di acquisire tutti gli artefatti di test. Ciò potrebbe non essere possibile nella modalità standard. + **Ambiente locale più coerente e replicabile**: in modalità standard, gli artefatti verranno forniti separatamente per ogni singolo test, il che può essere utile in determinate circostanze. Tuttavia, l'ambiente di test locale potrebbe differire dalla configurazione originale poiché Device Farm gestisce ogni test eseguito in modo diverso. Al contrario, la modalità personalizzata consente di rendere l'ambiente di esecuzione dei test di Device Farm costantemente in linea con l'ambiente di test locale. Gli ambienti personalizzati sono configurati utilizzando un file di specifiche di test (test spec) in formato YAML. Device Farm fornisce un file di specifiche di test predefinito per ogni tipo di test supportato che può essere utilizzato così com'è o personalizzato; personalizzazioni come filtri di test o file di configurazione possono essere aggiunte alle specifiche di test. Le specifiche di test modificate possono essere salvate per future esecuzioni di test. Per ulteriori informazioni, consulta [Caricamento di una specifica di test personalizzata utilizzando and](https://docs.aws.amazon.com/devicefarm/latest/developerguide/how-to-create-test-run.html#how-to-create-test-run-cli-step5). AWS CLI[Creazione di un'esecuzione di test in Device Farm](how-to-create-test-run.md) **Topics** + [Riferimento e sintassi delle specifiche di test](custom-test-environment-test-spec.md) + [Host per ambienti di test personalizzati](custom-test-environments-hosts.md) + [Accedi alle risorse AWS utilizzando un ruolo di esecuzione IAM](custom-test-environments-iam-roles.md) + [Variabili di ambiente per ambienti di test personalizzati](custom-test-environment-variables.md) + [Le migliori pratiche per l'esecuzione di ambienti di test personalizzati](custom-test-environments-best-practices.md) + [Migrazione dei test da un ambiente di test standard a un ambiente di test personalizzato](custom-test-environment-migration.md) + [Estensione degli ambienti di test personalizzati in Device Farm](custom-test-environments-extending.md) # Riferimento e sintassi delle specifiche di test La specifica di test (specifica del test) è un file che viene utilizzato per definire ambienti di test personalizzati in Device Farm. ## Flusso di lavoro delle specifiche di test La specifica di test di Device Farm esegue le fasi e i relativi comandi in un ordine predeterminato, consentendoti di personalizzare il modo in cui l'ambiente viene preparato ed eseguito. Quando ogni fase viene eseguita, i relativi comandi vengono eseguiti nell'ordine elencato nel file delle specifiche di test. Le fasi vengono eseguite nella seguente sequenza 1. `install`- È qui che devono essere definite azioni come il download, l'installazione e la configurazione degli strumenti. 1. `pre_test`- È qui che devono essere definite le azioni preliminari al test, come l'avvio di processi in background. 1. `test`- Qui deve essere definito il comando che richiama il test. 1. `post_test`- È qui che devono essere definite tutte le attività finali che devono essere eseguite dopo la conclusione del test, come la generazione di report di test e l'aggregazione di file di artefatti. ## Sintassi delle specifiche del test Di seguito è riportato lo schema YAML per un file di specifiche di test ``` 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` ** *(Obbligatorio, numero)* Riflette la versione delle specifiche di test supportata da Device Farm. Il numero della versione corrente è` 0.1`. ** `android_test_host` ** *(Opzionale, stringa)* L'host di test che verrà selezionato per le esecuzioni di test eseguite su dispositivi Android. Questo campo è obbligatorio per i test eseguiti su dispositivi Android. Per ulteriori informazioni, consulta [Host di test disponibili per ambienti di test personalizzati](custom-test-environments-hosts.md#custom-test-environments-hosts-available). ** `ios_test_host` ** *(Opzionale, stringa)* L'host di test che verrà selezionato per le esecuzioni di test eseguite su dispositivi iOS. Questo campo è obbligatorio per le esecuzioni di test su dispositivi iOS con una versione principale superiore a 26. Per ulteriori informazioni, consulta [Host di test disponibili per ambienti di test personalizzati](custom-test-environments-hosts.md#custom-test-environments-hosts-available). ** `phases` ** Questa sezione contiene gruppi di comandi eseguiti durante un'esecuzione di test, in cui ogni fase è facoltativa. I nomi delle fasi di test consentiti sono: `install``pre_test`,`test`, e`post_test`. + `install`- Le dipendenze predefinite per i framework di test supportati da Device Farm sono già installate. Questa fase contiene eventuali comandi aggiuntivi che Device Farm esegue durante l'installazione. + `pre_test`- I comandi, se presenti, eseguiti prima del test automatico. + `test`- I comandi eseguiti durante l'esecuzione del test automatico. Se un comando nella fase di test fallisce (il che significa che restituisce un codice di uscita diverso da zero), il test viene contrassegnato come fallito + `post_test`- I comandi, se presenti, eseguiti dopo l'esecuzione del test automatico. Questo verrà eseguito indipendentemente dal fatto che il test nella `test` fase abbia esito positivo o negativo. ** `commands` ** *(Facoltativo, List [string])* Un elenco di stringhe da eseguire come comando di shell durante la fase. ** `artifacts` ** *(Facoltativo, List [string])* Device Farm raccoglie artefatti come report personalizzati, file di registro e immagini da una posizione specificata qui. I caratteri jolly non sono supportati come parte della posizione di un artefatto, perciò devi specificare un percorso valido per ogni posizione. Questi artefatti di test sono disponibili per ciascun dispositivo nella tua sessione di test. Per informazioni sul recupero degli artefatti di test, consulta [Scaricamento di artefatti in un ambiente di test personalizzato](using-artifacts-custom.md). **Importante** Una specifica di test deve essere formattata come file YAML valido. Se l'indentazione o la spaziatura della tua specifica di test non è valida, il tuo test può non riuscire. Le schede non sono consentite nei file YAML. Puoi usare un validatore YAML per verificare se la tua specifica di test è un file YAML valido. Per ulteriori informazioni, consulta il [sito Web YAML](http://yaml.org/spec/1.2/spec.html). ## Esempi di specifiche di test Gli esempi seguenti mostrano le specifiche di test che possono essere eseguite su Device Farm. ------ #### [ Simple Demo ] Di seguito è riportato un esempio di file di specifiche di test che viene semplicemente registrato `Hello world!` come elemento di test run. ``` 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 ] Di seguito è riportato un esempio di file di test spec che configura un test Appium Java TestNG eseguito su 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 ``` ------ #### [ Appio iOS ] Di seguito è riportato un esempio di file di test spec che configura un test Appium Java TestNG eseguito su 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) ] Di seguito è riportato un esempio di file di test spec che configura un test Appium Java TestNG eseguito su Android e 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 ``` ------ # Host per ambienti di test personalizzati Device Farm supporta una serie di sistemi operativi con software preconfigurato tramite l'uso di un ambiente host di test. Durante l'esecuzione del test, Device Farm utilizza istanze (host) gestite da Amazon che si connettono dinamicamente al dispositivo selezionato in fase di test. Questa istanza viene completamente ripulita e non riutilizzata tra un'esecuzione e l'altra e viene terminata con gli artefatti generati al termine dell'esecuzione del test. **Topics** + [Host di test disponibili per ambienti di test personalizzati](#custom-test-environments-hosts-available) + [Selezione di un host di test per ambienti di test personalizzati](#test-host-selection) + [Software supportato in ambienti di test personalizzati](custom-test-environments-hosts-software.md) + [Ambiente di test per dispositivi Android](custom-test-environments-hosts-android.md) + [Ambiente di test per dispositivi iOS](custom-test-environments-hosts-ios.md) ## Host di test disponibili per ambienti di test personalizzati Gli host di test sono completamente gestiti da Device Farm. La tabella seguente elenca gli host di test Device Farm attualmente disponibili e supportati per ambienti di test personalizzati. | Piattaforma del dispositivo | Host di test | Sistema operativo | Architettura/e | Dispositivi supportati | | --- | --- | --- | --- | --- | | Android | amazon\$1linux\$12 | Amazon Linux 2 | x86\$164 | Android6 e versioni successive | | iOS | macos\$1sequoia | macOS Sequoia(versione 15) | arm64 | iOSda 15 a 26 | **Nota** Periodicamente, Device Farm aggiunge nuovi host di test per una piattaforma di dispositivi per supportare le versioni più recenti del sistema operativo del dispositivo e le relative dipendenze. Quando ciò si verifica, gli host di test precedenti per la rispettiva piattaforma di dispositivi sono soggetti alla fine del supporto. ### Versione del sistema operativo Ogni host di test disponibile utilizza una versione specifica del sistema operativo supportata in quel momento da Device Farm. Sebbene cerchiamo di utilizzare la versione più recente del sistema operativo, questa potrebbe non essere l'ultima versione distribuita pubblicamente disponibile. Device Farm aggiornerà periodicamente il sistema operativo con aggiornamenti di versione minori e patch di sicurezza. Per conoscere la versione specifica (inclusa la versione secondaria) del sistema operativo in uso durante l'esecuzione del test, puoi aggiungere il seguente frammento di codice a qualsiasi fase del file delle specifiche di test. **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 ``` ## Selezione di un host di test per ambienti di test personalizzati Puoi specificare l'host di test Android e iOS nelle `ios_test_host` variabili appropriate `android_test_host` del [file delle specifiche di test](custom-test-environment-test-spec.md#custom-test-environment-test-spec-syntax). Se non si specifica una selezione di host di test per una determinata piattaforma di dispositivi, i test verranno eseguiti sull'host di test che Device Farm ha impostato come predefinito per il dispositivo e la configurazione di test specificati. **Importante** Durante i test su iOS 18 e versioni precedenti, verrà utilizzato un host di test legacy quando non è selezionato un host. Per ulteriori informazioni, consulta l'argomento su[Host di test iOS legacy](custom-test-environments-hosts-ios.md#legacy-ios-host). Ad esempio, esamina il seguente frammento di codice: **Example** ``` version: 0.1 android_test_host: amazon_linux_2 ios_test_host: macos_sequoia phases: # ... ``` # Software supportato in ambienti di test personalizzati Device Farm utilizza macchine host preinstallate con molte delle librerie software necessarie per eseguire i framework di test supportati dal nostro servizio, fornendo un ambiente di test pronto all'avvio. Device Farm supporta più lingue tramite l'uso del nostro meccanismo di selezione del software e aggiornerà periodicamente le versioni delle lingue incluse nell'ambiente. Per qualsiasi altro software richiesto, puoi modificare il file delle specifiche di test per installarlo dal tuo pacchetto di test, scaricarlo da Internet o accedere a fonti private all'interno del tuo VPC (vedi [VPC](https://docs.aws.amazon.com//devicefarm/latest/developerguide/vpc-eni.html) ENI per ulteriori informazioni). Per ulteriori informazioni, consulta [Esempi di specifiche di test](custom-test-environment-test-spec.md#custom-test-environment-test-spec-example). ## Software preconfigurato Per facilitare il test dei dispositivi su ciascuna piattaforma, sull'host di test sono disponibili i seguenti strumenti: | Tools (Strumenti) | Piattaforme per dispositivi | | --- | --- | | Android SDK Build-Tools | Android | | Android SDK Platform-Tools(include`adb`) | Android | | Xcode | iOS | ## Software selezionabile Oltre al software preconfigurato sull'host, Device Farm offre un modo per selezionare determinate versioni del software supportato tramite gli `devicefarm-cli` strumenti. La tabella seguente contiene il software selezionabile e gli host di test che li contengono. | Software/Strumento | Host che supportano questo software | Comando da utilizzare nelle specifiche di test | | --- | --- | --- | | 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` | L'host di test include anche strumenti di supporto di uso comune per ogni versione del software, come i `pip` gestori di `npm` pacchetti (inclusi rispettivamente in Python e Node.js) e le dipendenze (come il UIAutomator2 driver Appium) per strumenti come Appium. Ciò garantisce di disporre degli strumenti necessari per lavorare con i framework di test supportati. # Utilizzo dello strumento devicefarm-cli in ambienti di test personalizzati L'host di test utilizza uno strumento di gestione delle versioni standardizzato chiamato a selezionare le versioni del software. ` devicefarm-cli` Questo strumento è separato dall'host di test Device Farm AWS CLI ed è disponibile solo sull'host di test Device Farm. Con`devicefarm-cli`, è possibile passare a qualsiasi versione software preinstallata sull'host di test. Ciò offre un modo semplice per mantenere il file delle specifiche di test di Device Farm nel tempo e offre un meccanismo prevedibile per aggiornare le versioni del software in futuro. **Importante** Questo strumento da riga di comando non è disponibile sugli host iOS precedenti. Per ulteriori informazioni, consulta l'argomento su[Host di test iOS legacy](custom-test-environments-hosts-ios.md#legacy-ios-host). Il frammento seguente mostra la `help` pagina di: `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. ``` Esaminiamo un paio di esempi di utilizzo di. `devicefarm-cli` Per utilizzare lo strumento per modificare la versione di Python da *3.10* a *3.9* nel file delle specifiche di test, esegui i seguenti comandi: ``` $ python --version Python 3.10.12 $ devicefarm-cli use python 3.9 $ python --version Python 3.9.17 ``` Per cambiare la versione di Appium da a: *1* *2* ``` $ appium --version 1.22.3 $ devicefarm-cli use appium 2 $ appium --version 2.1.2 ``` **Suggerimento** Nota che quando selezioni una versione del software, cambia `devicefarm-cli` anche gli strumenti di supporto per quei linguaggi, come `pip` Python `npm` e NodeJS. Per ulteriori informazioni sul software preinstallato sull'host di test, consulta. [Software supportato in ambienti di test personalizzati](custom-test-environments-hosts-software.md) # Ambiente di test per dispositivi Android AWS Device Farm utilizza macchine host Amazon Elastic Compute Cloud (EC2) che eseguono Amazon Linux 2 per eseguire test Android. Quando pianifichi un'esecuzione di test, Device Farm assegna un host dedicato per ciascun dispositivo per eseguire i test in modo indipendente. Le macchine host si interrompono dopo l'esecuzione del test insieme a tutti gli artefatti generati. L'host Amazon Linux 2 offre diversi vantaggi: + **Test più veloci e affidabili**: rispetto all'host precedente, il nuovo host di test migliora significativamente la velocità dei test, in particolare riducendo i tempi di inizio dei test. L'host Amazon Linux 2 dimostra inoltre una maggiore stabilità e affidabilità durante i test. + **Accesso remoto avanzato per i test manuali**: gli aggiornamenti all'host di test più recente e i miglioramenti comportano una minore latenza e migliori prestazioni video per i test manuali Android. + **Selezione della versione software standard**: Device Farm ora standardizza il supporto dei principali linguaggi di programmazione sull'host di test e sulle versioni del framework Appium. Per i linguaggi supportati (attualmente Java, Python, Node.js e Ruby) e Appium, il nuovo host di test fornisce versioni stabili a lungo termine subito dopo il lancio. La gestione centralizzata delle versioni tramite `devicefarm-cli` lo strumento consente lo sviluppo di file con specifiche di test con un'esperienza coerente tra i framework. **Topics** + [Intervalli IP supportati per l'ambiente di test Amazon Linux 2 in Device Farm](amazon-linux-2-ip-ranges.md) # Intervalli IP supportati per l'ambiente di test Amazon Linux 2 in Device Farm I clienti spesso hanno bisogno di conoscere l'intervallo di IP da cui proviene il traffico di Device Farm, in particolare per configurare i firewall e le impostazioni di sicurezza. Per gli host di test Amazon EC2, l'intervallo IP comprende l'intera regione. `us-west-2` Per gli host di test di Amazon Linux 2, che è l'opzione predefinita per le nuove esecuzioni di Android, gli intervalli sono stati limitati. Il traffico ora proviene da un set specifico di gateway NAT, limitando l'intervallo IP ai seguenti indirizzi: **** | Intervalli IP | | --- | | **44.236.137,143** | | **5213,151,44** | | **5235,189,1991** | | **54201.250,26** | Per ulteriori informazioni sugli ambienti di test Android in Device Farm, consulta[Ambiente di test per dispositivi Android](custom-test-environments-hosts-android.md). # Ambiente di test per dispositivi iOS Device Farm utilizza istanze macOS (host) gestite da Amazon che si connettono dinamicamente al dispositivo iOS durante l'esecuzione del test. Ogni host è preconfigurato con un software che consente il test dei dispositivi su varie piattaforme di test popolari, come UI e Appium. XCTest L'attuale iterazione dell'host di test iOS ha migliorato l'esperienza di test rispetto alle versioni precedenti, tra cui: + **Sistema operativo host e strumenti coerenti per iOS 15 e iOS 26** In precedenza, l'host di test veniva determinato dal dispositivo in uso, il che portava a un ambiente software frammentato durante l'esecuzione su più versioni di iOS. L'esperienza attuale consente una semplice selezione dell'host per consentire un ambiente coerente su tutti i dispositivi. Ciò consentirà di rendere disponibili la stessa versione e gli stessi strumenti di macOS (come Xcode) su ogni dispositivo iOS. + **Miglioramenti delle prestazioni per i test di iOS 15 e 16** Utilizzando un'infrastruttura aggiornata, i tempi di configurazione sono notevolmente migliorati per i test di iOS 15 e 16. + **Versioni software selezionabili standardizzate per le dipendenze supportate** Ora disponiamo del sistema di selezione del `devicefarm-cli` software sugli host di test iOS e Android, che consente di selezionare la versione preferita delle nostre dipendenze supportate. Per le dipendenze supportate (come Java, Python, Node.js, Ruby e Appium), le versioni saranno selezionabili tramite le specifiche di test. Per un'idea di come funziona questa funzionalità, consulta l'argomento su. [Software supportato in ambienti di test personalizzati](custom-test-environments-hosts-software.md) **Importante** Se esegui su iOS 18 e versioni precedenti, i test verranno eseguiti su host di test legacy per impostazione predefinita. Consulta l'argomento seguente su come migrare da host legacy. ## Host di test iOS legacy Per i test esistenti su iOS 18 e versioni precedenti, gli host di test legacy sono selezionati per impostazione predefinita per gli ambienti di test personalizzati. La tabella seguente contiene la versione dell'host di test eseguita con la versione del dispositivo iOS. | Sistema operativo | Architettura/e | Impostazione predefinita per i dispositivi | | --- | --- | --- | | macOS Sonoma(versione 14) | arm64 | iOS 18 | | macOS Ventura(versione 13) | arm64 | iOS 17 | | macOS Monterey(versione 12) | x86\$164 | iOS 16e di seguito | Per selezionare gli host di test più recenti, consulta l'argomento relativo[Migrazione degli ambienti di test personalizzati ai nuovi host di test iOS](ios-host-migration.md). ## Software supportato per dispositivi iOS Per supportare i test dei dispositivi iOS, gli host di test Device Farm per dispositivi iOS sono preconfigurati con Xcode e gli strumenti a riga di comando associati. Per altri software disponibili, consulta l'argomento relativo. [Software supportato in ambienti di test personalizzati](custom-test-environments-hosts-software.md) # Migrazione degli ambienti di test personalizzati ai nuovi host di test iOS Per migrare i test esistenti dall'host legacy al nuovo host di test macOS, dovrai sviluppare nuovi file di specifiche di test basati su quelli preesistenti. L'approccio consigliato consiste nell'iniziare con il file di test spec di esempio per i tipi di test desiderati, quindi migrare i comandi pertinenti dal vecchio file delle specifiche di test a quello nuovo. Ciò consente di sfruttare le nuove funzionalità e ottimizzazioni delle specifiche di test di esempio per il nuovo host riutilizzando al contempo gli snippet del codice esistente. **Topics** + [Tutorial: migrazione dei file delle specifiche di test iOS con la console](#ios-host-migration-console-tutorial) + [Differenze tra gli host di test nuovi e quelli precedenti](#ios-host-migration-differences) ## Tutorial: migrazione dei file delle specifiche di test iOS con la console In questo esempio, la console Device Farm verrà utilizzata per integrare le specifiche di test di un dispositivo iOS esistente per utilizzare il nuovo host di test. ### Passaggio 1: creazione di nuovi file delle specifiche di test con la console 1. Accedi alla [console AWS Device Farm](https://console.aws.amazon.com/devicefarm). 1. Vai al progetto Device Farm contenente i tuoi test di automazione. 1. Scarica una copia delle specifiche di test esistenti che desideri utilizzare. 1. Fai clic sull'opzione «Impostazioni del progetto» e vai alla scheda **Caricamenti**. 1. Vai al file delle specifiche di test con cui desideri effettuare l'onboarding. 1. Fai clic sul pulsante **Download** per creare una copia locale di questo file. 1. Torna alla pagina del progetto e fai clic su **Crea esegui**. 1. Compila le opzioni della procedura guidata come se dovessi iniziare una nuova esecuzione, ma fermati all'**opzione Select test spec**. 1. Utilizzando la specifica di test iOS selezionata per impostazione predefinita, fai clic sul pulsante **Crea una specifica di test**. 1. Modifica la specifica del test selezionata per *impostazione predefinita nell'editor* di testo. 1. Se non è già presente, modifica il file delle specifiche di test per selezionare il nuovo host utilizzando: ``` ios_test_host: macos_sequoia ``` 1. Dalla copia delle specifiche di test scaricata in un passaggio precedente, esaminale ciascuna. ` phase` 1. Copia i comandi dalle fasi della vecchia specifica di test in ciascuna rispettiva fase della nuova specifica di test, ignorando i comandi relativi all'installazione o alla selezione di Java, Python, Node.js, Ruby, Appium o Xcode. 1. **Immettete un nuovo nome di file nella casella di testo Salva come.** 1. Fai clic sul pulsante **Salva come nuovo** per salvare le modifiche. Per un esempio di file di specifiche di test che puoi usare come riferimento, vedi l'esempio fornito in[Esempi di specifiche di test](custom-test-environment-test-spec.md#custom-test-environment-test-spec-example). ### Fase 2: Selezione del software preinstallato Nel nuovo host di test, le versioni software preinstallate vengono selezionate utilizzando un nuovo strumento di gestione delle versioni standardizzato chiamato. `devicefarm-cli` Questo strumento è ora l'approccio consigliato per l'utilizzo dei vari software che forniamo sugli host di test. Ad esempio, dovresti aggiungere la riga seguente per utilizzare un JDK 17 diverso nel tuo ambiente di test: ``` - devicefarm-cli use java 17 ``` Per ulteriori informazioni sul software supportato disponibile, consulta:. [Software supportato in ambienti di test personalizzati](custom-test-environments-hosts-software.md) ### Passo 3: Utilizzo di Appium e delle sue dipendenze tramite gli strumenti di selezione del software Il nuovo host di test supporta solo Appium 2.x e versioni successive. Seleziona esplicitamente la versione di Appium utilizzando`devicefarm-cli`, rimuovendo strumenti legacy come. ` avm` Esempio: ``` # 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 ``` La versione Appium selezionata con `devicefarm-cli` viene preinstallata con una versione compatibile del driver XCUITest per iOS. Inoltre, dovrai aggiornare le specifiche del test per utilizzare invece di. ` DEVICEFARM_APPIUM_WDA_DERIVED_DATA_PATH_V9` ` DEVICEFARM_WDA_DERIVED_DATA_PATH` La nuova variabile di ambiente punta a una versione predefinita di WebDriverAgent 9.x, che è l'ultima versione supportata per i test di Appium 2. Per ulteriori informazioni, consulta e. [Selezione di una WebDriverAgent versione per i test iOS](test-types-appium.md#test-types-appium-select-wda) [Variabili di ambiente per i test di Appium](custom-test-environment-variables.md#custom-test-environment-variables-appium) ## Differenze tra gli host di test nuovi e quelli precedenti Quando modifichi il file delle specifiche di test per utilizzare il nuovo host di test iOS e trasferisci i test dall'host di test precedente, tieni presente queste differenze chiave nell'ambiente: + **Versioni Xcode:** nell'ambiente host di test legacy, la versione Xcode disponibile era basata sulla versione iOS del dispositivo utilizzato per i test. Ad esempio, i test su dispositivi iOS 18 hanno utilizzato Xcode 16 nell'host legacy, mentre i test su iOS 17 hanno utilizzato Xcode 15. Nel nuovo ambiente host, tutti i dispositivi possono accedere alle stesse versioni di Xcode, garantendo un ambiente coerente per i test su dispositivi con versioni diverse. Per un elenco delle versioni di Xcode attualmente disponibili, consulta. [Software supportato](custom-test-environments-hosts-software.md) + **Selezione delle versioni del software:** in molti casi, le versioni software predefinite sono cambiate, quindi se prima non selezionavi esplicitamente la versione del software nell'host di test precedente, potresti volerla specificare ora nel nuovo host di test che utilizza. [`devicefarm-cli`](custom-test-environments-hosts-software-cli.md) Nella maggior parte dei casi d'uso, consigliamo ai clienti di selezionare esplicitamente le versioni del software che utilizzano. Selezionando una versione del software con, `devicefarm-cli` avrai un'esperienza prevedibile e coerente e riceverai un'ampia quantità di avvisi se Device Farm prevede di rimuovere quella versione dall'host di test. Inoltre, strumenti di selezione del software come `nvm` `pyenv`` avm`, e `rvm` sono stati rimossi a favore del nuovo ` devicefarm-cli` sistema di selezione del software. + **Versioni software disponibili:** molte versioni del software preinstallato in precedenza sono state rimosse e sono state aggiunte molte nuove versioni. Pertanto, assicurati che quando utilizzi `devicefarm-cli` per selezionare le versioni del software, selezioni le versioni presenti nell'[elenco delle versioni supportate](custom-test-environments-hosts-software.md). + **La `libimobiledevice` suite di strumenti è stata rimossa** a favore di strumenti più nuovi/di prima parte per tenere traccia degli attuali test dei dispositivi iOS e degli standard di settore. Per iOS 17 e versioni successive, puoi migrare la maggior parte dei comandi per utilizzare strumenti Xcode simili, chiamati. `devicectl` Per informazioni in merito`devicectl`, puoi eseguirlo `xcrun devicectl help` da una macchina su cui è installato Xcode. + **I percorsi di file codificati** nel file delle specifiche di test dell'host precedente come percorsi assoluti molto probabilmente non funzioneranno come previsto nel nuovo host di test e generalmente non sono consigliati per l'uso di file di specifiche di test. Ti consigliamo di utilizzare percorsi relativi e variabili di ambiente per tutto il codice del file delle specifiche di test. Per ulteriori informazioni, consulta l'argomento su[Le migliori pratiche per l'esecuzione di ambienti di test personalizzati](custom-test-environments-best-practices.md). + **Versione e architettura del sistema operativo:** gli host di test precedenti utilizzavano una varietà di versioni macOS e architetture CPU in base al dispositivo assegnato. Di conseguenza, gli utenti potrebbero notare alcune differenze nelle librerie di sistema disponibili nell'ambiente. Per ulteriori informazioni sulla versione precedente del sistema operativo host, consulta[Host di test iOS legacy](custom-test-environments-hosts-ios.md#legacy-ios-host). + **Per gli utenti di Appium**, il modo di selezionare WebDriverAgent è stato modificato in un prefisso per le variabili di ambiente utilizzate ` DEVICEFARM_APPIUM_WDA_DERIVED_DATA_PATH_V` anziché il vecchio prefisso. ` DEVICEFARM_WDA_DERIVED_DATA_PATH_V` Per ulteriori informazioni sulla variabile aggiornata, consulta. [Variabili di ambiente per i test di Appium](custom-test-environment-variables.md#custom-test-environment-variables-appium) + **Per gli utenti di Appium Java**, il nuovo host di test non contiene alcun file JAR preinstallato nel percorso di classe, mentre l'host precedente ne conteneva uno per il framework TestNG (tramite una variabile di ambiente). `$DEVICEFARM_TESTNG_JAR` Consigliamo ai clienti di impacchettare i file JAR necessari per i propri framework di test all'interno del pacchetto di test e di rimuovere le istanze della variabile dai file delle `$DEVICEFARM_TESTNG_JAR` specifiche di test. Ti consigliamo di contattare il team di assistenza tramite un caso di supporto se hai commenti o domande sulle differenze tra gli host di test dal punto di vista del software. # Accedi alle risorse AWS utilizzando un ruolo di esecuzione IAM Device Farm supporta la specifica di un ruolo IAM che verrà assunto dall'ambiente di esecuzione del test personalizzato durante l'esecuzione del test. Questa funzionalità consente ai test di accedere in modo sicuro alle risorse AWS nel tuo account, come bucket Amazon S3, tabelle DynamoDB o altri servizi AWS da cui dipende l'applicazione. **Topics** + [Panoramica](#iam-execution-role-overview) + [Requisiti del ruolo IAM](#iam-role-requirements) + [Configurazione di un ruolo di esecuzione IAM](#configuring-iam-execution-role) + [Best practice](#iam-role-best-practices) + [risoluzione dei problemi](#troubleshooting-iam-roles) ## Panoramica Quando si specifica un ruolo di esecuzione IAM, Device Farm lo assume durante l'esecuzione del test, consentendo ai test di interagire con i servizi AWS utilizzando le autorizzazioni definite nel ruolo. I casi d'uso comuni per i ruoli di esecuzione IAM includono: + Accesso ai dati di test archiviati nei bucket Amazon S3 + Trasferimento degli artefatti di test ai bucket Amazon S3 + Recupero della configurazione dell'applicazione da AWS AppConfig + Scrittura di log e metriche dei test su Amazon CloudWatch + Invio di risultati di test o messaggi di stato alle code di Amazon SQS + Richiamo delle funzioni AWS Lambda come parte dei flussi di lavoro di test ## Requisiti del ruolo IAM Per utilizzare un ruolo di esecuzione IAM con Device Farm, il ruolo deve soddisfare i seguenti requisiti: + **Relazione di fiducia**: è necessario affidare il ruolo al responsabile del servizio Device Farm. La politica di fiducia deve essere inclusa `devicefarm.amazonaws.com` come entità attendibile. + **Autorizzazioni**: il ruolo deve disporre delle autorizzazioni necessarie per accedere alle risorse AWS richieste dai test. + **Durata della sessione**: la durata massima della sessione del ruolo deve essere almeno pari all'impostazione del timeout del lavoro del progetto Device Farm. Per impostazione predefinita, i progetti Device Farm hanno un timeout di lavoro di 150 minuti, quindi il tuo ruolo deve supportare una sessione della durata di almeno 150 minuti. + **Stesso requisito dell'account**: il ruolo IAM deve trovarsi nello stesso account AWS utilizzato per chiamare Device Farm. L'assunzione di ruoli tra account non è supportata. + **PassRole autorizzazione**: il chiamante deve essere autorizzato a passare il ruolo IAM mediante una policy che consenta l'`iam:PassRole`azione sul ruolo di esecuzione specificato. ### Esempio di policy di attendibilità L'esempio seguente mostra una politica di attendibilità che consente a Device Farm di assumere il ruolo di esecuzione dell'utente. Questa policy di fiducia deve essere associata solo al ruolo IAM specifico che intendi utilizzare con Device Farm, non ad altri ruoli nel tuo account: **Example** ``` { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "devicefarm.amazonaws.com" }, "Action": "sts:AssumeRole" } ] } ``` ### Policy di autorizzazione di esempio L'esempio seguente mostra una politica di autorizzazioni che garantisce l'accesso ai servizi AWS comuni utilizzati nei test: **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-*" } ] } ``` ## Configurazione di un ruolo di esecuzione IAM Puoi specificare un ruolo di esecuzione IAM a livello di progetto o per singole esecuzioni di test. Se configurate a livello di progetto, tutte le esecuzioni all'interno di quel progetto erediteranno il ruolo di esecuzione. Un ruolo di esecuzione configurato in un'esecuzione sostituirà qualsiasi ruolo configurato nel relativo progetto principale. Per istruzioni dettagliate sulla configurazione dei ruoli di esecuzione, consulta: + [Creazione di un progetto in AWS Device Farm](how-to-create-project.md)- per configurare i ruoli di esecuzione a livello di progetto + [Creazione di un'esecuzione di test in Device Farm](how-to-create-test-run.md)- per configurare i ruoli di esecuzione per singole esecuzioni Puoi anche configurare i ruoli di esecuzione utilizzando l'API Device Farm. Per ulteriori informazioni, consulta il [Device Farm API Reference](https://docs.aws.amazon.com/devicefarm/latest/APIReference/). ## Best practice Segui queste best practice per configurare i ruoli di esecuzione IAM per i test di Device Farm: + **Principio del privilegio minimo**: concedi solo le autorizzazioni minime necessarie per il funzionamento dei test. Evita di utilizzare autorizzazioni troppo ampie come `*` azioni o risorse. + **Utilizza autorizzazioni specifiche per le risorse: quando possibile, limita le autorizzazioni** a risorse specifiche (ad esempio, bucket S3 specifici o tabelle DynamoDB) anziché a tutte le risorse di un tipo. + Risorse **di test e produzione separate: utilizza risorse e ruoli di** test dedicati per evitare di influire accidentalmente sui sistemi di produzione durante i test. + **Revisione periodica dei ruoli**: rivedi e aggiorna periodicamente i ruoli di esecuzione per assicurarti che soddisfino ancora le tue esigenze di test e seguano le migliori pratiche di sicurezza. + **Usa le chiavi di condizione**: valuta la possibilità di utilizzare le chiavi di condizione IAM per limitare ulteriormente quando e come il ruolo può essere utilizzato. ## risoluzione dei problemi Se riscontri problemi con i ruoli di esecuzione IAM, controlla quanto segue: + **Relazione di fiducia**: verifica che la politica di fiducia del `devicefarm.amazonaws.com` ruolo includa un servizio affidabile. + **Autorizzazioni**: verifica che il ruolo disponga delle autorizzazioni necessarie per i servizi AWS a cui i test stanno tentando di accedere. + **Registri di test**: esamina i log di esecuzione dei test per messaggi di errore specifici relativi alle chiamate API AWS o ai dinieghi di autorizzazione. # Variabili di ambiente per ambienti di test personalizzati Device Farm configura dinamicamente diverse variabili di ambiente da utilizzare come parte dell'esecuzione dell'ambiente di test personalizzato. **Topics** + [Variabili di ambiente personalizzate](#custom-test-environment-variables-custom) + [Variabili di ambiente comuni](#custom-test-environment-variables-common) + [Variabili di ambiente per i test di Appium](#custom-test-environment-variables-appium) + [Variabili di ambiente per i test XCUITest](#custom-test-environment-variables-xcuitest) ## Variabili di ambiente personalizzate Device Farm supporta la configurazione di coppie chiave-valore che vengono applicate come variabili di ambiente sull'host di test. Queste possono essere configurate in un progetto Device Farm o durante la creazione dell'esecuzione; tutte le variabili configurate in un'esecuzione sostituiranno quelle che possono essere configurate nel relativo progetto principale. Le restrizioni si applicano come segue: + Le variabili di ambiente personalizzate non sono supportate sugli host di test iOS precedenti. Per ulteriori informazioni, consulta [Host di test iOS legacy](custom-test-environments-hosts-ios.md#legacy-ios-host). + I nomi delle variabili che iniziano con `$DEVICEFARM_` sono riservati all'uso interno del servizio. + Le variabili di ambiente personalizzate non possono essere utilizzate per configurare la selezione del calcolo dell'host di test nelle specifiche del test. ## Variabili di ambiente comuni Questa sezione descrive le variabili di ambiente comuni a tutti i test in Device Farm. ** `$DEVICEFARM_DEVICE_NAME` ** Il dispositivo su cui vengono eseguiti i test. Rappresenta l'identificatore univoco del dispositivo (UDID). ** `$DEVICEFARM_DEVICE_UDID` ** L'identificatore univoco del dispositivo. ** `$DEVICEFARM_DEVICE_PLATFORM_NAME` ** Il nome della piattaforma del dispositivo. O è `Android` o`iOS`. ** `$DEVICEFARM_DEVICE_OS_VERSION` ** La versione del sistema operativo del dispositivo. ** `$DEVICEFARM_APP_PATH` ** *(test delle app per dispositivi mobili)* Il percorso all'app mobile sulla macchina host dove vengono eseguiti i test. Questa variabile non è disponibile durante i test web. ** `$DEVICEFARM_LOG_DIR` ** Il percorso della directory predefinita in cui verranno archiviati i log del cliente, gli artefatti e gli altri file desiderati per un successivo recupero. Utilizzando una [specifica di test di esempio](custom-test-environment-test-spec.md#custom-test-environment-test-spec-example), i file in questa directory vengono archiviati in un file ZIP e resi disponibili come artefatto dopo l'esecuzione del test. ** `$DEVICEFARM_SCREENSHOT_PATH` ** Il percorso agli screenshot, se esistenti, acquisiti durante la sessione di test. ** `$DEVICEFARM_PROJECT_ARN` ** L'ARN del progetto principale del lavoro. ** `$DEVICEFARM_RUN_ARN` ** L'ARN dell'esecuzione principale del processo. ** `$DEVICEFARM_DEVICE_ARN` ** L'ARN del dispositivo sottoposto a test. ** `$DEVICEFARM_TOTAL_JOBS` ** Il numero totale di job associati all'esecuzione della Device Farm principale. ** `$DEVICEFARM_JOB_NUMBER` ** Il numero di questo lavoro è compreso`$DEVICEFARM_TOTAL_JOBS`. Ad esempio, un'esecuzione può contenere 5 job, ognuno dei quali avrà un valore univoco `$DEVICEFARM_JOB_NUMBER` compreso tra 0 e 4. ** `$AWS_REGION` ** La regione AWS. Il servizio lo imposterà in modo che corrisponda alla regione in cui si trova il dispositivo sottoposto a test. Se necessario, può essere sovrascritto da una variabile di ambiente personalizzata. ** `$ANDROID_HOME` ** *(Solo Android)* Il percorso della directory di installazione di Android SDK. ## Variabili di ambiente per i test di Appium Questa sezione descrive le variabili di ambiente utilizzate da qualsiasi test Appium in un ambiente di test personalizzato in Device Farm. ** `$DEVICEFARM_CHROMEDRIVER_EXECUTABLE_DIR` ** *(Solo Android)* La posizione di una directory che contiene gli ChromeDriver eseguibili necessari per l'uso nei test web e ibridi di Appium. ** `$DEVICEFARM_APPIUM_WDA_DERIVED_DATA_PATH_V` ** *(solo iOS)* Il percorso dati derivato di una versione di Device Farm WebDriverAgent creata per essere eseguita su Device Farm. La numerazione sulla variabile corrisponderà alla versione principale di WebDriverAgent. Ad esempio, `DEVICEFARM_APPIUM_WDA_DERIVED_DATA_PATH_V9` indicherà la WebDriverAgent versione a 9.x. Per ulteriori informazioni, consulta [Selezione di una WebDriverAgent versione per i test iOS](test-types-appium.md#test-types-appium-select-wda). Le variabili di `$DEVICEFARM_APPIUM_WDA_DERIVED_DATA_PATH_V` ambiente sono presenti solo su host iOS non legacy. Per ulteriori informazioni, consulta [Host di test iOS legacy](custom-test-environments-hosts-ios.md#legacy-ios-host). ** `$DEVICEFARM_WDA_DERIVED_DATA_PATH_V9` ** *(solo iOS, obsoleto)* Il percorso dati derivato di una versione di Device Farm WebDriverAgent creata per essere eseguita su Device Farm. `$DEVICEFARM_APPIUM_WDA_DERIVED_DATA_PATH_V`Per lo schema di denominazione sostitutivo, fare riferimento a. ## Variabili di ambiente per i test XCUITest Questa sezione descrive le variabili di ambiente utilizzate dal XCUITest test in un ambiente di test personalizzato in Device Farm. ** `$DEVICEFARM_XCUITESTRUN_FILE` ** Il percorso del `.xctestun` file Device Farm. Viene generato dalla tua app e dai pacchetti di test. ** `$DEVICEFARM_DERIVED_DATA_PATH` ** Percorso previsto dell'output xcodebuild di Device Farm. ** `$DEVICEFARM_XCTEST_BUILD_DIRECTORY` ** Il percorso ai contenuti decompressi del file del pacchetto di test. # Le migliori pratiche per l'esecuzione di ambienti di test personalizzati Negli argomenti seguenti vengono illustrate le best practice consigliate per l'utilizzo dell'esecuzione di test personalizzati con Device Farm. **Configurazione run** + **Affidati al software gestito da Device Farm e alle funzionalità API per eseguire la configurazione** laddove possibile, anziché applicare configurazioni simili tramite comandi shell nel file delle specifiche di test. Ciò include la configurazione dell'host di test e del dispositivo, in quanto sarà più sostenibile e coerente tra host e dispositivi di test. Sebbene Device Farm vi incoraggi a personalizzare il file delle specifiche di test nella misura necessaria per eseguire i test, il file delle specifiche di test può diventare difficile da mantenere nel tempo man mano che vi vengono aggiunti comandi più personalizzati. Utilizzando il software gestito da Device Farm (tramite strumenti come ` devicefarm-cli` e gli strumenti predefiniti disponibili in`$PATH`) e utilizzando funzionalità gestite (come il parametro [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)request) per semplificare il file delle specifiche di test spostando la responsabilità della manutenzione su Device Farm stessa. **Specifiche di test e codice del pacchetto di test** + **Non utilizzate percorsi assoluti né fate affidamento su versioni secondarie specifiche** nel file delle specifiche di test o nel codice del pacchetto di test. Device Farm applica gli aggiornamenti di routine all'host di test selezionato e alle versioni software incluse. L'utilizzo di percorsi specifici o assoluti (ad esempio «` /usr/local/bin/python`instead of»`python`) o la richiesta di versioni secondarie specifiche (ad esempio Node.js `20.3.1` anziché «just»` 20`) possono impedire ai test di individuare il file eseguibile/richiesto. Come parte dell'esecuzione dei test personalizzati, Device Farm imposta varie variabili di ambiente e la `$PATH` variabile per garantire che i test abbiano un'esperienza coerente all'interno dei nostri ambienti dinamici. Per ulteriori informazioni, consulta [Variabili di ambiente per ambienti di test personalizzati](custom-test-environment-variables.md) e [Software supportato in ambienti di test personalizzati](custom-test-environments-hosts-software.md). + **Salva i file generati o copiati nella directory temp durante l'esecuzione del test.** Oggi ci assicuriamo che la directory temporanea (`/tmp`) sia accessibile all'utente durante l'esecuzione del test (oltre alle directory gestite, come la). `$DEVICEFARM_LOG_DIR` Le altre directory a cui l'utente ha accesso possono cambiare nel tempo a causa delle esigenze del servizio o del sistema operativo in uso. + **Salva i registri di esecuzione dei test in. `$DEVICEFARM_LOG_DIR`** Questa è la directory degli artefatti predefinita fornita per l'esecuzione in cui aggiungere i log di esecuzione /gli artefatti. Le [specifiche di test di esempio](custom-test-environment-test-spec.md#custom-test-environment-test-spec-example) che forniamo utilizzano ciascuna questa directory per gli artefatti per impostazione predefinita. + **Assicurati che i tuoi comandi restituiscano un codice diverso da zero in caso di errore** durante la `test` fase delle specifiche di test. Determiniamo se l'esecuzione è fallita controllando la presenza di un codice di uscita diverso da zero per ogni comando di shell invocato durante la fase. `test` È necessario assicurarsi che la logica o il framework di test restituiscano un codice di uscita diverso da zero per tutti gli scenari desiderati, il che potrebbe richiedere una configurazione aggiuntiva. Ad esempio, alcuni framework di test (come JUnit5) non considerano l'esecuzione di zero test un errore, il che determinerà la corretta esecuzione dei test anche se non è stato eseguito nulla. Ad esempio, è necessario specificare l'opzione della riga di comando per garantire che questo scenario `--fail-if-no-tests` venga chiuso con un codice di uscita diverso da zero. JUnit5 + **Verifica la compatibilità del software** con la versione del sistema operativo del dispositivo e la versione dell'host di test che utilizzerai per l'esecuzione del test. Ad esempio, alcune funzionalità di test dei framework software (ad esempio: Appium) potrebbero non funzionare come previsto su tutte le versioni del sistema operativo del dispositivo in fase di test. **Sicurezza** + **Evita di archiviare o registrare variabili sensibili (come le chiavi AWS) nel file delle specifiche di test.** I file delle specifiche di test, gli script generati dalle specifiche di test e i log dello script delle specifiche di test vengono tutti forniti come elementi scaricabili al termine dell'esecuzione del test. Ciò può portare alla divulgazione involontaria di segreti per gli altri utenti del tuo account con accesso in lettura all'esecuzione del test. # Migrazione dei test da un ambiente di test standard a un ambiente di test personalizzato Puoi passare da una modalità di esecuzione di test standard a una modalità di esecuzione personalizzata in AWS Device Farm. La migrazione prevede principalmente due diverse forme di esecuzione: 1. **Modalità standard**: questa modalità di esecuzione dei test è progettata principalmente per fornire ai clienti report granulari e un ambiente completamente gestito. 1. **Modalità personalizzata**: questa modalità di esecuzione dei test è progettata per diversi casi d'uso che richiedono esecuzioni di test più rapide, la possibilità di passare da un modello all'altro e raggiungere la parità con l'ambiente locale e lo streaming video in diretta. Per ulteriori informazioni sulle modalità standard e personalizzate in Device Farm, vedere [Ambienti di test in AWS Device Farm](test-environments.md) e[Ambienti di test personalizzati in AWS Device Farm](custom-test-environments.md). ## Considerazioni sulle tempistiche di migrazione Questa sezione elenca alcuni dei principali casi d'uso da considerare durante la migrazione alla modalità personalizzata: 1. **Velocità**: nella modalità di esecuzione standard, Device Farm analizza i metadati dei test che hai impacchettato e caricato utilizzando le istruzioni di imballaggio per il tuo particolare framework. L'analisi rileva il numero di test nel pacchetto. Successivamente, Device Farm esegue ogni test separatamente e presenta i log, i video e gli altri artefatti dei risultati singolarmente per ogni test. Tuttavia, ciò aumenta costantemente il tempo totale di esecuzione dei end-to-end test, in quanto il servizio prevede la pre e post-elaborazione dei test e gli artefatti dei risultati. Al contrario, la modalità di esecuzione personalizzata non analizza il pacchetto di test; ciò significa nessuna preelaborazione e una post-elaborazione minima per i test o gli artefatti dei risultati. Ciò si traduce in tempi di end-to-end esecuzione totali vicini alla configurazione locale. I test vengono eseguiti nello stesso formato in cui lo sarebbero se fossero eseguiti sui computer locali. I risultati dei test sono gli stessi che si ottengono localmente e sono disponibili per il download al termine dell'esecuzione del lavoro. 1. **Personalizzazione o flessibilità**: la modalità di esecuzione standard analizza il pacchetto di test per rilevare il numero di test e quindi esegue ciascun test separatamente. Tieni presente che non è garantito che i test vengano eseguiti nell'ordine specificato. Di conseguenza, i test che richiedono una particolare sequenza di esecuzione potrebbero non funzionare come previsto. Inoltre, non è possibile personalizzare l'ambiente del computer host o trasmettere i file di configurazione che potrebbero essere necessari per eseguire i test in un determinato modo. Al contrario, la modalità personalizzata consente di configurare l'ambiente del computer host, inclusa la possibilità di installare software aggiuntivo, applicare filtri ai test, passare file di configurazione e controllare la configurazione di esecuzione dei test. Ciò avviene tramite un file yaml (chiamato anche file testspec) che è possibile modificare aggiungendovi comandi di shell. Questo file yaml viene convertito in uno script di shell che viene eseguito sulla macchina host di test. Puoi salvare più file yaml e sceglierne uno dinamicamente in base alle tue esigenze quando pianifichi un'esecuzione. 1. **Video e registrazione in diretta: sia la** modalità di esecuzione standard che quella personalizzata forniscono video e registri per i test. Tuttavia, in modalità standard, il video e i registri predefiniti dei test vengono visualizzati solo dopo il completamento dei test. Al contrario, la modalità personalizzata offre un live streaming del video e dei registri lato client dei test. Inoltre, puoi scaricare il video e altri artefatti alla fine del/i test/i. **Suggerimento** Se il tuo caso d'uso riguarda almeno uno dei fattori sopra indicati, ti consigliamo vivamente di passare alla modalità di esecuzione personalizzata. ## Fasi della migrazione Per migrare dalla modalità standard a quella personalizzata, procedi come segue: 1. Accedi Console di gestione AWS e apri la console Device Farm all'indirizzo [https://console.aws.amazon.com/devicefarm/](https://console.aws.amazon.com/devicefarm/). 1. Scegli il tuo progetto e poi inizia una nuova esecuzione di automazione. 1. Carica la tua app (o `web app` selezionala), scegli il tipo di framework di test, carica il pacchetto di test, quindi, sotto il `Choose your execution environment` parametro, scegli l'opzione`Run your test in a custom environment`. 1. Per impostazione predefinita, il file delle specifiche di test di esempio di Device Farm viene visualizzato e modificato. Questo file di esempio può essere utilizzato come punto di partenza per provare i test in [modalità ambiente personalizzato](https://docs.aws.amazon.com/devicefarm/latest/developerguide/custom-test-environments.html). Quindi, una volta verificato che i test funzionino correttamente dalla console, puoi modificare qualsiasi integrazione di API, CLI e pipeline con Device Farm per utilizzare questo file delle specifiche di test come parametro durante la pianificazione delle esecuzioni dei test. [Per informazioni su come aggiungere un file delle specifiche di test come parametro per le esecuzioni, consulta la sezione relativa ai `testSpecArn` parametri per l'API nella nostra guida all'`ScheduleRun`API.](https://docs.aws.amazon.com/devicefarm/latest/APIReference/API_ScheduleRun.html) ## Framework Appium In un ambiente di test personalizzato, Device Farm non inserisce né sostituisce alcuna funzionalità Appium nei test del framework Appium. Devi specificare le funzionalità di Appium del tuo test o nel file YAML di specifica del test o nel codice del test. ## Strumentazione Android Non devi apportare modifiche per spostare i tuoi test Instrumentation per Android in un ambiente di test personalizzato. ## iOS XCUITest Non è necessario apportare modifiche per spostare i XCUITest test iOS in un ambiente di test personalizzato. # Estensione degli ambienti di test personalizzati in Device Farm AWS Device Farm consente di configurare un ambiente personalizzato per i test automatici (modalità personalizzata), che è l'approccio consigliato per tutti gli utenti di Device Farm. La modalità personalizzata Device Farm ti consente di eseguire più di una semplice suite di test. In questa sezione, imparerai come estendere la tua suite di test e ottimizzare i test. Per ulteriori informazioni sugli ambienti di test personalizzati in Device Farm, vedere[Ambienti di test personalizzati in AWS Device Farm](custom-test-environments.md). **Topics** + [Impostazione di un PIN del dispositivo durante l'esecuzione dei test in Device Farm](custom-test-environments-extending-set-pin.md) + [Accelerazione dei test basati su Appium in Device Farm grazie alle funzionalità desiderate](custom-test-environments-extending-speed.md) + [Utilizzo di Webhook e altro APIs dopo l'esecuzione dei test in Device Farm](custom-test-environments-extending-webhooks.md) + [Aggiungere file aggiuntivi al pacchetto di test in Device Farm](custom-test-environments-extending-files.md) # Impostazione di un PIN del dispositivo durante l'esecuzione dei test in Device Farm Alcune applicazioni richiedono l'impostazione di un PIN sul dispositivo. Device Farm non supporta l'impostazione di un PIN sui dispositivi in modo nativo. Tuttavia, ciò è possibile con le seguenti avvertenze: + Il dispositivo deve avere Android 8 o versioni successive. + Il PIN deve essere rimosso al termine del test. Per impostare il PIN nei test, utilizza le `post_test` fasi `pre_test` e per impostare e rimuovere il PIN, come illustrato di seguito: ``` 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" ``` All'avvio della suite di test, viene impostato il PIN 1234. Dopo la chiusura della suite di test, il PIN viene rimosso. **avvertimento** Se non rimuovi il PIN dal dispositivo al termine del test, il dispositivo e il tuo account verranno messi in quarantena. Per ulteriori modi per estendere la suite di test e ottimizzare i test, consulta[Estensione degli ambienti di test personalizzati in Device Farm](custom-test-environments-extending.md). # Accelerazione dei test basati su Appium in Device Farm grazie alle funzionalità desiderate Quando usi Appium, potresti scoprire che la suite di test in modalità standard è molto lenta. Questo perché Device Farm applica le impostazioni predefinite e non fa ipotesi su come si desidera utilizzare l'ambiente Appium. Sebbene queste impostazioni predefinite siano basate sulle migliori pratiche del settore, potrebbero non essere applicabili alla vostra situazione. Per ottimizzare i parametri del server Appium, puoi regolare le funzionalità Appium predefinite nelle specifiche del test. Ad esempio, quanto segue imposta la `usePrebuildWDA` funzionalità `true` in una suite di test iOS per accelerare l'ora di avvio iniziale: ``` 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 & ``` Le funzionalità di Appium devono essere una struttura JSON citata e con escape da shell. Le seguenti funzionalità di Appium sono fonti comuni di miglioramento delle prestazioni: `noReset` e `fullReset` Queste due funzionalità, che si escludono a vicenda, descrivono il comportamento di Appium al termine di ogni sessione. Quando `noReset` è impostato su`true`, il server Appium non rimuove i dati dall'applicazione al termine di una sessione Appium, in effetti non esegue alcuna pulizia. `fullReset`disinstalla e cancella tutti i dati dell'applicazione dal dispositivo dopo la chiusura della sessione. Per ulteriori informazioni, consulta [Reset Strategies](http://appium.io/docs/en/writing-running-appium/other/reset-strategies/) nella documentazione di Appium. `ignoreUnimportantViews`(Solo Android) Indica ad Appium di comprimere la gerarchia dell'interfaccia utente Android solo nelle viste *pertinenti* per il test, velocizzando la ricerca di determinati elementi. Tuttavia, ciò può interrompere alcune suite di test XPath basate su di esse perché la gerarchia del layout dell'interfaccia utente è stata modificata. `skipUnlock`(Solo Android) Informa Appium che al momento non è impostato alcun codice PIN, il che velocizza i test dopo un evento di spegnimento dello schermo o un altro evento di blocco. `webDriverAgentUrl`(solo iOS) Indica ad Appium di presumere che una dipendenza iOS essenziale sia già in esecuzione e disponibile per accettare richieste HTTP all'URL specificato. `webDriverAgent` Se `webDriverAgent` non è già attivo e funzionante, Appium può impiegare del tempo all'inizio di una suite di test per avviare. `webDriverAgent` Se lo avvii `webDriverAgent` da solo e lo fai `http://localhost:8100` quando avvii Appium, puoi avviare la tua suite di test più velocemente. `webDriverAgentUrl` Nota che questa funzionalità non dovrebbe mai essere utilizzata insieme alla `useNewWDA` funzionalità. È possibile utilizzare il codice seguente per iniziare `webDriverAgent` dal file delle specifiche di test sulla porta locale del dispositivo`8100`, quindi inoltrarlo alla porta locale dell'host di test `8100` (ciò consente `webDriverAgentUrl` di impostare il valore su`http://localhost:8100`). Questo codice deve essere eseguito durante la fase di installazione dopo aver definito qualsiasi codice per la configurazione di Appium e delle variabili di `webDriverAgent` ambiente: ``` # 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 & ``` Quindi, puoi aggiungere il seguente codice al file delle specifiche di test per assicurarti che `webDriverAgent` sia avviato correttamente. Questo codice dovrebbe essere eseguito alla fine della fase di pre-test dopo aver verificato che Appium sia stato avviato correttamente: ``` # 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; ``` Per ulteriori informazioni sulle funzionalità supportate da Appium, consulta Appium Desired Capabilities nella documentazione di [Appium](http://appium.io/docs/en/writing-running-appium/caps/). Per ulteriori modi per estendere la suite di test e ottimizzare i test, consulta. [Estensione degli ambienti di test personalizzati in Device Farm](custom-test-environments-extending.md) # Utilizzo di Webhook e altro APIs dopo l'esecuzione dei test in Device Farm È possibile fare in modo che Device Farm chiami un webhook al termine dell'utilizzo **curl** di ogni suite di test. Il processo per eseguire questa operazione varia a seconda della destinazione e della formattazione. Per il tuo webhook specifico, consulta la documentazione relativa a quel webhook. L'esempio seguente pubblica un messaggio ogni volta che una suite di test termina su un webhook 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 ``` Per ulteriori informazioni sull'uso dei webhook con Slack, consulta [Invio del primo messaggio Slack utilizzando Webhook nel riferimento all'API Slack](https://api.slack.com/tutorials/slack-apps-hello-world). Per ulteriori modi per estendere la suite di test e ottimizzare i test, consulta. [Estensione degli ambienti di test personalizzati in Device Farm](custom-test-environments-extending.md) Non sei limitato a usare per **curl** chiamare i webhook. I pacchetti di test possono includere script e strumenti aggiuntivi, purché siano compatibili con l'ambiente di esecuzione Device Farm. Ad esempio, il pacchetto di test può includere script ausiliari che inoltrano richieste ad altri. APIs Assicurati che tutti i pacchetti richiesti siano installati insieme ai requisiti della tua suite di test. Per aggiungere uno script che viene eseguito dopo il completamento della suite di test, includi lo script nel pacchetto di test e aggiungi quanto segue alle specifiche di test: ``` phases: post_test: - python post_test.py ``` **Nota** La manutenzione delle chiavi API o degli altri token di autenticazione utilizzati nel pacchetto di test è una tua responsabilità. Ti consigliamo di mantenere qualsiasi forma di credenziale di sicurezza al di fuori del controllo del codice sorgente, di utilizzare credenziali con il minor numero di privilegi possibile e di utilizzare token revocabili e di breve durata quando possibile. Per verificare i requisiti di sicurezza, consulta la documentazione della terza parte che utilizzi. APIs Se prevedi di utilizzare AWS i servizi come parte della tua suite di esecuzione dei test, dovresti utilizzare le credenziali temporanee IAM, generate al di fuori della tua suite di test e incluse nel pacchetto di test. Queste credenziali devono avere il minor numero di autorizzazioni concesse e la durata di vita più breve possibile. *Per ulteriori informazioni sulla creazione di credenziali temporanee, consulta [Richiesta di credenziali di sicurezza temporanee nella Guida per l'utente IAM](https://docs.aws.amazon.com//IAM/latest/UserGuide/id_credentials_temp_request.html).* Per ulteriori modi per estendere la suite di test e ottimizzare i test, consulta. [Estensione degli ambienti di test personalizzati in Device Farm](custom-test-environments-extending.md) # Aggiungere file aggiuntivi al pacchetto di test in Device Farm Potresti voler utilizzare file aggiuntivi come parte dei tuoi test come file di configurazione aggiuntivi o dati di test aggiuntivi. Puoi aggiungere questi file aggiuntivi al tuo pacchetto di test prima di caricarlo AWS Device Farm, quindi accedervi dalla modalità ambiente personalizzata. Fondamentalmente, tutti i formati di caricamento dei pacchetti di test (ZIP, IPA, APK, JAR, ecc.) sono formati di archivio dei pacchetti che supportano le operazioni ZIP standard. È possibile aggiungere file all'archivio di test prima di caricarlo AWS Device Farm utilizzando il seguente comando: ``` $ zip zip-with-dependencies.zip extra_file ``` Per una directory di file aggiuntivi: ``` $ zip -r zip-with-dependencies.zip extra_files/ ``` Questi comandi funzionano come previsto per tutti i formati di caricamento dei pacchetti di test ad eccezione dei file IPA. Per i file IPA, specialmente se utilizzati con XCUITests, si consiglia di inserire i file aggiuntivi in una posizione leggermente diversa a causa della progettazione dei pacchetti AWS Device Farm di test iOS. Quando crei il tuo test iOS, la directory dell'applicazione di test si troverà all'interno di un'altra directory denominata*Payload*. Ad esempio, ecco come potrebbe apparire una di queste directory di test iOS: ``` $ 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 ``` Per questi XCUITest pacchetti, aggiungete eventuali file aggiuntivi alla directory che termina all'*.app*interno della *Payload* directory. Ad esempio, i comandi seguenti mostrano come aggiungere un file a questo pacchetto di test: ``` $ mv extra_file Payload/*.app/ $ zip -r my_xcui_tests.ipa Payload/ ``` Quando aggiungete un file al pacchetto di test, potete aspettarvi un comportamento di interazione leggermente diverso in AWS Device Farm base al formato di caricamento. Se il caricamento ha utilizzato l'estensione del file ZIP, AWS Device Farm decomprimerà automaticamente il caricamento prima del test e lascerà i file decompressi nella posizione con la *\$1DEVICEFARM\$1TEST\$1PACKAGE\$1PATH* variabile di ambiente. (Ciò significa che se aggiungeste un file chiamato *extra\$1file* alla radice dell'archivio come nel primo esempio, esso si troverebbe in *\$1DEVICEFARM\$1TEST\$1PACKAGE\$1PATH/extra\$1file* durante il test). Per usare un esempio più pratico, se sei un utente di Appium TestNG che desidera includere un *testng.xml* file nel test, puoi includerlo nel tuo archivio usando il seguente comando: ``` $ zip zip-with-dependencies.zip testng.xml ``` Quindi, puoi modificare il comando test nella modalità ambiente personalizzata nel modo seguente: ``` 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 l'estensione per il caricamento del pacchetto di test non è ZIP (ad esempio, APK, IPA o JAR), il file del pacchetto caricato si trova in*\$1DEVICEFARM\$1TEST\$1PACKAGE\$1PATH*. Poiché si tratta ancora di file in formato di archivio, puoi decomprimere il file per accedere ai file aggiuntivi dall'interno. Ad esempio, il comando seguente decomprimerà il contenuto del pacchetto di test (per file APK, IPA o JAR) nella directory: */tmp* ``` unzip $DEVICEFARM_TEST_PACKAGE_PATH -d /tmp ``` Nel caso di un file APK o JAR, i file aggiuntivi verranno decompressi */tmp* nella directory (ad esempio,). */tmp/extra\$1file* Nel caso di un file IPA, come spiegato in precedenza, i file aggiuntivi si troverebbero in una posizione leggermente diversa all'interno della cartella che termina con*.app*, che si trova all'interno della directory. *Payload* Ad esempio, in base all'esempio IPA precedente, il file si troverebbe nella posizione */tmp/Payload/ADFiOSReferenceAppUITests-Runner.app/extra\$1file* (referenziabile come). */tmp/Payload/\$1.app/extra\$1file* Per ulteriori modi per estendere la suite di test e ottimizzare i test, consulta. [Estensione degli ambienti di test personalizzati in Device Farm](custom-test-environments-extending.md)