A automação de teste ajuda a resolver vários problemas ao mesmo tempo - inclusive quando se trata de aplicativos móveis. Em vez de executar manualmente procedimentos rotineiros de trabalho intensivo, os especialistas podem delegar uma parte significativa deles nas estruturas. A automação simplifica os testes e ajuda a acelerar os testes de regressão, além de possibilitar o uso de tipos de testes anteriormente inacessíveis.
Vamos comparar várias ferramentas que se estabeleceram no mercado e continuarão a se desenvolver. Esse conhecimento o ajudará a escolher qual solução usar para testar um aplicativo móvel específico.
É improvável que este artigo abra novos horizontes para profissionais, mas pode ser útil para iniciantes que decidem aprender o básico sobre testes móveis e, em certa medida, especialistas de nível médio.
Classificação da ferramenta
A primeira coisa que você deve construir é a plataforma na qual o aplicativo é executado. Com base nisso, classificamos a lista de ferramentas da seguinte maneira:
AndroidiOSUniversal- Desintoxicação
- Appium
- Ranorex
- TestComplete Mobile
Automação de teste de aplicativos Android
UI Automator
Ferramenta de teste poderosa com integração externa avançada. Isso significa que essa estrutura não apenas permite testar o aplicativo em si, mas também é capaz de "se comunicar" com o sistema operacional e outros aplicativos - por exemplo, ativar e desativar Wi-Fi, GPS, abrir o menu de configurações durante o teste e fazer outras interações externas.
O objetivo do UI Automator é o teste de caixa preta. Isso significa que a análise é realizada a partir da posição de um usuário externo sem acesso ao código.
Os principais recursos incluem:
- UI Automator Viewer para rastrear e analisar componentes exibidos na tela durante o teste. Ele fornece informações sobre elementos e suas propriedades, o que facilita a criação de testes mais relevantes.
- API para obter informações sobre o status do dispositivo e os processos em execução nele.
- APIs do UI Automator para testes em várias plataformas.
Link para a documentação .
Espresso
Uma ferramenta mais leve que o UI Automator, não adequada para interagir com aplicativos externos, mas conveniente para testar uma caixa branca com acesso ao código fonte de um aplicativo específico ou testar uma caixa cinza, com que tem acesso a alguns processos e estrutura internos.
No entanto, o Espresso se destaca com sua poderosa API
https://github.com/hamcrest . A interface adiciona métodos convenientes para verificações em autotestes, por exemplo:
assert_that (1, less_ou_equal (2)). Para testar a visualização na web, métodos
especiais são usados.
O UI Automator e o Espresso são complementares entre si e podem ser usados em combinação no mesmo projeto.
Link para a documentação .
Automação de Teste para Aplicativos iOS
XCUITest
Uma ferramenta para teste de caixa preta sem acessar o código do aplicativo. Funciona apenas com produtos nativos - infelizmente, os testes entre aplicativos não funcionam.
Por outro lado, a natureza nativa da estrutura é uma vantagem do ponto de vista de que, ao usar o XCUITest, o grau de entendimento mútuo de desenvolvedores e testadores está em um nível muito mais alto do que nos casos em que um e outro usam idiomas diferentes.
Uma adição útil é o gravador de teste, que permite escrever testes registrando ações no aplicativo, mesmo para quem não trabalha com o código.
A ferramenta permite evitar erros comuns e desnecessárias, inacessíveis ao usuário, manipulações com o código. No entanto, o XCUITest também tem algumas desvantagens.
O XCUITest, diferentemente do Espresso, funciona em um thread separado. Durante o teste, é necessário aguardar o aparecimento de certos elementos e parâmetros. O estado atual do aplicativo não é lido e atrasos na atualização de dados podem levar à incapacidade de detectar os elementos solicitados.
Documentação XCTest e XCUITest .
Earlgrey
A ênfase do EarlGrey está na reprodução da experiência do usuário. Enquanto os elementos na tela não forem apresentados visualmente, a simulação de trabalho com o aplicativo não será iniciada.
Ao mesmo tempo, são observadas várias comodidades e vantagens. Antes de tudo, especialistas gostam da maneira como a estrutura sincroniza solicitações, interfaces de usuário e threads. Não é necessário esperar por vista e aguardar.
Em segundo lugar, como já mencionado, é dada atenção especial ao rastreamento da visibilidade dos elementos. A ferramenta possui uma camada adicional para verificar o carregamento da interface e reproduz gestos do usuário - deslize, cliques - diretamente no nível do evento do aplicativo.
Links do repositório:
github.com/google/EarlGrey e
google.imtqy.com/EarlGrey .
Ferramentas universais
As ferramentas universais (ou "combina") permitem não limitar sua escolha apenas ao Android ou iOS, mas trabalhar com ambas as plataformas.
Essas ferramentas são aplicáveis para testar aplicativos dos seguintes tipos:
- Aplicativos nativos (aplicativos nativos) - escritos diretamente no Android, iOS e Windows SDK.
- Aplicativos da web para celular - disponíveis em um navegador para celular, como o Safari ou o Chrome.
- Aplicativos híbridos (aplicativos híbridos) - o usuário trabalha com o shell do aplicativo da web, ou seja, interage com o conteúdo da web por meio da interface do aplicativo nativo.
Desintoxicação
Em nossa opinião, o Detox é conveniente para aplicativos escritos em React Native. Os testes são gravados em JavaScript, enquanto os aplicativos iOS e Android são gerados a partir do mesmo código JavaScript e são os mais semelhantes possíveis. Isso permite que você use os mesmos testes para ambas as plataformas.
Uma característica fundamental do Detox é o teste da caixa cinza. Nesse caso, a estrutura possui algum acesso a mecanismos internos, o que permite correlacionar o comportamento externo do aplicativo com o que acontece em um nível mais profundo.
A desintoxicação pode acessar a memória e acompanhar os processos em execução. O princípio da caixa cinza ajuda a combater a instabilidade, o que se reflete no fato de que, durante os testes de ponta a ponta:
- O teste pode travar aleatoriamente, mesmo sem alterações no código;
- Os resultados não são determinísticos - devido ao grande número de funcionalidades e processos heterogêneos no aplicativo, os resultados de cada inicialização podem diferir imprevisivelmente um do outro.
- Os testadores são forçados a sincronizar manualmente, o que implica uma diminuição na confiabilidade e na qualidade dos resultados.
Curiosamente, a “caixa cinza” mostra não apenas melhor estabilidade, mas também maior velocidade em comparação com a “caixa preta”. Evitando todos os tipos de pausas, aguarde até que a caixa cinza possa ser 5 a 10 vezes mais rápida.
A desintoxicação não precisa do WebDriver, trabalhando com o driver nativo por meio do JSON. Ele usa métodos nativos diretamente no dispositivo. Dentro dessa estrutura, EarlGrey para iOS e Espresso para Android são usados.
A estrutura funciona com emuladores e dispositivos físicos.
Link para a documentação .
Appium
A vantagem do Appium é que é possível escrever testes para cada plataforma usando uma única API, sem recorrer à conversão do aplicativo em qualquer formato especial compatível com a estrutura.
Ao testar, estruturas de fornecedores são usadas - ou seja, você está trabalhando com o aplicativo original. Para o Android 4.2+, respectivamente, é usado o UiAutomator / UiAutomator2 e para o iOS 9.3+ - XCUITest. O WebDriver (também conhecido como Selenium WebDriver) é usado como uma estrutura de estrutura.
Princípios de Appium:
- Não há necessidade de recompilar o aplicativo ou modificá-lo para automatizar o teste.
- Não é necessário anexar-se a um idioma ou estrutura.
- Não é necessário reinventar a roda quando se trata de APIs de automação.
O uso do Appium é justificado quando você precisa de uma ferramenta para automatizar testes em várias plataformas ao mesmo tempo. É útil se você tiver especialistas com experiência em testes de aplicativos da Web, mas nenhuma experiência em automatizar o teste de aplicativos móveis.
Em geral, essa é uma ferramenta flexível que pode ser modificada para atender às necessidades do projeto sem a necessidade de adaptação a um conjunto limitado de linguagens de desenvolvimento.
Link para a documentação .
Ranorex
Ferramenta abrangente paga para testar aplicativos de desktop, móveis e web. Permite testar usando programação e sem usar scripts. Oferece a capacidade de testar não apenas através de emuladores, mas também em dispositivos ativos.
A ferramenta permite criar e configurar testes, além de gerenciá-los centralmente. Você pode criar um teste no centro de controle e executá-lo em vários ambientes externos e em qualquer dispositivo.
Integra-se facilmente ao seu ambiente de IC existente: com sistemas de gerenciamento de aplicativos como Jira e TFS, bem como sistemas de controle de versão como Git e SVN.
Ranorex tem testes orientados a dados com carregamento de dados de SQL, CSV e Excel.
A ferramenta é adequada para absolutamente qualquer dispositivo, suporta testes paralelos em cada um deles.
Ele combina as três abordagens de teste: caixa preta, caixa branca e caixa cinza.
Link para a documentação .
Testcomplete
Ambiente pago para testar a automação de aplicativos móveis, da Web e de desktop. Ele suporta Android e iOS, e no contexto de tipos de aplicativos: nativo, aplicativos Web e híbrido.
Focada principalmente em testes funcionais e de unidade, a ferramenta também oferece a capacidade de realizar muitos outros tipos de teste:
- Regressão;
- Teste orientado a dados;
- Teste distribuído e muito mais.
Existe um gravador no TestComplete - nele, os testes são criados registrando ações e definindo comandos no editor. Em seguida, eles podem ser iniciados diretamente na própria ferramenta ou exportados para aplicativos de terceiros.
Essa ferramenta reconhece objetos e controles oferecendo comandos especiais para emular a interação do usuário com eles. Integra-se a Jenkins, Git e Jira, permitindo executar testes contínuos contínuos.
Link para a documentação .
Resumir
Ao planejar testar este ou aquele aplicativo móvel, preste atenção às ferramentas listadas acima. Cada um deles tem suas próprias características e, às vezes, limitações.
Vejamos um exemplo. Se você se deparar com a tarefa de testar um aplicativo pequeno em pouco tempo, é necessário levar em consideração fatores como o tipo de aplicativo que está sendo testado e a experiência de seus especialistas. Se um desenvolvedor escreve testes, é melhor escolher um idioma nativo e uma ferramenta para sua plataforma (veja a tabela abaixo). Se os testes forem realizados por especialistas em SDET que estão familiarizados com outras linguagens (Java, JavaScript, Python etc.) e trabalharam com o Selenium, é conveniente usar o Appium. Se não houver SDET experiente na equipe e os especialistas em controle de qualidade escreverem testes, é melhor escolher estruturas pagas, pois elas possuem utilitários para gravação de testes e suporte técnico mais estável do que estruturas de código aberto.
De nossa prática:
Trabalhamos com uma loja on-line, que tinha dois aplicativos móveis - no iOS e no Android. Para testar os principais cenários de usuário com testes, escolhemos Appium por vários motivos:
- multiplataforma, a capacidade de reutilizar parcialmente o código
- adequado para testes de ponta a ponta, pode trabalhar com a web
- a presença na equipe de especialistas que conhecem bem o selênio, que serve como base dessa estrutura.
Como resultado, o Appium atendeu totalmente às expectativas, realizamos testes com sucesso para iOS e Android. Deve-se ter em mente que esses testes de ponta a ponta com o Appium não são executados em todas as solicitações de mesclagem, pois leva muito tempo.Concluindo, chamamos a atenção para uma tabela que o ajudará a escolher a ferramenta para o seu projeto. Note-se que em alguns casos, a divisão na tabela é condicional. Em algum lugar para simplificar, é feita uma generalização e apenas os parâmetros mais básicos são fornecidos. As ferramentas de teste estão em constante evolução; portanto, ao escolher uma estrutura, é importante verificar a documentação atual.
Obrigado pela atenção!