Jak powszechne są automatyczne testy w tworzeniu gier? [Zamknięte]

Czy programiści używają gier do pisania testów jednostkowych i integracyjnych? Jak często występuje wśród twórców puzzli? A wśród twórców gier MMORPG i FPS?

(Nie mam doświadczenia w tworzeniu gier, ani też nie zastanawiam się nad tym, żeby z tym pracować - to tylko wątpliwość, która mi się przydarzyła. Nie muszę więc próbować mnie przekonywać do pisania, nawet dlatego, że lubię pisać testy automatyczne. )

Ogólnie rzecz biorąc, testy jednostkowe i integracyjne gier nie są tak powszechne. Wynika to głównie z faktu, że aspekt renderowania gier jest zwykle ściśle powiązany z resztą mechaniki gry, dlatego napisanie testów jednostkowych, które działają, może być bardzo trudne.

To powiedziawszy, testowanie jednostek może się zdarzyć podczas tworzenia gry, a jeśli kod jest skonfigurowany do tego, może to być bardzo korzystne. Jednak może być o wiele bardziej powszechne pisanie automatycznych testów gier, zwykle w formie programu AI, który może efektywnie grać w grę z większą prędkością niż normalny gracz. Jest kilka doskonałych historii o tym, że programiści robią to właśnie w tym pytaniu o automatycznych testach . Tego rodzaju automatyczne testowanie jest potencjalnie lepsze, ponieważ testy jednostkowe mogą nie wykryć błędu w silniku renderującym, ale bardziej prawdopodobne jest, że automatyczny test ujawni taki problem.

Ostatecznie jednak wszystko zależy od studia. Niektóre studia przeprowadzą pewnego rodzaju automatyczne testy, podczas gdy inne mogą po prostu zatrudnić 20 licealistów latem, aby grały w nie przez wiele godzin.

Z mojego doświadczenia nie wynika to zbyt często.

Przeważnie testy jednostkowe nie są przeprowadzane, ponieważ większość twórców gier wywodzi się z przeszłości i kultury, zanim takie rzeczy były szeroko rozpowszechnione, dlatego trudno jest teraz argumentować, że takie metody są konieczne. Stało się to jeszcze bardziej prawdziwe w ostatnich latach w oczekiwaniu, że użytkownik będzie mógł łatać własne oprogramowanie po wydaniu.

Częściowo dzieje się tak dlatego, że dominującym językiem w branży tworzenia gier jest C ++, co sprawia, że ​​testowanie jednostek jest nieco bardziej skomplikowane niż w przypadku innych języków. Struktury testów jednostkowych istnieją, ale nie są tak łatwe w użyciu, jak podobne systemy w bardziej nowoczesnych językach, które mogą używać refleksji i podobnych sztuczek, aby przyspieszyć wykrywanie przypadków testowych.

Również dlatego, że gry zazwyczaj nie poddają się testom jednostkowym - duża część logiki zależy od źródeł pół-deterministycznych (np. Sprzęt graficzny, czasy wejściowe, częstotliwość klatek), duża część wyników jest trudna do zmierzenia (np. grafika na ekranie, efekty dźwiękowe), a niektóre są prawie bez znaczenia poza pełnym tworzeniem kontekstu gry (np. złożona reaktywna AI, symulacje fizyki). Są wyjątki - wiele, jeśli ciężko pracujesz, aby kod był w ten sposób - ale ogólnie testowanie jest droższe w grach niż w większości innych rodzajów oprogramowania, więc stosunek kosztów do korzyści jest bardziej wątpliwy.

Jeśli chodzi o testy integracyjne, nigdy nie słyszałem o tym, aby termin ten był wyraźnie używany w rozwoju gier, ale wielu programistów przeprowadza automatyczne testy całego systemu, jeśli to możliwe. Domyślam się, że może 1 na 3 programistów robi to, ponieważ nie zawsze jest to łatwe do skonfigurowania i ponieważ korzyści są zmniejszone przez fakt, że prawie każdy średni lub duży programista (lub ich wydawca) ma kontrolę jakości dział, który ręcznie wykona podobne testy. Za kontrolę jakości zazwyczaj płaci się znacznie mniej niż programistów, dlatego może być uważane za ekonomiczne pozostawienie testowania, zamiast inwestowania dodatkowego czasu na kod. (Kontrowersyjny.)

Nie rozumiem, jak pisanie gry różni się od innych programów pod względem testowania. Każdy element oprogramowania, niezależnie od tego, czy wyzwala zdarzenie czasowe, wysyła polecenia do postaci w grze, czy naciska przyciski menu, powinien zostać przetestowany pod kątem prawidłowego wykonania.

Testowanie, czy gra jest możliwa do ukończenia, to inna sprawa i nie podlega tak bardzo testom jednostkowym, ani integracyjnym.

Ogólnie automatyzacja testów interfejsu użytkownika (nawet w zwykłych programach) jest trudniejsza niż zwykła automatyzacja. Więc nawet jeśli potrafisz pisać testy jednostkowe dla swoich gier, testowanie rzeczywistej gry jest trudniejsze. Większość firm korzysta ludzkie testerów, które uruchomić grę raz po raz.

