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


35

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. )


3
Jak częste są automatyczne pytania na Stack Exchange?
MichaelHouse


To, że nie są powszechne w branży gier, nie oznacza, że ​​nie powinieneś starać się ich pisać. Jaki problem próbujesz rozwiązać przy pomocy tego pytania?
Tetrad

@Tetrad Wystarczy przeczytać pytanie. Drugi akapit wyjaśnia wszystko.
brandizzi

Odpowiedzi:


37

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.


17
+1 tylko dlatego, że wszyscy chcielibyśmy być jednym z tych dzieciaków. :(
Bobby

13
@Bobby Mów za siebie. Bycie zmuszonym do grania w niedokończone i niedokończone gry to przerażająca myśl, nawet jeśli nie zostaniesz przydzielony do testowania czegoś takiego jak najnowsza gra Barney the Dinosaur.
Dan Neely,

9
@Bobby, byłem QA przez około 3-4 lata, to świetna robota, jeśli lubisz łamać oprogramowanie i pracować w tej branży, ale nie rób tego, ponieważ „kochasz grać przez cały dzień” :)
JuniorDeveloper1208

9
Byłem w QA przez około sześć miesięcy. Podchodząc do samochodu pod koniec drugiego dnia pracy, żywo pamiętam, że pomyślałem sobie: „Widzę, że w końcu nienawidzę tej pracy”. I pod koniec trzeciego dnia: „Naprawdę nienawidzę tej pracy”. Dobrzy testerzy jakości, którzy potrafią poradzić sobie z wymaganiami pracy, są na wagę złota, a przestępstwem jest to, że nie są cenieni i wynagradzani wyżej niż są.
Trevor Powell,

16

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.)


5
Świetna uwaga, że ​​wynik jest trudny do zmierzenia. Łatwo jest automatycznie przetestować, czy klasa wypluwa, powiedzmy, poprawną składniowo JSON, ale jedynym sposobem, aby upewnić się, że twoje ragdoll nie wymkną się spod kontroli, gdy faktycznie wystrzelona jest gra. Najgorsze jest to, że bardzo utrudnia to zauważenie efektów ubocznych (np.
Naprawiasz

8

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.


8

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”


4

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).


3

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.


3

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.


Jestem zaskoczony, że liczba ta jest tak niska (choć nie spodziewałbym się, że więcej niż jedna trzecia gamedevów użyje takich testów, jak powiedziałem w mojej odpowiedzi). Aby dodać osobiste anegdotyczne dowody, oprogramowanie serwera, nad którym pracuję ma ponad 70% pokrycia testem jednostkowym. Prawdopodobnie mógłbym to osiągnąć do 85% przy odrobinie ciężkiej pracy, ale ostatnie 15% wiązałoby się z różnymi zniekształceniami uzależnienia, których nie jestem skłonny zrobić. Dla porównania oprogramowanie klienckie jest prawie niemożliwe do przetestowania jednostkowego, dlatego skupiamy się na testowaniu ręcznym.
Kylotan

W projekcie Lua, dzięki łatwości karczowania i kpin, udało mi się zachować 100% zasięgu podczas programowania. Zauważyłem jednak, że wiele testów było nieciekawych (takich jak testowanie dokładnego umiejscowienia interfejsu użytkownika lub cokolwiek, co powinno być oparte na danych, ale tak naprawdę zostało zrobione w kodzie). Aby zachować czystość, podzieliłem kod na „silnik” (wielokrotnego użytku) i specyficzny dla gry i upewniłem się, że obejmuje on cały kod silnika, podczas gdy zasięg zmienia się dla kodu gry (nadal testuję klasy niskiego poziomu, ponieważ łatwo jest i dostosuj fizykę, ponieważ łatwo jest zepsuć, ale nie ma już interfejsu użytkownika / renderowania na wysokim poziomie).
hsandt
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.