Quando estiver a manter a sua Oracle BRM (Facturação e Gestão de Receitas) durante algum tempo, começa a aperceber-se de que a quantidade de entidades configuradas continua a aumentar. Por esta altura, é muito provável que também tenha desenvolvido algumas personalizações e integrado com soluções adicionais. A evolução do seu ambiente conduz a um conjunto complexo de objectos interligados. Chega a um ponto em que você, ou o seu cliente, decide mudar alguma coisa. À partida, a nova funcionalidade pode parecer fácil de desenvolver. A verdade, no entanto, é que muito provavelmente irá colidir com uma funcionalidade existente, ou irá requerer a actualização da configuração existente também. O que parecia ser uma simples alteração, acaba por afectar todo o sistema. Tais ocorrências são por vezes difíceis de evitar, mas estar preparado para elas pode poupar-lhe muitos problemas. Os cenários de teste funcional e a versatilidade dos testes podem ser um factor de mudança.
Tabela de conteúdos
Fluxo de desenvolvimento contínuo
Aqui na Tridens, estabelecemos um fluxo de desenvolvimento contínuo. Todas as nossas configurações BRM, personalizações e outros componentes integrados são devidamente versionados e controlados num sistema de controlo de versões distribuído (Git). Esta prática permite que os nossos programadores consultem as versões dos componentes necessários em qualquer altura e iniciem o seu trabalho. Tudo está bem até este ponto, mas como é que lidamos com a possibilidade de novas funcionalidades quebrarem a construção actual?
Temos um fluxo de implantação e teste configurado, que rastreia os repositórios remotos das nossas fontes. Consequentemente, cada vez que um programador faz um commit e envia algumas alterações para o controlo de versões, inicia-se o processo de teste. O fluxo de implantação constrói imagens docker para todos os componentes relevantes com suas versões mais recentes em um ambiente local (ou remoto), e testes automatizados são executados para garantir que a construção seja estável. Apenas quando os testes são bem-sucedidos, podemos lançar as novas versões para produção. Este processo ajuda-nos a garantir que as novas funcionalidades funcionam sem problemas com as existentes. Os testes executados fazem parte do Oracle BRM TestToolkit, que desenvolvemos. O BRM TestToolkit tem passos e cenários pré-definidos com código cola de fundo. Os passos são muito descritivos e fáceis de utilizar, permitindo aos nossos programadores ou a qualquer outro utilizador escrever rapidamente novos cenários de teste. Veja um exemplo de cenários de teste na imagem abaixo.
BRM TestToolkit para testes automatizados
O que começou como simples cenários de teste para criação de contas e compra de produtos, representa hoje a estrutura principal do nosso BRM TestToolkit de testes. Para clarificar, temos agora vários casos de teste diferentes e cenários marginais para garantir a cobertura máxima das funcionalidades implementadas. Os testes automatizados permitem que os nossos programadores se concentrem na tarefa que têm em mãos e não gastem muito tempo em testes manuais. Claro que, por vezes, damos por nós a desenvolver uma nova funcionalidade ainda não coberta pelos cenários de teste. Nesses casos, as definições dos passos de teste e o seu código de base são implementados como parte dessa funcionalidade - para serem utilizados também no futuro.
O TestToolkit pode comunicar com diferentes componentes, permitindo a possibilidade de ajustes rápidos também para outros sistemas. Também utilizamos versões redesenhadas do nosso BRM TestToolkit para os nossos outros componentes. Uma das últimas funcionalidades que adicionámos foi a modularidade, em que os programadores podem marcar diferentes cenários de teste como partes de um grupo. Cada grupo tem então os seus guiões e lógica separada, permitindo, se desejado, que apenas um número específico de testes seja executado de cada vez e em paralelo. Além disso, a modularidade permite-nos separar os testes de classificação pré-paga dos testes de classificação pós-paga ou os testes de compras adicionais das compras diversas. Pode ver o fluxo de testes na imagem abaixo.
Cobertura do cenário de teste
O BRM TestToolkit comunica com a nossa API, que integrámos no Oracle BRM para simplificar as operações mais complexas. O TestToolkit também pode interagir com o BRM RestBridgePara mais informações, consulte a nossa solução BRM wrapper, que facilita a comunicação com o BRM, permitindo a utilização do formato JSON ou XML através de uma API REST. As definições das etapas de teste suportam, entre muitas outras, as seguintes operações:
- Criação e gestão de contas
- Compra de transacções e outras operações de transacção
- Recuperação e controlo do saldo
- Geração de tráfego - Eventos de utilização
- Chamadas API
- Entrega do CDR
- ferramentas de tráfego em tempo real (protocolo diameter)
- Controlos de classificação
- O BRM TestToolkit compara diferentes eventos de utilização e compras com os valores esperados
- cada plano ou produto diferente pode ter o seu próprio conjunto de ficheiros de classificação, assegurando versatilidade em configurações complexas de produtos
Ao compor os passos de teste de fácil utilização, cada programador pode escrever os cenários para a funcionalidade em desenvolvimento. Em muitos casos, os nossos programadores optam por definir os cenários de teste com antecedência - antes de desenvolverem a funcionalidade. A preparação antecipada de cenários segue o padrão Behaviour Driven Development (BDD). O BDD significa essencialmente que os cenários ditam o fluxo de desenvolvimento e devem existir antecipadamente. Estes cenários descrevem a forma como o sistema se deve comportar e os programadores devem desenvolver novas funcionalidades de forma a encaixarem-se nestes cenários. Cada cenário de teste pode ser executado separadamente, resultando num relatório num formato específico. Abaixo está o exemplo de um relatório HTML.
Relatórios
Quando o sistema executa os cenários de teste como parte de uma nova compilação de desenvolvimento, normalmente executa-os em todo o seu potencial - incluindo todos os testes. De ambiente para ambiente, isto pode levar algum tempo, mas fornece-lhe uma imagem ampla de como a nova funcionalidade pode ter afectado quaisquer outras implementações existentes. Podemos avaliar a estabilidade da compilação a partir do relatório de teste, que o BRM TestToolkit gera no final de uma execução de teste. Os relatórios de teste contêm detalhes para cada cenário de teste, mas também fornecem algumas estatísticas e análises sobre todos os testes em geral. Podemos usar essa análise para encontrar diferenças entre compilações e para garantir que uma compilação esteja funcionando corretamente. Veja um exemplo de um relatório abaixo.
Conclusão
Ter a solução de teste correcta pode poupar muito tempo e evitar a ocorrência de erros desnecessários. Por conseguinte, se estiver a debater-se com alguma das dificuldades mencionadas neste artigo, ou se estiver interessado no nosso kit de ferramentas BRM para testes, não hesite em contactar-nos. Teremos todo o gosto em falar-lhe mais sobre a nossa solução e elaborar um plano optimizado para melhorar o seu fluxo de implementação e de testes.
