실라버스 정리) 테스트 기법 정리 (4장)

4장 테스트 기법

테스트 기법의 선택은 다음과 같은 요소를 기반한다.

- 컴포넌트나 시스템의 복잡도

- 규제 기준

- 고객 또는 계약 요구사항

- 리스크 수준과 유형

- 사용 가능한 문서

- 테스터의 지식과 역량

- 사용 가능한 도구

- 시간과 예산

- 소프트웨어 개발 수명주기 모델

- 컴포넌트나 시스템에서 예상되는 결함 유형

​

테스트 케이스를 작성할 때 테스터는 일반적으로 테스트 노력 대비 가장 좋은 결과를 얻기 위해

다양한 테스트 기법을 조합해서 사용한다.

​

테스트 분석, 테스트 설계, 테스트 구현 활동에서 테스트 기법의 사용은

매우 비공식적인 형식(거의 또는 문서화하지 않음)부터 매우 공식적인 형식까지 다양할 수 있다.

​

적절한 수준의 공식성은 테스트 및 개발 프로세스의 성숙도, 시간적인 제한, 안전 또는 규정 요구사항,

관련된 사람들의 지식과 역량, 준수해야 하는 소프트웨어 개발 수명주기 모델을 포함하는 테스팅의 정황에따라 결정된다.

​

4.1.1 테스트 기법의 종류와 특성 (Categories of Test Techniques and Thir Characteristics)

블랙박스 테스트 기법 (행위 기법 또는 행위 기반 기법)

- 적절한 테스트 베이시스(예: 공식 요구사항문서, 명세서, 유스케이스, 사용자 스토리 또는 비즈니스 프로세스)에 대한 분석 기반

- 기능 테스팅과 비기능 테스팅 모두에 적용할 수 있다.

- 테스트 대상의 내부 구조를 고려하지 않고, 입력과 출력에 집중한다.

- 테스트 컨디션, 테스트 케이스, 테스트 데이터는 소프트웨어 요구사항, 명세서, 유스케이스, 사용자 스토리와 같은 테스트 베이시스로부터 도출한다.

- 테스트 케이스는 요구사항과 요구사항 구현 결과물 간 차이와 편차를 식별하는데 사용한다.

- 커버리지는 테스트 베이시스에서 테스트된 항목과 테스트 베이시스에 적용한 기법을 기반으로 측정한다.

​

화이트 박스 테스트 기법(구조 기법 또는 구조 기반 기법)

- 아키텍쳐, 세부 설계, 내부 구조, 테스트 대상의 코드에 대한 분석 기반

- 테스트 대상의 내부 구조와 처리에 집중한다.

- 테스트 컨디션, 테스트 케이스, 테스트 데이터는 코드, 소프트웨어 아키텍쳐, 상세 설계 또는

소프트웨어 구조와 관련된 기타 정보를 포함한 테스트 베이시스로부터 도출한다.

- 커버리지는 선택한 구조(예: 코드나 인터페이스) 내에서 테스트한 항목과 테스트 베이시스에 적용된 기법을 기준으로 측정한다.

​

경험 기반 테스트 기법

- 개발자, 테스터, 사용자의 경험을 활용하여 테스트를 설계, 구현, 실행한다.

- 블랙박스 및 화이트박스 테스트 기법과 결합해서 사용하는 경우가 많다.

- 테스트 컨디션, 테스트 케이스, 테스트 데이터는 테스터, 개발자, 사용자,

기타 이해관계자의 지식과 경험과 같은 테스트 베이시스로부터 도출한다.

​

※ 지식과 경험은 소프트웨어의 예상 동작과 사용 환경, 발생 가능성이 있는 경함과 분포 등을 포함한다.

​

​

4.2 블랙박스 테스트 기법 Black-box Test Techniuqes

​

4.2.1 동등 분할 (Equivalence Partitioning)

동등 분할은 특정 파티션(partitions)의 모든 변수는 동일한 방식으로 처리된다는 가정으로 파티션("동등 클래스")에 데이터를 분할한다.

유요한 값과 비유효한 값 모두에 대해 동등 분할을 구성할 수 있다.

