Configurando um PIN Acelerar os testes baseados no Appium por meio dos recursos desejados Usando webhooks e outras APIs após a execução dos testes Adicionar arquivos extras ao seu pacote de teste

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.

Configurando um PIN

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

O dispositivo deve estar executando o Android 8 ou superior.
O PIN deve ser removido após a conclusão do teste.

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



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

Quando o conjunto de testes é iniciado, o PIN 1234 é definido. Depois que sua suíte de testes sair, o PIN será removido.

Atenção

Se você não remover o PIN do dispositivo após a conclusão do teste, o dispositivo e sua conta serão colocados em quarentena.

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 &

Os recursos do Appium devem ser uma estrutura JSON citada e com escape de shell.

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

noReset e fullReset

Esses dois recursos, que são mutuamente exclusivos, descrevem o comportamento do Appium após a conclusão de cada sessão. Quando noReset está definido como true, o servidor Appium não remove dados da aplicação quando uma sessão do Appium termina, efetivamente não fazendo nenhuma limpeza. fullReset desinstala e limpa todos os dados da aplicação do dispositivo após o encerramento da sessão. Para obter mais informações, consulte Reset Strategies na documentação do Appium.

ignoreUnimportantViews (somente Android)

Instrui o Appium a compactar a hierarquia da interface do usuário do Android somente em visualizações relevantes para o teste, acelerando as pesquisas de determinados elementos. No entanto, isso pode interromper alguns conjuntos de testes baseados em XPath porque a hierarquia do layout da interface do usuário foi alterada.

skipUnlock (somente Android)

Informa à Appium que não há um código PIN definido atualmente, o que acelera os testes após um evento de desligamento da tela ou outro evento de bloqueio.

webDriverAgentUrl (somente iOS)

Instrui o Appium a assumir que uma dependência essencial do iOS, webDriverAgent, já está em execução e disponível para aceitar solicitações HTTP no URL especificado. Se webDriverAgent ainda não estiver instalado e funcionando, o Appium pode levar algum tempo no início de um conjunto de testes para iniciar o webDriverAgent. Se você iniciar webDriverAgent por conta própria e definir webDriverAgentUrl como http://localhost:8100 ao iniciar o Appium, poderá inicializar o conjunto de testes mais rapidamente. Observe que esse recurso nunca deve ser usado junto com o recurso useNewWDA.

Você pode usar o código a seguir para iniciar webDriverAgent pelo arquivo de especificação de teste na porta local 8100 do dispositivo e, depois, encaminhá-lo para a porta local 8100 do host de teste (isso permite que você defina o valor de webDriverAgentUrl como http://localhost:8100). Esse código deve ser executado durante a fase de instalação após qualquer código para configurar o Appium e a definição das variáveis de ambiente webDriverAgent:


      # Start WebDriverAgent and iProxy
      - >-
        xcodebuild test-without-building -project /usr/local/avm/versions/$APPIUM_VERSION/node_modules/appium/node_modules/appium-webdriveragent/WebDriverAgent.xcodeproj
        -scheme WebDriverAgentRunner -derivedDataPath $DEVICEFARM_WDA_DERIVED_DATA_PATH
        -destination id=$DEVICEFARM_DEVICE_UDID_FOR_APPIUM IPHONEOS_DEPLOYMENT_TARGET=$DEVICEFARM_DEVICE_OS_VERSION
        GCC_TREAT_WARNINGS_AS_ERRORS=0 COMPILER_INDEX_STORE_ENABLE=NO >> $DEVICEFARM_LOG_DIR/webdriveragent_log.txt 2>&1 &
        
        iproxy 8100 8100 >> $DEVICEFARM_LOG_DIR/iproxy_log.txt 2>&1 &

Depois, você pode adicionar o código a seguir ao arquivo de especificação de teste para garantir que webDriverAgent tenha iniciado com êxito. Esse código deve ser executado no final da fase de pré-teste depois de garantir que o Appium tenha sido iniciado com sucesso:


      # Wait for WebDriverAgent to start
      - >-
        start_wda_timeout=0;
        while [ true ];
        do
          if [ $start_wda_timeout -gt 60 ];
          then
              echo "WebDriverAgent server never started in 60 seconds.";
              exit 1;
          fi;
          grep -i "ServerURLHere" $DEVICEFARM_LOG_DIR/webdriveragent_log.txt >> /dev/null 2>&1;
          if [ $? -eq 0 ];
          then
              echo "WebDriverAgent REST http interface listener started";
              break;
          else
              echo "Waiting for WebDriverAgent server to start. Sleeping for 1 seconds";
              sleep 1;
              start_wda_timeout=$((start_wda_timeout+1));
          fi;
        done;

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

Usando webhooks e outras 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 Sending your first Slack message using Webhook na referência de API do Slack.

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 para outras APIs. Certifique-se de que todos os pacotes necessários estejam instalados junto com os requisitos da sua suíte de testes. Para adicionar um script que seja executado após a conclusão da suíte de testes, inclua o script em seu pacote de teste e adicione o seguinte à sua especificação de teste:


phases:
  post_test:
    - python post_test.py

nota

A manutenção de todas as chaves de API ou outros tokens de autenticação usados em seu pacote de teste é de sua responsabilidade. Recomendamos que você mantenha qualquer forma de credencial de segurança fora do controle de origem, use credenciais com o menor número possível de privilégios e use tokens revogáveis e de curta duração sempre que possível. Para verificar os requisitos de segurança, consulte a documentação das APIs de terceiros que você usa.

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

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. Basicamente, todos os formatos de upload de pacotes de teste (ZIP, IPA, APK, JAR etc.) são formatos de arquivamento de pacotes compatíveis com operações ZIP padrão.

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


$ zip zip-with-dependencies.zip extra_file

Para um diretório de arquivos extras:


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

Esses comandos funcionam conforme o esperado para todos os formatos de upload de pacotes de teste, exceto para arquivos IPA. Para arquivos IPA, especialmente quando usados com XCUITests, recomendamos que você coloque todos os arquivos extras em um local ligeiramente diferente devido à forma como os pacotes de teste do iOS são AWS Device Farm resignados. Ao criar seu teste para iOS, o diretório da aplicação 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 pacotes do XCUITest, adicione qualquer arquivo extra ao diretório que termina em .app dentro do diretório Payload. Por exemplo, os comandos a seguir mostram como você pode adicionar um arquivo a esse pacote de teste:


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

Ao adicionar um arquivo ao seu pacote de teste, você pode esperar um comportamento de interação um pouco diferente no AWS Device Farm com base no formato de upload. Se o upload usou a extensão de arquivo ZIP, o AWS Device Farm descompactará automaticamente o upload antes do teste e deixará os arquivos descompactados no local com a variável de ambiente $DEVICEFARM_TEST_PACKAGE_PATH. (Isso significa que se você adicionasse um arquivo chamado extra_file à 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 arquivo testng.xml em seu teste, ele poderá ser incluído no arquivo usando o seguinte comando:


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

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


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

Se a extensão de upload do pacote de teste não for ZIP (por exemplo, arquivo APK, IPA ou JAR), o arquivo do pacote carregado 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 de dentro. Por exemplo, o comando a seguir descompactará o conteúdo do pacote de teste (para arquivos APK, IPA ou JAR) no diretório /tmp:


unzip $DEVICEFARM_TEST_PACKAGE_PATH -d /tmp

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

Atenção O Javascript está desativado ou não está disponível no seu navegador.

Para usar a documentação da AWS, o Javascript deve estar ativado. Consulte as páginas de Ajuda do navegador para obter instruções.

Convenções do documento

Migrar testes

Trabalhar com acesso remoto