[ISTQB] 외워야 할 부분

- 일반적으로 결정 커버리지와 조건/결정 커버리지를 달성하는 최소 테스트 케이스 수는 동일하다. 

- 제어 흐름 테스트(Control flow test)는 결정 포인트(Decision points)간의 흐름을 고려해 테스트하므로 100% 결정 커버리지를 달성할 수 있다.  

- 결정 포인트 간의 모든 논리적인 조합을 고려하는 테스팅은 결정 테이블 테스팅을 설명하는 것이다. 

- 반면, 결정 테스팅도 테스트 깊이 레벨을 높여 테스팅하면 거의 모든 논리적인 조합을 커버할 수는 있다. 

(5C - 29번)

다음중 테스트 프로젝트 관점에서 형상 관리에 대한 설명으로 틀린 것은?

1) 개발 수명주기 동안 나오는 시스템과 소프트웨어의 온전함을 확보하고 유지한다.

2) 테스트 문서화는 식별한 모든 개발 문서와 소프트웨어 아이템을 정확하게 참조한다.

3) 테스트케이스 명세를 개발 산출물과 연계해서 관리해 해당 개발 산출물의 테스트 커버리지를 높인다. 

4) 형상 관리 절차와 인프라는 테스트를 계획하는 동안 구현했다. 

(5C - 30번)

테스트웨어(Testware)의 모든( 품목 )이 식별되고, ( 버전 )이 제어(Control)된다. 그리고 변경 사항이 추적되고, 상호 연관되며, 테스트 대상과 연관된 테스트웨어의 ( 추적성 ) 이 테스트 프로세스 전반에 걸쳐 유지될 수 있다. 

- 리스크는 사용빈도 X 결함 가능성 X 손실로 계산이 가능하다. 

- 프로덕트 리스크는 조직적인 요소, 기술적 이슈, 공급자 이슈 등을 포함한다. 

(6C - 2번)

다음 중 테스트 관리 도구가 지원할 수 있는 업무는 무엇인가?

1) 테스트 실행

2) 테스트 진행 리포트

3) 인시던트 관리

4) 요구사항 관리
=> 테스트 관리 도구를 이용해 테스트 결과를 기록(Logging)하고 테스트 진행 상황에 대한 리포트(Progress report)를 생성할 수 있다. 

(6C - 4번)

다음 중 컴포넌트 테스트나 통합 테스트 단계에서 개발자가 유용하게 사용할 수 있는 테스트 도구가 아닌 것은?

1) 형상 관리 도구

2) 정적 분석 도구

3) 동적 분석 도구

4) 커버리지 측정 도구 

=> 컴포넌트 테스트나 통합 테스트 중에 개발자에게 보다 유용한 도구는 아래와 같은 것들이 있다.

정적 분석 도구, 모델링 도구, 테스트 하네스/유닛 테스트 프레임웍 도구, 커버리지 측정 도구, 동적 분석 도구 

(6C - 5번)

다음 중 테스트 실행과 로깅을 지원하는 도구의 유형에 속하지 않는 것은 무엇인가?

1) 테스트 비교자(Test comparators)

2) 커버리지 측정 도구(Coverage measurement tools)

3) 단위 테스트 프레임웍 도구(Unit test framework tools)

4) 테스트 데이터 준비 도구(Test data preparation tools)

=> 테스트 데이터 준비 도구는 테스트 설계 시에 사용한다.(테스트 실행 전) 

(6C -6 번)

소프트웨어 실행 중에 발생할 수 있는 메모리 누수(Memory leak)를 측정할 수 있는 도구는?

1) 동적 분석 도구

2) 성능 테스팅 도구

3) 스트레스 테스팅 도구

4) 모니터링 도구

=> 소프트웨어 실행 중에 메모리 누수는 동적 분석 도구가 발견할 수 있고, 소프트웨어를 실행하지 않고 코드를 분석해 메모리 누수를 발견하는 도구는 정적 분석 도구이다. 

