Question

Je vais bientôt commencer à coder des tests automatisés de notre présentation. Il semble que tout le monde recommande WatiN et Selenium . Que préférez-vous pour le test automatisé des formulaires Web ASP.NET? Lequel de ces produits vous convient le mieux?

En note de bas de page, j'ai remarqué que WatiN 2.0 est dans CTP depuis mars 2008, est-ce un sujet de préoccupation?

Était-ce utile?

La solution

Je veux juste dire que je travaille actuellement sur une version bêta de WatiN 2.0 quelque part au premier trimestre de 2009. Ce sera une mise à niveau majeure des versions actuelles de CTP 2.0 et vous offrira essentiellement les mêmes fonctionnalités pour automatiser FireFox. et IE en tant que version 1.3.0 propose d’automatiser IE.

Donc, pas d'inquiétude là-bas.

J'espère que cela vous aidera à faire votre choix Jeroen van Menen Chef de projet WatiN

Autres conseils

Si vous souhaitez investir sérieusement à long terme dans un cadre qui continuera à être amélioré et soutenu par la communauté, Selenium est probablement votre meilleur choix. Par exemple, je viens de trouver cette information sur le blog de Matt Raible:

  

Vendredi, Google compte plus de 50 équipes.   en cours d'exécution sur 51K tests par jour sur   ferme de sélénium interne. 96% de ces   les tests sont gérés par Selenium RC et   les machines agricoles correctement. L'autre   4% sont en partie dus à des bugs RC, en partie   pour tester les erreurs, mais en isolant le   cause peut être difficile. Le sélénium a   été adopté comme technologie primaire   pour le test fonctionnel du Web   applications au sein de Google. C'est le   bonne nouvelle.

J'ai récemment assisté à l'une des réunions Selenium et appris que Google investissait des ressources considérables dans l'amélioration de Selenium et son intégration à WebDriver, un outil de test automatisé développé par Simon Stewart. L'un des principaux avantages de WebDriver réside dans le fait qu'il contrôle le navigateur lui-même plutôt que de s'exécuter dans le navigateur en tant qu'application Javascript, ce qui signifie que de gros obstacles comme la "même origine" problème ne sera plus un problème.

Nous avons testé les deux et avons décidé d’utiliser WaTiN. Comme d'autres l'ont fait remarquer, Selenium présente certaines fonctionnalités intéressantes que l'on ne retrouve pas dans WaTiN, mais nous avons rencontré des problèmes pour que Selenium fonctionne et une fois que nous l'avons fait, il était nettement plus lent lors des tests que pour WaTiN. Si je me souviens bien, les problèmes d'installation que nous avons rencontrés découlaient du fait que Selenium avait une application distincte pour contrôler le navigateur actuel, où WaTiN a tout fait en cours de traitement.

Je les ai essayés tous les deux et voici mes pensées initiales ...

WatiN

Le bien

  • Exécution rapide.
  • Les outils de création de script sont des projets indépendants. il y en a deux que je connais: Wax (basé sur Excel, hébergé sur CodePlex) et Enregistrement du test WatiN (hébergé sur SourceForge). Ni est aussi robuste que Selenium IDE.
  • Très bon support IE. Peut attacher et détacher des instances en cours d'exécution. Peut accéder aux descripteurs de fenêtre natifs, etc. (voir l'exemple de script ci-dessous).
  • Pack NuGet, facile à utiliser dans les environnements de style .NET et Visual Studio et à garder à jour.

Le mauvais

  • Google recherche souvent "watir xyz" dans Google. au lieu. Pas beaucoup de documentation là-bas.
  • Le peu de choses qui existe (documentation) est déroutant. Par exemple: à première vue, il semblerait qu'il n'y ait pas de support natif pour les sélecteurs CSS. D'autant qu'il existe des bibliothèques d'extensions telles que 'WatiNCssSelectorExtensions' et de nombreux articles de blog sur les techniques alternatives (telles que l'injection de jQuery / sizzle dans la page). Sur Stack Overflow, j’ai trouvé un commentaire de Jeroen van Menen qui suggère que il y a un support natif. Au moins, le développeur principal passe son temps à Stack Overflow:)
  • Pas de support XPath natif.
  • Pas d'exécution immédiate basée sur la grille / l'exécution basée sur la grille.

