Artefacts de test de logiciel - Guide détaillé

30 octobre 2021

Table des matières

  • Artefacts de test de logiciel
  • 1. Programme d'essai
  • Types de plans de test
  • Modèle de plan de test
  • Lignes directrices du plan de test
  • 2. Suite de tests
  • Qu'est-ce qu'une suite de tests ?
  • Que signifie suite ? Expliqué par l'exemple
  • Types de suites de tests
  • Caractéristiques des suites de tests
  • Modèles de suites de tests
  • Différence entre le scénario de test, la suite de tests, le plan de test et le cas de test
  • Conclusion
  • 3. Cas d'essai
  • Qu'est-ce qu'un scénario de test ?
  • Comment écrire de bons cas de test ?
  • Modèle de cas de test
  • Exemple de cas de test Format de cas de test standard
  • Outils de gestion des cas de test
  • 4. Scénario de test
  • Qu'est-ce qu'un script de test ?
  • Tester le langage de script avec un exemple
  • Quel type de code est utilisé ?
  • Comment créer un script de test ?
  • Comment exécuter un script de test ?
  • 5. Données d'essai
  • Qu'est-ce que les données de test ?
  • Importance des données de test
  • Types de données d'essai
  • Données de test dans les tests
  • Bonnes propriétés des données de test
  • Techniques de préparation ou de génération de données de test
  • Approches pour tester la génération de données
  • Outils de génération de données de test
  • Gestion des données de test (TDM)
  • Limites des données de test
  • Conclusion
  • Articles recommandés

3. Cas d'essai

Qu'est-ce qu'un scénario de test ?

image 617dd4e6992fd

Un cas de test est un ensemble documenté de conditions préalables ou préalables, de procédures et de postconditions ou de résultats attendus utilisés par un testeur pour déterminer que le système soumis au test satisfait aux exigences, c'est-à-dire qu'il fonctionne correctement ou non.

Il contient des données de test, des étapes de test et des conditions pour vérifier la caractéristique ou la fonctionnalité particulière du logiciel.



Un cas de test peut comprendre plusieurs scripts de test et faire partie de la suite de tests contenant plusieurs cas de test.

Il peut être de deux types :

    Cas de test de haut niveau: Un cas de test contenant des informations abstraites pour les données d'entrée, les conditions préalables, les résultats attendus, les postconditions et les actions associées en fonction des conditions de test est appelé un cas de test de haut niveau.Cas de test de bas niveau: Un scénario de test contenant des informations factuelles pour les données d'entrée, les conditions préalables, les résultats attendus, les postconditions et les actions associées en fonction des conditions de test est appelé scénario de test de bas niveau.

Comment écrire de bons cas de test ?

Quelques bonnes pratiques pour écrire un bon cas de test :

1. Mise en œuvre des techniques de test de logiciels

Puisqu'il n'est pas possible de vérifier tous les cas de test possibles, le test de logiciel Ces techniques aident les testeurs à identifier les cas de test avec la probabilité maximale de trouver des défauts. Voici quelques-unes des techniques de test de logiciels :

    Partition d'équivalence (EP) :La technique EP divise cette plage de valeurs ayant un comportement similaire en parties ou groupes égaux.Technique de devinette d'erreur :Cette technique de test n'est pas une méthode formelle de test et repose fortement sur l'expérience d'un testeur. La technique consiste à anticiper ou à deviner les erreurs qui pourraient survenir dans test manuel .Analyse des valeurs limites (BVA) :Cette technique de test de logiciel définit les limites d'une plage de valeurs spécifiée.Technique de transition d'état :Lorsqu'en raison d'une action particulière, le comportement du logiciel passe d'un état à un autre, nous utilisons cette technique de test de logiciel.

2. Création de cas de test en fonction de l'utilisateur final

Le logiciel est développé pour un utilisateur final, et les cas de test doivent donc être créés en fonction de l'utilisateur final. Ainsi, les cas de test doivent répondre aux exigences du client et doivent être faciles à utiliser.

3. Aucune hypothèse

La fonctionnalité et les caractéristiques de l'application logicielle ne doivent pas être supposées et doivent être conformes aux documents de spécification.

4. Cohérence dans les résultats des cas de test.

Les cas de test doivent générer des résultats cohérents et identiques à chaque fois que le test est exécuté, quelle que soit la personne qui effectue le test.

5. Aucun cas de test ne doit être répété

Il existe déjà un nombre considérable de cas de test, et il n'est donc pas nécessaire de répéter des cas de test déjà définis. Si un cas de test est requis par un autre cas de test, appelez-le en utilisant l'ID de cas de test de la colonne préconditionnée.

6. Simple et transparent

Les cas de test doivent être simples, clairs et concis pour que tout le monde puisse les comprendre et pas seulement l'auteur.

Un langage fort comme entrer des données, aller à la page d'accueil, cliquer dessus, etc. doit être utilisé afin que les étapes du test soient faciles à comprendre et que l'exécution du test devienne plus rapide.

7. Examen par les pairs

Une fois la création du cas de test terminée, elle doit être examinée par les collègues ou les pairs pour découvrir les défauts dans la conception du cas de test que l'auteur a peut-être manqués.

8. Assurez une couverture à 100 %

Une matrice de traçabilité est utilisée pour assurer une couverture de test à 100 % afin qu'aucune fonction ou condition spécifiée dans l'exigence logicielle ne soit laissée non testée.

9. Stabilité de l'environnement de test

Les cas de test utilisés dans un environnement particulier ne doivent pas le rendre inutile. Une fois l'exécution du cas de test terminée, l'environnement de test doit revenir à son état de pré-test, en particulier dans les tests de configuration.

