Oi, Habr!
Meu nome é Maxim Ponomarenko e sou desenvolvedor da Sportmaster. Tenho 10 anos de experiência na área de TI. Ele começou sua carreira em testes manuais e depois mudou para desenvolvimento de banco de dados. Nos últimos 4 anos, acumulando o conhecimento adquirido em testes e desenvolvimento, venho automatizando testes no nível de SGBD.
Estou na equipe Sportmaster há pouco mais de um ano e estou desenvolvendo testes automatizados em um dos principais projetos. Em abril, o pessoal do Sportmaster Lab e eu conversamos em uma conferência em Krasnodar, meu relatório se chamava “Testes unitários em um SGBD” e agora quero compartilhá-lo com vocês. Haverá muito texto, então decidi dividir o relatório em dois posts. No primeiro falaremos sobre autotestes e testes em geral e, no segundo, abordarei mais detalhadamente nosso sistema de testes unitários e os resultados de sua aplicação.
Primeiro, uma teoria um pouco chata. O que são testes automatizados? São testes realizados por meio de software e, na TI moderna, são cada vez mais utilizados no desenvolvimento de software. Isto deve-se ao facto de as empresas estarem a crescer, os seus sistemas de informação estarem a crescer e, consequentemente, a quantidade de funcionalidades que precisam de ser testadas estar a crescer. A realização de testes manuais está se tornando cada vez mais cara.
Trabalhei para uma grande empresa cujos lançamentos saem a cada dois meses. Ao mesmo tempo, um mês inteiro foi gasto para que uma dúzia de testadores verificassem manualmente a funcionalidade. Graças à implementação da automação por uma pequena equipe de desenvolvedores, conseguimos reduzir o tempo de teste para 2 semanas em um ano e meio. Não apenas aumentamos a velocidade dos testes, mas também melhoramos sua qualidade. Os testes automatizados são lançados regularmente e realizam sempre todo o percurso de verificações neles incluídos, ou seja, excluímos o fator humano.
A TI moderna é caracterizada pelo fato de que um desenvolvedor pode ser obrigado não apenas a escrever o código do produto, mas também a escrever testes unitários que verificam esse código.
Mas e se o seu sistema for baseado principalmente na lógica do servidor? Não existe uma solução universal ou melhores práticas no mercado. Via de regra, as empresas resolvem esse problema criando seu próprio sistema de testes escrito por elas mesmas. Este é o nosso próprio sistema de testes automatizados escrito por nós mesmos, criado em nosso projeto e falarei sobre ele em meu relatório.
Testando a lealdade
Primeiro, vamos falar sobre o projeto onde implantamos um sistema de testes automatizados. Nosso projeto é o sistema de fidelidade Sportmaster (aliás, já escrevemos sobre isso em ).
Se sua empresa for grande o suficiente, seu sistema de fidelidade terá três propriedades padrão:
- Seu sistema estará altamente carregado
- Seu sistema conterá processos de computação complexos
- Seu sistema será melhorado ativamente.
Vamos em ordem... No total, se considerarmos todas as marcas Sportmaster, temos mais de 1000 lojas na Rússia, Ucrânia, China, Cazaquistão e Bielorrússia. Cerca de 300 mil compras são feitas nessas lojas todos os dias. Ou seja, a cada segundo, 000-3 verificações entram em nosso sistema. Naturalmente, nosso sistema de fidelidade é altamente carregado. E como é usado ativamente, devemos fornecer os mais altos padrões de qualidade, pois qualquer erro no software significa grandes perdas monetárias, de reputação e outras.
Ao mesmo tempo, a Sportmaster realiza mais de cem promoções diferentes. As promoções são diversas: tem promoções de produtos, tem aquelas dedicadas ao dia da semana, tem aquelas vinculadas a uma loja específica, tem promoções pelo valor do recibo, tem pela quantidade de mercadoria. Em geral, não é ruim. Os clientes contam com bônus e códigos promocionais que são utilizados na hora de fazer compras. Tudo isso leva ao fato de que calcular qualquer pedido é uma tarefa nada trivial.
O algoritmo que implementa o processamento de pedidos é realmente terrível e complicado. E quaisquer alterações neste algoritmo são bastante arriscadas. Parecia que as mudanças aparentemente mais insignificantes poderiam levar a efeitos bastante imprevisíveis. Mas são precisamente esses processos de computação complexos, especialmente aqueles que implementam funcionalidades críticas, que são os melhores candidatos à automação. Verificar manualmente dezenas de casos semelhantes consome muito tempo. E como o ponto de entrada no processo permanece inalterado, depois de descrevê-lo uma vez, você pode criar rapidamente testes automáticos e ter certeza de que a funcionalidade funcionará.
Como nosso sistema é usado ativamente, a empresa vai querer algo novo de você, conviver com os tempos e ser orientada para o cliente. Em nosso sistema de fidelidade os lançamentos saem bimestralmente. Isso significa que a cada dois meses precisamos realizar uma regressão completa de todo o sistema. Ao mesmo tempo, naturalmente, como em qualquer TI moderna, o desenvolvimento não passa imediatamente do desenvolvedor para a produção. Origina-se no circuito do desenvolvedor, passa sucessivamente pela bancada de testes, liberação, aceitação e só então vai para a produção. No mínimo, nos circuitos de teste e liberação, precisamos realizar uma regressão completa de todo o sistema.
As propriedades descritas são padrão para quase todos os sistemas de fidelidade. Vamos falar sobre as características do nosso projeto.
Tecnologicamente, 90% da lógica do nosso sistema de fidelização é baseada em servidor e implementada em Oracle. Existe um cliente exposto em Delphi, que desempenha a função de administrador automatizado de local de trabalho. Existem serviços web expostos para aplicações externas (por exemplo, um website). Portanto, é muito lógico que se implantarmos um sistema de testes automatizados, o faremos no Oracle.
O sistema de fidelidade no Sportmaster existe há mais de 7 anos e foi criado por desenvolvedores únicos... O número médio de desenvolvedores em nosso projeto durante esses 7 anos foi de 3 a 4 pessoas. Mas durante o ano passado, nossa equipe cresceu significativamente e agora há 10 pessoas trabalhando no projeto. Ou seja, chegam ao projeto pessoas que não estão familiarizadas com tarefas, processos e arquitetura típicos. E há um risco maior de não percebermos erros.
O projeto é caracterizado pela ausência de testadores dedicados como unidades de pessoal. É claro que existem testes, mas os testes são realizados por analistas, além de suas outras responsabilidades principais: comunicar-se com clientes empresariais, usuários, desenvolver requisitos de sistema, etc. etc... Apesar de os testes serem realizados com altíssima qualidade (isto é especialmente apropriado mencionar, já que alguns dos analistas podem chamar a atenção deste relatório), a eficácia da especialização e concentração em uma coisa não foi cancelada .
Considerando tudo isso, para melhorar a qualidade do produto entregue e reduzir o tempo de desenvolvimento, a ideia de automatizar os testes de um projeto parece muito lógica. E em diferentes estágios da existência do sistema de fidelidade, desenvolvedores individuais fizeram esforços para cobrir seu código com testes unitários. No geral, foi um processo bastante desarticulado, com cada um usando sua própria arquitetura e métodos. Os resultados finais foram comuns aos testes unitários: os testes foram desenvolvidos, utilizados por algum tempo, armazenados em um armazenamento de arquivos versionados, mas em algum momento pararam de rodar e foram esquecidos. Em primeiro lugar, isso se deveu ao fato dos testes estarem mais vinculados a um executor específico e não ao projeto.
utPLSQL vem para o resgate
Você sabe alguma coisa sobre Stephen Feuerstein?
Este é um cara inteligente que dedicou grande parte de sua carreira trabalhando com Oracle e PL/SQL e escreveu um grande número de trabalhos sobre esse assunto. Um de seus livros famosos se chama: “Oracle PL/SQL. Para profissionais." Foi Stephen quem desenvolveu a solução utPLSQL, ou, como significa, estrutura de testes unitários para Oracle PL/SQL. A solução utPLSQL foi criada em 2016, mas continua a ser trabalhada ativamente e novas versões são lançadas. No momento do relatório, a versão mais recente datava de 24 de março de 2019.
O que é. Este é um projeto de código aberto separado. Ele pesa alguns megabytes, incluindo exemplos e documentação. Fisicamente, é um esquema separado no banco de dados ORACLE com um conjunto de pacotes e tabelas para organizar testes unitários. A instalação leva alguns segundos. Uma característica distintiva do utPLSQL é a sua facilidade de uso.
Globalmente, utPLSQL é um mecanismo para execução de testes unitários, onde um teste unitário é entendido como procedimentos em lote comuns do Oracle, cuja organização segue certas regras. Além de iniciar, o utPLSQL armazena um log de todas as suas execuções de testes e também possui um sistema de relatórios interno.
Vejamos um exemplo da aparência do código de teste de unidade, implementado usando esta técnica.
Assim, a tela mostra o código para uma especificação típica de pacote com testes unitários. Quais são os requisitos obrigatórios? O pacote deve ser prefixado com "utp_". Todos os procedimentos com testes devem ter exatamente o mesmo prefixo. O pacote deve conter dois procedimentos padrão: “utp_setup” e “utp_teardown”. O primeiro procedimento é chamado reiniciando cada teste de unidade, o segundo - após o lançamento.
“utp_setup”, via de regra, prepara nosso sistema para executar um teste unitário, por exemplo, criando dados de teste. “utp_teardown” - pelo contrário, tudo retorna às configurações originais e redefine os resultados do lançamento.
Aqui está um exemplo do teste de unidade mais simples que verifica a normalização do número de telefone do cliente inserido no formulário padrão do nosso sistema de fidelidade. Não existem padrões obrigatórios sobre como escrever procedimentos com testes unitários. Via de regra, é feita uma chamada a um método do sistema em teste, e o resultado retornado por este método é comparado com o de referência. É importante que a comparação do resultado de referência e o obtido ocorra através de métodos utPLSQL padrão.
Um teste de unidade pode ter qualquer número de verificações. Como pode ser visto no exemplo, fazemos quatro chamadas consecutivas ao método testado para normalizar o número de telefone e avaliar o resultado após cada chamada. Ao desenvolver um teste de unidade, deve-se levar em consideração que existem verificações que não afetam de forma alguma o sistema e, após algumas, é necessário reverter ao estado original do sistema.
Por exemplo, no teste unitário apresentado simplesmente formatamos o número de telefone inserido, o que não afeta de forma alguma o sistema de fidelidade.
E se escrevermos testes unitários usando o método de criação de um novo cliente, após cada teste um novo cliente será criado no sistema, o que pode afetar o lançamento subsequente do teste.
É assim que os testes unitários são executados. Existem duas opções de inicialização possíveis: executar todos os testes de unidade de um pacote específico ou executar um teste de unidade específico em um pacote específico.
É assim que se parece um exemplo de sistema de relatórios internos. Com base nos resultados do teste unitário, o utPLSQL cria um pequeno relatório. Nele vemos o resultado de cada verificação específica e o resultado geral do teste unitário.
6 regras de autotestes
Antes de começar a criar um novo sistema de testes automatizados do sistema de fidelização, em conjunto com a gestão, determinamos os princípios que os nossos futuros testes automatizados deverão cumprir.
- Os autotestes devem ser eficazes e úteis. Temos desenvolvedores maravilhosos, que definitivamente precisam ser mencionados, porque alguns deles provavelmente verão este relatório e escrevem códigos maravilhosos. Mas mesmo seu código maravilhoso não é perfeito e contém, contém e continuará a conter erros. Autotestes são necessários para encontrar esses erros. Se não for esse o caso, ou estamos escrevendo autotestes ruins ou chegamos a uma área morta que, em princípio, não está sendo desenvolvida. Em ambos os casos, estamos a fazer algo errado e a nossa abordagem simplesmente não faz sentido.
- Autotestes devem ser usados. Não faz sentido gastar muito tempo e esforço escrevendo um produto de software, colocá-lo em um repositório e esquecê-lo. Os testes devem ser executados e executados com a maior regularidade possível.
- Os autotestes devem funcionar de forma estável. Independentemente da hora do dia, do suporte de lançamento e de outras configurações do sistema, os testes devem levar ao mesmo resultado. Via de regra, isso é garantido pelo fato de os autotestes funcionarem com dados de teste especiais com configurações fixas do sistema.
- Os autotestes devem funcionar a uma velocidade aceitável para o seu projeto. Este tempo é determinado individualmente para cada sistema. Algumas pessoas podem trabalhar o dia todo, enquanto outras acham fundamental fazê-lo em segundos. Contarei a vocês um pouco mais tarde quais padrões de velocidade alcançamos em nosso projeto.
- O desenvolvimento do autoteste deve ser flexível. Não é aconselhável recusar testar qualquer funcionalidade simplesmente porque não o fizemos antes ou por algum outro motivo. O utPLSQL não impõe nenhuma restrição ao desenvolvimento e o Oracle, em princípio, permite implementar uma variedade de coisas. A maioria dos problemas tem solução, é apenas uma questão de tempo e esforço.
- Implementabilidade. Temos vários estandes onde precisamos fazer testes. Em cada estande, um dump de dados pode ser atualizado a qualquer momento. É necessário realizar um projeto com testes automáticos de forma que seja possível realizar sua instalação total ou parcial sem dor.
E no segundo post, daqui a alguns dias contarei o que fizemos e quais resultados alcançamos.
Fonte: habr.com