- 유효값(valid values) : 컴포넌트나 시스템에 입력되는 값이다. 유효한 값을 포함하는 동등한 파티션을 "유효 동등 분할"이라고 한다.

- 비유효값(invalid values) : 컴포넌트나 시스템이 거부하는 값이다. 유효하지 않은 값을 포함하는 동등한 파티션을 "비유효 동등 분할" 이라고 한다.

​

- 분할은 입력값, 출력값, 내부값, 시간관련값(예: 이벤트 전 또는 후),

인터페이스 매개변수(예: 통합 테스팅에서 테스트 하는 통합 컴포넌트)를 포함하여 테스트 대상과 관련된 모든 데이터 요소에 대해 식별할 수 있다.

​

- 필요한 경우 모든 파티션은 하위 파티션(sub partitions)으로 나눌 수 있다.

- 모든 값은 동등 분할에 포함되어야 하며, 하나의 값은 하나의 동등 분할에만 속해야 한다.

- 비유효 동등 분할을 테스트 케이스로 만들 때는 장애가 마스크(masked) 즉, 가려지는 것을 방지하기 위해

개별적으로 테스트해야 하며, 다른 비유효 동등 분할과 조합하지 않아야 한다.

동시에 여러 장애가 발생할 때 겉으로 드러나는 하나의 장애 때문에 나머지가 인식되지 않아 장애가 가려지는 경우가 발생한다.

​

- 동등 분할 기법으로 100% 커버리지를 달성하기 위해서는 식별한 모든 분할(비유효 분할 포함)의 각 분할에서

최소 한 개의 값을 사용해 테스트 케이스를 작성해야 한다.

- 동등 분할 커버리지는 일반적으로 백분율로 표기하며, 최소한 한 개의 값으로 테스트한 동등 분할 수를 식별한 모든 동등 분할의 수로 나눠서 계산한다.

- 동등 분할은 모든 테스트 레벨에 적용할 수 있다.

​

4.2.2 경계값 분석 (Boundary Value Analysis)

경계값 분석(BVA)은 동등 분할의 확장 형태이지만 각 파티션이 순서화되어 있고, 숫자 또는 연속 데이터로 구성된 경우에만 적용할 수 있다. 아래 예제를 보자

​

분할의 최소값과 최대값(또는 첫 번째값과 마지막값)은 해당 분할의 경계값이된다. (Beizer 1990 참고).

경계당 세 개의 경계값을 식별하는 것도 있다: 경계 직전 값, 경계에 해당하는 값, 경계 직후의 값.

​

동등 분할의 경계에서 동작이 잘못될 확률이 동등 분할 중간의 값에서 잘못될 확률에 비해 높다.

명시된 경계값과 구현한 경계값 모두 의도했던 값보다 높거나 낮게 설정되거나, 모두 생략하거나 의도하지 않았던

경계값이 추가 되었을 수 있다는 사실을 기억하는 것이 중요 하다.

​

경계값 분석과 테스팅을 통해

소프트웨어가 경계값이 원래 속한 분할의 동작이 아닌

다른 분할의 동작을 수행하는 것과 같은 종류의 결함 대부분을 식별할 수 있다.

​

경계값 분석은 모든 테스트 레벨에 적용할 수 있다.

이 기법은 일반적으로 숫자의 범위(날짜, 시간 포함)와 연관된 요구사항을 테스트하는 데 적용된다.

​

경계값 분석 커버리지는 보통 백분율로 표기하며,

테스트한 경계값의 수를 식별한 모든 경계값의 수로 나눠서 계산한다.

​

4.2.3 결정 테이블 테스팅 (Decision Table Testing)

- 시스템이 구현해야 하는 복잡한 비즈니스 규칙을 기록하기에 좋은 방법이다.

- 테스터는 시스템의 조건(주로 입력)과 예상 동작(주로 출력)을 식별한다.

- 테이블의 행(rows)을 형성하며 일반적으로 조건은 위쪽에, 기대 결과는 아래쪽에 둔다.

- 각 열(Columns)은 하나의 결정 규칙으로 특정 조건의 고유한 조합과 연관된 기대 결과로 정의한다.

