ISTQB CT-GaMe 실러버스를 다시 공부하며 (2. 게임 메커니즘 테스팅)

본 ISTQB CT-GaMe 실러버스를 공부하며게시글은 이미 ISTQB CT-GaMe 자격증을 취득하였음에도 이 후 지속적으로 취업을 준비하는 중,

게임 테스트에 대한 이론 지식 습득 및 보완 및 취업 후 원활한 테스트 작업 수행을 위해 CT-GaMe 실러버스 v1.0.1을 바탕으로 학습한 내용을 정리하고 있습니다.

 

본 내용의 실러버스는 아래 첨부한 KSTQB의 학습 자료실 링크를 통해 다운 받아 학습하실 수 있습니다.

https://www.kstqb.org/board_skin/board_view.asp?idx=1874&page=1&bbs_code=4&key=0&word=&etc=

KSTQB

 

 

 

게임 메커니즘 유형

 

게임의 핵심적인 요소 중 하나는 플레이어를 늘리고 유지하기 위해 사용자의 관심을 유도하는 것이다.

플레이어는 게임의 그래픽, 게임플레이 그리고 게임플레이어를 구성하는 메커니즘을 평가하게 된다.

 

비디오게임 메커니즘은 모든 게임의 핵심이며,

게임과 사용자 간의 상호작용 방법을 정의하며 게임과 사용자 간의 영향 및 피드백과 정의된 요구사항 안에서

비디오게임의 상태 변화를 고려해서 정해진다.

 

메커니즘은 게임의 양상과 목표에 따라 여러 유형으로 나눌 수 있다.

 

메커니즘과 플레이어의 상호작용 유형에 따라

게임 플레이 메커니즘은

사용자가 가용한 정보를 바탕으로 의식적으로 게임 시스템과 상호작용하면서 행동하는 것과 관련이 있다.

사용자는 행동의 결과를 명확하게 확인하면서 비디오게임 상태의 변화에 영향을 미치게 된다.

 

주요 게임플레이에 미치는 영향에 따라

핵심 메커니즘은

게임의 기초를 형성하고 사용자가 게임 전반에 반복적으로 하는 동작을 정의한다.

이는 제작사가 게임에 넣어 놓은 어떤 경험을 사용자가 체험할 수 있도록 하기 위한 것이다.

 

메타 메커니즘은 주요 게임플레이에 포함되지 않지만, 그것에 영향을 미칠 수 있다.

이는 게임 디자이너가 의도한 행동을 플레이어가 실행 하는 것을 목표로 한다.

이러한 메커니즘은 핵심 메커니즘과 결합해서 게임을 더 흥미롭게 만들 수 있다.

 

(핵심, 메타 메커니즘에 대해 Escape From Tarkov을 예로 들어보자면

유저가 게임 내에서 사격, 파밍, 취식, 회복하는 행동들을 핵심 메커니즘이라고 볼 수 있겠으며,

유저의 플레이를 유도하는 게임 내 NPC가 제공하는 퀘스트, 은신처, 업적을 메타 메커니즘이라고 볼 수 있겠습니다)

 

게임 구조의 아키텍처에 따라

클라이언트 메커니즘은

사용자 디바이스에서 발생하는 사용자 행동 처리와 관련이 있다.

 

서버 메커니즘은

게임 서버에서 처리되는 메커니즘과 관련이 있다.

 

클라이언트-서버 메커니즘은

사용자 디바이스와 서버 모두에서 처리되는 메커니즘과 관련이 있다.

이때는 서버와 클라이언트 간 지속적인 데이터 통신이 있다.

 

 

게임 플레이 메커니즘 테스팅과 비-게임플레이 메커니즘 테스팅의 차이

 

유저는 게임에 구현된 모든 메커니즘과 직접 상호작용 하지는 않는다.

게임플레이 메커니즘은 공식 또는 비공식 명세에 명시되어 있을 수 있지만,

비-게임플레이 메커니즘은 사용자에게 설명되어야 한다.

 

