Guide de test fonctionnel complet avec ses types et son exemple

complete functional testing guide with its types

Un didacticiel de test fonctionnel complet et détaillé avec des types, des techniques et des exemples:

Qu'est-ce que le test fonctionnel?

Le test fonctionnel est une sorte de test boîte noire qui est effectué pour confirmer que la fonctionnalité d'une application ou d'un système se comporte comme prévu.

Il est fait pour vérifier toutes les fonctionnalités d'une application.

LISTE des tutoriels couverts dans cette série:

Tutoriel n ° 1: Qu'est-ce que le test fonctionnel (ce tutoriel)
Tutoriel n ° 2: Questions d'entrevue de test de fonctionnalité
Tutoriel n ° 3: Principaux outils de test d'automatisation fonctionnelle
Tutoriel n ° 4: Qu'est-ce que les tests non fonctionnels?
Tutoriel n ° 5: Différence entre unité, fonctionnelle et L'intégration Essai
Tutoriel # 6 : Pourquoi les tests fonctionnels et de performance doivent être effectués simultanément

Outils:

Tutoriel n ° 7: Automatisation des tests fonctionnels avec Ranorex Studio
Tutoriel n ° 8: Nouvelles fonctionnalités de l'outil fonctionnel UFT
Tutoriel n ° 9: Automatisation fonctionnelle Cross Browser avec Parrot QA Tool
Tutoriel n ° 10: Tutoriel Jubula Open Source Tool pour tester les fonctionnalités

Ce que vous apprendrez:

• Introduction aux tests fonctionnels
  • Types de tests fonctionnels
  • Traiter
  • Critères d'entrée / sortie
    • Critères d'admission:
    • Critère de sortie:
  • Étapes impliquées
  • Approcher
  • Techniques de test fonctionnel
    • # 1) Tests système / basés sur l'utilisateur final
    • # 2) Tests d'équivalence
    • # 3) Tests de valeur limite
    • # 4) Tests basés sur la décision
    • # 5) Tests de débit alternatifs
    • # 6) Tests ad hoc
  • Automatisation des tests fonctionnels
  • Avantages
  • Limites
  • Conclusion
  • lecture recommandée

Introduction aux tests fonctionnels

Il doit y avoir quelque chose qui définit ce qu'est un comportement acceptable et ce qui ne l'est pas.

Ceci est spécifié dans une spécification fonctionnelle ou d'exigence. C'est un document qui décrit ce qu'un utilisateur est autorisé à faire, qu'il peut déterminer la conformité de l'application ou du système à celui-ci. De plus, cela peut parfois impliquer la validation des scénarios réels du côté commercial.

Par conséquent, les tests de fonctionnalité peuvent être effectués via deux techniques populaires :

• Test basé sur les exigences: Contient toutes les spécifications fonctionnelles qui constituent la base de tous les tests à réaliser.
• Tests basés sur des scénarios commerciaux: Contient les informations sur la façon dont le système sera perçu du point de vue des processus métier.

Les tests et l'assurance qualité sont une partie importante du processus SDLC. En tant que testeur, nous devons être conscients de tous les types de tests, même si nous n'y sommes pas directement impliqués quotidiennement.

Les tests étant un océan, leur portée est si vaste et nous avons des testeurs dédiés qui effectuent différents types de tests . Il est fort probable que nous soyons tous familiers avec la plupart des concepts, mais cela ne fera pas de mal de tout organiser ici.

Types de tests fonctionnels

Les tests fonctionnels comportent de nombreuses catégories et celles-ci peuvent être utilisées en fonction du scénario.

Les types les plus importants sont brièvement décrits ci-dessous:

Test unitaire :

Les tests unitaires sont généralement effectués par un développeur qui écrit différentes unités de code pouvant être liées ou non pour obtenir une fonctionnalité particulière. Son, cela implique généralement d'écrire des tests unitaires qui appelleraient les méthodes dans chaque unité et les valideraient lorsque les paramètres requis sont passés, et sa valeur de retour est celle attendue.

