본 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
샘플문제해설 한글판(V1.0.1)이 수정, 업로드 되었습니다. - 2024.12.2 by KSTQB Team 샘플문제 한글판(V1.1)이 업로드 되었습니다. - 2024.8.16 by KSTQB Team ISTQB® 게임 테스팅(CT-GaMe) v1.0.1 실러버스와 샘플문제
www.kstqb.org
게임의 그래픽 테스팅 접근법
아티스틱(Artistic) 테스팅
그래픽 오브젝트를 만드는 과정은 여러 단계와 리뷰를 거치게 된다.
누군가는 디자인을 만들고 누군가는 그것을 애플리케이션에 통합하는데,
그렇기 때문에 결과물이 디자이너가 의도한 것과 다를 수 있다.
테스터는 디자인의 표준 준수 여부를 테스트하고 결함을 식별할 수 있지만,
배경의 투명도가 충분하지 않거나 애플리케이션의 해상도를 변경할 때 동작하지 않는 결함처럼
아티스트가 더 쉽게 알아차릴 수 있는 결함도 있다.
반대로 아티스트가 모든 것을 예상할 수 없으며, 실행 중인 애플리케이션에서만 이미 장애가 되어버린 결함을 인식할 수도 있다.
따라서 중요한 결함을 제거하기 위해 구현 후 디자이너가 애플리케이션을 리뷰할 수 있도록 제공하는 것이 좋다.
이 과정에서 테스터는 필요한 환경을 준비하고, 테스트 계정을 만들고, 테스트 후 결함을 설명한 다음 이를 테스트하거나 리뷰를 위해 아티스트에게 보낼 수 있다.
콘텐츠가 많은 프로젝트에는 주로 모델을 만드는 과정을 구체적으로 이해하는 아티스트들처럼
그래픽 테스팅에 참여하는 별도의 전문가가 있는 경우가 많으며 다음 모델 생성 단계를 확인한다.
- 형상 생성
- 텍스쳐 생성
- 충돌 모델 생성
이 작업의 목표는 비디오게임 엔진으로 내보내기 전에 모델의 품질을 향상하는 것인데
형상 다각형, 위치 정확성, 모델 전개 정확성, 너무 긴 다각형의 존재 여부, 모델의 이음새와 같은 측면과
같은 예시를 테스트한다.
아티스틱 테스팅은 가장 단순한 형상과 텍스쳐를 만드는 것부터 모델을 엔진으로 내보내고 맵에 배치하는 작업까지
다양한 개발 단계에서 수행할 수 있는 크고 복잡한 작업이다.
아티스틱 테스팅을 수행하기 위해 테스터는 특별한 도구나 콘첸츠 에디터가 필요하지 않는 경우가 많다.
게임을 실행하면서 직접 실행할 수 있다.
그러나 도구 및 콘텐츠 에디터를 사용할 수 있다면 결함을 훨씬 빠르고 효율적으로 식별할 수 있다.
아티스틱 테스팅은 다음에 의해 수행된다.
| 역할 | 아티스틱 테스팅에서 책임 |
| 아티스트 | 오브젝트를 리뷰할 때 오브젝트를 관찰하고 평가할 때 |
| 3D 모델러 | 오브젝트를 리뷰할 때 |
| 슈퍼바이저 | 오브젝트를 관찰하고 평가할 때 |
| 테스팅 엔지니어 | 모델을 엔진으로 최종 내보낸 후 |
| 플레이어 | 플레이 테스트에 참여할 때 |
기술적 테스팅
기술적 테스팅은 다음과 같은 그래픽의 기술 변수와 관련된 일련의 작업(Tasks)에 연관성을 가진다.
- 모델 폴리곤 수 제한 준수
- 텍스쳐 형식
- LoD 스위칭 거리, 사용할 수 있는 자원을 명세와 비교하는 것으로 충분함
기술적 테스팅 자체는 테스터와 기술적 아티스트가 수행하며 여기에는 다음에서 설명하고 있는 절차가 포함된다.
그래픽 콘텐츠 자원에서 사용하지 않는 파일이나 임시 파일 검색
개발자가 사용하지 않는 자원을 포함한 모든 자원을 저장소에 저장할 경우
게임 클라이언트가 하드디스크에 점유하는 공간의 크기가 늘어나며 성능에 부정적인 영향을 주게 되며,
개별 비디오게임 파일 업데이트처럼 플레이어에게 전달해야 하는 패치의 수가 늘어나게 된다.
이러한 예시처럼 아티스트가 작업할 때 나중에 사용하지 않는 자원을 실수로 저장소에 추가할 수 있는데
이를 예방하기 위해 사용하지 않는 자원 검색을 수행한다.
클라이언트의 자원에 필요한 모든 콘텐츠 레코드가 있는지 검색
게임 클라이언트 자원에 그래픽 콘텐츠가 다른 자원과 독립해서 존재하지 않는다.
텍스쳐에 대한 참조는 모델에 작성되고 모델에 대한 참조는 맵에 작성된다.
그러한 레코드에 가장 작은 결함조차도 예기치 않은 결과를 초래할 수 있다.
텍스쳐 형식 테스팅
각 텍스쳐 유형에 대해 기술 아티스느는 자체 요구사항을 설정한다.
이는 콘텐츠의 성능과 시각적 구성요소 간의 균형을 유지해야 하기 때문이다.
텍스쳐 형식은 압축 유형과 크기를 말한다.
콘텐츠 테스팅 중 클라이언트 로그 테스팅
때로는 클라이언트 하위 시스템이 하는 일이 별로 눈에 띄지 않을 수 있다.
플레이어는 결함이 있어도 결함을 볼 수 없는 상황이 있는데
이러한 결함을 찾으려면 리소스에 존재하지 않는 텍스쳐를 사용해서 렌더링하려고 했다고
기록돼 있을 클라이언트의 로그를 조사해야 한다.
텍스쳐, 모델 수에 대한 제한 준수 확인
각 콘텐츠 유형에는 보통 특정 그룹에 적용되는 고유한 제한이 있다.
콘텐츠 편집은 지속해서 이루어지고 저장소에 다운로드하는 횟수가 많기 때문에
모델을 새로 내보낼 때마다 비디오 프로세서 모델 계산에 필요한 하드웨어 자원 부족 사태를 방지하기 위해
제약 및 요구사항 준수를 테스트해야 한다.
기술적 테스팅은 단순한 테스트이지만 그것의 중요성을 이해하는 것이 중요하다.
그래픽은 전체 시스템 성능에 큰 영향을 미칠 수 있다.
따라서 기술적 테스팅에는 게임의 성능과 크기가 원하는 수준으로 유지되도록 하기 위해 성능 테스팅이 포함된다.
텍스쳐와 모델의 수를 늘리면 빌드 크기도 증가한다.
텍스쳐 형식의 불일치는 프레임 속도를 악화시켜 클라이언트에서 사용하는 메모리를 늘어나게 한다.
기술적 테스팅은 아티스틱 콘텐츠가 플레이어에게 최대한 완전하게 전달되도록 한다.
게임플레이 테스팅
게임플레이 테스팅은 게임플레이에 영향을 미치는 요소를 대상으로 하는 테스트 접근법이다.
이는 시각적 모델과 충돌 모델의 적합성 평가와 게임플레이 오브젝트 설정이 게임 모드의 요구사항을 준수하는지 확인하는 것 등을 포함한다.
오브젝트의 게임플레이 테스팅은 다음을 포함한다.
- 체력이 올바르게 적용하는지 테스트한다. 이것은 롤플레잉 및 컴퓨터 게임에서 오브젝트를 파괴하기 위해 오브젝트에 가해야 하는 최대 피해량을 결정하는 값이다. HP는 오브젝트의 구성 재료, 크기, 유형을 고려하여 자동으로 할당됨에도 불구하고 여젼히 결함이 나타날 수 있다. 따라서 HP 할당은 오브젝트 특성에 따라 수동으로 테스트한다.
- 충돌 모델이 시각적 모델과 일치하는지 테스트한다. 앞서 언급했듯이 충돌 모델은 시각적 모델보다 상당히 단순하다. 이에 따라 플레이어가 시각적으로는 모델 뒤에 숨어 있지만 적이 여전히 피해를 줄 수 있는 결함이 발생할 수 있다.
그래픽 테스팅은 복잡한 과정으로 유형에 따라 서로 중첩되는 부분이 있다.
위에서 설명한 테스트 접근법은 게임의 그래픽 콘텐츠가 여러 단계에서 철저하게 테스트되어 그래픽 결함이 식별될 수 있도록 한다.
오브젝트 개발의 여러 단계에서의 그래픽 테스트 실행
그레이 박스 생성
그래픽 오브젝트의 단순화된 모델로 실제 게임플레이를 테스트하는 데 사용하는 모형이다.
이 단계에서 식별하는 결함은 주로 아티스트가 이 모델을 사용할 때의 편의성과 관련이 있다.
시각적 형상 생성
모델링 및 매핑의 다음 단계는 환경을 대변하는 물리적 오브젝트에 3D 투사체를 매핑 및 생성하는 것이다.
여기에는 공간에서의 형상과 위치가 고려되며, 모델의 가시적 형상 및 UV 전개가 만들어지고
3D 오브젝트 표면의 좌표(X, Y, Z)와 텍스쳐 좌표(U, V) 간의 대응 관계가 확인된다.
인스펙션은 3D 그래픽 에디터를 사용하여 수행하는 경우가 많기 때문에
이 단계의 결함은 아티스트와 3D 모델러도 식별할 수 있다.
일반적으로 이러한 결함에는 다음이 포함된다.
- 과도한 세부 사항.
- 불충분한 세부 사항. 이러한 유형의 결함은 과도한 세부 사항 결함과 반대되는 개념이다. 모델이 플레이어에게 명확하게 보이는 경우 각진 것처럼 보이지 않도록 상세하게 표현돼야 한다.
- 렌더링 되지 않은 일부 형상
모델 텍스쳐 추가
이 단계에서 텍스쳐를 아티스트 또는 아트 디렉터가 받아들이게 된다.
이 경우 애플리케이션의 올바르지 않는 텍스쳐 적용, 이음새 없음 및 당김이 발견되지 않을 수 있다.
여기서의 테스트는 일반적으로 색상 팔레트와 오염 수준과만 관련된다.
이 단계에서 식별하는 보편적인 결함은 자동 매핑 및 후속 텍스쳐 추가로 서로 겹치는 복수의 모델이 겹치는 부분에서
서로 다른 색상의 텍스쳐가 적용되어 이음새가 눈에 띄는 경우이다.
오브젝트의 LoD 및 충돌 모델 리뷰
이 단계에서 아티스트와 레벨 디자이너 모두 모델의 품질을 평가하는데 참여한다.
레벨 디자이너는 충돌 모델이 게임플레이에 미치는 영향을 평가한다.
여기서 식별하는 보편적인 결함은 너무 상세하거나 필요한만큼 상세하지 않은 모델이다.
비디오게임 엔진으로 모델 내보내기
여기서는 거리에 따른 LoD 전환 설정과 오브젝트의 체력값의 정확성을 고려한다.
테스팅은 테스터가 콘텐츠 에디터와 게임 애플리케이션 모두를 활용해서 게임 엔진에서 직접 수행한다.
동시에 대부분의 아티스틱 테스트는 오브젝트에 대한 시각적 평가로 축소되며
많은 테스트가 이미 아티스트와 모델러가 수행한 테스트와 중복된다.
테스팅은 다음을 다루게 된다.
- 오브젝트가 사용될 위치와 상황을 고려한 오브젝트의 LoD 전환 가시성
- 플레이어의 눈에 띌 오브젝트 형상의 틈과 이음새
- 다양한 그래픽 오브젝트에 새겨진 글의 가시성
- 모델의 파괴 효과
- 오브젝트 애니메이션의 시각적 결함
아티스틱 테스팅에서 플레이어는 콘텐츠를 시각적으로 평가하고 다른 그래픽 결함을 식별하는 데 직접 참여할 수 있다.
그래픽 테스팅은 게임 맵 테스팅과 함께 수행하는 경우가 많은데,
이 경우 몇가지 단계가 더 존재한다.
맵에 오브젝트 배치
이 단계는 테스팅에서 가장 중요한 단계의 하나이다.
오브젝트 배치는 레벨 디자이너가 수행하며
이 과정에서 발생하는 보편적인 결함은 맵 아래에 "매달리거나" 움푹 들어간 오브젝트이다.
이것은 지형의 형상을 변경하고, 오브젝트르 배치하고, 맵 자체를 편집할 수 있는 많은 전문가가 동시에 맵을 작업할 때 종종 발생한다.
효과 만들기 및 배치
이 단계에서 효과 아티스트는 새로운 특수 효과를 만드는 작업을 한다.
다양한 상황에서 이를 관찰하면 아티스틱, 기술적 렌더링 결함을 감지할 수 있다.
이러한 테스트의 예로는 엔진에서 효과의 시각적 테스트가 있다.
효과 아티스트는 게임 클라이언트에서 각 효과를 확인하며 잘못된 효과변수를 식별한다.
그래픽 테스팅은 플레이 테스트르 사용하여 수행하는 경우가 많다.
이는 게임 상황에서 맵을 테스트하는 모든 테스팅과 관련이 있다.
이 테스팅의 목표는 광범위하며 모든 개발 단계에 적용된다.
개발이 끝날 무렵에는 플레이어의 관점에서의 맵에 대한 아티스틱 평가와 게임플레이 평가가 포함될 수 있다.
게임 디자이너가 맵의 밸런스를 조정하는 데 필요한 통계를 수집하는 것 외에도
이러한 테스트는 매달려 있는 오브젝트에서부터 그래픽 렌더링 결함에 이르기까지
다양한 아티스틱 및 기술적 문제를 식별할 수 있다.
맵 테스팅
이것은 맵이 완전히 준비되고 더 이상 수정되지 않을 때 수행하는 테스팅의 마지막 단계이다.
테스터는 매달린 오브젝트에서부터 테스트 애니메이션까지 찾는 맵 밸리데이션 체크리스트를 기반으로
전체 맵에 대한 벨리데이션을 수행한다.
테스터는 아티스트보다 더 많은 결함을 식별할 수 있는 테스트에 중접을 둔다.
아티스트 테스트 중 아티스트는 맵을 시각적으로 검토하는 반면 테스터는 특수한 도구 세트를 사용하여 문제가 될 소지가 있는 사항을 그래픽 오브젝트에서 식별한다.
역사적 사실의 정확도를 위한 그래픽 테스팅
그래픽 콘텐츠 테스팅의 또 다른 영역은 역사적 사실의 정확도 테스팅이다.
역사적 사실의 정확도는 역사적 사실의 정확성과 역사적 사실의 진위를 모두 고려한다.
역사적 사실의 진위는 게임의 품질에 영향을 미치고 특정 역사적인 사건을 특징적인 이미지를 사용하여
설명하는 것과 관련된다.
여기에 특정 사건, 인물 등이 언급되지는 않는다.
역사적 사실의 정확성도 게임으 품질에 영향을 미치며, 특정 역사적 사실의 기간에 대한 설명과 관련된다.
모든 주요 사건은 그 시대의 이미지 특성과 관련된 인물 및 그들의 행동을 포함한 동작으로 설명된다.
시대에 이질적인 이미지는 근본적으로 배제된다.
일반적으로 게임은 중독성 있는 게임플레이를 만드는 것에 초점을 두기 때문에
역사적 사실의 진위를 항상 유지하는 것은 불가능하다.
처음부터 결과가 정해진 게임에 플레이어를 참여시키기는 어렵다.
그러나 역사적 사실의 정확성은, 특히 게임 줄거리가 특정 역사 시대와 연결된 경우 특별히 주의가 필요한 게임 영역이다.
역사적 사실의 정확성을 위해 그래픽 콘텐츠를 테스트 할 때 고려해야 할 보편적인 요소는 다음과 같다.
- 역사적 사실의 원형과 캐릭터의 유사성
- 건축 오브젝트를 재현할 때의 정확성
- 특정 시대의 무기, 장비, 차량, 의복과 그 특성을 재현할 때의 정확성
- 일상생활 재현의 정확성
- 역사적인 사건과 날짜의 정확성
역사적 사실의 정확도 테스팅을 수행할 때 테스터는 광범위한 지식과 시야를 가져야 한다.
개발자는 최대한 현실적인 게임을 만들기 위해 게임을 테스트할 대 역사 컨설턴트를 참여시키는 경우가 많다.
그래픽 테스팅 지원 도구
콘텐츠를 테스트할 때 그래픽 테스터는 게임 콘텐츠 에디터에서부터 자동화 도구와 테스트 스크립트까지 다양한 도구를 사용한다.
일반적으로 게임은 오브젝트 에디터, 월드 에디터, 조명 에디터 등 그래픽 테스팅 도구뿐만 아니라
여러 내장 도구가 포함된 비디오게임 엔진을 사용하여 개발한다.
모든 도구는 플레이어가 상호작용 할 수 있도록 기존 콘텐츠를 사용자가 지정해서 수정할 수 있게 하는 기능을 제공한다.
모델 에디터를 사용하면 엔진과 상호작용할 때 나타나는 다양한 트리거, 사운드, 기타 이벤트 등의 효과를 모델에 결합할 수 있다.
월드 에디터르 사용하면 맵을 만들고, 그 위에 오브젝트를 배치하고, 맵의 게임플레이 메커니즘을 수정할 수 있다.
테스터는 대부분의 테스트를 이 에디터에서 수행하게 된다.
그렇기 때문에 개발자와 동일한 도구를 사용하게 되는데,
이러한 에디터는 또한 콘텐츠를 설정하고 테스팅을 할 수 있는 광범위한 툴킷을 제공한다.
특별한 도구는 일반적으로 그래픽카드 제조업체에서 개발한다.
이러한 도구를 사용하면 게임에서 프레임을 캡처하고 2D 및 3D 그래픽을 만들기 위한 다양한 API 세트를 사용하는 모든 애플리케이션을 자세히 분석할 수 있다.
또한, 다음을 평가할 수 있다.
- 게임 플레임이 준비되는 방식
- 성능 문제가 발생하는 영역
- 달리기의 형태
- 3D 모델러, 그래픽 디자이너, 애니메이션 디자이너를 위한 디버깅
이러한 도구의 사용 방법에 대한 자세한 내용은 해당 소프트웨어 명세에 설명되어 있다.
그래픽 테스팅 도구에는 게임에서 특정 경로를 따라 캐릭터가 자동으로 이동하는 기능을 제공하는
자동화 스크립트가 포함되어 있다.
이런 기능은 성능 및 호환성 테스팅에 사용한다.
'etc. > ISTQB CT-GaMe 실러버스를 다시 공부하며' 카테고리의 다른 글
| ISTQB CT-GaMe 실러버스를 다시 공부하며 (5. 레벨 테스팅) (0) | 2026.04.23 |
|---|---|
| ISTQB CT-GaMe 실러버스를 다시 공부하며 (4. 사운드 테스팅) (0) | 2026.04.22 |
| ISTQB CT-GaMe 실러버스를 다시 공부하며 (3. 그래픽 테스팅1) (0) | 2026.04.17 |
| ISTQB CT-GaMe 실러버스를 다시 공부하며 (2. 게임 메커니즘 테스팅) (2) | 2026.04.14 |
| ISTQB CT-GaMe 실러버스를 다시 공부하며 (1. 게임 테스팅 개요) (0) | 2026.04.13 |