Plataformas de teste móvel na nuvem

E agora chegou o momento em que nossas necessidades de teste ficaram lotadas na área de trabalho do testador. A alma pediu para as nuvens. Na verdade não. Na verdade não.



Nossas metas e objetivos


(leitor apressado, você pode terminar na próxima seção)


Estamos desenvolvendo um aplicativo financeiro para o mercado externo, disponível em diferentes formatos: para navegadores de desktop (site e extensão do Google Chrome), para navegadores móveis, bem como um aplicativo híbrido para telefones. Devido às especificidades do aplicativo, prestamos atenção especial ao teste do aplicativo em várias configurações e dispositivos. Para nós, a operação estável e segura do aplicativo é importante nos navegadores de desktop de nossos clientes e em qualquer dispositivo.


O motivo para encontrarmos um conjunto de dispositivos baseados em nuvem para testes foi uma alteração no formato do trabalho do escritório para completamente remoto e distribuído (entre cidades e países). Ou seja, se antes para o teste poderíamos montar diferentes dispositivos em um monte (literalmente) e testar manualmente o próximo assembly em uma tabela ao mesmo tempo, agora ficou impossível fazer isso. Além disso, com o crescimento da funcionalidade, para reduzir o trabalho manual, automatizamos os conjuntos de regressão de testes importantes, o que significa que após a montagem precisamos poder chamar testes na configuração e no dispositivo desejados, e é melhor fazer isso assim que a montagem passar para a preparação.


Nesse caso, a solução mais simples e óbvia é usar emuladores para Android e simuladores para dispositivos iOS em nosso pipeline de DevOps. No entanto, que é relativamente fácil de implementar no computador de trabalho do desenvolvedor, torna-se uma tarefa difícil e cara de usar na nuvem. Para que o mesmo emulador Android funcione rapidamente, é necessário um servidor x86 com suporte a HAXVM e, para um simulador iOS, apenas um dispositivo MacOS com xcode é necessário. Infelizmente, mesmo tendo resolvido esse problema, a questão permanece com a diferença entre o comportamento do software em emuladores e dispositivos reais. Por exemplo, a cada segundo lançamento, detectamos bugs estranhos em dispositivos Samsung que não podem ser reproduzidos em emuladores. Bem, e, é claro, raro "chinês" exótico "deleite-se" com bugs únicos e que eu também gostaria de pegar no estágio de desenvolvimento.


Como resultado, entendemos a necessidade de usar um farm de dispositivos móveis na nuvem, no qual poderíamos executar rapidamente nossos testes e, se necessário, depurar manualmente. E ao qual toda a nossa equipe teria acesso de qualquer lugar do mundo (adoramos trabalhar mesmo quando viajamos).



Nossos testes são escritos em Python 3.7 (isso será importante mais tarde), como a pilha que usamos tox + pytest + Selenium + Appium, bem, um pequeno conjunto de bibliotecas python úteis. Definitivamente, testaremos máquinas no Windows e MacOS com os navegadores Edge, Firefox, Chrome, Safari e dispositivos Android e iOS com navegadores e um aplicativo. Não temos muitos testes para cada dispositivo (menos de mil), mas ao testar em um único encadeamento nos dispositivos, um conjunto completo leva algumas horas. Portanto, o critério para escolher um serviço para nós será:


  • Teste de API (Selenium / Appium)
  • IOS, dispositivos Android
  • Suporte ao teste de navegador móvel
  • Suporte para download e teste de aplicativos
  • Dispositivo de referência (GooglePixel (Android 9) e iPhone X (iOS 12+))
  • Depuração manual
  • Registro (mais capturas de tela, gravação de uma execução de vídeo)
  • Disponibilidade e parque de dispositivos
  • Prazo médio de execução do teste
  • Preço

Desejável, mas não necessário:


  • Suporte a python no nível de serviço (o que isso significa)
  • Suporte para dispositivos de mesa \ navegadores

Resultados de pesquisa de mercado