Exemple de script (C #). Vous ne pouvez pas faire cela avec Selenium (pas que je sache, au moins):

class IEManager
{
    IE _ie = null;
    object _lock = new object();

    IE GetInstance(string UrlFragment)
    {
        lock (_lock)
        {
            if (_ie == null)
            {
                var instances = new IECollection(true);  //Find all existing IE instances
                var match = instances.FirstOrDefault(ie=>ie.Url.Contains(UrlFragment));
                _ie = match ?? new IE();
                if (match==null)  //we created a new instance, so we should clean it up when done!
                    _ie.AutoClose = true;
            }
        }

        return _ie;
    }
}

Sélénium

  • Plus lent que WatiN (d’autant plus qu’un nouveau processus doit être créé).
  • Sélecteurs CSS intégrés / support XPath.
  • Selenium IDE est bon (on ne peut pas en dire autant, mais c’est le meilleur de sa catégorie!).
  • se sent plus Java-ish que .NET-ish ... mais vraiment, il est agnostique de langage de programmation; toutes les commandes sont envoyées à un «pilote» hors processus. Le pilote est en réalité un processus "hôte" pour l'instance de navigateur. Toutes les communications doivent être sérialisées à l’intérieur et à l’extérieur des processus, ce qui pourrait expliquer les problèmes de rapidité liés à WatiN.
  • Processus découplés - " Pilote " et " Control " signifie plus de robustesse, plus de complexité, etc., mais aussi plus facile à créer des grilles / environnements de test distribués. J'aurais vraiment aimé si la " distribution " mécanisme (c’est-à-dire que la communication entre le pilote et le contrôle) s’appliquait via WebSphere ou un autre gestionnaire de files d’attente de messages robuste existant.
  • Prise en charge de chrome et des autres navigateurs prêts à l'emploi.

Malgré tout, j’ai suivi WatiN; J'ai principalement l'intention d'écrire de petites applications de grattage d'écran et d'utiliser LINQPad pour le développement. Le rattachement à une instance IE distante (que je n'ai pas générée moi-même) est un avantage considérable. Je peux jouer dans une instance existante, puis exécuter un peu de script, puis à nouveau, etc. C'est plus difficile à faire avec Selenium, bien que je suppose que "pauses" pourrait être intégré au script pendant lequel je pourrais jouer directement avec le navigateur.

