자동 게임 테스트 [폐쇄]

게임의 자동 테스트 방법이 있습니까?

설명에 도움이 될 경우 플랫폼 및 게임 유형과 같은 프로젝트에 대한 관련 정보를 통해 특정 경험을 높이 평가합니다.

1 인 독립 게임. 파괴 가능한 지형을 가진 멀티 플레이어 탱크 게임이었고 파괴 가능한 지형 및 충돌 코드는 다소 벗겨졌습니다.

나는 기본적인 바보 AI를 준비했습니다. ( "멍청한", 나는 "절대적으로 바보"를 의미합니다. 그들은 무작위로 "적의 탱크를 향해 운전", "적의 탱크를 떠나 운전", "무작위 방향으로 운전" ", 주요 무기를 무작위로 발사하는 동안) 키를 누르는 동안 최대 프레임 속도로 게임을합니다. 나는 약 10-15x 실시간으로 얻었다. 코드가 강력하게 주장되었으므로 문제가 발생하면 오류 키 및 초기 임의 시드와 함께 전체 키 누르기 로그를 디스크에 덤프합니다. 그런 다음 키 누르기 로그를 재생하여 상태를 정확하게 복제하거나 오류 보고서에서 디버그 할 수 있습니다.

나는 문자 그대로 몇 달 동안 지속적으로 실행했습니다. 처음에는 충돌없이 거의 1 시간이 걸리지 않았습니다. 나는 거기에 앉아서 일주일 동안 보모하여 하루에 몇 가지 모호한 버그를 죽였습니다. 결국 실패 사이에 일주일 동안 실행 된 지점에 도달했으며, 이는 충돌 당 약 1500 시간의 플레이어 시간으로 해석됩니다.

귀중한 것이었고 진심으로 추천합니다.

필자가 작업 한 MMO (100 개 개발자, PC 중심)를 위해 다양한 성공을 거두면서 다양한 자동화 테스트를 추가하려고했습니다. 다음은 효과가 있습니다.

• 자동화 된 빌드 프로세스 동안의 기본 테스트는 큰 승리였습니다. 여기에는 캐릭터 생성, 맵 전송, 스크립트 가능한 UI 테스트 실행 및 예상되는 동작 찾기와 같은 작업이 포함되었습니다. 그들은 실제로 회사의 다른 부분에 도달하기 전에 수많은 버그를 발견했습니다.
• 서버 인프라 스트럭처에서는 일반적인 MMO 서버 트랜잭션을 시뮬레이트하는 다양한 자동화 테스트를 개발했습니다. 그런 다음 다양한 상황에서 성능을 비교하거나 안전을 보장하기 위해 이러한 기능을 재생할 수 있습니다. 시간이 지남에 따라 이러한 테스트는 실시간으로 기록 된 데이터를 재생할 때까지 더욱 정확 해졌습니다.
• 우리는 전 세계에서 무작위로 로밍하고, 점프하고, 물건을 죽이고, 채팅에서 임의의 것을 말하는 "가짜 플레이어"를 썼습니다. 이것은 수많은 물리 및 인프라 문제를 발견했습니다.

작동하지 않는 것 :

• 우리는 매우 구체적인 전투 중심 자동화 테스트를 자동화 빌더에 추가하려고 시도했지만 기본적으로 작동하지 않았습니다. 구현 된 후 약 3 일 동안 디자이너 나 아티스트가 무언가를 변경하고 테스트가 실패하여 빌드 실패 경보를 던질 때까지 작동합니다. 시간의 90 %는 실제 문제가 아니 었습니다. 이 테스트는 너무 약해서 실제로는 특정 능력을 가진 특정 맵에서 특정 게임 플레이를 테스트하는 것은 유지하기가 어려울 수 있습니다
• 우리는 클라이언트 성능 (평균 FPS 등)을 일주일 전의 기록 된 성능과 비교하는 자동화 된 성능 테스트를 구현하려고 시도했습니다. 이것은 우리가 사용한 데모가 상당히 자주 부패하는 경향이 있었기 때문에 상당히 취약했습니다. 실제 성능 저하 또는 테스트 프로세스의 부작용으로 인해 속도 저하가 발생했는지 확인하기가 어려웠습니다.

불행히도 회사가 자금 부족으로 인해 결코 빛을 보지 못한 3D 전투 (Homeworld가 Masters Of Orion을 만난다고 생각하십시오)로 4x 전략 게임을 진행하고 있습니다.

나는 인간 플레이어없이 게임을 할 수 있도록 항상 밤새 게임을 계속할 수 있도록했습니다.

3D 전투를 중단하고 (임의의 결과로 단순화) AI 전략 엔진을 그대로 두었습니다. 이것은 많은 버그와 문제를 발견했습니다. (예를 들어) AI 전략이 교착 상태에 빠질 수 있고 "올바른 일"을하지 않는 1000 번의 턴을 보내는 전략 버그를 보여줍니다. 이런 종류의 버그는 단지 "게임을하는 것"을 찾기가 어려웠습니다.

내가 일한 1 인칭 슈팅 게임 (1999 년 팀에서 30 명 이하의 강의 3-linux / mac / windows)에서 데모 레코딩 / 재생 기능은 매우 유용한 것으로 판명되었습니다. 게임에서 프레임을 렌더링 할 수있는 한 빨리 데모를 재생할 수있는 옵션을 만들었습니다. 여러 가지 사항이 변경된 후 성능을 확인할 수있는 좋은 방법이되었습니다.

또한 렌더링 시스템을 넘어서 많은 코드를 사용했기 때문에 훌륭한 검사였습니다. 많은 변경을 한 후 10 분 동안의 게임 플레이 데모 데모를 실행할 수있었습니다. 여러 번 그것은 내가 스스로 확인하려고 생각하지 않은 영역에서 버그를 잡을 것입니다.

빌드 서버에서 빠른 연기 테스트를 사용하는 오픈 월드 슈팅 게임 (x360, PS3, PC)이있었습니다. 게임을로드하고, 프런트 엔드를 단계별로 실행하고, [아바타] 포워드를 실행하고, 스크린 샷을 버리고 종료했습니다. cctray가 클린 종료를 감지하면 빌드가 성공한 것입니다.

우리는 프로젝트의 작년에 약 100 명 규모의 팀 규모로 운영했습니다.

그것은 쇼 토핑 버그를 잡는 데 효과적 이었지만 스모크 테스트를 통과했지만 대부분의 "실제"레벨에 실패하거나 멀티 플레이어에서 작동하지 않거나 AI를 방해하는 빌드를 만드는 것은 쉬웠으므로 완벽하지 않았습니다. 확실히 가치가있었습니다.

그들이 나가서부터 여러 대의 PC로 농장 된 더 넓은 범위의 연기 테스트를 시작했다고 들었습니다. 분명히 연기 테스트를 유지 관리하는 것이 문제이며 빌드 서버와 소프트웨어를 유지 관리하는 데 전념하는 소규모 팀이 있으므로 성공 여부를 말할 수 없습니다.

크라이시스 2 개발 중 자동 테스트에 대한 나의 경험은 여기에 있습니다 : http://yetanothergameprogrammingblog.blogspot.com/2010/06/aaa-automated-testing.html

요약:

• 자동화 된 테스트는 결과물 안정성을 향상시켜 컨텐츠 제작자와 엔지니어 모두의 생산성을 높입니다.
• 자동 테스트는 코드 품질을 개선하고 초과 근무 시간을 줄일 수있는 효과적인 도구입니다.
• 게임 산업 전체는 일반적으로 매우 반동적입니다. 자동화 된 테스트는
• 테스트라고 부르지 말고 다른 것으로 부르십시오 (거동 주도)
• 융통성 있고 좋은 시험을 작성하는 것은 어렵고 게임 산업에서 널리 이용되지 않는 기술이 필요합니다

개별 시스템 간의 상호 작용이 너무 일반적이기 때문에 게임 개발은 실제로 단위 테스트가 나에게 의미가있는 경우 중 하나입니다. 계약 별 설계는 물론 이것의 일부이며, 개발 첫날부터 계획되어야하지만, 그럴 필요가 있다고 가정 할 때 나중에 구현할 수없는 이유는 알 수 없습니다.

어려운 부분은 물론 통합 테스트입니다. 많은 게임을 데모 루프하여 테스트 할 수는 있지만 개념적으로 디버깅하기가 쉽습니다. 내 시간을 보내는 데 더 관심이있는 부분은 플레이어 가 무언가를 할 때 발생할 수있는 버그를 노출시키는 것입니다. 플레이어가 볼 수없는 버그는 플레이어가하는 버그보다 덜 중요하다는 생각이 있습니다.

분명히 꽤 어렵습니다. 다른 응용 프로그램 (퍼지, 예상 통과 / 예상 실패 등)에서 작동하는 전술은 제대로 작동하지 않습니다. 스크립트 가능한 시스템에서는 플레이어를 시뮬레이트하기위한 테스트 스크립트 세트를 작성하는 것이 좋습니다 (JZig의 답변 참조). 그러나 플레이어가 만날 수있는 물건에 대한 테스트는 사람과 자동화 된 테스트 목적을 위해 시간을 집중할 수있는 최고의 장소라고 생각합니다.