ISTQB_FL_2018v.3.1_샘플문제_A_v1.7_한글_v0.1 (오답)

ISTQB_FL_2018v.3.1_샘플문제_A_v1.7_한글_v0.1

 

1. 테스트 컨디션(Test Condition) 이란

하나 또는 그 이상의 테스트 케이스에 의해 검증될 수 있는 항목 또는 이벤트.

테스트 베이시스(basis)로 파악된 컴포넌트나 시스템의 실행 가능한 측면

 

* 테스트 베이시스(basis) : 요구사항을 내포하고 있는 모든 문서. 테스트 케이스는 테스트 베이시스(basis)를 토대로 만들어 진다.

 

- 테스트 분석 : 무엇을 테스트할 것인가

   ㄴ 요구사항 명세. 비즈니스 요구사항, 기능 요구사항, 시스템 요구사항, 사용자 스토리, 에픽, 유스케이스

   ㄴ 기능/비기능 컴포넌트나 시스템 동작이 명시된 유사 작업 산출물

   ㄴ 설계와 구현 정보. 시스템이나 소프트웨어 아키텍처 다이어그램, 설계 명세, 콜 흐름도

 

- 테스트 설계 : 어떻게 테스트할 것인가

   ㄴ 테스트 케이스와 테스트 케이스 세트 설계 및 우선순위 설정

   ㄴ 테스트 컨디션과 테스트 케이스에 필요한 테스트 데이터 식별

   ㄴ 테스트 환경 설계와 필요한 인프라 및 도구 식별

   

2. 사용자 인수 테스팅

인수 테스팅에서 테스트는 기능적 요구사항 문서에 정의된 모든 워크플로우를 다루도록 설계된다.

 

* 인수 테스팅 이란 : 사용자 스토리를 기능적으로 테스트하는 것을 의마한다.

사용자 스토리를 기반으로 개발된 소프트웨어가 실제로 고객의 요구 사항을 만족시키는 것이 최종 목표로 설정된다.

 

3. 컴포넌트 테스팅과 시스템 테스팅

- 컴포넌트 테스팅 : 단위 테스팅이라고도 불리며, 테스트가 가능한 단위로 나누어진 소프트웨어 내에서 결함을 찾고 기능 검증

테스트 베이시스로 사용하는 산출물의 예로 상세 설계, 코드, 데이터 모델, 컴포넌트 명세 등이 있다.

 

- 스텁 : 골격만 있는 특별한 목적의 소프트웨어 컴포넌트를 구현한 것

- 드라이버 : 컴포넌트나 시스템을 제어하거나 호출하는 상위 컴포넌트를 대체하는 테스트용의 소프트웨어 컴포넌트 또는 툴

 

- 시스템 테스팅 : 전체 시스템의 기능과 성능을 검증한다. 특히 '성능'을 집중적으로 봄

테스트 베이시스로 사용하는 산출물의 예로 시스템 및 소프트웨어 요구사항 명세서(기능 및 비기능), 유스케이스 등 이 있다.

 

- 통합 테스팅 : 컴포넌트 테스팅(단위 테스트)로 검증이 끝난 모듈들을 결합한 후, 각 모듈간 상호작용이 잘 일어나는지 확인

단위 테스트에서는 오류가 없더라도, 모듈 간 파라미터나 공유 데이터에서 문제가 발생하는 경우 존재

 

4. 개발 모델

- 점진적 개발 모델 : 제품이 완성될 때까지 점진적으로 보완하고 조금씩 추가되어 테스트 진행

폭포수 모델의 요소와 프로토 타이핑의 반복 철학을 결합

 

- 순차적 모델 : 개발 프로세스 단계는 이전 단계를 완료할 때 시작해야 한다.

- 폭포수 모델 : 테스팅은 개발을 완료한 후 수행하는 별도의 단계로 간주한다.

 

5. 공식 리뷰의 역할 담당자

