Appium Capacidades desejadas para Android emulador

Quais são as capacidades desejadas

As 'Capacidades Desejadas' nos ajudam a modificar o comportamento do servidor durante a automação. Appium É um mapa hash, ou par chave-valor, usado para enviar um comando para o Appium servidor, onde cada comando do cliente é executado no contexto de uma sessão.

Por exemplo, um cliente envia uma solicitação POST /session contendo um objeto JSON para o Appium servidor.

Assim, para enviar uma solicitação ou manter uma sessão com o servidor, utiliza-se um conjunto de pares de chave e valor. Isso é conhecido como 'Desired Capabilities' (Capacidades Desejadas).

import io.appium.java_client.AppiumDriver;
import org.openqa.selenium.remote.DesiredCapabilities;
{
        DesiredCapabilities capabilities = new DesiredCapabilities();
        capabilities.setCapability("deviceName","Android Emulator");
        capabilities.setCapability("platformVersion", "4.4");
}

Papel importante da capacidade desejada

• As 'DesiredCapabilities' ajudam o usuário a controlar a solicitação de sessão com o servidor. Por exemplo, para uma sessão iOS, definimos a capacidade platformName = iOS e para uma sessão não iOS, definimos platformName = ['platformName'] ... Android nomeDaPlataformaDaSessão = Android.
• As 'DesiredCapabilities' são usadas para configurar a instância do WebDriver, por exemplo. FirefoxDriver, ChromeDriver ou InternetExplorerDriver.
• DesiredCapability é muito útil para Selenium Grid. Por exemplo, é usado para executar diferentes casos de teste em navegadores e sistemas operacionais diferentes. Com base na capacidade declarada, o hub do Grid aponta para o nó correspondente. Os nós são definidos usando os métodos de propriedade 'set':

  DesiredCapabilities obj = new DesiredCapabilities(); 
  obj.setBrowserName("firefox"); 
  obj.setVersion("18.0.1"); 
  obj.setPlatform(org.openqa.selenium.Platform.WINDOWS);					
  

• Uma funcionalidade desejada é um pacote definido pela biblioteca. Antes de usar 'DesiredCapabilities', ela deve ser importada da biblioteca abaixo.

  Org.openqa.selenium.remote.DesiredCapabilities

Appium suporta ambos Android e iOS, portanto, há um conjunto separado de Appium Capacidades do servidor para cada plataforma.

A tabela abaixo mostra alguns usos comuns. Android capacidades e valores a serem utilizados.

NOTA: consulte o Appium documentação para ver mais Android capacidades.

A tabela abaixo mostra algumas funcionalidades do iOS comumente usadas e os valores a serem utilizados.

NOTA: consulte o Appium guia de recursos Para visualizar mais recursos do iOS.

Como as capacidades desejadas mudaram em Appium 2

Os exemplos acima são provenientes de Appium A primeira era ainda mostra o formato de um conjunto de capacidades, mas duas regras foram alteradas e ambas impedirão o início de uma sessão moderna.

Em primeiro lugar, a especificação WebDriver do W3C define apenas um pequeno conjunto de recursos padrão, dos quais platformName e browserName Este é o ponto principal. Todas as outras funcionalidades são extensões de fornecedor e devem conter um prefixo de namespace terminado em dois pontos. AppiumO prefixo de 's é appium:. Assim deviceName torna-se appium:deviceName e platformVersion torna-se appium:platformVersion. Appium 2 também requer appium:automationName, porque os drivers são instalados separadamente, em vez de serem incluídos no pacote do servidor.

Em segundo lugar, repetir o prefixo torna-se tedioso, então Appium aceita um único appium:options Capacidade cujo valor é um objeto. As capacidades dentro desse objeto não precisam de prefixo e, quando um nome aparece tanto dentro quanto fora do objeto, o valor interno prevalece.

{
    "platformName": "iOS",
    "appium:options": {
        "automationName": "XCUITest",
        "platformVersion": "16.0",
        "app": "/path/to/your.app",
        "deviceName": "iPhone 12",
        "noReset": true
    }
}

⚠️ Nota de versão: na Java lado, Selenium 4 e Appium Java O cliente 8 descontinuou o DesiredCapabilities Classe mostrada anteriormente. Construtores específicos do driver herdados de BaseOptions substitua-o — UiAutomator2Options pela Android e XCUITestOptions para iOS — com um mapa um para umping de cada velho setCapability chamada. O código original acima é mantido aqui como exemplo histórico.

ExtracInformações sobre pacotes e atividades

Pacotes são arquivos ou classes agrupados. Eles fornecem uma estrutura organizada para a programação modular. JavaEm aplicações móveis, diferentes pacotes são armazenados em um único arquivo JAR, e o usuário pode chamar esse JAR para execução completa. Um conceito semelhante é seguido no desenvolvimento de aplicações móveis.

De acordo com o relatório Android sistema operacional, todos os aplicativos são instalados na forma de Java pacotes. Então, para extracinformações do caminho do pacote t, o Android A classe PackageManager é usada.

Ele recupera informações sobre pacotes e atividades de aplicativos pré-instalados e pós-instalados no dispositivo.

Você pode obter uma instância da classe PackageManager chamando o método getPackageManager(). Esse método permite acessar e manipular os pacotes e as permissões relacionadas dos aplicativos instalados.

Por exemplo:

PackageManager pManager = getPackageManager();
List<ApplicationInfo> list = pManager.getInstalledApplications(PackageManager.GET_META_DATA)

Como encontrar appPackage e appActivity com adb

A rota do PackageManager acima funciona de dentro de um aplicativo. Como testador, você geralmente tem apenas a versão instalada, então o caminho mais rápido é uma consulta sobre adb contra um dispositivo conectado ou emulador.

Abra o aplicativo manualmente no dispositivo e, em seguida, execute um dos comandos abaixo em um terminal na pasta platform-tools. O comando imprime a janela que está em foco no momento e o valor é formatado como package/activity.

adb shell dumpsys window | find "mCurrentFocus"
adb shell dumpsys window windows | grep -i "mCurrentFocus"

Use o primeiro formulário no Windows prompt de comando e o segundo em um shell Unix ou Git Bash. Leia o resultado como duas metades: tudo antes da barra é o valor de appPackagee tudo o que vem depois é o valor de appActivity.

Duas ressalvas se aplicam. A atividade em foco é aquela que está na tela naquele momento, que nem sempre é a atividade com a qual o aplicativo inicia — se uma sessão falhar durante a inicialização do driver, inicie o aplicativo novamente e leia o valor mais uma vez. E se uma tela de apresentação (splash screen) aparecer primeiro, a atividade de entrada será diferente daquela que você deseja usar para a verificação, que é exatamente o caso. appWaitActivity existe para.

Uma alternativa visual é uiautomatorviewer, que captura a hierarquia atual da tela e mostra o pacote e a classe de cada nó.

Erros comuns nas capacidades desejadas e como corrigi-los

A maioria falhou Appium As sessões são encerradas antes da execução de qualquer etapa de teste, e a causa quase sempre está no conjunto de recursos, e não no teste em si. A tabela abaixo relaciona cada mensagem à sua respectiva solução.

Quando uma sessão se recusar a iniciar, leia o Appium log do servidor em vez da pilha do cliente trace. O servidor indica qual funcionalidade não pôde ser atendida, e essa linha especifica a solução.

Perguntas Frequentes