게임플레이 메커니즘은 게임을 플레이하는 목적 달성에 직접적인 영향을 미치는 경우가 많다.

 

비-게임플레이 메커니즘은 보통 사용자에게 보이지 않지만, 사용자의 행동으로 발현된 수 있다.

비-게임플레이 메커니즘은 드러나지 않기 때문에 공식 요구사항으로 명시돼야 한다.

 

게임플레이 및 비-게임플레이 메커니즘의 테스팅은 기능 테스팅이다.

 

(비-게임플레이 메커니즘의 경우에는 Helldivers2를 예시로

인게임 스토어에서 현금으로 구매할 수 있는 슈퍼 크레딧을 구매, 처리 및 확인하는 과정으로 이해할 수 있을 것입니다)

 

핵심 메커니즘 테스팅과 메타 메커니즘 테스팅의 차이

 

핵심 메커니즘과 메타 메커니즘 테스팅 접근법은 그 영향에 따라 달라진다.

게임에서 하나의 핵심 메커니즘을 제거하면 게임플레이가 완전히 바뀌게 된다.

게임에서 어떤 메타 메커니즘을 제거했다고 전체 게임의 본질이 바뀌는 경우는 거의 없다.

 

기능 요구사항 외에도 핵심 및 메타 메커니즘은 테스트 방법에 직접적인 영향을 미치는 비기능 요구사항이 있을 수 있다.

메타 메커니즘의 경우 가장 중요한 것은 기능이 올바르게 동작하는 것이지만,

메커니즘이 약간 느리게 동작하더라도 테스터나 유저가 이것을 결함으로 간주하진 않는다.

그러나 핵심 메커니즘에 이러한 지연이 있다면 플레이어의 목표 달성를 방해할 수 있기에 매우 치명적으로 다가올 수 있다.

그렇기에 핵심 메커니즘에는 성능 테스팅도 중요하게 된다.

 

핵심 및 메타 메커니즘의 본질도 테스트를 수행하는 시점에 영향을 미친다.

일반적으로 이런 메커니즘의 검증은 게임 개발의 여러 단계에서 시작되며,

핵심 메커니즘은 게임의 초기 버전에서 구현된다.

동시에 기능 정확성과 목표 고객의 관심 수준에 대한 검증도 시작된다.

 

메타 메커니즘은 일반적으로 개발 단계에서 추가되고 테스트된다.

메타 메커니즘이 게임 제품 등에 미치는 영향에 대한 평가는 베타 테스팅 단계에서 이루어진다.

동일한 시점에 가장 효과적인 메커니즘을 판단하기 위해 A/B 테스팅을 사용하는 경우도 많다.

 

 

클라이언트, 서버, 클라이언트-서버 메커니즘 테스팅의 차이

 

클라이언트, 서버, 클라이언트-서버 메커니즘을 테스트해야 하는 필요성은 게임 자체의 아키텍처에 따라 다르다.

각 유형은 구현 방법에 따라 테스팅 접근법이 달라야 한다.

 

클라이언트 메커니즘

플레이어의 기기에서 처리되므로 사용자는 클라이언트에 저장된 모든 데이터에 접근할 수 있다.

모든 메커니즘이 클라이언트에서 실행되는 것처럼 일부 게임은 서버 없이 클라이언트에서만 실행될 수 있다.

일반적으로 이런 게임은 싱글 게임으로 인터넷 연결이 필요하지 않다.

 

게임 클라이언트는 플레이어의 기기에서 실행되는 코드와 모든 변수, 피해 계산 공식, 게임 레벨, 캐릭터 모델 등을 가지고 있다.

그렇기에 플레이어는 원한다면 게임 클라이언트의 모든 데이터를 수정할 수 있다.

유저는 클라이언트를 수정해서 기술의 속도, 캐릭터 체력, 퀘스트 완료 보상의 가치 등을 높일 수 있지만,