- 조건과 기대 결과의 값은 일반적으로 참, 거짓으로 표기하거나, 빨, 녹, 파 등과 같은 비 연속 값으로 표기하지만

숫자나 숫자 범위로 표기하는 경우도 있다.

​

조건 :

- Y, 조건이 참이라는 것을 의미 (T 또는 1로 표기할 수 있음)

- N, 조건이 거짓이라는 것을 의미 (F 또는 0 으로도 표기할 수 있음)

- ㅡ, 조건의 값이 중요하지 않다는 것을 의미 (N/A 로 표기할 수 있음)

​

기대결과 :

- X, 행동이 일어난다는 것을 의미 (Y,T, 1 로 표기할 수 있음)

- 공백(blank), 행동이 일어나지 않음을 의미 (ㅡ, N, F, 0 으로 표기할 수 있음)

​

전체 결정 테이블에는 모든 조건 조합을 포괄 할 수 있는 충분한 열이 있다.

- 결과에 영향을 미치지 않는 열

예를 들어 불가능한 조건 조합 등을 삭제하면 테스트 케이스 수가 상당히 줄어들 수 있다.

결정 테이블 축소 방법에 대해서는 ISTQB-CTAL-AT

​

일반적인 최소 커버리지 기준은

테이블의 결정 규칙당 최소 한 개의 테스트 케이스를 작성하는 것

(모든 조건 조합을 포함한다.)

커버리지는 일반적으로 백분율로 표기하며,

최소 한 개의 테스트 케이스로 테스트한 결정 규칙의 수를, 식별한 모든 결정 규칙의 수로 나눠서 계산한다.

​

결정 테이블 테스팅의 장점은 모든 조건 조합을 식별하는 데 도움이 된다.

그 중에는 결정 테이블을 사용하지 않았으면 간과했을 수 있는 조합도 있을 수 있다.

요구사항의 누락된 부분을 찾는 데 도움이 된다.

소프트웨어의 동작이 조건 조합에 영향을 받는 모든 상황에 적용 가능하며, 모든 테스트 레벨에 적용할 수 있다.

​

4.2.4 상태 전이 테스팅 (State Transition Testing)

컴포넌트나 시스템은 현재 조건이나 기존 이력(예: 시스템이 초기화되고 난 후 발생한 이벤트)에 따라 이벤트에 대해 다르게 반응할 수 있다.

기존 이력은 상태라는 개념을 활용해서 요약할 수 있다.

​

상태 전이 다이어그램 :

- 소프트웨어의 가능한 상태뿐만 아니라 상태 간에 어떻게 진입하고 빠져나오는지에 대한 전이 방법을 보여준다.

전이는 이벤트에 의해 시작된다. (예를 들어, 사용자가 입력 필드에 값을 입력)

이벤트는 전이라는 결과를 가져온다.

하나의 이벤트에 의해 동일한 상태로부터 두 개 이상의 다른 전이가 발생할 수 있다.

상태 변화로 소프트웨어가 특정 행동을 할 수도 있다. (예: 연산 결과 도는 오류 메시지 출력).

- 상태 전이 다이어그램은 일반적으로 유효한 전이만 보여주며, 비 유효 전이는 보여주지 않는다.

​

상태 전이 테이블 :

- 상태 간의 모든 유효 전이

- 잠재적인 비유효 전이, 유효 전이와 관련된 이벤트 결과 조치를 보여준다.

​

테스트는 상태의 일반적인 순서를 커버하거나, 모든 상태를 실행하거나 모든 상태 전이를 실행하거나,

특정 한 상태 전이 순서를 실행하거나 또는 불가능한 상태 전이를 테스트하도록 설계할 수 있다.

​

상태전이 테스팅은 메뉴 기반 애플리케이션에 사용하며, 임베디드 소프트웨어 업계에서 널리 사용하고 있다.

이 기법은 구체적인 상태를 포함한 비즈니스 시나리오를 모델링하거나 화면 탐색을 테스팅하는 데 적합하다.

​

상태의 개념은 추상적이다.

이는 코드 몇 줄 또는 전체 비즈니스 프로세스를 나타낼 수도 있다.

​