Durante uma semana, naveguei na Internet e tentei uma dúzia de serviços diferentes. A maioria deles oferece tempo livre para oportunidades de teste. Os resultados da minha pesquisa, mais conclusões são subjetivas. Sua opinião e resultados podem diferir dos meus.


Em Habré, encontrei um artigo para 2017 dedicado ao mesmo tópico, mas desde então surgiram novos serviços, e nossa tarefa é um pouco mais rigorosa. Por exemplo, serviços “saborosos” como o Samsung Remote Test Lab, o Firebase Test Lab, o Xamarin Test Cloud, infelizmente, não nos agradam.


Fora do jogo


Laboratório de teste remoto da Samsung



Link


O serviço oferece gratuitamente uma oportunidade de tentar trabalhar com vários dispositivos Samsung, incluindo os mais novos, incluindo TVs ou relógios inteligentes no Tizen (a limitação é no máximo 10 horas por dia, por dia, o serviço concede 10 créditos de graça, o que equivale a 2,5 horas por dia , a sessão mínima é de meia hora (2 créditos)). Isso é muito bom para depurar e encontrar as causas principais dos erros em determinados dispositivos, o serviço ainda fornece acesso à depuração remota (ponte de depuração remota, acesso ao console e aos logs do sistema), mas, infelizmente, o serviço não fornece acesso de API aos dispositivos. A única maneira de "automatizar" é registrar as ações do usuário e reproduzi-las na sua ferramenta de automação local.


Laboratório de teste do Firebase



Link


Um serviço do Google permite que você teste seu aplicativo em dispositivos com Android e iOS de graça (não muito). Mas há uma ressalva - o serviço requer o uso de ferramentas de automação nativas (UIAtomator2 e Espresso para Android e XCTest para iOS) ou usando aranhas automáticas (rastreador) para Android - Robo Test e Game Loop Test. Ou seja, usar UIAutomator e Selenium, infelizmente, não funcionará. Quanto grátis - o pacote gratuito é limitado a 10 testes em emuladores e cinco em dispositivos reais por dia. Se precisar de mais, a cada hora adicional você terá que pagar outros US $ 1 e US $ 5, respectivamente. Em geral, para nossas tarefas, seria uma boa opção se escrevêssemos testes do zero, mas não tenho vontade de refazer várias centenas de testes - é simplesmente caro. E acontece que teríamos que divergir bastante nos testes entre as versões desktop e móvel, o que complicaria bastante o suporte.


Visual studio app center



Link


Antiga nuvem de teste do Xamarin. Este serviço finalmente suporta o Appium e permite testes em milhares de dispositivos diferentes. Mas, como no caso de outros produtos da Microsoft, ele está firmemente pregado na pilha nativa, o que significa que, para usar esse serviço, você precisará da presença do VisualStudio e do requisito para escrever o projeto e testar exclusivamente em Java. Mas se de repente você tiver uma pilha Java (com o MS VS), o preço é de US $ 99 por slot de dispositivo por mês, o que é relativamente liberal.


Serviços para escolher


AWS Device Farm



Link


Talvez o farm mais poderoso para teste em dispositivos virtuais e reais atualmente (mais de 2500 dispositivos). Para nós, esse era um serviço prioritário, pois nossos serviços são implantados apenas na nuvem da AWS, além disso, os preços por minuto do dispositivo a partir de 17 centavos. A AWS permite que você trabalhe com estruturas nativas, bem como com Appium, Calabash e outras estruturas de teste automatizadas. Além do teste automatizado, o serviço oferece a capacidade de depurar manualmente. Bem, 1000 minutos "para tentar" é muito tentador. No entanto, o diabo, como sempre, está nos detalhes. Em termos de teste, a AWS possui vários recursos.


Como já mencionei, usamos o Python 3.7, no entanto, o AWS Device Farm ainda funciona com o Python 2.7.6 (consulte o manual aqui ). E fora da caixa não sabe nada sobre tox. Para nós, isso significa a ausência de vários recursos e a necessidade de processar parte dos testes para garantir compatibilidade com versões anteriores e criar um ambiente que contorneia o tox. Além disso, um mecanismo bastante estranho para baixar um pacote de teste (arquivo morto) também implica baixar o aplicativo para teste. No nosso caso, se testarmos nosso serviço através de um navegador móvel, o download do aplicativo é uma etapa extra. No entanto, você pode substituir o aplicativo por um "stub" e criar um venv com Python 3.7 no ambiente Python 2.7 e, em seguida, criar um ambiente com tox nele, o que ...