싱글 게임의 경우 다른 플레이어에게 영향을 끼치지 않고 자신의 게임플레이에만 영향을 주기에

보통 심각한 결함으로 간주하지 않는다.

(싱글 게임에서 콘솔 입력 혹은 외부 모드 매니저를 통해 게임 내 수치를 바꾸는 행동으로 이해할 수 있을 것입니다)

 

클라이언트 메커니즘은 멀티플레이어 게임에도 있을 수 있지만 여전히 다른 플레이어에게는 영향을 미치지 않으며,

클라이언트에서만 처리되고 서버를 사용하지 않는 기능 테스팅으로 검증할 수 있다.

 

클라이언트 메커니즘 테스팅은 일반적으로 블랙박스 테스팅을 사용하여 수행하는데,

이 작업을 수행할 때 테스터는 애플리케이션의 사용자 인터페이스를 확인해야 할 수 있다.

이 경우 실제 결과를 얻기 위해 실제 사용자 인터페이스를 사용해서 게임을 테스트하기도 한다.

 

서버 메커니즘

해당 메커니즘은 서버에서만 구현되는 특징으로 메커니즘의 논리는 사용자 개입으로부터 보호된다.

플레이어가 원격 서버에서 실행되는 프로세스에 직접 영향을 줄 수 없으므로

개발자는 게임 논리 계산의 가장 중요한 부분을 원격 서버로 이관한다.

 

서버 메커니즘 테스팅은 멀티 플레이어 온라인 게임에서 가장 중요하다.

서버에 구현된 기능을 테스트하는 방법은 클라이언트 메커니즘을 테스트하는 방법과 다르다.

 

여기서 테스터는 사용자 인터페이스가 필요 없는 경우가 많다.

테스트는 서버 콘솔 또는 특별한 도구를 사용하여 수행한다.

테스터는 로그(log)를 분석하거나 데이터베이스와 상호작용하는 데 대부분의 시간을 보낸다.

 

서버 메커니즘에서 가장 중요한 테스트 유형은 기능 테스팅, 성능 테스팅, 보안 테스팅이다.

 

클라이언트-서버 메커니즘

해당 메커니즘은 클라이언트와 서버를 다루며, 앞서 언급한 두 가지 유형의 메커니즘의 특징을 모두 가지고 있다.

논리의 일정 부분은 플레이어의 디바이스에서 처리되고, 나머지는 원격 서버에서 처리된다.

이러한 메커니즘의 일부는 지속적으로 서로 "통신" 하여 서로 데이터를 주고받는다.

 

멀티 플레이어 게임에서 서버는 클라이언트에서 데이터를 수신한 다음,

이루어진 작업의 영향을 받는 모든 플레이어에게 작업 결과를 보낸다.

서버에 도착한 데이터는 반드시 검증된다.

 

테스터는 클라이언트-서버 메커니즘을 테스트할 때 최대한 많은 메커니즘을 포함한 하나 이상의 테스트 케이스를 만들게 된다.

 

 

게임 메커니즘 결함 및 발생 원인 예

 

게임 메커니즘에는 게임 오브젝트에 대한 영향과 이러한 영향의 결과를 알리는 피드백이 포함된다.

두 가지를 합치게 되면 게임의 독창적인 특징과 적합한 게임 동작이 만들어진다.

대부분의 경우 게임은 다양한 반응 요소와 피드백 요소들을 사용한다.

 

게임 메커니즘과 관련이 있는 결함 유형

• 메커니즘의 기능적 결함
• 게임의 타당성 인식 결함
• 특정 게임 환경에서 나타나는 메커니즘의 효과성 결함

게임의 기능적 결함은 플레이어가 게임 메커니즘 결함에 대해 이야기할 때 가장 많이 언급된다.

이러한 결함은 보통 개발자가 만든 게임 코드에 있는 오류로 발생하며 눈에 띄며, 식별하고 수정하기 쉽다.

 

게임의 타당성 인식 결함은 특정 메커니즘을 사용하는 동안 게임에서 응답을 얻는 것과 관련이 있다.

