7.9 KiB
| title | date | tags | categories | |||||
|---|---|---|---|---|---|---|---|---|
| PdP: les tests | 2024-01-31 |
|
|
Les tests logiciels sont partiels, non exhaustifs et souvent approximé. Il se font tout au long du cycle de developpement mais commencent avant les implémentations. Il sont là pour assurer ou réfuter les propriétés du logiciels et renforcer / compléter une spécification.
Une spécification est une description abstraite et rigoureuse de fonctionnalités, comportement et services "rendus".
La validation d'une spécification permet de vérifier l'adéquation de celle-ci à ce qui a été dévellopé.
La vérification d'une spécification permet de s'assurer que l'implémentation est correcte et qu'elle fonctionne en rapport avec notre spécification.
Validation
La validation consiste donc à analyser si notre spécification reflète bien ce qui est requis (définis dans le cahier de besoin par exemple). D'après Sommerville (2005) ça passe par:
- Le contrôle de l'adéquation avec les parties prenantes;
- Le contrôle de la complétude, de tout de qui a été réalisé;
- Le contrôle de la consistance, qu'il n'y a pas de contradiction;
- le contrôle de la faisabilité de ce qui est à réaliser;
- le contrôle de la vérifiabilité, que ce qui va être réaliser peut être vérifier.
Cette vérification est le plus souvent informelle et non automatisable (difficilement formalisable, prouvable, quantifiable).
Cependant plusieurs techniques permettent de valider:
- La revue des besoins;
- Le prototypage;
- La construction de tests.
Vérification
Consitste à analyser que l'implementation est bien le reflet de la spécification. Elle prend deux formes:
- La vérification formelle qui implique un contrôle mathematique des propriété par des méthodes formelles et mathématiques.
- La vérification pratique par des test de propriété de notre implementation au regard de sa spécification.
Vérification formelle
elle utilise des langages abstrait de spécification, des outils d'aide à la spécification et à son contrôle, des langages de programmation incluant des éléments de spécification (comme Agda, Idriss), des outils d'aide à la preuve comme Coq, Isabelle ou Lean.
Cependant, toute propriété non triviale d'un programme est indécidable. Ce qui signifie que la vérification formelle est souvent difficile, fastidieuse même si elle est vecteur de progrès.
Elle est applique que dans les cas ou la robustesse est une composante crutiale (aéronautique, médical, etc.)
Vérification par les tests
Aussi appelée vérification pratique, elle est effectuée par des programmes qui vérifient ou non des propriété de notre implementation. Attention cependant, les tests validés ne signifient pas pour autant que notre programme fonctionne.
Il sont rarement exhaustifs et exacts.
La validations d'une batterie de tests ne signifie donc pas que notre programme fonctionne, cependant si l'un d'eux échoue alors notre programme ne fonctionne pas. On audugmente juste la confiance en notre implementation.
Non exhaustivité des tests
Plusieurs facteurs implique la non exhaustivité des tests:
- La taille et la description des domaines d'entrée;
- Les caractéristiques générale de notre logiciel par exemple la complexité, l'ergonomie, la flexibilité, ...;
- Les caractéristiques de l'implémentation;
- Les ressources affectés aux tests.
Les tests sont d'autant plus non exhastif qu'ils couvrent beaucoup d'aspects du logiciel comme les performances, la cmplexité, l'ergonomie, la préservation des propriétés après modifications ect. Même après décomposition en sous-besoins, ces points sont tout aussi difficiles à tester, par exemple l'ergonomie:
- l'efficacité - permettre aux utilisateurs d'atteindre leurs buts;
- la productivité - minimiser le temps et l'effort nécessaires à l'utilisateur;
- la sûreté de fonctionnement - limiter les risques pour l'utilisateur;
- La satisfaction.
Il est est difficile de décrire toutes les propriété d'un logiciel et donc de produire des tests exhastifs. Mais comme nous l'avons évoqué plus haut, les ressources allouées aus test limitent aussi cette exhastivité (motivatuons des testeurs, temps, moyens humains etc. ).
La robustesse d'un programme
Elle se définie par rapport à la spécification des domaines d'entrée \(Dom_{OK}\) pour lesquel le programme doit fonctionner. Les tests positifs sont ceux avec les entrées dans \(Dom_{OK}\). Ceux négatifs sont donc ceux pour les entrées hors de \(Dom_{OK}\).
Tester le domaine pour lesquelle le programme fonctionner est déjà compliqué, tester le complementaire à \(Dom_{OK}\) l'est encore plus! Mais ces tests sont important.
La couverture
La non-exhaustivité des tests induisent la couverture : on tend vers cette exhaustivité, nous avons plusieurs type de couverture aue nous allons détailler. Mais là encore il est très difficile d'atteindre l'exhaustivité.
Les couverture de code-sources
Elle conserne:
- Le code sources statiques qui couvrent les codes sources de tous les composants (les lignes de codes);
- Le code sources dynaniques qui couvrent le code pendant son exécution.
Il existe une terminologie spécifique qui se rapporte à la granularité des élements testés :
- Les tests unitaires qui concernent les éléments basiques du code source comme les fonctions ou les méthodes;
- Les test de composants qui concernent des ensembles d'éléments comme les modules ou des classes. Il sont souvent associés à des tests d'intégrations qui vérifient le lien avec les autres élements du code source;
- Les tests systèmes qui s'appliquent au logiciel.
Les couvertures de test domaines
Il couvrent les domaines d'entrée du programme programme.
Les tests autonomes
Il produit un résultat sous booléene : passé / non passé. Mais pour fonctionner les tests autonomes soivent contenir tout le necessaire à leurs fonctionnement comme les données. Il sont en général préférables: ils sont utilisables, reproductibles et facilement utilisables en batterie.
Ils peuvent utiliser des assertions au lien de renvoyer true ou false. Il
necessite aussi parfois la création de contextes via les fixtures setup. Ces
fixtures contiennent les opértions d'initialisation, d'ouverture de fichier
etc.
Il est aussi parfois utile de tester avec des composants incomplet ou non implementés ou instanciés, on passe alors pas des mocks objects, des fake objects, des dummy objects ou des stub. Tester un composant d'envoi de courriel ne doit pas vraiment envoyer de courriels.
Tests de non régression
L'evolution d'un logiciels comporte des risques d'introduire de nouveaux bugs même dans les éléments déjà en place. La progression d'un logicel peut entrainer la regression de son fonctionnement.
Pour vérifier ces élements, nous pouvons alors créer des tests de non régression en géneral mis en batterie pour vérifier la preservation du comportement.
Tests en boite blanche / noire
Les test en boite noire [^boitenoire] sont réalisés sans tenir compte de l'implementation mais seulement de son comportement (la spécification). Ceux en boite blanche tien compte su caractères particulier de l'implémentation. Et enfin ceux en boite grise sont des test en boite noire qui utilisent des hypothèses et / ou informations sur l'implementation.
Les tests en boite noire peuvent être dédiés à la validation et la vérification de la spécification. Il peuvent être conçus avant même l'implémentation des fonctionnalité testés. Il sont en quelque sorte une extention de la spécification.