Quelqu'un a-t-il utilisé SIKULI pour tester ses applications GUI?
SIKULI semble avoir une énorme quantité de possibilités. Personne n'a essayé de l'utiliser comme un outil pour tester? Ou serait-elle mieux adaptée à l'automatisation des actions pour les utilisateurs?
12 réponses
Citant (dans le projet Documentation):
Sikuli est conçu pour supporter les tests de l'unité GUI en s'intégrant avec junit. Le panneau de test de l'unité peut être ouvert en cliquant sur View/Unit Test ou en raccourci Cmd-U sur Mac (ou Ctrl-U sur Windows/Linux).
donc, bien que je comprenne que SIKULI est initialement destiné à l'automatisation GUI, il peut certainement être utilisé pour le test GUI (qui est étroitement liées si l'on considère que GUI test = GUI automatisation + cadre de vérification). Jetez un oeil à 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 tester car il semble faire des tests d'écriture très facile, même sans une seule ligne de la véritable application écrite (en utilisant juste quelques maquettes initiales par exemple). SIKULI pourrait devenir un grand compagnon pour les saveurs diverses de essais (BDD, essais d'acceptation, etc.).
c'est vraiment un logiciel incroyable, très impressionnant.
je me sers beaucoup de Sikuli pour automatiser les tests D'assurance-chômage. Je suis "en retard" pour le parti Sikuli, Je l'ai découvert en janvier 2011. En fait, je suis content de l'avoir découvert en retard, parce que même si elle était prometteuse plus tôt, Je ne pense pas jusqu'à Sikuli x1.0-rc1 (qui s'est produit en décembre) a été publié qu'il était prêt pour l'Heure de pointe.
auparavant, J'ai utilisé TestQuest et EggPlant pour l'automatisation des tests D'UI. À mon avis, Sikuli les bat tous les deux haut la main. Je crois vraiment qu'elle a la le potentiel de changer radicalement la façon dont les gens effectuent L'automatisation de test D'UI pour le mieux et sera l'évangélisation des gens autour de moi.
utiliser Sikuli correctement signifie que vous êtes suivant un modèle" record and playback". Vous devez plutôt aborder le développement de l'automatisation de test avec Sikuli - comme vous devez le faire avec tous les outils - comme une tâche de développement de logiciel.
nous sommes actuellement en train de porter un DSL (Domain Langue spécifique) nous avons construit pour aubergine à Sikuli. L'une des principales caractéristiques que nous utiliserons dans notre DSL est la capacité de reconnaissance de texte de Sikuli. Cela nous permettra d'exécuter le même script sur différentes versions localisées de notre produit.
parce que Sikuli construit sur OpenCV (pour la reconnaissance d'images) et tesseract-ocr (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
enregistré un flux de travail avec une application Web Flex. Il a fallu un certain temps pour 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é mon arrangement de couleur de bureau! La syntaxe devient un peu embarrassante quand vous devez cliquer sur un contrôle spécifique dans une collection de contrôles similaires, c'est-à-dire des cases à cocher, des champs d'entrée. On dirait que la seule façon de le faire est d'utiliser find() en combinaison avec right(); left(); inside(). Semble que plus les captures d'écran sont, le de manière plus fiable, ils sont détectés. Imo 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 unicité.
@jordan, Absolutley spot on ' utiliser Sikuli correctement signifie que vous ne suivez pas un modèle "record and playback". Vous devez plutôt aborder le développement de l'automatisation de test avec Sikuli - comme vous devez le faire avec tous les outils - comme une tâche de développement de logiciel.
j'ai créé une solution d'automatisation de test de bout en bout pour tester une application de visioconférence faite par le plus grand fabricant de PC au monde. Ils n'ont pas compris que c'était un dev projet, pas un point et cliquez sur fonctionnement que n'importe quel singe pourrait s'exécuter. Essayer d'expliquer les défis du codage avec un langage dynamiquement typé était impossible.
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 de configparser a fonctionné cependant il était difficile à mettre en œuvre. Dans le futur, je prévois d'utiliser des blobs. Sikuli ne supporte pas l'extraction directe d'images à partir D'un DB (encore) bien que j'ai un contourner.
L'utilisation d'un IDE est critique puisque le Sikuli IDE ne dispose pas d'outils de développement. Les 2 IDE que J'ai configurés, NetBeans et Eclipse / PyDev ont leurs propres problèmes. Les sont grands pour le codage cependant fausses erreurs, l'injection de blancs espace et la perte de code font à la fois des solutions moins qu'idéales. Je code et teste dans NetBeans, exécute dans SikuliIDE et enregistre tout dans notepad comme une 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 de la qualité sans avoir à être un codeur OO.
pour l'automatisation des tests moins axée sur les développeurs pour Sikuli, consultez aussi RobotFramework.org. Il y a un tutoriel sur la façon de faire une bibliothèque de test Sikuli (personnalisé) pour le cadre de Robot
http://blog.mykhailo.com/2011/02/how-to-sikuli-and-robot-framework.html
et j'ai créé un simple générique version
http://code.google.com/p/simplesikuli
et s'il y avait des limites pour Sikuli en termes de gestion des fenêtres, commandes graphiques, interaction avec la souris et le clavier, vous pouvez toujours le compléter avec un autre outil de test gratuit: AutoIt. AutoIt à lui seul a aussi des limites, quand vous le combinez avec Sikuli, ils compensent pour chaque défaut d'outils, pour remplacer les outils D'essai GUI de qualité commerciale.
Voici mon point de vue sur la qualité exceptionnelle de Sikuli pour l'automatisation des tests: http://pculture.org/devblogs/mirotesting/2011/06/24/using-sikuli-to-automate-miro-testing/
J'ai une suite de test multi-plateforme fiable pour Miro.
je suis en train d'écrire un framework pour tester/traiter les erreurs avec sikuli. C'est génial.
j'ai utilisé sikuli pour tester L'interface graphique, et J'ai pu l'intégrer à HUDSON.
je viens de publier mon propre framework pour les tests D'application GUI en utilisant Skikuli + Robotfram Framework.
Sikulifram Framework fournit une abstraction orientée objet au - dessus de Sikuli pour aider avec les éléments d'interface graphique en interaction, tels que les ensembles de boutons, les cases à cocher, les boutons radio, les fenêtres et les hiérarchies de dialogue pour l'automatisation et le test D'interface graphique. Il a également une intégration étroite avec Robotfram Framework.
Sikuli est basé sur une correspondance d'image statique. Elle ne convient donc qu'aux situations où l'interface graphique est suffisamment stable. Pour L'interface graphique dynamique comme l'animation ou L'interface graphique qui inclut une sorte de caractère aléatoire, elle n'est pas applicable.
et Sikuli ne couvre que la partie visuelle du Produit Testé. Il n'a aucune idée si l'état interne est effectivement comme prévu.