ISTQB CTFL 실라바스2

블랙박스 테스트 기법

1. 동등 분할 : 특정 파티션의 모든 변수는 동일한 방식으로 처리된다는 가정으로 파티션에 데이터를 분할한다. 유효한 값과 비유효한 값 모두에 대해 동등 분할을 구성할 수 있다.

• 모든 값은 동등 분할에 포함되어야 하며, 하나의 값은 하나의 동등 분할에만 속해야 한다.
• 비유효 동등 분할을 테스트 케이스로 만들 때는 장애가 마스크(masked) 즉, 가려지는 것을 방지하기 위해 개별적으로 테스트해야 하며, 다른 비유효 동등 분할과 조합하지 않아야 한다. 동시에 여러 장애가 발생할 때 겉으로 드러나는 하나의 장애 때문에 나머지가 인식되지 않아 장애가 가려지는 경우가 발생한다.

2. 경곗값 분석 : 동등 분할의 확장 형태이지만 각 파티션이 순서화되어 있고, 숫자 또는 연속 데이터로 구성된 경우에만 적용할 수 있다. 분할의 최솟값과 최댓값(또는 첫 번째 값과 마지막 값)은 해당 분할의 경곗값이 된다.

• 경곗값 분석은 모든 테스트 레벨에 적용할 수 있다. 이 기법은 일반적으로 숫자의 범위(날짜, 시간 포함)와 연관된 요구사항을 테스트하는 데 적용된다. 경곗값 분석 커버리지는 보통 백분율로 표기하며, 테스트한 경곗값의 수를 식별한 모든 경곗값의 수로 나눠서 계산한다.

3. 결정 테이블 테스팅 : 결정 테이블을 작성할 때 테스터는 시스템의 조건과 예상 동작을 식별한다. 이것들은 테이블의 행(rows)을 형성하며 일반적으로 조건은 위쪽에, 기대 결과는 아래쪽에 둔다. 각 열(column)은 하나의 결정 규칙으로 특정 조건의 고유한 조합과 연관된 기대 결과로 정의한다.

4. 상태 전이 테스팅 : 컴포넌트나 시스템은 현재 조건이나 기존 이력에 따라 이벤트에 대해 다르게 반응할 수 있다. 기존 이력은 상태라는 개념을 활용해서 요약할 수 있다. 상태 전이 다이어그램은 소프트웨어의 가능한 상태뿐만 아니라 소프트웨어가 상태 간에 어떻게 진입하고 빠져나오는지에 대한 전이 방법을 보여준다. 전이는 이벤트에 의해 시작된다. 이 이벤트는 전이라는 결과를 가져온다. 하나의 이벤트에 의해 동일한 상태로부터 두 개 이상의 다른 전이가 발생할 수 있다. 상태 변화로 소프트웨어가 특정 행동을 할 수도 있다.

5. 유스케이스 테스팅 : 유스케이스는 소프트웨어 기능에 대한 요구사항을 통합한다. 유스케이스는 액터와 대상 간의 관계이다. 각 유스케이스는 대상이 하나 이상의 액터와 협력하여 수행할 수 있는 동작들을 명시하고 있다. 유스케이스를 상호작용과 활동으로 설명하기도 하고, 적절한 경우 사전 조건, 사후 조건 및 자연어로 설명할 수도 있다. 액터와 대상 간의 상호작용으로 대상의 상태가 변경될 수 있다. 상호작용은 워크플로우, 활동 다이어그램, 비즈니스 프로세스 모델로 시각화할 수 있다.

​

화이트박스 테스트 기법

