Normes de documentation du plan de test API
J'ai une question pour les testeurs d'API expérimentés, en particulier ceux qui travaillent dans de grandes organisations. J'ai été chargé d'identifier les normes de l'industrie pour la documentation des plans de test API. Jusqu'à présent, j'ai constaté que la norme IEEE 829 et ISO 29119 pouvaient être utilisées pour informer les tests logiciels en général.
Cependant, existe-t-il des bonnes pratiques, des directives ou des normes pour documenter spécifiquement les plans de test d'API que vous pourriez recommander à partir de votre expérience?
Réponses
Ma prise personnelle:
À haut niveau
Testez les points de terminaison, les codes d'état et les données de l'API avec des tests Smoke, Happy et Sad
À un niveau détaillé, il faut se poser les questions suivantes.
Les réponses guideront quoi et comment tester.
- Quelle documentation existe?
- Quelle fonctionnalité offre-t-il?
- Prend-il en charge la concurrence?
- Quels sont les points de terminaison de l'API?
- L'API est-elle interne ou externe?
- Quels points de terminaison sont idempotents?
- Les points de terminaison sont-ils sans état ou avec état?
- Les workflows * 1 varient-ils selon le client?
- Existe-t-il des exigences de performance?
- Les points de terminaison d'API constituent-ils un flux de travail?
- Quelles validations sont attendues pour les données?
- Quel système ou bibliothèque se cache derrière l'API?
- Faut-il se moquer des services dépendants?
- Cela limite-t-il le trafic, ou limitation de débit?
- Quelle approche de gestion des versions (le cas échéant) est utilisée?
- L'API prend-elle en charge plusieurs langues?
- Si vous utilisez déjà SOAPui, comment est-il intégré?
- L'API est-elle limitée à un pays ou une région?
- Fournit-il des talons de client dans des langues spécifiques?
- Quels codes d'état sont attendus pour des points finaux donnés?
- Quels sont le format et la structure de domaine des données?
- L'API utilise-t-elle HATEOS * 2 pour l'auto-documentation?
- Quel type de validation / test des données peut être effectué?
- Quelle API est prise en charge par le framework de test que j'utilise?
- Quelles actions sont effectuées, par exemple GET, PUT, POST, etc.?
- Avons-nous besoin de préparer des données ou des services de test dépendants?
- Quelles approches non API seront nécessaires pour vérifier les données?
- Existe-t-il des définitions d'API, par exemple WADL, WSDL, Thrift?
- Quelles approches non API seront nécessaires pour préparer les données?
- Quel (le cas échéant) mécanisme d'autorisation («quel») sera utilisé?
- Quel (le cas échéant) mécanisme d'authentification («qui») sera utilisé?
- Qui l'utilisera, des programmeurs externes ou un autre module interne?
- Quel (s) format (s): SOAP, REST, GraphQL, Thrift, ProtoBuffer, Autre?
* 1 Les flux de travail nécessitent souvent plusieurs appels d'API et peuvent avoir des dépendances entre eux
* 2 HATEOS - Hypertext As The Engine Of Application State, qui permet l'auto-découverte d'une API