Criação de robô (RPA) com ferramentas de AutoTeste

Autores: Lebedev A., Nazarova E. A

necessidade de usar a robótica surge por várias razões: a necessidade de novos aplicativos trocarem dados com aplicativos que não possuem uma API, a rápida integração de aplicativos heterogêneos, a automação de processos de rotina com um custo mínimo, etc.

Tradicionalmente, os robôs ou RPA (automação de processo robótico) são construídos com base em estruturas prontas. Aqui, os líderes são, em nossa opinião, produtos da UiPath, Automation Anywhere, Blue Prism, NICE. Essas são plataformas comprovadas que permitem tomar decisões de qualidade. No entanto, não é barato. Você precisa pagar pelas licenças no número de trabalhos futuros, pagar pela personalização da sua tarefa específica e comissionamento. Em alguns casos, você pode ficar mais barato. Conseguimos e estamos prontos para compartilhar experiências.

Há algum tempo, em um dos bancos, a transformação do Agile começou. Novas abordagens para o desenvolvimento de aplicativos para as necessidades do banco. Para mostrar aos outros o caminho, eles formaram equipes piloto para desenvolver novos produtos.

O banco possui sistemas-chave tradicionais para a realização de atividades contábeis e operacionais. O trabalho com os produtos das novas equipes foi implementado na forma de microsserviços, que devem trocar dados com os principais sistemas. E o desenvolvimento em equipes começou muito rapidamente. Mas o problema é que as abordagens tradicionais à política de liberação dos principais sistemas não se encaixavam nesse ritmo. E a API para os novos microsserviços estava no plano para o futuro.

Acontece que, como o de Pechkin, "eu trouxe um pacote para você, mas não vou dar a você". Nessas condições, os representantes das equipes piloto abordaram nossa equipe de autoteste com a idéia de usar autotestes de interface do usuário de processos semelhantes para criar robôs.

Naturalmente, discutimos primeiro os riscos. O fato de que, ao usar as ferramentas de autoteste, que a confiabilidade das soluções de software para os requisitos de teste é menor do que para os aplicativos de sistema de pagamento, foi anunciada imediatamente. Mas, impulsionadas pela onda Agile, as equipes assumiram riscos.

O kit de ferramentas foi usado tradicional e gratuito: Java para desenvolvimento, montagem através do Maven. Para trabalhar com o navegador, o Selenium foi usado (o aplicativo em que era necessário inserir dados possui uma interface da web).

As principais características distintivas do robô em comparação com o autoteste da interface do usuário do mesmo processo é a necessidade do tratamento correto de situações e exceções de erro, integração como um subsistema via troca de arquivos.

Para o robô funcionar, um servidor virtual foi alocado, uma conta de domínio técnico e um usuário separado foi criado no sistema em que os dados foram inseridos. Com autoridade, como um funcionário vivo que executa ações semelhantes.

Um agente Jenkins foi instalado neste servidor, o que permite executar o robô. O relatório sobre o trabalho do robô foi formado tanto na forma de um log de execução quanto na forma de um relatório de fascínio. Ambos estão disponíveis no Jenkins e não exigem permissão especial para acessar recursos de rede.

O trabalho do robô foi estruturado da seguinte forma: um arquivo com dados para a entrada no sistema é colocado na pasta de entrada em um recurso de rede e o robô é iniciado através do Jenkins; ele compara os registros do arquivo de entrada pelo campo-chave com o arquivo de serviço, onde todos os registros já processados ​​são armazenados e seleciona apenas aqueles que ainda não foram processados. Em seguida, a matriz de registros é processada em um loop. Além disso, em cada etapa do processamento de cada registro, são processadas exceções e erros (try ... catch) e as "quedas" do processo são anotadas no arquivo resultante. Ao mesmo tempo, o processamento da matriz de entrada não para, apenas vamos para o próximo registro. Como resultado, quando o processamento de toda a matriz é concluído, o arquivo de entrada é excluído, na saída existem todos os registros processados ​​com o resultado e o tempo de execução. O Allure Report é exibido como informações sobre o processamento de cada registro,e uma lista geral com os resultados do processamento de cada registro. Isso facilita avaliar o resultado e localizar problemas, se houver.



Além disso, no processo de uso do robô, o fluxo de aplicativos nos dias de pico é bastante grande e, para atender ao tempo de processamento aceitável, é necessário um número maior de usuários simultâneos.

O sistema criou vários outros usuários. A execução paralela foi implementada usando threads (Thread). Toda a matriz de registros de entrada é distribuída igualmente entre os fluxos, em cada um dos quais o processamento é realizado sob seu próprio usuário. Os resultados são gravados em um arquivo e o relatório também é único. É confortável. Ao mesmo tempo, um único Selenium Server foi lançado, capaz de lidar com o lançamento paralelo de vários navegadores (de acordo com o número de usuários que trabalham). Trabalhamos com o navegador Chrome, respectivamente, o chromedriver foi usado.

Isso é surpreendente, mas durante os nove meses de operação, os problemas foram causados ​​apenas por dados de entrada incorretos. Os problemas técnicos surgiram apenas na fase de comissionamento e foram associados à coordenação das codificações no log e à expansão da memória usada ao iniciar o Selenium Server (1G instalado).

Depois de algum tempo, para a mesma equipe Agile, outro robô foi desenvolvido. Sua característica é que ele não é iniciado sob demanda, mas funciona continuamente examinando a pasta de entrada. Quando um arquivo recebido é exibido, ele é processado. Consequentemente, o agente Jenkins não é usado. Se o processo for bem-sucedido, o arquivo de entrada será movido para a pasta com os arquivos processados ​​com êxito, caso contrário, para a pasta com os arquivos errados. Diferentemente do robô anterior, o Allure Report está ausente, mas os logs de execução são gravados em um arquivo separado para análise em caso de problemas. E mais um recurso - o navegador é fechado à força no final do processamento e inicia quando o usuário precisa fazer login.

Portanto, em alguns casos, ao criar um RPA, você pode se dar bem de uma maneira visivelmente mais barata usando as ferramentas de autoteste.