La plus grande différence est que Selenium prend en charge différents navigateurs (pas seulement IE ou FF, voir http : //seleniumhq.org/about/platforms.html#browsers .

De plus, Selenium dispose d’un serveur de contrôle distant ( http://seleniumhq.org/projects/remote- control / ), ce qui signifie que vous n'avez pas besoin d'exécuter le navigateur sur la même machine que le code de test. Vous pouvez donc tester votre application Web. sur différentes plates-formes de système d'exploitation.

En général, je vous recommanderais d'utiliser Selenium. J'ai utilisé WatiN il y a quelques années, mais je n'étais pas satisfait de sa stabilité (elle s'est probablement améliorée à ce jour). Pour moi, le plus gros avantage de Selenium est le fait que vous pouvez tester l'application Web. sur différents navigateurs.

Ni l'un ni l'autre. Utilisez Coypu. Cela enveloppe le sélénium. Beaucoup plus durable. https://github.com/featurist/coypu

Mettre à jour Ye Oliver tu as raison. Ok pourquoi c'est mieux? Personnellement, j’ai trouvé que le pilote Selenium pour IE, en particulier, était très fragile. Il existe un certain nombre d’exceptions de pilotes «standard» que j’ai de nouveau trouvées lors de la conduite de Selenium for Unit Tests sur des sites Web lourds ajax.

Ai-je indiqué que je souhaitais écrire mes scripts en c # en tant que projet test? Oui Tests d'acceptation dans le cadre d'un déploiement en continu.

Eh bien, Coypu traite de ce qui précède. C’est un wrapper pour Selenium qui permet de réaliser des tests tels que,

browser.Visit("file:///C:/users/adiel/localstuff.htm")
browser.Select("toyota").From("make");
browser.ClickButton("Search");

... qui lancera un navigateur (marque configurable) et exécutera le script. Il fonctionne très bien avec les régions couvertes et est très extensible.

Il y a d'autres exemples sur GitHub et, comme Olvier le mentionne ci-dessous, la vidéo d'Adrian est excellente. Je pense que c'est la meilleure façon de mener des tests sur navigateur dans le monde .Net et d'essayer de suivre son nom Ruby capybara

J'ai utilisé les deux, ils semblent tous les deux bien fonctionner. Mon signe de tête est pour Selenium car il semblait avoir un meilleur support pour Ajax. Je pense que WaTiN a mûri depuis la dernière fois que je l’ai utilisé, il devrait donc avoir la même chose.

La chose la plus importante serait dans quel environnement de développement aimez-vous être? Selenium et Watin ont des enregistreurs, mais Selenium est dans le navigateur et watin est dans Visual Studio. + et - à tous les deux.

Jusqu'à présent, nous sommes un pur Microsoft Shop pour fournir des solutions aux entreprises et avons opté pour WatiN. Cela pourrait changer à l'avenir.

En tant que source plus récente:

Microsoft a imprimé MSDN Magazine 12/2010 BDD-Primer avec la combinaison de SpecFlow et de WatiN (cool développement basé sur le comportement BDD). Son auteur Brandon Satrom (évangéliste du développeur msft) a également publié en décembre 2010 un Webcast vidéo , qui explique en détail les résultats 1: 1 ci-dessus.

Il existe un Livre blanc de 04/2011 sur le support ATDD / BDD avec SpecLog, SpecFlow et Team Foundation Server (développement basé sur les tests d'acceptation / basé sur les comportements) à partir de Christian Hassa , dont l'équipe a créé SpecFlow.

J'utilise Watin, mais je n'ai pas utilisé de sélénium. Je peux dire que je me suis vite mis au travail sur Watin et que je n’ai eu que peu de problèmes. Je ne peux penser à rien de ce que j'ai voulu faire que je ne pouvais pas comprendre avec ça. HTH

J'utilise généralement Selenium, principalement parce que j'aime bien le plug-in Selenium IDE pour FireFox permettant d'enregistrer les points de départ de mes tests.

Je recommande WebAii , car c'est ce que j'ai eu du succès avec et quand je l'utilise. mes reproches étaient peu nombreux. Je n'ai jamais essayé Selenium et je ne me souviens pas d'avoir beaucoup utilisé WaTiN, du moins pas au point où je pourrais le faire fonctionner avec succès. Je ne connais aucun framework qui gère correctement les boîtes de dialogue Windows, bien que WebAii dispose d'une interface permettant d'implémenter vos propres gestionnaires de boîte de dialogue.

J'ai envisagé d'utiliser les deux. J'ai utilisé l'enregistreur pour Selenium pour construire des tests en FF. J’ai essayé de faire de même avec Watin et j’ai constaté que Watin Recorder (2.0.9.1228) n’avait aucune valeur pour nos sites . Il semble que le site soit rendu dans IE6, ce qui rend notre site inutilisable pour l’enregistrement. Nous ne supportons pas IE6. Je n'ai trouvé aucun moyen de changer le navigateur utilisé. Je n'ai trouvé qu'un seul enregistreur Watin. S'il y en a plus d'un, ou un qui est tenu à jour, veuillez commenter.

Selenium Recorder IDE for Firefox est simple à utiliser et transfère les tests en C #. Ce n'est pas génial à ça. Je ne parvenais pas à faire fonctionner des suites de tests de portage, malgré la lecture d'un article de blog ou deux qui contenaient des solutions de rechange. Il y a donc un peu de manipulation du code généré. Pourtant, cela fonctionne à 90% et c'est mieux que l'alternative.

Pour mon argent et mon temps, le sélénium est supérieur uniquement pour la facilité de création de nouveaux tests . IE n’a pas de bonnes barres d’outils pour les développeurs aussi proches de Firebug , aussi je fais mon développement sous Firefox pour commencer, donc avoir un bon enregistreur dans Firefox est un énorme bonus .

Ma conclusion ici ressemble beaucoup à cette citation de Churchill sur la démocratie: Le sélénium est la pire forme de test automatisé de l’UI. À l'exception de tous les autres.

Au risque de prendre une tangente, je recommanderais Ax / WatiN. Axe permet aux tests d'être écrits dans Excel par des testeurs "manuels" qui ne connaissent pas le "langage" du test sous-jacent. Il faut un "technicien" pour écrire les actions sur mesure (IE. Aujourd'hui, je devais faire une recherche de tableau légèrement complexe et une référence croisée), mais une fois écrites, les actions peuvent être utilisées dans des tests par des testeurs non techniciens.

J'ai aussi entendu dire que le projet britannique Government Gateway (qui, à mon avis, propose des tests automatisés 6K +) a récemment transféré tous ses tests d'Ax / Winrunner à Ax / Watin en une semaine! Et bon nombre des tests sont assez complexes - je le sais car j’y ai travaillé il y a quelques années ...

Je regarde Selenium pour le moment, car un client potentiel l’utilise. Mais je suggère de regarder Axe comme une couche au-dessus de l'outil "Cheval de travail".

Si vous devez accéder à des iframes, des boîtes de dialogue modales et des iframes entre domaines, WatiN est une solution. Selenium ne pouvait pas gérer les iframes générant des exceptions de délai de commande. WatiN pourrait faire beaucoup plus de choses, en particulier si le site Web utilise des éléments spécifiques à IE, tels que ShowModalDialog, etc. WatiN les gère très bien. Je pourrais même faire un accès iframe interdomaine.

Vous devrez faire les deux si vous devez faire des tests IE et FF, mais ils ne fonctionneront que très bien pour les tests de présentation. Ils ne peuvent pas détecter si un élément est légèrement éteint, mais simplement que les éléments sont présents. Je ne connais rien qui puisse remplacer l’œil humain pour les tests d’interface utilisateur / de présentation, bien que vous puissiez faire certaines choses pour l’aider (prenez des captures d’écran des pages à chaque étape pour que les utilisateurs puissent les consulter).

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top