Test automatisé d'interface graphique: nous rencontrer à mi-chemin

https://stackoverflow.com/questions/822275

03-07-2019
|

Question

J'ai été chargé de développer un système de test automatisé d'interface graphique et je pourrais vous donner quelques conseils. Comme par hasard, nous sommes en train de revoir complètement notre interface graphique et les développeurs effectuant le travail sont prêts à rendre leur code plus convivial pour l'automatisation. Mon problème est que je ne sais pas trop quoi leur demander. Les points d'ancrage ajoutés ne peuvent pas affecter la fonctionnalité, l'apparence ou la sécurité de l'interface et ne devraient pas avoir d'impact notable sur les performances. Sinon, le ciel est la limite!

L’application en question est une application Java Web accessible via AJAX. La plupart des fonctionnalités existantes sont codées à l'aide de jsp, Javascript et un peu de Flash 8. La prochaine série de fonctionnalités sera réalisée à l'aide de bibliothèque Javascript YUI . Je suis plutôt à l'aise avec Selenium comme outil de test en raison de sa flexibilité et de son prix (gratuit). Point majeur: je vise la réutilisabilité des tests et la facilité de maintenance. Ma préférence est d'écrire du code qui détecte, valide et utilise les éléments de la page plutôt que d'utiliser un système d'enregistrement et de lecture pour le développement de tests.

Quelqu'un peut-il donner des indications sur les crochets qui pourraient être placés dans le code ou sur les meilleures pratiques pour faciliter le développement de tests et rendre les tests plus robustes?

La solution

Principe de base: s'ils veulent que vous testiez quelque chose, les testeurs ont besoin d'un moyen de placer l'application dans cet état et, une fois dans cet état, d'un moyen de valider que l'état est correct.

La première chose à faire est donc de s’assurer qu’ils comprennent que l’automatisation est une programmation et que l’UI est votre API.

Accord pour ne pas changer arbitrairement l'interface utilisateur - si le testeur Bob voit que le composant est passé d'un bouton à un lien, et qu'il correspond à la spécification, clique et continue. Bien que le changement de code en automatisation soit relativement facile, il peut s’avérer nécessaire de le faire à plusieurs endroits. (Votre travail en tant que testeur consiste à comprendre que des changements surviennent et à minimiser les coûts de maintenance; leur travail consiste uniquement à apporter des modifications importantes et à en comprendre l'impact)
Un moyen de déterminer la page sur laquelle vous vous trouvez .... Bob peut faire la différence entre la connexion et la saisie de commande, mais comment l’automatisation le saura-t-elle? Si un champ avec le libellé "Nom d'utilisateur" est affiché, la page de connexion. Si un champ de saisie avec numéro de commande, le champ de commande.

Pas bien - la meilleure pratique est un élément d'interface utilisateur cohérent pour identifier le titre de la page, le composant caché, etc.