(6C - 심화4번)

다음은 무엇에 대한 설명인가?

성능 테스팅 도구 또는 모니터링 도구로 컴포넌트나 시스템을 측정하고 있을 때 측정 계측 코드(Instrument)가 컴포넌트나 시스템에 미치는 영향을 말한다. 예를 들면 성능 테스팅 도구가 사용될 때 해당 도구의 사용이 테스트 대상 시스템의 성능에 약간의 영향을 줄 수 있다.

1) 가변성(Changeability)

2) 이상 현상(Anomaly)

3) 탐사 효과(Probe effect)

4) 침투 현상(Penetration phenomenon)

=> 침입적 도구를 사용해 달라진 결과를 탐사효과(Probe effect)라고 한다. 

 

 

A타입

- (1번) 테스트 컨디션(Test Condition) : 특정 테스트 목적 달성과 관련된 테스트 베이시스의 한 측면 

- (10번) 컴포넌트 테스팅의 테스트 케이스는 일반적으로 컴포넌트 명세서, 설계 명세서 또는 데이터 모델에서 도출하지만, 시스템 테스팅의 테스트 케이스는 요구사항 명세서나 유즈케이스로부터 도출한다. 

- (10번) 시스템 테스팅은 컴포넌트 간 인터페이스와 시스템의 각 부분 간 상호작용을 테스트 하지 않는다. 이는 통합 테스트의 목표이다. 

- (10번) 컴포넌트 테스팅은 기능적 측면에만 중점을 두지 않는다. 

- (10번) 일반적으로 컴포넌트 테스팅은 개발자가 수행하며, 시스템 테스팅은 테스터가 수행한다.

- (12번) 점진적 개발 모델을 가장 잘 정의한 것은? 요구사항 정의, 소프트웨어 설계 및 테스팅을 일련의 추가 작업으로 수행한다. 
=> 점진적 개발이 폭포수 모델을 말하는듯.. 

- (13번) 다음 중 유지보수 테스팅을 유발하는 요인이 아닌 것은? 소프트웨어의 유지보수성을 테스트하기로 했다.
=> 유지보수(maintenance) 테스팅이 아니라 유지보수성(maintainability) 테스팅이다.

=> 유지보수 테스팅과 유지보수성 테스팅에 대해서 문제가 자주 나오니 주의해야 겠다.

- (14번) 다음 중 공식 리뷰의 역할 담당자들로 구성된 것은? 작성자, 중재자, 리뷰 리더, 리뷰어, 서기

=> 단골... 

- (15번) 다음 중 공식 리뷰 계획 중에 수행하는 활동은 무엇인가?

=> 리뷰를 위한 입력 기준(input criteria)의 검증 

=> 착수 기준(entry criteria)을 확인하는 것은 공식 리뷰의 계획에서 이루어진다. 

- (17번) 정적 테스팅에 대해 가장 잘 설명한 것은?

=> 결함을 발견하고 제거하는 경제적인 방법이다, 사용자 요구사항에 대한 초기 확인이다. 
=> 사용자 요구 사항에 대한 초기 확인이다.
(요구사항의 누락, 부정확함, 일관성 부족, 모호함, 중복을 찾아내 설계나 코딩단계에서 발생하는 결함을 예방한다.)

- (20번) 블랙-박스 테스트 기법으로 분류할 수 있는 것은?

=> 공식 요구사항에 기반한 기법(블랙 박스 테스트 기법은 적절한 테스트 베이시스 분석을 기반으로 한다(예 : 공식 요구사항 문서, 명세서, 유스케이스, 사용자 스토리))

- (25번) 유효동등 파티션 
=> 모든 TC 수

- (26번) 동등 분할의 경계를 경계값

=> 50, 51, 55, 56, 60, 61처럼 딥하게 테스트할 수 있는 숫자들. 희안하게 0은 아니네 

