Menu

Un guide simple pour les tests d'interopérabilité (avec des exemples)

simple guide interoperability testing

Essayez Notre Instrument Pour Éliminer Les Problèmes

Avant de comprendre la technique de «Test d’interopérabilité» , Permet d'abord de comprendre le terme «interopérabilité».

L'interopérabilité est la capacité d'un système à interagir avec un autre système. Cette interaction se fait entre 2 systèmes différents ou 2 applications différentes ensemble.

L'interopérabilité est souvent confondue avec L'intégration , compatibilité et portabilité. Eh bien, il existe des différences entre ces techniques.

Qu

Permettez-moi de commencer par expliquer les différences.

L'intégration - Est une technique lorsque les composants d'un même système interagissent les uns avec les autres. Ainsi, dans le monde des tests, lorsque nous effectuons des tests d'intégration, nous testons en fait le comportement des 2 niveaux les plus bas ou plus de composants du même système.

Compatibilité - Est une technique par laquelle 2 ou plusieurs applications interagissent dans le même environnement. Donc, dans le monde des tests, lorsque nous faisons des tests de compatibilité; nous validons si 2 ou plusieurs applications ou systèmes se comportent comme prévu dans le même environnement.

L'intention ici est de vérifier que les deux systèmes exécutent leurs tâches attendues, sans se gêner de fonctionnement, dans le même environnement. Comme - MS Word et Calculator sont 2 applications différentes et ils exécutent leur comportement attendu indépendamment dans le même système d'exploitation. On dit donc que ces 2 applications sont compatibles entre elles.

Portabilité - Il s'agit d'une technique lorsqu'une application ou un système se comporte comme prévu lorsqu'il est déplacé vers un autre environnement. Donc dans Portabilité testing, nous exportons l'application vers un autre environnement et testons son comportement. Par exemple, s'il existe une application qui fonctionne bien sous Windows XP, elle devrait également fonctionner correctement sous Windows 10.

Interopérabilité - Est une technique d'interaction d'une application avec une autre application. Ainsi, lorsque nous effectuons les tests d'interopérabilité, nous vérifions comment les données d'une application sont transférées dans une autre application sans indication préalable, de manière significative, puis traitées pour donner la sortie acceptée.

Cet article se concentre sur les tests d'interopérabilité (IOT), alors gardons notre attention sur l'interopérabilité. :)

Ce que vous apprendrez:

Test d'interopérabilité - Une brève introduction

Interopérabilité = Inter + opérable

application de conversion youtube en mp4 pour android

Inter - signifie «entre nous», «entre nous», «mutuel»

Opérable - signifie «capable d'accomplir la tâche donnée»

Donc, combiner les 2 termes ensemble - L'interopérabilité signifie 2 systèmes (ou plus), capables d'exécuter la tâche qui leur a été attribuée de manière indépendante et capables de communiquer entre eux comme prévu sans affecter leur fonctionnalité individuelle attribuée.

Exemple 1:Prenons un exemple de réservation de votre vol. Considérez que vous devez voyager de New Delhi à New York. Désormais, vous n’avez pas de vol direct. Vous devez voyager de New Delhi à Londres, puis prendre un vol de correspondance de Londres à New York. Parce que vous avez des contraintes de temps, vous réservez votre vol de New Delhi à Londres en «Jet Airways» et de Londres à New York en «Virgin Atlantic». Cela signifie que tous les détails de votre passager ont été transférés de Jet Airways à Virgin Atlantic. Donc ici, Jet Airways et Virgin Atlantic, sont toutes deux des applications indépendantes et lors de la réservation de votre vol, vos détails de réservation ont été échangés de Jet Airways à Virgin Atlantic de manière complète, sans indication préalable.

Exemple n ° 2:Dans le même ordre d'idées, pensez au système d'administration de l'hôpital, où les dossiers des patients sont échangés d'un service à un autre. Donc, ici, le département peut être lié à une application. Les détails du patient sont échangés entre 1 application et une autre application sans préavis.

Alors pourquoi avons-nous besoin de faire l'IOT?

Nous aurions besoin de faire des tests d'interopérabilité pour nous assurer que

  • Les applications du réseau exécutent indépendamment leur comportement attendu,
  • Peut échanger des informations sans préavis
  • Les informations / données sont échangées sans interrompre le comportement attendu individuel
  • Les données / informations échangées ne sont ni modifiées ni changées

