Webinaire en vedette : MISRA C++ 2023 : tout ce que vous devez savoir | Voir le séminaire

Comment automatiser les tests d'API REST avec des charges utiles de requêtes volumineuses

Portrait de Matt Love, ingénieur produit chez Parasoft
17 octobre 2018
5 min lire

Comment pouvez-vous automatiser les tests d'API REST avec une charge utile de requête importante ? Lisez pour en savoir plus.

Comment obtenir une suite de quelques dizaines de scénarios de test d'API REST, qui ont tous de très grandes charges utiles de requête, en quelques secondes ? Adopter une approche scientifique des tests aide à créer une cohérence avec Automatisation des tests de l'API REST, mais même les scientifiques ont besoin d'un coup de main de temps en temps.

Les testeurs sont la dernière ligne de défense entre nos applications et leur public de plus en plus averti en technologie. Si nous déployons sur le marché une application présentant des défauts ou des problèmes de performances, nos clients ne la toléreront plus. En conséquence, les testeurs doivent être intelligents et capables de tester les applications modernes de la manière la plus efficace possible. Mais les tests sont une science et nécessitent que vous adoptiez une approche systématique pour valider une application.

Les tests sont une science

Mais même avec une approche scientifique des tests, les tests logiciels ne sont pas si simples. Les testeurs passent généralement par un processus tel que le suivant:

  1. Posez une question, généralement sur le comportement de l'application. (Nécessite une quantité considérable de créativité.)
  2. Faites des recherches en arrière-plan pour comprendre les multiples interfaces (Web, mobile, API, etc.), comment les tester avec précision et comment l'application devrait fonctionner.
  3. Construire une hypothèse (c.-à-d. Tests d'assertion et de régression). En vous basant sur votre compréhension de la manière dont l'application «devrait fonctionner», vous pouvez configurer les variables qui indiquent vos attentes.
  4. Testez votre hypothèse en construisant des tests (de la manière la plus significative possible afin de pouvoir prouver ou réfuter votre hypothèse (assertion / régression).
  5. Analysez vos résultats et tirez des conclusions. Après avoir exécuté vos tests et reçu les résultats, vous pouvez soit interpréter manuellement pour voir s'ils répondent à vos attentes, soit automatiser l'exécution de vos tests pour être uniquement alerté des échecs de test.
  6. Communiquez vos résultats vers le pipeline de livraison de logiciels plus large afin que l'organisation puisse prendre une décision significative sur l'opportunité d'aller de l'avant avec l'application.

Les tests ne sont pas une affaire simple, nous avons donc besoin de tout le soutien que nous pouvons obtenir pour construire ces expériences significatives qui peuvent fournir des commentaires significatifs pour garantir que nos applications sont construites correctement. Et il est important pour nous, en tant que testeurs, de communiquer entre eux toutes les méthodes que nous avons découvertes pour faciliter les tests! Ici, une de ces méthodes. Ci-dessous, je vais expliquer un récent défi de test d'API REST que j'ai eu et partager comment j'ai pu résoudre le problème.

Test d'API REST avec des charges utiles de requêtes volumineuses

Les applications Web modernes envoient des appels d'API JSON RESTful du navigateur au serveur, car les données JSON sont faciles à utiliser par le code JavaScript. Mais créer des scripts d'automatisation de test avec ces données JSON n'est pas toujours aussi simple. Récemment, j'ai rencontré un mal de tête de test en raison de charges utiles de requêtes JSON importantes dans le service que je testais, et j'ai pu utiliser Parasoft SOAtestle nouveau générateur de tests Smart API de pour vous aider.

Contrairement aux grands nécessaire charges utiles, grandes réponse les charges utiles sont faciles à gérer pour les testeurs. Appelez le service, enregistrez la réponse, puis comparez les différences avec les réponses futures. Supprimez toutes les valeurs susceptibles de changer à tout moment, telles que les dates ou les horodatages. Rincez et répétez. Cependant, tout cela est basé sur l'appel du service en premier lieu. Avec des charges utiles de demande volumineuses, vous devez configurer un grand nombre de données avant de passer chaque appel de service et vous devez vous assurer que tout est correct. Bien sûr, vous pouvez copier et coller à partir des outils de développement du navigateur, mais avec de nombreux appels d'API REST, cela signifie beaucoup de copier-coller. C'est pourquoi maintenant, il est si excitant de pouvoir utiliser le générateur de test Smart API.

Mon projet récent impliquait une page de configuration Web pour l'intégration avec les serveurs LDAP et Active Directory. Le concept était simple: configurer les paramètres puis tester en listant les comptes d'utilisateurs et de groupes. Le problème était qu'une configuration LDAP avait beaucoup de paramètres, et le test de ces paramètres nécessite de les envoyer tous dans la charge utile de la demande. En outre, des appels supplémentaires ont été nécessaires pour tester l'appartenance de chaque groupe. Chaque demande a fini par être des centaines de lignes de données JSON.

Je travaillais sur l'ajout d'un support pour une nouvelle stratégie d'adhésion. Les seules données JSON que je me souciais de tester étaient sur la ligne 10, mais toutes les autres lignes de données étaient toujours nécessaires pour que tout fonctionne. J'ai donc configuré ma page de configuration pour pointer vers un serveur LDAP avec des données de test et activé l'enregistrement à l'aide de l'extension Parasoft Recorder pour Chrome. J'ai cliqué sur des boutons pour tester les utilisateurs et les groupes, et j'ai développé chaque groupe pour voir les membres. Chaque fois que j'ai cliqué, quelques appels d'API REST ont été effectués sur le serveur Web.

L'hypothèse était que la stratégie d'adhésion affecterait les groupes et les membres dans l'aperçu. J'ai changé la stratégie d'adhésion sur la page de configuration et j'ai cliqué à nouveau sur les données de test. Visuellement, je pouvais voir différents résultats d'appartenance à un groupe dans la boîte de dialogue. J'étais satisfait de mon test manuel, j'ai donc arrêté l'enregistrement et généré un ensemble très intelligent de tests d'API:

Et c'était là - en quelques secondes, j'avais une suite de quelques dizaines de tests d'API REST qui avaient tous des charges utiles de requêtes très importantes. Seules quelques propriétés telles que le nom du groupe et la stratégie d'appartenance ont changé entre les demandes, mais cela suffisait pour obtenir une variation des réponses et enregistrer un contrôle de différence pour chacune. Il était même assez intelligent d'extraire les noms de groupe de la première réponse d'aperçu de groupe et de les stocker pour une utilisation paramétrée dans les tests suivants. Le fait de voir tous les tests réussir m'a donné la certitude que ma nouvelle fonctionnalité de stratégie d'adhésion fonctionnait correctement.

Tout cela a été fait à l'aide d'un serveur LDAP avec des données de test au lieu de comptes d'utilisateurs réels. Je peux m'assurer que les données de test ne changeront pas, mais les vrais utilisateurs vont et viennent avec le temps. La modification des données peut créer beaucoup de bruit dans les contrôles de régression de test automatisés. Si vous ne disposez pas de données de test stables pour votre application, je vous suggère de consulter le service Web ou la virtualisation de base de données offerte par Parasoft Virtualiser.

Tirez parti de vos tests manuels pour créer des tests API RESTful automatisés et sans script.
Essayez Parasoft SOAtest

Mon défi de test, résolu

Comme je l'ai mentionné au début de cet article, adopter une approche scientifique des tests permet de créer de la cohérence. Mais même les meilleurs scientifiques ont besoin d'un coup de main de temps en temps! La technique que j'ai décrite ci-dessus est comme utiliser un microscope à haute puissance au lieu d'une loupe. C'est un bond en avant important dans ce qui est par ailleurs un processus très compliqué et, du moins pour moi, a considérablement accéléré mon défi de test. J'espère qu'il en fera de même pour vous. Bon test!