Menu

Utilisation de JSON pour les tests d'interface

using json interface testing

Essayez Notre Instrument Pour Éliminer Les Problèmes

Utilisation de JSON pour les tests d'interface:

Les tests d'interface vérifient la communication entre deux systèmes différents. Elle est effectuée sur l'application testée pour vérifier si la communication aller-retour entre deux réseaux est correctement effectuée.

Une interface est essentiellement la connexion entre deux systèmes logiciels et le test de cette connexion pour le transfert de données est appelé test d'interface. L'interface couvre un large éventail de services dans le monde réel, elle peut être utilisée pour faire référence à un service Web, une API, etc.

Test d

Une interface contient un ensemble de règles, messages, commandes, etc. qui facilite la communication entre deux systèmes.

Ces tests se concentrent principalement sur les tests de deux segments majeurs:

  • Communication avec la base de données et le serveur d'applications
  • Communication avec le serveur Web et d'application

Un test d'interface est effectué pour évaluer les scénarios mentionnés ci-dessus afin de valider si les composants se transmettent correctement le contrôle et les données. Il vérifie également l'interaction entre les différents modules.

Ce que vous apprendrez:

Pourquoi le test d'interface est-il effectué?

Il est effectué pour assurer:

  • Si la communication entre les systèmes est effectuée correctement.
  • Tous les logiciels et matériels utilisés dans le système fonctionnent correctement.
  • Tous les documents liés à la communication sont disponibles sur toutes les plateformes intégrées.
  • Les exigences de sécurité et de cryptage sont conformes à la communication entre les systèmes.
  • Les composants intégrés sont capables de gérer les pannes de réseau et les pertes de communication.

Types de défauts détectés

La plupart des défauts détectés lors des tests d'interface utilisateur sont dus à un mappage incorrect des données entre les systèmes. Par conséquent, la plupart des bogues peuvent être classés dans les catégories suivantes.

  • Transmission de données incohérente entre les deux systèmes.
  • L'un des systèmes interprète mal la transmission de données d'un autre système.
  • Le canal de transmission ou l'interface entre les deux systèmes échoue et cela limite le transfert de données entre les systèmes, provoquant ainsi l'échec de toute l'interface.

Comment se déroule-t-il?

Il peut être principalement classé dans les phases suivantes:

  • Les interfaces peuvent être testées individuellement pendant test du système . Ce type de test est principalement effectué à l'aide d'un système de stub ou factice. Un système factice ou un stub imite le comportement de l'ensemble de l'interaction du système.
  • Un autre cas où le test d'interface est effectué est une jonction où deux systèmes communiquent entre eux.
  • Par conséquent, nous testons si les données envoyées par un système ont été correctement mappées et insérées dans un autre système ou non. Outre l'insertion de données, nous vérifions également l'intégrité des données, c'est-à-dire que les données, lorsqu'elles sont insérées dans un autre système, n'ont pas été manipulées ou modifiées, etc.
  • Des tests peuvent également être effectués lorsqu'un système transmet des données à une autre base de données d'application. Ici, nous allons tester si les données d'un système ont été correctement insérées dans une colonne donnée de la table donnée en fonction du mappage. Nous testerons également l'intégrité des données et la cohérence des données par rapport au système source.

Dans tous ces scénarios de test, le test d'interface est effectué en fonction des exigences métier et des règles de flux métier.

Différence entre les tests d'interface et les tests d'intégration

La vérification et la validation de la fonctionnalité de bout en bout des composants connectés ensemble sont appelées Test d'intégration ou plus communément en tant que test d'intégration de système. Les tests d'intégration valident principalement si deux ou plusieurs systèmes intégrés ensemble fonctionnent parfaitement ensemble ou non.

