Автоматизоване тестування ігор [закрито]

Чи існують методи автоматизованого тестування ігор?

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

Самостійна гра на одну особу. Це була багатокористувацька танкова гра зі зруйнованою місцевістю, і руйнівний код місцевості та зіткнення виявився дещо хитким.

Я закінчився фальсифікацією деяких основних німих AI (маючи на увазі "німий", я маю на увазі "абсолютно ідіотський" - вони випадковим чином обирають "їхати до ворожих танків", "від'їжджати від ворожих танків" та "їхати у випадковому напрямку ", при цьому, випадково стріляючи з основної зброї) та граючи в гру з максимальною швидкістю кадрів під час записування натискання клавіш. Я отримав близько 10-15 разів у режимі реального часу. Код твердо стверджувався, тому, якщо щось пішло не так, він скидає весь журнал натискання клавіш на диск разом зі звітом про помилку та початковим випадковим початком. Тоді я міг би перейти та відтворити журнал натискання клавіш, щоб точно дублювати стан, або просто налагодити звіт про помилку.

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

Це було безцінне, і я щиро рекомендую це.

Для ММО, над яким я працював (100 розробників, орієнтовані на ПК), ми намагалися додати величезну різноманітність автоматизованих тестувань з різним успіхом. Ось що працювало:

• Основні тести під час нашого автоматизованого процесу збирання були величезною перемогою. Сюди входили такі завдання, як створення персонажа, перенесення карт, виконання деяких сценаріїв, призначених для сценаріїв, та пошук очікуваної поведінки. Це застало величезну кількість помилок, перш ніж вони насправді потрапили до решти компанії.
• На кінці серверної інфраструктури ми розробили купу різних автоматизованих тестів, що імітували типові транзакції сервера MMO. Тоді ми можемо відтворити ці дані за різних обставин, щоб порівняти продуктивність або забезпечити безпеку. З часом ці тести ставали все більш точними, поки вони не перетворилися на відтворення записаних у прямому ефірі даних
• Ми написали "фальшивого гравця", який випадковим чином блукатиме по всьому світу, стрибати, вбивати речі та говорити випадкові речі в чаті. Це виявило величезну кількість питань фізики та інфраструктури.

Що не вийшло:

• Ми намагалися додати декілька специфічних бойових орієнтованих автоматизованих тестів до автоматизованого будівельника, але це в принципі ніколи не працювало. Він буде працювати близько 3 днів після його впровадження, поки дизайнер чи художник щось не змінить і тест не вийде, відкинувши сигнали тривоги, що не відбулася. У 90% випадків це не було справжньою проблемою. Ці тести були надто крихкими, і насправді тестування конкретного геймплея на певній карті з конкретними повноваженнями може бути неможливим
• Ми спробували впровадити автоматизований тест продуктивності, який би порівняв продуктивність клієнта (середній FPS тощо) із записаною продуктивністю тижня тому. Це також було досить крихким, оскільки демонстрації, які ми використовували для цього, схильні гнити досить часто, і було важко встановити, якщо уповільнення спричинено фактичною втратою продуктивності або деяким побічним ефектом тестового процесу.

Робота над стратегічною грою в 4 рази з 3D-боєм (думаю, що Homeworld зустрічається з Masters Of Orion), яка, на жаль, ніколи не побачила світла дня, оскільки компанія закінчилася з фінансування ..

Я завжди гарантував, що ви можете грати в гру без людських гравців, щоб ми могли залишити гру біг на ніч.

Ми могли вимкнути 3d бій (спрощений до випадкового результату), і ми залишили двигун стратегії AI, граючи сам. Це виявило численні помилки та проблеми. Показати не лише стоп-помилки, але й стратегічні помилки, де (наприклад, AI-стратегії зайшли б у глухий кут і витратили 1000 тисяч оборотів, не роблячи «правильно». Такі помилки важко було помітити лише «в гру».

Над шутером від першої особи, над яким я працював (Descent 3 - linux / mac / windows, ~ 30 людей у ​​команді в 1999 році), можливість запису / відтворення демо-версії виявилася надзвичайно корисною. Я зробив варіант, коли ви могли відтворювати демонстрацію так швидко, як гра могла відтворювати кадри, і це стало чудовим способом перевірити продуктивність після того, як маса речей змінилася.

Він також використовував багато коду поза системою візуалізації, тож це була хороша перевірка правильності. Внісши зміни, я міг просто запустити демонстрацію демо 10 хвилин гри. Багато разів це потрапило б у місцевість, де я б не думав перевіряти себе.

У нас був шутер відкритого світу (x360, PS3, ПК), який використовував швидкий димовий сервер на сервері збірки - він завантажив гру, перейшов через передню частину, побіг [аватар] вперед, скинув скріншот і вийшов. Якщо cctray виявив чистий вихід, збірка була успішною.

Ми провели його приблизно за останній рік проекту, і розмір команди склав ~ 100 дев.

Це було ефективно при лові виставкових помилок, але було легко створити збірку, яка пройшла найдимніший, але не вдалася до більшості "реальних" рівнів, або не працювала в мультиплеєрі, або плекала AI, так що це не було ідеально. Це, безумовно, варто було зробити.

Я чув, як я покинув, що вони почали виконувати більш широкий спектр закупок, вироблених на декількох ПК. Очевидно, що підтримка димових закупівель є проблемою, і є невелика команда, яка присвячена тому, щоб просто підтримувати сервери збирання та програмне забезпечення, тому я не можу сказати, успішно це чи ні.

Мій досвід автоматизованого тестування під час розробки Crysis 2 доступний тут: http://yetagethergameprogrammingblog.blogspot.com/2010/06/aaa-automated-testing.html

Підсумок:

• Автоматизоване тестування покращило стабільність результатів, підвищивши продуктивність як для творців вмісту, так і для інженерів
• Автоматизоване тестування - це ефективний інструмент для поліпшення якості коду та зменшення шансів на роботу понаднормово
• Ігрова індустрія загалом є дуже реакційною, автоматизоване тестування відповідає декільком ірраціональним аргументам проти
• Не називайте це тестуванням, називайте його чимось іншим, майже будь-яким іншим (Дивіться на поведінку, керовану розвитком)
• Бути гнучким, писати хороші тести важко і вимагати навичок, які широко не доступні в ігровій індустрії

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

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

Що досить складно, очевидно. Тактики, які працюють над іншими програмами (плавлення, очікуваний пропуск / очікуваний збій тощо), тут не так добре працюють. У системах, написаних на скриптах, схоже, що скласти тестовий набір сценаріїв для імітації гравця - це шлях (див. Відповідь JZig). Але тестування спеціально для предметів, на які може зіткнутися гравець, прямо вважає мене найкращим місцем, щоб зосередити свій час як на людських, так і на автоматизованих тестування.