Тестирование совместимости
1. Аппаратная платформа;
3. Браузеры (Internet Explorer, Firefox, Opera, Chrome, Safari)
4. Различное расширение экрана
Тестирование совместимости проводится в основном в 2 этапа:
1) На первом этапе проверяется взаимодействие выпускаемого продукта с окружением, в которое он будет установлен, на различных аппаратных средствах.
2) На втором этапе выпускаемый продукт проверяется с позиции его конечного пользователя и конфигурации его рабочей станции.
Связанные понятия
Кросс-платформенность или межплатформенность — способность программного обеспечения работать с двумя и более аппаратными платформами и (или) операционными системами. Обеспечивается благодаря использованию высокоуровневых языков программирования, сред разработки и выполнения, поддерживающих условную компиляцию, компоновку и выполнение кода для различных платформ. Типичным примером является программное обеспечение, предназначенное для работы в операционных системах Linux и Windows одновременно.
В области информационных и компьютерных систем под конфигурацией понимают определенный набор комплектующих, исходя из их предназначения, номера и основных характеристик. Зачастую конфигурация означает выбор аппаратного и программного обеспечения, прошивок и сопроводительной документации. Конфигурация влияет на функционирование и производительность компьютера. Так же в операционной системе можно вручную выставлять настройки драйверов.
Тестирование совместимости
Введение в тестирование совместимости
Зачем нам нужно тестирование совместимости?
Процесс тестирования совместимости
Процесс тестирования включает в себя следующие этапы тестирования совместимости:
1. Настройка среды тестирования
Это первый шаг в тестировании. Среда должна быть настроена для проверки совместимости. Без надлежащей настройки среды тестирование невозможно. Официальное описание работы должно быть подготовлено для инфраструктуры.
2. Создать тестовый набор
Различные тестовые случаи создаются для проверки различных сценариев и поведения подключения. Чтобы охватить разные сценарии, должны быть созданы разные контрольные примеры. Это сделано для более эффективного проведения тестирования. Перед этим все настройки должны быть выполнены, как настройка инструментов автоматизации, чтобы уменьшить количество тестовых случаев и использовать их повторно. Все конфигурации базы данных должны быть сделаны, и показатели должны быть измерены.
3. Выполнение тестового примера
После того, как контрольные примеры сделаны, они должны быть выполнены в среде, которая настроена. Выполнение позволяет нам узнать реальное поведение программного обеспечения и дать нам знать, как будет вести себя программное обеспечение, когда оно запускается и как оно взаимодействует с другими компонентами.
4. Анализ результатов теста
По завершении выполнения все результаты теста должны быть проанализированы и проверены. Найденные дефекты должны быть отмечены и устранены. Команда тестирования должна получить основную причину обнаруженной ошибки. Они должны быть уверены, что они решены.
5. Повторное тестирование
Отмеченные дефекты должны быть устранены. После того, как команда разработчиков исправит дефект, необходимо убедиться, что тестирование выполнено снова, и весь процесс повторяется. Проблемы теперь должны быть решены.
После выполнения этих действий следует убедиться, что все результаты задокументированы, и ведется запись всех журналов испытаний и результатов испытаний.
Типы тестирования совместимости
Существует пять типов тестирования совместимости
Тип данных Совместимость
Основное внимание уделяется проверке того, что типы данных переносятся из одного типа в другой. При передаче данных между системами не должно быть каких-либо несоответствий данных.
Семантическая совместимость
Этот тип ориентирован на алгоритм, который используется для передачи данных. Он проверяет семантику, которая задействована, и проверяет, надежен ли алгоритм или нет.
Физическая совместимость
Это проверяет, являются ли соединения между двумя или более системами правильными или нет. Используемые порты и кабели не должны влиять на скорость или скорость передачи.
Совместимость протокола
Протокол, который используется для передачи данных, проверяется на безопасность данных. Контрольная сумма должна быть включена для передачи данных без каких-либо ошибок.
Совместимость формата данных
Формат, в котором данные отправляются и принимаются, должен быть одинаковым в обеих системах.
Преимущества и недостатки тестирования совместимости
преимущества
Вот следующие преимущества, упомянутые ниже:
Недостатки
Вот следующие недостатки, упомянутые ниже:
Вывод
Проверка функциональной совместимости очень важна, когда на карту выходит комплексное тестирование системы. Это гарантирует, что все программные компоненты в системе совместимы и могут работать вместе как единое целое. Все различные типы данных, форматы и семантика проверяются заранее. Цель этого тестирования, таким образом, ясна, и в нем также упоминается план тестирования и стратегия, которой необходимо следовать, чтобы выполнить это тестирование.
Рекомендуемые статьи
Фундаментальная теория тестирования
В тестировании нет четких определений, как в физике, математике, которые при перефразировании становятся абсолютно неверными. Поэтому важно понимать процессы и подходы. В данной статье разберем основные определения теории тестирования.
Перейдем к основным понятиям
Тестирование программного обеспечения (Software Testing) — проверка соответствия реальных и ожидаемых результатов поведения программы, проводимая на конечном наборе тестов, выбранном определённым образом.
Цель тестирования — проверка соответствия ПО предъявляемым требованиям, обеспечение уверенности в качестве ПО, поиск очевидных ошибок в программном обеспечении, которые должны быть выявлены до того, как их обнаружат пользователи программы.
Для чего проводится тестирование ПО?
Принципы тестирования
QC (Quality Control) — Контроль качества продукта — анализ результатов тестирования и качества новых версий выпускаемого продукта.
К задачам контроля качества относятся:
К задачам обеспечения качества относятся:
Верификация и валидация — два понятия тесно связаны с процессами тестирования и обеспечения качества. К сожалению, их часто путают, хотя отличия между ними достаточно существенны.
Верификация (verification) — это процесс оценки системы, чтобы понять, удовлетворяют ли результаты текущего этапа разработки условиям, которые были сформулированы в его начале.
Валидация (validation) — это определение соответствия разрабатываемого ПО ожиданиям и потребностям пользователя, его требованиям к системе.
Пример: когда разрабатывали аэробус А310, то надо было сделать так, чтобы закрылки вставали в положение «торможение», когда шасси коснулись земли. Запрограммировали так, что когда шасси начинают крутиться, то закрылки ставим в положение «торможение». Но вот во время испытаний в Варшаве самолет выкатился за пределы полосы, так как была мокрая поверхность. Он проскользил, только потом был крутящий момент и они, закрылки, открылись. С точки зрения «верификации» — программа сработала, с точки зрения «валидации» — нет. Поэтому код изменили так, чтобы в момент изменения давления в шинах открывались закрылки.
Документацию, которая используется на проектах по разработке ПО, можно условно разделить на две группы:
Этапы тестирования:
Программный продукт проходит следующие стадии:
Требования
Требования — это спецификация (описание) того, что должно быть реализовано.
Требования описывают то, что необходимо реализовать, без детализации технической стороны решения.
Отчёт о дефекте (bug report) — документ, который содержит отчет о любом недостатке в компоненте или системе, который потенциально может привести компонент или систему к невозможности выполнить требуемую функцию.
Атрибуты отчета о дефекте:
Жизненный цикл бага
Severity vs Priority
Серьёзность (severity) показывает степень ущерба, который наносится проекту существованием дефекта. Severity выставляется тестировщиком.
Градация Серьезности дефекта (Severity):
Градация Приоритета дефекта (Priority):
Тестовые среды
Основные фазы тестирования
Основные виды тестирования ПО
Вид тестирования — это совокупность активностей, направленных на тестирование заданных характеристик системы или её части, основанная на конкретных целях.
Автор книги «A Practitioner’s Guide to Software Test Design», Lee Copeland, выделяет следующие техники тест-дизайна:
Методы тестирования
Тестирование белого ящика — метод тестирования ПО, который предполагает, что внутренняя структура/устройство/реализация системы известны тестировщику.
Согласно ISTQB, тестирование белого ящика — это:
Тестирование чёрного ящика — также известное как тестирование, основанное на спецификации или тестирование поведения — техника тестирования, основанная на работе исключительно с внешними интерфейсами тестируемой системы.
Согласно ISTQB, тестирование черного ящика — это:
Тестовая документация
Тест план (Test Plan) — это документ, который описывает весь объем работ по тестированию, начиная с описания объекта, стратегии, расписания, критериев начала и окончания тестирования, до необходимого в процессе работы оборудования, специальных знаний, а также оценки рисков.
Тест план должен отвечать на следующие вопросы:
Чаще всего чек-лист содержит только действия, без ожидаемого результата. Чек-лист менее формализован.
Тестовый сценарий (test case) — это артефакт, описывающий совокупность шагов, конкретных условий и параметров, необходимых для проверки реализации тестируемой функции или её части.
Атрибуты тест кейса:
Чек-лист тестирования мобильных приложений
У многих начинающих специалистов в области тестирования возникает вопрос: «А как же протестировать мобильное приложение. С чего начать, какие проверки стоит осуществить?» Данный вопрос актуален, когда они приходят в компанию, где нет документации на проекте, либо это только что появившийся стартап. Чтобы ответить на эти вопросы была подготовлена универсальная шпаргалка, которую можно использовать при тестировании практически любого приложения.
В данный чек-лист вошли только общие характеристики. Естественно, в тестируемом приложении может быть функциональность, для которой нужно применять отдельный подход и создать отдельные сценарии. То же самое верно для производительности, удобства использования, безопасности и прочего тестирования, которое необходимо вашему приложению.
Чек-лист для тестирования мобильных приложений состоит из восьми разделов:
Функциональное тестирование
В данном пункте нам важно убедиться, что наш продукт соответствует нужной функциональной спецификации, упомянутой в документации по разработке.
Что проверяем?
1. Установка/удаление/накатка версий
2. Запуск приложения (отображение Splash Screen)
3. Работоспособность основного функционала приложения
3.1 Авторизация (по номеру телефона/через соц. сети/e-mail)
3.2 Регистрация (по номеру телефона/через соц. сети/e-mail)
3.3 Онбординг новых пользователей
3.4 Валидация обязательных полей
3.5 Навигация между разделами приложения
3.6 Редактирование данных в профиле пользователя
3.7 Проверка оплаты
3.8 Тестирование фильтров
3.9 Бонусы
4. Корректное отображение ошибок
5. Работа с файлами (отправка/получение/просмотр)
6. Тестирование тайм-аутов
7. Тестирование заглушек (не соединения с интернетом/нет, например, товаров и т.д)
8. Тестирование pop-up, алертов
9. Тестирование WebView
10. Скролл/свайп элементов
11. Тестирование PUSH уведомлений
12. Сворачивание/разворачивание приложения
13. Разные типы подключений (сотовая связь/Wi-Fi)
14. Ориентация экрана (альбомная/портретная)
15. Темная/светлая темы
16. Реклама в приложении
17. Шаринг контента в соц. сети
18. Работа приложения в фоне
19. Пагинация страниц
20. Политики конфиденциальности и прочие ссылки на документы
Тестирование совместимости
Тестирование совместимости используется, чтобы убедиться, что ваше приложение совместимо с другими версиями ОС, различными оболочками и сторонними сервисами, а также аппаратным обеспечением устройства.
Что проверяем?
1. Корректное отображение гео
2. Информации об операциях (чеки и т.д.)
3. Различные способы оплаты (Google Pay, Apple Pay)
4. Тестирование датчиков (освещенности, температуры устройства, гироскоп и т.д.)
5. Тестирование прерываний (входящий звонок/смс/push/будильник/режим «Не беспокоить» и т.д.)
6. Подключение внешних устройств (карта памяти/наушники и т.д.)
Тестирование безопасности
Данная проверка нацелена на поиск недостатков и пробелов с точки зрения безопасности приложения.
Что проверяем?
1. Тестирование разрешений (доступ к камере/микрофону/галерее/и т.д.)
2. Данные пользователя (пароли) не передаются в открытом виде
3. В полях, с вводом пароля и подтверждением пароля, данные скрываются астерисками
Тестирование локализации и глобализации
Тестирование интернационализации/глобализации приложения включает тестирование приложения для различных местоположений, форматов дат, чисел и валют, а также замену фактических строк псевдостроками. Тестирование локализации включает тестирование приложения с локализованными строками, изображениями и рабочими процессами для определенного региона.
Что проверяем?
1. Все элементы в приложении переведены на соответствующий язык
2. Тексты зашиты внутри приложения и пользователь в настройках приложения может выставить необходимый язык
3. Тексты зависят от языка в системных настройках
4. Тексты приходят с сервера
5. Корректное отображение форматов дат (ГОД — МЕСЯЦ — ДЕНЬ или ДЕНЬ — МЕСЯЦ — ГОД.)
6. Корректное отображение времени в зависимости от часового пояса
Тестирование удобства использования
Тестирование удобства использования помогает удостовериться в простоте и эффективности использования продукта пользователем, с целью достижения поставленных целей. Иными словами, это не что иное, как тестирование дружелюбности приложения для пользователя.
Что проверяем?
1. Корректное отображение элементов на устройствах с различными разрешениями экранов
2. Все шрифты соответствуют требованиям
3. Все тексты правильно выровнены
4. Все сообщения об ошибках верные, без орфографических и грамматических ошибок
5. Корректные заголовки экранов
6. В поисковых строках присутствуют плейсхолдеры
7. Неактивные элементы отображаются серым
8. Ссылки на документы ведут на соответствующий раздел на сайте
9. Анимация между переходами
10. Корректный возврат на предыдущий экран
11. Поддерживаются основные жесты при работе с сенсорными экранами (swipe back и т.д.)
12. Пиксель-перфект
Стрессовое тестирование
Стрессовое тестирование направлено на определение эффективности производительности приложения в условиях повышенной нагрузки. Стресс-тест в этом контексте ориентирован только на мобильные устройства.
Что проверяем?
1. Высокая загрузка центрального процессора
2. Нехватка памяти
3. Загрузка батареи
4. Отказы
5. Низкая пропускная способность сети
6. Большое количество взаимодействий пользователя с приложением (для этого может понадобиться имитация реальных условий состояния сети)
Кросс-платформенное тестирование
Важный вид тестирования, который необходимо проводить для понимания того, будет ли должным образом отображаться тестируемый продукт на различных платформах, используемых целевой аудиторией.
Что проверяем?
— Работоспособность приложения на различных устройствах разных производителей
Тестирование производительности
Если пользователь устанавливает приложение, и оно не отображается достаточно быстро (например, в течение трех секунд), оно может быть удалено в пользу другого приложения. Аспекты потребления времени и ресурсов являются важными факторами успеха для приложения, и для измерения этих аспектов проводится тестирование производительности.
Что проверяем?
1. Время загрузки приложения
2. Обработка запросов
3. Кэширование данных
4. Потребление ресурсов приложением (например расход заряда батареи)
Поиграть в игру = протестировать игру. Почему это утверждение неверно?
Определение термина и с чего начиналось тестирование игр
Разновидности «игрового» тестирования
Для тестирования видеоигр, как и в других направлениях, есть “стандартные” и свои особенные подходы для решения определённых задач. Давайте рассмотрим их!
Плейтестинг как важная часть обратной связи с вашей аудиторией
Говоря о специфических для видеоигр видов тестирования, я бы выделил такую группу как 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) я писал в своих предыдущих статьях. Вот они: раз, два и три.
Стоит упомянуть, что одни и те же понятия в разных игровых компаниях могут отличаться. Те же «тест кейсы, чеклисты, тот или иной вид тестирования» даже такие стандартные понятия могут называться иначе. Это не плохо и не хорошо, но нужно иметь такую особенность ввиду.
Посмотрите какие виды тестирования используются у вас в компании, сравните их с выше описанными и, если вы не нашли свой подход к тестированию игр тут, дайте знать об этом в комментариях!
