게임 테스트 전략


13

나는 웹 기반의 교육 게임을 물려 받았습니다. 지난 한 해 동안 코드를 안정화하고 새로운 기능을 추가하기 위해 노력했습니다. 대부분의 논리는 프론트 엔드에 있으므로 백엔드 단위 테스트는 도움이 되더라도 적은 비율의 코드를 커버합니다.

게임은 점점 복잡해지기 시작했다. 각 게임마다 두 가지 모드가 있으며 게임은 모드에 따라 다르게 작동합니다. 게임 플레이에 영향을주는 다양한 플래그도 있습니다.

저는 10 년 이상 응용 개발자였습니다. 엔터프라이즈 세계에서 알고리즘은 항상 같은 방식으로 작동합니다. 알고리즘에 대한 단위 테스트를 작성하고 값 42를 예상하고 해당 값을 얻지 못하면 오류가 발생합니다.

게임에 관해서는, 나는 길을 잃었다. 어떻게 테스트합니까? 테스터가 있습니다. 단위 테스트를 작성하는 데 시간을 할애 할 수 있습니다.

테스터는 ... 신뢰할 수 없습니다. 그들은 문제를 발굴하는 데 최고가 아니며 나는 그들에게 최선의 방향을 제시하지 않았습니다. 매 출시주기마다 게임의 순열과 조합을 테스트하는 데 많은 시간을 소비하지 않는 경우 어떻게 리소스로 사용해야합니까?

단위 테스트는 제한적인 것 같습니다. 대부분의 논리는 자바 스크립트 (스파게티 코드를 상속 함)이기 때문에 특정 기능이 작동하도록 Cucumber 또는 셀레늄과 같은 프런트 엔드 제품군을 사용할 수 있습니다.

이것이 최선의 전략입니까? 게임 회사는 게임을 어떻게 테스트합니까?

나는 " 복잡한 게임을위한 테스트 주도 개발 "이라는 질문을 읽었 지만 (사이트의 다른 사람들과 함께) 내가 찾는 것을 다루지 않습니다. 테스트하는 방법에 대한 구체적인 예가 아닌 전략을 요구하고 있습니다.


서적 / 사이트 외 자원 권장 사항은 도움말 센터 별로 주제를 벗어난 주제입니다 . 참조 meta.programmers.stackexchange.com/questions/6483/...을
모기


중복되지 않습니다. 그 질문은 단위 테스트를 작성하는 방법을 묻는 것입니다. 전략을 요구하고 있습니다.
jeffkolez


2
는 GUI를 테스트에 올 때 FWIW, 그것은 더 이상 단위 테스트 - 그것은 더 통합 테스트 또는 수용 테스트처럼
slebetman

답변:


16

엔터프라이즈 세계에서 알고리즘은 항상 같은 방식으로 작동합니다. 알고리즘에 대한 단위 테스트를 작성하고 값 42를 예상하고 해당 값을 얻지 못하면 오류가 발생합니다.

이것은 게임에서 크게 다르지 않습니다. 작업중인 게임에 두 개의 모드와 여러 개의 플래그가 있어도 아무런 변화가 없습니다. 특정 플래그 세트로 특정 모드를 사용하는 경우 소스 코드

너무 많은 모드와 플래그를 사용하면 가능한 많은 변형으로 인해 게임을 테스트하기가 매우 어려워 질 수 있습니다. 이 난이도에 빠질 위험을 조기에 완화하려면 다음을 수행해야합니다.

  • 모의 / 스텁 심각하게 . 테스트 한 부품을 작게 유지하고 그들이 사용하는 모든 것을 조롱하십시오.

    시간에 의존하는 경우 실제 시간과 관계없이 항상 특정 결과 또는 특정 결과 집합을 제공하도록 시간 개체를 조롱하십시오.

    그들이 의지하는 경우 random()매번 상수를 제공하도록 조롱하십시오.

  • 리팩터링 . 테스트가 지나치게 복잡해지기 시작하거나 테스트를 위해 클래스에 의존성 주입을 구현 한 후 12 개의 인수가 필요하다는 것을 발견 한 경우 이전에 2 개만 필요했지만 코드를 리팩터링해야합니다.

  • 응용 프로그램 의 실제 비즈니스 규칙질문하십시오 . 나는 아무도 이해하지 못한 사람도 필요로하지 않는 기능적 요구 사항에 의해 요구되는 다양한 변형으로 인해 테스트가 거의 불가능한 프로젝트 수를 세지 않았다.

    소규모 전자 상거래 웹 사이트에서 선적 가격 계산 방법을 결정하는 데 사용되는 기능 요구 사항을 설명하기 위해 10 페이지가 필요한 경우 테스트 나 코드를 작성하는 것으로 시작하지 말고 이해 당사자에게 연락하여 협력하여 생산해야합니다. 제정신 요건.

마지막으로 모든 테스트를 자동화하십시오 . 응용 프로그램이 실패한 상황을 발견하려면 테스터가 필요합니다. 테스터를 사용하여 모든 개정에서 동일한 조치를 반복적으로 실행하면 테스터가 반 생산적이고 무례합니다. 회귀 테스트는 사람이 아닌 기계에 의해 수행되어야합니다. 반면에 사람들은 가능한 버그를 찾는 데 훨씬 능숙합니다. "어떻게하면 ..."은 그들이 사용할 수있는 기술 중 하나입니다 ( "나의 나이를 묻는 필드에 몇 개의 \ x00을 포함하는 몇 메가 바이트의 이진 데이터를 입력하면 어떻게 될까요?"), 그러나 더 공식적인 접근 방식도 사용될 수 있습니다.


귀하의 의견에 감사드립니다. 해야 할 일이 많은 것 같습니다!
jeffkolez
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.