Comment faire des tests d'interopérabilité?

Nous pouvons suivre la roue de détermination (le cycle PDCA) pour effectuer les tests d'interopérabilité.

# 1) Planifier

La planification est la phase la plus importante pour déterminer la stratégie consistant à faire presque n'importe quoi dans le développement logiciel. Avant de planifier réellement la détermination de la procédure de réalisation de l'IOT, il est impératif que nous comprenions chaque application ou système déployé dans le réseau.

Nous devons savoir pour toutes les applications - ses fonctionnalités, son comportement, ses entrées et ses sorties qu'il révèle.

Je recommanderais également que chaque application soit entièrement testée fonctionnellement sans défaut, avant de la préparer pour les tests d'interopérabilité. Ainsi, lorsque vous planifiez, ne pensez pas seulement à une ou deux applications, pensez à toutes les applications comme une seule et même unité. Vous devez avoir une vue à vol d'oiseau lors de la planification de cette technique de test. Inutile de dire que - documentez votre plan.

Nous pouvons utiliser notre document de plan de test standard et adaptez-le un peu selon l'exigence de documenter la planification de l'IOT. Une fois votre plan de test en place, avancez pour dériver vos conditions de test.

L'objectif de la dérivation de votre condition de test ne doit pas être limité aux applications individuelles; au contraire, il devrait être basé sur le flux de données à travers toutes les applications. Les conditions doivent être conçues de manière à ce que, sinon toutes, mais la plupart des applications du réseau soient traversées.

