Heurísticas de API para software de qualidade

No campo do desenvolvimento de software, o processo de teste de API tem um papel crucial para garantir que as aplicações funcionem corretamente e se integrem sem atrito a outros sistemas.

O processo de teste é crucial para validar a funcionalidade, a confiabilidade, o desempenho e a segurança das APIs. Dentro desse processo, o uso de uma ferramenta de teste de API, ou de várias ferramentas de teste de API, é valioso para alcançar uma cobertura de teste abrangente. Além disso, a adoção da automação de testes de API (também conhecida como teste de automação de API) pode aumentar de forma significativa a eficiência do processo de teste.

Fazer uma avaliação abrangente das funcionalidades de uma API pode ser desafiador, sobretudo quando os prazos apertam. Nesse ponto, as heurísticas para teste de Application Programming Interface se tornam uma ferramenta valiosa.

Mas o que são heurísticas? Podem ser definidas como princípios ou estratégias que a equipe de teste usa para analisar com eficácia a qualidade de uma API. Em vez de seguir procedimentos rígidos e detalhados, as heurísticas oferecem uma abordagem mais ágil e flexível. Isso dá à equipe de teste a capacidade de identificar problemas rápido e tomar decisões informadas.

Vantagens das heurísticas para teste de API¶

Eficiência na detecção de problemas¶

As heurísticas permitem que a equipe de teste identifique rápido as áreas problemáticas de uma API. Ao usar princípios e estratégias específicos, a equipe de teste pode concentrar o esforço nas áreas mais críticas, e economizar tempo e recursos valiosos.

Flexibilidade e adaptabilidade¶

Heurísticas não são regras rígidas, e sim estratégias flexíveis. Isso permite que os testadores se adaptem com facilidade a contextos variados e a requisitos específicos do projeto. Além disso, as heurísticas podem ser ajustadas e melhoradas com o tempo, o que resulta num processo de teste mais eficaz e ágil.

Cobertura abrangente¶

Ao usar heurísticas específicas, a equipe de teste pode garantir que avalia aspectos diferentes da API, como a resposta a vários tipos de pedido, e a segurança. Isso permite uma cobertura abrangente e ajuda a identificar lacunas na funcionalidade da API.

Para conduzir testes de API de forma eficaz em geral, e também testes de carga de API, é essencial entender os vários tipos de teste de API, como teste de carga, teste automatizado, teste funcional e teste de segurança. Usar uma variedade de ferramentas de teste de API pode facilitar um processo de teste completo, o que permite que os testadores executem testes de API em cenários diferentes e garantam que ela funcione como esperado.

Heurísticas conhecidas¶

Aqui apresentamos algumas das heurísticas disponíveis que usamos no dia a dia, para elevar a qualidade do teste de API. Muitas delas compartilham pontos em comum. Ainda assim, cada projeto e cada contexto são únicos, o que torna essencial adaptar e ajustar essas heurísticas segundo as necessidades específicas.

1. VADER¶

Criada por Stuart Ashman, a VADER oferece um framework estruturado para avaliar aspectos diferentes de uma API, do uso correto dos verbos HTTP à eficiência da gestão de erros e à capacidade de resposta.

Verbos¶

Este aspecto envolve avaliar se os verbos HTTP estão sendo usados de forma adequada. É crucial entender as regras de negócio da API que você está avaliando.

Verbos HTTP e as suas características¶

Vamos recordar os principais verbos HTTP e as suas características:

• POST: em geral usado para registrar informação nova.
• GET: usado para recuperar informação. Pode ser uma listagem ou uma entidade específica filtrada por algum identificador, conforme o produto em teste.
• DELETE: usado para apagar registros, mas é importante saber se a exclusão é lógica (fica inativa) ou física (apagada por completo).
• PUT: em geral usado para atualizar toda a informação de uma entidade.
• PATCH: parecido com o PUT, mas usado para atualizar só uma parte de uma entidade.

Autorização ou autenticação:¶

