Pratique des tests logiciels - 2e éd.

Le test aux limites améliore le test par partitionnement, mais ne le remplace pas ; en effet, la construction des frontières, opération parfois complexe, est généralement déduite d'une analyse préalable des partitions liées aux domaines de définitions des paramètres.

On notera que le test aux limites permet de détecter simplement et efficacement certains types d'erreurs de réalisation :
- Mauvais opérateur de relation
- Erreur de borne
- Echange de paramètres
- Ajout d'un prédicat qui ferme un ensemble
- Frontière manquante
- Boucles mal réglées, mauvaise gestion des indices de tableau, etc.

Enfin, on notera également qu'une automatisation poussée peut être atteinte aussi bien dans le cadre de tests structurels que de tests fonctionnels.

Les défauts recherchés seront des erreurs de codage au sens large :
- Variables utilisées et non initialisées (erreur de codage la plus fréquente)
- Conditions inversées
- Sortie de boucle prématurée
- Absence de code défensif concernant des conditions d'entrée dans le composant non prévues (non-respect de préconditions)
- Utilisation d'un pointeur nul, etc.

Ces erreurs seront découvertes par la présence de défaillances typiques :
- Message d'erreur sorti à tort
- Sortie du composant sur des valeurs non prévues
- Violation mémoire
- Dépassement de capacité de représentation (overflow), etc.

Pour cela on prévoira des tests qui couvrent dans un premier temps les cas nominaux afin de vérifier que le code chargé de traiter le comportement normal du composant est réalisé correctement.
Ensuite, il faudra prévoir des tests pour vérifier que la prise en compte des cas irréguliers est correcte.

L'origine de ces méthodes dites "agiles" est liée à l'évolution permanente de l'environnement technologique et au fait que le client est souvent dans l'incapacité de définir ses besoins de manière précise et exhaustive dès le début du projet.

Le terme "agile" fait ainsi référence à la capacité d'adaptation du logiciel et des équipes aux changements de contexte et aux modifications de spécifications intervenant pendant le processus de développement.

En 2001, 17 personnes mirent ainsi au point le manifeste agile
http://agilemanifesto.org
dont les grandes lignes sont :
- Individus et interactions plutôt que processus et outils
- Développement logiciel plutôt que documentation exhaustive
- Collaboration avec le client plutôt que négociation contractuelle
- Ouverture au changement plutôt que suivi d'un plan rigide
- Ce manifeste s'oppose aux méthodologies dites "lourdes" comme ISO 12207 et le modèle de développement dit "en cascade", ISO 9000.

Grâce aux méthodes agiles, le client est au cœur de son projet et obtient très vite une première mise en production de son logiciel.
Il est ainsi possible d'associer les utilisateurs dès le début du projet.

Considérons le problème suivant : "Comment tester efficacement un composant logiciel qui génère des scripts utilisés pour valider le comportement de serveurs web". Ce composant prend quatre paramètres en entrée (...)
- Le type du poste client (...)
- Le type du navigateur client (...)
- Le type de données téléchargées (...)
- Le fait d'utiliser une connexion sécurisée ou non (...)

Dans cet exemple, il est possible d'énumérer toutes les combinaisons possibles des valeurs de paramètres en entrée et de réaliser ainsi un test exhaustif du composant [ce qui est rare, comme le rappelle souvent l'auteur du livre]. Cela a cependant un coût. Dans notre exemple, il faudrait réaliser
5 * 3 * 4 * 2 = 120 tests différents. (...)

Cette technique [énoncée plus haut, et nommée "all singles", on utilise au moins une fois chaque valeur de chaque paramètre]
permet de réduire très fortement le nombre de jeux de tests à considérer tout en maintenant une certaine qualité : toute valeur d'un paramètre est testée au moins une fois ; un oubli de réalisation ou une grosse erreur seront ainsi facilement détectés. Néanmoins, dès que les erreurs dépendront d'une association particulière de paramètres, ce genre de stratégie ne marchera pas mieux qu'une stratégie purement basée sur le hasard. (...)

Si l'on veut obtenir la garantie de tester toutes ces possibilités sans retomber dans l'énumération totale des valeurs possibles en entrée, il nous faut utiliser une stratégie intermédiaire, comme la stratégie dite "all pairs".
Cette stratégie vise à construire des jeux de tests de telle sorte que toutes les paires de possibilités soient couvertes au moins par un jeu de tests.
Dans notre exemple, il faudra que tous les couples (système/navigateur), (système/type de fichier) et (navigateur/type de fichier) apparaissent au moins une fois dans les jeux de tests.

Cette technique [all pairs] est très efficace, simple à mettre en œuvre et produit des documents de test facilement réutilisables. (...) Malheureusement, elle ne peut pas s'appliquer à tout type de composant logiciel. En effet, la plupart des paramètres prennent leurs valeurs dans des ensembles de cardinal très élevé.

Différentes stratégies complémentaires peuvent être mises en œuvre pour tester un logiciel.

Chacune se concentre plus particulièrement sur certains objectifs comme la mise en évidence de défauts dans la réalisation, la vérification de la cohérence ou du caractère complet des spécifications, le respect des standards, etc. Chacune déploiera ses propres méthodes et sera supportée par des outils dédiés comme l'aide à l'exécution, l'aide à la collecte de données, la vérification structurelle, etc.

Cependant, toutes ces stratégies partagent un certain nombre de points communs comme l'impossible exhaustivité, la qualité de la réflexion et l'importance des relations humaines dans tous les processus liés au test.
En cela, la formation et l'expérience du testeur sont irremplaçables.