A Amazon não seria a Amazon se tudo dependesse de versões antigas. Como alternativa (e nenhum serviço terá essa oportunidade abaixo), a AWS sugere o uso do AWS Device Farm por meio da CLI da AWS (interface da linha de comando) (consulte o manual aqui ). Ou seja, podemos conectar o dispositivo da nuvem como um dispositivo real ao nosso computador no modo de depuração remota, no entanto, substituímos anteriormente o adb pelo corrigido (não há binário para linux na lista de binários, mas tenho certeza que ele existe na natureza). Ou seja, configurando a CLI da AWS, para testar, precisaremos executar apenas alguns comandos (porque não usaremos a GUI como um aplicativo AWS Device Farm).



Exemplo de código
import boto3 #  AWS SDK https://pypi.org/project/boto3/ aws_client = boto3.client('devicefarm') response = aws_client.list_devices() #     device_arn = '' for phone in response["devices"]: if phone['name'] == "Google Pixel XL": #      (  ) device_arn = phone['arn'] #   Amazon Resource Name break project_arn = aws_client.list_projects()['projects'][0]['arn'] #        #      ,    SSH    response = aws_client.create_remote_access_session(projectArn=project_arn, deviceArn=device_arn, remoteDebugEnabled=True, ssh-public-key=SSH_KEY) #     adb devices     uuid Google Pixel XL  AWS Device Farm,   iOS #     ... RUN_TESTS() ... #    ( )    aws_client.stop-remote-access-session(arn=response['remoteAccessSession']['arn']) aws_client.delete_remote_access_session(arn=response['remoteAccessSession']['arn']) 

Se quisermos testar o aplicativo, ele também pode ser baixado pelo AWS SDK.


Mas não contei uma nuance chave aqui. Tropeçamos no diabo novamente em detalhes. O fato é que a opção de depuração remota estará disponível apenas se usarmos o plano de dispositivos privados para a AWS. Em primeiro lugar, esse recurso está disponível somente mediante solicitação (você precisa escrever uma carta para a Amazon); em segundo lugar, a opção está disponível para a região us-west-2; em terceiro lugar, de fato, essa opção retorna ao cenário em que temos um servidor para teste com um conjunto (ou pelo menos um) de dispositivos conectados a ele. As vantagens são óbvias - podemos usar este dispositivo exclusivamente, o que é obviamente mais seguro e mais rápido; por outro lado, perdemos a principal vantagem - a escolha e a variedade de dispositivos.


Gostei do serviço como um todo, mas para a nossa equipe, infelizmente, existem muitos "buts" nele.


Bitbar



Link


Esse farm móvel baseado em nuvem é o primeiro a cair nos mecanismos de pesquisa. E não em vão. No futuro, direi que este serviço tem a melhor escolha de dispositivos (apenas dispositivos reais) e o melhor desempenho em termos de um teste em comparação com outros. O Bitbar oferece serviços para testes manuais e automatizados remotos (usando Appium e outras estruturas), e também, se desejado, permite que você use algo semelhante ao rastreador do Firebase Test Lab (Teste do robô) - AI TestBot. A principal vantagem do BitBar é um número ilimitado de threads de teste (ou seja, você pode testar imediatamente seu aplicativo em centenas de dispositivos) selecionando antecipadamente o pool de dispositivos necessário. Se o dispositivo estiver ocupado, outro será selecionado da mesma forma ou a sessão será colocada na fila. No final da execução do teste, um log é gerado, um registro de teste, os resultados são salvos e a notificação é enviada para o correio. Embora existam oportunidades para configurar a interação com diferentes ferramentas de CI / CD. O serviço também oferece a capacidade de testar os navegadores da área de trabalho em diferentes resoluções e, se desejado, criar, como na AWS, seus dispositivos privados. É verdade que você precisa pagar por todos esses chips - cada minuto de teste custará US $ 0,29.



