Utilisez Selenium RC directement ou sélénium avec un cadre robot

Question

Je dois admettre que je suis tombé amoureux de Sélénium pour sa fonction d'enregistrement et de jeu ainsi que la fonctionnalité de génération de testcase pour les actions enregistrées de l'IDE. Mais je suis toujours hésité à passer à la phase de mise en œuvre en raison du détails accessoires (par exemple, localiser les événements avec DOM, xpath..etc) qui sont intégrés au testcase pendant l'enregistrement, ce qui pourrait rendre la panne de test sujette chaque fois qu'il y a un changement HTML une fois qu'il est importé dans le RC. Je comprends parfaitement que cela fait partie des travaux des testeurs pour ajuster les résultats attendus de temps à autre dans le cadre du test de régression, mais je ne souhaite pas non plus que le temps passé à ce sujet soit plus grand que le temps qui prend pour faire le test manuel .

Pour autant que je sache Sélénium avec cadre robot a la forme de mots clés des cas de test. Je suppose que cela nous permet d'extraire les détails fortuits dans divers mots clés, ce qui pourrait faciliter le réglage des cas de test et plus maintenable. (S'il vous plait corrigez moi si je me trompe)

Il sera apprécié d'entendre des suggestions sur la façon dont un environnement d'automatisation de l'interface utilisateur efficace devrait être configuré. Dois-je simplement utiliser le sélénium RC ou le sélénium avec un cadre robot? Et pourquoi?

Merci d'avance

Answer 1

Vous avez absolument raison que des détails accessoires et souvent changeants dans les scripts produits sont le plus gros problème de l'automatisation des enregistrements et des jeux. Vous pouvez évidemment supprimer les détails des scripts après l'enregistrement, mais à mon avis, il est préférable de créer manuellement des bibliothèques et des scripts de code réutilisables dès le début.

Une bonne alternative pour le codage des scripts à l'aide de «vraies» langages de programmation consiste à utiliser un cadre d'automatisation de niveau supérieur tel que Cadre de robot que vous avez mentionné. Comme vous l'avez supposé, les mots clés et les variables réutilisables de Robot rendent également les détails d'extraction des tests très faciles. Les cas de test dans Démo de séléniumLibrary illustre très bien cela et la démo montre également comment utiliser le sélénium via Robot.

Vous avez également posé des questions sur Sikuli. Je ne l'ai jamais utilisé moi-même mais ça a l'air intéressant. Vous pourriez être intéressé ce super commentaire Cela explique comment l'utiliser via Robot Framework.

Answer 2

Notre entreprise utilise Fitnesse, pas Robot, pour contrôler le sélénium cependant, nous avons le même problème. Nous sommes passés de faire des hypothèses sur le DOM pour accéder uniquement aux éléments par ID. Comme cela est lourd en fitnesse, nous travaillons actuellement pour ajouter un backend de sélénium à notre propre cadre (qui n'avait auparavant que des backends pour Java et Smalltalk).

Ainsi, en exigeant que les éléments avec certains ID soient présents dans le DOM, nous allons bien sûr briser nos tests si quelqu'un supprime les éléments de la page; Cependant, nous avons constaté que ce comportement est très utile car cela applique le contrat que les tests ont fait avec la mise en œuvre et c'est une bonne chose que nous trouvons des éléments manquants dès que quelqu'un a brisé la mise en œuvre.

De plus, il est bon à maintenir la peau d'automatisation de l'interface utilisateur: testez uniquement ce qui est présent sur la page avec du sélénium et testez le logique commercial en appelant directement les fonctions sous-jacentes.