Este ponto se refere a verificar a implementação correta dos mecanismos de autorização e de autenticação. Isso inclui garantir que os pedidos estejam protegidos de forma adequada e que credenciais válidas sejam exigidas para acessar certos recursos.

É importante diferenciar que a autenticação trata de determinar quem você é. Você pode se autenticar desde que o sistema reconheça que você está cadastrado. A autorização determina quais recursos você pode acessar.

Dados¶

Aqui se examinam a integridade e a precisão dos dados geridos pela API. O foco é garantir que a informação seja armazenada, processada e transmitida corretamente, segundo as regras de negócio estabelecidas, revisando tipos ou estruturas de dados permitidos, valores permitidos, máximos e mínimos permitidos, e estruturas.

Erros¶

Este ponto envolve checar como a API trata erros. Isso significa avaliar os códigos de status HTTP devolvidos em situações de erro, assim como a clareza e a utilidade das mensagens de erro fornecidas.

Ao entender as regras de negócio, podemos usar conjuntos de dados que sabemos que deveriam causar um erro, ou enviar pedidos malformados, e avaliar se esse erro está sendo tratado de forma adequada, se um código de erro e uma mensagem adequada àquela circunstância são devolvidos. Por exemplo, devolver códigos de erro 500 é uma má prática.

Capacidade de resposta¶

Este último ponto avalia a velocidade e a eficiência da API em termos de tempo de resposta. Garante que a API seja rápida o bastante para atender aos requisitos de desempenho do sistema.

2. POISED¶

Esta heurística foi desenvolvida por Amber Race e é um acrônimo que representa seis áreas-chave a considerar para garantir a qualidade e a robustez do sistema.

Parâmetros¶

Refere-se à avaliação dos parâmetros de cada operação da API sob teste. Em essência, envolve experimentar com os dados, passar parâmetros vazios ou aleatórios, modificar os tipos de dados permitidos etc. Além disso, verifique se o servidor responde de forma adequada.

Saída¶

O objetivo é corroborar que a resposta do servidor é a esperada. A experimentação pode ser tão extensa quanto as regras de negócio permitirem, enviando pedidos cujas saídas deveriam ser alguma mensagem específica segundo a regra de negócio e validando que ela atende aos requisitos especificados.

Por exemplo: se o cadastro de um usuário só é permitido quando a pessoa é maior de idade, enviar dados de um menor deve resultar numa mensagem esperada como: “o usuário não pode ser menor de idade”.

Interoperabilidade¶

Considera a capacidade do sistema de interoperar com outros sistemas ou componentes. Trata de avaliar se o sistema consegue se comunicar com eficácia com outros sistemas, serviços ou dispositivos.

Nem sempre será necessário. Entender o propósito da API, em quais outros sistemas ela precisa se integrar, ou quem vai precisar usá-la, é vital. Nesse sentido, é uma boa oportunidade para avaliar se a documentação é boa e compreensível para quem desenvolve e precisa integrar um sistema com a nossa API sob teste.

Segurança¶

Foca na segurança do sistema. Além de autenticação e autorização, sugere ir um passo além e avaliar outros aspectos de segurança, como criptografia de dados e a identificação de vulnerabilidades potenciais. Por exemplo: checar se é possível enviar e armazenar código JavaScript por meio de um POST.

Tratamento de erros¶

Parecido com a VADER, aqui se examina o tratamento de situações de erro do sistema. De novo, precisamos focar em casos de teste negativos e forçar todos os tipos de erro em que conseguirmos pensar, como não enviar campos obrigatórios, brincar com valores de fronteira ou usar tipos de dados não permitidos dentro do que as especificações nos dizem.

É importante dar feedback sobre como o servidor está comunicando os erros, se as mensagens são claras.

Dados¶

Isso abrange a integridade dos dados e a forma como eles são armazenados, recuperados e processados. Por exemplo: se os dados armazenados por um POST são obtidos corretamente por um GET, e se a exclusão dos dados deve ser permanente ou é uma exclusão lógica. Acessar bancos de dados pode ser uma boa ideia para complementar esse tipo de teste.

