RFT

Publié le 24/06/2007, par Romain Linsolas dans Agile | Ajouter un commentaire

Article paru dans la newsletter #15 – Septembre 2006

Cet article est issu de mes expérimentations sur la trial de Rational Functional Tester 6.1, et de la formation de 2 jours que j’ai reçue sur les outils de tests d’IBM-Rational.

Rational Functional Tester (RFT) est l’outil d’automatisation des tests fonctionnels d’IBM-Rational, pour applications dont la partie présentation repose sur l’une des technologies suivantes : HTML, Java et .Net.
Comme tous les automates d’IHM sur le marché, RFT propose un mode Record / Playback permettant la capture du scénario de test par enregistrement dans un script des actions utilisateur effectuées (actions souris et clavier), et sa ré-exécution par re-jeu du script ainsi enregistré.

En plus de ce mode Record / Playback, RFT propose également les fonctionnalités suivantes, maintenant classiques des outils du marché, pour la plupart d’entre elles (ou d’entre eux…) :

• Reconnaissance des contrôles graphiques : Pour qu’un outil d’automatisation soit robuste, celui-ci se doit d’identifier les contrôles graphiques utilisés, les mémoriser, puis les reconnaitre à nouveau (pour ré-exécuter le script). Pour cela, pour chaque contrôle graphique sur lequel une action effectuée (ou sur l’un de ses contrôles enfant), un objet le représentant est créé dans un référentiel (nommée la mappe d’objets dans le cas de RFT, soit local au test, soit partagé). Cet objet contient entre autres la liste des propriétés du contrôle graphique auxquelles l’outil a pu accéder. D’une manière générale, la compatibilité annoncée d’un outil avec telle ou telle technologie dépend de la capacité de cet outil à accéder aux propriétés des objets graphiques de cette technologie, et intercepter les évènements qu’ils reçoivent (« hook » sur le contrôle graphique). Cette fonctionnalité a pour but de permettre au script en cas de réarrangement de l’IHM, de continuer de fonctionner. Dans le cas de modification plus importante (changement de nom ou de classe d’objet par exemple), RFT propose en plus du classique assistant de mise à jour du référentiel d’objet une fonctionnalité « inédite » nommée ScriptAssure. Elle permet lorsqu’une action doit être effectuée sur un objet graphique introuvable dans l’IHM de déterminer l’objet présent le plus probable et d’effectuer l’action dessus, au lieu de faire échouer le test et/ou d’appeler un scénario de « recovery ». Pour déterminer l’objet le plus probable, RFT calcule pour chacun des contrôles graphiques présents dans la fenêtre/frame, la somme avec pondération de ses propriétés concordantes avec la description de l’objet capturé initialement. L’objet qui obtient la somme la plus élevée remporte le clic, et un warning dans le log d’exécution. Les pondérations de chaque propriété sont paramétrables, et la fonctionnalité est désactivable (l’interprétation dans le domaine du test est plutôt risquée, alors faite par un robot…).
• « Data-driven » : Association d’une feuille de données et d’un script de test permettant de déplacer les constantes du test (par exemple, nom du client à saisir dans le champ « Client ») du script vers des cellules de la feuille de données (une colonne par constante, une ligne par un cas de test). L’intérêt est à partir d’un même scénario/script de test de constituer plusieurs cas de test en variabilisant les informations utilisées. La création de « datapools » dans RFT est accessible durant ou après l’enregistrement, et ce, à l’aide d’un assistant.
• Assistant d’insertion de points de vérification. De même que les contrôles graphiques, les vérifications sont découplées du script par l’utilisation d’une référence vers un objet de type point de vérification. Ces points de vérification peuvent être crées durant ou après l’enregistrement du scénario. Il est toujours également possible de coder manuellement les vérifications directement dans le script.
• « Recovery scenarios » : gestion des comportements inattendus et bloquants (par exemple, affichage d’un message d’erreur modal non prévu, fermeture de l’application sous test, etc.) par appel de scripts spécifiques

Ces différentes fonctionnalités facilitant l’automatisation font que RFT remplira son office dans les mains de testeurs disposant de peu de compétences en développement logiciel.

Mais là où RFT se distingue de son principal (tandem) concurrent (WinRunner / QuickTest Pro, de l’éditeur Mercury), c’est par son intégration directement au sein de deux standards de l’industrie du développement logiciel : Visual Studio .Net et Eclipse.
Concrètement, RFT est constitué d’un plug-in pour chacun de ces deux EDI et d’un noyau accessible par ces deux plug-ins.

Voici les avantages que l’on peut attendre d’une telle intégration (liste probablement non exhaustive) :

• Environnement de développement des plus aboutis, autant pour l’édition que pour le débogage. Possibilités d’extensions.
• Pas de limitation liée au langage utilisé (VB.Net pour VS.Net, et … Java pour Eclipse). Par exemple avec WinRunner, le langage utilisé (le TSL, langage propriétaire s’apparentant au C au niveau de la syntaxe, mais pas des possibilités) permet de ne manipuler que des types simples, pas d’objet, pas de structures, etc. La majorité des fonctions de l’API système, de méthodes d’objet COM, ActiveX, etc. sont alors inutilisables.
• Possibilités d’extension importantes, de part les frameworks existants et les possibilités du langage objet Il est possible par exemple d’étendre les possibilités de RFT en implémentant de nouvelles méthodes et attributs dans la classe dont héritent chacun des scripts. Attention toutefois de ne tomber dans les problèmes engendrés par la validation d’un programme par un autre programme complexe et non validé (le script de test, pas RFT… enfin espérons…).
• Possibilités d’intégration de l’ensemble du processus de développement au sein d’un même socle/référentiel (centralisation de l’information, coordination améliorée des différentes phases, etc.).
• Socle éprouvé, et Open source pour la solution sous Eclipse (Eclipse + Hyades) : interopérabilité actuelle et future avec outils tierce-partie favorisée.
• Fonctionnalité non évidente à priori : un découplage entre l’EDI choisi et l’application sous test : il est tout à fait possible d’automatiser une application Java dans Visual Studio, ou une application .Net dans Eclipse (grâce au noyau partagé).
• Toutes les fonctionnalités de RFT excepté le mode Record, fonctionnent sous Linux (RedHat et Suse comme distributions officiellement supportées). Le coût pour valider par des tests RFT existants sous Windows le déploiement d’une application Java vers Linux est ainsi très faible (sans l’avoir testé, je ne pourrais dire nul)

Ainsi, RFT vise un public large, du développeur qui devrait s’y sentir à l’aise, à l’analyste métier ne voulant pas (trop) s’embêter avec la programmation (bien que de ce coté, Quick Test Pro soit probablement meilleur).

L’outil s’insère dans le reste dans la gamme des outils de test d’IBM-Rational, à savoir, TestManager pour la gestion des tests, et ManualTester pour la conception et l’exécution des tests manuels.

Autant RFT est impressionnant par ses possibilités, autant TestManager ne peut rivaliser avec TestDirector/Quality Center (Mercury). Ses possibilités de personnalisation sont pour ainsi dire inexistantes (pas de gestion du workflow, pas de gestion des habilitations, etc.), ce qui pourrait ne pas attirer les faveurs de consultants pour implémenter un processus de test « On Demand » dans l’outil d’IBM (oui, elle était facile…)
C’est dommage car du coup, RFT pâtit de l’absence d’association avec un bon outil pour gérer le processus de test et son référentiel. Une solution pourrait être en attendant un meilleur TestManager de se tourner vers les possibilités autour Visual Studio ou d’Eclipse.

Positionnement de RFT selon Forrester

Maxime Lemanissier

Comments are closed.