SIKULI semble avoir un énorme potentiel. Quelqu'un a-t-il essayé de l'utiliser comme outil de test ? Ou serait-il mieux adapté à l'automatisation d'actions pour les utilisateurs ?
Réponses
Trop de publicités?Citation : Tests unitaires pour les interfaces graphiques (dans le projet Documentation ) :
Sikuli est conçu pour supporter les tests unitaires pour les interfaces graphiques en s'intégrant à junit. Le panneau des tests unitaires peut être ouvert en cliquant sur View/Unit Test ou par le raccourci Cmd-U sur Mac (ou Ctrl-U sur Windows/Linux).
Ainsi, même si je crois comprendre que SIKULI est initialement destiné à l'automatisation des interfaces graphiques, il peut certainement être utilisé pour les tests d'interfaces graphiques (qui sont étroitement liés si vous considérez que les tests d'interfaces graphiques = automatisation des interfaces graphiques + cadre de vérification). Jetez un coup d'œil à Tests unitaires pour l'interface graphique (JEdit) pour un exemple complet (et voir le assertXXX
sur les images).
Et en effet, je vois un grand potentiel dans SIKULI pour les tests car il semble rendre l'écriture de tests très facile, même sans une seule ligne de l'application réelle écrite (juste en utilisant quelques maquettes initiales par exemple). SIKULI pourrait devenir un excellent compagnon pour différents types de tests (BDD, tests d'acceptation, etc.).
C'est vraiment un logiciel étonnant, très impressionnant.
J'utilise Sikuli de manière intensive pour l'automatisation des tests de l'interface utilisateur. J'ai découvert Sikuli "en retard", en janvier 2011. En fait, je suis content de l'avoir découvert tardivement, car même s'il était prometteur auparavant, je ne pense pas qu'il ait été prêt pour le primetime avant la sortie de Sikuli x1.0-rc1 (qui a eu lieu en décembre).
Auparavant, j'ai utilisé TestQuest et EggPlant pour l'automatisation des tests d'interface utilisateur. À mon avis, Sikuli les surpasse tous les deux haut la main. Je crois vraiment qu'il a le potentiel de changer radicalement la façon dont les gens effectuent l'automatisation des tests d'interface utilisateur pour le mieux et je vais l'évangéliser autour de moi.
Utiliser correctement Sikuli signifie que vous êtes no selon un modèle "enregistrement et lecture". Vous devez plutôt aborder le développement de l'automatisation des tests avec Sikuli - comme vous devez le faire avec tous les outils - comme une tâche de développement logiciel.
Nous sommes actuellement en train de porter un DSL (Domain Specific Language) d'automatisation de l'interface utilisateur que nous avons construit pour EggPlant vers Sikuli. L'une des principales fonctionnalités que nous allons exploiter dans notre DSL est la capacité de reconnaissance de texte de Sikuli. Cela nous permettra d'exécuter le même script dans diverses versions localisées de notre produit.
Parce que Sikuli s'appuie sur OpenCV (pour la reconnaissance d'images) y tesseract-ocr (pour la reconnaissance de texte) il a une puissance et une flexibilité incroyables.
Voir aussi le document : http://groups.csail.mit.edu/uid/projects/sikuli/sikuli-chi2010.pdf
@jordan, Absolument exact "Utiliser Sikuli correctement signifie que vous ne suivez pas un modèle "enregistrement et lecture". Vous devez plutôt aborder le développement de l'automatisation des tests avec Sikuli - comme vous devez le faire avec tous les outils - comme une tâche de développement logiciel.
J'ai créé une solution d'automatisation des tests de bout en bout pour tester une application de vidéoconférence réalisée par le plus grand fabricant mondial de PC. Ils ne comprenaient pas qu'il s'agissait d'un projet de développement complet, et non d'une opération de type pointer-cliquer que n'importe quel singe pouvait exécuter. Il était impossible d'expliquer les défis du codage dans un langage à typage dynamique.
D'après mon expérience, le plus grand défi est la gestion de l'image. J'ai utilisé le système de fichiers et configparser pour la première itération de l'automatisation des tests. L'utilisation du configparser a fonctionné, mais il était difficile à mettre en œuvre. Dans le futur, je prévois d'utiliser des blobs. Sikuli ne supporte pas (encore) l'extraction directe des images d'une base de données, mais j'ai une solution de contournement.
L'utilisation d'un IDE est essentielle car l'IDE Sikuli ne dispose pas d'outils de développement. Les deux IDE que j'ai configurés, NetBeans et Eclipse/PyDev, ont leur propre lot de problèmes. Ils sont parfaits pour coder, mais les fausses erreurs, l'injection d'espaces blancs et la perte de code en font des solutions loin d'être idéales. Je code et teste dans NetBeans, j'exécute dans SikuliIDE et je sauvegarde tout dans notepad comme sauvegarde.
En dépit de toutes les difficultés rencontrées, je suis un grand partisan de Sikuli. Sikuli a le potentiel de changer l'automatisation des tests, en la rendant accessible à l'ensemble de la communauté de l'assurance qualité sans avoir besoin d'être un codeur OO.
Enregistrement d'un flux de travail avec une application web Flex. J'ai mis du temps à trouver une stratégie fiable pour créer les captures d'écran, mais une fois que je l'ai fait, le script a continué à fonctionner même après que j'ai changé la couleur de mon bureau ! La syntaxe devient un peu maladroite cependant lorsque vous devez cliquer sur un contrôle spécifique dans une collection de contrôles similaires, c'est-à-dire des cases à cocher, des champs de saisie. Il semble que la seule façon de le faire est d'utiliser find()
en combinaison avec right(); left(); inside()
. Il semble que plus les captures d'écran sont petites, plus elles sont détectées de manière fiable. Une bonne pratique serait de n'inclure que les objets significatifs sur les captures d'écran, et de les rendre aussi atomiques que possible, mais sans compromettre leur caractère unique.