3. TATTA¶

Mark Winteringham, autor do livro Testing Web APIs, distingue entre “testar a API” e “testar por meio da API”. As duas abordagens envolvem avaliar o funcionamento de um serviço web, mas focam em aspectos diferentes do processo de teste.

Testar a API¶

• Verificar se um serviço web de terceiros está acessível.
• Checar se o serviço web atende às expectativas e está operacional.
• Avaliar se o serviço web devolve os resultados esperados.

Testar por meio da API¶

• Observar o comportamento do serviço web.
• Avaliar como o serviço web processa dados e os transforma para devolver resultados.
• Verificar a estrutura correta dos registros devolvidos pelo serviço web.
• Avaliar como o serviço web trata situações como estouro de dados (por exemplo, um inteiro grande demais).
• Confirmar se ocorre um redirecionamento depois de um pedido não autorizado.

A abordagem escolhida pode depender de fatores diferentes, como as ferramentas usadas e os propósitos específicos do teste.

4. LHTRAFFIC¶

Criada por Karol Szewczak, a LHTRAFFIC deriva de left-hand traffic e oferece um framework abrangente para avaliar aspectos críticos de segurança e funcionalidade no desenho, no desenvolvimento e no teste de APIs. Essa abordagem trata de problemas que vão de possíveis vazamentos de informação a injeção e manipulação de dados.

APIs que vazam¶

Refere-se a APIs que podem estar revelando informação que não deveriam. É importante inspecionar os dados transmitidos pela rede, avaliar se os usuários da API realmente precisam de toda aquela informação e se dados sensíveis que não deveriam ser expostos estão sendo enviados. Também envolve revisar os cabeçalhos de resposta para garantir que eles não revelem detalhes sobre os frameworks de base.

APIs ocultas¶

Refere-se a APIs que a equipe de desenvolvimento não achou que as pessoas encontrariam, mas que estão visíveis de várias formas. Isso envolve checar se um arquivo “robots.txt” é fornecido para impedir que crawlers acessem recursos importantes, evitar a exposição de endpoints de administrador e revisar a documentação automática, como o Swagger, para garantir que ela não revele informação sensível ou APIs privadas.

Adulteração de pedidos ou respostas¶

Estuda onde é feita a validação dos parâmetros enviados com os pedidos da API. Alerta sobre a possibilidade de manipulação de dados por um atacante intermediário ou um proxy. Isso significa que, se houver um sistema web ou mobile integrado à nossa API, as validações não podem ficar só do lado da interface de usuário (frontend). O nosso backend precisa ter o código defensivo necessário para mitigar possíveis envios de parâmetros inadequados.

Autorização ou autenticação¶

Foca na autorização e na autenticação da API. Como mencionado aqui, é importante saber que, com um conjunto de credenciais (corretas ou incorretas), uma pessoa pode se autenticar ou não. E, se conseguir, precisamos testar quais recursos ela pode acessar.

É uma oportunidade para entender bem o sistema, garantir que ele esteja bem documentado e responder a perguntas diferentes. Por exemplo: quais tipos de autorização são suportados, se é possível contorná-los (por exemplo, não passar um token nos pedidos), como os erros de autenticação são tratados, se as credenciais são enviadas de forma segura e se é possível fazer enumeração de usuários, entre outras considerações.

Fuzzing¶

Recomenda conduzir “fuzz testing” na API usando dados malformados ou inesperados para detectar vulnerabilidades potenciais. Isso envolve testar com tipos diferentes de dados, como números ou strings, e usar ferramentas como a “Big List of Naughty Strings”. É uma lista em evolução constante de strings de caracteres com alta probabilidade de causar problemas quando usadas como dados de entrada do usuário.

Esquecido¶

