La démarche de création de scripts de tests automatisés se révèle être un exercice difficile. De nombreux projets sont arrêtés dès la phase d’étude d’opportunité, en raison de contingences techniques qui empêchent l’automatisation, ou encore du manque de maturité des processus de test à l’œuvre dans l’entreprise. Quand les conditions initiales, requises, sont réunies, la réalisation des scripts et leur intégration dans un référentiel peuvent être effectuées. Cependant, une bonne constitution, ne prémunit pas totalement de désagréments, lorsqu’il faut « faire vivre ce référentiel » dans le temps. Cela tient autant à des considérations techniques qu’à la mise en place d’une organisation éprouvée. Pour vous aider dans cette tâche, nous vous livrons, dans cet article, quelques conseils.

En premier lieu, qu’entend-on par « faire vivre un référentiel » ? Il s’agit, en fait, de l’ensemble des opérations de mise à jour à porter aux scripts en fonction des évolutions de l’application en test. C’est à partir de cette définition que l’on peut segmenter l’approche en deux types d’interventions.

En amont, sur la réalisation de ces scripts. En effet, comme il va être question d’effectuer des opérations de maintenance, il est important de porter le maximum d’attention à la phase de design et de développements des procédures. Aussi, comme dans tout exercice de développement, quelques règles sont à respecter :

Créer des scripts de tests réutilisables

Les données

Il est préférable de stocker dans une table de paramètres, toutes les informations qui sont saisies. Sinon, les valeurs saisies font partie du code, et le besoin de les modifier équivaut à modifier le script.

Exemple : Login, dates

Eviter l’enregistrement d’images

•  L’enregistrement d’images (bitmap,…) doit être évité tant que possible.  En effet, cette technique est trop sensible à la plus petite des modifications (changement de couleur ou de position de n’importe quel élément).
• Le script ne fonctionne plus même sans modification de l’interface si on modifie la résolution de l’écran
• La place mémoire nécessaire pour stocker les attributs graphiques est très importante.

Limiter l’utilisation de la Capture et du re jeu

Il s’agit de la fonctionnalité la plus souvent avancée par l’éditeur pour parler de la simplicité d’utilisation de l’outil. Cependant, elle comporte certains défauts :

• Toutes les saisies faites pendant l’enregistrement sont rentrées, « en dur », dans le code.
• La position des fenêtres et des objets est mémorisée

Cela peut poser des problèmes pour le rejeu. C’est pour cela qu’il vaut mieux privilégier une approche où les ingénieurs de test modifient le script créé, afin de créer des scripts :

• Réutilisables
• Maintenables
• Robustes

Créer des scripts maintenables

Adopter des Standards cosmétiques

Il faut essayer de rendre les scripts les plus lisibles possibles :

• En adoptant des codes couleurs (quand l’outil le permet)
• En jouant sur les alignements
• En utilisant les caractères de continuation pour que les lignes soient plus courtes
• En essayant de faire des scripts courts afin qu’ils puissent être visualisés aisément

Commenter les scripts

• Ne pas lésiner sur les commentaires afin d’expliquer le scope du test
• Insister sur le commentaire de chaque début de pas de test.

Documenter les scripts

Chaque script doit être documenté. Cette documentation doit :

• Mettre en évidence les particularités du script
• Permettre à une personne qui ne dispose de capacités techniques particulières de lire le script et de savoir ce qu’il fait exactement.

Généralisert la cartouche de début de script

Il est impératif de débuter le script par une cartouche contenant :

• Id de la procédure de test dont il dépend
• Le nom de la procédure
• Les pré requis
• Les arguments en entrée
• Les conditions du test
• Les résultats attendus
• Les éventuels besoins en logiciel ou matériel

Indexer les procédures de test

Il peut être important d’indexer les scripts. En effet, souvent leur nombre est important, aussi il peut être intéressant de connaître tous les scripts qui touchent un domaine particulier ou qui font un certain type de contrôle.

Cette propension est importante lorsque l’on veut réutiliser les scripts, il faut donc pouvoir les retrouver facilement. Cette indexation peut se faire par la création d’une base de données, si l’outil que l’on utilise ne permet pas de le faire.

Prendre en charge les erreurs

Il est important de gérer les éventuelles erreurs pendant l’exécution du script. Sans ce type de gestion :

