Neste artigo, compararemos os recursos de teste de aplicativos nativos e de plataforma cruzada. Vou compartilhar minhas impressões sobre como trabalhar com o Flutter e dizer quais ferramentas usamos no Surf durante os testes, por que o Flutter é conveniente e quais problemas encontramos.
Os recursos de teste no Flutter estão no mesmo nível dos nativos
Quando uma empresa muda sua abordagem de desenvolvimento ou surge uma nova tecnologia, é importante que os recursos de teste não sejam gravemente afetados. Idealmente, ao trabalhar com uma nova linguagem ou estrutura, os especialistas em QA continuam a usar a pilha familiar de ferramentas e tecnologias que se provaram da melhor maneira.
Ao testar aplicativos nativos, nós da Surf usamos autotest e lemos e substituímos pacotes. Em nenhum lugar sem autotestes, principalmente com regressão, e sem a ajuda de um proxy, a variabilidade da aplicação e a cobertura de muitos casos diminuem.
Era importante para nós que os recursos familiares permanecessem ao testar os aplicativos Flutter.
Auto teste
O Surf funciona com as estruturas Calabash e Ruby para autoteste de aplicativos nativos. Quando o Flutter apareceu, a primeira coisa que nos perguntamos foi: é possível não usar o Calabash, mas ao mesmo tempo trabalhar totalmente com autotestes do jeito que estamos acostumados - ou até mais legal.
Descobriu-se que não só é possível - mas mesmo sem serviços de terceiros: no Flutter, testes de integração e testes de widgets no console estão disponíveis fora da caixa. Nosso desenvolvedor do Flutter contou sobre isso com mais detalhes no artigo sobre autotesting no Flutter .
Os autotestes no Flutter são multiplataforma e nativos ao mesmo tempo: você pode escrever testes dentro do projeto do aplicativo e eles funcionarão em ambas as plataformas. Quando o projeto inteiro está diante de seus olhos, você pode adicionar id-schnicks ausentes ou até mesmo encontrar bugs e corrigi-los - esta é outra oportunidade de melhorar a qualidade do aplicativo.
O Flutter também suporta a abordagem Behavior Driven Development - BDD. Nós o usamos para testes de IU. Escolhemos o Gherkin como idioma: você pode usar arquivos de recursos nele, escrever scripts em inglês e russo. É compreensível, tem a implementação de etapas de script sem argumentos adicionais dentro ou com eles, a capacidade de personalizar o lançamento de autotestes: por exemplo, rodando alguns scripts por tags, e nem todos os testes escritos como um todo.
Para usar o Gherkin ao testar aplicativos Flutter, conectamos a estrutura de código aberto flutter_gherkin .
Quando percebemos que existem autotestes no Flutter, nos perguntamos quais são as diferenças entre as tecnologias Calabash e Dart + Gherkin, qual abordagem é melhor. Vamos compará-los juntos.
1. Os arquivos de recurso são absolutamente idênticos para ambas as abordagens.
Por exemplo, o script para autorização por código PIN será interpretado corretamente no Dart e no Ruby usando Calabash:
: ( )
Ambas as tecnologias suportam russo, inglês e outros idiomas.
2. As etapas são diferentes na implementação.
| Dart + flutter_gherkin
|
Cabaça
|
|
|
3. O Flutter usa um arquivo .dart adicional para configurar e trabalhar com os testes. Com Calabash, tal arquivo único não existe.
Dizer que isso é uma vibração dentro do Flutter ou Calabash, em nossa opinião, é impossível - isso é apenas a especificidade de trabalhar com ferramentas e tecnologias específicas.
4Para a comodidade de trabalhar com elementos na aplicação, é necessário que cada elemento tenha seu próprio id. Ao trabalhar com autotestes com Calabash, é necessário atentar para que ambas as plataformas possuam id nos aplicativos testados. No Dart, você pode adicionar id no processo de escrever autotestes sem recarregar os arquivos de aplicativos iOS e Android separadamente - isso é conveniente e economiza tempo.
Nossa conclusão: os autotestes no Dart não são inferiores aos autotestes usando o framework Calabash.
Proxies
Para aumentar a cobertura do aplicativo por casos, o Surf usa programas para ler e falsificar o tráfego, como Charles. A análise da interação cliente-servidor permite:
- Determine se há interação real com o back-end.
- Descubra de que lado está o problema: no cliente ou no servidor.
- , .
- : , , . Charles , , , .
A Dart tem seu próprio cliente para trabalhar com a rede. Como todas as solicitações passam por ele, as configurações necessárias para trabalhar com um proxy devem ser inseridas dentro do aplicativo. Para comodidade dos testadores, todas as configurações necessárias são colocadas em uma tela separada: em Surf usamos a Tela de Depuração, que desenvolvemos nós mesmos.
A tela de depuração é uma tela de configurações adicionais que está disponível apenas na compilação de depuração e ajuda nos testes. Nele, você pode selecionar o servidor necessário, habilitar o uso de ler e salvar solicitações de http no aplicativo, visualizar o fcm-token do dispositivo e muito mais - há muitas oportunidades de teste.
A tela de depuração é personalizada: os desenvolvedores adicionam elementos adicionais a ela a pedido dos testadores - por exemplo, campos para configurar proxies do aplicativo. Portanto, temos todas as oportunidades de trabalhar com Charles: você pode conectar um servidor proxy à tela de depuração sem reiniciar o aplicativo.
Como você pode ver, as possibilidades de teste de aplicativos Flutter não são limitadas. Tudo o que estamos acostumados a trabalhar quando nativo é conveniente e fácil de usar. Esta é uma boa notícia.
Problemas: bugs de estrutura, falhas em bibliotecas de terceiros, comportamento nativo esperado
Os problemas que enfrentamos ao testar aplicativos Flutter também são nativos. Não se pode dizer que essas são as deficiências específicas do Flutter: em qualquer tecnologia, a resolução de problemas nem sempre é óbvia e simples.
Vamos dizer a você o que procurar ao testar aplicativos Flutter. Prevenido vale por dois.
Erros de estrutura oscilante
Durante o teste, encontramos um problema com a exibição e formatação de fontes no iOS: o espaçamento entre letras na plataforma iOS era visivelmente maior do que no Android. Isso causou muitos bugs visuais.
Descobriu-se que o problema estava no próprio framework. Quando nossos desenvolvedores de aplicativos móveis abordaram os caras da comunidade de desenvolvedores do framework Flutter com uma solicitação para corrigir um bug tão desagradável, o framework foi atualizado em breve e a exibição de texto no iOS foi corrigida.
Certamente tais situações se repetirão. Mas isso não pode ser chamado de um grande problema: os caras da comunidade Flutter respondem rapidamente às questões, apoiam e desenvolvem o framework.
Deficiências em bibliotecas de terceiros
Nas versões 10 e 11 do iOS, foram encontradas falhas de implementação em bibliotecas de terceiros. Por exemplo, estávamos corrigindo um bug quando a permissão para acesso às notificações aparece imediatamente quando o aplicativo é iniciado, e não no botão, conforme planejado pela especificação técnica e design.
Esses problemas podem ser encontrados em plataformas cruzadas e nativas. Eles são resolvidos por correções dentro do projeto ou junto com os desenvolvedores da biblioteca.
Lidando com o comportamento nativo esperado
Com o uso e teste de longo prazo de aplicativos nativos no iOS e Android, é fácil prever as expectativas do usuário a partir de diferentes comportamentos do aplicativo. Portanto, por exemplo, retroceder no iOS é um gesto padrão. E no Android, você não precisa disso.
As caixas de diálogo do sistema em ambas as plataformas são diferentes: no iOS, você precisa solicitar permissão para acessar as notificações e, no Android, esse acesso é concedido por padrão.
São essas partes das especificações do sistema operacional que geralmente precisam ser concluídas manualmente. E às vezes - para cortar, se de repente o comportamento esperado para a plataforma iOS migrou para o Android, como foi com o backwipe.
Em aplicativos nativos, problemas como atualização de tela, minimização incorreta de aplicativos, operação de aplicativo incomum para o sistema operacional atual são raros: ferramentas e tecnologias para desenvolver um aplicativo para uma plataforma específica são deliberadamente destinadas a cobrir todas as versões e recursos de um sistema específico.
Ao testar um dos aplicativos Flutter, nos deparamos com uma situação interessante: a capacidade de atualizar a tela não estava disponível em dispositivos iOS com estrondo - começando com o iPhoneX e superior. Ao mesmo tempo, dispositivos iOS sem estrondo e Android funcionaram corretamente.
Encontramos outro bug no Android versão 6: quando minimizado, o aplicativo foi completamente descarregado da memória.
Esses bugs foram corrigidos por nossos desenvolvedores dentro do projeto.
iOS estão bem cientes de seus dispositivos e sistemas, quais chips eles lançam com a nova versão do sistema operacional e quais não funcionarão mais nas versões anteriores, o que focar ao atualizar o mesmo Swift. O Android entende que precisa ter como alvo um grande número de dispositivos e tamanhos de tela completamente diferentes, e também conhece suas especificações.
Gostaria que a plataforma cruzada contivesse todas as sutilezas de implementação do desenvolvimento nativo. Claro, existem algumas falhas ao trabalhar com o Flutter, mas isso não é um problema: você só precisa de sua própria abordagem para a plataforma cruzada.
Benefícios: uma base de código, uma equipe de desenvolvimento
Uma única base de código reduz o tempo de teste.
O motivo dos bugs pode ser especificações técnicas confusas, falta de estados renderizados no design, compatibilidade com versões anteriores ao atualizar o back-end. É mais fácil criar esses bugs, porque você precisa criar a metade de muitas tarefas, e isso já economiza tempo.
Você pode pesquisar bugs e verificar recursos em uma plataforma: com um alto grau de probabilidade, eles se repetem em ambas as plataformas - afinal, há uma implementação.
A lógica dos novos recursos em ambas as plataformas também é a mesma, já que o mesmo código é escrito: testar processos complexos em um aplicativo se resume a testá-los em uma plataforma e confirmá-los em outra. Realizamos um ciclo completo de atividades em uma plataforma: fazemos testes exploratórios, executamos recursos, fumegamos / sanidade / completo, analisamos feedback. Depois disso, resta apenas confirmar a qualidade por meio de testes exploratórios em outra plataforma. Essa abordagem economiza tempo de teste lógico em cerca de 1,3 vezes.
, , , : , . , .
, (, iOS), , (Android), event .
Se os conjuntos para ambas as plataformas precisam ser entregues ao cliente no mesmo dia, eles saem ao mesmo tempo e há apenas um engenheiro de QA no projeto, pode não haver tempo suficiente para verificação no desenvolvimento nativo: o ciclo de teste deve ser executado em ambas as plataformas separadamente. Economizamos tempo testando aplicativos de plataforma cruzada: o teste de regressão de ambas as plataformas ocorre em um único ciclo.
Tentamos avaliar aproximadamente o teste de dois projetos semelhantes - um no Android e iOS nativos, o segundo no Flutter - e compará-los apicamente.
A análise e o teste foram realizados em um dispositivo iOS e um dispositivo da plataforma Android. Como você pode ver na prática, o Flutter realmente dá um ganho de tempo, embora não o dobro. Isso é compreensível: você não pode remover completamente o teste em uma das duas plataformas. O que quer que se diga, eles têm especificidade e foco diferentes no usuário.
|
|
IOS nativo
|
Android nativo
|
Flutter Android + iOS
|
| Recuperação de senha
|
2h
|
2h
|
3h 20m
|
| Autorização
|
1h 30m
|
1h 30m
|
2h 20m
|
| Notificações via push
|
2h
|
2h
|
4h
|
Ao testar um recurso pronto que não afeta completamente as especificações do sistema operacional e não é personalizado para cada plataforma separadamente, o tempo para verificar um aplicativo Flutter em ambas as plataformas é reduzido em cerca de 1,3-1,5 vezes. Por exemplo, os recursos de autorização e recuperação de senha que não têm comportamento específico em diferentes plataformas reduzem o tempo de teste da versão Flutter em 1,3 vezes.
Quanto aos recursos que exigem um comportamento personalizado de cada plataforma, você não deve esperar a redução do tempo. Espera-se que o comportamento para iOS e Android seja diferente, o que significa que ambas as plataformas precisam ser testadas completa e separadamente uma da outra. Por exemplo, muitas vezes é necessário testar notificações push em ciclo completo em ambas as plataformas devido a diferenças nas permissões, trabalho com conexão de notificações, configurações de push para envio de notificações no iOS e Android, bem como outras sutilezas de implementação - para que o trabalho usual do usuário com notificações seja suportado. TK e design foram respeitados.
É mais fácil organizar a comunicação dentro da equipe
Quando há muitas pessoas no projeto, é difícil organizar o processo de forma que mesmo as menores sutilezas não passem. Principalmente se houver muitas melhorias pela frente, implementações de novos recursos e mudanças em geral. A maioria dos problemas é resolvida quando a equipe de desenvolvimento é uma.
Primeiro, é mais fácil testar um aplicativo implementando um único comando do que trabalhar com duas implementações diferentes em duas plataformas. O profissional de garantia de qualidade está, obviamente, interessado em ter informações completas sobre o estado da aplicação, tanto na plataforma iOS como na plataforma Android. É mais fácil trabalhar com o Flutter.
Em segundo lugar, há um ponto importante no desenvolvimento nativo: sobre as mudanças que uma plataforma aprendeu e aceitou, é necessário notificar a outra plataforma, que às vezes é esquecida ou perdida no decorrer de mudanças grandes e intensas. Esse problema não existe no desenvolvimento de aplicativos Flutter: há apenas uma equipe - ou seja, uma tarefa para revisão se aplica a ambas as plataformas.
Adoramos testar aplicativos Flutter
Fazer parte de uma comunidade bacana
Para nós, um novo framework é uma vantagem: resolvendo problemas fora do padrão, ampliamos nossos horizontes. Encontramos muitos bugs interessantes e exclusivos que desenvolvem nossas habilidades e capacidades ao testar aplicativos.
Ao mesmo tempo, os desenvolvedores da comunidade Flutter-framework rapidamente fornecem feedback sobre os problemas identificados, melhoram a biblioteca e nos permitem contribuir com o projeto: estamos avançando juntos e é bom.
Seja um especialista
Ao trabalhar com aplicativos multiplataforma, é importante ter em mente as diferenças de sistemas operacionais e não perder o foco na especificidade da plataforma. Buscar e ver diferenças onde deveriam ser mínimas em teoria, aprender algo que você nunca encontrou antes - esse trabalho aumenta o profissionalismo.
Ao desenvolver e testar aplicativos nativos, é impossível construir um aplicativo iOS a partir de, por exemplo, Android Studio ou Visual Studio Code. Ao trabalhar com Flutter, o IDE é o mesmo para Android e iOS. Isso é legal.
Seja independente
Ao trabalhar com a Flutter, na Surf nos deparamos com projetos muito diferentes: do e-commerce ao banco. A prática tem mostrado que um engenheiro de QA pode testar sozinho as duas plataformas. É necessário conectar outro especialista só mais perto do lançamento, quando o ritmo de trabalho aumenta e o tempo para finalização das tarefas está se esgotando.
Flutter - um passo à frente
Testar aplicativos de plataforma cruzada não é difícil. Às vezes é ainda mais rápido e conveniente do que trabalhar com os nativos. Todas as dificuldades que se podem enfrentar não se sobrepõem à comodidade e às vantagens.
A experiência no desenvolvimento e teste de aplicativos Flutter mostrou ao Surf que essa estrutura é um grande passo à frente.