Существуют ли особые методики тестирования 3D-приложений?
Всем, привет!
Занимаюсь проблематикой TDD и вообще тестированием лишь недавно. Пока изучаю теоретические аспекты. Вот возникли такие, на мой взгляд, нетривиальные, вопросы. Коллеги, поделитесь опытом!
Вопрос 1.
Допустим мы делаем редактор 3D-мешей для модели. У нас есть в редакторе покрытая тестами функция объединения мешей. Но вот досада: при некоторых сочетаниях геометрий и взаимного расположения моделей слияние формирует вовсе не ту фигуру, которую ожидает увидеть пользователь. Например, при слиянии двух сфер, в некоторых случаях, получается нечто, очень напоминающее комету Чурюмова-Герасименко. В добавок, появляются полигоны, неправильно ориентированные к наблюдателю. Существует ли способ программно выявить такие лаги. Есть способ на "это" написать тест?
Вопрос 2.
Представим, что мы проектируем 3D-игру или демку. Мы пока только можем отображать ландшафт, небо с облаками, строения, траву, деревья, некоторые другие статичные объекты. Наконец, мы решили привнести в нашу модель мира понятие "ветра". Пока просто: он либо есть, либо его нет. На ветер будут реагировать только трава и деревья: они будут просто покачиваться, имитируя сам факт ветра. Плюс в мире появляется фоновый звук ветра. Первый этап пройден.
Затем мы решили параметризировать ветер, добавив ему силу и направление. Теперь трава и деревья нагибаются в сторону от ветра, а амплутида их колебаний зависит от силы ветра. (Можно сказать, что логическое поле "есть или нет" для ветра, превратилось в вещественное "сила" ветра. А старая функция isWindOn возвращает результат теперь проверкой: wind.force > 0). Но представим, что после этого, у нас стало лагать фоновое сопровождение звука. Оно когда появляется, а когда нет. Каким методом протестировать вообще сам факт этого, чтобы впредь не допустить?
Ну или другая вероятная проблема со звуком: при очень маленьких значениях силы ветра колыхание травы и деревьев не происходит, а вот звук еще идет. Получается, что шум от ветра есть, а действия нету. Понятно, что решение здесь - как минимум, поставить зависимость громкости фонового звука от силы ветра. Но каким образом (чисто гипотетически) написать тест на несоответствие громкости звука амплитуде колебаний деревьев и травы? Мало ли: а вдруг рефакторинг, или дальнейшие "нововведения"?
Или представим, что некоторые деревья в процессе деформации ствола (под действием ветра) при некоторых сочетяниях значения силы ветра и своего расположения на местности, скажем, переворачиваются к верху ногами. Причем заметно это становится, только при определенном ракурсе камеры наблюдателя. Каким тестом отслеживать подобное? Ведь формально, модульные и функциональные тесты проходят. Они не могут выявить нарушение геометрии. Человеко-тестеры тоже не всегда могут выявить такое безобразие. А ну как в продакшн?
Ну или еще подобное. Скажем, выявилось проникнование части персонажей за преграду (например, рука сквозь стену). В общем факты этого отслеживается специальной логикой. Есть даже тесты, проверяющие работу модуля, контролирующего пересечение двух объектов в пространстве. Но каким образом гарантировать, что тест в принципе верный? Что если сам тест написан неверно, и его писатель, допустил ошибку при оценке множества выходных значений (заузил возможный диапазон)?
TDD работает если к задаче можно написать тест и с написание теста может справиться хотя бы джуниор-мидл. Как вы напишете тест к октодереву, освещению или шейдеру? Никак же. FPS, артефакты, корректное отображение входных данных и прочее. Можете держать 100500 мелких тестовых проектов для отладки. Пишите генератор ресурсов на питоне и скармливайте программе. Может в Юбисофтах и прочих ЕА всё более гибко за счет овер-експириенсных кадров.
Раньше тестирование UI-интерфейса тоже считалось невозможным. Пока не появились такие продукты, как Selenium.
Еще Яндекс, кажется, развивает методику тестирования соответствия визуального оформления веб-страниц на разных устройствах. Пока сравнение ведется сравнением картинок. Качество шейдеров, теоретически, можно было бы тестировать по подобной методике...
С FPS вопросов нет. Его-то можно измерить. А значит реально написать тест, контролирующий приемлемое быстродействие для приложения, после проведенного рефакторинга или апгрейда.
Может быть у читателей, занятых в подобных сферах разработки, есть еще какие-то мысли.
KaminskyIlya: При чем тут UI? Вы говорите общие фразы, вырванные из контекста без конкретных примеров и привязки к предметной области. Логвинова пересмотрели? В батлфилд переиграли? Большинство вещей в 3D тестируется визуально, тактильно на демках. Херова-нехерова, пойдет/непойдет, переделать/непеределать и т.д.
mamkaololosha: Да в целом-то понятно. У нас, например, в разработке КАД/КАМ систем похожие проблемы возникают. Если внутренний функционал более-менее покрыт тестами, UI- лишь от части, то отрисовка вьюпорта не покрыта вообще никак. Из-за этого постоянно вылезают баги-регрессии, которых раньше не было, а написать на баг тест, чтобы никто больше ничего не поломал мы не можем.
Вот так и живём.
Кстати, когда работал в гейм-деве, тестов вообще не было, но команда и кодовая база были существенно меньше, так что каждый идеально знал свою часть и не лез в чужую.
1 случай - ну вообще то триада Хоара в чистом виде, у вас по входу набор вершин и по выходу тоже. Можно строить автоматизированные тесты по образцу.
2 ручное тестирование. Ну и опять же, амплитуда - это численная характеристика, наносите на террайн изомапу амплитуд звука, сравнивайте с эталонными.
3. Гарантировать корректность теста можно только если тест алгоритмически тривиален, очевидно. К счастью все тесты (почти все, скажем) - именно таковы.
Про тестирование шейдеров - я обычно вывожу в MRT какие то виузализации промежуточных вычислений, почти всегда можно придумать что-то такое. Читать нормализованные вектора в rgb все уже привыкли, если что :)
Простой
Простой
Сложный
