[SW테스팅] D-4 ISTQB Syllabus 4.1 테스트 기법의 종류

ACAI BERRY DEVELOVER·2023년 8월 20일

CTFL ISTQB 경험기반테스팅 구조기반테스팅 블랙박스테스팅 소프트웨어테스팅 실라버스 테스트기법 행위기반테스팅 화이트박스

📖 다음은 다가오는 ISTQB CTFL 자격증 셤을 위해 공부하면서 실라버스를 요약해 놓은 글이다.

✅ 테스트 기법의 목적:

테스트 컨디션, 테스트 케이스, 테스트 데이터 식별을 지원

✅ 테스트 기법의 선택:

컴포넌트, 시스템의 복잡도
규제 기준
고객 또는 계약 요구사항
리스크 수준과 유형
사용 가능한 문서
테스터의 지식과 역량
사용 가능한 도구
시간과 예산
소프트웨어 개발 수명주기 모델
컴포넌트, 시스템에서 예상되는 결함 유형

일부 기법은 특정 상황, 테스트 레벨에 더 적합하기도, 모든 테스트 레벨에 적합한 기법도 있음.

테스터는 테스트 노력 대비 가장 좋은 결과를 얻어야 하기에 다양한 테스트 기법을 조합해 테스트 케이스를 작성함.

4.1.1 📖 테스트 기법의 종류와 특성

블랙박스 테스트 기법
화이트박스 테스트 기법
경험 기반 테스트 기법

❶ 블랙박스(행위 기반 기법)

공식 요구사항문서, 명세서, 유스케이스, 사용자 스토리, 비즈니스 프로세스와 같은 test basis에 대한 분석을 기반으로 함.
기능, 비기능 테스트에 적용 가능
테스트 대상의 내부 구조 고려 x
입력, 출력에 집중
테스트 컨디션, 테스트 케이스, 테스트 데이터는 소프트웨어 요구사항, 명세서, 유스케이스, 사용자 스토리와 같은 test basis로 부터 도출
테스트케이스는 요구사항과 요구사항 구현 결과물 간 차이와 편차를 식별하는 데 사용
커버리지는 test basis에서 테스트된 항목과 test basis에 적용한 기법을 기반으로 측정

❷ 화이트박스(구조 기반 기법)

아키텍처, 세부 설계, 내부 구조, 테스트 대상의 코드에 대한 분석을 기반으로 함.
테스트 대상의 내부구조와 처리에 집중
테스트 컨디션, 테스트 케이스, 테스트 데이터는 코드, 소프트웨어 아키텍처, 상세 설계 또는 소프트웨어 구조와 관련된 기타 정보를 포함한 test basis로부터 도출
커버리지는 선택한 구조(코드, 인터페이스) 내에서 테스트한 항목과 테스트 베이시스에 적용된 기법을 기준으로 측정

❸ 경험기반

개발자, 테스터, 사용자의 경험을 활용해 테스트 설계, 구현, 실행
블랙박스, 화이트박스 테스트 기법과 결합해 사용
테스트 컨디션, 테스트 케이스, 테스트 데이터는 테스터, 개발자, 사용자, 기타 stakeholders의 지식과 경험(test basis)으로부터 도출.

지식과 경험은 SW의 예상 동작과 사용 환경, 발생 가능성이 있는 결함과 분포 등을 포함.

4.2 📖 블랙박스 테스트 기법

4.2.1 동등 분할 (Equivalence Partitioning)

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

유효값 : 컴포넌트, 시스템에 입력되는 값. 유효값 포함하는 동등 파티션을 "유효 동등 분할"이라함.
비유효값 : 컴포넌트, 시스템이 거부하는 값. 비유효값을 포함하는 동등한 파티션을 "비유효 동등 분할"이라함.
분할은 입력값, 출력값, 내부값, 시간관련값, 인터베이스 매개변수를 포함하여 테스트 대상과 관련된 모든 데이터 요소에 대해 식별 가능.
필요한 경우 모든 파티션은 하위 파티션으로 나눌 수 있음
모든 값은 동등 분할에 포함되어야 하며, 하나의 값은 하나의 동등 분할에만 속해야함.
비유효 동등 분할을 테스트 케이스로 만들 땐 장애가 가려지는 것을 방지하기 위해 개별적으로 테스트해야 하며, 다른 비유효 동등 분할과 조합하지 않아야함.(동시 장애 발생 시 겉으로 드러나는 하나의 장애때문에 나머지가 인식되지 않을 수 있음)
100% 커버리지를 달성하기 위해서는 식별한 모든 분할(비유효 분할 포함)의 각 분할에서 최소 한 개의 값을 사용해 테스트 케이스를 작성해야함.
동등 분할 커버리지는 일반적으로 백분율로 표기.
동등 분할 커버리지 : 최소한 한개의 값으로 테스트한 동등 분할 수 /식별한 모든 동등 분할의 수
모든 테스트레벨에 적용 가능.

