• Articles
• admin

La demande pour tester les applications Flash/Flex est devenue beaucoup plus importante au cours des dernières années. Cela indique une utilisation croissante de cette technologie, ce qui illustre à son tour un besoin de tests automatisés de ces applications. Cependant, ce besoin soulève quelques questions et problèmes, dont certains seront discutés dans l’article suivant.

Plus précisément, la première question à laquelle il faut répondre concernant l’automatisation d’une application Flash/ Flex est la suivante : quelle est la bonne technique d’automatisation ? Il y a deux façons distinctes d’y aller:

Souris native & intégration au clavier – convient aux situations où l’interaction Flash est minimale.

Intégration au niveau de l’API – bon pour les situations où il y a beaucoup d’interaction Flash requise.

Souris native & intégration du clavier – C’est là qu’un mouvement de souris, un clic de souris ou une action du clavier est simulé au niveau du système d’exploitation. Il reproduit la simulation utilisateur la plus réaliste en enregistrant des actions basées sur l’interface graphique, nous rapprochant ainsi de l’utilisation « réelle » de notre application. Cependant, l’utilisation de cette méthode pose quelques problèmes. Par exemple, le test d’une application Flash nécessite que l’application et l’environnement de test soient préparés d’une manière spéciale. Il existe différentes façons de rendre votre application Flash testable, en fonction de l’outil de test utilisé et de l’environnement de développement. Certains outils tels que TestComplete, Rational Robot et QTP nécessitent qu’une bibliothèque dédiée (généralement fournie par le fournisseur de l’outil) soit intégrée dans l’application Flash lors de la compilation ou de l’exécution. Les détails de ce processus peuvent généralement être trouvés dans la documentation de ces outils.

La capture des objets dans une application Flex/Flash est problématique en soi. Pour résoudre ce problème, il existe deux approches principales:

1. Capturez l’affichage à partir du dispositif et utilisez la reconnaissance d’image pour localiser les éléments souhaités sur l’écran, automatisant l’application de manière boîte noire. L’aubergine est un bon exemple d’outil qui utilise cette approche. C’est également ainsi que SilkPerformer fonctionne dans un environnement Citrix.
2. Analysez les objets utilisés en propriétés et utilisez ces propriétés pour localiser l’objet. C’est la même approche que celle utilisée dans les dépôts d’objets de QTP. Les propriétés d’objet Flash typiques telles que l’état, le nom et le texte sont utilisées à la fois pour localiser les objets et vérifier que certaines actions ont bien eu lieu. Rational Robot est un bon exemple de cette approche; il utilise 11 points de vérification différents pour vérifier qu’une certaine action a eu lieu, ou vérifier l’état d’un objet. Cette approche est parfaite pour ceux qui souhaitent simuler des interactions GUI relativement simples, telles que cliquer sur le bouton « lecture » d’un film ou interagir avec une boîte de dialogue de confirmation, car sur une application plus compliquée, cette approche a tendance à échouer.

Intégration au niveau de l’API – Pour les applications qui ont des interfaces utilisateur Flash / Flex beaucoup plus complexes ou des applications 100% basées sur Flash, il est difficile d’utiliser la capture GRAPHIQUE telle que présentée car elle peut être fragile et difficile de confirmer que la fonctionnalité souhaitée a fonctionné. Pour cela, on peut utiliser l’intégration au niveau de l’API. Pour ce type d’automatisation, il faut pouvoir recompiler /modifier le ou les objets Flash sous-jacents.

La façon dont vous procédez à partir d’ici dépend de si vous utilisez Flash ou Flex, car Flex expose certaines API d’automatisation qui devront sinon être reproduites si vous utilisez du Flash pur. Pour ce faire, on peut :