La couverture de code est une partie importante des tests unitaires où les cas de test doivent exister pour couvrir les trois suivants:

i) Couverture de ligne
ii) Couverture du chemin de code
iii) Couverture de la méthode

Test de santé mentale : Des tests qui sont effectués pour s'assurer que toutes les fonctionnalités majeures et vitales de l'application / du système fonctionnent correctement. Cela se fait généralement après un test de fumée.

Test de fumée : Les tests effectués après la publication de chaque build sont testés pour garantir la stabilité de la build. Il est également appelé test de vérification de construction.

Tests de régression : Tests effectués pour s'assurer que l'ajout de nouveau code, d'améliorations, de correction de bogues ne rompt pas la fonctionnalité existante ou ne provoque aucune instabilité et fonctionne toujours selon les spécifications.

Les tests de régression n'ont pas besoin d'être aussi étendus que les tests fonctionnels réels, mais doivent garantir juste la quantité de couverture pour certifier que la fonctionnalité est stable.

Tests d'intégration : Lorsque le système repose sur plusieurs modules fonctionnels qui peuvent fonctionner parfaitement individuellement, mais doivent fonctionner de manière cohérente lorsqu'ils sont regroupés pour atteindre un scénario de bout en bout, la validation de ces scénarios est appelée test d'intégration.

Test bêta / d'utilisabilité : Le produit est exposé au client réel dans une production comme un environnement et ils testent le produit. Le confort de l’utilisateur en découle et les commentaires sont pris en compte. Ceci est similaire à celui des tests d'acceptation par l'utilisateur.

Représentons-le dans un organigramme simple:

Test du système fonctionnel:

Test du système est un test effectué sur un système complet pour vérifier s'il fonctionne comme prévu une fois que tous les modules ou composants sont intégrés.

Test de bout en bout est effectuée pour vérifier la fonctionnalité du produit. Ce test est effectué uniquement lorsque le test d'intégration du système est terminé, y compris les exigences fonctionnelles et non fonctionnelles.

=> Différence entre les tests unitaires, fonctionnels et d'intégration

Traiter

Ce processus de test comporte trois étapes principales:

Approche, techniques et exemples

Les tests fonctionnels ou comportementaux génèrent une sortie basée sur les entrées données et déterminent si le système fonctionne correctement selon les spécifications.

Par conséquent, la représentation picturale ressemblera à celle ci-dessous:

Critères d'entrée / sortie

Critères d'admission:

• Le document de spécification des exigences est défini et approuvé.
• Des cas de test ont été préparés.
• Les données de test ont été créées.
• L'environnement de test est prêt, tous les outils nécessaires sont disponibles et prêts.
• L'application complète ou partielle est développée et testée à l'unité et est prête à être testée.

Critère de sortie:

• L'exécution de tous les cas de test fonctionnels est terminée.
• Aucun bogue critique ou P1, P2 n'est ouvert.
• Les bogues signalés ont été reconnus.

Étapes impliquées

Les différentes étapes impliquées dans ce test sont mentionnées ci-dessous:

