На что обратить внимание при тестировании мод файла
Я попытаюсь объяснить, чем отличается хороший мод от плохого, каков шанс багов в моде и т.д.
(English)
Вообще это не так уж и просто, судить о других модах и об их авторах. Так что я чувствую себя немного не в своей тарелке. Имею ли я право судить людей и их труд? Но мне кажется, что проливая свет на данную тему, я поспособствую улучшению качества модов в целом.
Главное правило:
Наличие багов в моде важнее, чем идея и дизайн мода.
Про такой мод пока что ничего не известно.
Такой мод заменяет игровые файлы целиком! Замена файлов действует до тех пор, пока мод активен. Если выключить мод, то его эффект замены исчезнет. Чтобы распознать такой мод, достаточно найти точное совпадение имени файла в папке мода и в папке игры.
Конечно же, такой мод будет несовместим с другими модами, которые заменяют те же самые файлы.
Обратите внимание, что иногда нет другого способа создать мод, кроме как замена файла. Например, мод, заменяющий текстуры, будет исключением из этого правила. Но если он заменяет текстур-паки целиком, то это всё же очень плохой мод.
Такой мод хоть и не заменяет файлы целиком, но зато заменяет целиком функции в коде или определения объектов. Замена действует, только когда мод активен (аналогично предыдущему уровню).
Распознать такой мод не просто. Вы можете поискать наличие признаков в файлах мода, особенно в txt файлах предметов. Определение предмета начинается с этого:
Если вы нашли такой же "ItemName" (идентификатор предмета) в папке игры (/media/scripts/), то будьте уверены, что мод заменяет определение целиком. Это признак того, что мод плохой.
В качестве результата замены есть средний шанс несовместимости с игрой или другими модами в будущем. Но это гораздо лучше, чем заменять файлы целиком.
(т.е. уровня 3 и выше)
Чтобы увидеть, что мод не плохой, достаточно убедиться, что он не заменяет ни файлов, ни функций, ни предметов. Вы должны хотя бы немного разбираться в программировании.
В моде есть файл:
/media/scripts/newitems.txt
Такой же файл есть в папке игры:
/media/scripts/newitems.txt
В моде есть файл:
/media/lua/client/TimedActions/ISReadABook.lua
Такой же файл есть в папке игры:
/media/lua/client/TimedActions/ISReadABook.lua
-- Reduce read time local old_fn = ISReadABook.new; function ISReadABook:new(. ) local o = old_fn(self, . ); if o.maxTime ~= 1 then o.maxTime = o.maxTime * 0.5; end return o; end
Такое же определение предмета (item Cigarettes) есть в txt-файлах самой игры.
Обратите внимание, что замена типа предмета (Type) - это очень плохо, потому что это приводит к удалению всех старых предметов (Cigarettes в данном случае) из сохранения.
name = "Base.Cigarettes" item = ScriptManager.instance:getItem(name) if item then item:DoParam("Count = 1") item:DoParam("Weight = 0.05") item:DoParam("Icon = SMPack") end
Автор такого мода может быть хорошим программистом или художником, но создаёт мод в ленивой манере. Поэтому мод будет содержать много опечаток и допущений, что приведёт к проблемам и багам (небольшой шанс).
Такой автор будет ждать фидбека (обратной связи) от пользователей в комментариях. В противном случае автор не будет исправлять баги, даже если мод вообще не работает.
Как видите, такой мод не так уж и плох, но я всё ещё рекомендую подумать дважды, прежде чем устанавливать такой мод. Как преданный игрок PZ, вы должны примерно знать, кто есть кто в сообществе моддинга Зомбоида: кто ленив, кто стеснителен, кто эгоистичен, кто горделив и т.д.
Чтобы распознать данный тип модов, если вы не особо разбираетесь в программировании или художествах, для начала посмотрите на оформление мода в мастерской Стима. Подробное описание и наглядные картинки означают, что автор потратил много времени на это, и, возможно, также потратил много времени на разработку и тестирование мода (это признак, но не доказательство). И конечно, если вы видите логотип Indie Stone вместо иконки мода, это однозначно говорит, что мод является неопрятным.
Если же вы разбираетесь в программировании, взгляните на код (конечно, если в моде вообще есть луа-файлы). Изящная инъекция кода выглядит примерно так (это отличает мод от плохих модов):
Аккуратная модификация свойств предмета выглядит примерно так (через скрипты Луа, а не через txt-файлы):
local item = ScriptManager.instance:getItem("Base.Battery") if item then item:DoParam("Weight = 0.05") end
Начиная с уровня 3, моды можно считать хорошо совместимыми как с игрой, так и с другими модами. Также мод МОЖЕТ быть заброшен автором, но всё равно вероятно не забагуется ещё долгое время, не смотря на изменения в игре от разработчиков. Конечно, если уже прошли годы, то уже стоит задуматься, а не устарел ли мод.
Такой мод не содержит багов, особенно если он очень простой. Но геймдизайн вызывает сомнения.
- делает ли мод игру сильно проще или сложнее;
- являются ли механики слишком детализированными и отнимают ли слишком много времени в игре при взаимодействии с ними;
- много ли выгоды от использования механик (или они бесполезны?) по сравнению с другими механиками игры;
- реалистичный ли мод (в конце концов, это же Зомбоид!);
Ничего из вышеперечисленного. :)
Обратите внимание, что всегда есть ненулевая вероятность того, что очередное обновление испортит даже хороший мод. Всплывающие красные ошибки не обязательно означают, что мод сам по себе бажный и не является хорошим. Помните, что все люди ошибаются, в том числе даже профессиональные мододелы и разработчики игры.
В данный чек-лист вошли только общие характеристики. Естественно, в тестируемом приложении может быть функциональность, для которой нужно применять отдельный подход и создать отдельные сценарии. То же самое верно для производительности, удобства использования, безопасности и прочего тестирования, которое необходимо вашему приложению.
Чек-лист для тестирования WEB приложений состоит из шести разделов:
Так что же по итогу?
Как вы могли убедиться, тестирование игр - это сложный, многоступенчатый, но крайне увлекательный и творческий процесс, который включает в себя самые разные виды тестирования, включая специфические, которые вы не найдёте в других “жанрах” программ. Начать тестировать игры, как и в целом начать заниматься тестированием, можно с простых задач, зная только базу для позиции “джуниор” и понимание чем и как живёт игровая индустрия. Для этого не обязательно иметь профессиональное высшее игровое образование =)
Однако как и во всём, чтобы стать специалистом в чём-то, вам нужно будет гриндить опыт в разных сферах и инструментах, а также обладать аналитическими качествами, которые помогут вам в этом направлении, например аналитические и логические навыки, глубокое знание видеоигр, их устройство и механики; способность работать под давлением и т.д. Тестирование игр - своего рода рейд босс, для победы над которым нужен соответствующего уровня специалист. И чтобы прокачать такого специалиста обычно не достаточно просто взять "опытного QA инженера", чтобы у вас вдруг материализовался классный Game Tester. В таких случаях часто всё работает наоборот, так как наиграть наработать богатый игровой опыт в краткосрочной перспективе - крайне сложная задача.
Но в целом, всё зависит от того, чем вы хотите далее заниматься: кто-то хочет помогать разработчикам своим фидбеком и прекрасным стартом для данной активности будут плейтесты, ранние доступы и т.д., а кто-то - углубленно изучать игры и добиваться их качества собственноручно, находить и локализовывать проблемы качества продукта прямиком на проекте! Данная серия из 3х статей как раз и была призвана помочь вам во всех этих случаях и ввести вас в курс дел на этот поприще! Надеюсь они были вам полезны и вы открыли для себя что-то новое! Пишите также примеры из вашего опыта в комментариях, чтобы мы могли подискутировать на данную тему!
Изучение
Модульное тестирование является одним из основных видов тестирования программного обеспечения. Как и в случае с тестированием программного обеспечения, модульное тестирование не может гарантировать отсутствие ошибок после развертывания приложения. Однако, тестируя наименьшие повторяющиеся фрагменты кода в ваших приложениях, модульное тестирование помогает выявлять ошибки в строительных блоках вашего проекта до того, как они повлияют на ваше интегрированное приложение.
Будучи важным процессом разработки программного обеспечения, модульное тестирование является ценным навыком, который должен знать разработчик. Если бы мы могли следовать передовым методам модульного тестирования, мы уже проводили бы модульное тестирование на этапе разработки. Однако это не реально для всех проектов разработки программного обеспечения. Таким образом, модульное тестирование может выполняться после того, как ваш производственный код написан, и это необходимо для обеспечения того, чтобы расширенный и рефакторинговый код оставался функциональным.
Сегодня мы рассмотрим обзор модульного тестирования и лучших практик модульного тестирования.
Кросс-платформенное тестирование
Кросс-платформенное тестирование проводится, чтобы убедиться, что ваше приложение совместимо с другими браузерами, различными оболочками, аппаратным обеспечением устройства.
6. Пишите тесты до или во время разработки
В идеальном мире мы пишем тестовый код перед написанием рабочего кода. Это известно как разработка через тестирование (TDD) — процесс разработки программного обеспечения, посредством которого мы параллельно улучшаем наши тестовые примеры и программный код. TDD помогает увеличить покрытие кода модульными тестами.
Процесс TDD выглядит следующим образом:
- Разработка модульных тестов для подмножества большого проекта
- Быстрое написание кода вышеупомянутого подмножества
- В случае каких-либо ошибок, рефакторинг вашего кода. В противном случае повторите цикл TDD.
- Продолжайте, пока весь ваш проект не будет завершен без явных ошибок.
Следующий рисунок иллюстрирует этот процесс:
Цикл разработки через тестирование
Функциональное тестирование
В данном пункте нам важно убедиться, что наш продукт соответствует нужной функциональной спецификации, упомянутой в документации по разработке.
Общие инструменты, которые могут быть полезны в тестировании игр
Говоря об инструментах, которые напрямую не связаны с тестированием, но могут облегчить вам жизнь, я бы выделил следующие: VCS (Perforce, Git), редакторы игровых движков, Grafana и Playfab.
Про Perforce и Git не буду говорить много, т.к. это распространённые Version Control System программы и важные элементы workflow большинства проектов. При помощи Perforce вы можете выкачать дев билд, залить изменения, выбрать и использовать определённый номер билда (Change List), сделать файлы доступными для редактирования (Check Out), задать нужные вам настройки и т.п. После проведения манипуляций, описанных выше, вы можете использовать данный билд как вашей душе угодно, например взять определённые файлы или коммиты и убедиться, что баг там (не)представлен, но это уже совсем другая история =)
Часто недалеко от Perforce можно найти и Git на вашем проекте, но используются они для разных нужд, например Perforce - для работы с клиентом, Git - для работы с Back-End частью. Больше о Perforce можно почитать на их оффициальном сайте и я крайне настоятельно рекомендую ознакомиться с ним.
UnrealGameSync (UGS)
Если же вы не хотите мучаться с изучением Perforce, но при этом вам нужна возможность собирать билды с определёнными CL'ами, то в помощь вам всегда придёт такой классный инструмент как UnrealGameSync (UGS). В данном случае это инструмент для Unreal Engine, который позволяет вам видеть и фильтровать CL'ы в репозитории. При помощи UGS крайне удобно отслеживать последние изменения и собирать новый билд - просто кликни дважды на нужный CL и процесс пойдёт! (звучит как рекламный слоган xD)
Engine Editor
Примерно та же история у нас и с редактором игровых движков. Тут вы можете перенастроить нужные вам элементы внутри игры перед её запуском. Игру можно запускать как в режиме "редактора" (игра запускается во ViewPort вашего движка), так и в "standalone" режиме. Любые ваши пожелания и предпочтения можно выполнить тут, если таковые имеются, однако чаще всего тестировать игру нужно на "финализированных" билдах, которые можно либо выкачать с ваших внутренних ресурсов после завершения очередного CI/CD процесса, либо играть напрямую через игровые площадки наподобие Steam.
Стоит также упомянуть, что редактора может не быть в некоторых кастомных движках.
Grafana
Grafana - это дашборд для визуализации метрик используется многими членами команды. Крайне полезный инструмент во время Performance и Network тестирования благодаря возможности следить за количеством реальных и сэмулированных игроков в данный момент времени, отображению ограниченного количества информации для внешних команд в вашем процессе и многое другое. Больше о данном инструменте можно почитать тут.
Пример графиков в Grafana
Playfab
Думаю также стоит упомянуть про Playfab. По сути это готовый Back-End, предоставляемый в наши дни компанией Microsoft по подписке, который объединяет аккаунты из разных игр в единый (мастер) аккаунт, помогает в настройке экономики без "лишнего" кодинга. Как утверждается на сайте Playfab - это комплексное серверное решение, которое позволяет избежать трудностей со сборкой, управлением и запуском серверов в нужном масштабе, а также помогает в организации чатов и обмена данными с минимальной задержкой.
В рамках тестирования Playfab будет использоваться не часто (это НЕ инструмент для тестирования, как и все инструменты в данной секции), однако может быть интересен, когда речь заходит про проверку правильности использования, например, аналитики, которая прикручивается к вашей функциональности. Кто же откажется использовать аналитику для BattlePass или системы прогрессии?
На сайте Playfab вы можете увидеть много игр, использующих данный продукт. Среди них - Doom Eternal, Minecraft, Roblox, Gears 5 и многие другие! Обзор предоставляемых Playfab функций можно посмотреть на их сайте.
Инструменты от производителей консолей
В конце данной секции уточню, что все производители консолей имеют свои инструменты для связи и работы с дев и тест китами. Данные программы имеют множество полезных функций, таких как сбор логов, работа с данными сохранений, сбор информации при краше игры, возможность использования расширенных ресурсов дев китов, эмуляция работы с онлайн сервисами без прямого подключения к ним, удалённое управление и многое другое! Начиная с 2020 все эти программы начали улучшать уже имеющийся функционал по удалённому управлению консолями, что крайне удобно современных реалиях.
Пример использования Nintendo Target Manager, найденный на просторах интернета
Удаление (Деинсталляция)
7. Один вариант использования на модульный тест
Каждый тест должен фокусироваться на одном варианте использования и проверять, что результат соответствует ожидаемому для этого тестируемого метода. Сосредоточив внимание на одном варианте использования, вы получите более четкое представление о корне проблемы в случае, если тест не пройден (в отличие от тестирования нескольких вариантов использования).
Файлы конфигурации
Файлы конфигурации встречаются повсеместно и вы можете ими пользоваться для самых разных нужд. В дев билдах таких файлов больше, чем в релизной версии, и через них вы можете включать/выключать фичи, менять разрешения, управлять уровнем логирования, указывать к какому back-end'у конектиться, управлять настройками графики и многое другое. Часто любители "игр в возрасте" ковыряются в файлах конфигурации (например формата ".ini") для настройки работоспособности старых игры на новом железе, если для неё не выходил соответствующий патч или переиздание. Количество и объём доступных настроек и их формат могу кардинально отличаться от игры к игре, даже если игры написаны на одном движке.
Пример файла конфигурации (.ini файла) из Fortnite
9. Сокращение тестовых зависимостей
Тесты не должны зависеть друг от друга. Уменьшая зависимости между модулями, исполнители тестов могут одновременно запускать тесты для разных фрагментов кода. Модуль может считаться пригодным для тестирования только в том случае, если его зависимости размещены (т. е. заглушки) в тестовом коде. Никакие реальные или внешние зависимости не должны влиять на результат теста.
Игровая консоль
Консоль в игре может и часто используется в качестве полезного в тестировании инструмента. Обычно вызывается она при нажатии кнопки "~" (тильда), выпадает либо внизу небольшой строчкой, либо сверху экрана, занимая приличную его часть. Думаю многие использовали консоль в Counter Strike 1.6, превращая вашего персонажа из правши в левшу или меняя характеристики вашего прицела. Однако консоль не была включена по-умолчанию: её нужно было предварительно активировать в Options.
Пример игровой консоли в Counter Strike 1.6
При помощи консоли на дев билдах (к примеру сразу из Unreal Editor) можно подключать back-end с нужными вам тестовым аккаунтам, ускорять или замедлять игру (не FPS, а именно внутриигровые действия), использовать чит коды, включать-выключать нужные вам HUD и многое другое.
Wireframe mode
Wireframe mode или режим “проволочной рамки” показывает все полигоны в сцене без заполнения. Цвет линий рёбер полигонов может иметь дополнительную функцию. А может и не иметь :) (тогда условно все рёбра - чёрные).
3. Настройте автоматические тесты
Выберите автоматизированное модульное тестирование с помощью среды модульного тестирования. Еще лучше автоматизировать тесты в конвейере непрерывной интеграции (CI/CD).
Альтернативой автоматизированному тестированию является ручное тестирование, при котором мы вручную выполняем тестовые случаи и собираем их результаты. Как вы понимаете, ручное тестирование небольших модулей невероятно утомительно. Он также менее надежен. Автоматические тесты, безусловно, помогут вам в этом.
10. Стремитесь к максимальному охвату тестами
Хотя мы можем стремиться к 100% охвату тестами, это может быть не всегда желательно или возможно. Такое всестороннее тестирование может иметь финансовые и временные требования, превышающие наши возможности. В некоторых случаях такое комплексное тестирование теоретически невозможно (т.е. неразрешимо). При этом мы должны стремиться к максимально возможному охвату с учетом наших ограничений.
Lit mode
Режим Lit отображает финальный результат вашей сцены после применения всех материалов и освещения.
Обновление
Проверка обратной совместимости включает следующие шаги:
● После установки обновления, все ранее созданные приложением объекты, такие как документы, формы, сохранения (если это игра) должны открываться и работать без ошибок. Такое поведение называется обратная совместимость (backward compatibility). Пользовательские настройки должны остаться прежними, конечно если обновления не затрагивали именно их изменение.
● Созданные в новой версии однотипные документы должны корректно открываться в старых версиях, конечно если целью обновления не стояло изменение формата и структуры файлов. Если же был внедрен новый формат, то в новой версии должна быть реализована возможность сохранения документа в старом формате.
● В случае, если обновляемое приложение запущено, пользователь должен получить предупреждение о том, что обновление невозможно, при работающем приложении.
Заметим, что процесс обновления может быть остановлен в любой момент, при этом исходное приложение должно остаться не изменённым и в рабочем состоянии. Допустим у вас установлено приложение версии 1, вы пытаетесь обновить его до версии 2, но в процессе установки передумали и прервали установку. В этом случае инсталлятор должен вернуть все уже сделанные изменения, почистить использованные для обновления временные файлы и завершить свою работу. При этом приложение версии 1 остается в рабочем состоянии.
Особенности тестирования инсталляторов:
Инсталлятор — это «обычная» программа, основные функции которой — Установка (Инсталляция), Обновление и Удаление (Деинсталляция) программного обеспечения.
Всем известна народная мудрость: "Встречают по одежке, а провожают по уму". Инсталляционное приложение и есть та самая одежка, по которой создается первое впечатление о Вашем продукте. Именно поэтому тестирование установки — это одна из важнейших задач.
Если эти особенности не зарядили Вас на серьезное отношение к тестированию инсталляционных программ, то хочу привести небольшой список рисков, который покажет всю значимость корректной работы инсталляторов:
● риск потери пользовательских данных.
● риск вывода операционной системы из строя.
● риск неработоспособности приложения.
● риск некорректной работы приложения.
В тоже время, как и на любую программу, на инсталлятор накладываются некоторые функциональные требования. Объединив их со списком особенностей, мы получим более полную картину, показывающую объем предстоящих работ по тестированию. Далее, исходя из списка требований, Вам надо будет ответить на вопросы: «Что тестировать?», и только затем — «Как тестировать?».
С современным изобилием персональных компьютеров, серверов и операционных систем, возникла потребность в установки одного и того же программного обеспечения на разные платформы. Для этого инсталляторы должны понимать что и куда они устанавливают в зависимости от окружения.
Reflections mode
Режим Reflection полезен для диагностики деталей отражений и позволяет вам размещать больше "Reflection Capture Actors" в областях, где вам нужно больше деталей.
Управление вашим интернет соединением
Крайне важный пункт для проверки в наше время, т.к. даже в сингл плеерных играх могут (и чаще всего встречаются) элементы, завязанные на онлайн. К сожалению здесь нету какого-то уникального и всеобъемлющего инструмента. Лично мне приятно и удобно использовать инструмент Clumsy в качестве помощника в этом деле. Программа манипулирует не игрой, а вашим соединением в целом, что делает Clumsy удобным инструментом для управления вашим соединением для абсолютно любых нужд: web, standalone software и т.п. В рамках данного инструмента вы можете управлять такими возможностями испортить ваше интернет соединение как Lag, Drop, Throttle, Out of order, Duplicate и Tamper. При чём делать это вы можете как для Inbound, так и для Outbound, указав шансы на встречу данной проблемы.
Пример использования Clumsy
Unlit mode
Данный режим выключает всё освещение в сцене, показывая только Base Color.
Что проверяем?
- Проверяем работу сторонних модулей: оплата, шаринг, карты.
- Реклама (просмотр, переходы по рекламе, аналитика).
- Метрики (переходы по страницам, показы элементов, клики).
5. Организовать, действовать и утверждать (ААА)
Протокол AAA является рекомендуемым подходом для структурирования модульных тестов. В качестве передовой практики модульного тестирования это улучшает читабельность вашего теста, придавая ему логическую последовательность. ААА иногда называют протоколом «Дано/Когда/Тогда».
Вы можете использовать протокол AAA для структурирования модульных тестов, выполнив следующие шаги:
- Упорядочить: Упорядочить настройку и инициализацию для теста.
- Act: Действуйте на единицу для данного теста.
- Утвердить: Утвердить или проверить результат
Следующий код демонстрирует структуру AAA при тестировании функции абсолютного значения в Python:
9 лучших практик модульного тестирования
Что проверяем?
- Дата и время. Например отображение времени, даты в соответствии с часовым поясом пользователя.
- Смена языка и проверка перевода всех элементов WEB приложения исходя из выбранного языка.
- Выбор номера телефона с разными кодами стран.
- Определение местоположения пользователя и отображение соответствующего пермишена ГЕО.
- Отображение соответствующих символов валюты.
1. Напишите тесты для ряда сценариев
При написании тестового примера убедитесь, что вы рассматриваете все возможные сценарии. Другими словами, не просто напишите тест на счастливый путь. Подумайте и о других сценариях, таких как обработка ошибок.
Тестовое покрытие
Тестовое покрытие — это метрика, определяющая, насколько тщательно мы провели модульное тестирование нашего программного обеспечения. Как правило, мы хотим максимально увеличить тестовое покрытие.
Тестовое покрытие можно дополнительно классифицировать следующим образом:
- Охват функций: процент функций, которые были протестированы.
- Покрытие операторов: процент утверждений, которые были протестированы. Иногда он включает в себя все операторы, которые были выполнены хотя бы один раз во время тестирования.
- Покрытие пути: процент проверенных путей. Программное обеспечение может иметь несколько путей (или ответвлений), выбранных им в зависимости от условий, таких как ввод данных пользователем, определение среды и другие события.
Инструментарий игровых площадок
Все игровые площадки предоставляют разработчикам свой инструментарий для загрузки и тестирования игры через их систему. Например Steam позволяет через меню Properties вашей игры переключать языки (локализация), запускать игру с вашими собственными параметрами (например запуск игры с нужными вам параметрами или переписи значений используемых параметров), позволяет проверять целостность файлов игры, вручную проверять обновления с вашей CI/CD системы и многое другое! Ну и само-собой площадки позволяют вам загрузить и добавить в библиотеку вашу игру по специальному коду. Если же игра уже доступна для скачивания игрокам или вы хотите использовать разные окружения (environments) для разных команд, то для таких нужд игровые площадки предоставляют возможность использования разных веток (Branches). К примеру один бранч смотрит на master client - test backend ("рабочее окружение"), а второй - production client - live backend (релизное окружение).
Пример функционала для добавления вашей игры (dev build) в вашу коллекцию Steam
Такой способ крайне удобен в использовании и помогает всем членам одной команды или даже разным командам использовать нужные всем версии игры без влияния друг на друга. При использовании "рабочего окружения" также площадки перед запуском спрашивают о необходимости запуска анти-чит системы.
Во многих случаях тестировщикам даже не нужно использовать Editor build (запуск игры через редактор игрового движка), ведь большинство нужд покрывается, по умолчанию, билдом с площадки. Также такая версия билда является максимально приближенной к тому, что получит конечный игрок, что является важным критерием для выбора данных сборок в качестве главных кандидатов для регрессионного тестирования.
Меню контроллеров, поддерживаемых вашей игрой на данный момент
4. Пишите детерминированные тесты
Ложноположительные и отрицательные результаты являются обычным явлением при тестировании программного обеспечения, и мы должны приложить все усилия, чтобы свести их к минимуму. Цель состоит в том, чтобы иметь согласованные выходные данные для тестов, чтобы проверить желаемую функцию. Поэтому модульные тесты должны быть детерминированными. Другими словами, пока код теста не изменяется, детерминированный тест должен иметь стабильное поведение при каждом запуске теста.
Что проверяем?
Режимы просмотра (View modes)
Игровые движки обладают такой функциональностью как "режимы просмотра" (view modes), которая помогает вам увидеть тип данных, обрабатываемых в вашей сцене, а также диагностировать любые ошибки или неожиданные результаты. У самых распространённых режимах просмотра есть свои горячие клавиши и они могут отличаться от движка к движку, но вы всегда можете просмотреть их все из режима просмотра или вызвать при помощи соответствующей команды в консоли. Ниже я приведу несколько примеров на основе View Modes из Unreal Engine, а больше и подробнее вы можете почитать в документации движка. Давайте же взглянем на несколько из них.
Чит коды / Чит меню (Cheat Codes / Cheat Menu)
Чит коды изначально были не пасхалками или полезными ништяками для игроков, чтобы те могли загружать определенный уровень или установить себе бесконечное здоровье/деньги и даже были придуманы не для сохранений, хоть и могут быть так применены. Чит коды использовались разработчиками для отладки игр. Их, в силу разных ограничений, нужно было вводить на определённом экране игры или меню. Со временем коды попали в народ и стали крайне востребованы по понятным “божественным” причинам.
Сейчас же вместо кодов, которые нужно запоминать и долго вводить, используются Чит Меню, в которых уже есть списки чит кодов, сгруппированных в удобный для использования вид. Данный список можно вызвать практически на любом экране, однако если код не подходит под текущие условия, то он не выполнится (к примеру если вы пытаетесь заспавнить объект в главном меню). Чит меню - это не типовая функциональность, у каждой игры оно имеет и уникальный вид, и уникальный код, ответственный за его реализацию.
Пример удобного чит меню
Однако с большой силой приходит и большая ответственность - использование чит кодов может привести к багам, которые в реальных игровых условиях никак не добиться. Именно по этой причине достаточно сложные и даже "странные" баги нужно перепроверять и воспроизводить без использования чит кодов, а также всегда держать в уме весь флоу, который должен пройти игрок, чтобы наткнуться на данную проблему. Также стоит учитывать и то, что есть большая вероятность, что тот или иной баг, легко воспроизводимый при помощи читов, игрок никогда на практике и не встретит.
P.S. Motherlode и Konami Code навсегда в наших сердечках!
Что тестировать в Инсталляционных программах?
Тестирование локализации и глобализации
Тестирование интернационализации/глобализации WEB приложения включает тестирование приложения для различных местоположений, форматов дат, чисел и валют. Тестирование локализации включает тестирование WEB приложения с локализованными строками, изображениями и рабочими процессами для определенного региона.
Тестирование мастера установки (Installation Wizard)
В большинстве случаев инсталлятор представляет собой приложение в виде мастера (Wizard), которое может обладать специфическими требованиями, рекомендации по тестированию которых рассмотрены ниже:
Что такое модульное тестирование?
Модульное тестирование гарантирует, что модули в вашей программе работают должным образом. Поскольку человек, написавший фрагмент кода, лучше всего понимает его ожидаемое поведение, ответственность за модульное тестирование обычно лежит на разработчике. В сочетании со сквозными и интеграционными тестами модульное тестирование помогает обеспечить качество кода на ранних этапах процесса разработки.
Модуль — это наименьший фрагмент кода в вашей программе, который повторяем, тестируем и функционален. Единицами могут быть функции, классы, методы и так далее.
Уровни тестирования программного обеспечения
На предыдущем рисунке показано модульное тестирование наряду с другими уровнями тестирования программного обеспечения, где каждый уровень имеет свою область применения:
- Модульное тестирование проверяет каждый программный модуль.
- Интеграционное тестирование проверяет объединенные модули в соответствии с проектной документацией системы и функциональными требованиями.
- Функциональное тестирование проверяет желаемую функциональность программы на основе документов анализа требований и руководства пользователя (т. е. обеспечение ожидаемого результата для заданных входных данных). Это иногда делится на системное тестирование и приемочное тестирование.
Тестирование «черного ящика» и «белого ящика» — это два подхода к тестированию программного обеспечения, в которых:
- Тестирование черного ящика проверяет поведение программного обеспечения, не зная деталей реализации программного модуля. Эти тесты получены из документа спецификации программного обеспечения.
- Тестирование методом белого ящика проверяет фактическую реализацию программного модуля, при этом внутренняя архитектура программы известна тестировщику. Эти тесты дают нам представление о реализации для разработки более комплексных тестов.
Для модульного тестирования наиболее подходящим вариантом обычно является тестирование белого ящика, особенно когда наши модули меньше и их код легче понять. С другой стороны, тестирование «черного ящика» — хороший вариант для более поздних стадий проекта, когда модули были интегрированы для создания сложного программного обеспечения.
Что проверяем?
- Тестирование в различных браузерах (Firefox, Chrome, Safari — это минимальный набор): анимация, верстка, шрифты, уведомления и т.д.
- Тестирование в различных версиях ОС: Windows, Mac, Linux.
- Java Script код работает в разных браузерах.
- Просмотр на мобильных устройствах.
Тестирование удобства использования
Тестирование удобства использования подразумевает проверку навигации, контента, другая информация для пользователя.
Как тестировать Инсталляции?
Получение списка файлов должно проводиться До, а проверка самих файлов — После установки.
Самое правильное — это попытаться получить список файлов от сборщика инсталляционного пакета. Фраза: «Возьмите и составьте список после установки ПО, там все верно» — это провокация и на нее лучше не поддаваться.
Если программа содержит файлы подписанные сертификатом, например от MS, то не исключено, что могут попадаться временные файлы, которые уже не нужны для работы приложения (*.tmp и т.д.). Обратите внимание, что один и тот же инсталляционный пакет может устанавливать под разные ОС разные наборы файлов. Поэтому тестировать надо делать под каждую ОС отдельно.
Практически для любой ОС важна регистрация рабочих библиотек и служебных записей. Например, в ОС Windows вам необходимо будет проверить системный реестр на предмет корректной записи новых данных и регистрации новых/нового приложения.
Если при открытии документа, на работу с которым рассчитана ваша программа, вы получите в результате диалог выбора программы для открытия файлов данного типа или же он будет открыт другим приложением, то налицо будет ошибка регистрации расширения в ОС.
Резюме
Мы ознакомились с универсальной шпаргалкой по тестированию WEB приложений. Не забывайте читать документацию и дополнять чек-лист проверками, характерными для вашего сервиса. А если остались вопросы — скорее пишите в телеграм-канал @qa_chillout.
Тестирование установки ПО направленно на проверку успешной инсталляции и настройки, а также обновления или удаления программного обеспечения.
В настоящий момент наиболее распространена установка ПО при помощи инсталляторов (специальных программ, которые сами по себе так же требуют надлежащего тестирования.
В реальных условиях инсталляторов может не быть. В этом случае придется самостоятельно выполнять установку программного обеспечения, используя документацию в виде инструкций или readme файлов, шаг за шагом описывающих все необходимые действия и проверки.
В распределенных системах, где приложение разворачивается на уже работающем окружении, простого набора инструкций может быть мало. Для этого, зачастую, пишется план установки (Deployment Plan), включающий не только шаги по инсталляции приложения, но и шаги отката (roll-back) к предыдущей версии, в случае неудачи. Сам по себе план установки также должен пройти процедуру тестирования для избежания проблем при выдаче в реальную эксплуатацию. Особенно это актуально, если установка выполняется на системы, где каждая минута простоя — это потеря репутации и большого количества средств, например: банки, финансовые компании или даже баннерные сети. Поэтому тестирование инсталляторов можно назвать одной из важнейших задач по обеспечению качества программного обеспечения.
Именно такой комплексный подход с написанием планов, пошаговой проверкой установки и отката инсталляции, полноправно можно назвать тестированием установки или Installation Testing.
Под катом много текста о том, что следует помнить при тестировании.
Что проверяем?
- Пользователь с данными существует в системе.
- Пользователь с данными не существует в системе.
- Пользователь, заблокированный в системе, не может пройти повторную регистрацию.
- Пользователь существует в системе с введенным логином и паролем.
- Пользователь с введенным логином не существует в системе.
- Пользователь с введенным логином существует в системе, но пароль неверный.
- Пользователь с введенным логином и паролем существует в системе, но заблокирован модерацией (страница заморожена).
- Валидация полей ввода.
- Максимальная и минимальная длина.
- Диапазон допустимых символов, спецсимволы.
- Обязательность к заполнению.
- Убедитесь, что астериск (знак звездочки) отображается у всех обязательных полей.
- Убедитесь, что система не отображает окно ошибки при незаполненных необязательных полях.
- Протестируйте функциональность сортировки (по возрастанию, по убыванию, по новизне).
- Задать фильтры с выдачей.
- Задать фильтры, по которым нет выдачи.
- Фильтры по категориям/подкатегориям.
- Фильтры с радиусом поиска.
- Данные в выпадающих списках.
- Пользователь очистил кэш браузера
- Посмотрите, что будет, если пользователь удалит куки, находясь на сайте.
- Посмотрите, что будет, если пользователь удалит куки после посещения сайта.
- Ошибки в Console.
- Все стили загружаются.
- Картинки загружаются.
Внутриигровые HUD (Heads-Up Display)
Крайне полезные инструменты, которые, в прочем, без помощи разработчиков, не получить. HUD виджеты часто вызываются при помощи консольной команды. В зависимости от того, как разработчики настроят HUD, будет выводиться та или иная информация под определённые нужды. При помощи таких элементов крайне удобно следить за нанесённым уроном, прогрессам по испытаниям (challenges), использованием предметов (consumables) и т. п.
Стоит упомянуть, что такие HUD разрабатываются разработчиками специально для отладочных нужд и их вполне может не быть в вашем проекте.
8. Избегайте логики в тестах
Чтобы уменьшить вероятность ошибок, ваш тестовый код должен практически не содержать логических условий или ручных конкатенаций строк.
11. Храните надлежащую тестовую документацию
Ведение тестовой документации поможет как разработчикам, так и, в некоторых случаях, конечным пользователям (например, в случае с API).
Интеграционное тестирование
Интеграционное тестирование проводится для того, чтобы убедиться, что ваше приложение совместимо со сторонними сервисами.
Что проверяем?
Тестирование безопасности
Данная проверка нацелена на поиск недостатков и пробелов с точки зрения безопасности нашего приложения.
Преимущества модульного тестирования
Некоторые преимущества модульного тестирования включают в себя:
- Упрощает отладку : тестируя функциональность небольших модулей, вы можете обнаруживать ошибки до того, как они повлияют на другие модули в интегрированном приложении.
- Поощряет более слабосвязанный код : намеренно уменьшая взаимозависимости между модулями, мы получаем более слабосвязанный код, что является передовой практикой кодирования.
- Быстрее, чем функциональное тестирование : поскольку модули очень маленькие, вы можете запустить несколько модульных тестов за секунды (при условии, что вы их автоматизировали).
- Минимизация регрессии кода : после рефакторинга или расширения кода вы можете повторно запустить все наборы тестов, чтобы убедиться, что ваш новый или обновленный код не нарушает существующие функции.
- Лучшее покрытие кода. Разбивая приложение на мельчайшие тестируемые компоненты, модульное тестирование помогает увеличить покрытие кода.
2. Напишите хорошие названия тестов
Хорошее имя модульного теста должно явно отражать цель тестового примера. Следуйте согласованным соглашениям об именах и используйте сокращения только в том случае, если они понятны читателю. Написание хороших имен тестов повышает читабельность кода, что облегчит вам и другим возможность расширять этот код в будущем.
Weapon room / Training room
Такого рода комнаты, как правило, содержат оружие, персонажей, врагов (включая боссов), поверхности, предметы (consumables), транспорт. В общем всё необходимое и теоретически необходимое, что может пригодиться для тестирования во время геймплея. Кроме всего вышеперечисленного, в таких пространствах могут быть созданы комнаты под определённые нужды: например в одной могут быть расставлены предметы таким образом, чтобы проверить защищает ли преграда определённого размера вас в приседе, стоя и т. п.; в другой комнате - проходит ли персонаж между объектами и т. п.
Пример Training Room из Apex Legends
Такие пространства встречаются, как правило, в достаточно больших играх, ведь для их создания нужен бюджет и разработчики, которые смогут всё необходимое собрать вместе. Далее вы уже сможете и сами "достраивать" нужные вам пространства внутри данной карты, если умеете пользоваться редактором движка.
Кросс-платформенное тестирование инсталляторов
Отдельным пунктом хочется выделить кросс-платформенное тестирование инсталляторов, которое обязательно должно проводиться для всех трех функций — установка, обновление и удаление:
● Корректность работы инсталлятора с различными версиями ОС, Сервиспаков (ServicePack) и установленных обновлений.
● Проверка файлов, драйверов и библиотек при установке под разные ОС.
● Проверка прав на доступа к файлам, папкам и к системным записям для разных ОС.
● Проверка установленных на файлы приложения разрешений (Permissions).
Для упрощения процедуры тестирования рекомендуется создать таблицу, где колонками будут идти требуемые конфигурации, а строками — тестовые случаи (test cases) или тестируемые функции. В процессе тестирования на пересечении колонок и строк заполняйте результат, что сможет визуально показать прогресс тестирования и соответствие «кросс-платформенным» требованиям.
Проверка списка устанавливаемых файлов проводится по аналогии, что же касается установки драйверов и библиотек, то тут следует отметить особую важность данной проверки. Не все драйвера и библиотеки одинаково хорошо работаю на разных платформах.
Случай из практики: «Для некоторых драйверов есть зависимость от файловой системы, на которой работает ОС. Точнее для некоторых типов ошибок. Был случай, когда на NTFS все прекрасно работало, а на FAT32 нет. Причина была в неверной записи при установке драйвера в реестр.»
Необходимо проверить, что инсталлятор имеет права на доступ к файлам, папкам и к системным записям. Особенно это важно при инсталляции под ОС семейства UNIX, с их жесткими ограничениями в доступе к ресурсам для разных категорий пользователей. При/после инсталляции на unix системах, у файлов должны быть соответствующие разрешения (Permissions). Т.е. если файл предназначен для запуска, то он должен быть запускаемым, если это конфигурационный файл, например, то должны быть разрешения на модификацию и т.д.
Идея моего друга dartos.
В первых двух статьях (раз и два) мы с вами уже взглянули на виды тестирования, применяемые в геймдеве и примеры багов, часто (и не очень) встречаемых в играх. Но в воздухе остался неозвученный вопрос: "Каким образом всё это тестировать?" В этой главе поделюсь подходами и инструментами, которые я использую для тестирования тех или иных игр, включая игры с большими картами (к примеру в жанре Battle Royal) или же что-то более локальное, такое как спортивный симулятор.
Среды модульного тестирования
Платформа модульного тестирования — это программное обеспечение, которое позволяет нам быстро создавать модульные тесты и автоматизировать их выполнение. В случае сбоя теста фреймворки могут сохранить результаты или выдать утверждение.
Существуют десятки фреймворков для модульного тестирования, доступных для различных языков программирования. Некоторые популярные среды модульного тестирования включают Cunit, Moq, Cucumber, Selenium, Embunit, Sass True, HtmlUnit и JUnit (одна из наиболее широко используемых сред с открытым исходным кодом для языка программирования Java).
Мы можем сэкономить много времени и ресурсов с помощью фреймворков модульного тестирования, которые включают следующие функции:
- Набор тестов: набор тестовых случаев, сгруппированных для выполнения тестов, что позволяет нам объединять несколько похожих модульных тестов.
- Test runner: компонент, который автоматизирует выполнение серии тестов и возвращает результат теста пользователю.
- Приспособление для тестирования: предопределенное состояние или фиксированная среда, в которой мы запускаем тесты, гарантируя, что наши тесты повторяются при нескольких запусках тестов.
Обзор модульного тестирования
Читайте также: