Dans les projets logiciels actuels, les tests d'interface graphique sont fréquemment utilisés. Comme tous les tests, ils servent à maintenir la qualité du logiciel et donc à garder la vitesse de développement aussi linéaire que possible. Cependant, ce logiciel est en cours de développement et donc sujet à des changements constants. En particulier, l'interface graphique et ses composants changent. Les tests de l'interface graphique doivent être capables de gérer ces modifications des composants. Sinon, ils échouent, ils se cassent. Une raison courante est que les composants modifiés ne sont plus trouvés et reconnus par le cadre utilisé pour les tests de l'interface graphique. Dans ce document de séminaire, des classes individuelles d'erreurs dans les tests GUI doivent être trouvées sur la base d'une étude de cas. L'objectif est de les éviter et de maintenir ainsi l'effort de maintenance des tests de l'interface graphique aussi bas que possible. Un ensemble de cas de test pour la version v2.00 de KeePass sera créé. Le développement ultérieur est simulé en appliquant les tests à la version suivante, c'est-à-dire la v2.01. Cela nous permet de déterminer à quel moment les tests échouent. Ceux-ci sont ensuite regroupés en classes. En résumé, en tenant compte de la persistance dans l'environnement de test, du renommage trivial et des propriétés du cadre de test de l'interface graphique, la grande majorité des erreurs peuvent être évitées.
Tout comme les dimensions qui peuvent être utilisées pour dériver différents types de tests, on peut également définir différentes dimensions qui modifient le SUT. Il s'agit par exemple de la version, de la langue ou de la plate-forme. Dans ce document de séminaire, seuls les changements causés par le développement, c'est-à-dire la version, seront considérés. L'objectif de cette étude est de trouver des erreurs dans les tests GUI et des moyens de les éviter. Ainsi, la qualité des tests de l'interface graphique augmente avec la production initiale et les pannes ultérieures sont moins fréquentes. L'objectif est d'améliorer la qualité des tests de l'interface utilisateur graphique en consacrant du temps supplémentaire au processus de création afin d'éviter des ajustements fréquents des tests de l'interface utilisateur graphique par la suite. Si le temps supplémentaire passé au début est inférieur au temps total potentiellement passé plus tard à s'adapter, l'effort de maintenance est réduit. Ceci est souhaitable dans tous les cas.
Le premier groupe d'erreurs a été causé par la persistance dans l'environnement de test. Cela signifie que les données sont écrites de manière persistante et utilisées par le SUT pendant l'exécution des tests.
Dans le cas de KeePass, cela était présent dans la boîte de dialogue Paramètres, par exemple. Depuis la version 2.07, KeePass enregistre l'onglet ouvert lorsque la boîte de dialogue est fermée. Lors de la prochaine ouverture de la boîte de dialogue, l'onglet enregistré est présélectionné et non le premier onglet comme dans les versions 2.00 à 2.06. Les tests ont été écrits en supposant que le premier onglet est toujours sélectionné. Ils ont donc échoué à partir de la version 2.07.
Au total, deux des 17 tests échoués l'ont été pour cette raison ou pour une autre. Cette erreur est très facilement évitée en effaçant les données persistantes avant d'exécuter les tests. Dans le cas d'une USE développée par l'utilisateur, il est également possible d'imaginer une fonction dans laquelle l'USE exécute un démarrage propre au moyen d'un argument. Et ce, sans tenir compte des données persistantes.
Le plus grand groupe d'erreurs identifiées dans cette étude de cas sont les renommages triviaux. Il s'agit de renommages qu'un utilisateur normal peut ne pas remarquer, mais qui sont découverts lors des tests automatisés de l'interface graphique. Parmi les exemples tirés de KeePass, citons le renommage de Rechercher en Rechercher..., de Côte à côte en Côte à côte, ou de Verrouiller les fenêtres en Verrouiller la fenêtre ou Déconnexion.
Avec dix essais sur dix-sept échouant pour cette raison ou pour une autre, ce groupe est le plus important des groupes énumérés ici. Il est donc très intéressant d'éviter ces erreurs.
Les moyens d'étude pour éviter ces erreurs sont plus larges que pour le premier groupe. Par exemple, des tests sans sensibilité à la casse peuvent éviter ces erreurs. Si un composant est déjà suffisamment caractérisé par une sous-chaîne, seule cette sous-chaîne peut être mise en correspondance. Un autre cas où une certaine tolérance d'erreur devrait être autorisée, cette tolérance pourrait être réalisée par une distance de Levenshtein. De cette façon, les composants peuvent être renommés dans le cadre de cette tolérance sans rompre les tests de l'interface graphique. Si le cadre de test de l'interface graphique permet l'utilisation d'expressions régulières, celles-ci peuvent également être utilisées avec le même degré de flexibilité.
Le dernier groupe d'erreurs peut être évité en connaissant les propriétés du cadre de test GUI. Ainsi, dans cette étude de cas, QF-Test et les propriétés dans la reconnaissance des composants. Le QF-Test est une approche basée sur la probabilité. Sur la base de certaines propriétés, une probabilité est calculée pour chaque composant qu'il s'agisse du composant recherché. Le composant ayant le résultat le plus élevé est finalement sélectionné. Le nom unique du composant, qui peut être défini à l'aide de setName(), par exemple, est particulièrement pondéré.
Comme le montre la figure 2.4, KeePass a modifié les noms des composants au cours du développement. Les autres propriétés de ces composants n'ont cependant pas changé, ce qui rend ce changement visuellement imperceptible. Cependant, les tests ont échoué avec QF-Test et la pondération utilisée. Au total, six des 17 tests échoués l'ont été en raison d'un changement de nom ou pour une autre raison. Encore une fois, ces erreurs peuvent être facilement évitées en définissant les noms des composants de manière cohérente dès le début.
Le résultat global de l'étude de cas est clair. Par exemple, 14 des 17 tests échoués l'ont été en raison d'au moins une des trois erreurs. Seuls les trois autres tests échoués ne font pas partie de ces classes d'échec. Bien entendu, ces résultats ne peuvent pas être appliqués à n'importe quel projet logiciel sans réserve. Les classes d'erreurs présentées ici sont très spécifiques et ne s'appliquent dans leur ensemble qu'aux conditions de l'étude de cas. La mesure dans laquelle les résultats peuvent être transférés à d'autres projets logiciels est un sujet possible d'autres travaux. Les changements possibles des conditions comprennent, par exemple, le cadre de test GUI utilisé, le SUT, les versions, les tests et les cas de test, le système d'exploitation utilisé, et bien d'autres.
Cependant, il a été clairement démontré qu'en raison de quelques erreurs dans les tests GUI, un grand pourcentage d'entre eux se cassent. Ainsi, la robustesse des tests GUI automatisés peut être augmentée en évitant les erreurs dans les classes d'erreurs identifiées. En conséquence directe, l'effort de maintenance des tests de l'interface graphique diminue, ce qui est souhaitable dans tous les cas.
L'intégralité de la thèse de maîtrise peut être consultée ici (PDF en allemand).
Thèse de séminaire : Pourquoi mes tests GUI automatisés ne fonctionnent-ils pas ? juillet 2020 - Leonard Husmann, Département d'informatique, Technische Universität München, Allemagne.