1. 구문 테스팅과 커버리지 : 구문 테스팅은 코드의 잠재적으로 실행 가능한 구문을 실행한다. 커버리지는 일반적으로 백분율로 표기하며, 테스트로 실행한 구문의 수를 테스트 대상의 모든 실행 가능한 구문의 수로 나눠서 계산한다.
2. 결정 테스팅과 커버리지 : 결정 테스팅은 코드에 존재하는 결정문을 실행하고 결정문의 결과에 따라 실행되는 코드를 테스트한다. 이것을 달성하기 위해 테스트 케이스는 결정문에서 시작되는 제어 흐름을 따라 실행된다. 커버리지는 일반적으로 백분율로 표기하며, 테스트로 실행된 결정문 결과의 수를 테스트 대상의 가능한 모든 결정문 결과의 수로 나눠서 계산한다.

​

경험 기반 테스트 기법

1. 오류 추정 : 오류 추정 기법에 대한 체계적인 접근법은 발생 가능한 오류, 결함, 장애 목록을 작성하고 이런 장애와 그것의 원인이 되는 결함을 노출하는 테스트를 설계하는 것이다. 이러한 오류, 결함, 장애 목록은 경험, 결함 및 장애 데이터 또는 소프트웨어가 실패한 이유에 대한 일반적인 지식을 기반으로 작성할 수 있다.
2. 탐색적 테스팅 : 탐색적 테스팅에서는 비공식(사전에 정의되지 않은) 테스트를 테스트 실행 중에 동적으로 설계, 실행, 기록하고 평가한다. 테스트 결과는 컴포넌트나 시스템에 대해 더 많이 학습하고, 더 많은 테스트가 필요한 영역에 대한 테스트를 작성하는 데 활용된다.
3. 체크리스트 기반 테스팅 : 체크리스트 기반 테스팅에서는 체크리스트에 기록된 테스트 컨디션을 커버하기 위해 테스터가 테스트를 설계, 구현, 실행한다. 테스터는 분석의 일환으로 새로운 체크리스트를 작성하거나 기존 체크리스트를 확장할 수 있지만, 기존 체크리스트를 수정하지 않고 그대로 사용하는 경우도 있다. 체크리스트는 경험, 사용자에게 무엇이 중요한지에 대한 지식 또는 소프트웨어가 실패하는 이유와 방법에 대한 이해를 기반으로 작성할 수 있다.

​

테스트 전략과 테스트 접근법

1. 분석적 : 특정 요소에 대한 분석을 기반으로 한 테스트 전략. 리스크 수준에 따라 테스트를 설계하고 우선순위를 결정하는 리스크 기반 테스팅이 분석적 접근법의 예이다.
2. 모델 기반 : 이러한 유형의 테스트 전략에서 테스트는 요구되는 제품의 특정 측면에 대한 모델을 기반으로 만들어진다. 특정 측면에는 기능, 비즈니스 프로세스, 내부 구조, 비기능 특성 등이 있다. 모델에는 비즈니스 프로세스 모델, 상태 모델, 신뢰성 성장 모델 등이 있다.
3. 방법론적 : 이 테스트 전략은 사전에 정의한 테스트 셋이나 테스트 컨디션을 체계적으로 사용하는 데 의존한다. 예를 들어, 보편적이고 발생 가능성이 높은 장애 분류, 주요 품질 특성 목록, 모바일 애플리케이션이나 웹페이지에 대한 전사 룩앤필 표준 등이 있다.
4. 프로세스 준수 : 이 테스트 전략은 외부 규정이나 표준을 기반으로 테스트를 분석, 설계, 구현한다. 예를 들어, 특정 산업 표준에서 제시하는 규정이나 표준, 프로세스의 문서화, 테스트 베이시스의 엄격한 식별과 사용, 조직이 강제하거나 조직에 강요된 모든 프로세스나 표준을 기반으로 한다.
5. 전문가 조언 : 이 테스트 전략은 주로 이해관계자, 비즈니스 도메인 전문가, 기술 전문가 등의 조언, 지도, 지시를 바탕으로 이루어진다. 이 사람들은 외부 테스트팀이나 외부 조직 소속일 수 있다.
6. 리그레션-기피 : 기존 기능에 대한 리그레션 테스트 기피를 목표로 한다. 이 테스트 전략에는 기존 테스트웨어의 재사용, 리그레션 테스트 자동화 확대, 테스트 스위트 표준화가 포함된다.
7. 반응적 : 지금까지 소개한 사전 계획에 따라 실행하는 테스트 전략과는 달리 테스트 대상 컴포넌트나 시스템에 따라 대응하고 테스트 실행 중 발생하는 이벤트에 따라 반응적으로 수행하는 테스트 접근법이다. 이전 테스트 결과에서 얻은 지식을 바탕으로 테스트를 설계하고 구현하며 즉각 테스트를 실행할 수 있다. 탐색적 테스팅이 반응적 전략에서 일반적으로 사용하는 기법이다.

