Vous devez structurer vos scripts de test avant de les implémenter, afin d'améliorer leur aptitude à la maintenance et
à la réutilisation. Vous découvrirez sans doute que certaines actions apparaissent dans plusieurs scripts de test.
Cherchez à identifier ces actions de manière à pouvoir réutiliser leur implémentation.
Par exemple, certains scripts de test peuvent contenir des combinaisons de différentes actions réalisables sur un
enregistrement. Ils peuvent combiner les actions d'ajout, de modification et de suppression d'un enregistrement :
-
ajouter, modifier, supprimer (la plus évidente)
-
ajouter, supprimer, modifier
-
ajouter, supprimer, ajouter, supprimer
-
ajouter, ajouter, ajouter,...
En identifiant et implémentant ces actions dans des scripts de test à part, puis en les réutilisant dans d'autres
scripts, vous améliorerez leur aptitude à la réutilisation.
Vous pouvez également chercher à structurer vos scripts de test de manière à ce qu'un changement dans le logiciel cible
engendre un changement localisé et maîtrisable dans ces scripts. Ainsi, vos scripts seront plus élastiques aux
changements apportés dans le logiciel cible. Supposons par exemple que la portion connexion du logiciel ait changé.
Pour tous les cas de test qui utilisent la portion connexion, seul le script de test appartenant à la connexion devra
changer.
Pour accroître la maintenabilité de vos scripts de test, vous devez utiliser la technique d'enregistrement la moins
vulnérable aux changements apportés dans la cible de test. Par exemple, pour un script de test qui renseigne les zones
d'une boîte de dialogue, il existe plusieurs possibilités de passer d'une zone à une autre :
-
Utilisation de la touche de tabulation
-
Utilisation de la souris
-
Utilisation des touches de raccourci
Parmi toutes ces possibilités, certaines sont plus vulnérables que d'autres aux changements de conception. Si une
nouvelle zone est insérée sur l'écran, l'utilisation de la touche de tabulation ne sera plus fiable. Si vous procédez à
une réattribution des touches de raccourci, elles n'assureront pas un bon enregistrement. Si la méthode utilisée par la
souris pour identifier une zone est sujette à changement, cette technique risque également de ne plus être fiable. En
revanche, certains automates de test offrent des enregistreurs de scripts de test qui peuvent recevoir des instructions
pour identifier la zone par une méthode plus fiable, telle que l'attribution de son Nom d'objet par un outil de
développement (PowerBuilder, SQLWindows ou Visual Basic). Ainsi, un script de test enregistré n'est pas affecté par les
changements mineurs apportés à l'interface utilisateur (tels que des changements de présentation, de libellé des zones,
de format, etc.)
De nombreux scripts de test consistent à entrer plusieurs ensembles de données de zone dans un écran d'entrée pour
vérifier les fonctions de validation de la zone, le traitement d'erreurs, etc. Les étapes de la procédure sont les
mêmes ; seules les données sont différentes. Plutôt que d'enregistrer un script de test pour chaque ensemble de données
d'entrée, il convient de procéder à un seul enregistrement et de le modifier de manière à gérer les différents
ensembles de données. Par exemple, tous les ensembles de données qui produisent la même erreur en raison d'une donnée
invalide doivent partager le même script de test enregistré. Le script est ensuite modifié pour adresser la donnée en
tant qu'information variable, pour lire les ensembles de données depuis un fichier ou une autre source externe, et pour
traiter chaque ensemble de données important.
Si des scripts de test ou un code de test ont été développés pour traiter chaque ensemble de données d'entrée et de
sortie, vous devez définir les ensembles de données. Le format habituellement utilisé pour ces ensembles de données
sont les enregistrements de zones séparées par des virgules dans un fichier texte. Il s'agit d'un format facile à lire
depuis les scripts de test et code de test, et simple à créer et à maintenir.
La plupart des packages de base de données et de tableur peuvent produire des sorties de texte séparé par des virgules.
L'utilisation de ces packages pour organiser ou enregistrer des ensembles de données comporte deux avantages
importants. Tout d'abord, comparés à un éditeur de texte ou un logiciel de traitement de texte, ils offrent un
environnement plus structuré pour l'entrée et la modification de données. Ensuite, la plupart d'entre eux peuvent
interroger les bases de données existantes et enregistrer les données renvoyées, facilitant ainsi l'extraction
d'ensembles de données à partir de sources existantes.
L'exécution du script de test enregistré est séquentielle. Il n'existe pas de points de branchement. Dans les scripts
de test, un traitement d'erreurs robuste requiert une logique supplémentaire pour répondre aux cas d'erreur. Lorsque
des erreurs se produisent, la logique de décision peut consister à :
-
S'orienter vers un script de test différent.
-
Appeler un script qui tente de nettoyer le cas d'erreur.
-
Sortir du script et démarrer le suivant.
-
Sortir du script et du logiciel, redémarrer et reprendre le test au script suivant celui qui est en échec.
Chaque technique de traitement d'erreurs requiert l'ajout d'une logique de programme au script de test. Autant que
possible, cette logique doit être confinée aux scripts de test de niveau supérieur qui contrôlent l'ordre d'exécution
des scripts de test de niveaux inférieurs. Ainsi, ces derniers pourront être entièrement créés à partir de
l'enregistrement.
Lors de la réalisation de tests de charge, il convient souvent de synchroniser les scripts de manière à ce qu'ils
démarrent à différents moments. Les scripts de test peuvent être modifiés pour démarrer à un moment spécifique, en
comparant l'heure de démarrage à l'heure du système. Dans les systèmes en réseau, tous les postes de test partagent la
même horloge, par le biais du réseau. Dans l'exemple suivant (extrait d'un script écrit en langage BASIC), des
instructions ont été insérées au début du script pour suspendre son exécution jusqu'au moment souhaité.
InputFile$ = "TIME.DAT"
Open InputFile$ For Input As 1
Input #1, StartTime$
Close #1
Do While TimeValue(StartTime$) > Time
DoEvents
Loop
[Start script]
Dans cet exemple, l'heure de démarrage souhaitée est stockée dans un fichier. Vous pouvez ainsi la modifier sans
modifier le script de test. L'heure est lue et stockée dans une variable appelée StartTime$ . La boucle
Do While se poursuit jusqu'à l'heure de démarrage. L'instruction DoEvents est importante :
elle autorise l'exécution de tâches en arrière-plan pendant la suspension du script de test, dans l'attente de son
démarrage. Sans l'instruction DoEvents , le système ne répondrait pas avant l'heure de démarrage du script.
Lorsque les scripts de test réenregistrés sont exécutés sur le logiciel sur lequel ils ont été enregistrés
précédemment, aucune erreur ne devrait se produire. L'environnement et le logiciel sont restés identiques. Dans
certains cas cependant, il se peut que le script de test ne fonctionne pas correctement. Le test des scripts de test
permet de détecter ces cas et de corriger les scripts avant leur utilisation dans un vrai test. Nous abordons ici deux
types de problèmes courants :
-
L'ambiguïté des méthodes utilisées pour la sélection des éléments dans une interface utilisateur peut conduire les
scripts de test à fonctionner différemment lors de la réexécution. Par exemple, deux éléments reconnus par leur
texte (ou légende) peuvent comporter un texte identique. Il y aura ambiguïté lors de l'exécution du script.
-
Les données spécifiques à un test de session/exécution sont enregistrées (un pointeur, un horodatage ou d'autres
valeurs de données générées par le système), mais sont différentes lors de la réexécution.
Les écarts temporels entre les enregistrements et les réexécutions peuvent poser problème. Par nature, l'enregistrement
d'un script de test est plus lent que son exécution. En raison de cet écart temporel, le script de test est parfois en
avance par rapport au logiciel. Si c'est le cas, vous pouvez insérer des Statuts d'attente pour modérer la vitesse du
script et l'adapter à celle du logiciel.
|