4.2.2 경계값 분석 (Boundary Value Analysis)

동등 분할의 확장 형태이나 각 파티션이 순서화되어있다.
숫자 혹은 연속 데이터로 구성된 경우에만 적용 가능하다.
분할의 최소값과 최대값(또는 첫번째값과 마지막값)은 해당 분할의 경계값이 된다.

예시)
• 특정 입력 필드가 한 자리 정수값만 입력으로 받아들이고 정수가 아닌 값의 입력은 막기 위해 입력 방법은 키패드로 제한한다.
• 이때 유효 범위는 1 이상 5 이하이다. 따라서 3개의 동등 분할이 존재한다 :
비유효(너무 낮음); 유효; 비유효(너무 높음).
• 유효 동등 분할의 경계값은 1 과 5이다.
• 비유효(너무 높음)분할의 경계값은 6이다.
• 비유효(너무 낮음) 분할은 변수가 하나뿐인 파티션으로 유일한 값 0이 경계값이다.
• 위의 예제에서는 각 경계에 대해 두 개의 값을 식별했다.
• 비유효(너무 낮음)과 유효 사이의 경계에 대해서는 테스트 값 0, 1을,
• 유효와 비유효(너무 높음) 사이의 경계에 대해서는 테스트 값 5, 6을 선택했다.(2-포인트)
• 이 기법에는 경계당 세개의 경계값을 식별하는 것도 있다. 경계 직전 값, 경계에 해당하는 값, 경계 직후의 값. (3-포인트)
• 낮은 쪽 경계에 해당하는 테스트 값은 0,1,2가 되며 높은 쪽 경계에 해당하는 테스트 값은 4, 5, 6이 된다.

동등 분할의 경계에서 동작이 잘못된 확률이 동등 분할 중간의 값에서 잘못된 확률에 비해 높다.
경계값 분석과 테스팅을 통해 SW가 경계값이 원래 속한 분할의 동작이 아닌 다른 분할의 동작으르 수행하는 것과 같은 종류의 결함 대부분을 식별할 수 있다.
경계값 분석은 모든 테스트 레벨에 적용가능하다.
이 기법은 일반적으로 숫자의 범위(날짜, 시간)와 연관된 요구사항을 테스트하는 데 적용된다.
경계값 분석 커버리지는 백분율로 포기하며, " 테스트한 경계값의 수/ 모든 경계값의 수" 이다.

같이 읽어보면 좋을 것 같은 글 : https://kitle.xyz/post/44/

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

시스템이 구현해야 하는 복잡한 비즈니스 규칙을 기록하기에 좋은 방법이다.
작성시 테스터는 시스템의 조건(입력)과 예상 동작(출력)을 식별한다.
결과에 영향을 미치지 않는 열, 불가능한 조건 조합 등을 삭제하면 테스트 케이스 수 가 상당히 줄어들 수 있다.

다음은 결정테이블의 예시이다(ISTQB_FL sample C Exam 출처)

	온라인 항공예약시스템에서 항공 사용이 빈번한 고객을 
    대상으로 포인트 항공권을 결제할 수 있도록 하는 기능에 대한 결정 테이블이다.

결정 테이블 테스팅에서 일반적인 최소 커버리지 기준은 테이블의 결정 규칙당 최소 한 개의 테스트 케이스를 작성한 것이며 이것은 일반적으로 모든 조건 조합을 포함한다.
커버리지는 일반적으로 백분율로 표기한다.
커버리지 = 최소 한 개의 테스트 케이스로 테스트한 결정 규칙의 수 / 식별한 모든 결정 규칙의 수
결정 테이블의 장점은 중요한 모든 조건 조합을 식별하는 데 도움이 된다는 것.(결정 테이블을 쓰지 않았다면 간과했을 수도 있는 조합 존재가능)
요구사항의 누락된 부분을 찾는 데도 도움이 된다.
소프트웨어의 동작이 조건 조합에 영향을 받는 모든 상황에 적용 가능하다.
모든 테스트레벨에 적용이 가능하다.

