● Equivalence Partitioning(동등 분할)
개요
-입력값, 출력값 영역을 유한개의 상호 독립적인 집합으로 나누어 수학적인 등가집합을 만든 후, 각 등가 집합의 원소 중 대표값을 하나 선택하여 TC선정
-같은 종류의 입력에서 어떤 대표값을 사용하더라도 같은 결과를 나타낼 것이라 기대하는 방식
-동등분할클래스는 유효한 입력데이터와 유효하지 않은 입력데이터를 포함할 수 있음
Test Case in Equivalence Partitioning
-같은 특성을 가지면서 같은 방식으로 처리된다고 판단하는 모든 등가집합에서 대표하는 입력 값들을 적어도 한 개씩은 사용하는 기법
-경험과 필요에 따라 하나 이상의 값을 선정하여 TC를 작성하는 경우, 결과적으로 보장성은 동일
-명세에 있는 입/출력 값을 활용하기 때문에 명세기반 테스트 기법임(구조기반, 경험기반 기법도 적용 가능)
Equivalence Partitioning 적용 범위
-출력값
-내부값
-시간 관련값
-통합테스팅에서 다루는 모듈간 인터페이스 파라미터
테스트 강도
-약한 동등 분할 테스팅: 등가 집합에서 각각 하나의 대표값을 이용하여 TC 구성
-강한 동등 분할 테스팅: 각 영역의 등가 집합들 사이의 조합으로 나타낼 수 있는 모든 경우의 수를 고려한 테스팅
ex) 주차보조 시스템
● Boundary Value Analysis(경계값 분석)
개요
-경험적으로 개발자가 경계값 처리시 오류 발생 가능성이 높기 때문에 경계 주변 값을 테스트 데이터로 선정하는 기법
-테스트 대상 시스템의 입력 혹인 출력 영역의 경계 값에 초점을 맞추어 TC 도출
-경계값: 해당 분할 영역의 최대값과 최솟값(유효경계값, 비유효경계값)
-결함 발견율이 높고 적용하기 쉬운 장점이 있어 가장 많이 사용되는 테스트 기법 중 하나임
-경계값 분석 기법은 경계값을 명시한 자세한 명세서가 지원될 경우 적용하기 수월
Test Case in Boundary Value Analysis
-Equivalence Class를 찾은 후 대표값을 선택할 때 경계값과 그 전후의 값들을 사용하는 방법
Boundary Value Analysis의 한계점
-일련의 동작에 대한 조합을 테스트하기에는 적합하지 않음
-입력 범위를 동등 분할하여 제한하더라도 입력값 조합의 수가 테스트 가능한 수를 넘어서는 경우가 많음
-입력 조합이 상호간에 독립적(의존성이 없는)이라는 가정에서만 적합
-출력이 입력조건이나 변수들 사이의 관계에 따라 달라지는 경우, 입력조건을 동등분할 하는 것이 매우 어려울 수 있음
ex) 주차보조 시스템
● 조합 테스팅(Pair-wise)
개요
-대부분의 결함이 2개 요소의 상호작용에 기인한다는 것에 착안하여 2개 요소의 모든 조합을 찾아내어 테스팅함
-하나의 파라미터의 각 값들이 모든 다른 파라미터의 각 값들과 최소 한 번씩 조합이 되는 집합
Pair-wise 원리 이해
-세 가지 파라미터에서 나올 수 있는 모든 조합의 수는 8가지
-세 가지 요소들의 모든 값들이 한쌍씩 모든 조합을 이룸, 조합의 수 50%감소
Beyond Pair-wise Testing - Combinatorial Testing
-TC를 얼마나 효율적으로 줄일것인지에 대한 고민
-모든 조합을 테스트하는 것은 불가능하다는 가정
● 결정 테이블 테스팅(Decision Table Testing)
개요
-테스트를 수행하기 위해 필요한 입력의 조합을 얻어 내기 위한 목적
-원인과 결과를 분석함으로써 TC를 조합해 내는 방법
-Cause: inputs, Effect: outputs / 둘 다 boolean 형태로 기술
장점
-요구사항 등 테스트 베이시스의 문제점을 드러내게 하는 효과적 TC생성
-테스트 베이시스의 불완전성과 모호함 지적 가능
단점
-작성에 많은 노력과 시간이 소요될 수 있음
-복잡한 시스템을 표현하기 어려울 수 있으며 논리적으로 작성 시 실수 소지 존재
ex)
▽
● 상태 전이 테스팅(State Transtion Testing)
개요
-이벤트, 액션, 활동, 상태, 상태전이 사이의 관계를 검증하는 테스팅 방법
-시스템/소프트웨어의 상태기반 행위가 명세된 내용과 일치함을 검증
-상태기반 시스템의 결함은 상태, 상태전이, 가드, 이벤트 결함 등으로 분류
-결함은 구현이 잘못된 경우와 명세가 잘못된 경우가 존재
상태 전이 테스팅이 발견하는 결함의 종류
-모델상의 결함: 주로 명세의 리뷰 및 인스펙션을 통해 결함 발견
-구현상의 결함: STT(state transition test)
테스팅의 심도
-Switch level
→1-Switch Valid TC
ex) A simple State Transition Diagram
● 유즈케이스 테스팅(Use case testing)
유즈케이스 명세서
-시스템이 제공하는 기본 단위 기능, 즉 유즈케이스와 액터(사용자 및 시스템) 간의 상호작용을 정의
-개별적인 유즈케이스에 대한 단위 테스팅
유즈케이스 TC 추출을 위한 요구사항 시나리오 분석
-Functional Testing을 위한 TC는 요구사항 Spec에서 추출함
-TC는 각각의 요구사항 시나리오마다 작성
-요구사항 시나리오는 Basic Flow와 Alternative Flow로 기술됨
-요구사항을 통과하는 모든 경로를 조합하면 서로 다른 요구사항 시나리오를 만들 수 있음
-단, 반복은 한 번만 수행된다고 가정(Alternative Flow3 = Single loop)
ex) 자동주차 기능
-요구사항 시나리오가 실행되기 위한 특정 조건을 식별함으로써. 각 시나리오로부터 TC를 추출할 수 있음
-특정 조건에 따라 특정 요구사항 시나리오가 실행됨
→ Basic Flow
→ Alternative Flow
→ 요구사항 시나리오 정의
-Basic Flow와 Alternative Flow를 조합하여 요구사항 시나리오를 정의할 수 있음