Dans le chapitre suivant, les possibilités des différents outils d'automatisation des tests concernant le logiciel d'intégration de réseau Service ON Integrator seront examinées.
Au premier plan des tests se trouve l'interface graphique du portail ServiceOn Integrator (SOI) qui est exécutable en tant qu'application JavaWebstart sous Windows ainsi que sous Linux/Unix. La plus grande partie des fonctionnalités existantes offertes par le SOI est disponible via cette interface. L'accent est mis sur les deux outils de tests automatisés GUI QF-Test et Marathon.
L'image montre le portail SOI sans composant ouvert. L'arbre de ressources à gauche aide à ouvrir les composants individuels (par exemple, la gestion des erreurs).
Les outils de test GUI Marathon et Q-Test seront évalués afin de déterminer s'ils sont adaptés à l'automatisation de l'interaction avec le portail SOI et lesquels offrent la plus grande valeur ajoutée.
Puisque Marathon n'a pas de fonctions spéciales pour démarrer les applications WebStart, toutes les archives jar doivent être enregistrées localement sur l'ordinateur de test, avant de démarrer le portail avec Marathon. Cela peut se faire par exemple en démarrant manuellement le chargeur SOP (l'implémentation Java WebStart spécifique au SOI).
Tous les fichiers jar téléchargés doivent être disponibles dans le chemin des classes du projet de test Marathon, ce qui peut être automatisé par un script. Il est un peu plus difficile de définir les propriétés Java dans les fichiers jnlp, mais cela est possible grâce à la structure xml des fichiers jnlp (Java Network Launching Protocol) via un analyseur syntaxique.
Un autre défi qui s'est présenté lors des tests du logiciel a été la manière dont Marathon gère la reconnaissance des composants, car les titres des fenêtres de programmes individuels sont créés dynamiquement et il arrive parfois que des textes soient utilisés plusieurs fois dans une fenêtre.
La manipulation de l'outil de test GUI de Marathon est très centrée sur le développeur, notamment en raison de l'enregistrement entièrement en Jython. Cela nécessite une connaissance approfondie de ce langage de script, en particulier lorsque les enregistrements doivent être modularisés et réutilisés.
Le démarrage du portail SOI peut être fait via le SOPLoader à condition que le jdk utilisé dans le jdk du SOPLoader soit instrumenté.
De même, la reconnaissance des composants dans QF-Test est extrêmement dépendante de la version de langue utilisée, car normalement aucun nom pour les composants n'est attribué dans le code source du projet. Grâce à la possibilité d'intervenir manuellement dans la reconnaissance des composants, les premiers tests ont pu obtenir de bons résultats. Nous avons rapidement constaté que la maintenance de la reconnaissance des composants transférait un effort de développement élevé sur les tests qui devraient normalement être consacrés au développement du système.
La possibilité suivante est un grand avantage : L'accès aux composants d'éléments de structures complexes comme par exemple des structures arborescentes ou des tableaux, selon la situation, via un chemin absolu ou une position relative. Cela permet de choisir directement un élément et de vérifier si un élément avec des propriétés spéciales est disponible sans en connaître le nom exact.
La convivialité de la suite QF-Test diffère radicalement des autres outils d'automatisation des tests Java GUI en raison de sa structure de nœuds. Cette structure vous donne un aperçu facile des séquences enregistrées ou configurées manuellement. Malgré cette structure simple, certains scénarios de test nécessitent parfois une intervention via des scripts. Un exemple en est la vérification du contenu de tableaux qui ne sont constitués que d'images. QF-Test offre la possibilité de tester l'image d'une seule ligne, mais ce test est alors dépendant de la largeur de la cellule. Le listing 12 vérifie la largeur d'une cellule via le contexte d'exécution rc fourni par QF-Test pour la régler dans une "séquence de glisser-déposer" simulée à une largeur définie.
En outre, de nombreux tests ne nécessitent que de simples requêtes de test et la comparaison avec une expression régulière ou une section de texte. Ici aussi, la fonctionnalité de script Jython est nécessaire.
Une autre option intéressante d'automatisation du SOI offre le nœud pour l'exécution d'une commande shell. Ainsi, il est également possible d'appeler des fonctionnalités du système central qui ne sont pas disponibles localement.
Les deux outils suivent des approches très différentes dans l'administration des tests. Le groupe d'utilisateurs de Marathon est composé de développeurs et de testeurs ayant une formation en développement, car il est centré sur le code source. QF-Test essaie d'éviter le contact des testeurs avec le code source, uniquement lorsque cela est nécessaire. Ce découplage devrait permettre aux testeurs ayant peu d'expérience en programmation d'enregistrer et de modulariser les tests. Pour les quelques cas de scripts, il est suffisant d'avoir quelques testeurs ayant des connaissances en Jython.
La question de la reconnaissance des composants n'est en fait pas suffisamment prise en charge par aucun de ces deux outils par défaut. QF-Test offre la possibilité d'un contournement rapide par un résolveur de nom qui offre point par point de bons résultats. À long terme, vous devrez changer l'application. Je pense que vous pouvez accepter d'avoir l'effort de développement pour le but de tester une application plus facilement, donc d'étendre la conception de l'application pour une meilleure testabilité.
Pour résumer, QF-Test offre l'approche la plus prometteuse pour tester l'intégrateur ServiceOn.
