Muitos desenvolvedores de testes de interface do usuário do iOS provavelmente estão familiarizados com o problema do tempo de execução do teste. O Badoo executa mais de 1.400 testes de ponta a ponta para aplicativos iOS para cada execução de regressão. São mais de 40 horas de máquina com testes que passam em 30 minutos reais.
Nikolai Abalov, do Badoo, compartilhou como ele conseguiu acelerar a execução do teste de 1,5 horas para 30 minutos; como eles desvendam os testes intimamente relacionados e a infraestrutura do iOS acessando o servidor do dispositivo; como facilitou a execução de testes em paralelo e facilitou o suporte e a escala de testes e infraestrutura.
Você aprenderá como é fácil executar testes em paralelo com ferramentas como fbsimctl e como a separação de testes e infraestrutura pode facilitar a hospedagem, o suporte e a escalabilidade de seus testes.
Inicialmente, Nikolai apresentou um relatório na conferência Heisenbug (você pode assistir ao
vídeo ), e agora para Habr fizemos uma versão em texto do relatório. A seguir, uma narrativa em primeira pessoa:
Olá pessoal, hoje vou falar sobre o teste de dimensionamento para iOS. Meu nome é Nicholas, lido principalmente com a infraestrutura iOS no Badoo. Antes disso, ele trabalhou na 2GIS por três anos, estava envolvido em desenvolvimento e automação, em particular, ele escreveu o Winium.Mobile - uma implementação do WebDriver para Windows Phone. Fui levado ao Badoo para trabalhar na automação do Windows Phone, mas depois de um tempo a empresa decidiu suspender o desenvolvimento dessa plataforma. E me ofereceram tarefas interessantes para a automação do iOS, sobre isso vou contar hoje.
Sobre o que vamos falar? O plano é o seguinte:
- Uma declaração informal do problema, uma introdução às ferramentas utilizadas: como e por quê.
- Testes paralelos no iOS e como ele se desenvolveu (em particular, de acordo com a história da nossa empresa, desde que começamos a trabalhar nele em 2015).
- Servidor de dispositivo é a parte principal do relatório. Nosso novo modelo para testes paralelos.
- Os resultados que alcançamos com o servidor.
- Se você não tiver 1500 testes, talvez não precise realmente de um servidor de dispositivo, mas ainda assim poderá obter coisas interessantes, e falaremos sobre eles. Eles podem ser aplicados se você tiver 10 a 25 testes, e isso ainda dará aceleração ou estabilidade adicional.
- E, finalmente, um interrogatório.
As ferramentas
O primeiro é um pouco sobre quem usa o quê. Nossa pilha é um pouco fora do padrão, porque usamos o Calabash e o WebDriverAgent (o que nos dá velocidade e backdoors do Calabash ao automatizar nosso aplicativo e, ao mesmo tempo, acesso total ao sistema e outros aplicativos pelo WebDriverAgent). O WebDriverAgent é uma implementação do WebDriver para iOS no Facebook usada internamente pelo Appium. E o Calabash é um servidor incorporado para automação. Nós escrevemos os testes eles mesmos de forma legível por humanos usando o Pepino. Ou seja, em nossa empresa pseudo-BDD. E porque usamos Cucumber e Calabash, herdamos Ruby, todo o código está escrito nele. Há muito código e você precisa continuar escrevendo em Ruby. Para executar testes em paralelo, usamos o
parallel_cucumber , uma ferramenta escrita por um dos meus colegas do Badoo.
Vamos começar com o que tínhamos. Quando comecei a preparar o relatório, havia 1200 testes. Quando foram concluídos, eram 1300. Enquanto cheguei aqui, já havia 1400 testes. Estes são testes de ponta a ponta, não de unidade e de integração. Eles compõem 35-40 horas de tempo no computador em um simulador. Eles passaram mais cedo em uma hora e meia. Vou lhe contar como eles começaram a passar em 30 minutos.
Temos um fluxo de trabalho em nossa empresa com filiais, análises e testes em execução nessas filiais. Os desenvolvedores criam aproximadamente 10 solicitações para o repositório principal de nosso aplicativo. Mas também possui componentes que são compartilhados com outros aplicativos; portanto, às vezes há mais de dez. Como resultado, 30 testes são executados por dia, pelo menos. Como os desenvolvedores pressionam, eles percebem que começaram com bugs, recarregam e tudo isso inicia uma regressão completa, simplesmente porque podemos executá-la. Na mesma infraestrutura, lançamos projetos adicionais, como o Liveshot, que captura capturas de tela do aplicativo nos principais scripts do usuário em todos os idiomas, para que os tradutores possam verificar a correção da tradução, se ela se encaixa na tela e assim por diante. Como resultado, cerca de mil e meia horas de tempo da máquina são lançadas no momento.
Primeiro, queremos que os desenvolvedores e testadores confiem na automação e confiem nela para reduzir a regressão manual. Para que isso ocorra, é necessário obter uma operação rápida e, mais importante, estável e confiável a partir da automação. Se os testes passarem em uma hora e meia, o desenvolvedor se cansará de esperar pelos resultados, ele começará a executar outra tarefa, seu foco mudará. E quando alguns testes caírem, ele não ficará muito feliz por ter que voltar, mudar de atenção e reparar alguma coisa. Se os testes não são confiáveis, com o tempo, as pessoas começam a percebê-los apenas como uma barreira. Eles caem constantemente, embora não haja erros no código. Estes são testes escamosos, algum tipo de obstáculo. Por conseguinte, estes dois pontos foram divulgados nestes requisitos:
- Os testes devem levar 30 minutos ou mais rápido.
- Eles devem ser estáveis.
- Eles devem ser escaláveis para que possamos adicionar meia hora para adicionar mais cem testes.
- A infraestrutura deve ser facilmente mantida e desenvolvida.
- Em simuladores e dispositivos físicos, tudo deve começar da mesma maneira.
Realizamos testes principalmente em simuladores, e não em dispositivos físicos, porque é mais rápido, mais estável e mais fácil. Dispositivos físicos são usados apenas para testes que realmente exigem isso. Por exemplo, câmera, notificações push e similares.
Como satisfazer esses requisitos e fazer tudo bem? A resposta é muito simples: removemos dois terços dos testes! Essa solução se encaixa em 30 minutos (porque apenas um terço dos testes permanece), é dimensionada facilmente (mais testes podem ser excluídos) e aumenta a confiabilidade (porque a primeira coisa que removemos são os testes não confiáveis). Isso é tudo para mim. Perguntas?
Mas, falando sério, há alguma verdade em toda piada. Se você tiver muitos testes, precisará analisá-los e entender quais trazem benefícios reais. Como tínhamos uma tarefa diferente, decidimos ver o que pode ser feito.
A primeira abordagem é filtrar os testes com base na cobertura ou nos componentes. Ou seja, selecione os testes apropriados com base nas alterações de arquivo no aplicativo. Não vou falar sobre isso, mas essa é uma das tarefas que estamos resolvendo no momento.
Outra opção é acelerar e estabilizar os próprios testes. Você faz um teste específico, vê quais etapas levam mais tempo e se elas podem ser otimizadas de alguma forma. Se alguns deles são muito instáveis com muita freqüência, você os corrige, porque reduz o reinício do teste e tudo corre mais rápido.
E, finalmente, uma tarefa completamente diferente - paralelizar testes, distribuí-los por um grande número de simuladores e fornecer uma infraestrutura escalável e estável para que haja muito o que paralelizar.
Neste artigo, falaremos principalmente sobre os dois últimos pontos e, no final, em dicas e truques, abordaremos o ponto sobre velocidade e estabilização.
Teste paralelo para iOS
Vamos começar com o histórico de testes paralelos para iOS em geral e Badoo em particular. Para começar, aritmética simples, aqui, no entanto, há um erro na fórmula se compararmos as dimensões:
Foram 1300 testes para um simulador, ou seja, 40 horas. Então Satish, meu líder, vem e diz que precisa de meia hora. Você tem que inventar alguma coisa. X aparece na fórmula: quantos simuladores executar, para que tudo corra em meia hora. A resposta é 80 simuladores. E imediatamente surge a questão, onde colocar esses 80 simuladores, porque eles não cabem em lugar algum.
Há várias opções: você pode ir para nuvens como SauceLabs, Xamarin ou AWS Device Farm. E você pode pensar em tudo em casa e se sair bem. Como esse artigo existe, fizemos tudo bem em casa. Decidimos que sim, porque uma nuvem com essa escala seria muito cara e também houve uma situação em que o iOS 10 foi lançado e o Appium lançou o suporte por quase um mês. Isso significa que no SauceLabs por um mês não pudemos testar automaticamente o iOS 10, o que não nos convinha. Além disso, todas as nuvens estão fechadas e você não pode afetá-las.
Então, decidimos fazer tudo internamente. Começamos em algum lugar em 2015, então o Xcode não conseguiu executar mais de um simulador. Como se viu, ele não pode executar mais de um simulador sob um usuário na mesma máquina. Se você tiver muitos usuários, poderá executar simuladores o quanto quiser. Meu colega Tim Bawerstock apresentou um modelo em que vivíamos o suficiente.
Existe um agente (TeamCity, Jenkins Node e similares), que executa o parallel_cucumber, que simplesmente vai para máquinas remotas via ssh. A imagem mostra dois carros para dois usuários. Todos os arquivos necessários, como testes, são copiados e executados em máquinas remotas via ssh. E os testes já executam o simulador localmente na área de trabalho atual. Para que isso funcionasse, era necessário primeiro ir a cada máquina, criar, por exemplo, 5 usuários, se você quiser 5 simuladores, tornar um usuário um login automático, abrir compartilhamento de tela para o resto, para que eles sempre tenham uma área de trabalho. E configure o daemon ssh para que ele tenha acesso aos processos na área de trabalho. De uma maneira tão simples, começamos a executar testes em paralelo. Mas há vários problemas nesta imagem. Primeiramente, os testes controlam o simulador, eles estão no mesmo local que o próprio simulador. Ou seja, eles sempre devem ser executados em papoulas, eles consomem recursos que poderiam ser gastos na execução de simuladores. Como resultado, você tem menos simuladores na máquina e eles custam mais. Outro ponto é que você precisa ir para cada máquina, configurar usuários. E então você tropeça no ulimit global. Se houver cinco usuários e eles gerarem muitos processos, em algum momento os descritores terminarão no sistema. Tendo atingido o limite, os testes começarão a cair ao tentar abrir novos arquivos e iniciar novos processos.
Em 2016-2017, decidimos mudar para um modelo ligeiramente diferente. Assistimos a um
relatório de Lawrence Lomax do Facebook - eles apresentaram fbsimctl e parcialmente contaram como a infraestrutura funciona no Facebook. Houve também um
relatório de Viktor Koronevich sobre esse modelo. A imagem não é muito diferente da anterior - acabamos de nos livrar dos usuários, mas este é um grande passo em frente, já que agora existe apenas uma área de trabalho, menos processos são iniciados, simuladores ficaram mais baratos. Existem três simuladores nesta imagem, e não dois, pois os recursos foram liberados para lançar um adicional. Vivemos com esse modelo por muito tempo, até meados de outubro de 2017, quando começamos a mudar para o servidor de dispositivos remotos.
Então parecia ferro. À esquerda, há uma caixa com macbooks. Por que executamos todos os testes neles é uma grande história separada. Executar os testes nos macbooks que inserimos na caixa de ferro não era uma boa ideia, porque em algum momento da tarde começaram a superaquecer, pois o calor não sai bem quando está na superfície. Os testes ficaram instáveis, especialmente quando os simuladores começaram a travar ao carregar.
Decidimos simplesmente: colocamos os laptops “em tendas”, a área do fluxo de ar aumentou e a estabilidade da infraestrutura aumentou repentinamente.
Às vezes, você não precisa lidar com software, mas gira em torno de laptops.
Mas se você olhar esta foto, há uma confusão de fios, adaptadores e geralmente estanho. Esta é a parte de ferro, e ainda era boa. No software, estava em andamento um entrelaçamento completo de testes com a infraestrutura, e era impossível continuar vivendo assim.
Identificamos os seguintes problemas:
- O fato de os testes estarem intimamente relacionados à infraestrutura, lançou simuladores e gerenciou todo o seu ciclo de vida.
- Isso dificultou o dimensionamento, porque adicionar um novo nó implicava em configurá-lo para testes e simuladores em execução. Por exemplo, se você queria atualizar o Xcode, precisava adicionar uma solução alternativa diretamente aos testes, porque eles são executados em versões diferentes do Xcode. Alguns se pilhas parecem executar o simulador.
- Os testes estão vinculados à máquina em que o simulador está localizado, e isso custa um centavo, pois eles precisam ser executados em papoulas, em vez de * nix, que são mais baratas.
- E sempre foi muito fácil mergulhar no simulador. Em alguns testes, fomos ao sistema de arquivos do simulador, excluímos alguns arquivos ou os mudamos, e tudo correu bem até que fosse feito de três maneiras diferentes em três testes diferentes e, inesperadamente, o quarto começou a travar se não tivesse sorte de começar depois aqueles três.
- E o último momento - os recursos não foram revistados de forma alguma. Por exemplo, havia quatro agentes do TeamCity, cinco máquinas foram conectadas a cada uma e os testes podiam ser executados apenas em suas cinco máquinas. Não havia um sistema centralizado de gerenciamento de recursos, por isso, quando apenas uma tarefa é executada, ela opera em cinco máquinas e todas as outras 15 ficam ociosas. Por esse motivo, as construções demoraram muito tempo.
Novo modelo
Decidimos mudar para um novo modelo bonito.
Removidos todos os testes em uma máquina, onde o agente TeamCity. Agora, esta máquina pode estar no * nix ou até no Windows, se desejar. Eles se comunicarão via HTTP com algo que chamaremos de servidor do dispositivo. Todos os simuladores e dispositivos físicos estarão localizados em algum lugar lá, e os testes serão executados aqui, solicitarão o dispositivo via HTTP e continuarão a trabalhar com ele. O diagrama é muito simples, existem apenas dois elementos no diagrama.
Na realidade, é claro, ssh e mais permaneceram atrás do servidor. Mas agora isso não incomoda ninguém, porque os caras que escrevem os testes estão no topo deste diagrama e têm algum tipo de interface específica para trabalhar com um simulador local ou remoto, então eles estão bem. E agora eu trabalho abaixo, e tenho tudo como era. Temos que viver com isso.
O que isso dá?
- Primeiro, a divisão de responsabilidade. Em algum momento do teste de automação, você deve considerá-lo como um desenvolvimento normal. Ele emprega os mesmos princípios e abordagens usados pelos desenvolvedores.
- O resultado é uma interface estritamente definida: você não pode fazer algo diretamente com o simulador; para isso, é necessário abrir um ticket no servidor do dispositivo e descobriremos como fazer isso da melhor maneira possível, sem interromper outros testes.
- O ambiente de teste ficou mais barato porque o aumentamos em * nix, que são muito mais baratos que as papoulas de serviço.
- E o compartilhamento de recursos apareceu, porque há uma camada única com a qual todos se comunicam e pode planejar a distribuição de máquinas localizadas atrás dela, ou seja, compartilhando recursos entre agentes.
Acima é retratado, como era antes. À esquerda, existem unidades de tempo convencionais, digamos, dezenas de minutos. Existem dois agentes, 7 simuladores estão conectados a cada um, no momento em que a compilação 0 chega e leva 40 minutos. Após 20 minutos, outro chega e leva o mesmo tempo. Tudo parece ótimo. Mas lá, e há quadrados cinza. Eles significam que perdemos dinheiro porque não usamos os recursos disponíveis.
Você pode fazer isso: a primeira compilação entra e vê todos os simuladores gratuitos, é distribuída e os testes são acelerados duas vezes. Não havia o que fazer. Na realidade, isso geralmente acontece porque os desenvolvedores raramente fazem brunches no mesmo momento. Embora às vezes isso aconteça, "damas", "pirâmides" e outras coisas semelhantes começam. No entanto, na maioria dos casos, a aceleração livre duas vezes pode ser obtida simplesmente instalando um sistema de gerenciamento centralizado para todos os recursos.
Outras razões para seguir adiante:
- Boxe preto, ou seja, agora o servidor do dispositivo é uma caixa preta. Ao escrever testes, você pensa apenas em testes e acha que essa caixa preta sempre funcionará. Se não der certo, basta bater em quem deve fazê-lo, ou seja, eu. E eu tenho que consertar isso. Na verdade, não apenas eu, várias pessoas estão envolvidas em toda a infraestrutura.
- Você não pode estragar o interior do simulador.
- Você não precisa colocar um milhão de utilitários na máquina para que tudo comece - basta colocar um utilitário que oculte todo o trabalho no servidor do dispositivo.
- Tornou-se mais fácil atualizar a infraestrutura, sobre a qual falaremos em algum lugar no final.
Uma pergunta razoável: por que não o Selenium Grid? Primeiro, tínhamos muito código legado, 1.500 testes, 130 mil linhas de código para diferentes plataformas. E tudo isso foi controlado pelo parallel_cucumber, que criou o ciclo de vida do simulador fora do teste. Ou seja, havia um sistema especial que carregava o simulador, esperando que ele estivesse pronto e testando-o. Para não reescrever tudo, decidimos tentar não usar o Selenium Grid.
Também temos muitas ações fora do padrão e raramente usamos o WebDriver. A parte principal dos testes no Calabash e WebDriver é apenas auxiliar. Ou seja, não usamos Selenium na maioria dos casos.
E, é claro, queríamos que tudo fosse flexível, fácil de prototipar. Como todo o projeto começou com uma ideia de que eles decidiram testar, implementado em um mês, tudo começou e se tornou a principal decisão em nossa empresa. A propósito, primeiro escrevemos em Ruby e, em seguida, reescrevemos o servidor do dispositivo no Kotlin. Os testes acabaram sendo no Ruby e no servidor no Kotlin.
Servidor de dispositivos
Agora, mais sobre o servidor do dispositivo, como ele funciona. Quando começamos a pesquisar esse problema, usamos as seguintes ferramentas:
- xcrun simctl e fbsimctl - utilitários de linha de comando para gerenciar simuladores (o primeiro é oficialmente da Apple, o segundo do Facebook, é um pouco mais conveniente de usar)
- WebDriverAgent, também do Facebook, para iniciar aplicativos fora do processo quando chega a notificação por push ou algo assim
- ideviceinstaller, - .
, device server, . , fbsimctl , xcrun simctl ideviceinstaller, , fbsimctl WebDriverAgent. - . : - , Facebook . , fbsimctl . :
, .
, .
? , curl list, :
JSON, , . , .
, approve — , . open deep links . , , fbsimctl. , :
, . - . : . , , .
- — . liveshot' iPhone X, iPhone 5S, iPhone 6s. .
- - WebDriverAgent XCUI- , .
- . - iOS 8 , , . device server iOS 8, , , - . fbsimctl.
- , cookies , , , .
- — . , device server , , , , . , . , .
, - , . — , . — , , , .
: Test Runner, ; Device Provider, Device Server, ; Remote Device — ; Device Server — -. , - - fbsimctl WebDriverAgent.
? Test Runner capability, iPhone 6. Device Provider, device server, , - , , , . Device Server . RemoteDevice .
, fbsimctl. , , headless-. , , headless-. - , . , , , syslog SpringBoard .
, XCTest, WebDriverAgent, healthCheck, WebDriverAgent , . , «ready» . healthCheck. , .
fbsimctl. . , WebDriverAgent, . .
— , device server, , , . (release), , , . . , device server , Test Runner . , -, , - .
— . . 30 60. , . , 30 . : , ?
. — . , .
. , , . Separation of Concerns — , , .
. , , Xcode 9, . Xcode 9.2, , — . , - .
Test Runner, rsync, ssh . - *nix, Docker-.
: device server
( GitHub ) , ssh, . device server, ssh, .
Tips & tricks
Agora, o mais importante são todos os tipos de truques e apenas coisas úteis que encontramos ao criar um servidor de dispositivo e essa infraestrutura.
O primeiro é o mais simples. Como você se lembra, tínhamos um MacBook Pro, todos os testes foram executados em laptops. Agora os lançamos no Mac Pro.
Aqui estão duas configurações. Essas são, na verdade, as principais versões de cada um dos dispositivos. No MacBook, poderíamos executar de forma estável 6 simuladores em paralelo. Se você tentar carregar mais ao mesmo tempo, os simuladores começarão a falhar devido ao fato de que carregam muito o processador, possuem bloqueios mútuos e assim por diante. Você pode executar 18 no Mac Pro - é muito fácil de calcular, porque em vez de 4 existem 12 núcleos. Nós multiplicamos por três - você recebe cerca de 18 simuladores. De fato, você pode tentar correr um pouco mais, mas eles precisam, de alguma forma, ser separados no tempo; você não pode, por exemplo, correr em um minuto. Embora exista um truque com esses 18 simuladores, não é tão simples.
E esse é o preço deles. Não me lembro quanto custa em rublos, mas está claro que eles custam muito. O custo de cada simulador para o MacBook Pro custa quase £ 400, e para o Mac Pro quase £ 330. Isso já representa cerca de £ 70 de economia em cada simulador.
Além disso, esses macbooks tinham que ser instalados de uma certa maneira, eles carregavam ímãs, que tinham que ser colados em fita, porque às vezes caíam. E você teve que comprar um adaptador para conectar a Ethernet, porque muitos dispositivos próximos à caixa de ferro no Wi-Fi na verdade não funcionam, isso se torna instável. O adaptador também custa cerca de £ 30, quando você divide por 6, você recebe outros £ 5 por cada dispositivo. Mas, se você não precisar dessa super-paralelização, terá apenas 20 testes e 5 simuladores, na verdade, é mais fácil comprar um MacBook, porque você pode encontrá-lo em qualquer loja e precisará solicitar e aguardar o Mac Pro de última geração. A propósito, eles nos custaram um pouco mais barato, porque os pegamos a granel e houve algum tipo de desconto. Você também pode comprar um Mac Pro com pouca memória e atualizar-se economizando ainda mais.
Mas com o Mac Pro, há um truque. Tivemos que dividi-los em três máquinas virtuais, colocar o ESXi lá. Isso é virtualização bare metal, ou seja, um hipervisor instalado em uma máquina vazia e não no sistema host. Ele é o próprio host, para que possamos executar três máquinas virtuais. E se você instalar algum tipo de virtualização normal no macOS, por exemplo, o Parallels, poderá executar apenas duas máquinas virtuais devido a restrições de licenciamento da Apple. Tive que interromper porque o CoreSimulator, o principal serviço que gerenciava os simuladores, tinha bloqueios internos e, ao mesmo tempo, mais de 6 simuladores simplesmente não foram carregados, eles começaram a esperar por algo na fila e o tempo total de carregamento de 18 simuladores tornou-se inaceitável. A propósito, o ESXi custa £ 0, é sempre bom quando algo não vale nada, mas funciona bem.
Por que não fizemos pool? Em parte porque aceleramos a redefinição do simulador. Suponha que o teste trava, você deseja limpar completamente o simulador para que o próximo não trate devido aos arquivos obscuros restantes no sistema de arquivos. A solução mais simples é desligar o simulador, apagar explicitamente (apagar) e inicializar (inicialização).
Muito simples, uma linha, mas leva 18 segundos. E seis meses ou um ano atrás, levou quase um minuto. Agradecemos à Apple por otimizar isso, mas você pode fazê-lo mais complicado. Faça o download do simulador e copie seus diretórios de trabalho para a pasta de backup. E então você desliga o simulador, exclui o diretório de trabalho e copia o backup, inicia o simulador.
Acontece 8 segundos: o download acelerou mais de duas vezes. Ao mesmo tempo, nada de complicado precisava ser feito, ou seja, no código Ruby, são necessárias literalmente duas linhas. Na figura, dou um exemplo em uma festança para que possa ser facilmente traduzido para outros idiomas.
O próximo truque. Existe uma aplicação Bumble, é semelhante ao Badoo, mas com um conceito ligeiramente diferente, muito mais interessante. Lá você precisa fazer login via Facebook. Em todos os nossos testes, como usamos um novo usuário do pool a cada vez, tivemos que sair do anterior. Para fazer isso, usando o WebDriverAgent, abrimos o Safari, acessamos o Facebook e clicamos em Sair. Parece ser bom, mas leva quase um minuto em cada teste. Cem testes. Cem minutos extras.
Além disso, o Facebook às vezes gosta de fazer testes A / B, para que eles possam alterar os localizadores, o texto nos botões. De repente, vários testes caem e todos ficam extremamente infelizes. Portanto, através do fbsimctl, criamos list_apps, que localiza todos os aplicativos.
Encontre MobileSafari:
E existe um caminho para o DataContainer e ele possui um arquivo binário com cookies:
Nós apenas o excluímos - leva 20 ms. Os testes começaram a passar 100 minutos mais rápido, tornaram-se mais estáveis, porque não podem cair por causa do Facebook. Portanto, às vezes, a paralelização não é necessária. Você pode encontrar locais para otimização, é fácil menos 100 minutos, nada precisa ser feito. No código, essas são duas linhas.
A seguir: como preparamos máquinas host para executar simuladores.
Com o primeiro exemplo, muitos que lançaram o Appium estão familiarizados com a desativação do teclado. O simulador tem o hábito de conectar o teclado de hardware no computador ao inserir texto no simulador e ocultar completamente o virtual. E o Appium usa um teclado virtual para inserir texto. Portanto, após uma depuração local dos testes de entrada, outros testes podem começar a falhar devido à falta de um teclado. Com este comando, você pode desativar o teclado físico, e fazemos isso antes de levantar cada nó de teste.
O próximo parágrafo é mais relevante para nós, porque o aplicativo está relacionado à geolocalização. E muitas vezes você precisa executar testes para que seja inicialmente desativado. Você pode definir 3101 no LocationMode. Por que? Havia um artigo na documentação da Apple, mas eles o excluíram por algum motivo. Agora, é apenas uma constante mágica no código pelo qual todos oramos e esperamos que não seja quebrado. Porque assim que quebra, todos os usuários estarão em São Francisco, porque o fbsimctl coloca esse local ao carregar. Por outro lado, descobriremos facilmente, porque todos estarão em São Francisco.
O próximo é desativar o Chrome, um quadro ao redor do simulador que possui vários botões. Ao executar autotestes, isso não é necessário. Anteriormente, desativá-lo permitiu colocar mais simuladores da esquerda para a direita para ver como tudo acontece paralelamente. Agora não fazemos isso, porque tudo é decapitado. Quantos não entram no carro, os próprios simuladores não serão visíveis. Se isso for necessário, você poderá transmitir a partir do simulador desejado.
Há também um conjunto de opções diferentes que você pode ativar / desativar. Destas, mencionarei apenas o SlowMotionAnimation, porque tive um segundo ou terceiro dia muito interessante no trabalho. Fiz os testes e todos começaram a cair em intervalos. Eles não encontraram os elementos no inspetor, embora ele estivesse. Aconteceu que naquele momento iniciei o Chrome, pressionei cmd + T para abrir uma nova guia. Nesse ponto, o simulador se tornou ativo e interceptou a equipe. E para ele, cmd + T é uma desaceleração de todas as animações em 10 vezes para depurar a animação. Essa opção também deve sempre ser desativada automaticamente se você deseja executar testes em máquinas às quais as pessoas têm acesso, porque elas podem interromper acidentalmente os testes diminuindo a velocidade das animações.
Provavelmente a coisa mais interessante para mim, desde que fiz isso não faz muito tempo, é o gerenciamento de toda essa infraestrutura. 60 hosts virtuais (na verdade, 64 + 6 agentes TeamCity) que ninguém deseja implementar manualmente. Encontramos o utilitário
xcversion - agora ele faz parte do fastlane, uma jóia do Ruby que pode ser usada como um utilitário de linha de comando: ele automatiza parcialmente a instalação do Xcode. Em seguida, pegamos o Ansible, escrevemos playbooks, para rolar o fbsimctl em toda a versão desejada, o Xcode e implantar configurações para o próprio servidor do dispositivo. E Ansible para remover e atualizar simuladores. Quando mudamos para o iOS 11, deixamos o iOS 10. Mas quando a equipe de teste diz que abandona completamente o teste automático no iOS 10, passamos pelo Ansible e limpamos os simuladores antigos. Caso contrário, eles ocupam muito espaço em disco.
Como isso funciona? Se você pegar o xcversion e o chamar em cada uma das 60 máquinas, levará muito tempo, pois ele acessa o site da Apple e baixa todas as imagens. Para atualizar as máquinas que estão no parque, é necessário selecionar uma máquina em funcionamento, executar a instalação do xcversion nela com a versão necessária do Xcode, mas não instale nada ou exclua nada. O pacote de instalação será baixado no cache. O mesmo pode ser feito para qualquer versão do simulador. O pacote de instalação é colocado em ~ / Library / Caches / XcodeInstall. Em seguida, você carrega tudo com o Ceph e, se não estiver lá, inicie algum tipo de servidor Web nesse diretório. Estou acostumado a Python, então eu executo um servidor Python Python em máquinas.
Agora, em qualquer outra máquina do desenvolvedor ou testador, você pode instalar o xcversion e especificar o link para o servidor levantado. Ele fará o download do xip da máquina especificada (se a rede local for rápida, isso acontecerá quase instantaneamente), descompactar o pacote, confirmar a licença - em geral, fará tudo por você. Haverá um Xcode totalmente funcional no qual será possível executar simuladores e testes. Infelizmente, eles não eram tão convenientes com os simuladores; portanto, você precisa fazer curl ou wget, baixar um pacote desse servidor para sua máquina local no mesmo diretório, executar simuladores xcversion --install. Colocamos essas chamadas em scripts Ansible e atualizamos 60 máquinas por dia. O tempo principal foi gasto pela cópia de arquivos de rede. Além disso, estávamos nos movendo naquele momento, ou seja, alguns carros foram desligados. Reiniciamos o Ansible duas ou três vezes para encontrar carros ausentes durante a mudança.
Um pouco de interrogatório. Na primeira parte: parece-me que as prioridades são importantes. Ou seja, primeiro você deve ter estabilidade e confiabilidade nos testes e depois acelerar. Se você apenas buscar velocidade, começar a paralelizar tudo, os testes funcionarão rapidamente, mas ninguém nunca olhará para eles, eles apenas reiniciarão tudo até que tudo repentinamente passe. Ou até marque nos testes e empurre para o mestre.
O próximo ponto: a automação é o mesmo desenvolvimento, para que você possa pegar os padrões que você já pensou em nós e usá-los. Se agora sua infraestrutura está intimamente conectada aos testes e o dimensionamento é planejado, é um bom momento para dividir primeiro e depois escalar.
E o último ponto: se a tarefa é acelerar os testes, a primeira coisa que vem à mente é adicionar mais simuladores para torná-lo mais rápido por algum fator. De fato, muitas vezes você não precisa adicionar, mas analise cuidadosamente o código e otimize tudo com algumas linhas, como no exemplo com cookies. Isso é melhor que a paralelização, porque 100 minutos foram salvos com duas linhas de código e, para paralelização, você precisará escrever muito código e oferecer suporte à parte essencial da infraestrutura. Por dinheiro e recursos, custará muito mais.
Os interessados neste relatório da conferência Heisenbug também podem estar interessados no seguinte Heisenbug : será realizado em Moscou nos dias 6 e 7 de dezembro e o site da conferência já contém descrições de vários relatórios (e, a propósito, a aceitação de pedidos de relatórios ainda está aberta).