Etape 2 : Préparer les données de test

constituent un cas de test. Mais attention
– un bon cas de test suppose que
l’on choisisse la bonne combinaison de
valeurs de test.

Les experts du testing ont conçu
de nombreuses manières (qui parfois
se chevauchent) pour choisir des valeurs
de test. La distinction classique se
fait entre les tests boîte blanche et boîte noire. Les tests boîte blanche, ou
à  base de code, utilisent des valeurs de
test qui traquent les erreurs dans
chaque voie logique d’un bloc de code.
Les tests boîte noire, ou à  base de spécifications,
utilisent des valeurs de test
qui vérifient qu’une procédure remplit
correctement son rôle, comme insérer
ou supprimer un enregistrement. Le
tableau 1 résume ces techniques de
conception de cas de test courantes et
d’autres. On peut créer des cas de test
à  l’aide de tout ou partie de ces techniques.
Les tests seront d’autant plus
exhaustifs que l’on fera appel à  beaucoup
de techniques. Il faut savoir que
chaque nouveau cas de test demande
du temps supplémentaire pour concevoir,
programmer, exécuter et analyser.
De ce fait, beaucoup de développeurs
limitent le nombre de tests et l’ordre
dans lequel ils s’exécutent. Si votre
équipe n’a pas encore établi de telles
règles, le moment est peut-être venu.

Quand on teste par unités des procédures
stockées, il vaut mieux généralement
commencer par le test boîte
blanche parce que les développeurs de
procédures sont ceux qui appréhendent
le mieux l’ensemble du code
concerné. De plus, contrairement aux
testeurs professionnels de nombreux
sites, les développeurs ont généralement
l’accès direct à  leurs propres procédures. Donc, si le programmeur
ne le fait pas lui-même, le test boîte
blanche sera probablement ignoré. Au
fil du temps on peut enrichir les tests
boîte blanche par d’autres techniques,
mais c’est sur le code T-SQL qu’il faut
concentrer les efforts de test par
unités.

Nous l’avons vu, le test boîte blanche
consiste à  rechercher les erreurs
dans chaque voie logique au travers
d’une procédure stockée. Concrètement,
il s’agit de tester toutes les combinaisons
possibles de conditions
vrai/faux créées par IF, GOTO et autres
instructions de branchement. (Les
structures de boucle créent une
couche supplémentaire de complexité
logique que l’on pourra explorer ultérieurement.)

On voit dans le listing 2 que
usp_lookupPrice contient deux
instructions IF (lignes 6 et 8). Chaque
condition recherche d’abord la présence
d’erreurs potentielles et, si elle
en trouve une, renvoie un code d’état
défini par l’utilisateur unique à  la procédure
appelante. Quand on les combine,
les deux instructions de branchement
définissent trois voies séparées
au travers du code T-SQL dans
usp_lookupPrice :

• Voie 1 : instructions 5, 6, 8 et 10
• Voie 2 : instructions 5, 6 et 7
• Voie 3 : instructions 5, 6, 8 et 9

Le tableau 2 montre les détails de
test des trois voies. La voie 1 teste la logique
de gestion centrale de
usp_lookupPrice. Il s’agit de définir
@product_price égal à  un product_
price valide et de renvoyer un code
d’état de 0. Les voies 2 et 3 testent les
deux gestionnaires d’erreurs. La voie 2
renvoie un code d’état de 10 et un
message d’erreur Row not found ; la
voie 3 renvoie un code d’état de 11
(Unit_price is null) en même temps
qu’un unit_price nul.
Pour tester les trois voies, il faut utiliser
un cas de test distinct pour chacune
d’elles. Le cas de test de la voie 1
couvre l’état normal, dans lequel la demande
d’un enregistrement valide (1,
2, 3 ou 4) renvoie un code d’état de 0
et donne à  @product_price la valeur
product_price pour l’enregistrement
correspondant. Pour voie 2, @@rowcount
sera de 0 chaque fois que @product_
id demande un product_id invalide
dans la table Products. Tout
product_id supérieur à  5 remplit cette
condition. Donc, un test qui utilise 6
comme @product_id devrait produire
les résultats attendus pour les instructions
de voie 2 dans le tableau 2 – soit
une valeur de renvoi de 10 et une valeur de paramètre de sortie NULL.
Enfin, pour voie 3, rappelons-nous
que l’enregistrement 5 dans la table
Products ne contient pas de product_
price – un bogue courant que j’ai
volontairement recréé pour cet
exemple. Le fait de demander un product_
price pour l’enregistrement 5
aura deux effets attendus : une valeur
de renvoi de 11 et un paramètre de sortie
@price NULL.