Test de l'interface utilisateur graphique - Graphical user interface testing
En génie logiciel , le test d'interface utilisateur graphique est le processus de test de l' interface utilisateur graphique (GUI) d' un produit pour s'assurer qu'il répond à ses spécifications. Cela se fait normalement en utilisant une variété de cas de test .
Génération de cas de test
Pour générer un ensemble de cas de test , les concepteurs de test tentent de couvrir toutes les fonctionnalités du système et d'exercer pleinement l' interface graphique elle-même. La difficulté d'accomplir cette tâche est double: gérer la taille du domaine et les séquences. De plus, le testeur rencontre plus de difficultés lorsqu'il doit faire des tests de régression .
Contrairement à un système CLI (interface de ligne de commande), une interface graphique peut avoir des opérations supplémentaires qui doivent être testées. Un programme relativement petit tel que Microsoft WordPad a 325 opérations GUI possibles. Dans un grand programme, le nombre d'opérations peut facilement être plus grand d'un ordre de grandeur .
Le deuxième problème est le problème de séquençage. Certaines fonctionnalités du système ne peuvent être accomplies qu'avec une séquence d'événements GUI. Par exemple, pour ouvrir un fichier, un utilisateur doit d'abord cliquer sur le menu Fichier, puis sélectionner l'opération Ouvrir, utiliser une boîte de dialogue pour spécifier le nom du fichier et concentrer l'application sur la fenêtre nouvellement ouverte. L'augmentation du nombre d'opérations possibles augmente le problème de séquençage de façon exponentielle. Cela peut devenir un problème sérieux lorsque le testeur crée manuellement des scénarios de test.
Les tests de régression sont également souvent un défi avec les interfaces graphiques. Une interface graphique peut changer de manière significative, même si l'application sous-jacente ne le fait pas. Un test conçu pour suivre un certain chemin dans l'interface graphique peut alors échouer car un bouton, un élément de menu ou une boîte de dialogue peut avoir changé d'emplacement ou d'apparence.
Ces problèmes ont conduit le domaine des problèmes de test GUI vers l'automatisation. De nombreuses techniques différentes ont été proposées pour générer automatiquement des suites de tests complètes et simulant le comportement des utilisateurs.
La plupart des techniques de test tentent de s'appuyer sur celles précédemment utilisées pour tester les programmes CLI, mais celles-ci peuvent avoir des problèmes de mise à l'échelle lorsqu'elles sont appliquées aux interfaces graphiques. Par exemple, la modélisation basée sur la machine à états finis - où un système est modélisé comme une machine à états finis et un programme est utilisé pour générer des cas de test qui exercent tous les états - peut bien fonctionner sur un système qui a un nombre limité d'états mais peut devenir trop complexe et peu maniable pour une interface graphique (voir aussi les tests basés sur des modèles ).
Planification et intelligence artificielle
Une nouvelle approche de la génération de suites de tests, adaptée d'une technique CLI, implique l'utilisation d'un système de planification. La planification est une technique bien étudiée du domaine de l' intelligence artificielle (IA) qui tente de résoudre des problèmes impliquant quatre paramètres:
- un état initial,
- un état d'objectif,
- un ensemble d'opérateurs, et
- un ensemble d'objets sur lesquels opérer.
Les systèmes de planification déterminent un chemin entre l'état initial et l'état cible à l'aide des opérateurs. À titre d'exemple simple d'un problème de planification, étant donné deux mots et une seule opération qui remplace une seule lettre dans un mot par une autre, le but pourrait être de changer un mot en un autre.
Dans les auteurs ont utilisé le planificateur IPP pour démontrer cette technique. L'interface utilisateur du système est d'abord analysée pour déterminer les opérations possibles. Ceux-ci deviennent les opérateurs utilisés dans le problème de planification. Ensuite, un état initial du système est déterminé, et un état d'objectif est spécifié qui, selon le testeur, permettrait d'exercer le système. Le système de planification détermine un chemin entre l'état initial et l'état cible, qui devient le plan de test.
L'utilisation d'un planificateur pour générer les cas de test présente certains avantages spécifiques par rapport à la génération manuelle. Un système de planification, de par sa nature même, génère des solutions aux problèmes de planification d'une manière très avantageuse pour le testeur:
- Les plans sont toujours valables. La sortie du système est soit un plan valide et correct qui utilise les opérateurs pour atteindre l'état de l'objectif, soit aucun plan du tout. Ceci est bénéfique car beaucoup de temps peut être perdu lors de la création manuelle d'une suite de tests en raison de cas de test non valides que le testeur pensait fonctionner mais qui ne l'ont pas fait.
- Un système de planification fait attention à l'ordre. Souvent, pour tester une certaine fonction, le scénario de test doit être complexe et suivre un chemin à travers l'interface graphique où les opérations sont effectuées dans un ordre spécifique. Lorsque cela est fait manuellement, cela peut entraîner des erreurs et peut également être assez difficile et long à faire.
- Enfin, et surtout, un système de planification est axé sur les objectifs. Le testeur concentre la génération de la suite de tests sur ce qui est le plus important, en testant la fonctionnalité du système.
Lors de la création manuelle d'une suite de tests, le testeur se concentre davantage sur la façon de tester une fonction (c'est-à-dire le chemin spécifique à travers l'interface graphique). En utilisant un système de planification, le chemin est pris en charge et le testeur peut se concentrer sur la fonction à tester. Un avantage supplémentaire de ceci est qu'un système de planification n'est en aucune façon limité lors de la génération du chemin et peut souvent trouver un chemin qui n'a jamais été anticipé par le testeur. Ce problème est très important à combattre.
Une autre méthode de génération de cas de test GUI simule un utilisateur novice. Un utilisateur expert d'un système a tendance à suivre un chemin direct et prévisible à travers une interface graphique, tandis qu'un utilisateur novice suivrait un chemin plus aléatoire. Un utilisateur novice est alors susceptible d'explorer plus d'états possibles de l'interface graphique qu'un expert.
La difficulté réside dans la génération de suites de tests qui simulent l'utilisation du système «novice». L'utilisation d'algorithmes génétiques a été proposée pour résoudre ce problème. Les chemins novices à travers le système ne sont pas des chemins aléatoires. Premièrement, un utilisateur novice apprendra au fil du temps et ne fera généralement pas les mêmes erreurs à plusieurs reprises, et, deuxièmement, un utilisateur novice suit un plan et a probablement une certaine connaissance du domaine ou du système.
Les algorithmes génétiques fonctionnent comme suit: un ensemble de «gènes» est créé au hasard et est ensuite soumis à une tâche. Les gènes qui complètent le mieux la tâche sont conservés et ceux qui ne le sont pas sont rejetés. Le processus est à nouveau répété, les gènes survivants étant répliqués et le reste de l'ensemble rempli de gènes plus aléatoires. Finalement, un gène (ou un petit ensemble de gènes s'il y a un certain seuil) sera le seul gène de l'ensemble et sera naturellement le meilleur ajustement pour le problème donné.
Dans le cas des tests GUI, la méthode fonctionne comme suit. Chaque gène est essentiellement une liste de valeurs entières aléatoires d'une longueur fixe. Chacun de ces gènes représente un chemin à travers l'interface graphique. Par exemple, pour un arbre donné de widgets, la première valeur du gène (chaque valeur est appelée un allèle) sélectionnerait le widget sur lequel opérer, les allèles suivants rempliraient alors l'entrée du widget en fonction du nombre d'entrées possibles au widget (par exemple, une zone de liste déroulante aurait une entrée… la valeur de liste sélectionnée). Le succès des gènes est noté par un critère qui récompense le meilleur comportement «novice».
Un système pour effectuer ces tests pour le système X window, mais extensible à tout système de fenêtrage est décrit dans. Le système X Window fournit des fonctionnalités (via XServer et le protocole des éditeurs) pour envoyer dynamiquement l'entrée GUI et obtenir la sortie GUI du programme sans utiliser directement l'interface graphique. Par exemple, on peut appeler XSendEvent () pour simuler un clic sur un menu déroulant, et ainsi de suite. Ce système permet aux chercheurs d'automatiser la création et les tests de gènes afin que pour toute application donnée en cours de test, un ensemble de cas de test d'utilisateurs novices puisse être créé.
Exécution des cas de test
Au début, les stratégies ont été migrées et adaptées à partir des stratégies de test CLI.
Capture de la position de la souris
Une méthode courante utilisée dans l'environnement CLI est la capture / lecture. La lecture de capture est un système dans lequel l'écran du système est «capturé» sous la forme d'un graphique bitmap à différents moments pendant les tests du système. Cette capture a permis au testeur de «relire» le processus de test et de comparer les écrans à la phase de sortie du test avec les écrans attendus. Cette validation pourrait être automatisée puisque les écrans seraient identiques si le cas passait et différents si le cas échouait.
L'utilisation de la capture / lecture fonctionnait assez bien dans le monde de la CLI, mais il y a des problèmes importants lorsque l'on essaie de l'implémenter sur un système basé sur une interface graphique. Le problème le plus évident que l'on trouve est que l'écran d'un système GUI peut être différent alors que l'état du système sous-jacent est le même, ce qui rend la validation automatisée extrêmement difficile. En effet, une interface graphique permet aux objets graphiques de varier en apparence et en placement à l'écran. Les polices peuvent être différentes, les couleurs ou les tailles des fenêtres peuvent varier, mais la sortie système est fondamentalement la même. Cela serait évident pour un utilisateur, mais pas évident pour un système de validation automatisé.
Capture d'événement
Pour lutter contre ce problème et d'autres, les testeurs sont allés «sous le capot» et ont collecté des données d'interaction GUI à partir du système de fenêtrage sous-jacent. En capturant les «événements» de la fenêtre dans des journaux, les interactions avec le système sont désormais dans un format découplé de l'apparence de l'interface graphique. Désormais, seuls les flux d'événements sont capturés. Un filtrage des flux d'événements est nécessaire car les flux d'événements sont généralement très détaillés et la plupart des événements ne sont pas directement liés au problème. Cette approche peut être facilitée en utilisant une architecture MVC par exemple et en rendant la vue (c'est-à-dire l'interface graphique ici) aussi simple que possible tandis que le modèle et le contrôleur détiennent toute la logique. Une autre approche consiste à utiliser la technologie d'assistance intégrée au logiciel , à utiliser une interface HTML ou une architecture à trois niveaux qui permet également de mieux séparer l'interface utilisateur du reste de l'application.
Une autre façon d'exécuter des tests sur une interface graphique est de créer un pilote dans l'interface graphique afin que des commandes ou des événements puissent être envoyés au logiciel à partir d'un autre programme. Cette méthode d'envoi direct d'événements et de réception d'événements à partir d'un système est hautement souhaitable lors des tests, car les tests d'entrée et de sortie peuvent être entièrement automatisés et l'erreur de l'utilisateur est éliminée.