O processo de configuração é simples, como a interação de dois dedos com o asfalto:


Exemplo de código
 from appium import webdriver """ ... """ com_executor = 'https://appium.bitbar.com/wd/hub' desired_capabilities = { 'deviceName': 'Motorola Google Nexus 6', 'deviceId': 'FA7AN1A00253', 'newCommandTimeout': 12000, 'browserName': 'Chrome', #     Chrome,    app 'bitbar_apiKey': 'BITBAR_API_KEY', 'bitbar_project': 'Software Testing', 'bitbar_testrun': 'Test run #N', 'bitbar_device': 'Motorola Google Nexus 6', 'bitbar_app': '23425235' } driver = webdriver.Remote(com_executor, desired_capabilities) """ ... """ 

Kobiton



Link


Outro serviço que fornece serviços de teste em dispositivos reais. A escolha de dispositivos é mais modesta que o Bitbar (350+), a disponibilidade de dispositivos também é menor. Em geral, é muito semelhante em sua funcionalidade básica ao BitBar, pois permite testes manuais e automáticos (usando Appium - aqui sem escolher estruturas). Não há como testar em navegadores de desktop. O serviço também permite organizar testes com um número ilimitado de sessões e dispositivos, mas você não pode criar um pool de dispositivos aqui. O preço do serviço é muito liberal - de US $ 0,10 por minuto adicional de teste, mas durante o período de teste notei alguma instabilidade do serviço - a Internet geralmente caiu nos dispositivos, uma vez que o dispositivo travou. Além disso, se o dispositivo estiver ocupado ou reservado, todos os seus testes em execução falharão. Ou seja, ao contrário do Bitbar, não há filas de sessões. É verdade que pode ser organizado a baixo custo. Kobiton tem sua própria API pequena.



A configuração também é muito simples, ao contrário do bitbar, quase o Appium original.


Exemplo de código
 import base64 from time import sleep from appium import webdriver import requests """ ... """ #  base64EncodedBasicAuth = base64.b64encode(bytes(f'{USERNAME}:{API_KEY}', 'utf-8')) headers = { 'Authorization': f'Basic {base64EncodedBasicAuth}' } reply = requests.get(f'https://api.kobiton.com/v1/apps', params={ }, headers = headers) #     deviceId headers = { 'Authorization': base64EncodedBasicAuth, 'Accept': 'application/json' } reply = requests.get(f'https://api.kobiton.com/v1/devices/{deviceId}/status', params={ }, headers = headers) #   ,      while (reply['isOnline'] == False or reply['isBooked'] == True): sleep(60) #   com_executor = f'https://{USERNAME}:{API_KEY}@api.kobiton.com/wd/hub' desired_capabilities = { 'browserName': 'Chrome', # The generated session will be visible to you only. 'sessionName': 'Automation test session', 'sessionDescription': '', 'deviceOrientation': 'portrait', 'captureScreenshots': True, 'deviceGroup': 'KOBITON', # For deviceName, platformVersion Kobiton supports wildcard # character *, with 3 formats: *text, text* and *text* # If there is no *, Kobiton will match the exact text provided 'deviceName': 'Pixel 2', 'platformName': 'Android', 'platformVersion': '9' } driver = webdriver.Remote(com_executor, desired_capabilities) """ ... """ #   RUN_TESTS() """ ... """ #       ,     (   ) headers = { 'Authorization': {base64EncodedBasicAuth} } requests.delete(f'https://api.kobiton.com/v1/sessions/{sessionId}/terminate', params={ }) """ ... """ 

Navegação



Link


Bom e velho BrowserStack. Muitas coisas foram escritas sobre ele e muitos que a usam. Sim, permite testar não apenas em navegadores diferentes, mas também em dispositivos diferentes. Tanto no modo manual quanto no Selenium / Appium. Dependendo das suas necessidades - em navegadores móveis ou no aplicativo. Em termos de recursos, tudo é igual aos dois serviços no topo, mas, diferentemente deles, já existem restrições no número de sessões simultâneas. É verdade que, pelo contrário, pague US $ 199 por mês e teste por tempo ilimitado. Existem plugins para Jenkins, Travis CI, TeamCity, sua rica API, excelentes logs e uma grande variedade de dispositivos e navegadores de desktop em diferentes configurações. É verdade que, dependendo do que você está testando, as configurações variam - para testar navegadores (mesmo os móveis), um hub Selenium é usado e, para aplicativos - um hub Appium. Além disso, para testar o aplicativo, você terá que pagar separadamente. Ou seja, para testar navegadores e aplicativos móveis, você precisa pagar US $ 199 e outros US $ 159 (o preço de um dispositivo para teste ao mesmo tempo).



Código de exemplo para aplicação
 from appium import webdriver """ ... """ com_executor = 'https://USERNAME:API_KEY@hub-cloud.browserstack.com/wd/hub' desired_capabilities = {'device': 'Google Pixel', 'deviceName': 'Google Pixel', 'app': app_name, 'realMobile': 'true', 'os_version': '8.0', 'name': 'Bstack-[Python] Sample Test' } driver = webdriver.Remote(com_executor, desired_capabilities) """ ... """ 

Código de amostra para um navegador móvel
 from selenium import webdriver """ ... """ com_executor = 'http://USERNAME:API_KEY@hub.browserstack.com:80/wd/hub' desired_capabilities = {'device': 'Google Pixel', 'deviceName': 'Google Pixel', 'browserName': 'Chrome', 'realMobile': 'true', 'os_version': '8.0', 'name': 'Bstack-[Python] Sample Test' } driver = webdriver.Remote(com_executor, desired_capabilities) """ ... """ 

Experimental



Link


Outro serviço que oferece a capacidade de testar manual e automaticamente dispositivos móveis e navegadores de desktop usando Appium, Selenium e outras estruturas. Como no caso do BrowserStack, o número de sessões simultâneas é limitado, mas os preços são um pouco diferentes - para testar aplicativos móveis, o serviço pede US $ 199 por mês e para testes em vários navegadores apenas US $ 39 (para uma sessão simultânea). Além disso, como o Bitbar na AWS, você pode criar seu próprio laboratório privado com dispositivos que, no entanto, podem ser misturados a uma nuvem pública de milhares de dispositivos, emuladores e navegadores de diferentes versões e plataformas (MacOS, Windows), se desejar. Entre os recursos interessantes - a disponibilidade de extensões para IntelliJ e Eclipse, sua própria ferramenta Appium Studio, que permite usar a funcionalidade avançada de dispositivos como interagir com FaceID, controle de voz, leitura de código de barras, definir qualidade de comunicação, localização geográfica e muito mais. Das desvantagens, posso citar um conjunto estranho de dispositivos para o período de teste, tarifa draconiana para o período de teste e o requisito de usar o correio corporativo (o gmail não funcionará).



Exemplo de código
 from appium import webdriver """ ... """ com_executor = 'https://Uhttps://cloud.seetest.io/wd/hub' desired_capabilities = {"deviceName": "iPhone X", "accessKey": API_KEY, "platformName": "ios", "deviceQuery": "'@os='ios' and @version='12.1.3' and @category='PHONE'", } driver = webdriver.Remote(com_executor, desired_capabilities) """ ... """ 

Saucelabs



Link


Um dos serviços de teste em nuvem mais antigos. Quase 400 dispositivos reais diferentes, uma ampla seleção de simuladores e emuladores, incluindo emuladores atípicos de dispositivos Samsung, existem navegadores de desktop para vários sistemas operacionais, incluindo Linux. Automação em Appium / Selenium e frameworks nativos. A principal vantagem do serviço é a presença de uma extensa coleção de configurações, incluindo sistemas operacionais antigos, navegadores e dispositivos. O SauceLabs também tem um limite no número de sessões simultâneas, mas aqui a opção mais barata inclui não uma, mas duas sessões simultâneas. O que é incomum: os planos de tarifas em dispositivos reais e emuladores são diferentes. Portanto, as opções mais baratas, que incluem duas sessões com 2000 minutos de teste por mês em emuladores, custarão US $ 149 e, em dispositivos reais, já com US $ 349. Existe integração com o CI / CD, Slack. Infelizmente, não pude experimentar o SauceLabs ao vivo, porque, infelizmente, o registro falha, possivelmente devido à região, mas não tenho certeza.


Perfecto



Link


O mais recente provedor de testes na nuvem é mais semelhante visualmente ao Experitest, mas sem funcionalidade avançada. Existe uma linguagem de script simples. É muito estranho, mas no serviço para tarifas não corporativas (corporativas) não há proposta para teste em navegadores de desktop, também é impossível monitorar a execução de testes em tempo real (apenas se não for manual). Cerca de cem dispositivos diferentes estão disponíveis para teste. Há integração com o Jenkins e, curiosamente, com ferramentas de gerenciamento de teste como HP ALM, IBM Rational, TFS. Planos tarifários muito estranhos também estão disponíveis, como 5 horas de teste por mês (em minutos, até US $ 0,33 (este é o serviço mais caro)), embora com a capacidade de comprar um pacote com horas adicionais, mas, novamente, é estranho que não haja por minuto ou pelo menos por hora, após o fato. Quanto à facilidade de uso, durante o período de teste, apenas testes manuais estão disponíveis, além de um laboratório comum, para que todos os lançamentos de diferentes usuários caiam em uma pilha. Portanto, é impossível julgar exatamente a conveniência e a velocidade do serviço. Percebe-se que o serviço está focado principalmente em grandes clientes corporativos, enquanto, pelo menos de acordo com as informações disponíveis, os recursos desse provedor são os mais modestos de todos os que testei.




Resumo Resultados


Por todos os critérios de seleção, os serviços são muito semelhantes, a diferença entre os serviços em seu desempenho e preço (se não houver recursos, por exemplo, como no caso da AWS). Portanto, resumiremos os dados da pesquisa em uma tabela, veremos a velocidade dos serviços (levando em consideração a conexão via VPN dos EUA), bem como o preço, por conveniência, comparando o tempo médio mensal de testes em dispositivos (5 lançamentos por mês, 2 horas de testes em dispositivos Android e iOS) = 20 horas). Como valores de referência, uso dados do meu computador local com um emulador, conectando-o novamente para a pureza do experimento por meio de uma VPN nos EUA).



