Qu'est-ce que le test d'interface ? Types et exemple

Qu’est-ce que le test d’interface ?

Test d'interface est défini comme un type de test logiciel qui vérifie si la communication entre deux systèmes logiciels différents est effectuée correctement.

Une connexion qui intègre deux composants est appelée interface. Dans le monde informatique, cette interface peut prendre diverses formes, comme des API, des services web, etc. Tester ces services de connexion ou interfaces est appelé test d'interface.

Une interface est en fait un logiciel composé d'ensembles de commandes, de messages et d'autres attributs permettant la communication entre un appareil et un utilisateur.

Le point important est qu'une interface a un contract : un format de requête convenu, un format de réponse convenu, un ensemble convenu de codes d'erreur et un délai d'attente convenu. Exercices de test d'interface qui contracde part et d'autre, une modification apportée par une équipe n'affecte pas silencieusement l'autre. Comme la majeure partie de ce trafic n'atteint jamais un écran, les défauts détectés sont invisibles pour l'utilisateur. test de la boîte noire effectué uniquement via l'interface utilisateur.

Comment faire des tests d'interface

Les tests d'interface comprennent les tests de deux segments principaux :

1. Interface du serveur Web et du serveur d'applications
2. Interface du serveur d'applications et du serveur de base de données.

Pour les scénarios mentionnés ci-dessus, les tests d'interface sont effectués pour

• Vérifier que les serveurs sont exécutés correctement ou non
• Les erreurs sont gérées correctement ou renvoient un message d'erreur pour toute requête effectuée par une application
• Vérifiez les résultats lorsque la connexion à un serveur Web est réinitialisée entre les deux

Le schéma ci-dessous représente ces deux segments comme une seule chaîne, le navigateur communiquant avec le serveur web, le serveur web communiquant avec le serveur d'applications et le serveur d'applications communiquant avec le serveur de base de données.

En pratique, un testeur parcourt cette chaîne étape par étape. Chaque étape est d'abord testée avec une requête valide, puis avec une requête malformée, et enfin avec l'extrémité distante délibérément indisponible, de sorte que le chemin de réussite et le chemin d'échec soient enregistrés de la même manière. cas de test.

Exemple de test d'interface

Supposons que pour toute application xyz, l'interface prenne XML fichier en entrée et fournit JSON Le fichier de sortie est requis. Pour tester l'interface de cette application, seules les spécifications des formats de fichiers XML et JSON sont nécessaires.

Grâce à ces spécifications, nous pouvons créer des exemples de fichiers XML d'entrée et les intégrer à l'interface. La validation des fichiers d'entrée (XML) et de sortie (JSON) par rapport aux exigences constitue ensuite un test d'interface.

Remarquez ce dont cet exemple n'a pas besoin : ni écran, ni interface utilisateur, ni connaissance du code interne. Deux spécifications de format suffisent pour écrire les tests ; c'est pourquoi les tests d'interface peuvent commencer bien avant même que l'interface utilisateur ne soit disponible.

Pourquoi faire des tests d'interface

Les tests d'interface sont effectués

• Pour garantir que les utilisateurs finaux ou le client ne rencontrent aucun problème lors de l'utilisation d'un produit logiciel particulier
• Identifier les domaines d'application habituellement consultés par les utilisateurs finaux et vérifier également leur convivialité.
• Pour vérifier les exigences de sécurité pendant que la communication se propage entre les systèmes
• Pour vérifier si une solution est capable de gérer les pannes de réseau entre un serveur d'applications et un site Web

Il y a aussi la question du coût. Corriger un défaut de format de requête est peu coûteux tant que les deux systèmes sont en cours de connexion, mais onéreux une fois que le système en aval a déjà stocké les données malformées.

Types de tests d'interface

Pendant les tests d'interface, divers types de tests sont effectués sur l'interface, qui peuvent inclure

• Workflow: Il garantit que le moteur d'interface gère vos flux de travail standard comme prévu.
• Cas limites - valeurs inattendues : Ceci est pris en compte lors des tests incluant la date, le mois et le jour inversés.
• Tests de performance, de charge et de réseau : Une interface à haut volume peut nécessiter davantage test de charge qu'une interface à faible volume, en fonction du moteur d'interface et de l'infrastructure de connectivité
• Systèmes individuels : Cela inclut le test de chaque système individuellement. Par exemple, le système de facturation et le système de gestion des stocks du magasin de détail devraient pouvoir fonctionner séparément.

Le premier élément est assez proche de tests de flux de travail réutiliser ses scénarios, et le dernier élément recoupe avec test de modulecar un système qui tombe en panne de lui-même tombera de nouveau en panne une fois connecté.

Stratégie de test d'interface