같이 읽으면 좋을 글 : https://inpa.tistory.com/entry/%F0%9F%A7%AA-%EA%B2%B0%EC%A0%95-%ED%85%8C%EC%9D%B4%EB%B8%94-%ED%85%8C%EC%8A%A4%ED%8A%B8

4.2.4 상태 전이 테스팅 (State Transition Testing)
컴포넌트, 시스템은 현재 조건(Conditions)이나 기존 이력(이벤트발생,History)에 따라 이벤트에 대해 다르게 반응할 수 있다.
기존 이력(History)은 상태(States)라는 개념을 활용해서 요약가능하다.
상태 전이 다이어그램은 소프트웨어의 가능한 상태뿐만 아니라 소프트웨어가 상태 간에 어떻게 진입하고 빠져나오는지에 대한 전이방법을 보여준다.
전이는 이벤트에 의해 시작되며, 이 이벤트는 전이라는 결과를 가져온다.
하나의 이벤트에 의해 동일한 상태로부터 두 개 이상의 다른 전이가 발생할 수 있다.
상태 변화로 소프트웨어가 특정 행동을 할 수도 있다.(ex: 연산 결과 또는 오류 메시지 출력).
상태 전이 테이블은 상태 간의 모든 유효 전이와 잠재적인 비유효 전이뿐만 아니라, 유효 전이와 관련된 이벤트, 결과 조치를 보여준다.
상태 전이 다이어그램은 일반적으로 유효한 전이만 보여주며, 비유효한 전이는 표시하지 않는다.
상태 전이 다이어그램 표기법 구성요소

◆ 상태(state) : 하나 또는 그 이상의 이벤트를 기다리는 모드원으로 표기, 원 안에 상태명 표시.
◆ 전이(transition) : 이벤트로 인해 한 가지 상태에서 다른 상태로의 변경, 화살표 형태의 링크로 표현하며 상태와 상태를 연결함.
◆ 이벤트 : 상태의 전이를 유발하는 요인, 화살표에 이름과 값을 표시(ex: ev취소)
그 외 가드와 액션이 있다.

다음은 상태전이다이어그램의 예시이다(ISTQB_FL sample C Exam 출처)

테스트는 상태의 일반적인 순서를 커버하거나, 모든 상태를 실행하거나, 모든 상태 전이를 실행하거나 특정한 상태 전이 순서를 실행하거나 불가능한 상태 전이를 테스트하도록 설계 가능하다.
메뉴 기반 애플리케이션이나 임베디드 소프트웨어 업계에서 널리 사용하고 있는 테스팅이다.
구체적인 상태를 포함한 비즈니스 시나리오를 모델링하거나 화면 탐색을 테스팅하는 데 적합한 기법이다.
커버리지는 일반적으로 백분율로 표시한다.
커버리지 = 식별한 상태나 전이 중 테스트된 수/식별한 모든 상태나 전이의 수.

reference: https://sw-test.tistory.com/8

※ 전이 분석에는 1-SWITCH, 0-SWITCH가 있다.

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

유즈케이스에서 테스트를 도출할 수 있으며, 이것은 소프트웨어 항목 간의 상호작용을 설계하는 특정 방법이다.
유즈케이스는 소프트웨어 기능에 대한 요구사항을 통합한다.
요즈케이스는 액터(사용자,외부 하드웨어, 기타 컴포넌트 시스템)와 대상(유즈케이스를 적용하는 컴포넌트나 시스템) 간의 관계이다.
각 유즈케이스는 대상이 하나 이상의 액터와 협력하여 수행할 수 있는 동작을 명시한다.(UML:Unified Modeling Language)
유즈케이스를 상호작용과 활동 그리고 적절한 경우 사전조건, 사후조건 및 자연어로 설명이 가능하다.
액터와 대상 간의 상호작용으로 대상의 상태가 변경될 수 있다.
상호작용은 워크플로우, 활동 다이어그램, 비즈니스 프로세스 모델로 시각화가 가능하다.
유즈케이스는 예외 동작 및 오류 처리(시스템 응답과 프로그래밍, 애플리케이션 및 통신 오류로부터의 복구, 오류 메시지 발생)를 포함한 기본 동작의 가능한 변형이 포함된다.
테스트는 정의한 동작(기본, 예외 또는 대안, 오류 처리)을 실행하도록 설계된다.
커버리지는 숫자로 표기한다.
커버리지 = 테스트한 유즈케이스 동작 수 / 모든 유즈케이스 동작