Hoje, quando todo morador de uma megalópole tem um computador no bolso que pode fazer muito mais do que voar para a lua , usamos aplicativos móveis todos os dias. Notícias, previsão do tempo, promoções, compras - todas essas funções são implementadas em centenas de milhares de aplicativos. Mas se o seu aplicativo favorito congelar ou travar, ele rapidamente deixará de ser o seu favorito.
Este artigo foi escrito pelos caras do
WaveAccess.Desenvolvemos aplicativos móveis há mais de 10 anos e não podemos dar ao luxo de lançar um produto que esteja nas mãos dos usuários. É por isso que “bombear” a equipe e a infraestrutura de teste não é menos importante para nós do que outras áreas.
Centenas de dispositivos Android, iPhones com diferentes versões do sistema operacional e uma diagonal diferente de dispositivos colocam os engenheiros de controle de qualidade a tarefa de "detectar" defeitos em dispositivos móveis reais e em diferentes versões de sistemas operacionais. Mas poucos conseguem lidar com o mesmo script manual em 10, 20, 50 dispositivos. Graças a essas tarefas, desenvolvemos nossa habilidade de teste automático, especialmente em dispositivos móveis. Mas sejamos honestos: criar e manter a infraestrutura, mesmo com 20 dispositivos reais para executar autotestes, é uma dor de cabeça.
Neste artigo, queremos contar como tentamos o novo serviço Microsoft App Center para verificar a qualidade do aplicativo que estamos desenvolvendo no zoológico de dispositivos reais.
Por que surgiu a questão de usar o serviço
Agora estamos desenvolvendo um aplicativo para dar suporte às compras. O projeto está em andamento há muito tempo: o cliente oferece constantemente novos recursos, ele está apenas desenvolvendo para o desenvolvimento. Já existem dezenas de telas no aplicativo, de "comprar" a várias opções de mensagem, push, funções "colete seu arco". E, durante todo esse tempo, são realizadas apresentações do projeto aos investidores, lançamentos em novos shopping centers, portanto, quanto maior a velocidade de liberação (sem queda na qualidade do produto) - melhor.
Até agora, realizamos testes automáticos em um número limitado de dispositivos que estavam à nossa disposição (para este projeto - cerca de 30 dispositivos Android e “maçãs”). Agora, o aplicativo está atingindo um novo nível, o público cresceu e a qualidade se tornou ainda mais crítica. Surgiu a pergunta sobre o uso de um serviço de nuvem para executar autotestes em mais dispositivos diferentes.
No processo de lançamentos, eu queria usar todas as práticas de desenvolvimento de software modernas e comprovadas: revisão cruzada, integração contínua, testes funcionais e de unidade automatizados em uma grande lista de dispositivos no iOS + Android, coleção de análises e travamentos.
Aplicamos cada uma dessas práticas anteriormente, individualmente e em combinação. Mas, dada a escala do projeto e o tamanho grande da equipe, eu queria obter uma solução universal. Permita que a ferramenta possa fazer tudo o que precede e, em um só lugar, forneça uma oportunidade para gerenciar o estado de desenvolvimento e entrega de aplicativos móveis para diferentes plataformas e monitorá-lo.
Cada uma das funções da equipe tinha suas próprias condições: os desenvolvedores não desejavam alterar o processo de desenvolvimento já estabelecido (repositório, ferramenta de construção etc.), além de mudar para ferramentas novas e não verificadas no produto. Os engenheiros de teste sonhavam em reduzir a carga de dispositivos de verificação no zoológico, os gerentes e o cliente desejavam uma interface conveniente para monitorar todo o estado com fluxo transparente.
O estudo de análogos é uma etapa bastante importante na escolha de uma ferramenta. Examinamos vários serviços que fornecem esses recursos (para testes do Appium, por exemplo, BrowserStack). No caso do Microsoft App Center, recebemos um período de teste, por isso tivemos a oportunidade de tentar entender o que aconteceria ao projeto se dedicarmos um pouco mais de recursos à qualidade e automatizar todo o processo de lançamento do aplicativo móvel para qualquer plataforma com um serviço. Contamos como foi.
Como configurar o aplicativo para iOS
Portanto, usando o período de avaliação, que não impõe restrições à funcionalidade, criamos nosso aplicativo iOS no Microsoft App Center:
Escolha uma plataforma:
Adicione o SDK do App Center ao projeto:
pod 'AppCenter'
Após instalar as lareiras, abra o arquivo AppDelegate.swift e adicione as seguintes linhas sob seu próprio comando de importação:
import AppCenter import AppCenterAnalytics import AppCenterCrashes
No mesmo arquivo, adicione as seguintes linhas ao método didFinishLaunchingWithOptions:
MSAppCenter.start("{Your App Secret}", withServices:[ MSAnalytics.self, MSCrashes.self ])
Um processo semelhante é para o objetivo C, a versão completa da instrução está aqui .
Buildim!
Vá para a aba Build, selecione nosso serviço svc.
Configure a construção. Não se esqueça de assinar, pois isso nos gera um arquivo de aplicativo no formato de aplicativo que pode ser executado em dispositivos reais:
Feito! Clique no botão Compilar agora e aguarde a compilação.
Uma história semelhante para aplicativos Android, as instruções estão aqui .
Lançamos os primeiros testes para iOS
Testes de unidade e nativos para cada plataforma podem ser incluídos na montagem (há uma marca de seleção). Falamos sobre a funcionalidade do AT em diferentes dispositivos abaixo.
Configure um conjunto de dispositivos iOS, Android, enviando testes para um conjunto
Vá para a guia Teste, conjuntos de dispositivos. Criamos um conjunto de dispositivos nos quais conduziremos nossos testes. Existem mais de 250 dispositivos Android para escolher e mais de 200 dispositivos iOS diferentes (versão de geração + versão do iOS). Uma lista detalhada de dispositivos está aqui .
Aqui, foi um pouco decepcionante que a resposta oficial à pergunta: quanto tempo após o lançamento os novos dispositivos da Apple apareçam, pareça "1-2 meses após a venda".
Preparamos os testes para o lançamento no App Center (um exemplo para o XCUITest) e os enviamos para o lançamento. O App Center tem a capacidade de criar apenas aplicativos, portanto você ainda precisa criar o projeto de teste localmente em sua máquina ou em seu IC.
Shell: # Generate an XCUITest bundle and your iOS application as described above. $ rm -rf DerivedData $ xcrun xcodebuild build-for-testing -derivedDataPath DerivedData -scheme YOUR_APP_SCHEME # Upload your test to App Center $ appcenter test run xcuitest \ --app "<app center username/<app name>" \ --devices DEVICE_SET \ --test-series "master" \ --locale "en_US" \ --build-dir DerivedData/Build/Products/Debug-iphoneos
Testes de Appium
Vale a pena garantir que as estruturas de teste usadas sejam consistentes com as suportadas. Além disso, você deve usar o driver fornecido pelo App Center, e isso impõe suas limitações ao uso de estruturas (por exemplo, o Google Giuce não pode ser usado).
Compilação do projeto para usuários do Maven
Etapa 1. Adicione um repositório e dependências
Você precisará adicionar o repositório do JCenter ao arquivo pom.xml.
XML <repositories> <repository> <id>jcenter</id> <url>https://jcenter.bintray.com/</url> </repository> </repositories>
Em seguida, adicione uma dependência para extensões de testes do Appium
XML <dependency> <groupId>com.microsoft.appcenter</groupId> <artifactId>appium-test-extension</artifactId> <version>1.3</version> </dependency>
Assim, durante a compilação, os drivers estendidos para Android e iOS estarão disponíveis (necessários antes de tudo para implementar o recurso "label"; mais sobre isso na Etapa 4).
Etapa 2. Adicione um perfil de inicialização
Copie o trecho no seu pom.xml em <profiles>. Se a seção <profiles> estiver ausente no arquivo pom, você precisará criá-lo. Após a ativação, o perfil agrupa nossas classes de teste e todas as dependências na pasta de destino / upload, pronta para upload no TestCloud.
Construir para usuários Gradle
Etapa 1. Repositório e dependências
Garantimos que no build.gradle na pasta raiz do projeto, o repositório do JCenter esteja ativado:
gradle allprojects { repositories { jcenter() } }
Adicione o seguinte trecho para build.gradle na pasta do aplicativo:
gradle androidTestCompile('com.microsoft.appcenter:appium-test-extension:1.0')
A partir do Gradle 3.0, o androidTestCompile foi descontinuado . Em vez disso, você precisa do androidTestImplementation.
Etapa 2. Automatize a geração do arquivo pom
Para o uploader funcionar, é necessário o arquivo pom.xml. Adicione o seguinte fragmento em build.gradle na pasta do aplicativo para que o arquivo pom seja coletado automaticamente:
gradle apply plugin: 'maven' task createPom { pom { withXml { def dependenciesNode = asNode().appendNode('dependencies') //Iterate over the compile dependencies (we don't want the test ones), adding a <dependency> node for each configurations.testCompile.allDependencies.each { def dependencyNode = dependenciesNode.appendNode('dependency') dependencyNode.appendNode('groupId', it.group) dependencyNode.appendNode('artifactId', it.name) dependencyNode.appendNode('version', it.version) } def profilesNode = asNode().appendNode('profiles') profilesNode.append(new XmlParser().parse('https://raw.githubusercontent.com/Microsoft/AppCenter-Test-Appium-Java-Extensions/master/gradleuploadprofilesnippet.xml')) } }.writeTo("pom.xml")
Alterações de teste
Etapa 1. Adicionar importações
Importe pacotes para suas classes de teste:
Java import com.microsoft.appcenter.appium.Factory; import com.microsoft.appcenter.appium.EnhancedAndroidDriver; import org.junit.rules.TestWatcher; import org.junit.Rule;
Etapa 2. Crie uma instância do TestWatcher
Adicione a cada classe de teste da regra JUnit (ou a classe de teste base):
Java @Rule public TestWatcher watcher = Factory.createWatcher();
Etapa 3. Altere o tipo de driver
Altere o tipo de driver quando declarado, de AndroidDriver <MobileElement> para EnhancedAndroidDriver <MobileElement> ou de IOSDriver <MobileElement> para EnhancedIOSDriver <MobileElement>
Java private static EnhancedAndroidDriver<MobileElement> driver;
Etapa 4. Atualizando Instâncias do Driver
Alteramos as instâncias do driver para que as linhas do formulário:
Java driver = new AndroidDriver<MobileElement>(url, capabilities);
... mudou de aparência:
Java driver = Factory.createAndroidDriver(url, capabilities);
O uso desses drivers ainda permitirá que você execute testes localmente sem modificações adicionais, mas também permitirá que você adicione um "rótulo" às etapas de um teste executável usando driver.label ("seu texto"). O texto e a captura de tela do dispositivo estarão disponíveis no relatório de teste na nuvem de testes. É altamente recomendável que você acesse o rótulo por meio do método After , pois isso adicionará uma captura de tela do último estado do aplicativo ao relatório de teste.
Uma captura de tela será feita mesmo se o teste falhar. Como regra, há informações suficientes para entender por que isso aconteceu. Um exemplo de implementação no método After :
Java: @After public void TearDown(){ driver.label("Stopping App"); driver.quit(); }
Download para o teste do App Center
O processo de carregamento é o seguinte:
- Gere o comando de upload do App Center Test. Documentação (EN) - iniciando uma execução de teste .
- Empacotamos classes de teste e todas as dependências na pasta de destino / upload
shell:
- mvn -DskipTests -P pacote de preparação para upload
- Download e execução de testes iniciados
Após a conclusão, podemos visualizar os resultados em cada dispositivo da lista:
Telas com resultados, logs, relatório
Em cada um dos dispositivos iOS ou Android, você pode visualizar um log detalhado e uma captura de tela para diagnosticar uma falha de teste:
Bem como estatísticas de todos os lançamentos ao longo de um intervalo de tempo:
É verdade que o acesso ao "dispositivo" para depuração e inspeção não é fornecido. Se algo der errado com os testes e os logs não forem suficientes - tudo será decidido apenas através do suporte. Em um dos serviços populares para iniciar o AT em dispositivos - o BrowserStack - existe essa oportunidade, e ele é incorporado ao Appium. Pode-se fornecer a URL e a porta para criar uma conexão com o servidor do dispositivo.
Conclusões
Surpreendentemente, todo o processo de lançamento, desde a Integração Contínua até a Entrega Contínua do aplicativo, é fornecido em um só lugar: o Microsoft App Center oferece criação, teste, implantação de CI, armazenamento, análise e crashlytics.
Tendo tentado menos da metade da funcionalidade proposta, a equipe causou uma boa impressão. Das vantagens óbvias: você não precisa escrever suporte para cada dispositivo na forma de código. Bem, outras guloseimas, por favor:
- Não há necessidade de aumentar o servidor para uma multidão de dispositivos.
- Não é necessário conectar 100500 dispositivos a este servidor.
- Não há necessidade de conviver com falhas do Android quando ativado 24 \ 7.
- Não é necessário montar um contêiner para o dispositivo, não é necessário gerenciar esses contêineres.
- Não há necessidade de suportar emuladores limitados.
O Microsoft App Center nos organizou de acordo com os parâmetros iniciais: não é muito exigente em termos de integração, mas fornece todas as funções solicitadas, eliminando o suporte difícil. Planejamos usar o serviço no projeto, pois ele resolve as tarefas das ferramentas e garante a qualidade.