CatSuite
Como testar APIs no Android com o Repetir do CatSuite
Use uma request válida, compare respostas A/B e investigue autenticação, autorização e contrato com um cenário fictício de pedidos.
O módulo Repetir do CatSuite permite testar uma API no Android editando uma request e comparando as respostas de envios controlados. O ponto de partida mais útil é uma chamada válida, capturada na aplicação. Preserve essa referência, mude uma variável por vez e confira o efeito no corpo da resposta, nos headers e no estado real do sistema.
Guia publicado em 6 de outubro de 2026. A capa é uma ilustração conceitual original, não uma captura do aplicativo nem evidência de teste.
Esse procedimento atende a QA, depuração de integração e investigação de autorização. Ele evita depender apenas de screenshots ou da interface de uma aplicação para explicar um problema. Conheça o aplicativo na visão geral do CatSuite e consulte a referência completa do Repetir para os controles da sua versão.
Por que uma request válida é a melhor referência
Uma chamada que já funciona reúne destino, formato do corpo, headers e contexto de autenticação coerentes. Se você começar removendo vários desses elementos ao mesmo tempo, uma falha pode decorrer de sessão expirada, formato inválido, regra de negócio ou autorização. Sem uma referência, fica difícil separar essas causas.
Capture uma ação simples no Navegador ou no Proxy de Rede e envie a mensagem ao Repetir. Confira protocolo, host, porta e método antes de enviar. Se precisa configurar a captura, siga o guia de interceptação HTTP e HTTPS no Android.
Um cenário fictício de pedidos
Imagine uma loja de laboratório com duas contas de clientes, Ana e Bruno. O pedido pedido-101 pertence a Ana; pedido-202 pertence a Bruno. As contas e os objetos foram preparados para o teste. A request abaixo é didática e só deve ser enviada a um ambiente seu que implemente esse cenário.
GET /api/pedidos/pedido-101 HTTP/1.1
Host: api.aurora.test
Accept: application/json
Authorization: Bearer TOKEN_ANA_LABPrimeiro confirme que Ana consegue ler seu próprio pedido. Uma resposta de referência pode conter identificador, titular e itens. Esses dados são fictícios; não são uma saída obtida em um serviço real.
{
"id": "pedido-101",
"titular": "ana-lab",
"itens": [{"sku": "produto-ficticio", "quantidade": 1}]
}Se a referência falha, pare e corrija o contexto. Testes de autorização feitos com uma credencial já inválida produzem conclusões ruins: um 401 generalizado não demonstra que cada regra de acesso foi aplicada.
Monte uma matriz pequena de comparação
| Caso | Credencial | Objeto | Questão investigada |
|---|---|---|---|
| A | Ana | Pedido de Ana | A chamada válida funciona? |
| B | Bruno | Pedido de Bruno | A segunda conta e seus dados estão corretos? |
| C | Ana | Pedido de Bruno | O servidor aplica autorização ao objeto? |
| D | Sem credencial | Pedido de Ana | O endpoint exige autenticação? |
| E | Ana | Objeto inexistente de laboratório | Como a API diferencia inexistência e acesso recusado? |
As respostas esperadas dependem do contrato da API. Uma aplicação pode responder 403 a acesso recusado ou usar 404 para não revelar a existência de um recurso. Em ambos os casos, verifique se dados e ações indevidos foram bloqueados. Não imponha um status universal a sistemas com políticas diferentes.
A classificação Broken Object Level Authorization da OWASP trata da autorização aplicada aos objetos acessados por uma API. No laboratório, a confirmação exige observar acesso indevido ao objeto preparado para outra conta; a simples presença de um identificador na URL é apenas uma hipótese.
Como usar a comparação A/B no Repetir
- Envie a request válida e confirme a response correspondente.
- Guarde a resposta de referência na comparação A/B.
- Altere um único elemento, por exemplo o identificador do pedido.
- Reenvie e confira se o editor, o destino e a credencial continuam corretos.
- Compare status, headers e campos relevantes do corpo.
- Anote a variável alterada, o resultado observado e a interpretação.
- Repita a chamada de referência se houver dúvida sobre mudança de estado ou expiração da sessão.
Não compare apenas tamanho e tempo. IDs de rastreamento, carimbos de horário e campos aleatórios podem mudar sem alterar a regra investigada. Identifique os campos que representam a decisão de negócio: dono do pedido, permissões retornadas, itens, alteração persistida ou erro estruturado.
Quando uma resposta contém dados de outra conta, preserve a relação entre request e response. Uma captura isolada do JSON perde informações importantes, como a credencial de teste utilizada e o objeto solicitado.
Teste contrato, validação e estados HTTP
O Repetir também ajuda a examinar tipos e limites de parâmetros. Em uma busca fictícia, comece com limit=10, depois investigue um limite permitido, um valor fora do contrato e um tipo inválido. Mantenha a mudança restrita ao parâmetro estudado e registre como a API responde.
| Resultado | Leitura inicial | Verificação necessária |
|---|---|---|
| 200 com HTML | Pode ser página de login ou fallback | Conferir Content-Type e conteúdo |
| 400 ou 422 | Pode ser validação de entrada | Comparar com o contrato e o erro informado |
| 401 | Credencial ausente, inválida ou expirada | Repetir a referência com sessão válida |
| 403 ou 404 | Acesso ou existência recusados | Conferir a política do objeto e o corpo |
| 429 | Limite de requisições atingido | Reduzir ritmo e respeitar Retry-After quando presente |
| 500 | Falha observada no servidor | Reproduzir minimamente e preservar identificador de rastreamento |
Um erro 500 não recebe automaticamente uma classificação de vulnerabilidade. Ele pode revelar uma falha funcional, um caso não tratado ou um problema de ambiente. Registre a entrada mínima, a repetibilidade e os efeitos antes de atribuir impacto de segurança.
Cuidados com métodos que alteram dados
Uma request POST, PUT, PATCH ou DELETE pode criar efeitos mesmo quando o cliente não recebe a resposta. Um timeout não informa se o servidor concluiu a operação. Antes de reenviar, confira o estado do recurso ou os registros disponíveis no ambiente de teste.
Se a API oferece idempotência, use o mecanismo documentado por ela. Reutilizar um header inventado não transforma uma transação em idempotente. Trabalhe com objetos descartáveis, ambiente restaurável e uma condição de parada clara. Para investigação inicial, prefira operações de leitura que já pertencem ao escopo.
Exporte cURL para reproduzir a chamada
Um comando cURL facilita reproduzir a request em outra bancada. O exemplo abaixo usa um marcador de token; substitua o valor apenas no seu ambiente privado. O domínio .test precisa ser configurado no laboratório.
curl --request GET 'https://api.aurora.test/api/pedidos/pedido-101' \
--header 'Accept: application/json' \
--header 'Authorization: Bearer TOKEN_ANA_LAB'Confira a exportação real antes de compartilhar. Cookies, tokens e corpos podem conter informações sensíveis. O guia de JWT e evidências propõe um registro separado para observação, hipótese e confirmação. Use também História e notas para guardar contexto.
Perguntas frequentes sobre testes de API no celular
Preciso automatizar para encontrar um problema?
Não. Duas requests bem comparadas podem esclarecer uma regra de autorização. Automatize depois de definir a hipótese e a condição que diferencia um resultado relevante.
Alterar um JWT no editor gera um token válido?
Não. Decodificar ou remontar o conteúdo não recria uma assinatura válida. A aceitação depende da validação feita pelo servidor e das chaves e políticas corretas.
Posso reaproveitar o mesmo teste após uma atualização?
Sim, preservando o cenário, os objetos, a versão e a regra esperada. Renove credenciais de teste e confira se o contrato mudou. Uma comparação de regressão exige contexto equivalente.
Do teste manual ao fluxo reproduzível
Quando a rotina estiver clara, use Intruso e Descobridor para variar entradas ou conheça os fluxos visuais com CatBridge para conectar etapas. Para começar, baixe o CatSuite e execute primeiro uma comparação pequena.