- (28번) 상태 전이 다이어그램 

=> 유효 전이라 함은 한번씩 다 터치하는지 체크하는 부분.. 

- (35번) 

=> 탐색적 테스팅 -> 경험 기반 테스팅

=> 제어 알고리즘은 서버에서 '모델링'되므로 모델 기반 전략으로 테스트된다.

=> 리스크 기반 테스팅은 리스크 수준에 따라 테스트를 설계하고 우선순위를 결정하는 분석적 접근법의 예이다.

=> 테스트 전략은 주로 이해관계자, 비즈니스 도메인 전문가, 기술 전문가 등의 조언, 지도, 지시를 바탕으로 이루어진다. 이 사람들은 외부 테스트팀이나 외부 조직 소속일 수 있다. 

- (39번) 테스트 실행 도구의 가장 큰 이점은 무엇인가?

=> 리그레션 테스트 수행에 용이하다.(반복적인 수동 업무를 줄여 주어(예: 리그레션 테스트 수행, 환경 구축/해제 작업, 동일 테스트 재입력, 코딩표준 준수 확인) 시간을 절약하게 된다. 

- (40번) 테스트 도구와 분류를 바르게 연결한 것은?

테스팅과 테스트웨어의 관리 지원 도구 : 형상관리 도구

정적 테스팅 지원 도구 : 리뷰를 지원하는 도구

테스트 실행과 로깅 지원 도구 : 커버리지 측정 도구

성능 측정과 동적 분석 도구 : 성능 테스팅 도구/모니터링 도구/동적 분석 도구

 

 

문제집

유효한 전이와 비유요한 전이의 차이점은 뭐지?

3. 테스트 분석(Test analysis)과 테스트 설계(Test design) 단계에서 기대할 수 있는 작업은?

1) 테스트 목표(Test objectives)를 정의하고 설정한다

2) 테스트 베이시스(Test basis)를 리뷰(Review)한다.

3) 테스트 프로시저(Test procedures)에서 테스트 스위트(Test suites)를 작성한다.

4) 프로세스 개선에서 습득한 교훈(Lesson learned)을 분석한다.

=> 테스트 계획(제어) 다음 단계가 테스트 분석과 설계다. 문제에서 테스트 분석과 설계 단계 활동을 묻고 있다.

일반적이고 추상적인 테스트 목적을 실제적이고 구체적인 테스트 컨디션(Conditions)과 테스트케이스로 바꾸는 활동이다. 이렇게 하려면 테스트 베이시스(예, 요구 사항 분석서, 아키텍처, 개발 설계 문서, 인터페이스) 리뷰 활동이 필요하다.

테스트 계획 단계에서 테스트 목표와 임무를 면밀히 확인한다. 또한 목표 달성을 위해 필요한 활동을 정의한다.

테스트 구현 및 실행 단계에서 테스트 프로시저와 테스트 스위트를 만든다. 

테스트 프로세스의 일반적인 단계와 각 단계에서 해야 하는 주요 활동이 무엇인지 알아 둔다. 

1) 테스트 목표는 계획단계에서 진행하는듯하다. 

 

13. 컴포넌트 테스팅(Component testing)과 시스템 테스팅(System testing)을 비교한 내용이다. 옳은 것은?

a) 컴포넌트 테스팅은 소프트웨어 모듈의 기능, 객체(Program objects), 별도로 테스트 가능한 클래스를 확인하는 반면, 시스템 테스팅은 컴포넌트 사이의 인터페이스와 시스템의 다른 부분과 상호작용을 확인한다.

b) 컴포넌트 테스팅 테스트케이스는 컴포넌트 명세, 디자인 명세나 데이터 모델에서 도출하는 반면, 시스템 테스팅 테스트케이스는 요구 명세서, 기능 명세서, 유즈 케이스(Use cases)에서 도출한다.

