Olá Habr!
Meu nome é Maxim Ponomarenko e sou desenvolvedor da Sportmaster. Tenho 10 anos de experiência na área de TI. Ele iniciou sua carreira em testes manuais e depois mudou para o desenvolvimento de bancos de dados. Nos últimos 4 anos, acumulando conhecimentos adquiridos em testes e desenvolvimento, participei da automação de testes no nível do DBMS.
Faço parte da equipe Sportmaster há pouco mais de um ano e estou envolvido no desenvolvimento de testes automatizados em um dos principais projetos. Em abril, os caras do Sportmaster Lab e eu conversamos em uma conferência em Krasnodar, meu relatório foi chamado de Testes de Unidade no DBMS e agora quero compartilhá-lo com você. Como há muito texto, decidi dividir o relatório em duas postagens. No primeiro, falaremos sobre autotestes e testes em geral; no segundo, abordarei nosso sistema de teste de unidade e os resultados de sua aplicação.
A princípio, um pouco de teoria chata. O que é teste automático? Este é um teste realizado por software e, na TI moderna, é cada vez mais utilizado no desenvolvimento de software. Isso se deve ao fato de as empresas estarem crescendo, seus sistemas de informação estarem crescendo e, consequentemente, a quantidade de funcionalidades que precisam ser testadas. A realização de testes manuais está se tornando cada vez mais cara.
Eu trabalhei para uma grande empresa, cujos lançamentos são lançados a cada dois meses. Ao mesmo tempo, um mês inteiro foi gasto em uma dúzia de testadores para verificar a funcionalidade com as mãos. Graças à introduçã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 aumentamos sua qualidade. Testes automatizados são executados regularmente e sempre completam todo o curso dos testes inerentes a eles, ou seja, excluímos o fator humano.
A TI moderna é caracterizada pelo fato de que o desenvolvedor pode ser solicitado não apenas a escrever o código do produto, mas a escrever testes de unidade que verificam esse código.
Mas e se o seu sistema for baseado principalmente na lógica do servidor? Não há uma solução única e boas práticas no mercado. Como regra, as empresas resolvem esse problema criando seu próprio sistema de teste auto-escrito. Um sistema de teste automatizado e auto-escrito proprietário foi criado em nosso projeto, e falarei sobre isso em meu relatório.
Testando a lealdade
Primeiro, vamos falar sobre um projeto em que implantamos um sistema de teste automatizado. Nosso projeto é o sistema de fidelidade da Sportmaster (a propósito, já escrevemos sobre isso
neste post ).
Se sua empresa for grande o suficiente, seu sistema de fidelidade terá três propriedades padrão:
- Seu sistema estará muito carregado.
- Seu sistema conterá processos de computação complexos.
- Seu sistema será desenvolvido ativamente.
Vamos em ordem. Sportmaster tem um grande número de lojas que estão vendendo ativamente. Naturalmente, o sistema de fidelidade é um sistema altamente carregado. E como o projeto é usado ativamente, devemos fornecer os mais altos padrões de qualidade, porque qualquer erro no software é muito dinheiro, reputação e outras perdas.
Ao mesmo tempo, mais de cem promoções diferentes funcionam no Sportmaster. As ações são muito diferentes: existem commodities, cronometram para o dia da semana, estão vinculadas a uma loja em particular, há ações no valor do cheque, há o número de mercadorias. Em geral, não é fraco. Os clientes têm bônus, existem códigos promocionais que são usados nas compras. Tudo isso leva ao fato de que o cálculo de qualquer ordem é uma tarefa não trivial.
O algoritmo que implementa o processamento de pedidos é realmente terrível e complicado. E quaisquer alterações neste algoritmo são uma coisa bastante arriscada. Parecia haver as menores mudanças externas que poderiam levar a efeitos imprevisíveis. Mas são precisamente esses processos computacionais complexos, tanto mais que a implementação de funcionalidades críticas é o melhor candidato para automação. Verificar dezenas de casos do mesmo tipo com as mãos consome muito tempo. E como o ponto de entrada para o processo permanece inalterado, uma vez descrito, você pode carimbar rapidamente os testes automáticos e ter certeza da funcionalidade.
Como nosso sistema é usado ativamente, a empresa desejará algo novo de você, atualizado e orientado para o cliente. Em nosso sistema de fidelidade, os lançamentos são lançados a cada dois meses. Portanto, a cada dois meses, precisamos realizar uma regressão completa de todo o sistema. Ao mesmo tempo, é claro, como em qualquer TI moderna, o desenvolvimento não vem imediatamente do desenvolvedor para a produção. Ele se origina no circuito do desenvolvedor e, em seguida, passa sequencialmente no banco de testes, na liberação, na aceitação e somente depois está em produção. Pelo menos 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 qualquer sistema de fidelidade. Vamos falar sobre os recursos do nosso projeto.
Tecnologicamente, 90% da lógica do nosso sistema de fidelidade é baseada em servidor e implementada no Oracle. Há um cliente exposto no Delphi, que executa a função de um administrador do AWP. Existem serviços da Web expostos para aplicativos externos (como um site). Portanto, é muito lógico que, se implantarmos um sistema de teste automatizado, faremos isso 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-4 pessoas. Mas, no ano passado, nossa equipe cresceu significativamente e agora 10 pessoas estão trabalhando no projeto. Ou seja, pessoas que não estão familiarizadas com tarefas, processos e arquitetura típicos vêm ao projeto. E há um risco maior de ignorarmos erros.
O projeto é caracterizado pela ausência de testadores dedicados como unidades de equipe. É claro que é o teste, mas os analistas estão envolvidos no teste, além de outras responsabilidades principais: comunicar-se com clientes comerciais, usuários, elaborar requisitos de sistema etc. etc ... Apesar de os testes serem realizados de maneira muito qualitativa (isso é especialmente apropriado para mencionar, uma vez que um dos analistas pode chamar a atenção neste relatório), ninguém cancelou a eficácia da especialização e concentração em uma coisa.
Dado tudo o que foi dito acima, para melhorar a qualidade do produto emitido e reduzir o tempo de desenvolvimento, a idéia de automatizar os testes no 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 de unidade. Geralmente, era um processo bastante díspar onde todos usavam sua arquitetura e métodos. Os testes de unidade eram comuns para os resultados finais: os testes foram desenvolvidos, usados por algum tempo, empilhados em um armazenamento de arquivo com versão, mas em algum momento eles pararam de iniciar e foram esquecidos. Isso ocorreu principalmente pelo fato de os testes estarem mais vinculados a um artista específico, e não a um projeto.
UtPLSQL vem em socorro
Você sabe alguma coisa sobre Stephen Feuerstein?
Esse é um cara esperto que dedicou uma longa parte de sua carreira a trabalhar com Oracle e com PL / SQL, escreveu um número bastante grande de trabalhos sobre esse tópico. Um livro bem conhecido dele é chamado: “Oracle PL / SQL. Para profissionais. ” É Steven quem é o proprietário do desenvolvimento da solução utPLSQL ou, como é o caso, da estrutura de Teste de Unidade para Oracle PL / SQL. A solução utPLSQL foi criada em 2016, mas eles continuam trabalhando ativamente nela e lançam novas versões. No momento do relatório, a versão mais recente era de 24 de março de 2019.
O que é isso? Este é um projeto de código aberto separado. Ele pesa alguns megabytes, levando em consideração exemplos e documentação. Fisicamente, é um esquema separado no banco de dados ORACLE com um conjunto de pacotes e tabelas para organizar o teste de unidade. A instalação leva alguns segundos. Um recurso distintivo do utPLSQL é sua facilidade de uso.
Globalmente, o utPLSQL é um mecanismo para executar testes de unidade, nos quais um teste de unidade se refere a procedimentos em lote regulares do Oracle, cuja organização segue determinadas regras. Além do lançamento, o utPLSQL armazena um log de todas as suas execuções de teste e também há um sistema interno de relatórios.
Vejamos um exemplo de como é o código de teste de unidade implementado por esta técnica.
Portanto, a tela mostra o código para a especificação padrão de um pacote com testes de unidade. Quais são os requisitos necessários? O pacote deve ter o prefixo 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 início.
"Utp_setup", via de regra, prepara nosso sistema para executar um teste de unidade, por exemplo, cria 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 digitado para a aparência padrão do nosso sistema de fidelidade. Não há padrões obrigatórios para escrever procedimentos com testes de unidade. Como regra, um método do sistema em teste é chamado e o resultado retornado por esse método é comparado com o de referência. É importante que a comparação entre o resultado de referência e o resultado ocorra através dos métodos utPLSQL padrão.
Um teste de unidade pode ter qualquer número de verificações. Como você pode ver no exemplo, fazemos quatro chamadas consecutivas do método testado para normalizar o número de telefone e, após cada chamada, avaliamos o resultado. Ao desenvolver um teste de unidade, é preciso levar em consideração que há verificações que não afetam o sistema de nenhuma maneira e, após algumas, é necessário reverter para o estado inicial do sistema.
Por exemplo, no teste de unidade apresentado, simplesmente formatamos o número de telefone de entrada, o que não afeta o sistema de fidelidade.
E se escrevermos testes de unidade usando o método de criação de um novo cliente, depois de cada verificação, um novo cliente será criado no sistema, o que pode afetar o lançamento subsequente do teste.
É assim que os testes de unidade são executados. Existem duas opções possíveis de inicialização: iniciar todos os testes de unidade de um pacote específico ou iniciar um teste de unidade específico em um pacote específico.
Aqui está um exemplo de um sistema de relatório interno. De acordo com os resultados do teste de unidade, o utPLSQL cria um pequeno relatório. Nele, vemos o resultado de cada teste específico e o resultado geral do teste de unidade.
6 regras de autoteste
Antes de começar a criar um novo sistema para testes automatizados de um sistema de fidelidade, juntamente com a gerência, determinamos os princípios que nossos futuros testes automáticos devem cumprir.
- Os testes automáticos devem ser eficazes e devem ser benéficos. Temos desenvolvedores maravilhosos, sobre os quais devo dizer, porque um deles provavelmente verá este relatório e eles escreverão um código maravilhoso. Mas mesmo o código maravilhoso deles não é perfeito e contém, contém e conterá erros. São necessários autotestes para encontrar esses erros. Se não é assim, escrevemos autotestes ruins ou chegamos a uma área morta que, em princípio, não está sendo finalizada. Nos dois casos, estamos fazendo algo errado, e nossa abordagem é simplesmente sem sentido.
- Testes automáticos devem ser usados. Não faz sentido gastar muito tempo e esforço escrevendo um produto de software, adicionar seu repositório e esquecê-lo. Os testes devem ser executados o mais regularmente possível.
- Os autotestes devem funcionar de forma estável. Independentemente da hora do dia, do suporte de lançamento ou de outras configurações do sistema, a execução dos testes deve levar ao mesmo resultado. Como regra, isso é garantido pelo fato de que os autotestes funcionam com dados de teste especiais com configurações fixas do sistema.
- Os testes automáticos devem funcionar a uma velocidade aceitável para o seu projeto. Esse tempo é determinado individualmente para cada sistema. Alguém pode se dar ao luxo de trabalhar o dia inteiro e alguém se encaixa criticamente nos segundos. Quais os padrões de velocidade que alcançamos em nosso projeto, vou contar um pouco mais tarde.
- O desenvolvimento de autotestes deve ser flexível. É indesejável recusar-se a testar qualquer funcionalidade simplesmente porque ainda não o fizemos ou por outras convicções. O utPLSQL não impõe nenhuma restrição de desenvolvimento e o Oracle, em princípio, permite implementar uma variedade de coisas. A maioria das tarefas tem uma solução, a única questão é tempo e esforço.
- Implantação. Temos vários estandes onde você precisa executar testes. Em cada um dos estandes, um despejo de dados pode ser atualizado a qualquer momento. É necessário realizar um projeto com autoteste, de forma a poder realizar sem problemas sua instalação completa ou parcial.
E no segundo post, em alguns dias, vou contar o que fizemos e que resultados foram alcançados.