커버리지는 백분율로 표기하며, 식별한 상태나 전이 중 테스트 된 수를 식별한 모든 상태나 전이의 수로 나눠서 계산한다.

상태 전이 테스팅 커버지리 조건에 대한 추가 정보는 ISTQB-CTAL-TA 에서 찾을 수 있다.

​

4.2.5 유스케이스 테스팅 (Use Case Testing)

유스케이스에서 테스트를 도출할 수 있으며,

이것은 소프트웨어 항목 간의 상호작용을 설계하는 특정 방법이다.

- 소프트웨어 기능에 대한 요구사항을 통합한다.

- 액터(actor, 즉 사용자, 외부 하드웨어, 기타 컴포넌트나 시스템)와 대상(유스케이스를 적용하는 컴포넌트나 시스템) 간의 관계이다.

​

각 유스케이스는 대상(subject)이 하나 이상의 액터와 협력하여 수행할 수 있는 동작들을 명시하고 있다.

유스케이스를 상호작용과 활동으로 설명하기도 하고,

적절한 경우 사전조건, 사후조건 및 자연어로 설명할 수도 있다.

액터와 대상 간의 상호작용으로 대상의 상태가 변경될 수 있다.

상호작용은 워크플로우, 활동다이어그램, 비즈니스 프로세스 모델로 시각화할 수 있다.

​

예외 동작 및 오류 처리(시스템 응답과 프로그래밍, 애플리케이션 및 통신 오류로부터의 복구, 예를 들어 오류 메시지 발생)를

포함한 기본 동작의 가능한 변형이 포함된다.

​

정의한 동작(기본, 예외 또는 대안, 오류처리)을 실행하도록 설계된다.

​

커버리지는 일반적으로 숫자로 표기하며,

테스트한 유스케이스 동작 수를 모든 유스케이스 동작 수로 나눠서 계산한다.

​

유스케이스의 커버리지 조건에 대한 추가 정보는 ISTQB-CTAL-TA 에서 찾을 수 있다

​

​

​

4.3 화이트박스 테스트 기법 White-box Test Techniques

테스트 대상의 내부 구조를 기반으로 한다.

모든 테스트 레벨에서 적용할 수 있지만, 두 가지 코드 관련 기법은 단위 테스트 레벨에서

가장 일반적으로 사용된다. 안전 최우선, 임무 최우선, 높은 무결성 환경에서 더 높은 커버리지 달성을 위해

적용하는 고급 기법들도 있지만, 여기서는 다루지 않는다.

​

4.3.1 구문 테스팅과 커버리지 (Statement Testing and Coverage)

- 코드의 잠재적으로 실행 가능한 구문을 실행

​

커버리지는 백분율로 표기,

테스트 실행한 구문의 수를, 테스트 대상의 모든 실행 가능한 구문의 수로 나눠서 계산

​

4.3.2 결정 테스팅과 커버리지 (Decision Testing and Coverage)

- 코드에 존재하는 결정문을 실행하고 결정문의 결과에 따라 실행되는 코드를 테스트한다.

- 이것을 달성하기 위해 테스트 케이스는 결정문에서 시작되는 제어 흐름을 따라 실행된다.

(ex, IF문에서 결과가 참인 경우와 거짓인 경우; CASE문에서 기본 결과를 포함한 가능한 모든 결과를 필요로 하는 테스트 케이스)

​

커버리지는 백분율로 표기,

테스트로 실행된 결정문 결과의 수를, 테스트 대상의 가능한 모든 결정문 결과의 수로 나눠서 계산

​

4.3.3 구문 및 결정 테스팅의 가치 (The Value of Statement and Decision Testing)

​

구문 커버리지 / 구문 테스팅 :

- 100% 구문 커버리지를 달성하면 코드에 존재하는 모든 실행 가능한 구문을 최소한 한 번식은 테스트 했다는 것을 의미 하지만,

- 모든 결정 로직을 테스트 했다는 것을 보장하지 않는다.

- 구문 테스팅은 결정 테스팅보다 커버리지가 낮다.

- 구문 커버리지는 다른 테스트에 의해 실행되지 않은 코드의 결함을 찾는 데 도움이 된다.

