Blog

POISED Testing: o que é e como utilizar?

A imagem mostra uma sala com pessoas desenvolvedoras utilizando o POISED Testing.
Desenvolvimento / Desenvolvimento de Software / Programação / QA

POISED Testing: o que é e como utilizar?

Já ouviu falar sobre modelos heurísticos? Resumidamente, são métodos que nos ajudam a entender e lembrar de algo rapidamente, como atalhos mentais. Por isso, no caso do tema que vamos falar hoje: POISED Testing, esses modelos irão ajudar muito!

O método heurístico de representatividade é utilizado como base para criar e pensar nossos testes de API.


O que é POISED?

Primeiramente, vamos dar uma olhada no que isso significa e como pode nos ajudar de fato! O significado das siglas de POISED Testing é:

  • P – Parameters (Parâmetros);
  • O – Outputs (Saídas);
  • I – Interoperability (Interoperabilidade);
  • S – Security (Segurança);
  • E – Errors (Erros);
  • D – Data (Dados).

O que cada uma dessas etapas significa?

Bom, visto que agora sabemos o que cada uma das letras de POISED Testing representa, vamos entender melhor a função de cada uma.

Parameters (Parâmetros)

Esta é a etapa em que você cria seus testes baseados nos parâmetros que a API a ser testada pode enviar. Isso pode funcionar tanto nos headers, parâmetros de URL e parâmetros no envio de dados, como o body de uma request com método POST.

Por exemplo:  

  • Uma URL aceita ser enviado um header com um tipo de “content-type” x ,y,z e você envia um tipo não aceito;
  • Uma URL precisa de um header específico para saber para qual parte da aplicação enviar e você não passa nesse header obrigatório;
  • Um body de um request POST, para fazer um login num portal, precisa de campos obrigatórios e tipados por exemplo:
   		 {
	“email”: “” ,
	"password": 12345678
 }

Aqui você deveria ter passado um e-mail válido e passou uma string vazia. Além disso, na senha, deveria ter sido uma string e você passou um numérico qualquer.

Podemos ficar horas vendo tipos de parâmetros. Entretanto, com esses básicos já dá para entender e ir mais além do que seria o P desse modelo!

Outputs (Saídas)

Essa etapa será onde você criará seus testes baseados nas respostas das requests, validará se são coerentes, se estão corretas de acordo com o tipo de request e o status code recebido (response body x status code), logs feitos no console ou no servidor.

Por exemplo:

  • Você envia uma requisição do método DELETE e recebeu status code 200 ou 204, mas no corpo da resposta recebeu “criado”;
  • Você envia uma requisição do método POST e recebe um status code 200 e com o corpo da resposta vazio;
  • Validar se os logs apresentados no console ou servidor são coerentes ou se possui o mínimo de informação relacionada.

Em tese, o Output é onde você cria seus testes para validar a coerência das respostas X o que foi requisitado.

Interoperability (Interoperabilidade)

Aqui é uma etapa muito importante, em que você cria testes para validar e checar a Interoperabilidade da comunicação das APIs, onde você cria testes de contrato, checa a idempotência da API, entre outros.

Além disso, nesta etapa, também pode ser pensado e criado testes de performance para entender qual a performance da sua API, quando muito exigida ou chamada por outros serviços ou outras APIs.

Por exemplo:

  • Criar teste de contrato para, sempre que uma API precise, chamar os requisitos básicos e predefinidos como corretos, sendo atendidos e validados em seu comportamento. Por exemplo, o que uma API espera de parâmetros no body? Quais os tipos desses parâmetros? Quais as saídas? É importante não confundir com o teste de schema, onde é validado somente os tipos do schema.
  • Validar a idempotência da API. Verificar se, mesmo ela sendo chamada n* x vezes por outra API ou outras, aquele comportamento esperado continua sendo o mesmo sempre.
  • Criar testes de performance para latência e/ou saber o tempo de resposta de cada request depois de ter sido carregada com muitas requests.

Security (Segurança)

Uma das partes mais importantes do nosso modelo é criar testes e pensar estratégias de teste para cobrir possíveis cenários ou gaps de segurança na API. Por exemplo:

  • Validar que, somente com informações corretas, você consegue chamar com sucesso os endpoints que precisam de autorização e autenticação, como tokens, cookies ou até mesmo senhas;
  • Autenticar tempo de expiração das credenciais;
  • Validar se é possível, por exemplo, ao invés de mandar a autenticação correta, você consegue mandar algum script de JavaScript no campo;
  • Confirmar possíveis mensagens de respostas que contenham mais informação que o necessário ou logs que contenham informações internas, como logar o erro do banco de dados diretamente.

Errors (Erros)

Nesta etapa, podemos pensar sobre como validar as mensagens de erro (já vimos um pouco sobre isso nos tópicos Outputs e Security). Por exemplo:

  • Pensar se estão de acordo com o contexto, requisição, ambiente e etc.;
  • Verificar as mensagens de erro X o status code da resposta;
  • Verificar se nos passam o real problema que aconteceu (pensando sempre na segurança, como dito acima).

Data (Dados)

Nesta fase, pensamos como validar os dados. Por exemplo:

  • Validar as estruturas dos dados das requests, no body ou parâmetros;
  • Validar os dados quando executamos alguma requisição que altere dados. Por exemplo, quando fazemos um delete, update ou created. Os dados foram corretamente atualizados ou deletados? Após as alterações, a estrutura continua a mesma? E por aí vai…

Pensando nisso, é importante lembrar:

  • Precisamos sempre ter contato e conhecimento do código base para poder criar os testes com mais precisão e sempre com base na documentação;
  • Além disso, é preciso checar também os testes unitários, para não cairmos no problema testes duplicados em camadas diferentes.

Conclusão

Passamos por um overview sobre o POISED Testing, para nos dar ideias e nos guiar quando pensarmos sobre criação de testes de API. Como falamos acima, este é um modelo heurístico que usamos para apoio.

Existem alguns outros modelos interessantes, segue aqui uma lista para você checar, se tiver interesse!

  • VADER
  • BINMEN

Autor: Francisco Antônio Navarro Moral.

Leia também:

Bot Para testes: Como executar.

Testes automatizados com adonis JS.

Select the fields to be shown. Others will be hidden. Drag and drop to rearrange the order.
  • Image
  • SKU
  • Rating
  • Price
  • Stock
  • Availability
  • Add to cart
  • Description
  • Content
  • Weight
  • Dimensions
  • Additional information
  • Attributes
  • Custom attributes
  • Custom fields
Click outside to hide the comparison bar
Compare