IREX - Les cas de test : comment vérifier qu'un logiciel répond aux exigences ?

1. Introduction

Développer un logiciel ne consiste pas uniquement à écrire du code. Une fois les fonctionnalités implémentées, il reste une étape essentielle avant toute mise en production : vérifier que le logiciel répond réellement aux exigences définies au début du projet.

Cette phase est appelée qualification logicielle. Son objectif est d'apporter des preuves objectives que le système fonctionne conformément aux besoins fonctionnels, techniques et de sécurité attendus.

Parmi tous les éléments utilisés lors d'une qualification, les cas de test occupent une place centrale. Ils permettent de reproduire des scénarios représentatifs de l'utilisation réelle du logiciel afin de vérifier son comportement dans différentes situations.

Dans cet article, nous allons découvrir ce qu'est un cas de test, pourquoi il est indispensable dans un projet informatique et comment ce concept s'applique concrètement au projet ACRA, une plateforme de supervision basée notamment sur Prometheus, Keycloak, Grafana et différents exporters.

2. Qu'est-ce qu'un cas de test ?

Un cas de test est un scénario documenté permettant de vérifier qu'une exigence du logiciel est correctement satisfaite. Contrairement à une simple vérification réalisée de manière informelle, il décrit précisément les conditions d'exécution, les actions à effectuer ainsi que les résultats attendus.

L'objectif n'est pas seulement de vérifier que le logiciel fonctionne, mais de démontrer qu'il fonctionne de manière reproductible et conforme aux spécifications.

Chaque cas de test constitue ainsi une preuve de validation qui pourra être rejouée à chaque nouvelle version de l'application afin de s'assurer qu'aucune régression n'a été introduite.

2.1 Pourquoi les cas de test sont indispensables ?

Lorsqu'un développeur termine une fonctionnalité, il peut naturellement penser que celle-ci fonctionne correctement puisqu'elle répond au comportement attendu sur son environnement de développement. Pourtant, une fois intégrée avec les autres composants du système, des anomalies peuvent apparaître : mauvaise configuration, erreur d'authentification, problème réseau, certificat invalide ou encore mauvaise gestion des droits d'accès.

Les cas de test permettent précisément d'éviter ce type de situation en vérifiant chaque exigence dans un contexte proche des conditions réelles d'exploitation.

Ils apportent plusieurs bénéfices :

• vérifier que chaque fonctionnalité répond aux besoins exprimés ;
• détecter rapidement les anomalies avant la mise en production ;
• garantir la stabilité du logiciel lors des évolutions futures ;
• documenter précisément le comportement attendu du système ;
• fournir des preuves de conformité lors de la phase de qualification.

Autrement dit, un logiciel n'est pas considéré comme validé parce qu'il compile ou parce qu'il démarre correctement. Il est validé uniquement lorsque les différents cas de test démontrent que toutes les exigences ont été satisfaites.

2.2 Les composants d'un cas de test

Quel que soit le domaine d'application, un cas de test suit généralement la même structure afin de garantir sa reproductibilité.

• L'objectif : ce que l'on cherche à vérifier.
• Les préconditions : les conditions nécessaires avant l'exécution du test.
• Les étapes : les manipulations réalisées par le testeur.
• Le résultat attendu : le comportement attendu du système.
• Le résultat obtenu : ce qui est réellement observé pendant l'exécution.
• Le verdict : Succès (Passed), Échec (Failed) ou Bloqué (Blocked).

Cette structure garantit que deux personnes différentes exécutant le même cas de test obtiendront les mêmes observations dans les mêmes conditions.

Dans un projet de qualification, plusieurs dizaines voire plusieurs centaines de cas de test peuvent être définis afin de couvrir l'ensemble des exigences fonctionnelles, techniques et de sécurité du logiciel.

2.3 Du besoin métier au cas de test

Un cas de test n'est jamais créé au hasard. Il est directement dérivé d'une exigence, c'est-à-dire d'un besoin exprimé par le client, les utilisateurs ou les équipes techniques lors de la conception du logiciel.

Une exigence décrit ce que le système doit être capable de faire, tandis que le cas de test permet de vérifier que cette exigence est effectivement satisfaite. Cette relation garantit que chaque fonctionnalité importante du logiciel fait l'objet d'une validation avant sa mise en production.

Prenons un exemple simple. Si une exigence indique qu'un utilisateur doit pouvoir accéder à une application après une authentification réussie, un cas de test consistera à se connecter avec des identifiants valides puis à vérifier que l'accès est effectivement accordé. À l'inverse, un autre cas de test vérifiera qu'un utilisateur utilisant un mot de passe incorrect est bien refusé.

Cette approche permet de couvrir progressivement l'ensemble des besoins définis lors du projet. À mesure que les exigences sont validées par des cas de test concluants, le niveau de confiance dans la qualité du logiciel augmente.

Dans les projets de supervision comme ACRA, cette démarche est essentielle. Les exigences portent aussi bien sur les fonctionnalités que sur la sécurité, la disponibilité des services ou encore les opérations d'exploitation. Chaque exigence est donc associée à un ou plusieurs scénarios de validation afin de démontrer que le comportement observé correspond bien au comportement attendu.

3. Illustration avec le projet ACRA

Les notions présentées jusqu'à présent peuvent sembler théoriques. Pourtant, elles prennent tout leur sens lorsqu'elles sont appliquées à une plateforme réelle. Le projet ACRA, dédié à la supervision et à l'observabilité d'une infrastructure informatique, constitue un excellent exemple de qualification logicielle.

