As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

Extensão de ambientes de teste personalizados no Device Farm

O Device Farm Custom Mode permite que você execute mais do que apenas sua suíte de testes. Nesta seção, você aprenderá como estender sua suíte de testes e otimizar seus testes.

Definindo um PIN

Alguns aplicativos exigem que você defina um PIN no dispositivo. O Device Farm não suporta a configuração de a PIN em dispositivos de forma nativa. No entanto, isso é possível com as seguintes ressalvas:

Para definir o PIN em seus testes, use as post_test fases pre_test e para definir e remover oPIN, conforme mostrado a seguir:

phases:
    pre_test:
      - # ... among your pre_test commands
      - DEVICE_PIN_CODE="1234"
      - adb shell locksettings set-pin "$DEVICE_PIN_CODE"
    post_test:
      - # ... Among your post_test commands
      - adb shell locksettings clear --old "$DEVICE_PIN_CODE"
    

Quando sua suíte de testes começa, o PIN 1234 é definido. Depois que sua suíte de testes PIN for encerrada, o será removido.

Acelerar os testes baseados no Appium por meio dos recursos desejados

Ao usar o Appium, você pode descobrir que o conjunto de testes do modo padrão é muito lento. Isso ocorre porque o Device Farm aplica as configurações padrão e não faz nenhuma suposição sobre como você deseja usar o ambiente Appium. Embora esses padrões sejam criados com base nas melhores práticas do setor, eles podem não se aplicar à sua situação. Para ajustar os parâmetros do servidor Appium, você pode ajustar os recursos padrão do Appium em sua especificação de teste. Por exemplo, o seguinte define o recurso usePrebuildWDA como true em um conjunto de testes do iOS para acelerar o tempo de início inicial:

phases:
  pre_test:
    - # ... Start up Appium
    - >-
    appium --log-timestamp
    --default-capabilities "{\"usePrebuiltWDA\": true, \"derivedDataPath\":\"$DEVICEFARM_WDA_DERIVED_DATA_PATH\",
    \"deviceName\": \"$DEVICEFARM_DEVICE_NAME\", \"platformName\":\"$DEVICEFARM_DEVICE_PLATFORM_NAME\", \"app\":\"$DEVICEFARM_APP_PATH\",
    \"automationName\":\"XCUITest\", \"udid\":\"$DEVICEFARM_DEVICE_UDID_FOR_APPIUM\", \"platformVersion\":\"$DEVICEFARM_DEVICE_OS_VERSION\"}"
    >> $DEVICEFARM_LOG_DIR/appiumlog.txt 2>&1 &
      
    

As capacidades do Appium devem ser uma estrutura cotada e que escapa de uma concha. JSON

Os seguintes recursos do Appium são fontes comuns de melhorias de desempenho:

Para obter mais informações sobre os recursos compatíveis com o Appium, consulte Appium Desired Capabilities na documentação do Appium.

Usando Webhooks e outros APIs após a execução dos testes

Você pode fazer com que o Device Farm chame um webhook depois que cada conjunto de testes terminar de usar curl. O processo para fazer isso varia de acordo com o destino e a formatação. Para seu webhook específico, consulte a documentação desse webhook. O exemplo a seguir publica uma mensagem sempre que uma suíte de testes termina em um webhook do Slack:

phases:
  post_test:
    - curl -X POST -H 'Content-type: application/json' --data '{"text":"Tests on '$DEVICEFARM_DEVICE_NAME' have finished!"}' https://hooks.slack.com/services/T00000000/B00000000/XXXXXXXXXXXXXXXXXXXXXXXX

Para obter mais informações sobre como usar webhooks com o Slack, consulte Enviar sua primeira mensagem do Slack usando o Webhook na referência do Slack. API

Você não está limitado a usar curl para chamar webhooks. Os pacotes de teste podem incluir scripts e ferramentas extras, desde que sejam compatíveis com o ambiente de execução do Device Farm. Por exemplo, seu pacote de teste pode incluir scripts auxiliares que fazem solicitações a outrosAPIs. Certifique-se de que todos os pacotes necessários estejam instalados junto com os requisitos da sua suíte de testes. Para adicionar um script que seja executado após a conclusão da suíte de testes, inclua o script em seu pacote de teste e adicione o seguinte à sua especificação de teste:

phases:
  post_test:
    - python post_test.py

Se você planeja usar AWS serviços como parte de sua suíte de execução de testes, você deve usar credenciais IAM temporárias, geradas fora da suíte de testes e incluídas no pacote de testes. Essas credenciais devem ter o menor número de permissões concedidas e a menor vida útil possível. Para obter mais informações sobre a criação de credenciais temporárias, consulte Solicitação de credenciais de segurança temporárias no Guia do IAM usuário.

Adicionar arquivos extras ao seu pacote de teste

Talvez você queira usar arquivos adicionais como parte de seus testes como arquivos extras de configuração ou dados de teste adicionais. Você pode incluir esses arquivos adicionais ao seu pacote de testes antes de carregá-lo no AWS Device Farm e acessá-los no modo de ambiente personalizado. Fundamentalmente, todos os formatos de upload de pacotes de teste (ZIPIPA,, APKJAR, etc.) são formatos de arquivamento de pacotes que oferecem suporte a ZIP operações padrão.

