Padrões de documentação do plano de teste de API

Question

Tenho uma pergunta para testadores de API experientes, especialmente aqueles que trabalham em grandes organizações. Fui incumbido de identificar quaisquer padrões da indústria para documentação de planos de teste de API. Até agora, descobri que o padrão IEEE 829 e o ISO 29119 podem ser usados ​​para informar os testes de software em geral.

No entanto, existem práticas recomendadas, diretrizes ou padrões para documentar planos de teste de API especificamente que você poderia recomendar com sua experiência?

Answer 1

Minha opinião pessoal:

Em alto nível

Teste os pontos de extremidade, códigos de status e dados da API com os testes Smoke, Happy e Sad

Em um nível detalhado, é necessário fazer as seguintes perguntas.
As respostas guiarão o que e como testar.

• Que documentação existe?
• Que funcionalidade ele oferece?
• Ele oferece suporte à simultaneidade?
• Quais são os pontos de extremidade da API?
• A API é interna ou externa?
• Quais endpoints são idempotentes?
• Os endpoints são sem estado ou com estado?
• Algum fluxo de trabalho * 1 varia de acordo com o cliente?
• Existem requisitos de desempenho?
• Os endpoints da API constituem um fluxo de trabalho?
• Que validações são esperadas para os dados?
• Qual sistema ou biblioteca está por trás da API?
• Precisamos simular serviços dependentes?
• Isso restringe o tráfego, também conhecido como limite de taxa?
• Qual (se houver) abordagem de controle de versão é usada?
• A API oferece suporte a vários idiomas?
• Se você já usa o SOAPui, como ele é integrado?
• A API está restrita a um país ou região?
• Ele fornece stubs de cliente em idiomas específicos?
• Quais códigos de status são esperados para determinados terminais?
• Qual formato e estrutura de domínio existem para os dados?
• A API usa HATEOS * 2 para autodocumentação?
• Que tipo de validação / teste de dados pode ser realizado?
• Qual API é compatível com a estrutura de teste que estou usando?
• Quais ações são realizadas, por exemplo, GET, PUT, POST etc?
• Precisamos preparar dados ou serviços de teste dependentes?
• Quais abordagens não API serão necessárias para verificar os dados?
• Existem definições de API, por exemplo, WADL, WSDL, Thrift?
• Quais abordagens não API serão necessárias para preparar os dados?
• Qual (se houver) mecanismo de autorização ('qual') será usado?
• Qual (se houver) mecanismo de autenticação ('quem') será usado?
• Quem o usará, programadores externos ou outro módulo interno?
• Que formato (s): SOAP, REST, GraphQL, Thrift, ProtoBuffer, Other?

* 1 Os fluxos de trabalho geralmente exigem várias chamadas de API e podem ter dependências entre elas

* 2 HATEOS - Hipertexto como o motor do estado do aplicativo, que permite a autodescoberta de uma API