Une fois vos conditions de test identifiées, passez à la conception ou au script (au cas où vous prévoyez d'automatiser) vos cas de test. Tu peux créer un RTM (Matrice de traçabilité des exigences) pour mapper vos cas de test avec les conditions de test et vos conditions de test avec les conditions / exigences de test d'acceptation.

différence entre les tests sit et uat

Lorsque vous travaillez sur un réseau, il est à nouveau important de planifier également les activités de test non fonctionnel. Cela ne peut être écrit ou documenté nulle part, mais il est obligatoire de vérifier les aspects non fonctionnels du système dans son ensemble. Ces domaines non fonctionnels incluraient la performance et la sécurité. Si nécessaire, vous pouvez créer un plan distinct pour les tests fonctionnels, les tests de performance et les tests de sécurité; ou créer un plan unique et un document différent des conditions de test pour chacun de ces types de test.

# 2) Faire

Do - est la durée pendant laquelle vous effectuez réellement votre exécution. Planifiez votre temps en conséquence pour exécuter les tests fonctionnels et non fonctionnels. Nous suivons le cycle de test dans cette phase d'exécution des cas, enregistrons les défauts, effectuons le suivi avec l'équipe de développement pour les résoudre, effectuons le nouveau test et le test de régression du système dans son ensemble, rapportons les résultats des tests et le déplaçons vers fermeture.

# 3) Vérifier

Vérifier - C'est la phase où nous revoyons nos résultats de test et essayons de mapper ceux avec les RTM et de valider si toutes les exigences attendues sont satisfaites et si toutes les applications sont traversées. Nous vérifions que les données sont traversées et échangées correctement et en douceur entre les applications / systèmes. Nous aurions également besoin de valider que les données qui sont parcourues ne sont pas modifiées.

Envisagez également de faire une rétrospective de l'ensemble du processus de test d'interopérabilité. Identifiez les domaines qui ont bien fonctionné, ceux qui ne se sont pas bien déroulés et toutes les actions à prendre en compte.

# 4) Agir

Agir - C'est agir sur les éléments rétrospectifs. Les points qui ont été identifiés comme «bonnes pratiques», continuer à les appliquer et les points qui pourraient être mieux travaillés, identifier les étapes pour y remédier et agir en conséquence. Gardez à l'esprit que les zones ou les étapes qui n'ont pas bien fonctionné ne doivent PAS être répétées. Après tout, nous devons apprendre de nos erreurs et ne pas les répéter.

Les 5 étapes et demie:

  1. Identifiez toutes les applications qui font partie du réseau.
  2. Identifiez leurs fonctionnalités respectives.
  3. Pour chaque application, identifiez l'entrée qu'elle prend et la sortie qu'elle renvoie.
  4. Identifiez les données qui traverseraient toutes / la plupart des applications.
  5. Identifier le comportement attendu pour chaque combinaison de demande et de date à valider

½ Documentez-le.

Considérez la figure ci-dessous:

5 ½ étapes

Sur la base de la figure, essayons de reproduire les 5 étapes et demie:

  1. Application 1, Application 2, Application 3 et Application 4 sont 4 systèmes différents.
  2. Chacun de ces systèmes possède l'ensemble défini de fonctionnalités qui doit être identifié.
  3. Les entrées et sorties de chaque système doivent être identifiées.
  4. Dans le cas de Application1, il rend 2 sorties. 1 sortie forme l'entrée de l'application 3 et la sortie 1 forme l'entrée de l'application 2. La sortie de l'application 2 forme l'entrée de l'application 3 et de l'application 4 et ainsi de suite.
  5. La validité de chacune des entrées et sorties est vérifiée. Le point majeur à considérer ici est que les données qui traversent sous forme d'entrée et de sortie ne sont pas modifiées ET que toute l'application est couverte.

½ Ce chiffre dans la vraie vie peut ne pas sembler aussi simple. Il en résulte en fait une structure plus complexe avec n nombres de conditions d'entrée et de sortie.

Dessiner ce genre de figure donnerait une meilleure image pour identifier les données et les informations qui traverseraient différents systèmes. Cela nous aiderait à dériver les conditions et les cas de test.

Un exemple:

Prenons un exemple de réalisation de tests d'interopérabilité pour un «système de gestion hospitalière»

Un hôpital comprend les départements et sous-départements ci-dessous;

Système de gestion hospitalière

comment ouvrir le fichier eps dans windows 10

Ici, chaque département est une application en soi. Chaque département (application) a son propre sous-département (modules) et chaque module a ses propres unités.

Alors maintenant, pour considérer la portée de l'IOT, voici quelques conditions de test:

  1. Un patient qui a rencontré un accident de la route (Département OPD - Accident), doit subir une chirurgie de la jambe (ORL - Chirurgie générale), doit ensuite subir la kinésithérapie (Service Support - Physiothérapie) puis obtient son congé (Service Support - Fermeture)
  2. Un enfant admis aux soins intensifs (Pédiatrie - Soins intensifs) doit subir une intervention chirurgicale (Pédiatrie / ORL - Chirurgie générale) puis est renvoyé (Service de soutien - Fermeture / RP)
  3. Un patient extérieur consulte un médecin généraliste (service OPD); prend les médicaments prescrits (Service d'assistance - Pharmacie) et s'éloigne.
  4. Une femme enceinte vient pour des contrôles réguliers (service de gynécologie - soins maternels et infantiles), prend les médicaments prescrits (service d'assistance - pharmacie) et s'éloigne.
  5. Un patient dentaire fait le canal radiculaire (service de dentisterie), prend les médicaments prescrits (service d'assistance - pharmacie) et s'éloigne.
  6. Un patient vient en OPD (médecin généraliste), subit un traitement en (Service d'obstétrique et de gynécologie - Obstétrique à haut risque) prend les médicaments prescrits (Service d'assistance - Pharmacie) et est libéré

De cette façon, nous identifions toutes les conditions de test; en gardant à l'esprit que la majeure partie du département doit être couverte.

Nous pouvons dessiner un RTM pour montrer la couverture comme:

RTM

De cette façon, nous pouvons identifier plus de conditions de test et dessiner le RTM pour voir notre portée exacte. Nous pouvons également déterminer la profondeur de nos efforts de test sur la base du RTM.

Comme dans cet exemple, nous voyons que le «service de support» est l'application qui est le point de sortie pour la totalité (la plupart) de l'application, donc l'effort de test pour cette application particulière est un peu plus par rapport à une autre application.

Défis:

  1. Difficile de tester toute l'application avec toutes les permutations et combinaisons.
  2. Les applications sont développées dans différentes combinaisons matériel / logiciel et sont installées dans différents environnements, donc si l'un des environnements est en panne, cela a un impact sur les tests.
  3. En raison des différents logiciels et environnements, la détermination de la stratégie de test et son exécution est en soi une tâche importante.
  4. Stimuler l'environnement pour effectuer le test, est un grand défi.
  5. En cas de défaut, faire l'analyse des causes profondes est un défi de taille.
  6. Parce que les applications sont dans un réseau, il y aurait des moments où le réseau est en panne. Pour cette raison, les tests sont également affectés.

Comment puis-je atténuer ces défis?

1) Essayez d'utiliser les techniques de test avancées telles que:

  • OATS (technique de test Orthogonal Array)
  • Diagrammes de transition d'état,
  • Graphiques de cause à effet
  • Portion d'équivalence et analyse de la valeur limite.

Ces techniques vous aideraient à identifier l'interdépendance entre l'application et à identifier les cas de test / conditions qui assureraient une couverture maximale.

deux) Essayez d'identifier certaines données historiques telles que: dans quelles circonstances les systèmes étaient en panne, combien de temps faut-il pour revenir en action. Dans ce cas, essayez d'exécuter les scénarios dont les applications ne sont pas affectées ou utilisez le temps pour documenter les scénarios et rapporter les résultats. De plus, chaque fois que vous planifiez ou planifiez les tests, considérez toujours ces données historiques comme une entrée pour votre estimation et planifiez en conséquence.

3) PLAN - Utilisez les données historiques, les expériences passées, les compétences de l'équipe, les facteurs environnementaux pour identifier la stratégie des tests. Meilleur sera votre plan, meilleure sera votre exécution.

4) Commencez à préparer l'environnement bien avant le début de votre exécution réelle. Inutile de dire que vous planifiez vos étapes lorsque vous préparez l'environnement. Assurez-vous que votre environnement est configuré, prêt et opérationnel lorsque votre exécution démarre.

