Dans ce dernier volet des techniques basées sur les spécifications, je vous propose de découvrir celle sur les tests de cas d’utilisation.

PRÉSENTATION DE LA TECHNIQUE

DÉFINITION ISTQB

Le test de cas d’utilisation fournit des tests de transactions basés sur les scénarios qui simulent l’usage du système. Des cas d’usage sont définis en termes d’interactions entre les acteurs et le système qui effectue des actions. Les acteurs peuvent être des utilisateurs ou des systèmes extérieurs.

APPLICATION

Le test des cas d’utilisation est en général appliqué aux niveaux de test système et acceptation. Il peut être utilisé pour le test d’intégration en fonction du niveau d’intégration et même au niveau composant en fonction du comportement du composant.

Les cas d’utilisation servent souvent de base au test de performance parce qu’ils représentent un usage réaliste du système. Les scénarios décrits dans les cas d’utilisation peuvent être affectés à des utilisateurs virtuels pour créer une charge réaliste sur le système.

LIMITATIONS/DIFFICULTÉS/RISQUES

Pour être valides, les cas d’utilisation doivent représenter des transactions réalistes avec l’utilisateur. L’information doit provenir d’un utilisateur ou d’un représentant des utilisateurs. La valeur d’un cas d’utilisation est diminuée si celui-ci ne représente pas les activités d’un utilisateur réel.

Pour que la couverture de test puisse être rigoureuse, il est important de disposer d’une description précise des différents chemins (flux) possibles. Les cas d’utilisation doivent être considérés comme un guide, mais pas comme une définition exhaustive de ce qui doit être testé car ils ne fournissent pas systématiquement une définition claire de l’ensemble des exigences. Il peut également être intéressant de créer d’autres modèles, tels que des diagrammes de flux, à partir de la description des cas d’utilisation, pour améliorer la précision du test et pour vérifier le cas d’utilisation lui-même.

COUVERTURE

La couverture minimale d’un cas d’utilisation consiste à avoir au moins un cas de test pour le principal chemin possible, et un cas de test pour chaque chemin ou flux alternatif.

Les chemins alternatifs incluent les chemins concernant les exceptions et les défaillances. Les chemins alternatifs sont parfois considérés comme des extensions du chemin principal. Le pourcentage de couverture est déterminé en prenant le nombre de chemins testés et en divisant par le nombre total de chemins principaux et alternatifs.

TYPE DE DÉFAUT

Les défauts pourront être la mauvaise gestion de scénarios définis, l’absence de prise en compte de chemins alternatifs, le mauvais traitement de certaines conditions et une gestion des erreurs imprécise ou incorrecte.

MISE EN ŒUVRE

Afin de mettre en oeuvre cette technique, il est préconisé de suivre les étapes suivantes:

• Analyser la base de test
• Identifier les acteurs
• Identifier les étapes
• Construire un diagramme au besoin
• Dériver les cas de test
• Identifier les jeux de données pour chaque cas de test

Illustrons cette démarche avec l’exemple suivant dont la base de test se compose de la spécification ci-dessous:

Le site Internet doit proposer un système de réservation de chambres d’hôtel. Pour cela, un client fourni les informations utiles et nécessaires via un formulaire de réservation.

Après avoir vérifié les informations saisies, le système propose au client les chambres disponibles au sein des hôtels partenaires.

Le client choisi une chambre, se connecte à son compte puis fourni les informations bancaires pour réserver la chambre.

Le système, après avoir pré-réservé la chambre auprès du système d’information de l’hôtel concerné,  demande l’autorisation à la banque pour finaliser le paiement et la réservation.

Une fois la réservation finalisée, le système confirme la réservation auprès de l’hôtel et envoi un mail de confirmation au client.

En analysant cette spécification, nous pouvons en déduire quatre acteurs:

• le client (via son navigateur Internet)
• le système (notre site Internet sous test)
• le système d’information (SI) d’un hôtel (surement une API web) que l’on nommera « SI hotel » dans la suite de l’article
• le système de paiement bancaire (surement une API web) que l’on nommera « banque » dans la suite de l’article.

Nous pouvons aussi déduire de cette spécification, le contexte, la préconditions ainsi que le déclencheur. Je vous propose le formalisme tabulaire suivant pour initier notre cas d’utilisation.

Nous allons maintenant essayer de définir les étapes du cas d’utilisation. Je vous propose une fois encore d’utiliser un formalisme tabulaire.

Identifions maintenant les exceptions ou les erreurs possibles dans ce cas d’utilisation.

Cette liste d’exceptions n’est pas directement déductible de la spécification initiale et est le résultat de l’analyse de cette dernière. Il conviendra de faire valider les comportements souhaités du système avec les représentants du produit.

Nous pouvons mettre en commun toutes ces informations dans ce document : UC01-Réserver-une-chambre-d_hôtel-via-le-site-internet.pdf

Vous pouvez constater que j’ai aussi rajouté un critère de performance utilisable pour mesurer la performance du système dans une campagne de test de performance.

Nous pouvons représenter ce cas d’utilisation avec un diagramme. Pour construire un tel diagramme, je préconise de commencer par le chemin principal.

Ajoutons-y maintenant les chemins alternatifs:

Dans ce diagramme, je n’ai illustré que les UC qui servent directement notre cas d’utilisation. Les autres UC qui sont mentionnés dans les chemins alternatifs sont réalisés en parrallèle de notre cas d’utilisation.

Nous disposons donc d’un chemin principal et de 14 chemins alternatifs. Nous allons donc construire 15 cas de test pour avoir une couverture de 100% de notre cas d’utilisation.

Attention, cette technique ne se préoccupe pas de la combinatoire possible au sein de chaque étape du cas d’utilisation. Par exemple, les données saisies dans le formulaire ne seront pas vérifiées ici. L’étape 2 ne se préoccupe que de vérifier que le système dispose des informations suffisantes pour poursuivre. Nous supposons que la validité des données du formulaire a déjà été testée en test unitaire par exemple.

Cela en va de même pour le système de recherche de chambres ou le système de paiement qui sont réputés déjà être testés dans les niveaux de tests unitaires ou intégration.

Maintenant que nous avons nos 15 cas de test (le chemin principal et les 14 chemins alternatifs), il nous reste à déterminer le besoin en jeux de données.

Prenons l’exemple avec le chemin principal, nous avons besoin :

• d’un utilisateur qui dispose d’un compte dans le système
• d’une CB valide
• d’un hôtel avec des dates de disponible

Il conviendra aussi de se préoccuper des dépendances externes comme les SI de l’hôtel et de la banque. En fonction du contexte, il sera peut-être nécessaire de les bouchonner.

Conclusion

Cette technique est très pratique pour apporter une vision réaliste du système avec les acteurs mis en oeuvre. Couplée avec une approche BDD, il devient plus facile de décrire le produit puis de définir les interactions entre acteurs.

Cet article conclut une série de 7 articles sur des techniques basées sur les spécification: https://latavernedutesteur.fr/tag/boite-noire/

Selon votre contexte, vous serez amenés à utiliser une ou plusieurs de ces techniques pour optimiser votre conception de cas de test. N’oubliez pas que chaque technique a ses forces mais embarque aussi du risque qu’il convient de gérer.

SOURCES ET REMERCIEMENTS

Le syllabus ISTQB niveau avancé Test Analyste traduit en français par le CFTL

Le glossaire ISTQB traduit en français par le CFTL

Advanced Software Testing Vol.1 – Guide to the ISTQB Advanced Certification as an Advanced Test Analyst de Rex Black

Merci à Marc Hage Chahine pour sa relecture.