Tests d'interface graphique [fermé]

Question

Je travaille sur la question de tester mon interface graphique et je ne suis pas tout à fait sûr de la meilleure approche ici. Mon interface graphique est construite à l'aide d'un framework MVC traditionnel, ce qui me permet de tester facilement les parties logiques de l'interface graphique sans afficher l'interface graphique elle-même. Cependant, lorsqu'il s'agit de tester les fonctionnalités de l'interface graphique, je ne sais pas vraiment si je devrais m'inquiéter de tester individuellement des composants d'interface graphique ou si je devrais me concentrer principalement sur les tests fonctionnels du système. Il s'agit d'un système assez complexe dans lequel le test de l'interface graphique implique souvent l'envoi d'un message au serveur, puis l'observation de la réponse sur l'interface graphique. Mes idées initiales sont que les tests fonctionnels sont la voie à suivre ici car j'ai besoin de tout un système en marche pour vraiment tester l'interface utilisateur. Des commentaires sur cette question seraient appréciés.

Merci, Jeff

Answer 1

Vous avez (au moins) 2 problèmes - la complexité de l'environnement (le serveur) et la complexité de l'interface graphique.

Il existe de nombreux outils pour automatiser les tests d'interface graphique. Tous sont plus ou moins fragiles et nécessitent un entretien quasi constant face aux changements de disposition. Leur utilisation présente des avantages, mais c’est un avantage à long terme.

L’environnement, en revanche, est un domaine qui peut être apprivoisé. Si votre application est architecturée à l'aide de la technique Dependency Injection / Inversion (où vous "injectez" le composant serveur dans l'application), vous pouvez utiliser une "maquette" des interfaces de serveur pertinentes pour vous permettre de scripter des scénarios de test.

La combinaison de ces deux techniques vous permettra d’automatiser le test de l’interface graphique.

Une dernière pensée: bonne chance!

Answer 2

Les autres outils de test d'interface graphique que je peux proposer sont les suivants: Thoughtworks White , PyWinAuto , AutoIt , AutoHotKey .

Une chose à garder à l’esprit lorsque vous essayez d’automatiser des interfaces graphiques est que la seule façon de le faire est de construire cette interface graphique en gardant à l’esprit l’automatisation. Les développeurs qui pensent que leurs interfaces graphiques ne devraient pas prendre en charge la testabilité au début du projet et exposent volontiers tous les points d'ancrage qui peuvent aider à l'automatisation à la demande, car vos besoins en tests l'exigent.

Answer 3

Selon l'endroit où vous vous situez dans le spectre de MVC (c'est un terme surutilisé), le test de la vue peut être un processus mécanique permettant de s'assurer que les méthodes de modèle appropriées sont appelées en réponse aux entrées correctes de la vue pour tester un client. validation côté à qui sait.

De nombreux modèles issus de MVC (je pense à affichage passif , contrôleur de supervision ) s'efforcent de faire en sorte que la vue nécessite très peu de tests, car elle est vraiment câblage des entrées utilisateur au présentateur ou au modèle (en fonction de la variante exacte du motif que vous utilisez).

"Le test de l'interface graphique implique souvent l'envoi d'un message au serveur, puis l'observation de la réponse sur l'interface graphique " Cette déclaration m'inquiète.

Je pense immédiatement que l'interface graphique doit être testée à l'aide d'une maquette ou d'un moignon du serveur pour vérifier que les interactions correctes se produisent et que l'interface graphique répond correctement.

Si vous avez besoin de tests fonctionnels automatisés du serveur, je ne vois pas la nécessité d'impliquer l'interface graphique.

Answer 4

Mercury QuickTest Pro, Borland SilkTest et Ranorex Recorder sont des outils de test d'interface graphique.

Answer 5

Si votre application est basée sur le Web, vous pouvez rédiger des tests à l'aide d'outils tels que WatiN ou Selenium .

Si votre application est basée sur Windows .NET, vous pouvez essayer Blanc .