La stratégie de test d'interface est une méthode utilisée pour tester les interfaces avec des tests communs, indépendamment de leur implémentation. Nous pouvons utiliser des tests absolus.tracCréez des cas de test et des instances concrètes pour chaque implémentation de la stratégie de test d'interface. La base/abstracLes cas de test t effectuent des tests indépendants de l'implémentation, tandis que les tests concrets prennent en charge l'instanciation des objets à tester et effectuent des tests spécifiques à l'implémentation.

L'avantage de cette structure est la réutilisation. Lorsqu'une troisième implémentation de la même interface apparaît, l'abstracLa suite t s'exécute sans modification, et seul le code d'instanciation doit être écrit. La même idée est appliquée à plus grande échelle dans test de composants, où un contrat partagétract suite est exécuté sur chaque composant qui prétend le satisfaire.

Outils de test d'interface

Puisqu'une interface n'a pas d'écran, les outils doivent construire directement les requêtes et traiter les réponses brutes. Les équipes combinent généralement trois catégories d'outils.

• Clients API et générateurs de requêtes : Des outils tels que Postman, SoapUIInsomnia et Hoppscotch envoient des requêtes REST, SOAP ou GraphQL, les stockent sous forme de collections réutilisables et vérifient les codes d'état, les en-têtes et les corps de réponse.
• Code- bibliothèques de test de niveau : Les bibliothèques qui s'exécutent au sein de la suite de tests existante permettent aux vérifications d'interface de coexister avec les tests unitaires et de s'exécuter à chaque compilation, ce qui les empêche de devenir obsolètes.
• Outils de chargement et de protocole : Un outil tel que JMeter pilote la même interface à volume élevé, ce qui transforme un contrôle fonctionnel en Test de performance de la connexion.
• Virtualisation des services et simulations : Un câble de test faisant office d'extrémité permet de tester un côté pendant que l'autre est indisponible, inachevé ou trop coûteux à appeler à plusieurs reprises.

Le choix du client importe moins que la couverture. Quel que soit le client choisi, l'ensemble des requêtes doit être stocké dans un système de contrôle de version avec le code, afin qu'une modification de l'interface et une modification de ses tests soient incluses dans le même commit. Les détails de cette catégorie plus large sont traités dans [référence manquante]. Test d'API.

Liste de contrôle et meilleures pratiques pour les tests d'interface

Une courte liste de vérification permet de garantir une couverture d'interface cohérente entre les versions. Il convient de la suivre pour chaque connexion plutôt que pour l'application dans son ensemble.

• Avectract premier : Vérifiez que les schémas de requête et de réponse correspondent à la spécification publiée, champ par champ, y compris les types de données et les champs optionnels.
• Valeurs limites : Envoyer des charges utiles vides, des champs de longueur maximale, des jeux de caractères inattendus et des formats de date inversés.
• Chemins d'erreur : Vérifiez que chaque échec renvoie un code et un message explicites plutôt qu'une pile d'erreurs. trace ou un succès silencieux.
• Délais d'attente et nouvelles tentatives : Interrompre la connexion en cours de requête et vérifier que l'appelant réessaie en toute sécurité sans dupliquer la transaction.
• Sécurité : Vérifiez l'authentification, l'autorisation et le chiffrement du lien, et assurez-vous que les messages d'erreur ne divulguent pas d'informations internes.
• La cohérence des données: Relisez l'enregistrement depuis l'autre côté et vérifiez qu'aucun élément n'a été tronqué, réencodé ou réorganisé pendant le transport.
• Volume: Répétez l'appel le plus sollicité en cas de charge simultanée et surveillez l'épuisement du pool de connexions.

Trois pratiques permettent de garantir la reproductibilité de cette liste de contrôle. Premièrement, automatisez la suite de tests et exécutez-la à chaque compilation, car les interfaces évoluent plus discrètement que les écrans. Deuxièmement, consignez l'intégralité de la requête et de la réponse pour chaque échec, car un défaut d'interface est quasiment impossible à reproduire à partir d'une capture d'écran. Troisièmement, assurez-vous que la suite de tests soit indépendante des données de test créées par d'autres suites, afin qu'un échec pointe vers l'interface et non vers un enregistrement manquant.

Ces contrôles s'inscrivent naturellement dans le plan plus large décrit dans types de tests logicielset elles s'exécutent avant que les mêmes connexions ne soient exercées de bout en bout pendant test du système.

Tests d'interface et tests d'intégration

Ces deux termes sont liés plutôt qu'opposés : les tests d'interface désignent la partie du travail d'intégration qui se concentre sur la connexion elle-même. Le tableau ci-dessous met en évidence les points communs et les différences.

Toute personne découvrant cette discipline plus vaste trouvera les niveaux environnants décrits dans test d'intégration et en général test logiciel Dans l'introduction, la terminologie utilisée ci-dessus provient de la norme. génie logiciel En pratique, pour les systèmes accessibles via un navigateur, les mêmes connexions sont finalement réutilisées lors de la phase d'entraînement. tests d'applications Web.

FAQ