2009-10-18 2 views
12

У меня есть приложение Java, которое использует JOGL для обеспечения большей части графического интерфейса.Автоматическое тестирование для приложения OpenGL

Есть ли какой-либо инструмент, который вы знаете, или использовали, которые могут автоматизировать тестирование приложений OpenGL (или более специфически тех, кто использует JOGL)

Просто обновить: Инструмент может работать как на Linux или Windows.

+0

pardon noob question, но что делает тестирование приложений OpenGL отличным от любого другого тестирования приложения? – Bahbar

+1

Что я на самом деле имел в виду, это проверить само представление OpenGL. Нажатие, перетаскивание, поворотное масштабирование и т. Д. Существуют инструменты, позволяющие вам записывать взаимодействие с графическим интерфейсом, используя приложение Swing и воспроизводить их. Вы можете сделать это для всех ваших основных взаимодействий и воспроизвести его как регрессионное тестирование. Мне бы хотелось получить аналогичное решение для OpenGL, но я не знаю того, что существует. – hhafez

ответ

10

Я написал модульные тесты для C++ (Qt на Linux) & OpenGL раньше. Я не знаю, почему он тоже не должен работать на Java.

Вещи, которые работали для меня являются:

  • Аннотация ваш контекст OpenGL поставщик поэтому остальная часть кода не зависит от него. В моем случае основное приложение использовало QGLWidget Qt, но unittests использовали pbuffer-based, который я мог бы создать без инфраструктуры оконной обработки (кроме назначенного X11 DISPLAY). Позже я добавил «offscreen Mesa» (чистая реализация OpenGL для программного обеспечения), поэтому они даже работали на безголовой машине сборки без GPU.

  • Сохраните код OpenGL независимо от вашего графического интерфейса. В моем случае OpenGL «движок рендеринга» ничего не знал о Qt-классах (например, событиях мыши). Определите свой собственный тестируемый API, который не привязан к каким-либо конкретным концепциям GUI, и напишите тесты для него.

  • В unittests читайте содержимое обратно из фреймбуфера с помощью glReadPixels и нажимайте на них с некоторыми утверждениями о том, какие пиксели должны быть конкретными значениями, или сходите по маршруту тестирования регрессии и сравните захват фреймбуфера с сохраненным изображением вы знаете, что это хорошо (либо при ручной проверке, либо потому, что оно производится из какой-либо другой эталонной модели).

  • Позвольте немного нечеткости в любых регрессионных тестах изображений; большинство реализаций OpenGL дают немного отличающийся результат.

  • (Я этого не делал, но ...) В идеале вы хотите протестировать слой GUI, заявив, что он делает ожидаемую последовательность вызовов вашего механизма рендеринга в ответ на активность графического интерфейса. Если это так, и вы уверены в своем уровне рендеринга из-за вышеуказанных тестов ... ну, не нужно делать рендеринг. Поэтому создайте подходящий макет объекта вашего слоя рендеринга для использования при тестировании графического интерфейса (я бы предположил, что такие тесты, как «перетаскивание мышью» сюда, приводит к вызову слоя рендеринга, чтобы установить определенную матрицу преобразования »... такие вещи).

+1

+1 для всех хороших советов. Для сравнения framebuffer мы написали небольшое приложение, которое делает нечеткое различие на изображениях, которые смотрят на перцептивные дельта, а не на абсолютные значения пикселей. –

+0

Проблема заключается в том, что GUI - это построенная пользователем встроенная фреймворк, построенная с использованием JOGL. Вот почему номер 2 не может работать. Например, мы используем для создания графических элементов на экране, которые пользователь может взаимодействовать со всеми, используя JOGL. Мне нужен способ автоматизации взаимодействия с пользователем .... – hhafez

+2

Использование любой конкретной библиотеки для реализации GUI не должно иметь значения. Создайте класс GraphicsContext, который абстрагирует Canvas/frame OpenGL и класс GUI, который абстрагирует все необходимые графические функции. Затем реализация GUI-класса может отображать реализацию контекста отображения, но вам не нужно будет заботиться о том, как они работают вместе. –

2

Я думал об использовании такого инструмента, как PDiff картинки дифф для тестирования OpenGL код, моментальных снимков, сохраняя их на диск и по сравнению с предыдущим выходом регрессии. Таким образом, действительно плохие вещи (недостающие текстуры) появляются, но по-человечески незаметные вещи (например, вышеупомянутые небольшие различия между реализацией) проходят через штраф.

Кроме того, для автоматизации взаимодействия с пользователем классы GUI должны быть достаточно открыты для отправки событий или вызова «нажата» на кнопке, или вы должны вручную вводить события ОС в свои приложения. Это возможно, но гораздо более хлопотно. Может быть проще открыть слой GUI, если это Open Source.

+0

SSIM («Структурный индекс сходства») - http://en.wikipedia.org/wiki/Structural_similarity - это еще один компаратор изображений, основанный на перцептивных соображениях. – timday

3

Вы можете протестировать приложение на основе JOGL, используя Sikuli, который выполняет автоматизацию пользовательского интерфейса с помощью технологии распознавания образов на снимках экрана.

В настоящее время я использую Sikuli для функционального тестирования Java-приложения, которое преимущественно основано на NASA Worldwind Java SDK (основано на JOGL). С помощью Sikuli Java API мой тестовый набор может распознавать значки в холсте OpenGL, нажимать на них, а также перетаскивать их. Sikuli также может распознавать и извлекать текст с холста через OCR, однако производительность этого, кажется, немного хита и промаха (в зависимости от языка, шрифта, размера и цветов фона за текстом).

Я провел много автоматизированного пользовательского тестирования с использованием других инструментов, которые работают, исследуя инструментарий для оконной обработки (например, Swing, SWT, родная Windows) и обнаружили, что Sikuli работает намного медленнее, чем это, однако это понятно, учитывая сумму обработки изображений, которые он должен делать за кулисами. Также обратите внимание, что Sikuli в настоящее время требует, чтобы ваше приложение запускалось в окне (не в полноэкранном режиме).

Sikuli работает как на Windows, так и на Linux. Я бы порекомендовал вам попробовать. Я не мог найти другого инструмента, способного выполнять этот уровень функционального тестирования приложения на основе OpenGL.

Смежные вопросы