Instructions: Programmation de scripts de test automatisés
Ces instructions décrivent les principes de développement efficace de scripts de test automatisés.
Relations
Eléments connexes
Description principale

Structure des scripts de test

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.

Technique d'enregistrement

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.)

Test conditionné par les données

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.

Traitement d'erreurs

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.

Synchronisation et planification des scripts de test

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.

Test et débogage des scripts de test

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.