Explora a possível presença de cabeçalhos padrão que podem ter sido deixados habilitados por acidente. Também enfatiza a importância de desabilitar a documentação automática, como o Swagger, em ambientes de produção, se ela foi pensada no início só para o ambiente de desenvolvimento.

Injeções¶

Refere-se à busca por possíveis injeções, como as conhecidas injeções de SQL, e avalia pontos de injeção diferentes, inclusive cabeçalhos, parâmetros e o corpo do pedido.

Content-type¶

Examina se o cabeçalho Content-type está alinhado ao tipo MIME enviado. Também estuda como a aplicação responde quando se envia um tipo de conteúdo não suportado e se a API suporta vários tipos de conteúdo.

ICEOVERMAD¶

Criada por Ash Winter, ela não só busca contemplar aspectos funcionais da API, como também aspectos ligados ao desempenho e à arquitetura do sistema.

Integração¶

Busca avaliar como os consumidores vão se integrar ao serviço, quando vão fazer isso e se a intenção é renderizar num navegador, gerar num arquivo ou usar outro método de consumo.

Consumidores¶

Busca identificar quem serão os consumidores do serviço, se humanos ou máquinas, e entender qual problema o serviço resolve para cada consumidor.

Endpoints¶

Envolve analisar a forma do endpoint e como ele é acessado, se é um único endpoint, vários endpoints ou se passa por um balanceador de carga. Avalia o nível de segurança aplicado.

Operações¶

Foca em identificar as funções de negócio executadas pelo serviço, se elas podem ser atribuídas a funções atuais executadas por uma interface de usuário, se as operações têm nomes descritivos e são legíveis para humanos e máquinas, e se tratam dados sensíveis.

Volume¶

Envolve avaliar se o serviço será usado em alto volume de forma concorrente ou de forma esporádica, com pedidos únicos de alto valor, se o tamanho das transações individuais é um problema, como as sessões de API são geridas e se a arquitetura alvo é em cluster.

Tratamento de erros¶

Envolve analisar como o serviço trata erros no lado do servidor e no lado do cliente, se os erros são informativos e/ou detalhados, e como se gere a perda de conectividade com o banco de dados.

RESTful¶

Consiste em avaliar se o serviço tem as características de um serviço RESTful e determinar se isso é desejável no contexto específico.

Modularidade¶

Refere-se a analisar como os componentes do serviço estão distribuídos, como interagem, se podem existir de forma independente e se podem falhar entre si.

Autenticação¶

Envolve investigar como as pessoas se autenticam dentro do serviço, quais permissões se aplicam e como isso muda a operação do serviço, quais níveis de segurança são usados e se os dados são enviados ou recebidos criptografados.

Definições¶

Trata de determinar o que define as entradas e as saídas do serviço, se se usa WSDL, WADL, XSD, XSLT ou outro método, quais limites isso impõe ao serviço e quais métodos HTTP são usados e com que propósito.

BINMEN¶

Esta é uma heurística criada por Gwen Diagram e Ash Winter. É uma heurística simples que foca em verificar o tratamento de erros do servidor, como outras heurísticas, mas se divide em pontos específicos para induzir ou forçar esses comportamentos.

Fronteira¶

O teste de fronteira, ou “Boundary”, refere-se a testar a API com valores que estão nos limites do que a API deveria tratar. Isso pode envolver testar a API com os valores máximo e mínimo possíveis, e também com valores um pouco acima e abaixo desses limites.

Entradas inválidas¶

Entradas inválidas consistem em testes em que se usam entradas que não deveriam ser aceitas pela API. São conduzidos para garantir que a API trate entradas inválidas de forma adequada, seja devolvendo um erro de maneira controlada, seja ignorando-as.

Nulos¶

Em “NULL”, enviam-se valores à API para garantir que ela consiga tratar esses valores de forma adequada. Algumas APIs podem ter problemas ao tratar valores nulos, o que pode levar a erros inesperados.

Método¶

