게임 개발에서 자동 테스트는 얼마나 일반적입니까? [닫은]

게이머 개발자는 단위 및 통합 테스트를 작성하는 데 사용합니까? 퍼즐 개발자들 사이에서 얼마나 흔합니까? 그리고 MMORPG 및 FPS 개발자 중?

(게임 개발에 대한 배경 지식이없고 그 일을하는 것에 대해 관심을 갖고 있지도 않다. 그것은 나에게 일어난 의심 일 뿐이다. 따라서 이미 자동화 된 테스트를 작성하고 있기 때문에이를 작성 하도록 설득 할 필요가 없다 . )

일반적으로 게임의 단위 및 통합 테스트는 일반적이지 않습니다. 이는 주로 게임의 렌더링 측면이 나머지 게임 메커니즘과 밀접하게 연관되어 있기 때문에 실제로 작동하는 단위 테스트를 작성하는 것이 매우 어려울 수 있기 때문입니다.

즉, 단위 테스트는 게임 개발에서 발생할 수 있으며 코드가 설정되면 큰 도움이 될 수 있습니다. 그러나 일반적으로 일반 플레이어보다 더 빠른 속도로 게임을 효과적으로 플레이 할 수있는 AI 프로그램의 형태로 게임에 대한 자동 테스트를 작성하는 것이 훨씬 일반적 일 수 있습니다. 자동화 된 테스트에 대한이 질문 에서 개발자가하는 훌륭한 이야기가 있습니다. 단위 테스트는 렌더링 엔진의 버그를 잡을 수는 없지만 자동화 된 테스트는 이러한 문제를 더 많이 노출시킬 수 있기 때문에 이러한 종류의 자동화 된 테스트는 잠재적으로 더 좋습니다.

그러나 결국 이것은 스튜디오에 달려 있습니다. 일부 스튜디오는 일종의 자동 테스트를하는 반면, 다른 스튜디오는 여름 동안 20 명의 고등학생을 고용하여 몇 시간 동안 게임을 할 수 있습니다.

내 경험상, 그것은 흔하지 않습니다.

대부분의 게임 개발자는 그러한 문화가 널리 퍼지기 전에 시대와 문화에서 왔기 때문에 단위 테스트는 발생하지 않으므로 이러한 방법이 필요하다는 주장을하기가 어렵습니다. 이것은 사용자가 출시 후 자신의 소프트웨어를 패치 할 수 있다는 기대로 최근 몇 년 동안 더욱 사실이되었습니다.

게임 개발 산업에서 지배적 인 언어는 C ++이기 때문에 다른 언어보다 단위 테스트가 조금 더 번거롭기 때문입니다. 단위 테스팅 프레임 워크가 존재하지만 리플렉션과 유사한 트릭을 사용하여 테스트 사례의 탐지 속도를 높일 수있는 최신 언어의 유사 시스템만큼 사용하기 쉽지 않습니다.

또한 게임이 일반적으로 단위 테스트에 적합하지 않기 때문입니다. 논리의 대부분은 반 결정적 소스 (예 : 그래픽 하드웨어, 입력 타이밍, 프레임 속도)에 따라 달라지며 출력의 대부분은 측정하기 어렵습니다 (예 : 온 스크린 그래픽, 음향 효과) 및 일부는 전체 게임 컨텍스트 제작 (예 : 복잡한 반응성 AI, 물리 시뮬레이션)을 제외하고는 거의 의미가 없습니다. 예외적으로 코드를 작성하는 데 많은 노력을 기울이면 많은 경우가 발생하지만 대부분의 다른 유형의 소프트웨어보다 게임에서 전체 테스트 비용이 더 비싸므로 비용 / 이익 비율이 더 모호합니다.

통합 테스트에 관해서는 게임 개발에 명시 적으로 사용되는 용어를 들어 본 적이 없지만 많은 개발자가 가능한 경우 전체 시스템에 대해 자동 테스트를 수행합니다. 어쩌면 내가 설정하기가 쉽지 않기 때문에 3 명의 프로 개발자 중 1 명은이 작업을 수행 할 것이라고 말하고 거의 모든 중대형 개발자 (또는 게시자)가 QA를 가지고 있다는 사실로 인해 이점이 감소하기 때문에 유사한 테스트를 수동으로 수행하는 부서 QA는 일반적으로 개발자보다 훨씬 적은 비용을 지불하므로 추가 코드 시간을 투자하지 않고 테스트를 떠나는 것이 경제적 인 것으로 간주 될 수 있습니다. (논쟁의.)

테스트가 진행되는 한 게임 작성이 다른 소프트웨어와 어떻게 다른지 알 수 없습니다. 시간 초과 이벤트를 트리거하거나 게임 내 캐릭터에게 명령을 보내거나 메뉴 버튼을 누를 때마다 소프트웨어의 각 구성 요소가 제대로 실행되는지 테스트해야합니다.

게임을 완료 할 수 있는지 테스트하는 것은 다른 문제이며 단위 테스트 나 통합 테스트에 포함되지 않습니다.

