Quel problème le test automatisé de l'interface utilisateur résout-il?

Nous étudions actuellement les tests automatisés de l'interface utilisateur (nous effectuons actuellement des tests unitaires et d'intégration automatisés).

Nous avons examiné Selenium et Telerik et avons choisi ce dernier comme l'outil de choix en raison de son enregistreur beaucoup plus flexible - et nous ne voulons pas vraiment que les testeurs écrivent trop de code.

Cependant, j'essaie de comprendre l'avantage global. Quelle est l'opinion des gens et quel genre de choses fonctionne bien et qu'est-ce qui ne fonctionne pas?

Notre système est en constante évolution et nous publions régulièrement de nouvelles versions de notre plateforme (basée sur le Web).

Jusqu'à présent, le principal avantage que nous pouvons constater concerne les tests de régression, en particulier sur plusieurs déploiements clients de notre plateforme.

Vraiment à la recherche des opinions des autres. Nous «pensons» que c'est la bonne chose à faire, mais dans un calendrier déjà chargé, nous recherchons des informations supplémentaires.

Lorsque mon équipe a mis en œuvre des tests d'interface utilisateur automatisés, de nombreuses choses formidables se sont produites.

Tout d'abord, l'équipe QA est devenue beaucoup plus efficace pour tester l'application et plus compétente avec l'application. Le responsable QA a déclaré qu'il était en mesure de mettre rapidement les nouveaux membres QA au courant en les présentant aux suites de tests pour l'interface utilisateur.

Deuxièmement, la qualité des tickets QA qui sont revenus à l'équipe de développement était meilleure. Au lieu de «La page s'est cassée lorsque j'ai cliqué sur le bouton Soumettre», nous avons obtenu le cas exact qui a échoué afin que nous puissions voir ce qui a été entré dans le formulaire. L'équipe QA est également allée plus loin en vérifiant tous les cas qui ont échoué et a testé d'autres scénarios autour de cette page pour nous donner une meilleure vue de ce qui s'est passé.

Troisièmement, l'équipe QA a eu plus de temps. Avec ce temps supplémentaire, ils ont pu participer à davantage de réunions de conception. À leur tour, cela leur a permis d'écrire les nouveaux cas de suite de tests en même temps que les développeurs codaient ces nouvelles fonctionnalités.

De plus, les tests de résistance que la suite de tests que nous avons utilisée valaient son pesant d'or. Honnêtement, cela m'a aidé à mieux dormir la nuit en sachant que notre application pouvait accepter à peu près tout ce qui était lancé. Nous avons trouvé pas mal de pages qui se sont effondrées sous la pression que nous avons pu corriger avant la mise en ligne. Juste parfait.

La dernière chose que nous avons trouvée, c'est qu'avec quelques ajustements de l'équipe QA, nous pourrions également faire des tests d'injection SQL sur notre application. Nous avons trouvé des vulnérabilités que nous avons pu corriger rapidement.

La configuration de la suite de tests d'interface utilisateur a pris beaucoup de temps. Mais, une fois sur place, elle est devenue un élément central de notre processus de développement.

Les tests d'interface utilisateur automatisés sont les vrais tests d'intégration. Ils testent l'ensemble du système de la manière dont il est réellement utilisé lorsqu'il est en direct. Cela en fait les tests les plus significatifs. Cependant, ils ont également tendance à être les plus fragiles et les plus lents à exécuter.

Gardez un œil sur le rapport coût / bénéfice (la fragilité faisant partie du coût) et n'hésitez pas à faire tester certaines choses uniquement manuellement (mais assurez-vous qu'elles le sont ). Et si possible, permettez aux développeurs d'exécuter des parties spécifiques de la suite de tests d'interface utilisateur par rapport à leur version locale de l'application, afin qu'ils puissent bénéficier des tests pendant le développement.

Bien entendu, l'exécution automatique des tests sur un serveur de build (au moins une fois par jour) est absolument indispensable.

nous ne voulons pas vraiment que les testeurs écrivent trop de code.