No teste de “Method”, o objetivo é verificar que cada um dos métodos da API opere segundo a documentação, de forma consistente e previsível. Isso pode incluir testes para os métodos GET, POST, PUT, DELETE etc.

Vazio¶

Parecido com o teste de “NULL”, os testes de “Empty” envolvem enviar valores vazios à API. Isso pode ajudar a identificar problemas que surgem quando a API recebe uma entrada vazia.

Negativos¶

O teste negativo envolve enviar à API entradas que não são válidas ou que se sabe que causam um erro. O objetivo desses testes é garantir que a API consiga tratar esses erros de forma adequada e não falhe nem pare de funcionar.

Fechamento¶

As heurísticas acima cobrem de forma abrangente os aspectos críticos do teste de API. Porém, cada heurística tem os seus pontos fortes e o seu foco.

Podemos pegar os pontos em comum, combinar pontos relevantes de cada uma e acrescentar outros aspectos que consideramos importantes com base na nossa experiência, para gerar um framework mais completo e diverso.

A seguir, propomos outra heurística que abrange os principais aspectos nos quais é importante enfatizar, um resumo e um exemplo do que recomendamos considerar em cada ponto:

HEURÍSTICA BADVIPERS¶

Com BAD-VIPERS, as equipes de teste poderiam tratar aspectos funcionais, segurança, desempenho e aspectos ligados à integração da API e à sua documentação, e assim oferecer uma visão mais holística e integral do teste de API.

Para explicar a heurística passo a passo e mostrar alguns exemplos, vamos considerar uma operação POST num certo endpoint, responsável por criar um usuário novo no banco de dados, com base nos valores enviados no corpo da mensagem, com dados básicos de uma pessoa ou de um usuário do sistema:

VIPERS

Verbos¶

Este aspecto foca em avaliar se os verbos HTTP estão sendo usados de forma adequada.

Exemplo: garantir que um POST no endpoint de usuários /api/users crie um usuário novo, enquanto um GET recupera um usuário ou uma lista de usuários. Um erro comum seria permitir a criação de usuário com um GET, o que é incorreto, porque viola os princípios RESTful.

Este aspecto se refere a avaliar se os verbos HTTP estão sendo usados de forma adequada.

Integração¶

Este aspecto avalia a capacidade da API de interagir com eficácia com outros sistemas ou componentes. Envolve determinar se a API consegue se comunicar com eficiência com outros sistemas, serviços ou dispositivos, com base no seu propósito e nas necessidades do usuário.

Exemplo: ao integrar o endpoint de usuários /api/users com /api/login, confirme que, depois de criar um usuário com POST, ele possa se autenticar pelo endpoint de login, e que as duas APIs funcionem juntas de forma coerente.

Parâmetros¶

Isso envolve experimentar com dados, passar parâmetros vazios ou aleatórios, modificar os tipos de dados permitidos etc., e verificar se o servidor responde de forma adequada. Você pode usar técnicas como fuzzing com dados malformados ou inesperados para detectar vulnerabilidades potenciais.

Exemplo: envie um pedido POST para o endpoint de usuários /api/users com um corpo como:

{

"username": "",

"email": "[email protected]",

"password": "12345"

}

Para checar que o servidor trata parâmetros vazios de forma adequada e devolve um erro específico para o nome de usuário ausente.

Tratamento de erros¶

O tratamento de erros da API é examinado ao avaliar códigos de status HTTP em situações de erro e a clareza das mensagens de erro. Isso envolve induzir erros, como omitir campos obrigatórios ou usar dados não permitidos, e examinar se uma mensagem adequada é devolvida.

É essencial analisar como se gere a perda de conectividade com o banco de dados e como os erros são tratados tanto no lado do cliente quanto no lado do servidor.

Exemplo: omita o campo de e-mail num pedido POST para o endpoint de usuários /api/users e espere um 400 Bad Request com uma mensagem explicativa como {"error": "O campo email é obrigatório"}.

Capacidade de resposta¶