• On ne sait pas pourquoi le script sort en erreur
• Cela peut mettre en péril le reste de la campagne

Cette gestion des erreurs permet :

• D’avoir une information précise sur le type d’erreur et la corriger.
• De mettre en place des actions correctives pour remettre le système dans sa configuration initiale, par exemple
   

Viser la modularité des scripts

Un script modulaire simplifie sa maintenance. Plus un script est petit, plus il est compréhensible. Cela permet d’effectuer des corrections plus aisément.

Diviser un script en modules logiques est une des façons de gérer des scripts plus complexes. Les modules ainsi créés peuvent être réutilisés dans d’autres scripts. Une modification précise de l’application entraîne la MAJ de simplement un module au lieu de plusieurs. (ex : module de login)

Ces quelques conseils, s’ils sont suivis vous garantissent des scripts bien développés et donc plus facilement maintenables. Pour ce qui est de la partie plus dynamique, du cycle de vie du référentiel, il s’agit de mettre en place une organisation avant de lancer toute nouvelle campagne de tests automatisés. En effet, cette action intervient à chaque nouvelle qualification, accompagnant toute nouvelle version du produit logiciel. Globalement, les tâches à accomplir tournent autour ;

• De la non régression
• Du test des nouvelles fonctionnalités

Chaque campagne, doit donner lieu à deux phases, encadrant l’exécution. La préparation, et l’analyse avec la définition du nouveau périmètre de la régression. Globalement, en phase de préparation, on procède à des modifications sur les scripts existants, en phase d’analyse on décide de la création ou de la suppression éventuelle de scripts automatisés.

La phase de préparation

On doit d’abord procéder à une étude d’impact des évolutions sur le référentiel de non régression. Si l’organisation, et notamment l’utilisation d’un outil, a permis la mise en place de matrices de traçabilité, on met facilement en évidence les liens entre les exigences impactées et les procédures de test qui les couvrent. On obtient alors :

• La liste des procédures de test qui doivent, potentiellement, être revues
• La liste des nouvelles exigences qui ne sont pas couvertes et qui doivent donner lieu à la création de procédures de test

Le premier item doit être étudié avec attention. En effet, des modifications mineures sur l’application, comme le changement de propriété d’un objet, peuvent mettre un script en échec. Aussi, si on ne procède pas à cet examen, on encourt le risque de « polluer » l’analyse de la campagne par des « fausses anomalies », qui ne sont pas la mise en évidence d’erreurs mais correspondent à la non prise en compte des évolutions.

Pour ce qui est des nouvelles exigences, pour des raisons de priorisation, de temps ou encore de définition du périmètre, à venir, de la régression, il est préférable de ne pas créer de scripts automatiques. En effet, on ne dispose pas en général, de l’application en phase de préparation de la qualification. Aussi, les robots fonctionnant sur l’IHM, il est impossible d’écrire complètement les scripts avant la livraison du produit. Même si aujourd’hui de nouveaux outils permettent de préparer les scripts en modélisant les actes métiers, il est préférable de créer des procédures manuelles. Cette approche se voulant pragmatique, il est bien évident qu’un traitement répétitif et lourd en ressources humaines, peut bien évidemment donner lieu, à la marge, à la création d’un script automatique.

L’analyse et la définition du nouveau périmètre du référentiel

Après les phases d’exécution et d’analyse des campagnes, on est en mesure de décider du nouveau périmètre du référentiel de test. En fait sur la base des nouvelles exigences induites par les évolutions, on a créé des procédures. L’ensemble de ces procédures ne migre pas forcément vers le référentiel testant la non régression. En effet, il peut s’agir, par exemple, de nouveaux tests liés à des contrôles de cohérence, suite à une migration de données. Dans ce cas, il n’est pas nécessaire la campagne terminée de les intégrer. Pour les autres, leur intégration n’est pas forcément synonyme d’automatisation, en effet certaines contingences peuvent l’empêcher :

• Contraintes techniques liées à une éventuelle incompatibilité de l’outil
• Complexité technique
• Charge de travail
• Nécessité d’intervention manuelle
•  …

Il faut également penser à supprimer les scripts qui correspondent à des fonctionnalités qui ne sont plus présentes dans l’application. Cette disposition permet de disposer d’un référentiel à jour et utile.