Como verificar a cobertura de testes de APIs REST

Nayara Crema
Dec 17, 2020 · 6 min read
Software Quality Assurance.

Algumas vezes, no projeto em que estamos inseridos na empresa, precisamos passar para o time uma clareza sobre o que está sendo implementado nos testes automatizados de API REST ou quanto da API está coberta pelos testes.

Existe uma forma de calcular a cobertura de testes, que se baseia nos critérios de cobertura de entrada (Input Coverage) e cobertura de saída (Output Coverage).

Neste artigo vou te mostrar como é realizado o cálculo da cobertura de testes de uma forma simples e objetiva, assim você poderá calcular a cobertura de seus testes, caso ache necessário.

Em seguida, passarei por alguns critérios para explicar como calcular sua cobertura.

Path Coverage (input)

Verifica a cobertura da suíte de testes de acordo com os endpoints que a API possui. Este critério é importante, pois ao receber uma solicitação, o programa pode executar caminhos diferentes, então precisamos garantir que os endpoints da API REST estão cobertos pelos testes.

A análise é realizada pela quantidade de URI( URL + URN (Resource name)) que a API possui (se for a mesma URI para métodos diferentes, considera-se apenas um).

O ideal é realizar ao menos uma requisição para verificar cada endpoint.

Se verificar a imagem do swagger abaixo, podemos notar 13 endpoints diferentes:

A imagem mostra um swagger e a contagem dos endpoints que não se repetem.
A imagem mostra um swagger e a contagem dos endpoints que não se repetem.
Figura 1: Endpoints da API. Fonte: Swagger UI

Suponha que a automação desta API tenha apenas 6 desses endpoints implementados, mas a API possui 13 endpoints.

Para calcular a cobertura: quantidade de testes automatizados / quantidade de endpoints na API REST.

Exemplo do calculo de cobertura: 6 divido por 13 é igual a 0,46 que seria igual a 46 porcento.
Exemplo do calculo de cobertura: 6 divido por 13 é igual a 0,46 que seria igual a 46 porcento.
Figura 2: Cálculo path coverage

Então 46% dos testes de path estão cobertos pela automação.

Operator Coverage (input)

Confere a cobertura de testes de todos os métodos existentes na API REST (GET, POST, PUT, DELETE…).

O swagger abaixo tem um total de 19 operações:

A imagem mostra um swagger com vários métodos POST, GET, PUT e DELETE.
A imagem mostra um swagger com vários métodos POST, GET, PUT e DELETE.
Figura 3: Operações da API. Fonte: Swagger UI

Então, deve-se verificar quais métodos da API foram cobertos pela automação de testes. Vamos supor que dezesseis métodos tiveram testes automatizados implementados.

Para calcular a cobertura: quantidade de operações da API estão automatizados/ quantidade total de operações da API REST.

Figura 4: Cálculo operator coverage

Então temos 84% dos testes de operações cobertos.

Parameter Coverage (input)

Verifica a cobertura de uma suíte de testes conforme os parâmetros existentes em cada método da API.

A imagem mostra os parametros query de um método GET.
A imagem mostra os parametros query de um método GET.
Figura 5: Parâmetros método GET. Fonte: Swagger UI
A imagem mostra um parametro body do método POST
A imagem mostra um parametro body do método POST
Figura 6: Parâmetro método POST. Fonte: Swagger UI
A imagem mostra o parametro api_key no headers e o parametro path no método DELETE.
A imagem mostra o parametro api_key no headers e o parametro path no método DELETE.
Figura 7: Parâmetros no método DELETE. Fonte: Swagger UI

Para calcular a cobertura:

Para atingir 100% de cobertura de testes é necessário testar todos os parâmetros de entrada de cada operação pelo menos uma vez. Realizar a combinação de todos os parâmetros é desejável, mas não estritamente necessário para chegar a 100% de cobertura.

Suponha que a API tenha um total de 5 parâmetros, e na automação da API os 5 parâmetros foram cobertos.

Quantidade total de parâmetros cobertos na suítes de testes / quantidade total de parâmetros nos métodos da API.

A imagem mostra o exemplo do calculo de cobertura. Cinco divido por cinco é igual a 1, que é igual a cem por cento.
A imagem mostra o exemplo do calculo de cobertura. Cinco divido por cinco é igual a 1, que é igual a cem por cento.
Figura 8: Cálculo parameter coverage

Parameter Value Coverage (input)

Confere a cobertura da suíte de testes de parâmetros booleano e enum nas operações (se existirem).

Para calcular a cobertura:

Quantidade total de valores diferentes enviados / quantidade total de valores que podem assumir.

Para atingir 100% de cobertura cada parâmetro booleano e enum deve assumir todos os valores possíveis.

Content-Type Coverage (input e output)

Verifica a cobertura de testes automatizados onde o content-type está sendo exibido em cada endpoint, ou seja, se for demonstrado nas opções do content-type de envio application/json e um application/xml, então duas opções do parâmetros de envio deveriam ser cobertas.

A imagem mostra o combo-box do content-type com as opções application/json e application/xml, exibidos no swagger.
A imagem mostra o combo-box do content-type com as opções application/json e application/xml, exibidos no swagger.
Figura 9: Opções de content-type no swagger. Fonte: Swagger UI
A imagem monstra o content-type application-json, informado no headers da ferramenta postman.
A imagem monstra o content-type application-json, informado no headers da ferramenta postman.
Figura 10: Content-Type informando no teste. Fonte: Swagger UI

Também devem ser verificadas as opções do content-type da resposta:

A imagem mostra o combo-box do content-type com as opções application-json e application-xml em um response do swagger.
A imagem mostra o combo-box do content-type com as opções application-json e application-xml em um response do swagger.
Figura 11: Content-type no response. Fonte: Swagger UI

Para calcular a cobertura:

Quantidade total de content-type em cada operação cobertos pela suíte de testes / Quantidade total de content-type em todas as operações da API.

Suponha a API possua as operações POST, PUT, GET e DELETE. POST e PUT possuem cada um 2 opções de content-type, logo a API possui um total de 4 content-type a serem cobertos. A automação cobriu apenas uma opção, no POST e uma opção, no PUT. Sendo assim:

Exemplo de calculo de cobertura: 2 dividido por 4 é igual a 0,5, que corresponde a 50 porcento.
Exemplo de calculo de cobertura: 2 dividido por 4 é igual a 0,5, que corresponde a 50 porcento.
Figura 12: Cálculo content-type coverage

Operation Flow (input)

Este critério mede um conjunto de testes de acordo com as sequências de operações que é executado.

Por exemplo:

Fluxo1: Post-Get(id)

Fluxo2: Post-Put

Fluxo3: Post-Delete

Fluxo4: Post-Get(Query)

Se todos os fluxos estiverem implementados no teste automatizado, então a API Rest está 100% coberta pela automação.

Porém se é possível criar 4 tipos de fluxos, mas sua automação possui apenas um, por exemplo, criação (Post) e consulta (Get id), então terás apenas 25% de cobertura.

Exemplo calculo cobertura: 1 dividido por 4 é igual a 0,25 que corresponde a 25 porcento.
Exemplo calculo cobertura: 1 dividido por 4 é igual a 0,25 que corresponde a 25 porcento.
Figura 13: Cálculo operation flow

Response Properties Body Coverage (Output)

Este critério mede os parâmetros no corpo da resposta, então deve ser verificado se todas as propriedades da resposta estão cobertas pelo teste.

Para calcular a cobertura deve-se dividir o número total de todas as propriedades de todos os objetos que pode ser obtido na resposta da API, pelo número de propriedades da resposta que os testes estão cobrindo.

Status Code Coverage (Output)

Este critério verifica quais status codes existentes em cada endpoint estão cobertos pelos testes.

A imagem mostra um método do swagger que pode ter os status code 200, 400 e 404.
A imagem mostra um método do swagger que pode ter os status code 200, 400 e 404.
Figura 14: Status code. Fonte: Swagger UI

Suponha que a API tenha um total de 25 status code, e na automação da API apenas 15 status code foram cobertos.

Exemplo de calculo de cobertura: 15 dividido por 25 é igual a 0,6, que corresponde a 60 porcento.
Exemplo de calculo de cobertura: 15 dividido por 25 é igual a 0,6, que corresponde a 60 porcento.
Figura 15: Cálculo status code coverage

Portanto, para atingir 100% da cobertura de testes, todos os status codes de cada operação deve estar implementado nos testes.

Realizar o levantamento dos critérios de cobertura é importante, pois te dá um norte para saber o quão efetivo os testes automatizados estão sendo. Será que todos os paths da sua API estão cobertos? Será que não é possível atingir 100% de cobertura de parâmetros de entrada dos métodos? Comenta aí, o que você achou desta metodologia ou se você aplicaria e mostraria a cobertura de testes para o seu time.

Referências

Revista DTAR

Conteúdo produzido por alunos do DTAR, o Treinamento de Descomplicando Testes de API Rest

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store