Прибуток:
- Здатність розуміти функціональний, регресійний, крайовий і краш-тести рівнів і створювати тестові сценарії та списки крайових випадків за допомогою штучного інтелекту
- Можливість прискорити налагодження шляхом написання автоматичного тестового коду за допомогою штучного інтелекту та вилучення шаблонів у журналі та аналізі збоїв
- Можливість зрозуміти, що діагностика помилок штучного інтелекту – це не доказ, а гіпотеза, причину потрібно довести за допомогою журналів і відтворення, а також важливість відтворюваності звіту про помилку.
Коли гра виходить, гравці грають у неї так, як розробник не міг уявити: застрягають у стінах, використовують інвентар, досягають неможливих місць, викликають збої. Забезпечення якості (QA — quality assurance); Це процес систематичного тестування гри перед випуском, пошуку та виправлення помилок (багів), збоїв, нестабільності та поганого досвіду. Це одна з найбільш трудомістких, але критичних ланок у виробництві ігор. AI прискорює перевірку якості в багатьох моментах: створення тестів, аналіз звітів про помилки, перегляд журналів, автоматичне написання тестового коду, налагодження та вдосконалення етапів виробництва. Але штучний інтелект не замінює інтуїцію тестувальника та оцінку відчуття від гри.
У цьому розділі ви дізнаєтеся, як використовувати штучний інтелект для забезпечення якості та налагодження; Ви дізнаєтесь про розробку тестового сценарію, аналіз журналу, автоматичне написання тесту та дисципліну звітування про помилки.
Рівні QA та місце ШІ
QA є багаторівневим. Функціональне тестування: чи працює функція (чи відкриваються двері, чи завантажується запис). Регресійне тестування: чи нова зміна порушила те, що працювало раніше? Перевірка граничного випадку: незвичні введення (скидання інвентарю, два ключі одночасно, граничні значення). Тестування продуктивності/збоїв: чи стабільна гра. Ігровий процес/тест на досвід: веселий, інтуїтивно зрозумілий. ШІ сильний у перших чотирьох: генерація сценаріїв, перелік граничних випадків, написання тестового коду, аналіз журналів. Останнє — досвід — належить людині.
Крок за кроком:
- Створюйте тестові випадки (функціональний і крайовий список випадків за допомогою ШІ).
- Напишіть автоматизоване тестування (код для повторних перевірок).
- Запускай і збирай (реєструвати помилки, журнали, збої).
- Аналіз (вивчіть журнал і шаблон помилок за допомогою ШІ).
- Повідомте та перевірте (чіткий, відтворюваний звіт про помилку; тестове виправлення).
Підказка: Важко знайти крайові випадки, тому що дизайнер грає свою гру «правильно». Запитайте ШІ «що б спробував гравець, якби захотів зламати цю систему?» Список експлойтів і крайніх випадків.
Автоматичне тестування: залиште повторення машині
Ручне тестування одних і тих самих речей у кожному випуску втомлює та може викликати помилки. Автоматизоване тестування вводить ці перевірки в код: чи повертає функція правильний результат кожного разу, коли її викликають, чи система в очікуваному стані. Unity та Unreal пропонують фреймворки тестування; ШІ швидко пише ці тести. Це особливо цінно для регресії: якщо зміна порушує те, що працювало раніше, тест стає червоним. Перегляньте тести, які проводить штучний інтелект, переконавшись, що вони перевіряють те, що є справді значущим — порожній тест гірший, ніж відсутність тесту.
Застереження: під час налагодження ШІ іноді створює вигадане пояснення як «ймовірну причину» (галюцинація). Не визнавайте причину помилки лише тому, що це сказав вам ШІ; Доведіть причину шляхом реєстрації, відтворення та тестування. Помилковий діагноз затримує пошук правильного.
Відтворення: серце налагодження
Першою вимогою для виправлення помилки є надійне її відтворення. Помилка, описана як "іноді трапляється", не може бути виправлена, оскільки ви не можете перевірити, чи спрацювало виправлення. Отже, найцінніша робота з усунення помилок — це звуження точних умов, за яких виникає помилка (які кроки, яка ситуація, який час). ШІ допомагає звузити це: ви можете надати симптоми та часткові етапи відтворення та сказати «запропонуйте умови та стратегію звуження, які можуть викликати таку поведінку». Але насправді ви виконуєте звуження, запускаючи гру; ШІ генерує гіпотези, ви їх усуваєте.
Особливо підступними є помилки, пов’язані з синхронізацією (стан змагання) і станом пам’яті; вони відбуваються лише в певній послідовності або навантаженні. Для таких помилок важливо додати позначку часу та інформацію про статус до журналу; ШІ може проаналізувати цей насичений журнал і побачити шаблон («помилка завжди виникає, коли ці дві події відбуваються нещодавно»). Пам’ятайте про золоте правило налагодження: спочатку зрозумійте, потім виправляйте. Виправлення без розуміння приховує помилку, але не вирішує її і часто створює нову помилку в іншому місці.
три міні-чохла
Випадок 1 — пошук крайніх випадків. У рольовій грі команда випробувала систему інвентаризації в «нормальному» ігровому процесі та вважала її надійною. Вони змусили штучний інтелект сказати «спробуйте зламати цей інвентар» і створили 30 крайніх сценаріїв; 4 з них були справжніми помилками (0 розділення ваги предметів, одноразове використання). Виправлено перед публікацією.
Випадок 2. Аналіз журналу вирішив збій. Гра випадково вилітала; журнали збоїв містили сотні рядків. Коли штучному інтелекту надали журнали та запитали шаблон, виявилося, що збій завжди відбувався під час переходу певної сцени та браку пам’яті. За допомогою цієї підказки програміст знайшов витік пам'яті; Частота аварій впала до нуля.
Випадок 3 — Повернення після неправильного діагнозу. Програміст довірився поясненню штучного інтелекту про те, що «ця помилка спричинена цією функцією», і возився з нею півдня; результатів не вийшло. Коли він уточнив і знову занотував етапи виробництва, помилка була зовсім в іншому місці. Урок: Діагностика ШІ – це гіпотези, а не докази.
Чотири шаблони, які можна копіювати
1) Генерація крайнього випадку/сценарію експлуатації:
Ваша роль: тестувальник якості шкідливих програм. Я описую таку систему: [система, правила]. Завдання: перелічіть 20 граничних сценаріїв, які намагатимуться зламати, використовувати або кинути цю систему в неочікуваний стан. Для кожного: що спробувати, очікуваний результат, можлива помилка.
2) Автоматизоване написання тесту:
Двигун: [Unity 2022.3 / Unreal 5.3]. Інфраструктура тестування: [укажіть]. Напишіть автоматизовані тести для такої функції/системи: [опис/код]. Включіть звичайний випадок, граничний випадок і помилковий вхід. Переконайтеся, що кожен тест перевіряє щось справді значуще; Написання порожніх/безглуздих тестів.
3) Аналіз журналу/збою:
Нижче наведено журнали збоїв/помилок гри: [журнал]. Завдання: позначити повторювані шаблони, загальні умови (сцена, пам’ять, час) і можливі першопричини. Подайте кожну причину як «гіпотезу, яку потрібно підтвердити»; говорити чітко. Також підкажіть, як перевірити.
4) Пояснення звіту про помилку:
Зробіть такий нечіткий звіт про помилку зрозумілим і придатним для відтворення: [необроблений звіт]. Вихідні дані: назва, покрокове відтворення, очікуваний результат, фактичний результат, частота, середовище. Якщо інформації бракує, вкажіть, яка інформація потрібна.
Слабка підказка / Сильна підказка
Слабка підказка:
У моїй грі є помилка, виправте її.
Ні контексту, ні журналу, ні відтворення; ШІ є передбачуваним, і ризик галюцинацій високий.
Потужна підказка:
У моїй грі Unity 2022.3 є помилка: інвентар іноді подвоюється, коли гравець виконує швидке збереження та завантаження. Відтворення: [кроки]. Пов’язаний код: [вставити]. Журнал: [вставити]. Завдання: перелічіть можливі першопричини як гіпотези, які потрібно підтвердити, вкажіть, як перевірити та можливе вирішення для кожної. Придумайте неіснуючу причину; Якщо ви не впевнені, дайте мені знати.
Відтворення, код, журнал і запит «подати як гіпотезу» роблять діагноз надійним.
Таблиця рівня якості
шар
Що він перевіряє?
внесок ШІ
людська частка
функціональний
Функція працює?
Скрипт, тестовий код
Рішення про прийом
регресія
Стара річ зламалася?
автоматичний тест
Рішення про обсяг
крайній випадок
незвичайний вхід
Виробництво сценарію
пріоритет
Збій/продуктивність
рішучість
Аналіз журналу
Підтвердження першопричини
Досвід
розвага, інтуїція
обмежений
цілком людський
Поширені помилки
- Просто тестую «нормальний» геймплей. Граничні випадки вибухають після випуску.
- Помилковий діагноз ШІ як доказ. Чому це доведено журналом і тестуванням.
- Написання порожніх автоматизованих тестів. Безглузде тестування створює ілюзію впевненості.
- Розпливчастий звіт про помилку. Невідтворювана помилка не може бути виправлена.
- Пропуск регресійного тестування. Кожне виправлення може викликати нові помилки.
Підсумовуючи
QA — це дисципліна, яка робить гру готовою для гравця. ШІ; створює крайові сценарії, записує автоматизовані тести, аналізує журнали та уточнює звіти про помилки. Але їхні діагнози — гіпотези, оцінка досвіду — людська, і кожне виправлення потребує повторної перевірки. Повторіть рефлекс «хто може це зламати і як» за допомогою ШІ; Ви збираєте докази.
Аплікаційне завдання
Виберіть систему зі своєї гри. Згенеруйте 20 сценаріїв за допомогою шаблону «Генерація сценарію крайнього випадку/експлуатації» та перевірте 5 найризикованіших. Створіть відтворюваний звіт про знайдену помилку за допомогою шаблону «Уточнення звіту про помилку».
контрольний список
- [ ] Я створив крайовий випадок із запитом "Хто може зламати це і як?"
- [ ] Написав і перевірив автоматизоване тестування для повторюваних перевірок.
- [ ] Я розглядав діагноз ШІ як гіпотезу та довів це за допомогою журналу/тесту.
- [ ] Я повідомляв про помилки відтворюваним чином.
- [ ] Я повторно перевірив кожне виправлення на регресію.