Conclusões


Foi muito interessante para mim pesquisar e escolher o serviço certo para nossa equipe. Em geral, existem soluções para todos os gostos e tarefas, e os serviços acabaram sendo muito semelhantes em termos de características e implementação. Como resultado, dependendo das suas tarefas, eu recomendaria a seguinte opção:


Opção A : Se a velocidade da verificação é importante para você e você precisa verificar dezenas de dispositivos diferentes ao mesmo tempo, sua escolha é Bitbar .


Opção B : Se você tem prioridade nos resultados dos dispositivos de referência e o teste de configuração é secundário (mas necessário) - sua escolha é BrowserStack . Este é apenas o nosso caso, uma vez que estatisticamente - 90% de todos os erros são erros de plataformas e dispositivos de referência (na maioria das vezes, os bugs são comuns a todas as plataformas de referência ao mesmo tempo). Os 8% restantes são erros do MS IE, com a recusa de suporte do IE - 2% de erros do MS Edge e 0,5% de erros em configurações específicas.


Opção B : Se você estiver interessado em verificar condições especiais, como comunicações de baixa qualidade, geolocalização ou Touch / FaceID, sua escolha é Experitest .


Mas, a longo prazo, se sua empresa ocupa um escritório grande, seu trabalho é em período integral; em geral, organizando seus próprios laboratórios, mesmo minitabelos com um servidor para emuladores com 2-3 dispositivos conectados, custará menos e mais conveniente do que usar serviços especializados. serviços.

Source: https://habr.com/ru/post/pt464433/


All Articles