플레이어가 게임이 끝난 이유을 이해하지 못화면 문제가 있기에 게임 메커니즘에 시각 및 음향 효과를 수반되는 경우가 많다.

메커니즘 사용에 대한 응답 자체의 유무가 테스트되고, 그 유무의 근거가 평가된다.

효과의 동작 및 정확성은 다른 유형의 테스팅(그래픽 또는 사운드 테스팅)으로 검증된다.

 

세 번째 유형의 결함은 메커니즘의 범위 및 효과성과 관련이 있다.

메커니즘은 그 자체로는 잘 동작하지만, 게임플레이 내에서 동작하지 않을 수 있다.

이러한 상황을 피하기 위해 메커니즘은 게임 레벨의 다른 메커니즘, 오브젝트, 기타 필요한 콘텐츠와 함께 테스트한다.

따라서 통합 테스팅은 게임플레이에서 메커니즘의 효과성을 확인하기 위해 사용성 테스팅과 함께 수행한다.

 

이러한 테스트의 복잡성은 그러한 상황과 그때 메커니즘이 어떻게 동작할 지 예측하는 것과 관련이 있다.

따라서 메커니즘과 환경 오브젝트 간의 상호작용 문제를 찾는 것은

여러 플레이어 그룹과 함께하는 베타 테스팅 단계 내 애드혹 테스팅의 일환으로 수행하는 경우가 많다.

 

 

게임 소프트웨어 개발 수명주기 전반에서 게임 메커니즘 테스팅의 절차 및 접근법

 

소프트웨어 개발의 여러 단계에서 다양한 테스팅 접근법을 사용하여 게임 메커니즘을 테스트 할 수 있는데,

게임 프로토타입을 만드는 단계에서는 핵심 메커니즘만 구현하게 된다.

여기서 테스터의 주요 작업은 다음 특성에 대해 게임 메커니즘을 테스트하는 것이다.

• 기능 정확성
• 플레이어가 가질 관심 수준
• 플레이어가 느낄 매력

모든 메커니즘과 메커니즘의 동작 방식을 리뷰하여 비디오게임 설계 문서에 완전하고 모호하지 않게 설명되어 있는지 확인한다.

유저와 메커니즘의 상호작용에 대해 허용되는 모든 옵션을 확인해야 하며

각 메커니즘이 전체 게임 플레이에 미치는 영향을 결정해야 한다.

 

개발단계에서는 구현된 메커니즘이 명시된 요구사항을 충족하는지 확인하기 위한 기능 테스팅을 수행하며,

일반적으로 테스트 컨디션 및 체크리스트 세트를 사용하여 테스트를 수행한다.

테스트 절차는 메커니즘의 모든 측면을 최대한 다루는 것을 목표로 해야 한다.

 

탐색적 테스팅과 애드혹 테스팅은 서로 다른 메커니즘의 상호작용을 테스트하는데 효과적이다.

특히, 테스트 컨디션으로 정의하기에는 게임의 메커니즘과 다양한 구성 요소 간의 상호작용 방법이 너무 많은 경우에 더 그러하다.

 

비기능 테스팅의 일환으로 메커니즘이 게임의 전반적인 성능에 미치는 영향을 테스트해야 하며

자원 사용률과 실제 결과를 확인한다.

다양한 구성 요소와 소프트웨어의 호환성, 특히 바이러스 백신 프로그램과의 호환성도 테스트해야 한다.

 

게임에 서버가 필요한 경우, 서버 성능도 테스트해야한다.

성능 테스팅은 계획된 메커니즘 중 성능에 영향을 줄 수 있는 것들이 구현되는 개발 단계에서 계획하고 실행한다.

 

베타 테스팅을 수행할 때는 메타 메커니즘에 상당한 주의를 기울여야 하는데

많은 수의 플레이어가 느끼는 게임의 편의성과 명확성이 평가되기 때문이다.

게임이 아닌 소프트웨어를 테스트하는 것과 마찬가지로

명백한 기능 결함을 찾는 것이 아니라 최종 플레이어로부터 피드백을 받는 것이 이 테스팅의 목적이다.

이상적으로 명백한 기능 결함은 앞선 단계에서 식별되어야 한다.

일부 게임의 경우, 최종 플레이어가 초기 알파 테스트에도 참여하고 피드백을 제공할 수도 있다.

 

게임이 시장에 출시된 후 테스터의 임무는 플레이어가 보고한 메커니즘 결함을 처리 및 확인하고

게임에 추가되는 새로운 메커니즘을 테스트하는 것이다.

 

 

게임 메커니즘 테스팅의 중요성

 

게임 메커니즘은 게임의 핵심이며 플레이어의 관심을 유지하기 위해 중요한 유저 경험의 근간을 형성한다.

그렇기에 올바르게 동작하는지 테스트하는 것이 테스터에게 가장 높은 우선순위를 가지게 되며

이때 발견하는 결함이 가장 중요한 경우가 많다.

 

핵심 메커니즘에 결함이 생기게 되면 특정 장애물을 극복하지 못해서 결국 게임을 완수하지 못하게 될 수도 있다.

심지어 게임에서 거의 사용되지 않는 메커니즘이거나 게임을 완수하는 데 꼭 필요한 활동이 아니더라도

잘못된 동작은 게임 전체에 대한 인식에 부정적인 영향을 미치게 된다.

 

 

게임 메커니즘 리뷰의 중요성

 

게임 개발에서 게임 메커니즘을 설명하는 게임 문서의 작성은 중요한 단계이다.

게임 문서에는 게임 메커니즘 외에도 여러 정보가 담기게 된다.

 

개발 단계 초기에 게임 메커니즘 명세를 리뷰하면 나중에 많은 문제를 피할 수 있다.

이러한 문제는 개발 프로세스뿐만 아니라 최종 제품에 구현된 게임 메커니즘에 대한 플레이어의 반응과 관련이 있을 수 있다.

 

리뷰 과정에서 테스터는 다음 품질 특성[ISO 25010]에 주의를 기울여야한다.

• 설명의 완전성
• 현실과의 일치
• 문서의 구조와 탐색 용의성

게임 개발 프로세스에서 리뷰로 예방할 수 있는 문제

• 모호하고 구체적이지 않은 메커니즘 설명으로 인한 메커니즘의 본질에 대한 개발자의 잘못된 이해와 필요 노력에 대한 잘못된 평가
• 새로운 메커니즘과 기존 메커니즘의 비 호환성
• 특정 프로젝트에 메커니즘을 구현할 수 없는 경우

리뷰로 예방할 수 있는 메커니즘에 대한 플레이어의 인식과 관련된 문제

• 특정 게임에서 메커니즘의 전반적인 부적절함
• 흥미롭지 않은 메커니즘
• 불공정한 메커니즘
• 게임에서 너무 드물게 사용되는 메커니즘

 

세션 재개 후 및 사용자가 비활성 상태일 때의 비디오게임 상태 테스팅

 

비디오게임 상태

비디오게임 상태란 특정 순간에 게임 내의 모든 오브젝트를 설명하는 모든 변수와 변수 값을 말한다.

게임이 복잡해지고 플레이어가 수행할 수 있는 행동이 많아질수록 각 오브젝트는 더 많은 변수를 가지게 된다.

 

모든 변수는 조건에 따라 드러난 것과 숨겨진 것으로 구별할 수 있다.

 

드러난 변수의 값에 대한 정보는 플레이어에게 명시적으로 제공되며 다음이 포함된다.

• 완료한 작업으로 인한 게임 내 사용자 경험치 수준
• 선택한 무기의 특성
• 인벤토리에 허용되는 아이템 수
• 게임 내 상점의 상품 가격

숨겨진 변수는 개발자에 의해 플레이어가 인지하지 못하는 사이에 게임 진행에 영향을 미치기 위해 사용한다.

