Tester une application Gui-heavy WPF
We (my colleagues) have a messy 12 y. O. application mature basée sur GUI, et le plan actuel est d'ajouter de nouveaux dialogues et D'autres GUI dans WPF, ainsi que de remplacer certains des dialogues plus anciens dans WPF aussi bien. Dans le même temps, nous souhaitons pouvoir tester cette Monster - GUI automation de manière maintenable. Quelques défis:
- l'application est massive.
- il gagne constamment de nouvelles fonctionnalités.
- il est en train de changer (corrections de bug, correctifs).
- il a une extrémité arrière, et une couche entre les deux. L'état de la situation peut devenir hors de combat si vous battez à mort.
Ce que nous voulons, c'est:
- un outil qui peut automatiser les tests de WPF.
- auto-découverte de ce que les entrées et les sorties de la boîte de dialogue. Un vieux test doit encore fonctionner si vous ajoutez une étiquette qui ne fait rien. Il devrait échouer, cependant, si vous supprimez un champ de texte nécessaire. Ce serait très agréable si la suite de test était facile à entretenir, si elle fonctionnait et ne cassait pas la plupart du temps.
- toute nouvelle boîte de dialogue doit être créée en gardant à l'esprit la testabilité.
à ce point je ne sais pas exactement ce que je veux, donc je marque ceci comme un wiki communautaire. Si avoir à tester une application GUI énorme basé sonne la cloche (même si pas dans WPF), alors s'il vous plaît partager votre bon, mauvais et laide expériences ici.
5 réponses
OK, votre application sonne grand! Je peux partager mes expériences autour d'une application que nous avons conçue récemment; il s'agissait d'une interface graphique de services web vers un serveur qui à son tour a contacté plusieurs bases de données et d'autres services web. La base de clients était d'environ 15.000 utilisateurs... dans tous les cas - c'est beaucoup de travail, peu importe comment vous l'abordez; le bon côté est qu'il vous aidera à ne pas mâcher vos ongles à chaque fois que vous faites une version!
MVVM
en général, je recommande également le modèle MVVM et faire autant de tests que possible sans L'interface graphique. Le test de GUI est tout simplement difficile! J'aime Josh Smith article sur MSDN: " des Applications WPF Avec Le Modèle model-View-ViewModel Modèle de Conception " ( http://msdn.microsoft.com/en-us/magazine/dd419663.aspx )
Test De Script
le truc avec cette application était que nous avions beaucoup à test, les tripes sont constamment en mouvement et il y avait (étrangement) pas assez de gens pour obtenir les tests travail effectué pour chaque itération.
ma solution a été de trouver un outil de test personnalisé qui a mis à profit les bibliothèques existantes. Nous avions un simple moteur de script qui lisait un fichier et exécutait des commandes. En effet, nous avons développé un DSL ( http://en.wikipedia.org/wiki/Domain-specific_language ) pour tester nos application. La DSL comprenait quelques commandes simples pour signaler ce que" fenêtre "elle testait, n'importe quels signaux" setup " spécifiques et puis une série de commandes suivies par des assertions. Il ressemblait à quelque chose comme ceci:
Test NewXyzItem Setup Clear_items Press Some_button Enter_text_into Name Bobby Joe (...) Press Save Assert_db_has_itemX SomeKey
le format de chaque ligne est
"command" "argument" [data]
Les scripts d'aller dans des groupes de répertoires et le "testeur" des charges, analyse et les exécute. Créer des journaux et des rapports comme vous allez est utile, j'ai été ajouté dans hook pour faire des captures d'écran, etc, qui est venu dans maniable. si vous êtes intéressé à mettre en œuvre quelque chose comme ceci et que vous voulez un coup de main, faites-moi savoir .
ce qui était pratique ici, c'était que nous pouvions apporter des changements généraux à la stratégie d'essai.
écrire les scripts devient assez simple ce qui est important parce que vous finissez avec beaucoup, beaucoup de scripts. Les contrôles sont découverts par nom si vous suivez une convention (par exemple, "Nom" peut être "NameTextBox "en code, ou" Save "pourrait être"SaveButton").
vous pouvez en fait harnacher NUnit etc pour être votre coureur de test aussi.
NOTE-il suffit d'exécuter les tests de façon interactive, il est difficile et problématique de faire fonctionner le test GUI Avec CI...
données et essais
une chose importante ici est que la gestion des données était une partie énorme du problème de test et ne peut pas être négligée. Notre le "nouveau déploiement" était également très long, mais certaines parties étaient externes et nous n'avions aucun contrôle sur la fraîcheur des données. La façon dont nous avons géré le nettoyage était de fournir des crochets à travers le script qui nous a permis de retirer facilement les objets avant les tests. Pas optimal, mais rarement problématique.
bibliothèques
La bibliothèque que vous pouvez trouver le plus utile dans les " Blanc " ( http://white.codeplex.com / ) il peut tester les applications windows en général-I. e WPF et WinForms. Essentiellement, on finit par coder des choses comme ça:
Button button = window.Get<Button>("SaveButton");
button.Click();
si votre application fait des appels asynchrones, vous aurez besoin de trouver une stratégie pour que le coureur de test sache quand l'appel asynchrone est terminé, peut-être via la barre d'état ou quelque chose. Cela dépend de la façon dont vous accrochez...
Encore une fois, beaucoup de travail, mais ça en vaut la peine.
PK :- )
à mon avis, L'un des principaux points forts du FPF est en fait la capacité de ne pas avoir besoin de tests spécifiques à L'assurance-chômage. Utiliser une approche M-V-VM vous permettrait de sortir la logique de la zone UI/messy-GUI. Avoir un modèle de vue d'unité testable (surtout si vous écrivez de nouveaux dialogues!) vous permet d'écrire des tests unitaires qui émulent le clic de votre interface graphique.
je voudrais vraiment reconsidérer ce que vous voulez accomplir en passant à WPF et ce que vous voulez accomplir avec un certain type de test automatisé d'une interface graphique WPF. Une fois que cela a été établi, regardez dans qui passe de WinForms à WPF si cela répond encore à vos besoins.
comme dit Jimmy Lyke, la plupart de vos tests devraient être concentrés sur le modèle de vue. Cela consiste à écrire des tests unitaires pour le modèle de vue - essentiellement en envoyant des commandes et en définissant et obtenant des propriétés.
une fois que cela est fait, 95% de vos tests sont hors de portée. Si vous voulez le prendre un peu plus loin et tester la vue au-delà de la MANUELLE "Walkthrough" test que vous feriez de toute façon, il ya un certain nombre de "contrôles de santé" simples, vous pouvez facilement automatiser pour s'assurer vous n'avez pas accidentellement supprimer une boîte de texte importante ou rendre un indicateur visuel invisible.
chacune des techniques suivantes peut être automatisée à l'aide d'un code d'automatisation simple qui utilise une approche par "fusil de chasse" en faisant aveuglément l'arbre visuel et en ne présumant rien au sujet de la structure réelle de L'UI.
-
pour vérifier que toutes les données de ViewModel sont liées, trouver tous les visuels et Freezables (en utilisant l'arbre visuel) et vérifier chaque lié propriété pour le chemin de liaison de son expression de liaison.
-
pour vérifier que toutes les données de ViewModel sont affichées d'une manière ou d'une autre, modifiez les données de ViewModel en utilisant un script et après chaque changement utilise RenderTargetBitmap pour capturer L'UI et le comparer avec avant le changement de données pour s'assurer que L'UI a changé.
-
pour vérifier que les valeurs des propriétés sont mises à jour correctement, trouver tous les visuels et Freezables, et les balayages et enregistre toutes les propriétés liées sur eux, puis faire le changement de ViewModel, rescan, et searche pour le changement prévu à n'importe quelle propriété du type donné. (Pour double-vérifier, vous pouvez alors utiliser la technique de comparaison bitmap sur le visuel affecté particulier.)
-
pour vérifier que toutes les commandes sont accessibles, définissez un État ViewModel connu puis lancez chaque commande liée à un bouton visible pour voir si l'une d'elles déclenche L'ICommand ou autre mise à jour ViewModel de l'état.
-
pour vérifier qu'une propriété de ViewModel est réellement modifiable par l'utilisateur, changez le contenu ou la sélection de chaque boîte de texte, boîte de dialogue, Boîte aux lettres visible pour voir si l'un d'eux affecte la propriété.
-
pour avoir l'occasion de vérifier tout changement qui affecte L'UI, garder une base de données contenant des instantanés bitmap de chaque vue dans les différents états de ViewModel dans un ensemble de fenêtre différente taille. Quand une nouvelle version de l'application est construite, exécutez le même système de snapshot et comparez avec les bitmaps précédents. Si quelque chose a changé, créez une tâche manuelle pour que le personnel de L'assurance de la qualité puisse comparer visuellement les anciens et les nouveaux bitmaps pour voir si quelque chose d'important a changé.
une autre automatisation de test est possible sur la vue, mais ce qui précède vous donnera un début.
Encore une fois, je dois souligner qu'il est préférable de se concentrer sur testé le ViewModel. Les Bugs dans la vue elle-même sont assez rares, généralement détectés rapidement, et généralement triviaux à corriger. Mais une fois que le test de ViewModel est complet, il est logique de faire une certaine automatisation du test de vue.
Vous avez une très grande application. Je devine qu'il a beaucoup de logique enveloppé avec la couche de présentation et vous ne serez jamais donné le temps de reformuler la bête pour séparer la vue du reste de la logique.
Vous n'avez pas beaucoup de choix ici, mais:
- Refactoriser le code comme vous allez le long. Cela peut être de petites extractions de méthode de sorte que vous pouvez Unité de test ou de passer à un modèle approprié.
- utiliser un ou plus de la variété de Windows GUI outils de test . Notez que si vous prévoyez beaucoup de changements de mise en page et/ou de contrôle, reportez-les le plus longtemps possible. Les outils de cet article utiliseront le positionnement absolu des actions, le contrôle lié (parfois par des identificateurs internes) ou un mélange des deux. Puisqu'ils doivent généralement être formés sans utiliser de code (visant les testeurs de QC, pas les programmeurs), vos tests cesseront de fonctionner après le changement.
- Investir dans l'humain les testeurs. Bien que ce ne soit pas un bon choix, il améliore la qualité de la fin et commence à faire réfléchir la direction sur les coûts de refonte de l'application.
pour tester les applications WPF, nous avons eu du succès avec:
et serait peut-être le nouveau VSTS 2010 features , bien que nous ne les avons pas essayé