• La toute première étape consiste à déterminer la fonctionnalité du produit qui doit être testée et comprend le test des principales fonctionnalités, la condition d'erreur et les messages, les tests d'utilisabilité, c'est-à-dire si le produit est convivial ou non, etc.
• L'étape suivante consiste à créer les données d'entrée pour la fonctionnalité à tester conformément à la spécification des exigences.
• Plus tard, à partir de la spécification d'exigence, la sortie est déterminée pour la fonctionnalité testée.
• Les cas de test préparés sont exécutés.
• La sortie réelle, c'est-à-dire la sortie après l'exécution du scénario de test et la sortie attendue (déterminée à partir de la spécification d'exigence) sont comparées pour déterminer si la fonctionnalité fonctionne comme prévu ou non.

Approcher

Différents types de scénarios peuvent être imaginés et créés sous la forme de «cas de test». En tant que spécialistes du contrôle qualité, nous savons tous à quoi ressemble le squelette d'un scénario de test.

Il comporte principalement quatre parties:

• Résumé du test
• Conditions préalables
• Étapes de test et
• Résultats attendus.

Tenter de créer tous les types de tests est non seulement impossible mais aussi long et coûteux.

En règle générale, nous voudrions découvrir le maximum de bogues sans aucune fuite avec les tests existants. Par conséquent, le QA doit utiliser des techniques d'optimisation et élaborer une stratégie sur la manière dont il aborderait les tests.

Expliquons cela avec un Exemple.

Exemples de cas d'utilisation des tests fonctionnels:

Prenez un portail SIRH en ligne où l'employé se connecte avec son compte d'utilisateur et son mot de passe. Sur la page de connexion, il y a deux champs de texte pour le nom d'utilisateur et le mot de passe, et deux boutons: Connexion et Annuler. Une connexion réussie amène l'utilisateur à la page d'accueil de HRMS et l'annulation annule la connexion.

Les spécifications sont indiquées ci-dessous:

#1 ) Le champ de l'ID utilisateur prend un minimum de 6 caractères, un maximum de 10 caractères, des chiffres (0-9), des lettres (a-z, A-z), des caractères spéciaux (seuls les traits de soulignement, point, tiret sont autorisés) et il ne peut pas être laissé vide. L'ID utilisateur doit commencer par un caractère ou un nombre et non par des caractères spéciaux.

#deux) Le champ Mot de passe prend un minimum de 6 caractères, un maximum de 8 caractères, des chiffres (0-9), des lettres (a-z, A-Z), des caractères spéciaux (tous) et ne peut pas être vide.

L'approche de base pour tester ce scénario peut être classée en deux grandes catégories:

1. Test positif et
2. Test négatif

Bien entendu, chacune de ces catégories a sa sous-section de tests qui seront effectués.

Tests positifs sont des tests heureux qui sont effectués pour s'assurer que le produit répond - au moins aux exigences de base vitales pour l'utilisation par le client.

Scénarios négatifs assurez-vous que le produit se comporte correctement même s'il est soumis à des données inattendues.

Lecture suggérée => Qu'est-ce que le test négatif et comment écrire des cas de test négatifs

Maintenant, permettez-moi d'essayer de structurer les techniques de test en utilisant un organigramme ci-dessous. Nous entrerons dans les détails de chacun de ces tests.

Techniques de test fonctionnel

# 1) Tests système / basés sur l'utilisateur final

Le système testé peut avoir de nombreux composants qui, lorsqu'ils sont couplés ensemble, réalisent le scénario de l'utilisateur.

dans le Exemple , un scénario client comprendrait des tâches telles que le chargement d'une application SGRH, la saisie des informations d'identification correctes, l'accès à la page d'accueil, l'exécution de certaines actions et la déconnexion du système. Ce flux particulier doit fonctionner sans aucune erreur pour un scénario métier de base.

fausse adresse e-mail que je peux utiliser

Quelques exemples sont donnés ci-dessous:

Ceci est un exemple de base de la façon dont les cas de test sont créés pour des situations. Le format ci-dessus s'appliquera également à tous les tests ci-dessous. Par souci de solidité conceptuelle, je n'ai fait que quelques tests simples ci-dessus et ci-dessous.

# 2) Tests d'équivalence

Dans Partitionnement d'équivalence , les données de test sont séparées en diverses partitions appelées classes de données d'équivalence. Les données de chaque partition doivent se comporter de la même manière, par conséquent, une seule condition doit être testée. De même, si une condition dans une partition ne fonctionne pas, aucune des autres ne fonctionnera.

Par exemple , dans le scénario ci-dessus, le champ de l'ID utilisateur peut avoir un maximum de 10 caractères, donc la saisie de données> 10 doit se comporter de la même manière.

# 3) Tests de valeur limite

Les tests de limites impliquent des limites de données pour l'application et valident son comportement.

Par conséquent, si les entrées sont fournies au-delà des valeurs limites, alors il est considéré comme un test négatif. Ainsi, un minimum de 6 caractères pour l'utilisateur définit la limite de délimitation. Tests écrits pour avoir un identifiant d'utilisateur<6 characters are boundary analysis tests.

# 4) Tests basés sur la décision

Les tests basés sur la décision sont centrés sur l'idéologie des résultats possibles du système lorsqu'une condition particulière est remplie.

Dans le scénario ci-dessus, les tests décisionnels suivants peuvent être immédiatement dérivés:

1. Si de mauvaises informations d'identification sont saisies, il doit l'indiquer à l'utilisateur et recharger la page de connexion.
2. Si l'utilisateur entre les informations d'identification correctes, il doit passer à l'interface utilisateur suivante.
3. Si l'utilisateur entre les informations d'identification correctes mais souhaite annuler la connexion, il ne doit pas amener l'utilisateur à l'interface utilisateur suivante et recharger la page de connexion.

# 5) Tests de débit alternatifs

Des tests de chemin alternatifs sont exécutés pour valider toutes les manières possibles qui existent, autres que le flux principal pour accomplir une fonction.

# 6) Tests ad hoc

Lorsque la plupart des bogues sont découverts grâce aux techniques ci-dessus, tests ad hoc sont un excellent moyen de découvrir les écarts qui ne sont pas observés plus tôt. Celles-ci sont effectuées avec la mentalité de briser le système et de voir s'il répond gracieusement.

Par exemple , un exemple de cas de test serait:

• Un utilisateur est connecté, mais l'administrateur supprime le compte utilisateur pendant qu'il effectue certaines opérations. Il serait intéressant de voir comment l'application gère cela avec élégance.

Tests fonctionnels vs non fonctionnels:

Tests non fonctionnels se concentrer sur la qualité de l'application / du système dans son ensemble. Par conséquent, il essaie de déduire les performances du système selon les exigences du client, contrairement à la fonction qu'il exécute.

=> Lisez la différence exacte ici

Automatisation des tests fonctionnels

Pouvons-nous automatiser les tests fonctionnels?

Avec l'automatisation, l'effort manuel peut être réduit, le temps peut être économisé, le glissement de bogues peut être évité et l'efficacité peut être augmentée.

Cependant, il n'est pas possible d'automatiser tout et chacun. Ces tests peuvent être automatisés, mais l'utilisateur doit travailler sur des cas de test pour que l'automatisation soit effectuée. Il est important de trouver les bons scénarios de test à automatiser avec un outil approprié.

L'automatisation des cas fonctionnels peut avoir des inconvénients, comme si le nombre de cas de test est beaucoup plus élevé et est régressé encore et encore (ce qui doit être fait), le développeur pourrait alors rencontrer un problème pour valider les modifications du code.

Plusieurs fois, lors de l'analyse des évasions de défauts, la cause principale et pérenne des évasions semble avoir un manque de couverture de test dans une fonction particulière.

Encore une fois, il y a plusieurs causes à cela, comme le manque d'environnements, le manque de testeurs, trop de fonctions livrées, moins de temps pour couvrir tous les aspects des tests et parfois simplement l'ignorer.

Bien que des équipes de test dédiées puissent effectuer des tests détaillés sur chaque sprint ou chaque cycle de test, des défauts existeront toujours et il y aura toujours des défauts qui pourraient être manqués. C'est l'un des besoins fondamentaux pour mettre en place l'automatisation des tests, ce qui permet une nette amélioration de l'efficacité du processus de test global et de la couverture des cas de test.

Bien que les tests automatisés ne puissent jamais remplacer les tests manuels, avoir un mélange idéal des deux s'avérera essentiel pour obtenir la qualité souhaitée dans les projets logiciels.

Considérations d'automatisation:

#1) Sélectionnez le bon outil d'automatisation : Il existe plusieurs outils disponibles sur le marché, choisir un outil d'automatisation est une véritable tâche ardue! Cependant, vous pouvez faire une liste d'exigences, sur la base de laquelle vous pouvez sélectionner l'outil d'automatisation à utiliser.

Certains aspects principaux à considérer comprennent:

• Sélectionnez un outil qui sera facile à utiliser par tous les membres du contrôle qualité de l'équipe, s'ils ne possèdent pas déjà les compétences requises.
• L'outil peut être utilisé dans différents environnements. Pour Exemple : Les scripts peuvent-ils être créés sur une plate-forme OS et exécutés sur une autre? Avez-vous besoin de l'automatisation de la CLI, de l'automatisation de l'interface utilisateur, de l'automatisation des applications mobiles ou de tout?
• L'outil doit avoir toutes les fonctionnalités dont vous avez besoin. Pour Exemple : Si certains testeurs ne sont pas bien familiarisés avec un langage de script, l'outil doit avoir une fonction d'enregistrement et de lecture, puis prendre en charge la conversion du script enregistré vers le langage de script souhaité. De même, si vous avez également besoin de l'outil pour prendre en charge les tests de construction automatisés, les rapports spécifiques et la journalisation, il doit également être en mesure de le faire.
• L'outil doit être capable de prendre en charge la réutilisabilité des cas de test en cas de modifications de l'interface utilisateur.

Outils d'automatisation : Il existe de nombreux outils disponibles pour l'automatisation fonctionnelle. Le sélénium est probablement un favori, mais il existe d'autres outils open source comme Sahi, Watir, Robotium, AutoIt, etc.

Plusieurs outils d'automatisation des tests sont disponibles sur le marché. Mais le choix de l'outil approprié est très important pour l'organisation. Cela peut dépendre de l'exigence, de la facilité d'utilisation et le coût joue ici un rôle majeur.

Voici quelques-uns des meilleurs outils de test fonctionnel:

• Sélénium
• QTP
• Junit
• Loadrunner
• SAVON
• TestComplete

=> Consultez cette liste complète des meilleurs outils d'automatisation fonctionnelle

#deux) Choisissez les bons cas de test à automatiser : Si vous voulez tirer le meilleur parti de l'automatisation, il est essentiel d'être intelligent sur le type de tests que vous choisissez d'automatiser. S'il y a des tests qui nécessitent une configuration et des configurations activées et désactivées pendant l'exécution des tests, il vaut mieux les laisser non automatisés.

Par conséquent, vous pouvez automatiser les tests qui:

• Besoin d'être exécuté à plusieurs reprises.
• Exécutez avec différents types de données.
• Certains cas de test P1, P2 nécessitent beaucoup d'efforts et de temps.
• Tests sujets aux erreurs.
• Ensemble de tests qui doivent être exécutés dans différents environnements, navigateurs, etc.

# 3) Équipe d'automatisation dédiée : Ceci est probablement négligé dans la plupart des organisations et l'automatisation est imposée à tous les membres de l'équipe QA.

Chaque membre de l'équipe a des niveaux d'expérience, des compétences, des niveaux d'intérêt, une bande passante pour prendre en charge l'automatisation, etc.

Dans des situations comme celle-ci, il est recommandé de procéder à une analyse de tous les membres de l’équipe et de faire en sorte que certains membres se consacrent uniquement à l’automatisation.

L'activité d'automatisation nécessite du temps, des efforts, des connaissances et une équipe dédiée qui aidera à obtenir les résultats requis au lieu de surcharger tous les membres de l'équipe avec des tests manuels et automatisés.

# 4) Tests basés sur les données: Les cas de test automatisés qui nécessitent plusieurs ensembles de données doivent être bien écrits afin qu'ils puissent être réutilisables. Les données peuvent être écrites dans des sources telles que du texte ou un fichier de propriétés, des fichiers XML ou lues à partir d'une base de données.

Quelle que soit la source de données, la création de données d'automatisation bien structurées facilite la maintenance du cadre et permet aux scripts de test existants d'être utilisés à leur plein potentiel.

# 5) Les modifications de l'interface utilisateur ne doivent pas interrompre les tests: Les scénarios de test que vous créez à l'aide de l'outil sélectionné doivent être en mesure de gérer les modifications potentielles de l'interface utilisateur. Par exemple, les versions antérieures du sélénium utilisaient un emplacement pour identifier les éléments de la page.

Par conséquent, si l'interface utilisateur a changé, ces éléments n'ont plus été trouvés à ces emplacements et entraîneront à leur tour l'échec massif des tests.

Par conséquent, il est important de comprendre au préalable les lacunes de l'outil et de créer les cas de test de sorte qu'il n'y ait que des modifications minimes requises en cas de modification de l'interface utilisateur.

# 6) Tests fréquents: Une fois que vous avez un bucket de test d'automatisation de base prêt, prévoyez une exécution plus fréquente de ce bucket. Cela a un avantage dans les deux sens: le premier est que vous pouvez améliorer le cadre d'automatisation et le rendre plus robuste et le second est que vous détecterez plus de bogues dans le processus.

Avantages

Vous trouverez ci-dessous les divers avantages des tests fonctionnels:

• Ce test reproduit ou est une réplique de ce qu'est le système réel, c'est-à-dire qu'il s'agit d'une réplique de ce que le produit est dans l'environnement réel. Les tests sont axés sur les spécifications selon l'utilisation du client, c'est-à-dire les spécifications du système, le système d'exploitation, les navigateurs, etc.
• Cela ne fonctionne pas sur des si et des mais ou sur des hypothèses concernant la structure du système.
• Ces tests garantissent la livraison d'un produit de haute qualité qui répond aux exigences du client et s'assure que le client est satisfait des résultats finaux.
• Il garantit de fournir un produit sans bogue qui a toutes les fonctionnalités fonctionnant selon les exigences du client.
• Des tests basés sur les risques sont effectués pour réduire les chances de tout type de risque dans le produit.

Limites

Ces tests sont effectués pour s'assurer que le produit fonctionne comme prévu et que toutes les exigences sont mises en œuvre et que le produit est exactement conforme aux exigences du client.

Cependant, il ne prend pas en compte les autres facteurs tels que les performances du produit, c'est-à-dire la réactivité, le temps de production, etc., qui sont importants et très nécessaires pour faire partie des tests avant de lancer le produit.

Désavantages

• Il existe de nombreuses chances d'effectuer des tests redondants.
• Des erreurs logiques peuvent être omises dans le produit.
• Ce test est basé sur l'exigence, si dans le cas où l'exigence n'est pas complète ou est compliquée ou n'est pas claire, l'exécution de ces tests dans un tel scénario devient difficile et peut également prendre du temps.

Par conséquent, ces deux types de tests sont nécessaires pour un produit de qualité.

Conclusion

Ce didacticiel a abordé en détail tout ce que vous devez savoir sur les tests fonctionnels, dès les bases.

Le test fonctionnel est l'un des processus de test importants car il vérifie la fonctionnalité d'un produit qui est l'aspect le plus requis et en fait l'aspect important de tout produit ou application.

A propos de l'auteur: Sanjay Zalavadia - en tant que vice-président du service client pour Zéphyr , apporte plus de 15 ans d'expérience en leadership dans les services informatiques et de support technique.

J'espère que certaines des techniques que nous avons suggérées seront utiles à tous les lecteurs. Faites-nous part de vos commentaires dans les commentaires ci-dessous.

Lecture suggérée => Tutoriel de test de fonctionnalités

lecture recommandée

• Test fonctionnel vs test non fonctionnel
• Test alpha et test bêta (un guide complet)
• Meilleurs outils de test de logiciels 2021 (Outils d'automatisation des tests QA)
• Les différences entre les tests unitaires, les tests d'intégration et les tests fonctionnels
• Types de tests logiciels: différents types de tests avec des détails
• Spock pour l'intégration et les tests fonctionnels avec sélénium
• Build Verification Testing (BVT Testing) Guide complet
• Un guide complet de tests non fonctionnels pour les débutants