Essai Interface d'autre part se concentre essentiellement sur le canal de connexion entre les deux systèmes. Le canal de connexion entre deux ou plusieurs systèmes est appelé une interface. Le test de ce canal de connexion est appelé Test d'interface. La plupart des interfaces sont des API ou des services Web. Il n'a pas d'interface utilisateur mais prend une entrée et présente à l'utilisateur une sortie.

Par exemple

Test d

Dans l'exemple ci-dessus, le site Web et la base de données partagent une interface pour transmettre les informations de connexion, c'est-à-dire le nom d'utilisateur et le mot de passe.

L'interface utilise le service Web pour envoyer les informations de connexion à la base de données, qui à son tour valide l'authenticité du message entrant (nom d'utilisateur et mot de passe) et renvoie la valeur true si le nom d'utilisateur et le mot de passe correspondent à l'enregistrement présent dans la base de données ou false au cas où l'un d'entre eux ou les deux le nom d'utilisateur et le mot de passe ne correspondent pas aux données présentes à l'intérieur.

Parlons d'un exemple de test d'interface:

Disons que nous avons une application dans laquelle différentes bases de données interagissent les unes avec les autres.

Dans ce Exemple , nous allons considérer deux interactions de base de données via un canal d'interface.

Considérons qu'il existe deux bases de données ou application, les bases de données A et B. «A» transfère certaines données vers «B», qui est ensuite utilisée par B pour effectuer une opération. Après avoir effectué une certaine opération sur les données entrantes, B insère ces données dans la base de données et crée un JSON de sortie pour confirmation avec la liste des données mises à jour et les renvoie à A.

A et B utilisent le canal d'interface pour la communication entre eux.

Scénario commercial

«A» contient les données des employés pour tous les employés appartenant au service financier.

Les données doivent être portées vers «B ' sur une base quotidienne. «B» contient des données sur les détails généraux des employés. Toutes les données de «A» doivent être transférées vers une table et une colonne particulières de «B». Outre les données saisies, «B» doit également trier et organiser les données. Il doit également s'assurer que les données ont été saisies pour le bon employé.

Une fois que les données ont été entrées dans le système, «B» doit envoyer un JSON de sortie pour confirmer si les données ont été insérées dans la base de données.

En cas de divergence dans le schéma JSON ou de données manquantes, «B» ne traitera pas les données et enverra un message Reject JSON avec la raison du rejet.

Scénario métier de test d

Configuration de l'environnement de test

Pour tester un scénario comme celui-ci, nous aurons besoin d'un stub de test pour imiter la base de données «A». Le développeur peut fournir un emplacement où vous pouvez vider votre JSON de test ou une interface utilisateur fictive, coller vos données JSON et appeler le traitement via l'interface. À des fins de test, nous pouvons également avoir un emplacement de sortie où nous pouvons recevoir la confirmation JSON de «B».

Dans notre Exemple , nous utiliserons un chemin de dossier où nous mettrons notre test JSON, le service piquera constamment l'emplacement du fichier JSON. Une fois le fichier présent, le service récupère le fichier et l'envoie à «B» via l'interface. Une fois que le fichier a été ramassé, il sera supprimé du lieu de ramassage.

Commencer vos tests

Une fois l'environnement de test configuré, l'étape suivante consiste à créer les données de test.

Lors de la création de données de test (lire le test JSON), nous devons garder quelques points à l'esprit:

  • Suivez les règles métier.
  • Assurez-vous que les champs obligatoires sont présents.
  • Modifiez la valeur des champs en fonction des règles métier de chaque test.
  • Assurez-vous que le schéma JSON est au format correct.
  • Assurez-vous que la nomenclature du nom de fichier JSON a été respectée.

Jetons un coup d'œil à l'exemple de test JSON que nous utiliserons pour les tests:

{ 'employeeID ': 2569875, 'LastName': “Jackson”, 'baseSalary': 2569, 'DesignationCode':'P102', “Expenditure”:{ 'Month':“Feb”, 'Year': 2017, 'Official':560, 'Others”:0, } }

Commencez votre test

Une fois que vous avez créé votre fichier JSON de test, déposez-le à l'emplacement de prise en charge. Le service le récupérera et le publiera dans la base de données B.

Scénarios à tester:

Il peut y avoir un certain nombre de scénarios qui doivent être testés pour cet exemple, comme:

  • Travailler avec le service Web pour envoyer et recevoir des données.
  • Intégrité des données pour les données d'entrée. Cela peut être validé en interrogeant les tables et les colonnes de la base de données B pour les données saisies via le JSON de test.
  • Scénarios négatifs.

Dans un premier temps, nous vérifierons si le fichier JSON de test a été récupéré à l'emplacement ou n'est pas présent à l'emplacement. Cela validera le fonctionnement du service. Ensuite, nous naviguerons vers le dossier de sortie pour afficher le JSON de sortie. La présence de la sortie JSON valide si les données d'entrée ont été envoyées à la base de données B et si un accusé de réception a été reçu.

La partie suivante du test consiste à valider les données saisies dans la base de données.

Dans le test ci-dessus, nous validerons si les données envoyées via le test JSON ont été correctement entrées dans la base de données. Nous validerons l'intégrité des données, la cohérence des données et l'insertion des données. Nous devrons interroger la base de données B pour la colonne donnée dans une table particulière pour valider si les données ont été correctement insérées dans la table.

Disons que nous avons une table EmpDetails dans laquelle les données doivent être insérées. Nous allons donc lancer une requête pour valider les données.

La requête sera quelque chose comme ceci:

SELECT employeeID, LastName, baseSalary, DesignationCode, Month, Year, Official, Others FROM EmpDetails Where employeeID = 2569875;

Ici, nous utiliserons le employeeID comme clé primaire pour interroger les données dans la table EmpDetails. Nous interrogerons en utilisant tout le nom de colonne dans lequel les données ont été insérées. Ensuite, les données dans le nom de la colonne peuvent être validées avec les données envoyées via le JSON.

Dans le cas ci-dessus, les données du JSON sont stockées dans plus d'une table de la base de données, vous pouvez donc utiliser SQL JOINS pour récupérer toutes les données souhaitées.

La troisième étape du test consistera à tester les scénarios négatifs.

Certains des scénarios négatifs qui peuvent être testés sont:

  • Le comportement du système lorsque des données incorrectes sont transmises via JSON.
  • Lorsque le JSON a le mauvais schéma ou structure.
  • Lorsque le JSON traité ne contient pas la clé primaire ou des champs obligatoires.
  • La nomenclature du fichier JSON n'est pas valide.

Dans tous ces cas, le système doit être en mesure de gérer ces scénarios et aucune donnée ne doit être insérée dans le système conformément à la règle métier.

Conclusion

Le canal de connexion entre deux systèmes à travers lequel les données sont transmises est appelé un test d'interface et d'interface fonctionne principalement autour du test de ces connexions. La plupart des interfaces utilisent des services Web ou des API. Il n’a pas toujours d’interface utilisateur, mais il accepte les entrées et fournit une sortie.

quel est le meilleur téléchargeur vidéo

Étant l'un des formats de transfert de données les plus largement utilisés, JSON peut être utilisé pour le transfert de données d'interface.

Un testeur doit avoir des connaissances de base sur la structure JSON pour créer des données de test (sous la forme de JSON) et pour lire les données de sortie du système. Un testeur doit également être familiarisé avec le mappage entre les clés JSON et la table-colonne de la base de données.

Tout testeur souhaitant travailler sur les tests d'interface doit avoir une connaissance claire des directives commerciales et des règles d'une application. Un testeur doit également avoir des connaissances adéquates sur la base de données et doit être capable d'écrire des requêtes SQL simples.

Pour toute question ou clarification, veuillez nous contacter dans la section commentaires.

Tutoriel n ° 5: Questions d'entretiens JSON

lecture recommandée

^