Na przykład Oto artykuł wyjaśniający, jak to robią w małym Game Studio (2 deweloperów). Z tego, co przeczytałem, wydaje się, że ich walidacja nie jest bardzo szczegółowa (automatyzacja uruchamia grę i rejestruje wszelkie błędy / stwierdzenia).

Jednak niektóre firmy odnoszą duże sukcesy dzięki półautomatyce (np. Microsoft Test Studios). Oznacza to, że programiści lub SDET tworzą narzędzia, które znacznie ułatwiają testowanie gry. Odbywały się rozmowy Gamefest, podczas których dyskutowali o tym, jak przetestowali Crackdown na przykład lub Fable. Na przykład nadal używają testerów, którzy sprawdzają, czy każdy obiekt jest tam, gdzie powinien być, ale używają narzędzia, które robi migawkę z tej lokalizacji, dzięki czemu wszystko, co robi człowiek, to wizualna weryfikacja, że ​​tam jest, bez konieczności grania w grę.

Oto dobre omówienie tego, jakie narzędzia budują / używają do testowania gier. Nazywa się to „Klejnotami ołowiu testowego: wychodzenie naprzeciw rosnącej złożoności naszych gier”

Założę się, że kod serwera MMO i multiplayer jest jednak nieco częściej testowany.

Przynajmniej powszechne są automatyczne testy regresji. Widziałem je zaimplementowane jako masowe kontrole poczytalności podczas uruchamiania serwera, aby np. Upewnić się, że nowy serwer „w chmurze” został poprawnie skonfigurowany, zanim zacznie akceptować graczy; dość dobry pakiet regresji zbudowany przez 3-4 lata, w takim przypadku działał w ciągu około 4 sekund, a uruchomienie wirtualnego hosta (z pustego obrazu systemu operacyjnego) zajęło prawie 10 minut, więc było warto. Przeprowadziliśmy te same testy na „tinderboksie” (system ciągłej kompilacji) w naszym repozytorium Subversion, aby sprawdzić irytujące, dość częste błędy, które lubiły się z powrotem wkradać. W szczególności funkcjonalność wielu serwerów miała nieprzyjemny zwyczaj próbować tworzyć duplikaty obiektów w miarę ich przekazywania: tworzenie instancji obiektu, buforowanie, a kod sieciowy został objęty prawie w 100%; ciągle myśleliśmy, że pomyśleliśmy o wszystkim, co można przetestować, a następnie odkryliśmy „zabawną”, nową skrzynkę.

W kilku MMO, nad którymi pracowałem, opracowywaliśmy również „klientów pośredniczących” do przeprowadzania wstępnych testów jednostkowych i zwykle udostępnialiśmy polecenia „operatora” do przeprowadzania testów jednostkowych ad hoc nowych funkcji. Pozwoliło nam to wykonać kod serwera, zanim klient był gotowy go wykorzystać, i wykonać sytuacje „niemożliwe” (np. Teleportowanie gracza do ściany), aby upewnić się, że procedury usuwania błędów działają dobrze. Uruchomienie nowej funkcji online na serwerze może czasem zająć wiele dni krócej niż obsługa klienta; i odwrotnie, czasami musielibyśmy stworzyć „pozorną” metodę serwera dla klienta, zwracającą fałszywe, ale dobrze sformułowane dane, jeśli wyprzedzą nas.

Jednak ogólnie rzecz biorąc, rozwój MMO podlega znacznie więcej tego rodzaju problemów, które mogą odzwierciedlać środowisko. Kiedy pracowałem nad wbudowanymi systemami gier, „testowanie” było praktycznie niespotykane w niczym innym, jak tylko kod wielokrotnego użytku (np. Edytory tekstu).

Innym powodem, dla którego automatyczne testowanie nie jest tak powszechne w tworzeniu gier, które można wziąć pod uwagę, jest to, że w większości gier jest wielu ochotników testujących Beta, którzy przed uczestnictwem w grze biorą udział jako „przewaga”. Automatyczne testy wyrosły oczywiście z wymagań jakościowych, ale także z ograniczeń budżetowych. Dlatego, ponieważ w grach jest wielu doświadczonych testerów, którzy są gotowi do testowania za darmo, być może jest to kolejny powód, dla którego automatyczne testy nie są tak powszechne.

Brałem udział w dyskusji przy okrągłym stole na temat automatycznych testów na GDC 2011 . IIRC, w pokoju było około 60 osób. W pewnym momencie moderator przeprowadził ankietę dotyczącą zasięgu testu jednostkowego. Był jeden człowiek , który twierdził, większa niż 90% pokrycia kodu. Wszyscy inni śmiali się z myśli, że kiedykolwiek osiągną 1% zasięgu. Jeśli ta grupa stanowi uczciwą reprezentację branży jako całości, powiedziałbym, że zautomatyzowane testowanie zasadniczo nie zdarza się dużo, jeśli w ogóle.

Inne odpowiedzi tutaj podają uzasadnienie. Pomyślałem, że warto mieć konto z pierwszej ręki.