Mam aplikację Java, która używa JOGL, aby zapewnić dużą część GUI.Automatyczne testowanie aplikacji OpenGL
Czy istnieje narzędzie, które znasz, czy zostały wykorzystane, które mogą zautomatyzować testowania aplikacji OpenGL (lub więcej specificly korzystających Jogl)
Wystarczy zaktualizować: Narzędzie można uruchomić na każdym Linux lub Windows.
Napisałem testy jednostkowe dla C++ (Qt na Linux) & OpenGL przed. Nie znam żadnego powodu, dla którego nie powinien on działać również w Javie.
Rzeczy, które pracowały dla mnie są:
Streszczenie dostawca kontekstu OpenGL więc reszta kodu jest niezależne od niego. W moim przypadku główna aplikacja korzystała z QGL-owego QGLWidget, ale unittests używało opartego na pufie, który mogłem stworzyć bez infrastruktury okienkowej (poza wyznaczonym DISPLAY X11). Później dodałem "poza ekranem Mesa" (czysto programowa implementacja OpenGL), aby mogli pracować nawet na bezgłowej maszynie do budowania bez GPU.
Zachowaj swój kod OpenGL niezależnie od kodu GUI. W moim przypadku "silnik renderujący" OpenGL nie wiedział nic o klasach Qt (np. Zdarzenia myszy). Zdefiniuj własny testowalny interfejs API, który nie jest powiązany z żadnymi konkretnymi koncepcjami GUI i napisz dla niego testy.
W unittests, odczytać zawartość z powrotem z bufora ramki za pomocą glReadPixels i albo uderzyć z pewnych twierdzeń o których piksele powinny być konkretne wartości, albo zejść trasę regresji testowania i porównywania przechwytywanie bufora ramki z zapisanego obrazu wiesz, że jest dobra (albo z ręcznej weryfikacji, albo z tego, że jest produkowana z jakiegoś innego modelu odniesienia).
Zezwalaj na odrobinę rozmytości podczas testowania regresji obrazu; większość implementacji OpenGL daje nieco inne wyniki.
(Nie zrobiłem tego, ale ...) Idealnie chciałbyś móc przetestować warstwę GUI, potwierdzając, że wywołuje oczekiwaną sekwencję wywołań do silnika renderującego w odpowiedzi na aktywność GUI. Jeśli tak, i jesteś pewny swojej warstwy renderowania z powodu powyższych testów ... cóż, nie musisz wykonywać renderowania. Stwórz więc odpowiedni próbny obiekt twojej warstwy renderowania do użycia podczas testowania GUI (wyobrażam sobie testy takie jak "przeciągnięcie myszą stąd powoduje wywołanie warstwy renderującej w celu ustawienia konkretnej macierzy transformacji" ... takie rzeczy).
+1 za dobrą radę. W przypadku porównania bufora ramki napisaliśmy niewielką aplikację, która robi nieostrą różnicę w obrazach, która patrzy na delta percepcyjne, a nie na bezwzględne wartości pikseli. –
Problem polega na tym, że GUI to niestandardowe zbudowane środowisko zbudowane przy użyciu JOGL. To dlatego numer 2 nie działa. Na przykład używamy do tworzenia elementów graficznych na ekranie, które użytkownik może współdziałać ze wszystkimi za pomocą JOGL. Potrzebuję sposobu, aby zautomatyzować interakcję użytkownika ... – hhafez
Używanie dowolnej biblioteki do implementacji GUI nie powinno mieć znaczenia. Utwórz klasę GraphicsContext, która abstrakcyjna płótno/ramkę OpenGL, i klasę GUI, która generuje dowolne funkcje GUI, których potrzebujesz. Następnie implementacja klasy GUI może być renderowana do implementacji kontekstu wyświetlania, ale aplikacja nie musi dbać o to, jak pracują razem. –
Myślałam korzystania z funkcji obraz-diff takich jak PDiff przetestować kod OpenGL, przez robienia zdjęć, zapisując je na dysku i porównując z poprzednim wyjściu regresji. W ten sposób pojawiają się naprawdę złe rzeczy (brakujące tekstury), ale ludzkie rzeczy, których nie można nie zauważyć (takie jak wspomniane wyżej małe różnice między implementacjami), przechodzą dobrze.
Ponadto, aby zautomatyzować interakcję użytkownika, klasy GUI powinny być wystarczająco otwarte, aby można było wysyłać zdarzenia lub wywoływać "kliknięto" na przycisku, lub trzeba ręcznie wstrzykiwać zdarzenia systemu operacyjnego do aplikacji. Jest to możliwe, ale znacznie bardziej kłopotliwe. Może być łatwiej otworzyć warstwę GUI, jeśli jest to Open Source.
SSIM ("Structural Podobieństwo index") - http://en.wikipedia.org/wiki/Structural_similarity - to kolejny komparator obrazu oparty na rozważaniach percepcyjnych. – timday
Możesz przetestować aplikację opartą na JOGL przy użyciu Sikuli, która wykonuje automatyzację interfejsu użytkownika za pośrednictwem technologii rozpoznawania obrazu na zrzutach ekranu.
Obecnie używam Sikuli do testowania funkcjonalnego aplikacji Java opartej głównie na modelu NASA Worldwind Java SDK (opartym na JOGL). Za pomocą mojego zestawu testów można rozpoznawać ikony w obszarze roboczym OpenGL, klikać je i przeciągać. Sikuli potrafi rozpoznać i wyodrębnić tekst z płótna za pomocą OCR, jednak wydajność tego wydaje się być mało trafiona (w zależności od języka, czcionki, rozmiaru i kolorów tła za tekstem).
Zrobiłem wiele zautomatyzowanych testów interfejsu użytkownika przy użyciu innych narzędzi, które działają poprzez introspekcję zestawu narzędzi do okien (np. Swing, SWT, rodzimy system Windows) i odkryłem, że Sikuli działa znacznie wolniej niż te, jednak jest to zrozumiałe, biorąc pod uwagę kwotę przetwarzania obrazu musi to robić za kulisami. Zauważ też, że Sikuli wymaga obecnie, aby Twoja aplikacja działała w Oknie (nie w trybie pełnoekranowym).
Sikuli działa zarówno w systemie Windows, jak i Linux. Polecam wypróbować to. Nie mogłem znaleźć żadnego innego narzędzia zdolnego do takiego poziomu funkcjonalnego testowania aplikacji opartej na OpenGL.
Ułóż pytanie o noob, ale co różni testowanie aplikacji OpenGL od innych testów aplikacji? – Bahbar
Chciałem przetestować sam widok OpenGL. Kliknięcie, drążenie, obracanie powiększania itp. .... Istnieją narzędzia umożliwiające nagrywanie interakcji z GUI za pomocą aplikacji Swing i powtórzenie ich. Możesz to zrobić dla wszystkich swoich podstawowych interakcji i powtórzyć to jako test regresyjny. Chciałbym podobne rozwiązanie dla OpenGL, ale nie wiem, który istnieje. – hhafez