- 저자(Author) : 리뷰 대상 작업 산출물 작성, 리뷰 대상 작업 산출물 결함 수정

- 관리자(Management) : 리뷰 계획 담당, 리뷰 실행 결정, 인력/예산/시간 할당, 진행 비용 대비 효과 모니터링, 제어 결정 실행

- 촉진자(Facilitator)/중재자(moderator) : 효과적 회의 진행 보장, 다양한 관점들에 대한 중재, 리뷰 성공 여부에 대한 결정적인 역할

- 리뷰 리더(Reivew leader) : 전반적으로 리뷰에 대한 책임을 지는 사람, 참여자를 결정하고 언제 어디서 진행할지 결정

- 검토자 : (Reviewers) : 해당 주제에 대한 전문가, 프로젝트 참여 인원, 리뷰 대상 작업 산출물의 결함 식별

- 서기(Scribe) / 기록자(Recoder) : 개별 리뷰 활동에서 발견한 잠재 결함 수집, 새로운 잠재결함 쟁점, 결정사항 기록

 

6. 리뷰 유형

- 비공식 리뷰 (버디체크, 페어링, 짝 리뷰) : 잠재적 결함 발견

 

- 워크쓰루 : 결함발견, 소프트웨어 제품 개선, 다른 구현 방법 고려

리뷰 회의는 일반적으로 작업 산출물의 저자(Author)가 주도, 서기(Scribe) 참여 필수

 

- 기술리뷰 : 합의도출, 잠재적 결함 발견

검토자(Reviewers)는 저자의 기술 동료이면서, 동일 분야의 기술 전문가여야함

서기 필수, 저자(Author)가 아닌 사람이 수행, 잠재 결함 로그와 리뷰 보고서 작성

 

- 인스펙션 : 잠재적 결함발견, 저자 학습과 근본 원인 분석을 통한 유사 결함 발생 예방

체크리스트를 기반으로 공식 문서 산출물을 작성하는 정의된 프로세스를 수행

검토자(Reviewer)는 저자의 동료 또는 작업 산출물과 연관된 분야의 전문가, 서기(Scribe) 참여 필수

 

6. 구문 커버리지와 결정 커버리지

- 구문 커버리지 : 프로그램을 구성하는 모든 문장들이 최소한 한번은 실행될 수 있는 입력 데이터를 테스트 데이터로 선정하는 기준

 

- 결정 커버리지 : 각 조건문이 True 또는 False가 되는 조건이 모두 테스트되는 정도를 측정하는 척도

 

* 결정 커버리지는 구문 커버리지 달성을 보장한다. 그러나 반대는 불성립

 

7. 탐색적 테스팅

요구사항 문서나 사용자 스토리에 없는 다양한 상황에서 애플리케이션의 작동을 탐색

요구사항과 구현된 기능 사용자 사용흐름 간의 관계에서 애플리세이션의 품질을 향상시키기 위한 흐름을 파악하는데 목적

한정된 시간간에 집중적으로 대상 기능이나 법위에 한정하여 테스트를 수행하면서 경험을 기반으로 수행.

 

8. 테스트의 일반적인 완료 조건

1. 측정된 신뢰성

2. 테스트 커버리지

3. 테스트 비용

4. 수정하는 결함과 잔존 리스크에 대한 상태와 일정

 

9. 테스트 요약 보고서 내용

1. 테스트 접근법과의 차이

2. 완료 기준 대비 실제 진척률 측정

3. 테스트 대상의 품질 평가

 

10. 테스트 추정

- 메트릭 기반 접근법 : 공식적이거나 비슷한 프로젝트에서 측정한 메트릭이나 전형적인 값을 기반으로 테스팅

- 전문성 기반 접근법 : 전문가나 작업자가 스스로 작업을 예측

 

11. 정적분석 도구

코드를 검사하여 메모리 누수 또는 버퍼 오버플로우 등 일반적으로 알려진 오류 및 취약점 파악