J'ai une application Java qui utilise JOGL pour fournir une grande partie de l'interface graphique.
Y a-t-il un outil que vous connaissez ou avez utilisé qui peut automatiser le test d'applications OpenGL (ou plus spécifiques à ceux utilisant JOGL)
Juste pour mettre à jour: l'outil peut exécuter sous Linux ou Windows.
3 Réponses :
J'ai écrit des tests d'unité pour C ++ (QT sur Linux) et OpenGL avant. Je ne sais aucune raison pour laquelle il ne devrait pas travailler pour Java aussi.
Les choses qui fonctionnaient pour moi sont:
Résumé Votre fournisseur de contexte OpenGL afin que le reste de votre code soit indépendant de celui-ci. Dans mon cas, l'application principale utilisée Qt's Qglwidget, mais les instances utilisaient un PBuffer basé sur lequel je pouvais créer avec aucune infrastructure de fenêtrage du tout (autre qu'un affichage X11 désigné). Plus tard, j'ai ajouté une "Mesa offscreen" (implémentation pure logiciel OpenGL) afin qu'elle fonctionne même sur une machine de construction sans tête sans GPU du tout.
Gardez votre code OpenGL indépendant de votre code d'interface graphique. Dans mon cas, le "moteur de rendu" OpenGL ne savait rien des classes Qt (E. E. Events de la souris). Définissez votre propre API testable qui n'est pas liée à des concepts d'interface graphique spécifiques et d'écrire des tests pour cela.
dans les unesest, lisez le contenu de la tramebuffer à l'aide de GLREADPIXEXELS et de les frapper avec certaines affirmations sur lesquelles les pixels doivent être des valeurs particulières ou descendre la voie de test de régression et comparer la capture de tramebuffer avec une Image que vous connaissez est bonne (soit de la vérification manuelle, ou parce qu'elle est produite à partir d'un autre modèle de référence).
Autoriser un peu de floue dans tout test de régression d'image; La plupart des implémentations OpenGL produisent une sortie légèrement différente.
(Je n'ai pas fait cela, mais ...) Idéalement, vous souhaitez pouvoir tester la couche d'interface graphique en affirmant qu'il rend la séquence attendue des appels à votre moteur de rendu en réponse à l'activité de l'interface graphique. Si cela le fait, et que vous êtes confiant de votre couche de rendu à cause des tests ci-dessus ... Eh bien, pas besoin de faire le rendu. Donc, créez un objet simulateur approprié de votre couche de rendu pour une utilisation lorsque des tests d'interface graphique (j'imagine que des tests comme «la glisser de la souris» à partir de là, il en résulte un appel à la couche de rendu pour définir une matrice de transformation particulière »... des choses comme ça ).
+1 pour tous les bons conseils. Pour la comparaison de tramebuffer, nous avons écrit une petite application qui fait une différence floue sur les images qui examine les Deltas perceptuelles, plutôt que des valeurs de pixels absolues.
Le problème est que l'interface graphique est un framework conçu sur mesure utilisant JOGL. C'est pourquoi le numéro 2 ne peut pas fonctionner. Par exemple, nous utilisons pour créer des éléments graphiques sur l'écran que l'utilisateur peut interagir avec tous l'utilisation de JOGL. J'ai besoin d'un moyen d'automatiser l'interaction de l'utilisateur ....
L'utilisation d'une bibliothèque particulière pour mettre en œuvre l'interface graphique ne devrait pas avoir d'importance. Créez une classe graphiqueContext qui résumait le canevas / cadre OpenGL et une classe d'interface graphique qui résume toutes les fonctionnalités de l'interface graphique dont vous avez besoin. Ensuite, la mise en œuvre de la classe d'interface graphique peut rendre la mise en œuvre du contexte d'affichage, mais votre application n'aura pas besoin de veiller à la manière dont ils travaillent ensemble.
Avez-vous des webstarts / démos de votre application basée sur JOGL? Je serais également intéressé par un cadre de test JOGL.
J'ai envisagé d'utiliser un outil d'image-diff tel que PDIff pour tester le code OpenGL, En prenant des instantanés, sauvez-les sur le disque et en comparant avec la sortie de régression antérieure. De cette façon, des choses vraiment mauvaises (textures manquantes) apparaissent mais des choses humainement appelées (telles que la petite diffusion mentionnée ci-dessus entre la mise en œuvre) passent à travers l'amende.
En outre, pour automatiser l'interaction de l'utilisateur, les classes de l'interface graphique doivent être suffisamment ouvertes pour que vous envoie des événements ou appelez «cliqué sur» sur un bouton, ou vous devez injecter des événements d'exploitation manuellement sur vos applications. . C'est possible, mais beaucoup plus gênant. Peut-être plus facile d'ouvrir la couche d'interface graphique, s'il est open source.
SSIM ("Indice de similarité structurel") - en.wikipedia.org/wiki/tructural_similarity - est un autre comparateur d'image basé sur des considérations perceptuelles.
Vous pouvez tester votre application basée sur JOGL à l'aide de Sikuli qui effectue une automatisation de l'interface utilisateur via la reconnaissance de l'image Techonolgy sur Screen-Shots .
J'utilise actuellement Sikuli vers fonctionnel-tester une application Java qui est principalement basée sur le NASA Worldwind Java SDK ( qui est basé sur jogl). Utilisation de API SIKULI JAVA My Test Suite peut reconnaître les icônes de la toile OpenGL, cliquez sur eux et aussi les traîner. Sikuli peut également reconnaître et extraire du texte de la toile via OCR, mais la performance de cela semble être un peu hit-et-manne (en fonction de la langue, de la police, de la taille et des couleurs d'arrière-plan derrière le texte).
J'ai fait de nombreux tests d'interface utilisateur automatisés à l'aide d'autres outils qui fonctionnent en intriguant de la boîte à outils de fenêtres (p. Ex. Swing, SWT, Windows indigènes) et que SIKULI fonctionne beaucoup plus lentement que ceux qui sont compréhensibles compte tenu de la quantité de Traitement de l'image Il doit faire dans les coulisses. Notez également que Sikuli exige actuellement que votre application s'exécute dans une fenêtre (non en mode plein écran).
Sikuli fonctionne sur Windows et Linux. Je vous recommanderais de l'essayer. Je ne pouvais trouver aucun autre outil capable de faire ce niveau de test fonctionnel d'une application basée sur OpenGL.
Pardon La question noob, mais ce qui rend un test d'application OpenGL différent de tout autre test d'application?
Ce que je voulais vraiment dire, c'est de tester la vue OpenGL elle-même. En cliquant sur, la mise en marche, la rotation du zoom, etc .... Il existe des outils pour vous permettre d'enregistrer votre interaction de l'interface graphique avec une application Swing et de les rejouer. Vous pouvez le faire pour toutes vos interactions principales et la rejouer en tant que test de régression. Je voudrais une solution similaire à OpenGL mais je ne connais pas celui qui existe.