Search Unity

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

, Декабрь 21, 2016

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

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

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

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

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

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

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

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

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


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

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

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

Комментарии закрыты.

  1. 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.

  2. 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 ?

    1. You properly want to set the «-configuration» parameter instead; you can set it to glcore, glcore43, d3d11, d3d9 and so on.

      The «-dx11featurelevel» parameters are listed as featurelevelX_Y, for example featurelevel9_0 and is only for forcing dx11.

  3. 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.

    1. No they are not entirely deterministic, each platform (and some test combinations) has a configurable allowed delta for catching those slight differences.

      1. Just curious, what causes it to not be deterministic? Just a part of how floating point calculations work?

        1. Yes, take for example a simple ting like addition of floating point numbers, that may yield different result depending the order they are added and the compiler may reorder additions depending on what currently are in the registers.

        2. There are also more odd areas such as std::sort will sort identical values different per platform which will affect things such as particle sorting. We now have our own sorting methods that don’t suffer from this.

  4. 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?)

  5. Is this something you could consider open sourcing?

    1. In it current form, no. It has a lot of integration to other systems which are currently also closed source, such as our build statistics Hoarder. But I have considered making the polymer components open source so it would be easy to setup/build something similar.

    2. We do provide some of our test suites here https://unity3d.com/unity/qa/test-suites