Answer 6

Mon conseil: oubliez les tests d'interface graphique traditionnels. C'est trop cher. La codification des tests prend beaucoup de temps, les outils n'étant pas vraiment stables, vous obtiendrez des résultats de test non fiables. Le couplage entre le code et le test est très fort et vous passerez beaucoup de temps à la maintenance.

La nouvelle tendance consiste à ignorer les tests d'interface graphique. Voir le modèle ModelViewPresenter de Fowler comme guide texte du lien

Answer 7

La façon la plus claire de dire ceci est:

Ne perdez pas votre temps à écrire des tests d'interface graphique automatisés .

Surtout lorsque vous travaillez avec une application MVC. Dans votre cas, lorsque vous envoyez un message au serveur, vous pouvez vous assurer que le bon numéro de message est correctement enregistré. Vous pouvez ajouter des cas supplémentaires ou un autre test complètement pour vous assurer que l'interface graphique convertit l'identifiant du message en chaînes appropriées, mais vous devez simplement exécuter ce test une fois.

Answer 8

Nous intégrons des tests d'interface graphique à notre projet, ce qui a des effets secondaires. Les développeurs ont toutefois un principe de conception essentiel: Gardez la couche graphique aussi fine que possible!

Cela signifie pas de logique dans les classes d'interface graphique. Séparez-le dans les modèles de présentation responsables de la validation des entrées, etc.

Pour tester sur un ordinateur Unix, nous utilisons le serveur Xvfb en tant qu'AFFICHAGE lors de l'exécution des tests.

Answer 9

Essayez le test d'utilisation des couloirs . C'est bon marché et utile: allez dans le couloir le plus proche, prenez la première personne qui passe, assoyez-la devant votre ordinateur et utilisez votre logiciel. Regardez par-dessus leur épaule, vous verrez ce qu'ils essaient de faire, ce qui les frustre, etc. Faites cela plusieurs fois et notez les motifs.

Answer 10

Ce que vous recherchez, c’est les "tests d’acceptation". La façon dont vous le faites dépend des frameworks que vous utilisez, du type d'application que vous créez et de la langue. Si vous recherchez votre technologie et la phrase ci-dessus sur Google, vous devriez trouver des outils que vous pouvez utiliser.

Answer 11

J'ai trouvé WinTask un très bon moyen de tester l'interface graphique. Si vous ne modifiez pas constamment la façon dont le système d'exploitation fait référence à chaque élément de l'interface utilisateur, WinTask adresse les éléments de l'interface utilisateur par leur nom. Ainsi, même si la présentation change, les éléments de l'interface utilisateur peuvent toujours être activés / modifiés / sélectionnés.

Answer 12

Ne manquez pas le "U" dans "l'interface graphique"
Je veux dire: si tout ce que vous essayez de tester fonctionne correctement et fonctionne comme prévu, alors vous pouvez suivre Réponse de Seb Rose .

Mais s'il vous plaît, n'oubliez pas qu'une interface utilisateur doit être configurée en pensant à USERS , et non à TOUT utilisateur, mais à l'UTILISATEUR CIBLE pour lequel l'application a été créée. Ainsi, une fois que vous êtes certain que tout fonctionne comme prévu, soumettez chaque vue / écran / formulaire à un test avec une équipe composée d'utilisateurs représentant chaque groupe d'utilisateurs pouvant utiliser votre application: utilisateurs avancés, administrateurs, MS Office utilisateurs, utilisateurs de profil d'ordinateur faible, utilisateurs de profil d'ordinateur élevé ... et ensuite, recevez les critiques de chaque utilisateur, faites un mix, retouchez votre interface graphique si nécessaire, puis revenez au test de l'utilisateur de l'interface graphique.

Answer 13

Pour les tests d'interface graphique Web SIMPLE, essayez iMacros . Firefox plug-in, a une fonctionnalité intéressante pour envoyer le test complet à une autre personne)  Notez que SIMPLE a été orthographié avec des initiales ...