Search Unity

Графические тесты: последний рубеж автоматизированного тестирования

, 21 декабря, 2016

Unity поддерживает десятки платформ, поэтому нам, разработчикам Unity, бывает сложно сохранять единство визуализации контента. Давайте посмотрим, какими средствами можно обеспечить такое единство.

Мы предусмотрели множество автоматических тестов. В Unity есть встроенные юнит-тесты, интеграционные тесты, системные тесты, которые работают и в редакторе, и в игровом режиме. И, наконец, у нас появились тесты графики. Такие тесты позволяют визуализировать сцену с использованием или без использования конкретных графических возможностей, сделать сборку этой сцены, запустить ее на всех поддерживаемых устройствах, а также сохранить кадр в виде изображения.

Итоговое изображение затем сравнивается с утвержденным эталоном сцены, в котором учтены конкретные настройки графики и особенности платформы. Если же итоговое изображение отличается от эталонных, то мы помечаем тест как проваленный, после чего сотрудник вручную проверяет, что стало причиной неудачи (намеренное или же непреднамеренное изменение), и что необходимо исправить.

Поскольку отличия тестового изображения от эталонного не всегда хорошо заметны (пример приведен ниже), для каждого проваленного теста мы готовим изображение, на котором показаны эти отличия.

Рисунок 1. Слева направо: эталон, тестовое изображение и визуализация отличий.

Работа с графическими тестами, по сравнению с обычными, осложняется их непостоянством. Визуализация на разных платформах, моделях устройств и видеокартах дает разные результаты, поэтому для получения однородных результатов в графических тестах мы проводим их на тестовой ферме, что обеспечивает постоянство аппаратной базы. Это усложняет процесс обновления и добавления новых тестов, поскольку разработчику необходимо:

  1. Изменить код, обновить удаленный репозиторий.
  2. Запустить графические тесты на всех соответствующих устройствах.
  3. Подождать завершения тестов и получения неудачных результатов.
  4. Загрузить эталонные изображения для проваленных тестов каждой сборки.
  5. Сравнить каждое эталонное изображение с результатом, чтобы убедиться, что все получившиеся изменения были ожидаемыми.
  6. В случае необходимости скопировать все новые изображения в репозиторий графических тестов.
  7. Внести правки и обновить удаленный репозиторий графических тестов.
  8. Заново запустить графические тесты.

Этот процесс может быть очень затратным по времени, поэтому в помощь разработчикам мы создали небольшое приложение Polymer на основе ASP.NET Core, которое получает информацию от Hoarder, системы статистики по сборкам, и находит все данные по графическим тестам для конкретных правок. Затем приложение загружает артефакты графических тестов по каждой сборке и выводит результаты на одной странице.

Разработчик видит проваленные тесты и может сравнить результаты с эталонными образами, а также визуализацией отличий. Тем не менее не всем и не всегда удается сразу заметить разницу между изображениями, как в примере ниже:


Именно поэтому приложение дает возможность разработчику переключаться между тестовым и эталонным изображениями, а также при необходимости просматривать разностное, чтобы быстро понять, в чем заключаются отличия. Это очень помогает, поскольку разницу между изображениями часто можно увидеть только при переключении между ними.

Затем разработчик может выбрать тесты, которые нужно обновить, после чего автоматически загрузить и обновить выбранные изображения в локальном репозитории графических тестов с помощью командной строки или же вручную загрузить архив изображений с сохранением структуры каталогов и самостоятельно скопировать содержимое в локальный репозиторий графических тестов.

Учитывая, что в данной системе хранится информация о 13 700 графических тестах для 33 конфигураций сборок, и репозиторий графики обновляется ежедневно, этот инструмент упрощает жизнь разработчика и снижает объем ручной работы при проведении графических тестов.

13 replies on “Графические тесты: последний рубеж автоматизированного тестирования”

Have you considered hooking in to something like Applitools? https://applitools.com/

They do some nice machine learning to allow for minute changes due to minor rendering differences and have interfaces for marking ignore regions, detecting layout changes etc.

by default Unity.GraphicsTestRunner.exe runs in DX9 mode,how to run dx11featurelevel ? what is value need to set for «—dx11featurelevel — Set to force feature level for DX11 »
similarly how or run OGL mode ?

Is everything in the rendering completely deterministic ? I thought that there is always slight differences between every rendering, and so the tests would always fail.
See that makes me wonder if Physic engine companies also run this sort of test for their physic simulations.

This would be extremely useful for asset store developers as we don’t necessarily have the time or all platforms test on. I hope some version of this will be made available to us soon (maybe as a Unity service?)

Comments are closed.