숨겨진 변수는 게임의 다양한 측면을 담당할 수 있다.

• 드랍률, 즉 보상으로 무작위 아이템을 획득할 확률
• 발사 속도 또는 다양한 표면에서 물체의 이동 속도

플레이어의 선택은 게임 플롯의 전개에 영향을 미친다.

플레이어가 제어하는 게임 캐릭터와 기타 여러 오브젝트를 정의하는 고유의 숨겨진 명시적 변수 집합이 있다.

 

비디오게임 상태 테스팅의 목적

게임 변수를 테스트할 때 중요한 요소 중 하나는 게임이 변수의 실제 값을 정말로 사용하는지 테스트하는 것이다.

 

드러난 변수의 경우, 표시된 값을 실제로 사용된 값과 시각적으로 비교하여 테스팅을 수행한다.

이러한 테스트는 새로운 피해량 정보가 게임 내 도움말 형식으로 플레이어에게 제공되는 경우에 특히 중요하며,

플레이어도 도움말에 표시된 값을 실제 피해량과 비교할 수 있다.

 

일반적인 플레이어는 보통 특정 변수 값을 고려하지 않고 피해량 변화의 적절성과 일관성에만 관심을 둔다.

플레이어는 피해량이 정확하지 않은 것으로 결함을 간주하지 않을 수 있지만,

피해량이 바뀌지 않거나 되려 감소하게 되면 분명히 인식하게 된다.

 

전문 테스터는 문서에 명시된 계산 공식 및 원칙에 따라 테스트를 수행한다.

이러한 정보를 문서에서 얻을 수 없다면 테스터는 플레이어와 마찬가지로 상식에 따라 상대적으로 평가를 수행하게 된다.

 

숨겨진 변수를 테스트하기 위해 테스터는 때때로 게임 데이터베이스에 접근해야 할 수도 있다.

그렇게 해서 테스터는 변수의 실제 값을 예상 값과 비교할 수 있다.

또한 사용자가 게임 중에 캐릭터와 연관된 드러난 변수를 바꿀 수 있다면,

변수를 변경하는 것 자체와 표시된 값의 정확성도 테스트하게 된다.

 

비디오 게임 상태 테스팅은 게임 저장 및 불러오기와 밀접한 관련이 있다.

 

저장 및 불러오기

게임을 단일 세션 내에 완료하는 게 불가능하거나 원칙적으로 게임플레이에 끝이 없는 경우도 많다.

따라서 게임은 플레이어가 매번 처음부터 시작할 필요가 없도록 "저장과 불러오기"라는 비디오게임 상태 기능을 지원하게 된다.

저장을 사용하는 다른 이유로는 사용자가 게임 세계를 탐험하고, 게임이 제시하는 문제를 해결할 다양한 방법을 찾거나,

경우에 따라서는 게임 자체의 복잡성을 관리하기 위해서일 수도 있다.

플레이어가 어려운 장애물 앞에서 생존할 수 있는 기회가 있다면,

잘못된 행동으로 진행이 완전히 무효가 되는 경우보다 실패 비용이 적어진다.

 

저장은 하드 드라이브 또는 클라우드에 저장된 게임 진행 상황 정보를 말한다.

저장은 게임의 현재 상태에 대한 정보가 포함된 파일이 될 수 있다.

 

이러한 파일의 크기는 게임 자체보다 매우 작으며 일반적으로 다음 정보를 포함한다.

• 상태 정보를 저장해야 하는 오브젝트 목록
• 각 오브젝트에 대한 변경되는 변수 목록
• 게임에 현재 무슨 일이 일어나고 있는지 확일할 수 있는 각 변수에 대한 구체적인 코드

거의 모든 변수는 오브젝트가 될 수 있다.

그리고 그 상태는 게임 시스템에 의해 수정될 수 있으며 기억되어야 한다.

오브젝트에는 캐릭터의 체력 수준, 학습한 능력의 수, 게임 맵에서 캐릭터의 좌표 등이 있을 수 있다.

 

