Como executar testes de fumo de API no seu pipeline de implementação contínua

Todos os anos, mais empresas de software adotam uma arquitetura de microsserviços utilizando Interfaces de programação de aplicações (APIs), porque as APIs facilitam o acesso das diferentes equipas de um projeto aos recursos umas das outras. As APIs também permitem que empresas de software ou indivíduos obtenham dados uns dos outros: por exemplo, o Twitter tem uma API que é utilizada por muitas pequenas empresas para obter tweets relacionados com a sua atividade e apresentá-los na página Web da empresa.

Outra excelente funcionalidade das APIs é serem mais pequenas do que uma aplicação monolítica, o que significa que podem ser implementadas frequentemente. Na empresa onde trabalho, cada equipa tem várias APIs e temos oito ambientes diferentes nos quais fazemos implementações. Se dependêssemos exclusivamente de testes manuais para verificar se as APIs tinham sido implementadas corretamente, teríamos de executar oito conjuntos de testes para cada versão de uma API. E se implementássemos mais do que uma API de cada vez, o que fazemos frequentemente porque as nossas APIs funcionam em conjunto, poderíamos estar a executar centenas de testes. E, se fizermos uma implementação de duas em duas semanas, esses testes representarão muitos testes maçadores e repetitivos! 

Resolvemos este problema configurando testes de fumo automatizados das APIs, executados a cada implementação, em todos os ambientes. Neste artigo, descrevo como decidimos o que testar e como configurámos os nossos testes de fumo. Utilizámos Postman, Newman, PowerShell e Octopus para configurar os nossos testes de fumo automatizados, pelo que descreverei o que fizemos com essas ferramentas. No entanto, estas estratégias poderiam ser adotadas em qualquer pipeline de implementação contínua (CD).

Passo um: decidir o que testar

O principal objetivo dos testes de fumo é realizar alguns testes simples e de alto nível para garantir que a implementação foi bem-sucedida. Este não é o momento para testar tudo o que a sua API consegue fazer. Quando escolhemos o que incluir nos nossos testes de fumo, tivemos em consideração o seguinte:

• Configurámos um teste de “Caminho feliz” para cada ponto de acesso — isto é, um teste que se espera que seja bem-sucedido. Por exemplo, seria de esperar que um pedido GET de um recurso com um ID específico devolvesse esse recurso. Deve testar cada ponto de acesso uma vez para verificar se cada um funciona conforme esperado.

• Se existissem variações importantes na forma como um ponto de acesso específico seria utilizado, adicionávamos um ou mais testes para verificar essas variações. Por exemplo, temos uma API de obtenção de ficheiros através da qual um ficheiro pode ser obtido por dois métodos diferentes. O ponto de acesso é igual, mas os corpos dos pedidos são diferentes. Por isso, adicionámos um teste para cada método.

• Para os pontos de acesso que exigiam um determinado nível de segurança, adicionámos um teste para validar que um pedido sem a autenticação adequada NÃO devolveria informações e, em vez disso, devolveria um erro de nível 400.

• Não adicionámos outros testes negativos, como um pedido POST com dados fora dos parâmetros permitidos, porque não considerámos que fossem necessários para garantir o funcionamento da API. Em vez disso, executámos esses testes como parte de um conjunto de testes de regressão noturno.

Passo dois: exportar os seus testes 

Utilizámos o Postman para criar os nossos testes de API, pelo que, quando os testes foram criados, exportámos tanto a coleção de testes como o ficheiro do ambiente de testes para ficheiros JSON. Para quem não está familiarizado com o Postman, um ambiente de testes é um grupo de variáveis que pode ser referenciado numa coleção de testes. 

Passo três: escrever um script para executar os seus testes

O Postman tem uma ferramenta de linha de comandos chamada Newman, que pode ser utilizada para executar uma coleção de testes, pelo que foi o que utilizámos para executar os nossos testes. Criámos um script PowerShell que executaria o comando Newman. 

Passo quatro: criar um passo de implementação para chamar o seu script

Assim que o script PowerShell ficou pronto, configurámos um passo de implementação em cada projeto de implementação de APIs do Octopus que executaria o script de testes. Se o script falhasse, a implementação falharia.

Passo cinco: organizar as suas variáveis

As variáveis são frequentemente uma consideração importante ao executar testes de fumo em diferentes ambientes. Por exemplo, no seu ambiente de QA, o seu utilizador de teste pode ter um ID de 340, mas no seu ambiente de pré-produção, o seu utilizador de teste pode ter um ID de 620. Outro problema relacionado com as variáveis é que, por vezes, por motivos de segurança, pode não ter acesso a palavras-passe ou chaves nos ambientes de produção. Era esse o caso da nossa equipa, mas, felizmente, o Octopus tem os valores de que precisamos para executar os nossos testes em produção, pelo que resolvemos o problema fazendo com que o Octopus transmitisse os valores de que precisávamos ao nosso script de testes.

Eram necessários três tipos diferentes de variáveis para o nosso teste de fumo:

• Tipo 1: Variáveis que não sofriam alterações em cada ambiente de testes, como “firstName”: “Prunella”. Estas variáveis podiam ser colocadas diretamente no ambiente do Postman, pelo que não era necessário fazer mais nada com elas. 

• Tipo 2: Variáveis que mudavam em cada ambiente de testes, mas que não precisavam de ser mantidas em segurança, como “userId”: 340. Estas variáveis foram adicionadas como variáveis do Octopus desta forma: “smoke.userId”, e o valor da variável foi definido para cada ambiente; por exemplo, QA foi definido como 340, pré-produção como 620 e produção como 450.

• Tipo 3: Variáveis que mudavam para cada ambiente de teste e que tinham de ser mantidas seguras, como “apiKey”: “b20628a9-3c00-4dad-b38c-0a4d2d85ffab”. As variáveis do Tipo 3 já tinham sido definidas na biblioteca de variáveis do Octopus. 

Utilizámos então as variáveis da seguinte forma:

1. Quando chamámos o script Powershell no Octopus, enviámos para o script as variáveis definidas no Octopus. 
2. No script Powershell, aceitámos as variáveis do Octopus recebidas e atribuímo-las a variáveis do Powershell. 
3. Quando utilizámos o comando Newman no script Powershell, enviámos as variáveis do script para o ambiente do Postman.
4. O Newman utilizou as variáveis enviadas no script Powershell, combinadas com as variáveis do ambiente do Postman, para executar a coleção do Postman.

Com os nossos testes rápidos de API a serem executados no Octopus para cada API e em todos os ambientes, podemos ter a certeza de que quaisquer problemas graves numa implementação de API serão detetados imediatamente. Além disso, podemos testar em ambientes de Produção mesmo quando não temos acesso a chaves de API sensíveis. A automatização dos testes rápidos de implementação permite-nos dedicar-nos a outros tipos de testes, como testes exploratórios manuais e testes de segurança, bem como escrever mais automação de testes para regressões noturnas. 

Para obter mais guias práticos, subscreva a newsletter do The QA Lead.

Continue a aprender e ouça este podcast: COMO O SOFTWARE DE CÓDIGO ABERTO SIMPLIFICA A INTEGRAÇÃO NA ENGENHARIA DE AUTOMAÇÃO (COM JAMES WALKER E SANJAY KUMAR)