> Tech > Etape 3 : Exécuter le test, vérifier le résultat

Etape 3 : Exécuter le test, vérifier le résultat

Tech - Par Renaud ROSSET - Publié le 24 juin 2010
email

Avant de conduire les tests, rassemblez toutes les informations et autres ressources nécessaires : résultats attendus, cas de tests, instructions spéciales éventuelles pour conduire les tests (par exemple, dans quel ordre exécuter les tests) et d'éventuelles exigences de préparations spéciales (par exemple, se connecter à  la base de données

Etape 3 : Exécuter le test, vérifier le résultat

comme testeur) et les opérations
de nettoyage. Il faut aussi déterminer
le moyen de fournir des valeurs
à  la procédure (dans mon exemple,
j’utilise Query Analyzer) et une feuille
de calculs, table de données ou gestionnaire
de tests automatisé pour
journaliser les résultats des tests.

Parfois on exécutera un test une
seule fois sans jamais le répéter. Mais,
le plus souvent, on réexécutera la plupart
des tests. Comme la finalité d’un
test est de débusquer les bogues, la
première session de test devrait généralement
être suivie d’une seconde
chargée de vérifier les corrections
de bogues. Par la suite, chaque
changement de code effectué, par
vous ou par d’autres, devrait être suivi du tryptique tester-déboguer-retester.

Pour assurer la cohérence de tous
les cycles, il faut un script écrit indiquant
au testeur comment préparer et
effectuer le test et enregistrer les résultats.
Pour les tests comportant de nombreuses
exigences de préparation ou
étapes d’exécution, le script du test
doit comporter des instructions détaillées
autosuffisantes. Quand on prépare
les scripts de test, il faut fournir
suffisamment de détails pour que quelqu’un
puisse effectuer le test sans être
obligé de demander un complément
d’informations ou de suivre une formation
spéciale. Pour gagner du temps
et améliorer la cohérence au fil des
tests, on réutilisera les mêmes scripts
autant que possible.

Le tableau 3 contient un exemple
de script pour tester la procédure
usp_lookupPrice. Les étapes 3.1 à  3.3
sont des opérations de préparation essentielles
pour les tests de procédure
au niveau unité. L’étape 3.4 vérifie
qu’une bonne connexion à  la base de
données a été faite et que les données
correctes ont été chargées dans les
tables de test.

L’étape 3.5 montre un driver de
test que l’on peut utiliser pour fournir
des valeurs de test à  la procédure stockée
visée. Ici, nous effectuons nos tests
directement à  partir de Query Analyzer
; mais, si l’on fait beaucoup de
tests, il vaudra mieux écrire une procédure
stockée pour automatiser ce processus.
Autre possibilité : effectuer le
test à  partir d’une page Web ou d’une
autre application client. A ce stade de
test précoce, il vaut mieux réduire au
minimum toute interférence avec l’extérieur – comme un serveur Web
mort – en se tenant le plus près possible
du module de code.

Enfin, l’étape 3.6 exécute le test,
documente les résultats et enregistre
les renseignements fournis par le test.
Dans ce cas, on examine simplement
les résultats de la requête pour s’assurer
qu’ils sont conformes aux attentes.
Si les données entrées passent le test
avec succès, on peut en prendre acte et
passer au test suivant. Pour les procédures
qui contiennent des opérations
INSERT, UPDATE ou DELETE, il faudra
aussi vérifier que tous les enregistrements
de test ont été correctement
ajoutés, modifiés ou supprimés des
tables concernées.

Quand le résultat correct n’est pas
au rendez-vous, il faut enregistrer ce
résultat, comme nous le verrons plus
loin. Incluez tous les détails pertinents
sur le résultat réel comme les éventuels
messages d’erreur renvoyés ou
tout problème potentiel, comme une
connexion interrompue. Une telle information
indique à  quiconque débogue
la procédure où il doit commencer
à  rechercher des erreurs
probables. Elle permet aussi, après
avoir effectué un test de post-débogage,
de savoir si l’on a corrigé les
bogues responsables de l’échec du test
initial.

Pour finir, pour parachever les cas
de tests concernant usp_lookupPrice,
examinons les résultats des deux scénarios
restants dans le tableau 2. Le cas
de test 2 nécessite un product_id
supérieur à  5, donc demandons à 
product_id 6 de tester le code de
traitement d’erreurs qui capture les ID produit hors limites. En utilisant le driver
de test de l’étape 3.5, exécutons le
script suivant à  partir de Query
Analyzer :

DECLARE @price money, @return_
value int
EXEC @return_value=usp_
lookupPrice 6, @price OUTPUT
SELECT @price « Unit Price »
SELECT @return_value « Return
Value »

Comme prévu, cette requête provoque
la défaillance de usp_lookupPrice
et renvoie un code d’état de 10
– en même temps qu’un paramètre de
sortie NULL – confirmant ainsi que le
code de traitement d’erreurs est correct.
La requête de product_id 5 cause
aussi un défaut attendu et renvoie un
code d’état de 11, indiquant un prix invalide
(pour effectuer ce test, il suffit
de remplacer le 6 par un 5 dans le
script précédent). Là  aussi, les résultats
du test montrent que le code de traitement
d’erreurs joue parfaitement son
rôle.

Téléchargez cette ressource

Guide de Sécurité IA et IoT

Guide de Sécurité IA et IoT

Compte tenu de l'ampleur des changements que l'IA est susceptible d'entraîner, les organisations doivent élaborer une stratégie pour se préparer à adopter et à sécuriser l'IA. Découvrez dans ce Livre blanc Kaspersky quatre stratégies efficaces pour sécuriser l'IA et l'IoT.

Tech - Par Renaud ROSSET - Publié le 24 juin 2010