🧩Тестування за підходами

Що таке тестування гри? Типи тестування

Тестування ігор - це процес тестування програмного забезпечення для тестування ігор з метою контролю якості. Основною метою тестування гри є виявлення дефектів та помилок в іграх для підвищення стабільності і продуктивності. Тестування ігор - це компонент розробки ігор, який допомагає забезпечити відсутність помилок у розгортанні гри.

Тип тестування гри — це класифікація різних дій тестування за категоріями, кожна з яких має визначену мету тестування, стратегію тестування та результати тестування. Метою типу тестування є перевірка гри, що тестується для визначеної цілі тестування.

Типи тестування умовно можна розділити на 3 категорії:

• Тестування за підходами (Test Approaches)

• Тестування за рівнем (Test Levels)

• Тестування за метою (Test Objectives)

Тестування за підходами

Розглянемо тестування за підходами. Вони бувають наступними:

Ручне або автоматизоване (Manual vs Automated)

При ручному тестуванні (manual testing) тестувальники виконують вручну тести, не використовуючи жодних засобів автоматизації. Ручне тестування – найнижчий та найпростіший тип тестування, що не потребує великої кількості додаткових знань.

Автоматизоване тестування передбачає використання спеціального програмного забезпечення (крім тестованого) для контролю виконання тестів та порівняння очікуваного фактичного результату роботи програми. Цей тип тестування допомагає автоматизувати завдання, що часто повторюються, але необхідні для максимізації тестового покриття.

Існує кілька основних видів автоматизованого тестування:

– автоматизація тестування коду (Code-driven testing) – тестування на рівні програмних модулів, класів та бібліотек (фактично автоматичні юніт-тести);

– автоматизація тестування графічного користувальницького інтерфейсу (Graphical user interface testing) – спеціальна програма (фреймворк автоматизації тестування) дозволяє генерувати події користувача – натискання клавіш, кліки мишкою, і відстежувати реакцію програми на ці дії – чи відповідає вона специфікації.

- Автоматизація тестування API (Application Programming Interface) - програмного інтерфейсу програми. Тестуються інтерфейси, призначені для взаємодії, наприклад, з іншими програмами або користувачем. Тут знову ж таки, як правило, використовуються спеціальні фреймворки.

Проактивне та реактивне (Proactive vs Reactive)

Реактивне тестування передбачає реакцію на проблему коли вона виникає замість того, щоб її попередити. Цей вид тестування застосовується тоді, коли у нас готовий дизайн гри і вже завершене кодування, тобто ми маємо готову гру, яку потрібно тестувати.

Проактивне тестування навпаки застосовується наперед, ще до того, як почнеться кодування та дизайн гри, тобто на етапі аналізу вимог. Саме з тестування вимог ми і починаємо проактивне тестування з метою виявлення помилок на ранній стадії розробки, щоб у майбутньому мінімізувати можливі дефекти.

Black-, White- and Grey-box

Black box

Summary: Ми не знаємо, як влаштована система, що тестується

Тестування методом «чорного ящика», також відоме як тестування, засноване на специфікації або тестування поведінки – техніка тестування, заснована на роботі виключно з зовнішніми інтерфейсами тестованої гри.

Чому саме «чорний ящик»? Гра, що тестується, для тестувальника – як чорний непрозорий ящик, змісту якого він не бачить. Метою цієї техніки є пошук помилок в таких категоріях:

• – Неправильно реалізовані або відсутні функції гри;

• – Помилки інтерфейсу;

• – Помилки в структурах даних або організації доступу до зовнішніх баз даних;

• – Помилки поведінки або недостатня продуктивность системи.

Таким чином, ми не маємо уявлення про структуру та внутрішній пристрій системи. Потрібно концентруватися на тому, що програма робить, а не на те, як вона це робить.

Приклад:

Тестувальник проводить тестування гри, не знаючи особливостей її реалізації, використовуючи тільки передбачені розробником кнопки. Джерело очікуваного результату – специфікація.

White Box

Summary: Нам відомі всі деталі реалізації програми, що тестується.

Тестування методом білого ящика (також: прозорого, відкритого, скляного ящика; засноване на коді або структурне тестування) – метод тестування гри, який передбачає, що внутрішня структура/пристрій/реалізація системи відомі тестувальнику. Ми вибираємо вхідні значення, грунтуючись на знанні коду, який буде їх обробляти. Точно так само ми знаємо, яким повинен бути результат цієї обробки. Знання всіх особливостей тестованої гри та її реалізації – обов’язкові для цієї техніки. Тестування білого ящика – поглиблення у код системи, за межі її зовнішніх інтерфейсів.

Чому «білий ящик»? Програма, що тестується, для тестувальника – прозорий ящик, вміст якого він чудово бачить.

Приклад:

Тестувальник, який, як правило, є програмістом, вивчає реалізацію коду поля введення в грі для зміни імені гравця, визначає всі передбачені (як правильні, так і неправильні) і не передбачені користувальницькі вводи, і порівнює фактичний результат виконання програми з очікуваним. При цьому очікуваний результат визначається саме тим, як повинен працювати код програми.

Grey Box

Summary: Нам відомі тільки деякі особливості реалізації тестової системи.

Тестування методом сірого ящика – метод тестування гри, який передбачає, комбінацію White Box і Black Box підходів. Тобто, внутрішній устрій гри нам відомий лише частково. Передбачається, наприклад, доступ до внутрішньої структури та алгоритмів роботи гри для написання максимально ефективних тест-кейсів, але саме тестування проводиться за допомогою техніки чорного ящика, тобто, з позиції користувача.

Цю техніку тестування також називають методом напівпрозорого ящика: щось ми бачимо, а щось – ні.

Приклад:

Тестувальник вивчає код програми з тим, щоб краще розуміти принципи її роботи і вивчити можливі шляхи її виконання. Таке знання допоможе написати тест-кейс, який напевно буде перевіряти певну функціональність.

Техніка сірого ящика може застосовуватися на різних рівнях тестування – від модульного до системного, але головним чином застосовується на інтеграційному рівні для перевірки взаємодії різних модулів гри.

Позитивне і Негативне (Positive vs Negative)

Позитивне тестування – це тестування із застосуванням сценаріїв, які відповідають нормальній (штатній, очікуваній) поведінці системи. З його допомогою ми можемо визначити, що гра робить те, для чого і була створена. Наприклад, після кліку на кнопку Налаштувань відкривається вікно з налаштуваннями гри.

Негативним називають тестування, в рамках якого застосовуються сценарії, які відповідають позаштатній поведінці тестованої системи. Це можуть бути, наприклад, виняткові ситуації або невірні дані. Наприклад, при матчуванні тайлів два-в-ряд збирається комбінація і зникають +2 тайлика. Звісно, що це баг, так як ми очікували, що тайлики не будуть збиратись два в ряд, адже згідно специфікації тайлики мають збиратись лише три в ряд.

Перш за все негативне тестування направлено на перевірку стійкості системи до різних впливів, валідації невірних даних, обробки виняткових ситуацій. Сценарії позитивного тестування, в свою чергу, спрямовані на перевірку роботи системи з тими типами даних, для яких вона розроблялася.

Створення позитивних сценаріїв (тест-кейсів), як правило, передує створенню негативних тест-кейсів. Спочатку ми перевіряємо роботу системи, коли наш умовний користувач працює з системою "правильно", а потім приступаємо до перевірки відгуку системи на користувача, який допускає різні помилки (введення невірних даних, наприклад). І наша система повинна бути готова відповісти на невірний запит. Це і є мета негативного тестування.

Верифікація і Валідація (Verification vs Validation)

Верифікація (Verification) – це статична практика перевірки документів, дизайну, архітектури, коду тощо. Тобто ми перевіряємо, чи відповідає гра або частина гри вимогам та технічним завданням.

Валідація (validation) – це процес оцінки кінцевого продукту, необхідно перевірити, чи гра відповідає очікуванням та вимогам клієнта. Це динамічний механізм перевірки та тестування фактичного продукту.

З документацією та без документації (Scripted vs Unscripted)

Тестування за сценарієм – це тип тестування гри, який виконується шляхом упорядкування деталей усіх технічних завдань і планування. Команда тестування належним чином планує тестування за сценарієм і пише тестовий сценарій. Сценарій тестування — це набір правил, задіяних фаз і різних етапів процесу тестування.

Тестування без сценарію — це тип тестування гри, у якому тестувальник може вибрати будь-яку можливу методологію для тестування гри. Під час тестування без сценарію розробники гри використовують свої особисті знання, знання, навички та здібності для тестування гри, розроблені власноруч.

Різниця між тестуванням за сценарієм і без нього:

Тестування за сценарієм
Для тестування гри використовується звичайна методологія.	Тестер може вільно використовувати будь-яку методологію для тестування гри.
Попередній досвід і досвід досліджень використовуються для цілей тестування.	Для тестування тестувальник використовує власні знання, уміння та навички.
Тестування за сценарієм вимагає надання належної документації.	Під час тестування без сценарію документація не потрібна.
У сценарному тестуванні готується тестовий сценарій.	У тестуванні без сценарію не готується тестовий сценарій.
Потрібна велика підготовка.	Підготовка не потрібна.
Гра порівнюється зі стандартами та специфікаціями.	Гра порівнюється з очікуваннями тестувальника.
Можна легко відтворити.	Лише дефекти можна відтворити.
Потрібно багато часу.	Потрібно менше часу.