Wie häufig ist automatisiertes Testen in der Spieleentwicklung? [geschlossen]

Verwenden Gamer-Entwickler, um Unit- und Integrationstests zu schreiben? Wie häufig ist es bei Puzzle-Entwicklern? Und unter Entwicklern von MMORPGs und FPS?

(Ich habe keinen Hintergrund in der Spieleentwicklung und denke auch nicht darüber nach, damit zu arbeiten. Es ist nur ein Zweifel, der mir in den Sinn gekommen ist. Es ist also nicht nötig , mich zu überreden , sie zu schreiben, selbst weil ich bereits gerne automatisierte Tests schreibe. )

Im Allgemeinen sind Unit- und Integrationstests von Spielen nicht so verbreitet. Dies liegt hauptsächlich daran, dass der Rendering-Aspekt von Spielen normalerweise eng mit dem Rest der Spielmechanik verknüpft ist, sodass es sehr schwierig sein kann, tatsächlich funktionierende Komponententests zu schreiben.

Das heißt, Unit-Tests können in der Spieleentwicklung stattfinden, und wenn der Code dafür eingerichtet ist, kann dies von großem Nutzen sein. Es kann jedoch weitaus üblicher sein, automatisierte Tests für Spiele zu schreiben, üblicherweise in Form eines KI-Programms, das das Spiel effektiv mit einer höheren Geschwindigkeit als ein normaler Spieler spielen kann. In dieser Frage zum automatisierten Testen gibt es einige ausgezeichnete Geschichten von Entwicklern, die genau das tun . Diese Art des automatisierten Testens ist möglicherweise besser, da Unit-Tests möglicherweise keinen Fehler in der Rendering-Engine erkennen, ein automatisierter Test jedoch mit größerer Wahrscheinlichkeit ein solches Problem aufdeckt.

Letztendlich hängt das alles vom Studio ab. Einige Studios werden eine Art automatisiertes Testen durchführen, während andere im Sommer vielleicht nur 20 Highschool-Kinder einstellen, um ihr Spiel stundenlang zu spielen.

Nach meiner Erfahrung ist es nicht sehr verbreitet.

Meistens finden Unit-Tests nicht statt, da die meisten Spieleentwickler aus einer Zeit und Kultur stammen, als solche Dinge noch nicht weit verbreitet waren. Daher ist es schwierig, jetzt zu argumentieren, dass solche Methoden erforderlich sind. Dies hat sich in den letzten Jahren mit der Erwartung noch verstärkt, dass der Benutzer nach der Veröffentlichung seine eigene Software patchen kann.

Dies liegt zum Teil daran, dass die dominierende Sprache in der Spieleentwicklungsbranche C ++ ist, was das Testen von Units etwas umständlicher macht als andere Sprachen. Unit-Test-Frameworks existieren, sind jedoch nicht so einfach zu verwenden wie ähnliche Systeme in moderneren Sprachen, die mithilfe von Reflexion und ähnlichen Tricks die Erkennung von Testfällen beschleunigen können.

Dies liegt auch daran, dass sich Spiele im Allgemeinen nicht zum Testen von Einheiten eignen - ein Großteil der Logik hängt von semi-deterministischen Quellen ab (z. B. Grafikhardware, Eingabe-Timings, Framerate), ein Großteil der Ausgabe ist schwer zu messen (z. B. Bildschirmgrafiken, Soundeffekte) und einige sind außerhalb des gesamten Spielkontexts (zB komplexe reaktive KI, Physiksimulationen) nahezu bedeutungslos. Es gibt Ausnahmen - viele, wenn Sie hart arbeiten, um den Code auf diese Weise zu erstellen -, aber insgesamt ist das Testen in Spielen teurer als in den meisten anderen Softwaretypen, und daher ist das Kosten-Nutzen-Verhältnis zweifelhafter.

Was Integrationstests angeht, habe ich noch nie davon gehört, dass der Begriff in der Spieleentwicklung ausdrücklich verwendet wird, aber viele Entwickler führen, wo immer möglich, automatisierte Tests des gesamten Systems durch. Ich würde sagen, dass vielleicht jeder dritte Profi dies tut, da es nicht immer einfach ist, es einzurichten, und weil die Vorteile dadurch gemindert werden, dass so ziemlich jeder mittlere bis große Entwickler (oder deren Herausgeber) eine Qualitätssicherung hat Abteilung, die ähnliche Tests manuell durchführt. QA wird in der Regel viel weniger bezahlt als Entwickler, daher kann es als wirtschaftlich angesehen werden, die Tests ihnen zu überlassen, anstatt zusätzliche Codezeit darauf zu investieren. (Umstritten.)

Ich verstehe nicht, wie sich das Schreiben eines Spiels vom Testen von jeder anderen Software unterscheidet. Jede Komponente der Software, ob sie ein zeitgesteuertes Ereignis auslöst, Befehle an einen Spielcharakter sendet oder Menütasten drückt, sollte auf ordnungsgemäße Ausführung geprüft werden.

Das Testen, ob das Spiel abgeschlossen werden kann, ist eine andere Sache und fällt nicht so sehr unter Unit- oder Integrationstests.

Im Allgemeinen ist die Automatisierung von UI-Tests (auch in regulären Programmen) schwieriger als die reguläre Automatisierung. Obwohl Sie Komponententests für Ihre Spiele schreiben können, ist es schwieriger, das eigentliche Spiel zu testen. Die meisten Unternehmen nutzen menschliche Tester, die das Spiel laufen Zeit wieder .