Você pode adicionar arquivos ao seu arquivo de teste antes de enviá-lo AWS Device Farm usando o seguinte comando:

$ zip zip-with-dependencies.zip extra_file

Para um diretório de arquivos extras:

$ zip -r zip-with-dependencies.zip extra_files/

Esses comandos funcionam conforme o esperado para todos os formatos de upload de pacotes de teste, exceto para IPA arquivos. Para IPA arquivos, especialmente quando usados comXCUITests, recomendamos que você coloque os arquivos extras em um local um pouco diferente devido à forma como os pacotes de teste do iOS são AWS Device Farm resignados. Ao criar seu teste do iOS, o diretório do aplicativo de teste estará localizado dentro de outro diretório chamado Payload.

Por exemplo, é assim que um desses diretórios de teste do iOS pode parecer:

$ tree
.
└── Payload
    └── ADFiOSReferenceAppUITests-Runner.app
        ├── ADFiOSReferenceAppUITests-Runner
        ├── Frameworks
        │   ├── XCTAutomationSupport.framework
        │   │   ├── Info.plist
        │   │   ├── XCTAutomationSupport
        │   │   ├── _CodeSignature
        │   │   │   └── CodeResources
        │   │   └── version.plist
        │   └── XCTest.framework
        │       ├── Info.plist
        │       ├── XCTest
        │       ├── _CodeSignature
        │       │   └── CodeResources
        │       ├── en.lproj
        │       │   └── InfoPlist.strings
        │       └── version.plist
        ├── Info.plist
        ├── PkgInfo
        ├── PlugIns
        │   ├── ADFiOSReferenceAppUITests.xctest
        │   │   ├── ADFiOSReferenceAppUITests
        │   │   ├── Info.plist
        │   │   └── _CodeSignature
        │   │       └── CodeResources
        │   └── ADFiOSReferenceAppUITests.xctest.dSYM
        │       └── Contents
        │           ├── Info.plist
        │           └── Resources
        │               └── DWARF
        │                   └── ADFiOSReferenceAppUITests
        ├── _CodeSignature
        │   └── CodeResources
        └── embedded.mobileprovision

Para esses XCUITest pacotes, adicione quaisquer arquivos extras ao diretório que termina em .app dentro do Payload diretório. Por exemplo, os comandos a seguir mostram como você pode adicionar um arquivo a esse pacote de teste:

$ mv extra_file Payload/*.app/
$ zip -r my_xcui_tests.ipa Payload/

Ao adicionar um arquivo ao seu pacote de teste, você pode esperar um comportamento de interação um pouco diferente no AWS Device Farm com base no formato de upload. Se o upload usou a extensão do ZIP arquivo, AWS Device Farm descompactará automaticamente o upload antes do teste e deixará os arquivos descompactados no local com o $DEVICEFARM_TEST_PACKAGE_PATH variável de ambiente. (Isso significa que se você adicionou um arquivo chamado extra_file para a raiz do arquivo, como no primeiro exemplo, ele estaria localizado em $DEVICEFARM_TEST_PACKAGE_PATH/extra_file durante o teste).

Para usar um exemplo mais prático, se você for um usuário do Appium TestNG que deseja incluir um testng.xml arquivo com seu teste, você pode incluí-lo em seu arquivo usando o seguinte comando:

$ zip zip-with-dependencies.zip testng.xml

Em seguida, você pode alterar seu comando de teste no modo de ambiente personalizado para o seguinte:

java -D appium.screenshots.dir=$DEVICEFARM_SCREENSHOT_PATH org.testng.TestNG -testjar *-tests.jar -d $DEVICEFARM_LOG_DIR/test-output $DEVICEFARM_TEST_PACKAGE_PATH/testng.xml

Se a extensão de upload do pacote de teste não for ZIP (por exemploAPK,IPA,, ou JAR arquivo), o arquivo do pacote enviado em si será encontrado em $DEVICEFARM_TEST_PACKAGE_PATH. Como esses ainda são arquivos em formato de arquivamento, você pode descompactar o arquivo para acessar os arquivos adicionais a partir de dentro. Por exemplo, o comando a seguir descompactará o conteúdo do pacote de teste (para APKIPA, ou JAR arquivos) no /tmp diretório:

unzip $DEVICEFARM_TEST_PACKAGE_PATH -d /tmp

No caso de um JAR arquivo APK ou, você encontraria seus arquivos extras descompactados no /tmp diretório (por exemplo, /tmp/extra_file). No caso de um IPA arquivo, conforme explicado anteriormente, os arquivos extras estariam em um local ligeiramente diferente dentro da pasta que termina em .app, que está dentro do Payload diretório. Por exemplo, com base no IPA exemplo acima, o arquivo seria encontrado no local /tmp/Payload/ADFiOSReferenceAppUITests-Runner.app/extra_file (referenciável como /tmp/Payload/*.app/extra_file).