ACRA s'appuie sur plusieurs composants interconnectés, notamment Prometheus pour la collecte des métriques, Grafana pour leur visualisation, Keycloak pour la gestion des identités, Nginx comme reverse proxy sécurisé et différents exporters permettant de superviser les équipements de l'infrastructure.

Dans un tel environnement, la qualification ne consiste pas uniquement à vérifier que chaque service démarre correctement. Il est indispensable de démontrer que tous les composants collaborent correctement afin de fournir une plateforme fiable, sécurisée et conforme aux exigences définies.

3.1 Vérifier les exigences fonctionnelles

Les exigences fonctionnelles décrivent les services que le logiciel doit rendre à ses utilisateurs. Chaque fonctionnalité importante doit donc être validée au moyen d'un ou plusieurs cas de test.

Dans le cas d'ACRA, plusieurs fonctionnalités essentielles doivent être vérifiées avant toute mise en production.

• Un utilisateur authentifié doit pouvoir accéder à Prometheus via Keycloak.
• Les métriques collectées doivent être consultables depuis l'interface Prometheus.
• Les nouvelles cibles ajoutées dans la configuration doivent apparaître dans la page Targets avec un état UP.
• Les requêtes PromQL doivent retourner les valeurs attendues.
• Les dashboards Grafana doivent afficher correctement les métriques provenant de Prometheus.

Chaque scénario est documenté sous la forme d'un cas de test détaillant les prérequis, les manipulations à effectuer et les résultats attendus. Si le comportement observé correspond au comportement attendu, l'exigence est considérée comme validée.

3.2 Vérifier les exigences de sécurité

Une plateforme de supervision manipule souvent des informations sensibles sur l'infrastructure de l'entreprise. Sa qualification doit donc intégrer un ensemble de contrôles de sécurité afin de limiter les risques d'accès non autorisés ou de compromission des données.

Dans ACRA, plusieurs mécanismes de sécurité font l'objet de cas de test spécifiques.

• Validation de l'authentification via Keycloak.
• Refus d'accès lorsqu'un mot de passe est incorrect.
• Blocage immédiat d'un utilisateur désactivé.
• Redirection automatique du protocole HTTP vers HTTPS.
• Contrôle des rôles et des droits d'accès selon le profil utilisateur.
• Expiration correcte des sessions utilisateur.

Ces vérifications permettent de confirmer que les politiques de sécurité définies lors de la conception sont effectivement appliquées par l'ensemble de la plateforme.

Par exemple, lorsqu'un administrateur désactive un compte dans Keycloak, celui-ci ne doit plus être capable d'accéder à Prometheus, Grafana ou tout autre service protégé. Le cas de test permet de reproduire précisément cette situation afin d'observer le comportement réel du système.

3.3 Vérifier l'exploitation et la supervision

La qualification d'une plateforme de supervision ne s'arrête pas à la validation des fonctionnalités ou des mécanismes de sécurité. Il est également nécessaire de vérifier que les opérations quotidiennes d'exploitation peuvent être réalisées sans difficulté.

Ces scénarios reproduisent le travail réalisé quotidiennement par les administrateurs système et les équipes d'exploitation.

Dans le cadre d'ACRA, plusieurs opérations critiques peuvent être qualifiées :

• Ajouter un nouvel équipement à superviser.
• Déployer un nouvel exporter afin de collecter des métriques supplémentaires.
• Vérifier que les nouvelles métriques remontent correctement dans Prometheus.
• Créer un nouveau dashboard Grafana pour visualiser ces données.
• Modifier un dashboard existant sans perdre les informations déjà configurées.
• Supprimer un dashboard devenu obsolète.
• Détecter automatiquement l'indisponibilité d'un serveur grâce aux alertes Prometheus.
• Contrôler que les administrateurs disposent des droits nécessaires pour réaliser ces opérations tandis que les utilisateurs standards en sont empêchés.

Ces tests permettent de vérifier que la plateforme reste exploitable tout au long de son cycle de vie, même lorsque l'infrastructure évolue ou que de nouveaux équipements sont intégrés.

La qualification ne consiste donc pas uniquement à valider le logiciel lors de son installation initiale. Elle garantit également que les futures opérations de maintenance, d'évolution et de supervision pourront être réalisées de manière fiable et sécurisée.

4. Conclusion

Les cas de test constituent l'un des piliers de la qualification logicielle. Ils permettent de démontrer, de manière objective et reproductible, qu'un logiciel répond aux exigences qui ont été définies lors de sa conception. Au-delà de la simple vérification d'une fonctionnalité, ils apportent une véritable garantie de qualité en détectant les anomalies avant la mise en production et en limitant les risques de régression lors des évolutions futures.

L'exemple du projet ACRA illustre parfaitement cette démarche. Chaque fonctionnalité critique, qu'il s'agisse de l'authentification via Keycloak, de la collecte des métriques par Prometheus, de la supervision des équipements ou de la sécurisation des communications HTTPS, peut être associée à des cas de test précis. Cette approche permet de vérifier progressivement que l'ensemble de la plateforme fonctionne conformément aux exigences fonctionnelles, techniques et de sécurité.

La rédaction de cas de test constitue ainsi une étape essentielle de tout projet de qualification. Elle fournit des preuves objectives de conformité, facilite les campagnes de validation et contribue à renforcer la fiabilité globale du système avant son déploiement en environnement de production.

5. Voir aussi

• Les exigences logicielles : comment les définir ?
• Jenkins CI/CD : comment initier et tester un premier déploiement