Zautomatyzowane testowanie gier [zamknięte]

Czy istnieją metody automatycznego testowania gier?

Doceniane są konkretne doświadczenia, wraz z odpowiednimi informacjami na temat projektu, takimi jak platforma i rodzaj gry, jeśli to pomaga w wyjaśnieniu.

Niezależna gra jednoosobowa. Była to gra czołgowa dla wielu graczy z niszczycielskim terenem, a niszczycielski teren i kod zderzenia okazały się nieco niestabilne.

Skończyło się na przygotowaniu podstawowych głupich AI (przez „głupie”, mam na myśli „absolutnie idiotyczne” - losowo wybrali „jedź w kierunku wrogiego czołgu”, „jedź od wrogiego czołgu” i „jedź w losowym kierunku” ”, podczas losowego strzelania z głównej broni) i grania z maksymalną szybkością klatek podczas nagrywania naciśnięć klawiszy. Mam około 10-15 razy w czasie rzeczywistym. Kod został mocno potwierdzony, więc jeśli coś pójdzie nie tak, zrzuci cały dziennik naciśnięć klawiszy na dysk wraz z raportem błędu i początkowym losowym początkiem. Mógłbym wtedy przejść i odtworzyć dziennik naciśnięć klawiszy, aby dokładnie powielić stan, lub po prostu debugować z raportu o błędach.

Pozostawiłem to działające nieprzerwanie przez dosłownie miesiące. Na początku rzadko bywało godzinę bez awarii - musiałem tam siedzieć i opiekować się nim przez tydzień, zabijając kilka niejasnych błędów dziennie. W końcu doszło do tego, że działał przez tydzień między awariami, co przekłada się na około 1500 godzin gracza na awarię.

To było bezcenne i serdecznie polecam.

W przypadku MMO, nad którym pracowałem (100-stu programistów, skupionych na komputerach PC), próbowaliśmy dodać ogromną różnorodność automatycznych testów z różnym powodzeniem. Oto, co zadziałało:

• Podstawowe testy podczas naszego automatycznego procesu kompilacji były ogromną wygraną. Obejmowało to takie zadania, jak tworzenie postaci, przesyłanie map, uruchamianie skryptowych testów interfejsu użytkownika i szukanie oczekiwanego zachowania. Wykryło to ogromną liczbę błędów, zanim dotarły do ​​reszty firmy.
• Po stronie infrastruktury serwerów opracowaliśmy szereg różnych automatycznych testów symulujących typowe transakcje na serwerach MMO. Następnie moglibyśmy odtworzyć je w różnych okolicznościach, aby porównać wydajność lub zapewnić bezpieczeństwo. Z biegiem czasu testy te stawały się coraz bardziej dokładne, aż przekształciły się w odtwarzanie nagranych na żywo danych
• Napisaliśmy „fałszywego gracza”, który losowo wędrowałby po świecie, skakał, zabijał rzeczy i mówił przypadkowe rzeczy na czacie. Znalazło to ogromną liczbę problemów fizyki i infrastruktury.

Co nie działało:

• Próbowaliśmy dodać kilka bardzo szczegółowych automatycznych testów zorientowanych na walkę do zautomatyzowanego konstruktora, ale w zasadzie nigdy nie zadziałało. Będzie działać przez około 3 dni po wdrożeniu, dopóki projektant lub artysta coś nie zmieni, a test zakończy się niepowodzeniem, wyrzucając alarmy o niepowodzeniu kompilacji. W 90% przypadków nie był to prawdziwy problem. Testy te były zbyt kruche, a testowanie konkretnej rozgrywki na konkretnej mapie z konkretnymi mocami może być niemożliwe do utrzymania
• Próbowaliśmy wdrożyć automatyczny test wydajności, który porównywałby wydajność klienta (średni FPS itp.) Z zarejestrowaną wydajnością sprzed tygodnia. Było to również dość delikatne, ponieważ dema, których używaliśmy do tego, miały tendencję do gnicia dość często i trudno było ustalić, czy spowolnienie było spowodowane faktyczną utratą wydajności lub jakimś efektem ubocznym procesu testowego.

Pracujesz nad strategią 4x z walką 3d (myśl, że Homeworld spotyka Masters Of Orion), która niestety nigdy nie ujrzała światła dziennego, ponieważ firmie zabrakło funduszy.

Zawsze zapewniałem, że możesz grać w tę grę bez ludzi, dzięki czemu możemy pozostawić grę uruchomioną na noc.