c) 컴포넌트 테스팅은 기능 특성에 초점을 맞춘 반면에 시스템 테스팅은 기능적 특성과 비기능적 특성에 초점을 맞춘다.

=> 컴포넌트 테스팅은 소프트웨어를 테스팅이

가능한 최소 단위(모듈, 오브젝트, 클래스)로 분류해 코드를 테스팅한다.

따라서 컴포넌트 명세, 디자인 명세, 데이터 모델 등을 토대로 테스트케이스를 작성한다.

그에 비해 시스템 테스트는 개발 프로젝트 차원에서 정의된 전체 시스템의 동작과 관련되므로 요구명세, 기능 명세, 유즈 케이스에서 테스트케이스를 작성할 수 있다. 

14. 다음 중 공식적인 리뷰(Formal review)에서 주요 절차는?

1) 착수, 상태, 준비, 리뷰 미팅, 재작접, 후속 조치

2) 계획, 준비, 리뷰 미팅, 재작업, 종료, 후속 조치 

3) 계획, 시작, 개별 준비, 리뷰 미팅, 재작업, 후속 조치

4) 준비, 리뷰 미팅, 재작업, 종료, 후속 조치, 근본 원인 분석 

=> 공식적 리뷰의 단계와 활동은 다음과 같다.

계획(인원 설정, 역할 할당) -> 시작(Kick off / 목표, 절차, 문서, 배포, 설명) -> 개별 준비(잠재적 결함 및 질문 도출) -> 리뷰 미팅(결함 여부 결정, 기록, 해결 방안 모색) -> 재작업(문서 작성자가 결함수정) -> 후속 조치(재작업 결과 확인) 

 

15.  다음의 리뷰 유형 중 소프트웨어 프로젝트에서 안전 최우선 컴포넌트(Safety critical components) 리뷰 시 가장 적합한 두 가지 리뷰 유형은?

1) 비공식적 리뷰(Informal review)

2) 매니지먼트 리뷰(Management review)

3) 인스펙션(Inspection)

4) 워크쓰루(Walkthrough)

5) 테크니컬 리뷰(Technical review)

=> 안전 최우선 컴포넌트는 공식적 리뷰를 해야 한다. 공식적 리뷰에는 인스펙션과 테크니컬 리뷰가 있다. 

 

17. 프로젝트에서 테스트 목표는 결정 커버리지 100% 달성이다. 아래 제어 흐름 그래프에서 테스트를 실행한다. 
다음중 결정 커버리지(Decision coverage) 달성에 대해 올바르게 설명한 것은? 

=> 결정 커버리지 100%달성 관련 문제다. 결정 커버리지를 100% 달성하려면 테스트 케이스가 각 결정 포인트의 모든 분기를 커버하면 된다. 

 

18. 

1) 기능 테스팅 -> 서버에서 데이터를 받는 기능을 테스트한다고 볼 수 있다.

2) 구조적 테스팅 -> 구문 커버리지(Statement coverage) 100%를 달성했다고 했다.

3) 재테스팅 : 결함 수정 사항을 확인하는 테스팅이 재테스팅이다. 

4) 성능 테스팅은 언급하지 않았다. 

 

27.

경계값 분석과 동등분할 분석을 이해하자. 경계값 분석은 경계값들을 모두 테스팅한다. 

 

31. 다음 중 일반적인 테스트 종료 기준(Test exit critieria)은?

1) 완전성 측정치(Thoroughness measures), 신뢰성 측정치, 테스트 비용, 스케줄, 결함의 수정 정도와 잔존 리스크

2) 완전성 측정치, 신뢰성 측정치, 테스터의 독립성 정도와 제품 완성도

3) 완전성 측정치, 신뢰성 측정치, 테스트 비용, 시장 출시 시기, 제품 완성도, 테스트 가능한 코드의 가용성

4) 시장 출시 시기, 잔여 결함, 테스터 자격, 테스터의 독립성 정도, 철저한 대책 및 테스트 비용 