Zum Beispiel hier ist ein Artikel erklären , wie sie es in einem kleinen Game Studio tun (2 Devs). Nach dem, was ich gelesen habe, scheint ihre Validierung nicht sehr detailliert zu sein (Automatisierung startet das Spiel und protokolliert alle Fehler / Behauptungen).

Einige Unternehmen sind jedoch mit Halbautomatisierung sehr erfolgreich (z. B. Microsoft Test Studios). Das heißt, Entwickler oder SDETs erstellen Tools, die das Testen des Spiels erheblich erleichtern. Es gab Gamefest-Gespräche, in denen diskutiert wurde, wie sie beispielsweise Crackdown oder Fable getestet haben . Zum Beispiel verwenden sie immer noch Tester, die überprüfen, ob sich jedes Objekt an dem Ort befindet, an dem es sich befinden soll, aber sie verwenden ein Tool, das einen Schnappschuss von diesem Ort erstellt, sodass der Mensch nur visuell überprüft, ob es vorhanden ist, ohne das Spiel spielen zu müssen.

Hier ist ein guter Vortrag darüber, welche Tools sie zum Testen der Spiele erstellen / verwenden. Es heißt "Test Lead Gems: Raus aus der zunehmenden Komplexität unserer Spiele"

Ich würde wetten, dass MMO- und Multiplayer-Server-Code allerdings etwas öfter getestet wird.

Zumindest sind automatisierte Regressionstests weit verbreitet. Ich habe gesehen, dass dies als Massenprüfung während des Serverstarts implementiert wurde, um zB sicherzustellen, dass ein neuer "Cloud" -Server korrekt konfiguriert wurde, bevor er beginnt, Spieler zu akzeptieren. Eine ziemlich gute Regressionssuite, die über 3-4 Jahre aufgebaut wurde, lief in diesem Fall in ungefähr 4 Sekunden, während das Aufrufen eines virtuellen Hosts (von einem leeren Betriebssystem-Image) fast 10 Minuten dauerte, sodass sich die Zeit wirklich gelohnt hat. Wir haben die gleichen Tests auf einer "Tinderbox" (Continuous Build System) in unserem Subversion-Repository durchgeführt, um zu überprüfen, ob nervige, recht häufige Fehler aufgetreten sind, die sich gerne wieder eingeschlichen haben Duplikate von Objekten erstellen, während sie herumgereicht wurden: Objektinstanziierung, Caching, und der Netzwerk-Passing-Code war nahezu zu 100% abgedeckt; Wir dachten immer, wir hätten an alles gedacht, was getestet werden könnte, und entdeckten dann einen „lustigen“ neuen Edge-Fall.

Bei mehreren MMOs, an denen ich gearbeitet habe, haben wir auch "Stub-Clients" entwickelt, um anfängliche Komponententests durchzuführen, und normalerweise "Operator" -Befehle bereitgestellt, um Ad-hoc-Komponententests für neue Funktionen durchzuführen. Auf diese Weise können wir den Servercode ausführen, bevor der Client bereit war, ihn zu nutzen, und "unmögliche" Situationen (z. B. das Teleportieren eines Spielers innerhalb einer Mauer) ausüben, um sicherzustellen, dass die Fehlerbehebungs-Handler ordnungsgemäß funktionieren. Das Online-Schalten einer neuen Funktion auf dem Server kann unter Umständen viele Tage weniger dauern als der Client-Support. Umgekehrt müssten wir manchmal eine "Dummy" -Servermethode für den Client erstellen, die gefälschte, aber wohlgeformte Daten zurückgibt, wenn sie uns überholen.

Die MMO-Entwicklung im Allgemeinen ist jedoch mit einer Vielzahl solcher Probleme behaftet, die die Umgebung widerspiegeln können. Als ich an eingebetteten Spielesystemen arbeitete, war das „Testen“ für nichts anderes als für wiederverwendbaren Widget-Code (z. B. Texteditoren) ungewöhnlich.

Ein weiterer Grund, warum automatisierte Tests in der Spieleentwicklung nicht so häufig vorkommen, ist, dass es für die meisten Spiele viele freiwillige Betatester gibt, die die Teilnahme an der Spiele-Beta als "Vorteil" betrachten, wenn das Spiel veröffentlicht wird. Das automatisierte Testen ist natürlich aus Qualitätsanforderungen, aber auch aus Budgetbeschränkungen heraus gewachsen. Da es im Gaming-Bereich viele erfahrene Tester gibt, die bereit sind, kostenlos zu testen, ist dies möglicherweise ein weiterer Grund, warum automatisierte Tests nicht so verbreitet sind.

Ich nahm an einer Diskussionsrunde zum Thema automatisiertes Testen auf der GDC 2011 teil . Im IIRC befanden sich ungefähr 60 Personen im Raum. An einem Punkt nahm der Moderator an einer Umfrage zur Berichterstattung über Einheitentests teil. Es gab eine Person , die eine Codeabdeckung von mehr als 90% behauptete. Alle anderen lachten über den Gedanken, jemals 1% zu erreichen Deckung zu erreichen. Wenn diese Gruppe eine faire Repräsentation der Branche als Ganzes ist, würde ich sagen, dass automatisierte Tests im Allgemeinen, wenn überhaupt, nicht viel passieren.

Die anderen Antworten geben gute Gründe, warum. Ich dachte nur, es wäre nützlich, einen Account aus erster Hand zu haben.