Get best of the week

Por que mudamos para Selenide escrevendo mais de 200 novos autotestes ao longo do caminho

Olá, sou uma ferramenta de automação de teste para um dos projetos de uma grande empresa. Neste artigo, explicarei por que decidimos mudar de Serenity para Selenide. Temos uma tarefa em larga escala e, embora a mudança da pilha tecnológica tenha demorado algum tempo, mais tarde se pagou mais acelerando a escrita de testes e a regressão.

imagem

Antes de chegar ao ponto, um pouco sobre a tarefa como um todo.

Infelizmente, não posso divulgar os detalhes do projeto sob os termos da NDA. De fato, essas são algumas das ferramentas para um call center de uma grande empresa - roteamento de chamadas, separação de operadores por tópico de chamadas etc. em uma bela interface de usuário. A interface, a propósito, é fornecida não apenas para as operadoras, mas também para os controladores que ouvem e avaliam as chamadas selecionadas. Acima de tudo, existe um sistema de diferenciação de direitos e um painel de administração que permite configurar todas as funções internas - de telefonia a classificações disponíveis para controladores.

Todo o volume de funcionalidade é dividido em vários projetos: telefonia, painel de usuário e painel de administração. Todos os três projetos estão em desenvolvimento ativo. E minha tarefa é automatizar os testes nesses projetos no sentido amplo da palavra.

Para algumas das funcionalidades desenvolvidas, já existiam testes automáticos, mas o especialista que os desenvolveu deixou a empresa; portanto, parecia haver um certo dever técnico de automatizar os testes. No total, foram escritos cerca de 50 autotestes, mas a grande maioria deles está completamente desatualizada, porque a funcionalidade foi muito à frente. Portanto, inicialmente a tarefa era atualizar tudo isso.

Atualização da pilha


Os autotestes existentes foram gravados usando a biblioteca Serenity. Na verdade, eles tiveram que ser reescritos novamente, de modo que não havia sentido em manter os desenvolvimentos existentes. A biblioteca em si era familiar para mim, mas, pessoalmente, não a considero uma ferramenta ideal. Então, entendendo a quantidade de trabalho, decidi mudar para Selenide desde o início.

Selenide é uma ferramenta bastante popular para a qual existem muitas soluções prontas. Alguns dos recursos do Selenide também estão disponíveis para análogos - Atlas, Selenium, HTMLElements, etc. Mas cada um deles à sua maneira não nos convinha.

O selênio é a base do seleneto. Mas, para nossos propósitos, é um nível muito baixo. Não faz sentido reinventar a roda quando existe uma solução pronta.

Atlas apareceu recentemente. Ele é bruto o suficiente e não possui suporte ao Groovy.
HtmlElements é bom para todos, mas está obsoleto e não é suportado. Há também JDI, mas há problemas de multithreading.

A serenidade, usada anteriormente no projeto, era muito complicada. Tudo nele é tão interconectado que, para adicionar um novo manipulador ou interceptador de eventos, tivemos que reescrever uma dúzia de classes (e isso não levou ao sucesso todas as vezes). Além disso, o Surenity não conseguiu conectar o Allure, o padrão real do setor e da empresa para gerar relatórios de teste.

No Selenide, do ponto de vista da automação, tudo é muito mais simples. Por exemplo, não há necessidade de descrever separadamente as etapas - anexar a métodos etc. Como ele possui o suporte Allure pronto para uso, todas as ações relacionadas ao trabalho com elementos da Web caem automaticamente no relatório de teste.

Obviamente, o Selenide tem suporte para PageFactory, Page Object e PageElement. Isso torna o código mais legível. Além disso, existem expectativas internas para o momento em que o elemento aparece - não há necessidade de declarar explicitamente que você precisa interromper o teste por alguns segundos antes de prosseguir (o limite de tempo limite é definido nas configurações). Expectativas explícitas existem separadamente - é possível redefinir explicitamente o tempo limite para os elementos necessários em cada etapa do teste.

Convenientemente, o Selenide possui todo um conjunto de vários métodos prontos.

Como no início da transição de Serenity para Selenide, eu estava sozinho na equipe, a vantagem adicional era que eu já tinha experiência suficiente com Selenide e Groovy, para poder implementar rapidamente soluções prontas e, posteriormente, gastar menos esforço para apoiá-las.

A transição foi quase indolor. Implementamos o Selenide em conjunto com o Allure. O Allure permite criar relatórios legíveis e até belos, que mostram claramente quais etapas caíram e com que erro. Pronto, você pode anexar capturas de tela de páginas da web a relatórios. Inclusive adicionamos um vídeo da corrida, o código fonte da página, os logs do navegador e o driver da web.

