what is incremental testing
Avec l'aide de cet article, je vais couvrir l'une des principales approches d'intégration - les tests incrémentiels.
À la fin de cette section, le public aura une bonne connaissance des éléments suivants:
- Qu'est-ce que le test incrémental?
- Son objectif
- Méthodologies
- Avantages
- Désavantages
Ce que vous apprendrez:
- Qu'est-ce que le test incrémentiel
Qu'est-ce que le test incrémentiel
Le test incrémental, également connu sous le nom de test d'intégration incrémentielle, est l'une des approches du test d'intégration et intègre ses concepts fondamentaux.
C'est comme un test qui combine module et intégration stratégie de test .
Dans ce test, nous testons chaque module individuellement dans la phase de test unitaire, puis les modules sont intégrés de manière incrémentielle et testés pour assurer une interface et une interaction fluides entre les modules.
Dans cette approche, chaque module est combiné de manière incrémentielle, c'est-à-dire un par un jusqu'à ce que tous les modules ou composants soient ajoutés logiquement pour créer l'application requise, au lieu d'intégrer l'ensemble du système en une seule fois, puis d'effectuer des tests sur le produit final. Les modules intégrés sont testés en groupe pour garantir une intégration et un flux de données réussis entre les modules.
Comme pour les tests d'intégration, l'objectif principal de ces tests est de vérifier l'interface, les liens intégrés et le flux d'informations entre les modules. Ce processus est répété jusqu'à ce que les modules soient combinés et testés avec succès.
Exemple
Comprenons ce concept avec un exemple:
Le système ou l'application logicielle se compose des modules suivants:
Approche de test d'intégration incrémentale
- Chaque module, c'est-à-dire M1, M2, M3, etc. sont testés individuellement dans le cadre des tests unitaires
- Les modules sont combinés progressivement, c'est-à-dire un par un, et testés pour une interaction réussie
- Sur la figure 2, le module M1 et le module M2 sont combinés et testés
- Sur la figure 3, le module M3 est ajouté et testé
- Sur la figure 4, le module M4 est ajouté et des tests sont effectués pour s'assurer que tout fonctionne correctement
- Le reste des modules sont également ajoutés de manière incrémentielle à chaque étape et testés pour une intégration réussie
Fig2
Fig3
tutoriel Microsoft Dynamics Ax 2012 pour débutant
Fig4
Objectif du test incrémental
- Pour s'assurer que différents modules fonctionnent ensemble avec succès après l'intégration
- Identifiez les défauts plus tôt et à chaque phase. Cela donne aux développeurs un avantage pour identifier où se situe le problème. Comme si le test après l'intégration de M1 et M2 réussit, mais lorsque M3 est ajouté, le test échoue; cela aidera le développeur à séparer le problème
- Les problèmes peuvent être résolus au début sans trop de retouches et à moindre coût
Méthodologies de test d'intégration incrémentale
Avant de commencer avec ce sujet, j'aimerais faire une brève introduction sur Stubs et pilotes puisque nous utiliserons souvent ces termes.
Les stubs et les pilotes sont des pseudo-codes ou des codes factices utilisés dans l'intégration ou test des composants lorsqu'un ou plusieurs modules ne sont pas développés mais doivent tester un autre module.
Bouts sont utilisés dans l'approche de test descendante et sont appelés «programmes appelés». Les stubs aident à simuler l'interface entre les modules de levier inférieurs qui ne sont pas disponibles ou développés.
Conducteurs sont utilisés dans l'approche de test ascendant et sont connus sous le nom de «programmes d'appel». Les pilotes aident à simuler l'interface entre les modules de niveau supérieur qui ne sont pas développés ou disponibles.
Une question qui pourrait se poser à certains d'entre nous est pourquoi ne pas attendre que tous les modules d'application soient développés au lieu d'utiliser stub / driver avant de commencer les tests?
La réponse simple est que cela augmente le temps d'exécution du projet puisque les testeurs resteront inactifs jusqu'à ce que tous les modules soient développés. En outre, cela rend difficile l'analyse de la racine du défaut. Ce type d'approche de test est connu sous le nom de test d'intégration Big-Bang.
Maintenant que nous avons couvert les stubs et les pilotes, passons à différentes méthodologies de test incrémental:
# 1) De haut en bas
Comme son nom l'indique, les tests ont lieu de haut en bas, c'est-à-dire du module central au sous-module. Les modules encadrant la couche supérieure de l'application sont testés en premier.
Cette approche suit le flux structurel de l'application en cours de test. Les modules ou composants non disponibles ou non développés sont remplacés par des stubs.
Comprenons cela avec un exemple:
- Module : Connexion au site Web aka L
- Module : Ordre aka O
- Récapitulatif de la commande du module aka OS (pas encore développé)
- Module : Paiement aka P
- Module Paiement en espèces aka CP
- Module de paiement par débit / crédit aka DP (pas encore développé)
- Module Wallet Payment aka WP (pas encore développé)
- Module: Reporting aka R (pas encore développé)
Approche de test d'intégration incrémentielle descendante
Les cas de test suivants seront dérivés:
Cas de test 1: Le module L et le module O seront intégrés et testés
Cas de test 2: Les modules L, O et P seront intégrés et testés
Cas de test 3: Les modules L, O, P et R seront intégrés et testés.
Et ainsi de suite, d'autres cas de test sont dérivés.
Ce type de test où tous les modules d'une couche sont d'abord intégrés et testés est appelé «largeur d'abord». Une autre catégorie est «la profondeur d'abord».
Les cas de test suivants seront dérivés pour «la profondeur d'abord»:
Cas de test 1: Le module L et le module O seront intégrés et testés
Cas de test 2: Les modules L, O et OS seront intégrés et testés
Cas de test 3: Les modules L, O, OS, P seront intégrés et testés
Cas de test 4: Les modules L, O, OS, P, CP seront intégrés et testés
Et ainsi de suite, d'autres cas de test sont dérivés.
Mérites de la méthodologie descendante
- Exposition précoce des défauts d'architecture
- Il décrit le fonctionnement d'une application dans son ensemble dans les premiers stades et aide à la divulgation précoce des défauts de conception.
- Les principaux points de contrôle sont testés tôt
Mérites de la méthodologie descendante
- Des modules importants sont testés en fin de cycle
- Il est très difficile d'écrire des conditions de test
- Un stub n'est pas une implémentation parfaite du module associé. Il simule simplement le flux de données entre deux modules
# 2) De bas en haut
Dans cette approche, les tests se déroulent de bas en haut, c'est-à-dire que les modules de la couche inférieure sont intégrés et testés en premier, puis séquentiellement d'autres modules sont intégrés à mesure que nous progressons. Les modules non disponibles ou non développés sont remplacés par des pilotes.
Examinons un exemple ci-dessous pour une meilleure compréhension:
Les modules Rank, Marks, Percentage et Sports Grade ne sont pas encore développés, ils seront donc remplacés par le Driver associé:
Approche de test d'intégration incrémentale ascendante
Les cas de test suivants seront dérivés:
Cas de test 1: Test unitaire du module Pratique et Théorie
Cas de test 2: Intégration et test des modules Marks-Practical-Theory
Cas de test3 : Intégration et test des modules Percentage-Marks-Practical-Theory
Cas de test 4: Test unitaire de Module Sports Grade
Cas de test5: Intégration et test des modules Rank-Sports Grade-Percentage-Marks-Practical-Theory
VPN gratuit netflix Japon
Mérites de la méthodologie ascendante
- Cette méthodologie est très utile pour les applications où un modèle de conception ascendant est utilisé
- Il est plus facile de créer des conditions de test dans une approche ascendante
- Commencer les tests au niveau inférieur de la hiérarchie signifie tester les modules ou fonctionnalités critiques à un stade précoce. Cela aide à la découverte précoce des erreurs
- Les défauts d'interface sont détectés à un stade précoce
Les mérites de la méthodologie ascendante
- Les pilotes sont plus difficiles à écrire que les stub
- Les défauts de conception sont détectés à un stade ultérieur
- Dans cette approche, nous n'avons pas d'application fonctionnelle jusqu'à ce que le dernier module soit construit
- Le pilote n'est pas une implémentation complète du module associé. Il simule simplement le flux de données entre deux modules.
# 3) Test de sandwich
Cette approche est un hybride de méthodologie descendante et ascendante. Le stub et les pilotes sont utilisés pour les modules incomplets ou non développés.
Approche de test
- Une couche intermédiaire est identifiée à partir de laquelle les tests ascendants et descendants sont effectués. Cette couche intermédiaire est également appelée couche cible
- La couche cible est identifiée selon l'approche heuristique, c'est-à-dire, sélectionnez une couche qui permet une utilisation minimale des stubs et des pilotes
- Les tests descendants commencent à partir de la couche intermédiaire et se déplacent vers le bas vers les modules de niveau inférieur. Cette couche sous la couche intermédiaire est connue sous le nom de couche inférieure
- Les tests ascendants commencent également à partir de la couche intermédiaire et remontent vers les modules de la couche supérieure. Cette couche au-dessus de la couche intermédiaire est appelée couche supérieure
- Avec l'utilisation de stubs et de pilotes, l'interface utilisateur et les fonctions des modules de niveau inférieur sont testées respectivement
- Au final, il ne reste que la couche intermédiaire pour l'exécution du test final
Exemple:
Les cas de test suivants peuvent être dérivés avec la stratégie de test sandwich:
Cas de test 1: Testez A, X, Y et Z individuellement - où le test A relève du test de la couche supérieure et les tests X, Y et Z sont soumis aux tests de la couche inférieure
Cas de test 2: Test A, G, H et I
Cas de test 3: Tester G, X et Y
Cas de test 4: Main d'essai Z
Cas de test5: Test A, G, H, I, X, Y et Z
Mérites de la méthodologie de test sandwich
- C'est très bénéfique pour un grand projet qui a plusieurs sous-projets
- La méthodologie de test descendante et ascendante peut fonctionner côte à côte
Inconvénients de la méthodologie de test sandwich
- Avant l'unification des modules, les sous-systèmes et leurs interfaces ne sont pas testés de manière approfondie
- Coût plus élevé en raison de l'implication de la méthodologie de test descendante et ascendante
- Ce type de test n'est pas conseillé pour un système où les modules sont fortement interdépendants
Conclusion
Les tests incrémentaux sont couverts par les tests d'intégration. Dans cette approche de test, les tests d'intégration sont effectués sur le module individuel dans le cadre des tests unitaires et dans la phase suivante, les modules ou composants de l'application sont intégrés de manière incrémentielle et les tests sont effectués sur des modules combinés en tant que groupe.
Sur trois méthodologies de test d'intégration incrémentale, le choix de la méthodologie à choisir dépend de la structure de l'application et également de la position des modules à haut risque.
Les trois méthodologies de test incrémentiel relèvent de la catégorie horizontale en raison des aspects comportementaux suivants:
- Les trois méthodologies se concentrent sur les tests de couches
- Tous considèrent une conception structurelle ou hiérarchique
- Tous intègrent des couches de manière incrémentielle
Les mérites:
Avec cette approche de test, il est plus facile d'identifier rapidement les défauts et aide également le développeur à déterminer la cause du problème. Puisqu'elle utilise les bases des tests structurés, cette approche de test est très efficace et précise.
Démérites:
Ce type d'approche de test prend du temps en raison de l'utilisation de stubs et de pilotes. C'est également répétitif.
À propos de auteur: Ce tutoriel utile est écrit par Neha B. Elle est analyste principale de la qualité certifiée ISTQB avec plus de 8 ans d'expérience.
Faites-nous savoir si vous avez des questions / suggestions.
lecture recommandée
- Meilleurs outils de test de logiciels 2021 (Outils d'automatisation des tests QA)
- Qu'est-ce que le test de composant ou le test de module (apprendre avec des exemples)
- Téléchargement du livre électronique sur les tests
- Test fonctionnel vs test non fonctionnel
- Qu'est-ce que les tests d'endurance dans les tests logiciels (exemples)
- Tutoriel de test par paires ou de test toutes paires avec outils et exemples
- Types de tests logiciels: différents types de tests avec des détails
- Tutoriel de test de volume: exemples et outils de test de volume