Um aspecto não funcional importante de desempenho é avaliar a velocidade e a eficiência da API em termos de tempo de resposta. Garanta que a API seja rápida o bastante para atender aos requisitos de desempenho do sistema.

Exemplo: meça o tempo de resposta de um GET para o endpoint de usuários /api/users. Se levar mais de 500 ms para receber uma resposta, você deve investigar a eficiência do endpoint e otimizá-lo. Os resultados podem sugerir a necessidade de teste de desempenho.

Segurança¶

A segurança em APIs envolve explorar APIs privadas ou não documentadas e checar se há dados potencialmente sensíveis na API. A presença de informação confidencial na URL traz riscos significativos.

APIs privadas exigem medidas de segurança para limitar o acesso. É crucial determinar o uso de SSL para permitir a transmissão segura de dados.

Você deve proteger a API para mitigar ameaças como ataques XSS. Além de autenticação e autorização, é essencial avaliar a criptografia de dados e detectar vulnerabilidades potenciais, como a possibilidade de enviar código JavaScript por meio de um POST.

Exemplo: teste o endpoint de usuários /api/users enviando um pedido POST com um payload que inclua um script malicioso no campo de nome de usuário, para garantir que a API esteja protegida contra ataques XSS.

BAD

Comportamento¶

É importante entender o comportamento esperado da API em termos gerais, entender o negócio e elaborar um plano de teste que priorize os aspectos mais críticos.

É crucial prestar atenção às respostas do servidor. O nosso objetivo é confirmar que essas respostas estejam alinhadas ao que antecipamos. Ao elaborar pedidos com base nas regras de negócio, podemos fazer um teste detalhado para obter mensagens específicas do servidor. Desse jeito, verificamos que essas mensagens atendam aos requisitos estabelecidos.

Exemplo: faça um pedido POST para criar usuários em /api/users com dados corretos e confira se o servidor devolve a saída esperada, por exemplo uma mensagem de sucesso com o ID do usuário criado.

Autenticação¶

A autenticação no teste de API foca em verificar se os mecanismos de identificação estão implementados corretamente. Os pedidos precisam estar suficientemente protegidos e exigir credenciais válidas para o acesso.

Esse processo de autenticação permite determinar a identidade do usuário, o que faz o sistema reconhecer só usuários cadastrados. Além disso, é necessário analisar e testar como os erros de autenticação são tratados, como os dados são transmitidos de forma segura e como as sessões de usuário são geridas.

Exemplo: tente fazer um pedido GET para a área de usuários /api/users/private sem incluir um token de autenticação, para verificar que o sistema rejeita o pedido corretamente e devolve um 401 Unauthorized.

O teste de API em termos de autorização foca em checar os acessos permitidos aos usuários. Esse processo é crucial para determinar quais recursos um usuário autenticado pode acessar. Inclui entender quais tipos de autorização são suportados e testar situações em que se tenta contornar a autorização.

Exemplo: tente atualizar a informação de um usuário com PUT para o recurso de usuários /api/users/{id}, sem as permissões adequadas, para checar que a API restringe o acesso e devolve um 403 Forbidden.

Documentação¶

No nosso papel, é importante validar a documentação do que testamos e determinar se ela é fácil de acessar, clara e organizada. Essa revisão busca garantir que a informação necessária seja localizável com eficiência, coerente, e inclua exemplos que ajudem a detalhar a funcionalidade da API.

Exemplo: confirme que a documentação de /api/users, o endpoint de usuários, detalhe com clareza como fazer pedidos e quais respostas esperar, inclusive exemplos de pedidos e de erros potenciais.

Conclusão¶

No conjunto, o mercado global de teste de API exige adaptação e aprimoramento contínuos das estratégias de teste.

Ao adotar uma mistura dessas heurísticas e usar as ferramentas mais recentes de teste de API, as equipes de teste podem impulsionar as suas APIs para entregar o desempenho, a segurança e a confiabilidade esperados, e assim atender aos altos padrões exigidos no mundo digital de hoje.