Moglibyśmy wyłączyć walkę 3D (uproszczoną do losowego wyniku) i zostawiliśmy silnik strategii AI sam w sobie. Znalazło to wiele błędów i problemów. Nie tylko pokazują błędy stoppera, ale także błędy strategii, w których (np.) Strategie AI zostałyby zakleszczone i spędziłyby tysiące tur, nie robiąc „właściwej rzeczy”. Tego rodzaju błędy były trudne do wykrycia po prostu podczas „gry”.

Na strzelance FPS, nad którą pracowałem (Descent 3 - Linux / Mac / Windows, ~ 30 osób w zespole w 1999 r.), Możliwość nagrywania / odtwarzania demo okazała się niezwykle przydatna. Udostępniłem opcję, w której można odtwarzać demo tak szybko, jak gra może renderować klatki, i stał się to świetny sposób na sprawdzenie wydajności po zmianie wielu rzeczy.

Ćwiczył także dużo kodu poza systemem renderowania, więc był to dobry test poprawności. Po wprowadzeniu wielu zmian mogłem po prostu uruchomić odtwarzanie demo 10 minut gry. Wiele razy łapałby błąd w obszarze, o którym bym nie pomyślał.

Mieliśmy strzelankę OpenWorld (x360, PS3, PC), która zastosowała szybki test smoketest na serwerze kompilacji - załadowała grę, przeszła przez interfejs, uruchomiła [awatara] do przodu, zrzuciła zrzut ekranu i wyszła. Jeśli cctray wykryje czyste wyjście, kompilacja zakończyła się sukcesem.

Pracowaliśmy nad nim przez ostatni rok projektu, a zespół liczył około 100 programistów.

Był skuteczny w wykrywaniu błędów związanych z showstopowaniem, ale łatwo było stworzyć kompilację, która przeszła najdelikatniejsze, ale zawiodła większość „prawdziwych” poziomów, nie działała w trybie dla wielu graczy lub niszczyła AI, więc nie była idealna. Zdecydowanie warto było to zrobić.

Słyszałem, że odkąd opuściłem, zaczęli organizować większą liczbę testów smoketestów, przeznaczonych dla wielu komputerów. Najwyraźniej utrzymywanie testów smoket to problem, a niewielki zespół zajmuje się utrzymywaniem serwerów kompilacji i oprogramowania, więc nie mogę powiedzieć, czy to był sukces, czy nie.

Moje doświadczenie z automatycznymi testami podczas tworzenia Crysis 2 jest dostępne tutaj: http://yetanothergameprogrammingblog.blogspot.com/2010/06/aaa-automated-testing.html

Podsumowanie:

• Zautomatyzowane testy poprawiły stabilność wyników, zwiększając wydajność zarówno twórców treści, jak i inżynierów
• Automatyczne testowanie jest skutecznym narzędziem do poprawy jakości kodu i zmniejszenia szansy na pracę w nadgodzinach
• Przemysł gier jako całość jest bardzo reakcyjny, zautomatyzowane testowanie spotyka się z kilkoma irracjonalnymi argumentami przeciwko
• Nie nazywaj tego testowaniem, nazwij to czymś innym, prawie czymkolwiek innym (spójrz na rozwój oparty na zachowaniu)
• Bądź elastyczny, pisanie dobrych testów jest trudne i wymaga umiejętności, które nie są powszechnie dostępne w branży gier

Rozwój gry jest w rzeczywistości jednym z tych przypadków, w których testowanie jednostkowe wydaje mi się mieć sens, ponieważ interakcje między systemami dyskretnymi są tak powszechne. Projektowanie na podstawie umowy jest oczywiście częścią tego i powinno być planowane od pierwszego dnia rozwoju, ale nie rozumiem, dlaczego nie można go wdrożyć później, zakładając, że istnieje taka możliwość.

Najtrudniejsze jest oczywiście testowanie integracji. Wiele gier można przetestować po prostu zapętlając wersję demo lub coś w tym stylu, ale te rzeczy są dość łatwe do debugowania - bardziej interesuje mnie odsłonięcie błędów, które pojawią się, gdy gracz coś zrobi, z myślą, że błąd, którego gracz nigdy nie widzi, jest oczywiście mniej ważny niż błąd, który robi gracz.

Co oczywiście jest dość trudne. Taktyki, które działają w innych aplikacjach (fuzzowanie, oczekiwany przebieg / oczekiwany błąd itp.) Nie działają tutaj tak dobrze. W systemach skryptowych wydaje się, że budowanie zestawu testowego skryptów do symulacji gracza jest właściwą drogą (patrz odpowiedź JZiga). Ale testowanie konkretnie rzeczy, które gracz może napotkać bezpośrednio, wydaje mi się najlepszym miejscem do skupienia czasu zarówno na testach ludzkich, jak i automatycznych.