Un moyen d'identifier de manière unique chaque élément avec lequel vous devez interagir (cliquer, taper, vérifier, etc.) et pas INPUT_42 ....
Demandez aux développeurs quelles informations les testeurs peuvent leur fournir pour accélérer leur débogage et demandez-leur de les insérer dans un fichier journal
Possibilité d'afficher l'état du programme
Traitement des erreurs cohérent & amp; création de rapports (tout simplement une bonne conception d'interface utilisateur)

Autres conseils

Comme avec la plupart des questions, cela dépend. Principalement sur l'apparence de votre site et sur le type de contrôles sur les pages: y a-t-il beaucoup d'éléments répétés, etc.?

J'ai eu beaucoup de succès avec Selenium RC et Selenium IDE. Le principal est de s’habituer à utiliser Selenium et ses commandes. Il est également utile de s'habituer à localiser des objets sur la page (sélecteurs XPaths et CSS, ainsi que la fonction 'contient'). Ce que vous ne voulez pas, c'est beaucoup d'éléments qui ont le même chemin de sélection. Si les tableaux et les divs ci-dessous ne comportent pas une partie unique, cela peut ajouter une complexité supplémentaire à vos tests.

<html>
  <body>
    <table>
      <tr>
        <td>
          <div></div>
          <div></div>
          <div></div>
        </td>
      </tr>
    </table>
    <table>
      <tr>
        <td>
          <div></div>
          <div></div>
          <div></div>
        </td>
      </tr>
    </table>
  </body>
</html>

Pour tester les images, il est agréable de pouvoir vérifier leur existence en fonction d'un nom autre que le nom du fichier image. Vous n'avez donc pas à modifier vos tests lorsque l'image est mise à jour. Si vous devez tester des objets Flash, consultez ce site .

Au-delà de cela, je n’ai pas remarqué beaucoup de choses qui puissent être intégrées au développement. Une fois que vous avez commencé à configurer les tests et à localiser les éléments sur la page, vous verrez probablement assez rapidement ce que les développeurs doivent faire pour vous aider.

Un conseil: conservez votre code de test à au moins deux couches d'abstraction :

couche supérieure : il s’agit d’une façade orientée vers la terminologie / les actions de votre application, etc. Cette couche n’utilise pas directement la bibliothèque Selenium RC . En arrière-plan, il utilise le ...
... couche inférieure : une bibliothèque avec des modèles de test communs (exemple: " affirme que la valeur X du contrôle du bouton radio est choisie ") , qui utilise la bibliothèque Selenium RC.

De cette manière, vos tests seront plus propres et plus compréhensibles pour ce qui est testé. Nous avons même essayé une approche en trois couches, la troisième couche (la plus haute) constituant les tests spécifiés à l'aide de XML. . Ceci afin de permettre à nos testeurs hors programmation de pouvoir spécifier des tests d'acceptation sans fouiller dans le code C #.

Ajout aux commentaires de McWafflestix et de s_hewitt - Les éléments gui doivent être correctement étiquetés, uniques et prévisibles pour assurer le succès de l’automatisation gui. Si les identifiants d'élément ne sont pas prévisibles, vous rencontrerez des problèmes. Prévisible ne signifie pas nécessairement statique. Pour les éléments de page statiques tels qu'un champ de nom d'utilisateur ou un bouton de connexion, je m'attendrais à ce que le nom / id de ces éléments soit statique à partir de build à build et à l'exécution. Pour les cases à cocher, les boutons radio et le contenu dynamique, je m'attendrais à ce qu'ils soient dynamiques, mais prévisibles. Par exemple, vous pourriez avoir un div avec un class = " contentdetail " et un id = "12345". Tant que vous pouvez créer votre xpath pour trouver l'objet avec lequel vous avez besoin d'interagir de manière fiable, vous devriez être bon.

EDIT: La configuration de test est un excellent moyen pour les développeurs de prendre en charge l'automatisation de test. En fonction de votre application, la configuration et le démontage automatisés des tests peuvent être problématiques. Par exemple, dans une application de flux de travaux d'entrepôt, les tests au début du flux de travail (accepter des articles dans le magasin) sont faciles à configurer, mais les tests à la fin du flux de travail (expédier un article de l'entrepôt au client) de nombreuses dépendances (article doit être dans un entrepôt, avec une quantité suffisante, dans un emplacement correct pour l'inventaire, etc.) que la plupart de votre code d'automatisation peut traiter simplement en naviguant et en entrant votre chemin dans l'application pour arriver au point où vous pouvez l'exécuter un examen. Dans ces cas, il peut être avantageux de disposer d'un type d'utilitaire externe (en dehors de l'application, de sorte que l'interface graphique principale n'est pas affectée) pour injecter des dépendances ou réinitialiser la base de données à un état connu. Dans mon exemple d’entrepôt, votre service public pourrait configurer le scénario via le niveau de l’API, de sorte que le test de l’interface graphique automatisée puisse être effectué au point approprié.

Il y a très peu de choses que les développeurs peuvent ajouter au code pour vous aider.

Le problème est que si vous souhaitez tester l'exécution des chemins de code et leur validité, vous devez le faire dans les tests unitaires et les divorcer complètement de votre interface graphique. Mais si vous voulez vraiment tester votre interface graphique, vous devez simuler les entrées de l'utilisateur. La seule chose qui puisse vous aider est que vos objets et vos contrôles soient correctement étiquetés de sorte qu'ils puissent être correctement détectés par votre infrastructure de test et être exercés. En dehors de cela, il n’ya tout simplement pas grand chose à faire (bien que cela puisse aider un peu en soi).

Je suis plutôt vert en ce qui concerne les tests unitaires (appropriés), mais j'ai mentionné quelques fois que vous devriez essayer d'éviter de tester votre interface graphique. Ils omettent généralement des raisons spécifiques, je ne peux donc pas vraiment les sauvegarder.

L’approche que j’adopte (et je pense que l’approche proposée par Juval Lowy dans "Programmation de composants .NET") consiste à essayer d’abstraire le code réel de l’interface graphique via une interface, ce qui me permet d’écrire des tests unitaires pour toutes les applications. logique métier déclenchée par l'interface graphique sans tester l'interface graphique elle-même.

Cela fonctionne plutôt bien et a abouti à un code beaucoup plus propre, avec une grande séparation de la logique métier et de l'interface graphique, ainsi que des modifications d'interface graphique beaucoup moins stressantes.

Licencié sous: CC-BY-SA avec attribution

Non affilié à StackOverflow