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à. # 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)