5) Avant de commencer avec l'IOT, assurez-vous que les applications individuelles sont entièrement testées fonctionnellement sans défaut. Ensuite, en cas de défaut, il vous suffira de rechercher les facteurs environnementaux qui ont entraîné une erreur.

6) Comme indiqué au point 2, planifiez votre activité. S'il s'agit d'une panne planifiée, vous devriez tenir compte de ce temps d'arrêt lorsque vous planifiez vos tests.

Test d'interopérabilité sur les mobiles:

Dans les mobiles, nous effectuons des tests d'interopérabilité chaque fois qu'une nouvelle application ( Application mobile ) est lancé. Nous devons prendre en compte de nombreux domaines lors de la planification de ces tests sur les appareils mobiles:

  • Les types d'appareils mobiles disponibles sur le marché sont énormes. Vous auriez besoin de lister tous les types d'appareils que vous envisagez pour vos tests. Vous devrez coupler un type d'appareil avec le système d'exploitation qu'il prend en charge.
  • Tous les OS mobiles sont développés dans différents langages de programmation. Par conséquent, l'application doit être testée contre toutes les variations du système d'exploitation.
  • Comprendre les facteurs juridiques et les contrats liés à la région.
  • La taille / résolution des différents appareils est différente.
  • L'impact sur les applications mobiles intégrées doit également être pris en compte.

Donc, pour faire de l'IOT sur les mobiles, vous auriez besoin de planifier et de créer un RTM, comme nous l'avons fait pour un test d'application informatique.

L'intention, la stratégie, les risques et l'exécution seraient les mêmes mais le outils et techniques serait différent dans le cas des mobiles.

Conclusion:

Les tests d'interopérabilité sont une tâche énorme. Cette technique nécessite une planification appropriée qui doit commencer en parallèle lorsque la planification des tests du système commence.

Il y a beaucoup de facteurs qui doivent être pris en compte lors de l'exécution de cette technique. Gardez à l'esprit d'avoir suffisamment de temps pour la correction des bogues et les retest, car c'est un effort énorme, il devrait y avoir des dispositions pour le suivi des défauts.

Cela peut arriver que vous n'atteigniez pas 100% couverture , mais nous devrions être assez intelligents pour sélectionner nos cas de telle sorte que la plupart des applications soient couvertes en un seul flux en utilisant de bonnes techniques d'écriture de cas de test.

J'espère que cet article a été utile pour comprendre la technique de test d'interopérabilité. Faites-nous part de vos questions / commentaires.

lecture recommandée

^