​

결정 커버리지 / 결정 테스팅 :

- 100% 결정 커버리지를 달성하면 명확한 거짓 구문이 명시되지 않은 경우

(ex if문에 else문이 없는 경우)에도 결과가 참인 경우와 거짓인 경우를 포함한 모든 결정 결과가 실행되었다는 것을 의미한다.

- 결정 커버리지는 다른 테스트가 참과 거짓 결과 모두를 테스트하지 않은 코드의 결함을 찾는 데 도움이 된다.

- 100% 결정 커버리지는 100% 구문 커버리지를 보장한다.

​

​

4.4 경험 기반 테스트 기법 Experience-based Test Techniques

- 테스트 케이스는 테스터의 기술 역량과 직관 그리고 유사한 애플리케이션과 기술에 대한 경험을 기반으로 도출한다.

- 체계적인 다른 기법으로는 쉽게 찾아내기 어려운 테스트를 식별하는 데 도움이 된다.

- 테스터의 접근 방식과 경험에 따라 이 기법으로 달성하는 커버리지와 효과성 매우 다양하게 나타난다.

- 경험 기반 테스트 기법을 사용할 경우 커버리지를 평가하기 어려울 수 잇고, 측정이 불가능할 수도 있다.

​

4.4.1 오류 추정 (Error Guessing)

테스터의 지식을 기반으로 오류, 결함 및 장애 발생을 예측하는 데 적용하는 기술

- 애플리케이션의 과거 동작

- 발생하기 쉬운 오류의 유형

- 다른 애플리케이션에서 발생한 장애

​

오류 추정 기법에 대한 체계적인 접근법은 발생 가능한 오류, 결함, 장애 목록을 작성하고

이런 장애와 그것의 원인이 되는 결함을 노출하는 테스트를 설계하는 것이다.

​

이러한 오류, 결함, 장애 목록은 결험, 결함 및 장애 데이터 또는 소프트웨어가 실패한 이유에 대한

일반적인 지식을 기반으로 작성할 수 있다.

​

4.4.2 탐색적 테스팅 (Exploratory)

- 비공식 테스트를 테스트 실행 중에 동적으로 설계, 실행, 기록하고 평가

- 테스트 결과는 컴포넌트나 시스템에 대해 더 많이 학습하고, 더 많은 테스트가 필요한 영역에 대한 테스트 작성에 활용

- 세션 기반 테스팅을 사용하여 활동을 구성한다.

- 세션 기반 테스팅에서는 탐색적 테스팅을 정해진 시한동안 수행

- 테스터는 테스트 목적이 포함된 테스트 차터를 활용해 테스팅 방향 설정

- 테스터는 테스트 세션 시트에 수행 단계와 발견 사항을 기록한다.

- 명세가 충분하지 않거나 적은 경우

- 테스팅에 상당한 시간적 압박이 있을 때 가장 유용

- 다른 보다 공식적인 테스팅 기법을 보완하는 데도 유용하다

- 반응적 테스트 전략과 밀접하게 관련되어 있다

- 다른 블랙박스, 화이트박스, 경험 기반 기법과 통합하여 사용 가능

​

4.4.3 체크리스트 기반 테스팅 (Checklist-based Testing)

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

- 테스터는 분석의 일환으로 새로운 체크리스트를 작성하거나 기존 체크리스트를 확장할 수 있고

기존 체크리스트를 수정하지 않고, 그대로 사용하는 경우도 있다.

- 경험, 사용자에게 무엇이 중요한지에 대한 지식 또는 소프트웨어가 실패하는 이유와 방법에 대한 이해를

기반으로 작성할 수 있다.

- 기능 및 비기능 테스팅을 포함한 다양한 테스트 유형을 지원하기 위해 작성할 수 있다.

- 구체적인 테스트 케이스가 없는 경우, 체크리스트 기반 테스팅은 대략적인 지침과 일관성을 제공할 수 있다.

- 체크리스트는 상위 수준으로 작성되기 대문에 실제 테스팅에서 어느 정도의 가변성이 있고,

커버리지는 늘어날 수 있지만 재현 가능성은 줄어들 수 있다.