테스트 기법 개요
테스트 기법은 테스터의 테스트 분석(무엇을 테스트할지)와 테스트 설계(어떻게 테스트할지) 작업을 지원한다.
테스트 기업은 적은 수이지만, 충분한 TC를 체계적인 방식으로 개발할 수 있도록 해준다.
테스트 기법은 테스터가 체스트 분석과 설계에서 테스트 컨디션을 정의하고, 커버리지 항목과 테스트 데이터를 식별하는 데 도움을 준다.
테스트 기법은 세가지로 분류된다.
- 블랙박스 테스트 기법(명세 기반 기법) : 내부 구조를 참조하지 않고, 명시된 동작에 대한 분석을 기반으로 한다. TC는 소프트웨어
구현방식에 의존하지 않는다. 구현이 바뀌어도 동작이 동일하면 TC는 유효하다.
- 화이트박스 테스트 기법(구조 기반 기법) : 테스트 대상의 내부 구조와 처리에 대한 분석을 기반으로 한다. TC는 소프트웨어 설계
방식에 의존하기 때문에 테스트 대상의 설계나 구현이 끝난 후에 만들 수 있다.
- 경험 기반 테스트 기법 : 테스터의 지식과 경험을 테스트 케이스의 설계 및 구현에 효과적으로 활용하게 한다. 이 기법의 효과성은
테스터의 능력에 따라 크게 달라진다. 경험 기반 테스트 기법은 블랙박스, 화이트박스 기법으로 식별하지
못하는 결함을 찾을 수 있게 해준다.
블랙박스 테스트 기법
많이 사용되는 블랙박스 테스트 기법은 다음과 같다
- 동등 분할
- 경계값 분석
- 결정 테이블 테스팅
- 상태 전이 테스팅
동등 분할
동등 분할은 테스트 대상이 하나의 분할에 포함된 모든 요소를 동일한 방식으로 처리할 것이라는 가정 하에 데이터를 분할 단위로 나눈다. 동등 분할에 속한 특정 값을 테스트 하는 테스트 케이스로 결함을 식별할 수 있다면, 같은 동등 분할의 다른 어떤 값을 테스트하는 TC라도 해당 결함을 식별할 수 있어야 한다는 것이다.
-> 따라서 각 분할에 대해 하나의 테스트만 수행하면 충분하다.
분할을 연속적이거나 아닐수도 있으며, 유한 또는 무한일수도, 정렬되어 있을수도 있다. 분할은 겹치지 않아야 하며, 값이 없는 공집합일 수는 없다. 단순한 테스트일 경우, 동등 분할을 적용하기가 쉽지만, 실제로는 테스트 대상이 다양한 값을 어떻게 처리하는지 이해하기 어려울 때가 많다. 따라서 분할 식별은 신중하게 해야 한다.
유효한 값을 포함하는 분할을 유효 분할, 비유요한 값을 포함하는 분할을 비유효 분할이라고 한다.
동등 분할에서 커버리지 학목은 각 분할이 된다. 이 테스트 기법으로 100%커버리지를 달서앟려면 테스트 케이스로 각 분할을 최소 한번씩 다뤄 식별한 모든 분할이 실행되도록 해야 한다.
많은 테스트 항복이 다수의 분할 집합을 가지고 있기 때문에 하나의 테스트 케이스는 여러 분할 집합에 속한 분할을 다루게 된다. 분할 집합이 다수인 경우, 가장 간단한 커버리지 기준을 이치 초이스 커버리지 라고 한다.
이치 초이스 커버리지는 테스트 케이스가 모든 분할 집합의 각 분할을 최소 한번은 실행할 것을 요구한다.
--> 이치 초이스 커버리지에서는 분할의 조합은 고려하지 않는다.
경계값 분석
경계값 분석은 동등 분할의 경계 실행을 기반으로 하는 테스트 기법이다. 따라서 경계값 분석은 정렬된 분할에만 사용할 수 있다.
분할의 최솟값과 최댓값이 경계값이 된다. 경계값 분석에서 두 값이 같은 분할에 속하는 경우, 둘 사이의 모든 값도 해당 분할에 속해야 한다.
개발자가 분할의 경계에 있는 값을 다룰 떄 오류를 범할 가능성이 높기 때문에 경계값 분석은 분할의 경계에 있는 값에 초점을 두게 된다. 경계값 분석으로 많이 찾는 결함은 구현된 경계가 의도한 위치보다 위나 아래에 잘못 배치되거나 누락된 결함이다.
경계값 분석은 두가지 유형이 있다.
- 두 개 선택 경계값 분석
- 세 개 선택 경계값 분석
두 유형은 100%의 커버리지를 달성을 위해 실행해야 하는 경계별 커버리지 항목의 수에서 차이가 난다.
두 개 선택 경계값 분석은 각 경계값에 대해 두 개의 커버리지 항목을 도출한다.
경계값과 인전 분할에 속한 가장 가까운 값이 커버리지 항목이다. 두 개 선택 경계값 분석에서 100%커버리지를 달성하려면, 테스트케이스로 모든 커버리지 항복, 식별한 모든 경계값을 실행해야 한다. 커버리지는 실행한 경계값의 수/경계값의 총 수 이다.
세 개 선택 경계값 분석은 각 경계값에 대해 세 개의 커버리지 항목을 도출한다.
이웃한 양쪽의 값 모두가 커버리지 항목이다. 따라서 세 개 선택 경계값 분석에서는 경계값이 아닌 커버리지 항목도 있을 수 있다. 세 개 선택 경계값 분석에서 100% 커버리지를 달성하려면, 테스트 케이스로 모든 커버리지 항목, 식별한 경계값과 그 이웃 값을 실행해야 한다. 커버리지는 실행한 경계값과 이웃한 값의 수/식별한 경계값과 이웃 값의 총 수 이다.
결정 테이블 테스팅
결정 테이블은 서로 다른 조건 조합으로 달라지는 결과를 나타내는 방식으로 요구사항이 제대로 구현되었는지를 테스트 하는 데 사용한다. 결정 테이블은 비즈니스 규칙과 같은 복잡한 논리를 기록하는 효과적인 방법이다.
결정 테이블을 만들 때 조건들과 그에 따른 시스템의 동작 결과를 정의한다.
조건의 표기법은 T, F, -, N/A로 표기한다.
전체 결정 테이블에는 모든 조건 조합을 포함할 수 있는 충분한 열이 있다. 실현 불가능한 조건 조합열을 삭제해 테이블을 더 단순화 할 수 있다.
일부 조건이 결과에 영향을 미치지 않는 열들을 하나로 병합해 테이블을 최소화 할 수도 있다.
이 기법으로 100%커버리지를 달성하려면 테스트케이스가 이런 열을 모두 실행해야 한다.
커버리지는 실행된 열의 수/실행 가능한 열의 총 수로 나눈 값으로 측정하며 백분율로 표시한다.
결정테이블의 장점 : 간과했을 수도 있는 조합을 포함한 모든 조건 조합을 식별하는 체계적인 방법을 제공한다.
결정테이블의 단점 : 조건이 많으면 규칙의 수가 기하급수적으로 늘어 오랜 시간이 걸릴 수 있다.
상태 전이 테스팅
상태 다이어그램(state diagram)은 가능한 상태와 유효한 상태 전이를 표시해 시스템 동작을 모델링한다.
전이는 하나의 이벤트에 의해 발생하며, 별도의 가드 조건이 있을 수 있다. 전이는 즉각적인 것으로 간주되며, 소프트웨어의 어떤 동작으로 연결되기도 한다.
상태 테이블은 상태 다이어그램을 다르게 표현한 모델이다. 행은 상태를 나타내고, 열은 이벤트를 나타낸다. 테이블 항목은 전이를 나타네며, 정의되어 있는 경우에는 목표 상태와 그에 따른 결과 동작도 함께 포함한다. 상태 전이 다이어그램과 달리 상태 테이블은 유효하지 않은 전이를 "빈 셀"로 명확하게 보여준다.
상태 다이어그램이나 상태 테이블을 기반으로 하는 테스트 케이스는 보통 일련의 이벤트 순서와 그 결과로 생기는 상태 변화로 표현된다. 하나의 테스트 케이스는 대부분의 경우 여러 개의 상태 전이를 포함한다.
상태 전이 테스팅에는 세가지 커버리지 측정 기준이 있다.
- 모든 상태 커버리지 : 커버리지 항목은 상태이다. 100%커버리지를 달성하려면 모든 상태가 실행되도록 TC를 구성해야 한다.
- 유효 전이 커버리지 : 각 유효 전이가 커버리지 항목이다. 100%커버리지를 달성하려면 TC가 모든 유효 전이를 실행해야 한다.
- 모든 전이 커버리지 : 상태 테이블에 표시된 모든 전이들이 항목이다. 100%를 달성하려면 TC로 모든 유효 전이를 실행하고
유효하지 않은 비유효 전이의 실행도 시도해야 한다. 오직 하나의 비유효 전이만을 테스트 하는 것은
결함 마스킹을 방지하는 데 도움이 된다.
모든 상태 커버리지는 일반적으로 모든 전이를 실행하지 않고도 달성하기 때문에 유효 전이 커버리지보다 약하다.
유효 전이 커버리지는 가장 널리 사용하는 커버리지 조건이다.
유효 전이 커버리지 100%를 달성하면 모든 상태 커버리지도 달성된다.
모든 전이 커버리지 100%를 달성하면 모든 상태 커버리지와 유효 전이 커버리지도 모두 모장된다.
모든상태 < 유효전이 < 모든전이
미션과 안전에 치명적인 소프트웨어의 경우 이것을 충족해야 할 최소 기준으로 삼으면 된다.
화이트박스 테스트 기법
화이트 박스 테스트는 다음 두가지 기법이 가장 널리 사용된다.
- 구문 테스팅
- 분기 테스팅
안전이나 미션에 치명적이거나 무결성이 높아야 하는 환경에서는 철저한 코드 커버리지를 달성하기 위해 보다 엄격한 화이트박스 기법이 사용된다. 또한 상위 테스트 레벨에 사용하거나, 코드와 관련 없는 커버리지를 사용하는 화이트 박스 테스트 기법도 있다.
구문 테스팅과 구문 커버리지
구문 테스팅에서 커버리지 항목은 실행 가능한 구문이 된다.
코드 구문을 실행하는 테스트 케이스를 설계해서 허용할 수 있는 수준의 커버리지를 달성하는 것이다. 커버리지는 테스트 케이스가 실행한 구문 수를 코드의 실행 가능한 구문 총수로 나누어 계산하며 백분율로 표시한다.
100% 구문 커버리지를 달성하면 코드의 모든 실행 가능한 구문을 적어도 한 번은 실행하겠다는 것이 보장된다. 이는 결함이 있는 모든 구문도 실행해 결함 존재를 식별할 수 있는 장애가 났타났어야 함을 의미한다고 여길 수 있다.
그러나 TC로 구문을 실행했다고 결함이 반드시 식별되는 것은 아니다. ex)데이터에 종속적인 결함 등
또한 100%구문 커버리지가 모든 결정 논리를 테스트했다고 보장하는 것도 아니다.
분기 테스팅과 분기 커버리지
분기는 제어 흐름 그래프에서 두 노드 간의 제어 이동으로 테스트 대상에서 소스 코드 구문의 실행 가능 순서를 보여준다.
제어의 이동은 조건 없이 또는 조건에 따라 이루어질 수 있다.
분기 테스팅에서 커버리지 항목은 분기이며, 목적은 코드의 분기를 실행하는 TC를 설계해서 허용할 수 있는 수준의 커버리지를 달성하는 것이다.
100% 분기 커버리지를 달성하면 코드의 모든 분기를 테스트 케이스로 실행하게 된다.
분기 커버리지는 구문 커버리지를 포함한다. 100% 분기 커버리지를 달성하는 테스트 케이스 집합은 100% 구문 커버리지도 달성
화이트박스 테스팅의 가치
화이트박스 테스트 장점 : 테스트 중 전체 소프트웨어 구현을 고려하므로 소프트웨어 명세가 모호하거나 뒤떨어지고 불완전한 경우에도 결함을 쉽게 찾을 수 있다.
화이트박스 테스트 단점 : 소프트웨어가 하나 이상의 요구사항을 구현하지 않는 경우 누락 됐다는 결함을 식별하지 못할 수 있다.
화이트박스 테스트 기법은 정적 테스팅에 사용할 수 있다. 아직 실행할 준비가 되지 않은 코드 외에도 슈도코드 또는 제어 흐름 그래프로 모델링 할 수 있는 상위 수준 및 하향식 논리를 검토하는 데 적합핟.
** 블랙박스 테스팅만 수행해서는 실제 코드 커버리지 측정치를 얻을 수 없다. 화이트박스 커버리지 측정치는 객관적인 커버리지 측정 값을 제공하고, 이 커버리지를 높이기 위해 추가 테스트 생성을 위한 정보도 제공함으로써, 코드 신뢰도를 높일 수 있다.
경험 기반 테스트 기법
경험 기반 테스트 기법 중 주요한 3가지는 다음과 같다.
- 오류 추정
- 탐색적 테스팅
- 체크리스트 기반 테스팅
오류 추정
오류 추정 : 테스터의 지식을 기본으로 오류, 결함, 장애 발생을 예측하는 데 사용하는 테스트 기법이다.
테스터의 지식에는 다음이 포함된다.
- 애플리케이션의 과거 동작
- 개발자가 범하기 쉬운 오류 유형과 이런 오류로 인해 발생하는 결함 유형
- 다른 유사 애플리케이션에서 발생한 장애 유형
일반적으로 오류, 결함, 장애는 입력, 출력, 논리, 계산, 인터페이스, 데이터와 관련 있을 수 있다.
결함 공격 : 오류 추정을 구현하는 방법 중 하나이다. 테스터가 발생 가능한 오류, 결함, 장애 목록을 만들거나 획득하여 오류와 관련된 결함을 식별 및 노출하거나 장애를 유발하는 테스트를 설계하도록 한다.
탐색적 테스팅
탐색적 테스팅 : 테스터가 테스트 대상에 대해 배워가면서 테스트의 설계, 실행, 평가를 동시에 하게 된다. 이 테스팅은 테스트 대상에 대해 더 배우고, 집중하고 있는 테스트는 더 깊이 탐색하고, 테스트 되지 않은 영역에 대한 테스트를 만들기 위해 사용된다.
탐색적 테스팅은 떄로 테스팅을 구조화하기 위해 세션 기반 테스팅을 사용하기도 한다. 세션 기반 접근법에서는 탐색적 테스팅을 시간을 정해놓고 수행한다. 테스터는 테스트 목적이 정의된 테스트 차터를 테스팅 지침으로 사용한다.
탐색적 테스팅은 명세가 버ㅜ족하거나 부적합할 경우, 테스트에 시간적 압박이 심할 때 유용하다. 탐색적 테스팅은 다른 공식 테스트 기법을 보완하기에도 유용하다.
체크리스트 기반 테스팅
체크리스트 기반 테스팅에서 테스터는 체크리스트를 활용해 테스트 컨디션을 확인하는 테스트를 설계, 구현, 실행한다.
체크리스트는 경험, 사용자에게 중요한 것이 무엇인지에 대한 지식 또는 소프트웨어가 실패하는 이유와 방법에 대한 이해를 바탕으로 작성할 수 있다.
자동으로 점검할 수 있는 항목, 시작 조건, 종료 조건으로 더 적합한 항목, 너무 일반적인 항목은 체크리스트에 포함해서는 안된다.
체크리스트 항목을 질문 형식으로 표현하는 경우가 많다. 각 항목은 개별적이면서 직접적으로 확인할 수 있어야 한다. 이런 항목은 요구사항, 그래픽 인터페이스 속성, 품질 특성 또는 기타 유형의 테스트 컨디션일 수 있다.
체크리스트는 기능 및 비기능 테스트를 포함한 다양한 테스트 유형을 지원하기 위해 만들 수 있다.
시간이 지남에 따라 개발자가 같은 오류를 범하지 않게 됨으로써 일부 체크리스트 항목은 점차 효과가 떨어질 수 있다.
새로 발견한 심각도가 높은 결함으로 인해 새로운 항목을 추가해야 할 수도 있다.
-> 따라서 체크리스트는 정기적으로 업데이트 해야 한다.
협업 기반 테스트 접근법
협업 기반 접근법은 협업과 커뮤니케이션을 통한 결함 예방에 초점을 둔다.
협업 기반 사용자 스토리 작성
사용자 스토리는 사용자 또는 구매자에게 가치를 제공하는 기능을 나타낸다.
사용자 스토리는 다음 세가지 중요 요소를 가지고 있다. 이를 3C라고 부른다.
- 카드(Card) : 사용자 스토리를 설명하는 매체
- 대화(Conversation) : 소프트웨어 사용 방법에 대한 설명
- 확인(Confirmation) : 인수 조건
사용자 스토리의 가장 일반적인 형식은 "'역할'로서 '목표'를 달성해 [역할이 얻게 될 비즈니스 가치]를 얻기를 원한다"이며, 이 후 인수 조건이 뒤따르는 형식이다.
협업 기반 사용자 스토리 작성은 브레인스토밍, 마인드 매핑과 같은 기법을 사용한다.
좋은 사용자 스토리는 독립적이고, 협상 가능하고, 가치 있고, 추정 가능하고, 작고, 테스트 가능해야 한다(INVEST)
이해 관계자가 사용자 스토리를 테스트 하는 방법을 모른다면, 그 사용자 스토리가 명확하지 않거나 사용자에게 중요한 내용이 반영되어 있지 않거나, 이해관계자가 테스트를 수행하는 데 있어 도움이 필요하다는 것을 의미할 수 있다.
인수 조건
사용자 스토리의 인수 조건은 사용자 스토리 구현 결과를 이해관계자가 승인하기 위해 충족되어야 하는 조건이다.
인수 조건은 3C 중 대화(Conversation)을 통해 결정된다.
인수 조건은 다음을 위해 사용된다
- 사용자 스토리 범위 정의
- 이해관계자 간 합의 도출
- 긍정과 부정 시나리오 설명
- 사용자 스토리 인수 테스팅의 베이시스 제공
- 정확한 계획 및 추정
다양한 사용자 스토리의 인수 조건 작성법이 있으며 일반적인 형태는 두가지이다
- 시나리오 기반
- 규칙 기반
인수 테스트 주도 개발
인수 테스트 주도 개발은 테스트 우선 접근법이다. TC는 사용자 스토리 구현 전에 만들어진다.
테스트 케이스는 사용자 스토리의 모든 특성을 다뤄야 하며 스토리를 벗어나면 안된다.
테스트 자동화 프레임워크가 지원하는 형식으로 작성하면 개발자는 사용자 스토리에서 설명하는 기능을 구현할 때 필요한 코드를 작성해 테스트 케이스를 자동화 할 수 있다. 그러면 인수 테스트가 실행 가능한 요구사항이 된다.
'공부 > ISTQB' 카테고리의 다른 글
| 테스트 도구 (0) | 2026.02.12 |
|---|---|
| 테스트 활동 관리 (0) | 2026.02.11 |
| 정적 테스팅 (0) | 2026.02.09 |
| 소프트웨어 개발수명주기(SDLC)와 테스팅 (0) | 2026.02.08 |
| 테스팅의 기초(Fundamentals of Testing) (0) | 2026.02.07 |