[ISTQB CTFL] 실라버스 C유형 문제 정리/요약 (21~40번)

 

 

 

 

 

 

 

 

 

 

* 탐색적 테스팅

테스터의 기술과 경험을 활용하는 경험 기반 테스팅의 한 형태

 

 

 

 

* 체크리스트 기반 테스팅

- 체크리스트에 기록된 테스트 컨디션을 커버하기 위해 테스터가 테스트를 설계, 구현, 실행

 

 

 

 

 

* 결정 테스팅

- 결정 지점에서 발생하는 제어 흐름을 따르는 테스트 케이스를 포함

 

 

 

 

* 루프 구조에서 구문 커버러지와 결정 커버리지

- 구문 커버리지 : 루프 안의 모든 구문이 실행되는 것을 요구

- 결정 커버리지 : 루프가 실행되는 조건과 건너뛰는 조건을 모두 테스트

 

 

 

 

 

* 경계값 분석 vs 동등분할 예제

ex)

최소 유효 단위는 0.5단위, 최대 유효 단위는 25단위, (단위의 정밀도는 0.1) => 비유효(0.4이하), 유효(0.5 ~ 25), 비유효(25.1이상)

 결과:

경계값 분석 ( 0.4 / 0.5 / 25 / 25.1 )

동등분할 ( 0.4이하에서 1개 / 0.5 ~ 25에서 1개 / 25.1 이상에서 1개)

 

 

 

 

 

 

* 결정 테이블 테스팅

테스트 케이스가 결정 테이블에 표시된 입력값과 자극(원인)의 조합을 테스트하도록 설계하는 블랙박스 설계기법

(예제)

유효한 계정/비밀번호가 아닌 경우는 두 가지 동등분할 영역이 있다. 하나는 계정이 유효하지 않은 경우이고, 다른 하나는 비밀번호가 유효하지 않은 경우.   유효 계정/비밀번호에 대한 동등 분할 영역을 커버하면서 결정 테이블 경우의 수도 만족하기 위한 테스트를 설계. 최소 몇 개의 테스트가 필요한가?

조건	1	2	3
유효 계정/비밀번호	N	Y	Y
충분한 포인트	-	N	Y
예상결과
항공 이력 보기	N	Y	Y
포인트로 항공권 결제	N	N	Y

 

풀이)

조건	1	2	3
유효 계정/비밀번호	N(계정과 비밀번호중 어떤게 유효하지 않은지 모름)	Y(계정+비번 모두 유효)	Y(계정+비번 모두 유효)

 

조건	1	2	3	4
유효 계정/비밀번호	N (계정 비유효)	N (비번 비유효)	Y (계정+비번 모두 유효)	Y (계정+비번 모두 유효)

 

이렇게 최소 4가지의 테스트 개수가 필요.

 

 

 

 

 

 

 

* 상태 전이 다이어그램 문제

ex)

각 테스트가 시작 상태인 ‘대기’에서 시작하여 다시 시작 상태로 돌아오면 끝난다고 가정할 때, 최소 몇 개의 테스트가 필요한가?

 

총 4

 

 

 

 

 

 

* 종속성 문제 예제

테스트 케이스 번호	테스트 컨디션	우선 순위	논리적 종속성
001	음식 유형 선택	3	없음
002	음식점 선택	2	001
003	길찾기	1	002
004	음식점에 전화	1	002
005	예약	3	002

1. 우선순위 1인 003과 004부터 시작

2. 003, 004은 002에 종속되므로 002->003->004 또는 002->004->003

3. 002는 001에 종속되므로 001->002->003->004 또는 001->002->004->003

4. 그리고 남은 순서은 005가 맨 마지막으로

001->002->003->004->005 또는 001->002->004->003->005 가 답.

 

 

 

 

* 테스팅에 사용하는 메트릭

테스트 케이스 준비율 : 테스트 준비 중에 사용하는 일반적인 메트릭

테스트 케이스 성공, 실패, 미실행율 등은 테스트 실행 중에 사용하는 일반적인 메트릭

 

 

 

* 리스크 레벨 : 부정적인 일이 발생할 가능성과 그 일로 인한 영향(피해)로 결정

 

 

 

* 테스트 추정기법

-메트릭 기반 기법 : 기존 유사한 프로젝트에서 얻은 메트릭에 기반하거나 보편적인 값을 바탕

-전문가 기반 기법 : 테스팅 작업의 책임자나 전문가의 경험을 기반

 

 

* 테스트 독립성의 이점

- 개발자와는 다른 유형의 장애를 찾아낼 수 있음

- 이해관계자의 가정에 이의를 제기할 수 있음

*단점

- 협업이 어렵고 피드백 전달이 늦어짐

- 품질에 대한 책임감을 잃을 수 있음

 

 

 

* 제품 리스크 vs 프로젝트 리스크

- 제품 리스크

작업 산출물(명세, 컴포넌트, 시스템, 테스트 등)이 사용자나 이해관계자의 합당한 니즈를 충족하지 못할 가능성

(품질 리스크 : 제품리스크가 제품의 특정 품질 특성과 연관되는 경우)

- 프로젝트 리스크

프로젝트 목적 달성 능력에 부정적인 영향을 줄 수 있는 상황

(프로젝트, 조직, 정치적, 기술적, 공급적 등등)

 

 

* 파일럿 프로젝트 목표

- 도구 지식의 습득 및 이해 ( 그 외에도 여러 도구에 대한 내용 )

- 목표한 가치를 적절한 비용으로 달성할수있는지 평가

 

 

 

* 테스트 도구

- 테스트 관리 도구 : 테스트 관리 도구는 (메트릭을 포함하여)테스트 관리자와 관련된 활동들을 지원

- 정적 분석 도구 : 테스팅 전체가 아니라 단지 코드와 관려

- 커버리지 도구 : 테스팅 전체가 아니라 테스트 베이시스의 커버리지와 코드 커버리지만을 보고

- 보안 도구 : 테스팅 전체가 아니라 특정 부분에 초점