Наскільки поширене автоматизоване тестування в розробці ігор? [зачинено]

Чи використовують розробники геймерів для написання тестів на одиниці та інтеграцію? Наскільки це поширене серед розробників головоломок? А серед розробників MMORPG та FPS?

(Я не маю передумов у розробці ігор, і я не беруся над тим, щоб працювати з нею - це просто сумніви, які виникли у мене. Отже, не потрібно намагатися переконувати мене написати їх, навіть тому, що я вже люблю писати автоматизовані тести. )

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

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

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

На мій досвід, це не дуже часто.

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

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

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

Щодо тестування інтеграції, я ніколи не чув, щоб термін явно використовувався в розробці ігор, але багато розробників проводять автоматизовані тести всієї системи, де це можливо. Гадаю, я можу сказати, що, можливо, кожен третій розробник Pro робить це, оскільки це не завжди просто налаштувати, а тому що переваги зменшуються тим, що майже кожен середній та великий розробник (або їхній видавець) має QA відділ, який буде виконувати аналогічні тести вручну. За якість QA зазвичай платять набагато менше, ніж розробники, тому можна вважати економічним залишити тестування на них, а не вкладати в нього додатковий час. (Суперечливий.)

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

Тестування, чи можна завершити гру, є іншою справою і не підпадає під тестування одиниці чи інтеграції.

Загалом автоматизація тестування інтерфейсу (навіть у звичайних програмах) важче, ніж звичайна автоматизація. Тож хоч ви можете писати одиничні тести для своїх ігор, протестувати фактичну гру складніше. Більшість компаній використовують людські тестери, які запускають ігровий час і знову.

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

Однак деякі компанії є дуже успішними з напівавтоматизацією (наприклад, Microsoft Test Studios). Тобто розробники або SDET створюють інструменти, які значно спрощують тестування гри. Там відбулися бесіди Gamefest, де вони обговорювали те, як протестували Crackdown наприклад, Fable. Наприклад, вони все ще використовують тестери, які підтверджують, що кожен об'єкт знаходиться там, де він повинен бути, але вони використовують інструмент, який робить знімок цього місця, щоб все, що робить людина, візуально перевіряв, чи є він там, не граючи в гру.

Ось хороша розмова про те, які інструменти вони будують / використовують для тестування ігор. Це називається "Тестові дорогоцінні дорогоцінні камені: вихід із-перед все більшої складності наших ігор"

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

Принаймні, поширені автоматичні тести регресії. Я бачив, що вони реалізуються як масові перевірки рівня безпеки під час запуску сервера, наприклад, щоб переконатися, що новий «хмарний» сервер був правильно налаштований, перш ніж він починає приймати гравців; досить хороший набір регресії, розроблений протягом 3-4 років, у цьому випадку пробіг приблизно за 4 секунди, тоді як виведення віртуального хоста (із зображення пустого ОС) зайняло майже 10 хвилин, тому варто було витратити час. Ми проводили ті ж тести на "tinderbox" (система постійної збірки) у нашому сховищі Subversion, щоб перевірити наявність набридливих, досить поширених помилок, які хотіли повзати назад. Зокрема, функціонал мультисервера мав жахливу звичку намагатися створювати дублікати об'єктів під час їх передачі: інстанція об'єкта, кешування, а код передачі мережі був майже на 100%; ми продовжували думати, що подумали про все, що можна було б перевірити, а потім відкрили для себе якийсь «веселий» новий край край.

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

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

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

Я брав участь у круглому столі, присвяченому автоматизованому тестуванню на GDC 2011 . ІІРК, в кімнаті було близько 60 осіб. В один момент модератор провів опитування покриття тестування одиниці. Була одна людина, яка заявляла про покриття коду понад 90%. Всі інші сміялися з думки про те, щоб коли-небудь досягти 1% охоплення. Якщо ця група є справедливим представленням галузі в цілому, я б сказав, що автоматичного тестування зазвичай не буває багато, якщо взагалі.

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