저장 유형과 테스팅 영역

저장 방법, 저장 파일 형식, 저장된 변수 목록은 게임마다 다를 수 있다.

비디오게임의 역사에서 진행 상황을 저장하기 위한 접근법은 여럿 발명되었으며,

가장 일반적으로 사용되는 것은 아래와 같다.

 

저장에 체크포인트 사용

저장은 개발자가 지정한 순간에 자동으로 발생하며,

다음 체크포인트에 도달하면 플레이어의 현재 진행 상황 정보를 덮어쓰게 된다.

체크포인트에 저장된 비디오게임 상태는 현재 게임 세션에 대해서만 저장되며 게임이 종료되면 삭제된다.

 

게임이 사용자가 체크포인트에 도달했음을 명시적으로 알려주지 않고 진행 상황을 저장하는 경우도 있다.

저장 및 불러오기의 정확성을 테스트하기 위해 테스터는 모든 체크포인트의 정확한 위치 목록을 제공하는 문서가 필요하다.

다른 저장 방법을 사용하는 경우 문서에 이러한 정보가 없거나 구체적으로 설명되어 있지 않을 수 있다.

 

고정 지점 저장 사용

개발자는 플레이어가 원할 경우 현재 진행 상황을 수동으로 저장할 수 있는 특수 지점을 어떤 장소에 배치하기도 한다.

이러한 지점은 일반적으로 소수의 비디오게임 오브젝트로 둘러싸여 있어서 저장 파일의 크기를 제한 할 수 있게 해준다.

 

자동 저장

이 방법은 체크포인트와 고정 지점 저장을 조합한 것이다.

플레이어의 진행 상황은 여러 지점에서 게임플레이 전반에 걸쳐 자동으로 저장된다.

이 경우 테스터의 임무는 저장이 제대로 되었는지, 모든 지점에서 달성한 비디오게임 상태를 불러올 수 있는지 확인하는 것이다.

 

수동 또는 자유 저장

사용자는 게임 메뉴의 특정 항목을 사용하여 게임 중 언제든지 저장할 수 있으며,

하나의 키를 누르거나 한 번의 클릭으로 저장 및 불러오기가 수행되도록 빠른 저장을 구현할 수도 있다.

 

자동 저장과 마찬가지로 수동 저장은 비디오게임 상태 정보가 포함된 특수 파일을 생성한다.

이 경우 테스팅에는 파일에서 불러오는 정보의 정확성, 파일명의 정확성, 운영 체제에서 파일의 위치,

새로운 버전의 게임에서의 올바른 동작 그리고 저장 파일 사용 가능성을 확인하는 것이 포함될 수 있다.

 

다음 설명에 해당하는 게임에서는 필요한 게임 레벨을 올바르게 불러오는지 테스트하는 것으로 충분하다.

• 게임이 올바른 경로와 통과 방법이 하나만 있다고 가정할 수 있다.
• 플레이어가 제어하는 게임 캐릭터가 레벨에 따라 바뀌지 않는다.

다음 설명에 해당하는 게임의 저장에는 게임 세션, 레벨, 캐릭터 등에 대한 더 구체적인 정보가 포함된다.

• 게임 캐릭터가 많은 변수를 가지고 있다.
• 위에서 설명한 변수가 플레이어의 게임 내 행동 및 결정에 따라 변경될 수 있다.

이런 게임의 경우 테스터는 필요한 게임 레벨과 고유 정보뿐만 아니라

개별 플레이어 및 게임 캐릭터에 관한 고유 정보를 불러오는 것의 정확성을 테스트해야 하며,

저장을 테스트할 때 테스터는 다음을 확인해야 한다.

• 플레이어가 이전 게임 세션을 마친 게임 레벨에 있다.
• 플레이 가능한 캐릭터가 아이템을 가지고 있다.
• 게임 캐릭터의 속도 변수가 실제로 아이템으로 인해 증가했다.