Инструменты функционального тестирования — Monkey и MonkeyRunner
Monkey
Начнём с самого простого инструмента — с Monkey. Monkey является не столько инструментом функционального тестирования, сколько т.н. стресс-тестирования, либо, как говорится на официальной странице документации проекта — UI/Application Exerciser. Грубо говоря, Monkey эмулирует попадание телефона с запущенным приложением в лапки к обезьянке (ну или в руки к маленькому ребенку), с последующими хаотичными действиями «пользователя». Впрочем, Monkey позволяет достаточно гибко настроить «хаотичность», интервал между событиями, их тип и т.п. Для подобного тестирования исходный код приложения не требуется — оно просто должно быть установлено на устройство либо эмулятор, а запуск в простейшем случае осуществляется следующим образом из консоли:
Указывается имя пакета вашего приложения и количество генерируемых событий. В случае возникновения исключения (Exception), соответствующий stack trace будет выведен в консоль:
Вот и все о Monkey — тестируйте свое приложение, и возможно, это сделает его более надежным — кто знает.
MonkeyRunner
Несмотря на схожее с Monkey название, MonkeyRunner совершенно другой инструмент, который позволяет выполнять функциональное тестирование приложения («прокликивающие» тесты), предоставляя API для управления устройством. MonkeyRunner является более низкоуровневым по сравнению с Robotium, и не требует исходного кода приложения в сравнении с Robolectric. Но только лишь тестированием область применения MonkeyRunner не ограничивается — с его помощью можно строить системы, контролирующие android-устройства через UI (и не только). MonkeyRunner использует Jython и скрипты или сценарии тестов могут быть написаны на Python, или записать действия пользователя с помощью рекордера.
Запись и проигрывание сценария
Из состава SDK нам понадобятся два python-скрипта: для рекордера и плеера. Запускать их нужно соответственно с помощью monkeyrunner :
Рекордер выглядит примерно так: 
С помощью кнопки «Export actions» сценарий может быть записан в файл, после чего его можно будет воспроизвести плеером:
Конечно же, эмулятор должен быть запущен при всех вышеперечисленных действиях.
Как видно из скриншота, MonkeyRunner оперирует координатами для выбора элемента управления, что конечно же не столь удобно, как выбор элемента в Robotium или Robolectric и будет зависеть от размеров экрана, но может быть, что такое поведение будет востребовано для создания сценариев тестирования приложений, не обладающих привычными элементами интерфейса — например, игр.
Написание сценария
MonkeyRunner позволяет описывать собственные сценарии с использованием Python. В дополнение к управлению интерфейсом возможны удаление и установка приложения, сохранение скриншотов и прочее. Пример такого скрипта:
Более подробно о возможностях, предоставляемых API можно узнать в официальной документации к MonkeyRunner.
Интеграция с Eclipse
Можно конечно создать для сценариев отдельный Python-проект.
Вот собственно и все, о чем хотелось вкратце рассказать. Возможно, описанные инструменты тестирования будут вам полезны.
Разница между тестированием на обезьянах и специальным тестированием
Ключевая разница: Adhoc Тестирование выполняется без какого-либо планирования или подготовки. После того, как программа заработает, программист или тестер будут тестировать программное обеспечение, ис
Содержание:
Adhoc Тестирование выполняется без какого-либо планирования или подготовки. После того, как программа заработает, программист или тестер будут тестировать программное обеспечение, используя свои знания о программе. Он, как правило, проверяет основы системы, чтобы убедиться, что они работают и система не падает. Этот тип тестирования выполняется без использования тестового примера.
Тестирование на обезьянах похоже на Ad hoc Testing. Это также проводится случайным образом, без какого-либо планирования или подготовки. По этой причине многие программисты относят Monkey Testing к типу Adhoc Testing. Однако Monkey Testing отличается от Adhoc Testing одним существенным образом, Monkey Testing можно проводить без каких-либо знаний или информации о программном обеспечении.
Преимущество Monkey Testing и Adhoc Testing заключается в том, что оно тестирует программное обеспечение в реальной и случайной ситуации по сравнению со структурированным тестированием. Подобные ситуации также более реальны и могут произойти, когда продукт появится на публике. Однако недостатком Monkey Testing и Ad-hoc Testing является то, что, когда ошибка действительно возникает, невозможно воспроизвести ошибку, так как нет файлов тестовых примеров, на которые можно было бы сослаться. Вот почему Monkey Testing и Adhoc Testing почти всегда используются в сотрудничестве с традиционными и структурированными методами тестирования.
Сравнение между тестированием на обезьянах и специальным тестированием:
Обезьяна Тестирование
Специальное тестирование
Несколько тестов, чтобы убедиться, что система или приложение не аварийно завершают работу.
Тестер пытается «сломать» систему путем случайного опробования ее функциональных возможностей.
Никакого конкретного теста не проводится; это может включать в себя просто случайный щелчок или ввод текста, чтобы увидеть, не происходит ли сбой системы.
Основано на знаниях тестера. Тестер может проверить, что он считает необходимым.
«Обезьяна на пишущей машинке». Любой, кто не знает программного обеспечения или даже компьютеров.
Программист с детальным знанием программного обеспечения и системы.
Gremlins.js — monkey testing библиотека для веб приложений
Это первая из двух статей, рассказывающая о тестировании с помощью gremlins.js и grunt-gremlins. Первая статья — перевод официальной документации gremlins.js. Вторая — опыт внедрения gremlins.js в реальный проект при помощи grunt-gremlins.
Gremlins.js это monkey testing библиотека написанная на JavaScript, для Node.js и браузеров. С ее помощью проверяется надежность веб-приложений под полчищем гремлинов.
Kate: What are they, Billy?
Billy Peltzer: They’re gremlins, Kate, just like Mr. Futterman said.
Предвидите ли вы все необычные пользовательские сценарии при разработке HTML5 приложений? Можете ли вы обнаружить и устранить возможные утечки памяти? Если нет, ваше приложение рано или поздно может дать сбой. Если случайные действия могут положить ваше приложений, лучше узнать о проблемах на стадии тестирования, вместо того, чтобы позволить пользователю обнаружить их самостоятельно.
Gremlins.js эмулирует случайные действия пользователя: гремлины кликают везде, куда могут добраться, вводят случайные данные в формы, или перемещают мышь над элементами, которые этого не ожидают. Их цель: вызвать JavaScript ошибку или заставить приложение выйти из строя. Если им это не удалось, поздравляю! Приложение достаточно пуленепробиваемо для того, чтобы показать его реальным пользователям.
Эта практика так же известна как Monkey testing или Fuzz testing, она широко распространенна в мире мобильной разработки (посмотрите на Android Monkey program). Сегодня, когда интерфейс (MV*, d3.js, Backbone.js, Angular.js, etc.) и бекенд (Node.js) разрабатывается полностью на JavaScript, эта технология становится применима и для веб приложений.
Базовое использование
Полчище гремлинов ( horde ) — это армия из специализированных гремлинов, готовых встряхнуть ваше приложение. Выпустите ( unleash ) их для начала стресс тестов:
Gremlins.js предоставляет несколько типов гремлинов: некоторые кликают во всевозможных местах, другие заполняют формы данными, кто то скролит окно браузера, и т.д.
Вы можете наблюдать за их поведением в окне браузера (они оставляют за собой следы) или отслеживать логи в консоли:
Кроме того, существуют безвредные могваи ( mogwais ). Могваи только наблюдают за активностью приложения и записывают дынне в лог. Для примера, «fps» могвай каждые 500ms показывает количеcтво кадров в секнду (FPS).
Иногда могваи сообщают, когда гремлинам все же удалось навредить приложению. К примеру, если fps опустится ниже отметки в 10, fps могвай выведет ошибку в лог:
После 10 ошибок специальный могвай Gizmo остановит тестирование и всех выпущенных гремлинов. В конце концов, после первых 10 ошибок, вы уже знаете, что вам нужно сделать, чтобы сделать ваше приложение более устойчивым.
Гремлины, как и могваи — это простые JavaScript функции. Если gremlins.js не предоставляет необходимых вам гремлинов, вы довольно просто можете реализовать их самостоятельно:
Загляните в папку с примерами, чтобы лучше понять как работает gremlins.js.
Вы можете сконфигурировать любой компонент в gremlins.js; расширяйте функциональность и адаптируйте ее для своих сценариев.
Установка
В браузере, файл gremlins.min.js может быть добавлен как сторонняя библиотека, после чего gremlins будет доступен в глобальном пространстве имен:
Есть возможность подключить gremlins.min.js как RequireJS модуль, не засоряя глобальное пространство имен:
Продвинутое использование
Настройка гремлинов и могваев для использования в тестах
Изначально все гремлины и могваи уже добавлены в полк ( horde ).
Вы так же можете выбирать и добавлять только необходимых вам гремлинов с помощью метода gremlin() у объекта horde :
Для того, чтобы добавить ваших собственных гремлинов к стандартным, воспользуйтесь методом allGremlins() :
Чтобы добавить могваев, используйте методы mogwai() и allMogwais() таким же образом.
На данный момент gremlins.js поставляет несколько гремлинов и могваев:
Конфигурация гремлинов
Все гремлины и могваи поставляемые в gremlins.js являются настраиваемыми функциями ( configurable functions ), то есть вы можете изменить логику работы их методов.
Для примера, гремлин clicker — это функция, возвращающая объект, который вы можете вызвать напрямую:
Гремлин clicker имеет следующие методы для кастомизации:
Каждый гремлин или могвай имеет собственные методы для настройки, советую изучить исходный код каждого из них.
Больше информации о конфигурируемых функциях ищите в статье о service closures.
Поддержка Random Seed
Если вы хотите, чтобы ваши атаки можно было повторить, вам необходимо инициализировать генератор случайных чисел. Gremlins.js использует Chance.js для генерации случайных данных, таким образом его можно инициализировать:
Выполнение кода до или после атак
Вы можете исполнять произвольный код до начала тестирования. Обычно бывает полезно:
Для очистки тестового окружения, объект horde так же предоставляет метод after() :
Оба метода поддерживают асинхронный вызов callback’a:
Стратегия
По умолчанию гремлины будут атаковать ваше приложение в произвольном порядке разделенные промежутком в 10ms. Эта стратегия атаки называется distribution. Изменить ее можно используя метод horde.strategy() :
Существует возможность использовать и другие стратегии. Стратегия — это просто callback ожидающий три параметра: массив гремлинов, объект (возвращенный в результате unleash() ) и финальный callback. В комплекте идут еще две встроенных стратегии (allTogether и bySpecies) и реализовать собственную стратегию для более специфичных сценариев атак должно быть предельно просто.
Остановка тестирования
Модификация логирования
По умолчанию, gremlins.js выводит в консоль все действия гремлинов и наблюдения могваев. Если для вас предпочтительней использовать альтернативный метод журналирования (к примеру, хранить активность гремлинов в localStorage и отправка их каждые 10 секунду c помощью AJAX), просто передайте объект logger с четырьмя методами (log, info, warn, и error) в метод logger() :
Вместо создания собственного логгера, посмотрите в сторону Minilog
вторник, 3 ноября 2020 г.
Что такое monkey testing
Самый известный тип тестирования, ведь все начинают с него )))
Просто берем. И тестируем! Без цели, без плана. Просто тыкаемся везде с намерением что-то сломать. Как обезьянка.
Между прочим, метод работает! Мы можем влететь на такую ошибку, которую сами бы никогда не нашли. Просто не догадались бы, что это другой класс эквивалетности. Всякое бывает.
А еще бывает такое, что приложение тупо падает от манки-тестирования. То есть после хаотичного тыкания во все подряд (особенно актуально для мобильных приложений). Или памяти не хватает, или вы случайно задействуете комбинацию, которая все разваливает, или еще что.
Есть даже автоматизация манки-тестинга! Да-да, создается робот, который просто тыкает во все подряд. Генерирует кучу случайных значений и пихает во все доступные поля. И снова ходит и тыкает, тыкает, тыкает.
Вот почему я вспомнила про мобильные — именно для них и пишутся такие роботы. Можно и для простого ПО написать, но в мобилках это популярнее и профита больше. Написал робота, ушел домой. А он всю ночь тыкает, тыкает. Пришел утром — все зависло / упало. Дальше локализуем.
Вот тут и возникает проблема — как понять причину ошибки, если ты бессистемно тыкал во все подряд?
Когда я работала на первой работе и тестировала игры на мобильных, у меня было несколько таких случаев. Когда баг воспроизводился «по наитию». Тогда то я еще не знала о существовании классов эквивалентности и всякого такого. Очень тяжело было воспроизводить!
Сделали игрушку — бильярд. Сижу, тестирую. Дело было поздним вечером, я проверяла уже N-ный телефон. Проверив основные идеи, просто стала тыкать туда-сюда, отключив мозг и думая о чем-то своем.
И тут я бью по мячу, а он ударяется об один борт, потом о другой, третий. И не останавливается! Обычно же бьешь сильно, но инерция проходит и он катится все медленнее и медленнее. А тут нет! Что-то где-то не сработало и мячик не снижал скорости. И в лунку так и не влетел, катался по квадрату между стенками. 5 минут, 10.
Сначала я завороженно смотрела на это. Потом мимо прохошел генеральный директор — зашел к нам в настольный теннис поиграть. Показала ему, похвастаться, что нашла. Похвалил, ушел играть)))
А я остановила игру и стала пытаться воспроизвести ошибку. Вся раслабленность и «мысли о своем» испарились, теперь я была сосредоточена на игре. Но. Воспроизвести почти случайную последовательность силы и направления удара?
Мне так и не удалось. Если бы были средства записи экрана, возможно, разработчик даже смог бы исправить баг. Правда, как такое проверять, я не представляю. Только на уровне кода или автотеста!
Тем не менее тот найденный манки-тестингом баг до сих пор помню. 10 лет прошло, но засело в голове, ведь так и не смогла локализовать ошибку.
Игрушка, в которой ты рисуешь линии, а потом по ним катится человечек на санках. Задача — чтобы он катился как можно дольше.
Там тоже однажды нашла баг чисто случайно. Мозги отключились и я просто тыкала игрушку. Тык-тык-тык, о, баг! Сразу оживилась, круто же, там картинки накладываются друг на друга. Сейчааааас как покажу разработчику!
Пытаюсь воспроизвести — не получается! Оооо, как я мучилась тогда с этим багом, весь вечер корячила. И все пыталась вспомнить, что же я делала, ну что?! Вот бы мне тогда видео-запись моих действий.
Баг, кстати, воспроизвела. И если бы знала про классы эквивалентности, тестовые туры и прочее, могла бы и раньше воспроизвести. Насколько я помню, там надо было выйти в меню и отменить какое-то действие, и вот тогдаааа!
Если вы оставляете манки-робота на ночь, обязательно включите запись видео действий. Иначе единственная надежда будет на то, что разработчик по стеку ошибки поймет, где косяк в коде. А если не поймет — воспроизводите как хотите.
Перезапуск робота тут не поможет, ведь вся его фишка — в рандомности. Запустили один раз, он тыкался в одни места, вводил одни значения. Запустили второй — он не повторит тот же маршрут. А, значит, если он случайно попал на комбинацию, приводящую к багу — ее надо или самим искать, или надеяться, что робот сможет ее повторить за ночь.
Поиграть в игру = протестировать игру. Почему это утверждение неверно?
Определение термина и с чего начиналось тестирование игр
Разновидности «игрового» тестирования
Для тестирования видеоигр, как и в других направлениях, есть “стандартные” и свои особенные подходы для решения определённых задач. Давайте рассмотрим их!
Плейтестинг как важная часть обратной связи с вашей аудиторией
Говоря о специфических для видеоигр видов тестирования, я бы выделил такую группу как Game Design Testing, куда включу Balance testing, Level Design testing, «Fun Factor» testing).
Иногда «тестирование баланса» в вашей игре стоит воспринимать буквально =)
Level Design Testing подразумевает проверку уровней (левелов). Даже самый красивый визуально уровень может содержать непроходимые места из-за, к примеру, невидимых стен (есть модель (меш), но нет текстур), дырок в полу (к примеру из-за плохой стыковки плоскостей или моделей), попадания в так называемые Stuck points, где встрял и уже никуда дальше сдвинуться персонаж не может.
Пример Левел Дизайна на ранних стадиях
Такой достаточно абстрактный вид тестирования как Fun Factor Testing кто-то выделяет отдельно, а кто-то считает, что это часть Playtesting. Здесь упор делается на «фановость» процесса игры. Идеально сбалансированная игра может банально не весело играться и это отпугнёт аудиторию. Также тут стоит проверить такие игровые механики как навигация, прицеливание, взаимодействие с предметами, NPC и т.д. Неудачные механики, непривлекательный арт, также находится на этой стадии. Если вас в процессе ничего не фрустрирует, вы на верном пути =) Больше про плейтесты, включая Fun Factor, можно посмотреть тут, хоть я и не во всем согласен с автором.
Чуть выше кто-то где-то упомянул персонажей/уровни/предметы и т.п.? Т.е. мы начинаем говорить о Visual Components Testing группе, куда можно внести тестирование 3D моделей/сцен, 2D (спрайты) и 2.5D.
3D Models Testing включает в себя проверку корректности модели (хай и лоу поли) на визуальную составляющую и кол-во полигонов, выставленное в требованиях. Также проверяются все ли текстурные карты доступны и используются для моделей, есть ли отображение внутренней стороны моделей (если они видны), не ломается ли модель во время анимации (риггинг и правильный скиннинг). Во время таких проверок всегда можно заранее найти проблемы с, к примеру, текстурными картами и запечь новые для фикса найденной проблемы.
Пример работы над 3Д моделью
Такие хитрости как замены хай поли на лоу поли моделей или даже на Импостеров, баланс и скорость отображения полигонов на загруженных сценах, обработка эффектов и т.п. очень сильно могут снизить производительность и количество кадров в секунду (FPS). Данные аспекты проверяются в рамках всем нам известного Performance Testing. Я бы отнёс плюс/минус в эту категорию и Soak Testing, благодаря которому ищут memory leaks в играх. Также в рамках группы по тестированию производительности стоит отнести Stability testing, в рамках которого вы находите такие всеми любимые вещи как фризы, краши, чёрные экраны, невозможность загрузить уровень, порча сохранённых данных и прочее.
Однако проблемы могут возникнуть не только при большом количестве моделей на экране, но также и при большом количестве онлайн игроков в вашей игре. Хотя и не при большом, если вы не протестировали неткод в рамках Network Testing. Благодаря данному виду тестирования можно также проверить лаги/дропы в соединени, matchmaking, стабильность конекшенов, инпут лаги контроллеров и многое другое. Немного отходя в сторону, я бы выделил ещё баги, которые воспроизводятся при плохом интернет соединении и, если у вас со скоростью интернета всё хорошо, то нужно эмулировать «плохое интернет соединение». Больше о неткоде и типах соединения можно посмотреть здесь.
Уже всё вышеописанное звучит достаточно громоздкая и сложная система. Но это ещё ничего, ведь мы больше говорили о front-end части (клиент), а ведь Back-End часть и Back-End testing никто не отменял. Здесь мы пробегаемся по вашему беку, который часто включает базы данных, API (к примеру REST API), телеметрию и многое другое.
Важно держать во внимании, что кроме ваших собственных стандартов качества к игре, свои стандарты есть у платформодержателей. Часто такие проверки называются Technical Requirements Checklist или TRC, а проверяются они в рамках Compliance testing и, часто, не вашей командой, а командой QA на стороне платформодержателя. В рамках данного тестирования вы можете также проверить внутриигровые покупки, достижения (Achievements), подписки (subscriptions), если они у вас есть, а также поддержку фич стриминговых сервисов. Часто для таких нужд «отпочковывается» отдельный билд, который доводят до ума и не аффектят его изменениями основной билд.
Правила у каждого платформодержателя свои и вам стоит их искать на соответствующих ресурах
А ещё приятнее пользоваться игрой на родном для вас языке + выход на глобальный рынок подразумевает больший охват потенциальной аудитории. Вооружившись знаниями по тестированию I18N и L10N вы сможете сделать так, чтобы от вашей игры получали удовольствие даже в противоположной от вас части земного шара! Если вам не понятные сокращения I18N и L10N, то ознакомьтесь с моим большим и полезным гайдом и чеклистом по тестированию интернационализации и локализации. В качестве особенности проверки локализации игр (Localization testing), стоит упомянуть разницу в часовых поясах ваших игроков и сервера, а также возможность манипуляции времени и даты на вашем устройстве через смену даты и/или времени через календарь. Часто это приводит к разнообразным ошибкам или нежелательному результату. К примеру если вы засетали какой-то контент для отображения с определённой даты, то хитренький пользователь может сменить дату на будущую и заранее увидеть всю ту красоту, что вы ему подготовили и спойлернуть это всем. Даже дата майнингом заниматься не обязательно 🙂 Для проверки корректности языков есть специальные команды локализации, но не забывайте, что в ваших силах проверить языко-независимые вещи в рамках данного тестирования и это стоит сделать заранее!
Читайте статью по I18N и L10N
Не стоит также забывать и о Security Testing, использование которого глобально не отличается от других сфер. В играх используются учётные записи, аккаунты от разных систем, включая онлайн сервисы и аккаунты от ваших учёток на консолях (к примеру вам нужно играть играть в Rocket League через Epic Games аккаунт, но в системе Playstation), В наше время крайне важно уделять этому аспекту достаточно внимания, ведь никто не хочет потерять даже одну игру, которую этот человек купил или донатил в ней, не говоря уже о потере целого аккаунта со всем «наработанным» добром!
Также стоит упомянуть работу с DRM системами (Denuvo и т.д.) и Anti-Cheat программами (Easy Anti-Cheat и т.п.).
В качестве финального пункта на сегодня в разделе «видов тестирования» важно выделить Game Automation Testing. Автоматизация в геймдеве является достаточно сложным процессом. Многие вещи крайне сложно поддаются автоматизации, к примеру, геймплей, ведь важно не только «знать» расположение персонажа, но и понимать, что вокруг него происходит. Если у вас есть рандомайзер, который спавнит врагов в разное время и в разном количестве или ваши элементы для «3 в ряд» появляются далеко не всегда одинаково, то вам нужно придумать что-то наподобие бота для автоматизации и осмысленных действий в рамках ваших тестов. Думаю вы уже догадались, что автоматизация UI элементов или навигации по таким экранам как «Главное Меню» не составит большого труда. Геймплей же автоматизируют при помощи написании своих ботов. Также можно использовать Image Recognition тулы, они также хорошо подходят и для автоматизации скринов без геймплея. Про одну такую интересную тулу (Airtest) я писал в своих предыдущих статьях. Вот они: раз, два и три.
Стоит упомянуть, что одни и те же понятия в разных игровых компаниях могут отличаться. Те же «тест кейсы, чеклисты, тот или иной вид тестирования» даже такие стандартные понятия могут называться иначе. Это не плохо и не хорошо, но нужно иметь такую особенность ввиду.
Посмотрите какие виды тестирования используются у вас в компании, сравните их с выше описанными и, если вы не нашли свой подход к тестированию игр тут, дайте знать об этом в комментариях!
