La capture et la relecture est une possibilité efficace pour créer des tests de régression automatisés. Les tests générés de cette manière sont considérés comme fragiles et ont un besoin élevé de maintenance. Un grand problème est la reconnaissance des composants de l'interface utilisateur graphique. Souvent, des scripts de test créés manuellement et des modèles laborieux comme les objets de page sont utilisés pour réduire l'utilisation des ressources. Les scripts nécessitent des compétences en programmation, ce qui complique les tests effectués par les experts du domaine. Des coûts supplémentaires peuvent survenir en raison du besoin élevé de communication.
L'objectif est d'examiner les forces et les faiblesses de l'approche capture-relecture. Quatre outils commerciaux et open source pour la technologie d'interface Java Swing sont donc évalués. À cette fin, un scénario de test est conçu pour pallier les déficiences typiques de ces outils et aider à simuler les processus de développement quotidiens. Ce rapport montre que les résultats peuvent varier considérablement et quels types d'avantages et d'inconvénients la capture et la relecture offrent par rapport aux scripts de test créés manuellement.
Les résultats de ce rapport montrent que l'efficacité des outils de capture-relecture varie beaucoup. Contrairement aux publications pertinentes, la compatibilité des composants de l'interface graphique et des événements correspondants a été vérifiée et le comportement des outils dans leur discipline a également été évalué - tests de régression. Quatre outils ont été choisis : Pounder, Marathon, QF-Test et Ranorex qui ont des antécédents différents. Pounder est un outil open source et gratuit qui n'est plus activement maintenu mais qui a une bonne réputation. Marathon, quant à lui, n'est pas open source et gratuit, mais est maintenu en permanence par des développeurs salariés. QF-Test est un outil propriétaire qui a atteint une grande maturité et offre un grand nombre de fonctionnalités supplémentaires. Le profil de Ranorex est similaire, mais dans cette évaluation, c'est le seul outil qui n'est pas implémenté en Java.
Ces différences sont à prendre en compte pour l'évaluation des résultats. QF-Test est l'outil qui a pu terminer avec succès le plus grand nombre de tests, mais il est comparé au deuxième gagnant Marathon : une solution fermée et payante. Avec MarathonITE, une variante étendue et prometteuse de Marathon est disponible. Comme compromis, il faut renoncer à l'open source et à la disponibilité gratuite. Pounder et Ranorex, en troisième et quatrième position, semblent absolument inadaptés. Pounder nécessite de trop grandes adaptations en raison de ses restrictions au démarrage et pour l'administration d'applications complexes, Ranorex ralentit énormément le temps d'exécution et s'en est mal sorti lors des tests. Il semble donc avantageux que le SUT et l'outil utilisent la même plateforme comme c'est le cas ici : Java et la machine virtuelle Java (JVM).
Ainsi, deux outils, QF-Test et Marathon, constituent une possibilité efficace de générer des tests de régression automatisés. Les experts du domaine ne possédant pas de compétences en programmation peuvent créer leurs propres tests fonctionnels sans avoir à élaborer des spécifications écrites qui doivent être mises en œuvre par les développeurs de manière fastidieuse. Les deux outils offrent la connexion de langages de script, par lesquels la capture et la relecture peuvent être utilisées efficacement dans les premières étapes du développement. En outre, les adaptations pour optimiser l'application qui doit être testée via les outils de capture et de relecture (par exemple, l'attribution de noms explicites) semblent moins longues, comme les modèles spéciaux (par exemple, les objets de page), qui sont fréquemment utilisés pour les tests avec des scripts de test créés manuellement.
Cette thèse nécessite d'autres études empiriques pour comparer l'efficacité de la capture et du rejeu directement avec des solutions alternatives. Les résultats peuvent être pris en compte pour la sélection d'un outil approprié. Le scénario de test conçu offre un bon point de départ pour d'autres comparaisons. Mais à ce stade, d'autres adaptations sont nécessaires. Cette évaluation a montré que les différents tests dépendent trop les uns des autres. En outre, des tests plus indépendants permettent une analyse plus facile de la cause réelle de l'erreur. En outre, le scénario de test ou SwingSet3 peut être étendu pour appliquer les caractéristiques typiques des projets logiciels afin de pouvoir évaluer l'aptitude à l'utilisation quotidienne ou une stratégie de test alternative. Ici, par exemple, la connexion de sources de données externes ou l'intégration dans des processus de construction est imaginable.
L'extrait complet du rapport d'évaluation concernant QF-Test peut être trouvé ici (PDF en allemand).