OMI c'est un rêve de pipe. Créer des tests automatisés, c'est écrire du code. La fonctionnalité d' enregistrement peut vous aider à écrire une partie de ce code plus rapide et commencer plus rapidement avec l'écrire manuellement (et vous ralentir terriblement si vous manquez le point où l' écriture de code devient manuellement plus rapidement), mais en fin de compte écrire du code manuellement ce que vous allez finir par faire beaucoup. Mieux vaut espérer que votre framework de test le supporte bien et que son développement ne se soit pas trop concentré sur le rêve de pipe (très vendable) de permettre aux personnes qui ne peuvent pas écrire de code de produire des tests automatisés.

et nous ne voulons pas vraiment que les testeurs écrivent trop de code

Nous avons adopté l'approche inverse. Nous voulions que les testeurs écrivent du code.

Voici le workflow que nous avons commencé à adopter. Ce n'est pas facile à faire car la gestion ne dépend pas absolument des tests automatisés du front-end. Ils sont prêts à se contenter de "assez près".

1. Histoires d'utilisateurs.

2. Concept opérationnel. Comment l'histoire fonctionnerait probablement. Examen de la conception.

3. Croquis d'écran: conception de l'interface utilisateur. À quoi cela ressemblerait.

4. Scripts de sélénium. Si les scripts fonctionnent tous, nous avons terminé avec la version.

5. Codage et test jusqu'à ce que le script fonctionne.

Les tests automatisés sont le seul moyen de démontrer que la fonctionnalité existe.

Les tests manuels sont sujets aux erreurs et sujets à un dépassement de gestion: "c'est assez bien, ces tests qui échouent n'ont pas autant d'importance que de les publier à temps."

"Toute fonctionnalité de programme sans test automatisé n'existe tout simplement pas."

La présentation visuelle est une autre histoire. Le test manuel d'une disposition visuelle est un cas exceptionnel car il peut impliquer soit un jugement esthétique, soit l'examen de (petits) problèmes spécifiques sur un écran de pixels très grand et complexe.

Jusqu'à présent, le principal avantage que nous pouvons constater concerne les tests de régression, en particulier sur plusieurs déploiements clients de notre plateforme.

L'automatisation de vos tests de régression est une bonne chose. Cela libère vos testeurs pour effectuer des travaux plus intéressants - que ce soit en ajoutant des tests plus automatisés, des tests de résistance de votre application ou un certain nombre d'autres choses.

De plus, en le rendant automatisé, vous pouvez demander à vos développeurs d'exécuter les tests et donc de prévenir les problèmes qui ne sont découverts que plus tard dans le processus.

Nous avons examiné Selenium et Telerik et avons choisi ce dernier comme l'outil de choix en raison de son enregistreur beaucoup plus flexible

Je ne sais pas à quel point vous y avez réfléchi. Il y a certainement d'autres options également. Avez-vous examiné Watir , WatiN , Sikuli pour n'en nommer que quelques-uns?

et nous ne voulons pas vraiment que les testeurs écrivent trop de code.

Je me sens mal pour les gens qui doivent maintenir ces scripts. Le plus souvent, sans code facilement modifiable, les scripts deviennent fragiles et il faut plus de temps pour modifier le script que pour le réenregistrer, ce qui fait perdre encore plus de temps.

Cependant, j'essaie de comprendre l'avantage global. Quelle est l'opinion des gens et quel genre de choses fonctionne bien et qu'est-ce qui ne fonctionne pas?

L'automatisation des tests est une belle chose lorsqu'elle est effectuée correctement. Il fait gagner du temps sur les tests / vérifications de régression afin de donner à vos testeurs plus de temps pour faire ce qu'ils font le mieux, tester. Ne croyez pas un instant que c'est une solution miracle. Les scripts d'automatisation nécessitent beaucoup de temps pour se développer si l'application existe déjà, mais pas les tests, et nécessitent une mise à jour constante avec chaque version. Les tests automatisés sont également un excellent moyen pour les nouvelles personnes de l'équipe de voir comment le système est censé se comporter. Assurez-vous également que vos testeurs décident de ce qui doit être automatisé. S'il s'agit d'un petit chèque qui ne prend pas beaucoup de temps à vérifier, qui est très monotone et facile à automatiser, commencez par cela. Commencez toujours par les vérifications qui gagnent le plus grâce à l'automatisation, et travaillez à partir de là.

Jusqu'à présent, le principal avantage que nous pouvons constater concerne les tests de régression, en particulier sur plusieurs déploiements clients de notre plateforme.

C'est le principal avantage, et s'il est correctement configuré, il peut tester la plupart des navigateurs dont vous auriez besoin avec une petite modification de configuration.

Nous «pensons» que c'est la bonne chose à faire, mais dans un calendrier déjà chargé, nous recherchons des informations supplémentaires.

Comme je l'ai dit plus tôt, l'automatisation des tests demande des efforts considérables, cependant, une fois correctement effectuée, je n'ai pas encore rencontré une équipe qui a déclaré: "Je souhaite que nous n'ayons pas configuré notre automatisation des tests."

Vous avez raison, la régression est énorme. Également -

• si vos tests sont écrits de manière modulaire, vous pouvez en avoir plus pour votre argent en mélangeant et en assortissant les ensembles de tests

• nous avons réutilisé des scripts de test automatisés pour le chargement des données afin de ne pas avoir à surcharger une base de données pour effectuer des tests de grande taille

• test de performance

• tests multi-threads

• sur les systèmes Web - permutation entre les navigateurs et permutation entre les systèmes d'exploitation. Avec les problèmes de cohérence du navigateur, atteindre une base aussi large que possible est une chose énorme.

Éléments à ignorer - en particulier dans les systèmes Web, faites attention aux cas où des éléments de votre affichage sont créés avec des ID dynamiques et changeants - les scripts de test automatisés ne gèrent souvent pas bien cela, et vous devrez peut-être une refonte sérieuse pour mettre à jour cela.

Un seul exemple: mesurer avec précision la durée de rendu d'une page Web

À l'aide de tests d'automatisation, il est beaucoup plus facile de tester les performances du navigateur Web. Pour mesurer le temps de réponse maximum que vous êtes susceptible d'accepter, définissez simplement une constante dans vos scripts de test et / ou passez-la comme paramètre de fonction, par exemple dans ce pseudocode: $ sel-> wait_for_page_to_load ($ mypage, $ maxtime).

Faire des tests multi-navigateurs avec des valeurs faibles peut être très instructif.

L'alternative serait de demander aux employés d'effectuer des mesures de chronométrage avec un chronomètre.

Les tests automatisés de l'interface utilisateur permettent de:

• répéter rapidement les tests d'un grand nombre de composants
• n'oubliez pas de tester un grand nombre de fonctions à chaque fois
• comparer les exécutions et les temps d'exécution des suites de tests à mesure que l'application se développe
• configurer des parcours avec des centaines d'entrées différentes et des conditions variables
• permettre aux personnes qui n'ont pas écrit le test de l'exécuter et de voir les problèmes visuels
• permettre aux utilisateurs finaux de voir l'application utilisée de manière simple et rapide
• distribuer des tests d'interface utilisateur sur un réseau, un serveur ou un service distant
• démarrer les tests de volume à l'aide de machines parallèles.

Cependant, comme d'autres l'ont noté:

Telerik ...

l'outil de choix grâce à son enregistreur beaucoup plus flexible

est un drapeau rouge pour beaucoup d'entre nous.

Les scripts enregistrés de cette manière ne sont généralement pas une solution à long terme car:

• la base de données / l'ID d'objet ont tendance à changer d'un cas à l'autre
• les scripts enregistrés manuellement reposent souvent sur des balises de mise en page qui changent fréquemment
• les actions courantes devront être écrites encore et encore au lieu de permettre leur réutilisation (voir l'approche SitePrism & PageObject)
• parfois, vous devez utiliser des outils tels que xpath pour récupérer des informations supplémentaires en fonction des informations de la page actuelle. Un simple script enregistré ne fera pas cela.
• les développeurs et les testeurs qui écrivent du code ne seront pas encouragés à utiliser des classes CSS, des ID et des attributs de données HTML5, qui sont des pratiques qui conduiront à des tests plus robustes et plus faciles à maintenir.

Telerik présente cependant certains avantages qui doivent être pris en compte:

• destiné aux clients mobiles
• des outils intégrés pour gérer la croissance
• gère Android, iOS et Windows Phone

Une approche qui peut aider à combler les lacunes consiste à enregistrer le script initial à l'aide de l'enregistreur de page d'outils, puis à modifier le script pour utiliser les ID, les classes et les attributs de données afin qu'il dure dans le temps. C'est une approche que j'ai réellement utilisée avec le plugin firefox selenium.

Il facilite les «tests experts» (similaires aux «tests exploratoires», mais effectués par des utilisateurs finaux ou des membres de l'équipe ayant une grande connaissance de l'entreprise), plus faciles à réaliser, à enregistrer les résultats, à mesurer et à automatiser.

J'en viens à un contexte différent. Chez mes anciens employeurs, nous avons développé des outils de test automatisés commerciaux (QALoad, QARun, TestPartner, SilkTest, SilkPerfomer).

Nous avons vu les tests d'interface utilisateur automatisés comme remplissant deux rôles:

1. Test de régression complet

2. Configuration automatisée des environnements de test

Nous nous sommes fortement appuyés sur les outils pour effectuer des tests de régression tous les soirs. Nous n'avions tout simplement pas le pouvoir de tester tous les boutons et boîtes de dialogue pour vérifier que nous n'avions rien cassé entre l'interface utilisateur et la logique métier.

Pour des tests plus importants, nous avons constaté qu'une seule personne pouvait faire tourner plusieurs machines virtuelles et utiliser des scripts pour arriver à un véritable test. Il leur a permis de se concentrer sur les bits importants et de ne pas essayer de suivre un cas de test en 24 étapes.

Le seul problème avec les tests automatisés était l'habitude de vider trop de tests sur la boîte sans aucune sorte de supervision pour éliminer les tests en double ou inutiles. De temps en temps, nous devions rentrer et tailler les choses afin que la suite puisse se terminer en moins de 12 heures.

Les tests automatisés, de toute nature, prévoient des tests de régression; en exécutant le test qui fonctionnait auparavant, vous vérifiez qu'il fonctionne toujours (ou ne fonctionne pas), indépendamment de tout ce que vous avez ajouté. Cela est vrai que le test soit un test d'intégration (qui ne touche généralement pas l'interface utilisateur) ou un AAT (qui nécessite généralement l'interface utilisateur).

Les tests automatisés de l'interface utilisateur permettent de tester le système comme si un utilisateur cliquait sur des boutons. De tels tests peuvent ainsi être utilisés pour vérifier la navigation dans le système, l'exactitude des étiquettes et / ou des messages, les performances et / ou les temps de chargement dans un environnement de test particulier, etc. etc. L'objectif principal est de réduire le temps passé par le gars AQ à cliquer sur les boutons, tout comme l'intégration et les tests unitaires pour le programmeur. Il peut configurer un test une fois (généralement en enregistrant ses propres clics de souris et entrées de données dans un script), et une fois que le test fonctionne correctement, tout ce qu'il doit faire pour vérifier l'exactitude du système testé est relancé. Certains frameworks, tels que Selenium, permettent de migrer les tests entre les navigateurs, permettant de tester plusieurs environnements dans lesquels le site devrait fonctionner correctement.

Sans test automatisé, vous êtes limité par le nombre et la vitesse de vos testeurs QA; ils doivent littéralement avoir une expérience pratique du système, testant que votre nouvelle fonctionnalité répond aux exigences et (tout aussi important) que vous n'avez rien cassé qui était déjà là.

Les tests déterminent de nombreuses choses différentes. Beaucoup de ces tests peuvent être automatisés, pour permettre de supprimer les corvées et pour en faire plus. Pour déterminer si vos tests peuvent être automatisés, vous devez d'abord voir si la question qu'ils posent est appropriée.

• Déterminez-vous si un composant fonctionne conformément aux spécifications?
• Voulez-vous tester toutes les différentes entrées et sorties possibles?
• tester la résistance du composant?
• Ou essayez-vous de vérifier que "cela fonctionne"?

La plupart d'entre eux peuvent être automatisés, car ils sont de nature mécanique. La nouvelle fonction accepte les entrées, alors que se passe-t-il lorsque nous lui envoyons des données aléatoires? Mais certains, comme tester si le système fonctionne, nécessitent que quelqu'un l' utilise réellement . S'ils ne le font pas, vous ne saurez jamais si les attentes de vos utilisateurs sont les mêmes que celles du programme. Jusqu'à ce que le système «casse».

D'après mon expérience, les tests automatisés de l'interface utilisateur couvrent de nombreuses lacunes, notamment:

• Manque de documentation (exemple: utilisation du lanceur de test automatisé pour faire la démonstration des fonctionnalités existantes)
• Exigences dépassées en raison du fluage de la portée (exemple: identification de l'écart entre les exigences et le code en capturant l'écran pendant les tests)
• Taux de rotation élevé des développeurs et des testeurs (exemple: reverse engineering legacy JavaScript by capture the screen during test runs with the developer tool open)
• Identification des violations des conventions de dénomination standard via les tests de régression XPath (exemple: recherche dans tous les nœuds d'attribut DOM des noms de casse de chameau)
• Reconnaître les failles de sécurité que seul un ordinateur peut découvrir (exemple: se déconnecter d'un onglet tout en soumettant simultanément un formulaire dans l'autre)

Je souhaite partager l'expérience de notre équipe. Nous utilisons notre propre outil de test d'interface utilisateur, Screenster, pour tester les nôtres et les applications Web de nos clients. Il s'est avéré être une alternative utile à Selenium pour les tâches de test visuel / CSS. Screenster est un outil d'automatisation de test qui effectue une comparaison basée sur des captures d'écran de différentes versions de vos pages Web. Tout d'abord, il crée une ligne de base visuelle pour une page, en prenant une capture d'écran pour chaque action de l'utilisateur. Lors de la prochaine exécution, il prend une nouvelle capture d'écran à chaque étape, la compare à celle de la ligne de base et met en évidence les différences.

Pour résumer, Screenster présente les avantages suivants: Base de référence visuelle: des captures d'écran sont capturées pour chaque étape de l'utilisateur pendant l'enregistrement de test Comparaison basée sur des captures d'écran: Screenster compare les images capturées pendant une lecture à celles de la ligne de base et met en évidence toutes les différences Sélecteurs CSS intelligents: le testeur peut sélectionner Éléments CSS sur les captures d'écran et effectuez des actions avec eux - par exemple, marquez-les comme ignorant les régions à exclure de toute comparaison ultérieure