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.

[adrotate banner=”4″]
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.

[adrotate banner=”5″]

Leia também:

Bot Para testes: Como executar.

Testes automatizados com adonis JS.