​

형상 관리

1. 모든 테스트 항목에 고유 식별번호를 부여하고, 버전을 관리하고, 변경 이력을 기록한다. 형상 관리에서 테스트 항목은 서로 연관돼 있다.
2. 모든 테스트웨어 항목에 고유 식별번호를 부여하고, 버전을 관리하고, 변경사항을 추적하고, 서로 연결해 테스트 항목 버전과도 연결되도록 해서 테스트 프로세스 전반에 걸쳐 추적성을 유지할 수 있게 한다.
3. 식별한 모든 문서와 소프트웨어 아이템은 테스트 문서 내에서 명확하게 상호 참조되도록 한다.

​

결함관리 : 테스팅의 목적 중 하나가 결함을 찾는 것이기 때문에 테스팅 중 발견한 결함은 반드시 기록해야 한다. 결함을 기록하는 방법은 테스트 대상 컴포넌트나 시스템의 정황, 테스트 레벨, 소프트웨어 개발 수명주기 모델에 따라 달라진다. 찾아낸 모든 결함은 조사하고, 발견에서 결함 분류까지 추적해야 한다. 모든 결함을 해결까지 관리하기 위해 조직은 결함 관리 프로세스를 수립해야 한다. 아키텍처, 설계자, 개발자, 테스터, 제품 책임자 등 결함 관리에 참여하는 모든 사람이 프로세스에 동의해야 한다. 일부 조직에서는 결함 로깅과 추적이 매우 비공식적일 수 있다.

​

테스트 도구의 분류

1. 테스팅 및 테스트웨어 관리 지원 도구
2. 정적 테스팅 지원 도구
3. 테스트 설계 및 구현 지원 도구
4. 테스팅 실행 및 로깅 지원 도구
5. 성능 측정과 동적 분석 지원 도구
6. 특수 목적 테스팅 지원 도구

​

테스트 실행 도구

1. 캡처 기반 테스트 접근법 : 테스터의 수동적인 조작을 녹화해 테스트를 캡처하는 것은 매력적으로 보일 수 있지만 이러한 접근 방식은 테스트 스크립트의 수가 많을 경우 적절하지 않다. 캡처한 스크립트마다 특정 데이터와 행위를 1 차원적으로 표현하고 있기 때문에 미처 예상하지 못한 이벤트가 발생하면 취약할 수 있으며, 시스템의 사용자 인터페이스가 시간이 지남에 따라 바뀌게 되면 스크립트도 그에 맞게 계속해서 유지보수를 해 줄 필요가 있다.
2. 데이터 주도 테스트 접근법 : 이 접근법은 테스트 입력값과 기대 결과값을 보통 스프레드시트에 저장하고 더 많은 공통 스크립트를 활용해 해당 테스트 데이터를 읽어 들여 동일한 테스트 스크립트를 매번 다른 데이터로 반복적으로 실행한다.
3. 키워드 주도 테스트 접근법 : 이 접근법은 해야 할 행동을 설명하는 키워드를 공통 스크립트가 처리해 키워드 스크립트를 호출한다. 키워드 스크립트는 연관된 테스트 데이터를 처리한다.