10. Cas de test identifiables

Les cas de test doivent avoir une identification appropriée afin qu'ils puissent être facilement identifiables lors du suivi des défauts ou de l'identification des exigences logicielles à un stade ultérieur.

Outre les pratiques ci-dessus, voici quelques informations que le testeur doit inclure lors de la rédaction du cas de test :

  • Pas plus de 15 étapes ne doivent être présentes dans un scénario de test.
  • Le cas de test doit contenir des informations sur la manière dont les tests du système se dérouleront.
  • Les actions, les résultats attendus, les intrants et les extrants doivent être inclus.
  • Offrir une alternative aux tests préalables.
  • La configuration de test doit contenir des informations telles que le matériel, le système d'exploitation, la version de l'application testée, l'accès de sécurité, le logiciel, l'heure de la journée, les données physiques ou logiques, les prérequis et d'autres informations relatives à la configuration pertinentes pour les exigences testées.
  • Une description du logiciel ou de la fonctionnalité en cours de test doit être présente.
  • Les preuves ou les pièces jointes liées aux tests doivent être présentes.
  • Les commentaires sur les résultats attendus des entrées et l'objectif doivent figurer dans le script de test automatisé.
  • Utilisez la casse active dans le script de test.

Modèle de cas de test

Les éléments suivants font partie du modèle de cas de test. Cependant, les entreprises utilisent souvent des outils de gestion de cas de test, et donc le modèle ou le format des cas de test est déterminé par cet outil.

ID de la suite de tests Il indique l'ID de la suite de tests à laquelle appartient le cas de test.
ID de cas de test Il s'agit de l'ID du cas de test.
Résumé du cas de test Il définit l'objectif ou le résumé du cas de test.
Exigence connexe Il s'agit de l'ID d'exigence que le cas de test trace ou relie.
Conditions préalables Ce sont les conditions préalables ou les prérequis qui doivent être satisfaits avant le début de l'exécution du test.
Script/procédure de test C'est la procédure étape par étape de l'exécution du test.
Données de test Les données de test ou les liens associés qui seront utilisés dans le test.
résultat attendu Les résultats de cas de test attendus.
Résultat actuel Les résultats réels du cas de test après avoir effectué le test.
Statut Cela peut être une réussite ou un échec. L'autre statut inclut « Non exécuté » si le test n'est pas effectué et « Bloqué » si le test est bloqué.
Remarques Commentaires liés au scénario de test ou à l'exécution du test.
Créé par Nom de l'auteur du scénario de test.
Date de création Date de création du cas de test.
Exécuté par Nom de la personne qui a effectué le test.
Date de l'exécution Date d'exécution du test.
Environnement d'essai Logiciel ou matériel ou réseau utilisé pour l'exécution des tests.

Exemple de cas de test Format de cas de test standard

ID de la suite de tests TS1
ID de cas de test TC1
Résumé du cas de test Pour vérifier la fonctionnalité de paiement d'un produit
Exigence connexe RS1
Conditions préalables 1. L'utilisateur est connecté.2. Le panier est ajouté avec les produits.
Script/procédure de test 1. Après l'ajout du produit, cliquez sur le bouton de paiement.2. Entrez l'adresse et les coordonnées.3. Sélectionnez le mode de paiement.4. Entrez les détails liés à la méthode de paiement.5. Effectuer le paiement.
Données de test 1. Adresse et coordonnées.2. Mode de paiement : carte de crédit, carte de débit, UPI, portefeuille, Net Banking.3. Détails de paiement
résultat attendu 1. Si les détails de paiement sont valides, redirigez-vous depuis la passerelle de paiement et affichez le message de paiement réussi.2. Si les détails de paiement ne sont pas valides, redirigez vers la passerelle de paiement et affichez le message d'échec du paiement.
Résultat actuel 1. Si les détails de paiement sont valides, les résultats sont comme prévu.2. Si les détails de paiement ne sont pas valides, les résultats sont comme prévu.
Statut Passe
Remarques La fonctionnalité de paiement fonctionne correctement.
Créé par Jean
Date de création 19-04-2020
Exécuté par Marie
Date de l'exécution 05-12-2020
Environnement d'essai Système d'exploitation : Windows 10Navigateur : Chrome 85

Outils de gestion des cas de test

Les outils d'automatisation utilisés pour gérer et maintenir les cas de test sont appelés outils de gestion de test.

Leurs principales caractéristiques sont :

un. Traçabilité : Les cas de test, les exigences et leur exécution sont tous liés par des outils de telle sorte que chacun d'eux peut être relié les uns aux autres pour vérifier la couverture des tests.

deux. Exécution des cas de test et enregistrement des résultats : Les outils facilitent l'exécution des cas de test et l'enregistrement des résultats obtenus.

3. Protection du boîtier de test : Le contrôle de version ne doit pas être inadéquat car les cas de test doivent être réutilisés et doivent donc être protégés contre la perte ou la corruption. Certaines fonctionnalités incluses pour cela sont:

  • Gestion des versions
  • Sauvegarde hors site
  • Conventions de nommage et de numérotation
  • Accès en lecture seule
  • Accès contrôlé

Quatre. Documentation des cas de test : Les outils de gestion de test peuvent être utilisés pour accélérer la création de cas de test à l'aide d'un modèle.

5. Suivi automatisé des défauts : Les tests échoués peuvent être automatiquement liés au bug tracker dans les outils de gestion des tests et attribués aux développeurs, tout en étant suivis par des notifications par e-mail.