Home

Автор: Ноэми Феррера (NoemiFerrera)
Оригинал статьи
Перевод: Ольга Алифанова

В своем докладе на Heisenbug я демонстрировала два примера автоматизации в виртуальной реальности - Unium и Poco (Airtest). Мои объяснения были довольно поверхностными, поэтому я решила расширить их в этой статье.

1) Подготовка приложения к тесту

В примерах ниже я буду использовать VR-приложение, созданное мной в ходе курса UdacitytheVRfoundations. Оно было сделано с использованием GoogleVRCardboard(сейчас оно не особо поддерживается, но с моей точки зрения, это лучший стартовый шаг в VR-разработку).

Кодможнонайтиздесь. Онбылсозданна Unity версии 2017.1.0p4 и Google Cardboard версии gvr-unity-sdk-1.0.3. Я указываю это, так как иногда Unity плохо реагирует на переключение версий, а в GoogleVRвсе быстро устаревает, поэтому при других версиях все может не сразу заработать.

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

Проводя юнит-тесты приложения при тестовом прогоне, можно кое-что проверить. Например, то, что переменная двери "замок" или включена, или выключена. Однако мы видим результаты не так, как пользователь, и тут могут скрываться проблемы – например, эта переменная никак не влияет на сюжет, или же раздаются неприятные звуки, или пользователь не может попасть к объектам, или они не того размера.

Чтобы это протестировать, надо действительно прогуляться по лабиринту, собрать все монеты, получить ключ, вернуться к двери, и протестировать таким образом. Путь всегда одинаков, и ручное тестирование может занять много времени. Вот она, причина поискать решение по автоматизации пользовательского поведения, и сейчас мы рассмотрим это с Unium.

2) Установка и настройка Unium

Несмотря на то, что Github-проект в свободном доступе, рекомендую сделать это из AssetStoreв Unity.

Для открытия магазина кликните Window -> AssetStore.

Затем найдите Unium и скачайте.

После этого в проектной папке Assetsпоявится новая папка. Затем мы добавим новый пустой объект в Scene, а потом – скрипт папки из Assets. Этот скрипт открывает локальный веб-сервер (порт по умолчанию – 8342, его можно поменять), который мы будем использовать для взаимодействия с приложением, получения от него данных и отправки данных в него. Если вам интересно, как это работает, прочитайте мою статью про API. Теперь сервер и наша Unity-программа могут общаться.

3) Использование Unium

Теперь мы можем совершать вызовы напрямую в браузере, как будто стучимся на веб-сайт, например:

http://localhost:8342/q/scene/Main Camera/transform/position={'x':1,'y':1,'z':0}

Это перемещает камеру в координаты 1,1,0. Поворот камеры:

http://localhost:8342/q/scene/MainCamera.Transform.eulerAngles={'x':180,'y':0,'z':0}

Это повернет камеру на 180 градусов по оси Х, 0 градусов по оси Y и 0 градусов по оси Z.

Движение камеры очень важно для VR-приложений, и уже сейчас можно увидеть три проблемы в этих функциях. Первая из них в том, что в VR-приложениях мы обычно перемещаемся, кликая по объектам-"ориентирам", или при помощи функций шлема. В Unium можно использовать ориентиры и кликать по ним вот так:

http://localhost:8342/q/scene/Waypoints/Waypoint_7.Waypoint.Click()

Заметьте, что все ориентиры у меня находятся в другом объекте – Waypoints, точный ориентир называется Waypoint_7, а код, вызывающий метод клика, называется Waypoint. Метод, кликающий по двери, проще, потому что дверь всего одна, и мы не используем имена несколько раз:

http://localhost:8342/q/scene/DoorObject/Door.OnDoorClick()

Если вы не уверены в точном имени объекта, можно использовать знаки подстановки и запросы.

Вторая проблема – это использование EulerAngles. Я смогла увидеть вращение при помощи кватернионов (используя "rotation" вместо "eulerAngles" в конце вызова), но почему-то не смогла это настроить (возможно, сейчас это поддерживается, или же в ходе тестирования я делала что-то не так).

Последняя проблема – это ротация камеры: пользователи движутся, вращая камеру к точке или в определенном направлении, но вращение через вызов делается однократно. Это плохо имитирует пользовательское поведение, но при помощи Unium можно настроить скрипт и имитировать такой сценарий, или же использовать возможности веб-сокета, прогоняя запрос с определенной частотой.

Unium поддерживает несколько языков для автоматизации вызовов, к примеру, nUnit (который мы используем для юнит-тестов в C#). Вот пример кода:

4) Заключение

Unium– мощный инструмент автоматизации Unity-проектов. Он позволяет автоматизировать виртуальную реальность и даже имитировать пользовательское поведение. Однако этот вид автоматизации – неполноценный черный ящик, так как код надо добавлять в приложение (и, возможно, использовать существующие в приложении методы). В идеале полностью черноящичная автоматизация будет симулировать поведение контроллеров напрямую.

В чем разница между автоматизацией игры и автоматизацией VR-игры? Основное различие в том, что вместо движения игрока нужно автоматизировать движение камеры и учитывать гарнитуру (если она есть).

Иногда трансформация (переходы) осуществляется через клики по ориентирам, и это легко автоматизируется в Unium. Вращение можно эмулировать, вращая камеру, как показано выше.

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

Обсудить статью в форуме