일반적으로 UI 테스트 자동화 (일반 프로그램에서도)는 일반 자동화보다 어렵습니다. 따라서 게임에 대한 단위 테스트를 작성할 수 있지만 실제 게임을 테스트하는 것이 더 어렵습니다. 대부분의 회사는 게임을 반복 해서 실행하는 인간 테스터를 사용 합니다.

예를 들어 다음 은 소규모 Game Studio (2 개발자)에서 수행하는 방법을 설명하는 기사입니다. 내가 읽은 것에서 그들의 검증은 매우 상세하지 않은 것처럼 보입니다 (자동화는 게임을 시작하고 오류 / 주장을 기록합니다).

그러나 일부 회사는 반 자동화 (Microsoft Test Studios와 같은)에 매우 성공적입니다. 즉, 개발자 또는 SDET은 게임을 훨씬 쉽게 테스트 할 수있는 도구를 빌드합니다. 예 를 들어 Fable이나 Crackable을 어떻게 테스트했는지 토론하는 Gamefest 강연이있었습니다 . 예를 들어, 그들은 여전히 ​​모든 물체가 원래 위치에 있는지 확인하는 테스터를 사용하지만, 사람이하는 모든 것이 게임을하지 않고도 시각적으로 확인할 수 있도록 해당 위치의 스냅 샷을 찍는 도구를 사용합니다.

다음 은 게임을 테스트하기 위해 어떤 도구를 만들고 사용하는지에 대한 좋은 이야기입니다. "테스트 리드 젬 : 점점 더 복잡 해지는 게임에서 벗어나기"

그러나 MMO 및 멀티 플레이어 서버 코드는 조금 더 자주 테스트됩니다.

최소한 자동 회귀 테스트가 일반적이었습니다. 서버를 시작하는 동안 대량 위생 검사로 구현 된 것을 보았습니다. 예를 들어 플레이어를 수락하기 전에 새 "클라우드"서버가 올바르게 구성되어 있는지 확인하십시오. 3-4 년에 걸쳐 구축 된 상당히 우수한 회귀 스위트는 약 4 초 동안 실행되었으며 빈 OS 이미지에서 가상 호스트를 가져 오는 데 거의 10 분이 걸렸으므로 시간 가치가있었습니다. 우리는 Subversion 저장소의 "tinderbox"(연속 빌드 시스템)에서 동일한 테스트를 실행하여 되돌아 가기를 좋아하는 성가신 상당히 일반적인 오류를 확인했습니다. 전달 된 객체 복제 : 객체 인스턴스화, 캐싱, 네트워크 통과 코드는 100 %에 가까워졌습니다. 우리는 테스트 할 수있는 모든 것을 생각한 다음 새로운 재미를 발견했습니다.

필자가 작업 한 여러 MMO에서 초기 단위 테스트를 수행하기 위해 "스텁 클라이언트"를 개발하고 일반적으로 새로운 기능의 임시 단위 테스트를 수행하는 "운영자"명령을 제공했습니다. 이를 통해 클라이언트가이를 활용할 준비가되기 전에 서버 코드를 실행하고 "불가능한"상황 (예 : 플레이어를 벽 내부로 순간 이동)을 수행하여 오류 복구 처리기가 제대로 작동하는지 확인할 수 있습니다. 서버에서 새 기능을 온라인 상태로 만드는 데 클라이언트 지원에 비해 며칠이 더 걸릴 수 있습니다. 반대로, 우리는 때때로 클라이언트를 위해 "더미"서버 메소드를 작성하여 가짜 데이터이지만 잘 구성된 데이터를 반환해야합니다.

그러나 일반적으로 MMO 개발에는 환경을 반영 할 수있는 이러한 종류의 많은 문제가 있습니다. 임베디드 게임 시스템에서 작업 할 때 재사용 가능한 위젯 코드 (예 : 텍스트 편집기)를 제외한 모든 것에서 "테스트"는 실제로 들어 보지 못했습니다.

게임 개발에서 자동화 테스트가 일반적이지 않은 또 다른 이유는 대부분의 게임에서 게임이 출시 될 때 게임 베타 참여를 "가장자리"로 인식하는 베타 테스트 지원자가 많이 있기 때문입니다. 자동화 된 테스트는 물론 품질 요구 사항에서 벗어나 예산 제한에서 벗어났습니다. 따라서 게임에는 무료로 테스트 할 준비가 된 숙련 된 테스터가 많이 있기 때문에 자동화 테스트가 널리 보급되지 않은 또 다른 이유 일 수 있습니다.

GDC 2011 에서 자동화 된 테스트에 대한 원탁 회의에 참여했습니다 . IIRC, 방에 약 60 명이있었습니다. 어느 시점에서 중재자는 단위 테스트 범위를 조사했습니다. 코드 범위가 90 % 이상이라고 주장한 사람 이 한 명 있었습니다 . 다른 모든 사람들은 1 % 범위 에 도달한다는 생각에 웃었다 . 만약 그 그룹이 산업 전체를 공정하게 대표한다면, 자동화 테스트는 일반적으로 전혀 일어나지 않는다고 말하고 싶습니다.

여기에 다른 답변은 이유에 대한 충분한 이유를 제공합니다. 방금 직접 계좌를 갖는 것이 도움이 될 것이라고 생각했습니다.