À mesure que l'IA est de plus en plus intégrée au développement et aux tests d'API, la barrière à l'entrée pour les tests automatisés diminue constamment. Des tâches qui nécessitaient auparavant des opérations manuelles répétitives et la préparation de données peuvent désormais être gérées par l'IA. Apidog reflète également ce changement dans les tests d'API.
Dans Apidog, les tests automatisés s'articulent principalement autour de deux approches : les Tests d'Endpoints et les Scénarios de Test.
Si vous ne voyez pas le module Test d'Endpoint, cela signifie que votre version d'Apidog est obsolète. Il vous suffit de mettre à jour vers la dernière version.
Le module Tests d'Endpoints affiche tous les endpoints HTTP de vos API, permettant aux développeurs QA de se concentrer davantage. Il n'inclut que les cas de test, les rapports de test et la documentation, sans autoriser la modification des endpoints. Cette conception garantit que les testeurs peuvent se concentrer sur la création et l'exécution efficaces des cas de test.
Les Scénarios de Test, en revanche, lient plusieurs endpoints ou cas de test entre eux. Ils vous permettent de définir l'ordre d'exécution et les relations de transfert de données entre les endpoints, simulant ainsi efficacement un processus métier complet.
Avec l'IA intégrée aux Tests d'Endpoints et aux Scénarios de Test, les tests d'API peuvent progressivement évoluer vers une exécution plus automatisée, réutilisable et efficace. Ensuite, nous explorerons comment ces deux méthodes de test aident à résoudre les défis du monde réel.
Tests d'Endpoints avec automatisation
Le Test d'Endpoint se concentre sur la question de savoir si l'endpoint lui-même est stable et si l'entrée/sortie répond aux attentes. Chaque cas de test est exécuté indépendamment, l'accent étant mis sur la vérification approfondie d'un seul endpoint avec différentes données.
Cas de Test Générés par l'IA
Ouvrez n'importe quel endpoint dans le module Test d'Endpoint et cliquez sur Générer avec IA. L'IA générera automatiquement un ensemble de cas de test basés sur les paramètres de l'endpoint et la structure de la réponse.
Si vous n'avez besoin que de cas de test spécifiques, il n'est pas nécessaire de sélectionner les types par défaut. Décrivez simplement vos exigences directement à l'IA, et elle générera le cas de test correspondant. Par exemple, vous pouvez demander à l'IA de :
- Générer un cas de test pour "connexion réussie et extraction du jeton".
- Générer un cas de test pour "créer le champ de signature
signbasé sur les paramètres existants et l'envoyer".
Pour des résultats plus précis, vous pouvez fournir des conditions et des règles détaillées, telles que :
Générer un cas de test positif pour cet endpoint.
L'endpoint requiert un paramètre de signature sign, avec les règles de signature suivantes :
1. Collecter tous les paramètres de requête non vides (hors sign), les trier par nom de paramètre dans l'ordre ASCII, les concaténer au format clé=valeur joints par &, et ajouter la clé secrète SECRET_KEY à la fin.
2. Appliquer le hachage MD5 à la chaîne résultante et convertir le hachage en majuscules. Le résultat final est utilisé comme valeur de sign.
Exigences du cas de test :
1. Avant d'envoyer la requête, utiliser un script de pré-requête pour générer la signature, avec des commentaires clairs inclus.
2. Ajouter la signature générée aux paramètres de la requête et envoyer la requête.De cette façon, l'IA générera des cas strictement selon vos règles, sans omissions ni malentendus.
Génération de Données de Test
Lors de la génération de cas de test, l'IA prépare également des ensembles de données de test correspondants pour différents types de cas afin de couvrir diverses situations d'entrée réelles.
Dans les cas de scénarios commerciaux standard, les données de test consistent généralement en plusieurs ensembles de valeurs de paramètres sémantiquement valides. Par exemple, dans un test d'endpoint de connexion, bien que tous les e-mails et mots de passe soient valides, l'ensemble de données inclura divers formats d'e-mail courants (tels que ceux avec des points, des signes plus, des e-mails numériques ou des e-mails d'entreprise) pour vérifier la compatibilité et la stabilité de l'endpoint dans des scénarios d'utilisation normale.
Dans les cas de test anormaux ou limites, les données de test sont intentionnellement conçues pour inclure des entrées qui violent les règles de validation.
Par exemple, dans un cas de test tel que "Se connecter avec un format d'e-mail invalide et s'attendre à une erreur 400", l'ensemble de données contiendrait différents types d'adresses e-mail invalides (telles que des e-mails sans le symbole @, sans nom de domaine ou contenant des espaces). L'objectif est de vérifier si l'endpoint de l'API peut détecter correctement ces entrées invalides et rejeter la requête de manière appropriée.
Référencer des Données de Test
Dans les cas de test, vous pouvez utiliser la syntaxe {{nom_variable}} pour référencer des données de test et insérer des variables dans les paramètres de requête, les corps de requête et d'autres champs.
Lorsque le test s'exécute, Apidog extrait automatiquement les valeurs de l'ensemble de données une par une et envoie des requêtes en utilisant chaque valeur. Cela vous permet de tester le même endpoint plusieurs fois avec des données différentes, sans avoir à réécrire le cas de test.
Exécution par Lots et Rapports de Test
Une fois les cas de test et leurs données correspondantes prêts, vous pouvez sélectionner plusieurs cas de test et les exécuter ensemble. Chaque cas de test s'exécute indépendamment selon sa propre configuration, et tous les résultats sont regroupés dans un seul rapport de test pour un examen facile.
Dans les applications réelles, les endpoints opèrent rarement de manière isolée. Lorsque la réponse d'une requête est utilisée comme entrée pour la suivante, le test ne concerne plus un seul endpoint mais la chaîne d'appels entière.
C'est là que les Scénarios de Test entrent en jeu.
Scénarios de Test
Un seul endpoint ne suffit généralement pas à accomplir une tâche métier. Par exemple, un utilisateur doit se connecter avant de passer une commande, et ce n'est qu'après la création réussie de la commande que les détails de celle-ci peuvent être consultés. La réponse d'un endpoint devient souvent l'entrée pour le suivant.
Ces dépendances sont difficiles à valider entièrement avec un seul test d'endpoint.
Les Scénarios de Test déplacent l'attention de la vérification du bon fonctionnement d'un endpoint vers la vérification du bon déroulement et de la conformité d'une chaîne d'appels entière aux attentes.
Orchestrer les Endpoints en un Flux de Travail
Dans Apidog, après avoir créé un nouveau scénario de test, vous pouvez ajouter plusieurs endpoints ou des cas de test existants dans un ordre spécifique, définissant clairement la séquence d'exécution pour chaque étape.
Transférer des Données entre les Étapes de Test
Lorsque les endpoints dépendent les uns des autres, les scénarios de test vous permettent de passer des données d'une étape à l'autre sous forme de variables. Par exemple, l'id renvoyé par l'endpoint Créer une Commande peut être réutilisé directement dans les étapes ultérieures, telles que la consultation ou la mise à jour de la commande.
Ce transfert de données ne nécessite aucun code supplémentaire. Il repose plutôt sur le référencement de variables pour définir clairement les relations en amont et en aval entre les endpoints.
Que Faire si des Cas de Test Manquent ?
Lors de l'orchestration des scénarios de test, le premier objectif est souvent de s'assurer que le flux de travail principal se déroule sans accroc, par exemple : Connexion → Créer une Commande → Consulter la Commande, où chaque étape correspond à un cas de test existant.
Cependant, en pratique, vous pouvez rencontrer un défi courant : certaines étapes du flux de travail peuvent ne pas avoir de cas de test prêts à l'emploi, ou les cas existants peuvent ne pas répondre pleinement aux exigences du flux de travail.
Par exemple, à l'étape de connexion, vous pourriez avoir besoin non seulement de vérifier une connexion réussie, mais aussi d'extraire le jeton renvoyé en tant que variable d'environnement pour les requêtes suivantes. Un cas de test d'endpoint unique existant pourrait ne réaliser qu'une validation de connexion de base sans gérer l'extraction de jeton.
Si vous ne savez pas comment extraire les champs retournés sous forme de variables ou si vous n'êtes pas familier avec le scriptage, vous pouvez interrompre l'orchestration du scénario. Ensuite, accédez à la page Test d'Endpoint pour cet endpoint et utilisez l'IA pour gérer l'exigence. Par exemple, vous pourriez spécifier :
"Générer un cas de test qui extrait le jeton et le sauvegarde en tant que variable d'environnement après une connexion réussie, incluant les assertions nécessaires."
Si vous souhaitez un contrôle plus précis sur vos cas de test, vous pouvez activer la génération pas à pas dans les Paramètres avancés.
Une fois activé, Apidog générera d'abord une liste de cas de test, incluant leurs noms et descriptions. Vous pourrez ensuite les examiner, les modifier et les confirmer manuellement avant de générer l'ensemble des données détaillées du cas de test.
Une fois le cas de test généré, revenez au scénario de test. Vous pouvez utiliser ce cas directement comme étape de connexion, et les endpoints suivants pourront référencer le jeton via les Valeurs dynamiques, permettant ainsi au flux de travail de se poursuivre sans interruption.
Si vous avez besoin de données de test dans vos Scénarios de Test, vous pouvez d'abord demander à l'IA de générer des cas avec des Données de Test dans Test d'Endpoint. Ensuite, copiez l'ensemble de données au format CSV dans le scénario de test en utilisant l'Édition en Vrac, ce qui rend la configuration des données beaucoup plus rapide et pratique.
Cette approche garantit que le scénario de test est toujours centré sur le flux de travail principal, tandis que l'IA agit comme un assistant "au fur et à mesure". Chaque fois qu'une étape manque, utilisez simplement l'IA pour générer le cas de test correspondant à cet endpoint, puis reliez-le immédiatement au flux de travail.
Résumé
L'IA n'a pas changé ce que les tests d'API doivent vérifier, mais elle a considérablement réduit l'effort requis pour démarrer et achever les tests.
Pendant les Tests d'Endpoints, l'IA s'attaque principalement à la lenteur de la création des cas de test et à la couverture incomplète. Cela permet aux tests de passer plus rapidement à la phase de validation, au lieu de rester bloqués à préparer manuellement les données et à écrire les cas.
Lorsque les tests progressent vers les Scénarios de Test, l'accent se déplace de la vérification d'un seul endpoint à la garantie que les endpoints peuvent fonctionner correctement ensemble dans des séquences d'appels réelles.
Dans ce flux de travail, vous n'avez pas besoin de préparer tous les cas de test à l'avance. Au fur et à mesure que le scénario est construit, vous pouvez revenir aux Tests d'Endpoints individuels à tout moment pour que l'IA génère les cas spécifiques nécessaires au flux de travail actuel, puis continuer à orchestrer les étapes. Cela réduit les efforts initiaux inutiles et économise l'utilisation des crédits.
Dans l'ensemble, Apidog intègre les Tests d'Endpoints, les Scénarios de Test et les capacités d'IA au sein d'un seul flux de travail, transformant les goulots d'étranglement habituels des tests d'API — écriture de cas, préparation de données et chaînage de processus — en tâches gérables.
Si vous pensez toujours que les tests automatisés signifient "configuration complexe et courbe d'apprentissage abrupte", commencez petit : choisissez un seul endpoint dans Apidog, générez quelques cas, et exécutez un scénario de test. Vous constaterez rapidement à quel point le processus peut être plus fluide et plus rapide en pratique.