=> 테스트 종료 조건은 보통 아래와 같은 사항을 참조한다.

1) 보장성 또는 완전성 측정치(테스트 종료 조건은 코드 커버리지, 기능(성) 커버리지, 리스크 커버리지)

2) 추정된 결함 밀도나 신뢰성 측정치

3) 테스트 비용과 예산

4) 잔존 리스크

5) 출시 시기에 따른 스케쥴

6) 테스터 독립성, 테스트 가능한 코드 가용성, 테스트 자격 등은 테스트 종료 조건으로 부적합하다.
보통 테스트 종료 조건을 따질 때 "테스트 마감 활동 후 출시 시점은? 다음 테스트 단계로 넘어가도 괜찮은가?"를 생각하며 이미지 트레이닝해보고 정리해 두자.

 

36. 정 주임은 안전-최우선 소프트웨어 개발 프로젝트를 수행하는 테스터다. 테스트 실행 중 기대 결과와 다른 결과가 나와 인시던트 리포트(Incident report)를 작성하려고 한다. IEEE 표준 829를 따른다면 가장 중요하게 생각해야 할 정보는?
1) 영향도(Impact), 인시던트 설명, 날짜와 시간, 테스터 이름

2) 리포트 고유 ID, 필요한 특별 요구사항

3) 본인이 생각하는 테스트 대상 전달 항목(Transmitted items), 테스터 이름, 결함 원인

4) 인시던트 설명, 환경, 기대 결과 

=> IEEE 829에서는 다음과 같이 기술한다.

1) 테스트 인시던트 보고 식별자(Test incident report identifier) : 테스트 리포트는 다른 문서와 구별할 수 있도록 고유 식별자(고유 ID)가 있다.

2) 요약(Summary) : 사건을 요약한다.

3) 인시던트 기술(Incident description) : 입력 값, 예상 결과, 실제 결과, 환경, 반복시도 등

4) 영향도(Impact) : (알려진 경우) 인시던트가 테스트에 미칠 영향도를 기술한다. 

 

38. 다음 중 키워드 주도 테스트(Keyword-driven test) 실행 도구의 특성을 가장 잘 설명한 것은?

1) 테스트 입력 데이터, 액션 단어(Action word), 기대 결과가 들어있는 테이블(표)로 테스트 대상의 실행을 제어한다.

-> 액션 단어(Action word)는 테스트할 대상을 실행하는 명령을 기술한다.
2) 여러 번 재실행한 테스터의 액션을 스크립트에 기록한다.
-> 녹화-재생(Record&Play) 도구의 일반적 특징이다. 

3) 여러 입력 데이터 모음을 실행한 테스터의 액션을 스크립트에 기록한다.

-> 데이터 주도 테스팅(Data-driven testing)에서 고려할 사항이다.

4) 테스트 결과를 기록할 수 있다. 또한 테스트 결과와 텍스트 파일로 저장한 기대결과를 비교할 수 있다. 

-> 테스트 비교기와 함께 녹화-재생 도구의 일반적인 특징이다. 

키워드 주도 테스팅은 테스트 데이터와 예상 결과뿐 아니라, 테스트 대상 관련 키워드를 포함한 데이터 파일을 사용하는 스크립트 기법이다. 제어 스크립트(Control script)가 테스트 목적으로 호출한 특별 지원 스크립트로 키워드를 해석한다.

데이터 주도 테스팅은 테이블이나 스프레트시트에 테스트 입력 값과 예상 결과를 저장해 스크립트를 작성하고 테스트하는 기법이다. 이를 통해 제어 스크립트 한 개로 해당 테이블에서 모든 테스트를 수행할 수 있다. 데이터 주도 테스팅은 주로 기록 과 재생 도구 같은 테스트 실행 도구 활용을 지원하는데 쓰인다. 

 

 

 

<광고 한번 클릭해주시면 저에게 큰 힘이 됩니다 😃>