A migração de testes existentes exigiu um mínimo de esforço. O que a Serenity possui, o que o Selenide possui são PageObjects com anotações @FindBy. Serenidade e fascínio usam as mesmas anotações de etapa. Eu tive que atualizar o modelo, o aninhamento de elementos um no outro, a ordem de chamar as etapas do teste. Alguns testes foram completamente excluídos, outros foram reescritos do zero e, em algum lugar, apenas a atualização dos localizadores foi suficiente. De fato, mover tornou-se uma tarefa trivial que a maioria dos automadores de interface do usuário enfrenta ao projetar um aplicativo da web.

Atualização de teste


Após atualizar a pilha tecnológica, eles mesmos fizeram os testes. A propósito, parte deste trabalho já foi concluída como parte da transição para uma nova pilha.

Considerando o atraso acumulado da funcionalidade dos projetos, eles ainda precisariam ser reescritos de qualquer maneira - é mais lucrativo com o tempo do que procurar inconsistências em um volume de código tão grande.

No total, cerca de 220 autotestes foram escritos no momento para o front-end e o back-end. A ênfase no desenvolvimento futuro será no back-end, pois a maioria dos elementos funcionais no front-end já está envolvida em autotestes. Ao mesmo tempo, está mudando constantemente; portanto, quanto mais testes aparecerem no front-end, mais forças terão que ser gastas em seu apoio.

Com recursos de tempo infinito, sempre tentamos direcionar esforços para o que nos permitirá reduzir os custos de mão-de-obra para suporte, cobrindo a funcionalidade o máximo possível. Agora, a cobertura dos autotestes excedia um pouco 50%.


Os testes reescritos no Selenide tornaram-se mais compactos e precisos devido à reutilização repetida do código - tudo graças aos recursos da própria biblioteca.

Atualizando os testes, levamos em conta que eles precisam ser executados simultaneamente (em vários threads). Os testes foram executados anteriormente em máquinas virtuais separadas. Mas a transição para o Selenide nos permitiu paralelizar ainda mais a tarefa, executando-a em vários segmentos.

Grosso modo, a transição para uma nova estrutura aumentou o número de threads lançados simultaneamente de 3 para 8 e a otimização subsequente dos testes - até 50. Como resultado, 100 testes de interface do usuário são executados em apenas 10 minutos.


A multithreading, a propósito, é outra vantagem pela qual escolhemos o Selenide. Esta não é uma grande camada de clichê, você escreve um mínimo de código. Não há reduções supérfluas de que o Selenium precisa preparar o projeto para o lançamento. Tudo o que você precisa para executar os testes já está pronto.

Paralelamente à atualização e gravação de novos testes, conduzi o treinamento para os funcionários do departamento de testes, ajudando-os a mudar do manual para o teste de pilha cheia, para que ele chegasse ao regimento de automação do projeto. A pilha de tecnologia usada possui um limite de entrada mais baixo e a Internet está cheia de documentação e vídeos sobre como resolver certos problemas. Um mês depois, fui acompanhado por alguns testadores que podiam executar tarefas relacionadas à automação.

Já uma equipe inteira foi capaz de otimizar os testes de regressão. Se anteriormente, a regressão levava 7 dias da equipe, agora as mesmas tarefas são executadas por 4 dias, ou seja, Reduzimos o tempo dos testes em quase 2 vezes.

Existem muitos cenários à frente que ainda precisam ser automatizados. Automatizamos os testes de fumaça quase completamente, mas agora mudamos para os cenários de teste mais trabalhosos. Isso ajudará a reduzir ainda mais os tempos de recurso.

Naturalmente, desenvolveremos uma infraestrutura de teste. Planeja introduzir um servidor Mock. Agora estamos testando tudo em uma posição real, gerando dados de teste. Leva tempo e recursos. O servidor simulado permitirá que você execute autotestes sem essa preparação preliminar (escrevemos sobre o servidor simulado para outro projeto ).

Também planejamos introduzir um registro de autoteste para que você possa escrever um script TestRail com base em uma peça de trabalho obtida clicando diretamente na interface do navegador. Na saída, temos um tipo de protótipo de autoteste.

Autor do artigo: Yuri Kudryavtsev, especialista em teste de software automatizado.

PS Publicamos nossos artigos em vários sites do Runet. Assine nossas páginas no VK , FB , Instagram ou no canal Telegram para aprender sobre todas as nossas publicações e outras notícias do Maxilect.

More articles:


All Articles