PART4 테스트 설계 기법
4. 테스트 설계 기법
TC를 도출하고 수행하여 테스트 대상이 어느 수준까지 테스팅 되었는지 확인하기 위해 사용된다. 다양한 종류의 테스트 설계 기법으로 어떻게 TC를 도출하고 테스트에 보장성을 확보해 주는지 보자.
4.1 테스트 설계 및 구현 프로세스( Test design & implementation process)
테스트 조직 구성, 테스팅과 개발 프로세스의 성숙도, 시간적 제약, 참여 인원 등 테스팅 정황(context)에 따라 달라진다.
테스트 조건을 식별하기 위해 테스트 베이시스를 분석한다.
트랜잭션, 품질 특성 또는 구조적 요소 등이 있다.
테스트 조건과 명세 및 요구사항 사이에 추적성(tracebility)를 유지함으로써 요구사항이 변경 시 영향도 분석과 요구사항 커버리지를 확인할 수 있다.
TC 구성 요소
사전 조건, 수행 절차, 기대 결과와 실행 사후조건 외에도 테스트 케이스 ID, TC 명, 추적성, 중요도, 결과 등 내용에 따라 포함된다.
테스트 수행 절차 : 7단계 이내 권고
결과 : NOT TESTED, BLOCKED (사전 조건이 충족하지 않아 테스트가 수행되지 않음)
TC 목적
최소한의 TC로 가능한 많은 결함을 발견하는 것
대상을 빠짐없이 테스트하여 원하는 수준의 테스트 보장성(coverage) 확보할 수 있도록 tc 설계해야 함
4.2 테스트 설계 기법 종류
블랙 박스 기법(명세 기반 기법과 경험 기반 기법을 포함)
내부 코드 참조하지 않고 테스트 베이시스, 개발자와 테스터, 사용자들의 경험을 바탕으로 tc 도출
화이트 박스 기법 (구조 기반 기법)
컴포넌트(단위) 또는 sw의 구조(코드)를 중심으로 tc 도출하는 방법
명세 기반 기법 특징
공식적이거나 비공식적인 모델을 사용
구조 기반 기법의 특징
수행된 tc 바탕으로 테스트 커버리지를 측정할 수 있으며, 커버리지 높이기 위해 tc를 시스템적으로 도출해 추가할 수 있다.
경험 기반 기법 특징
인력의 지식이나 경험으로 tc 도출
sw에서 자주 발생하는 결함이나 결함 분포 등의 지식
4.3 기본 설계 기법(fundamental test design techniques)
명세 기반 기법
동등 분할, 경계값 분석, 결정 테이블 테스팅, 상태 전이 테스팅, 유즈케이스 테스팅
주어진 명세(개발 설계 모델 형태)를 바탕으로 tc를 도출하는 것을 의미, 해당 tc를 실행해 중대한 결함 없음을 보장함
고려해야 할 사항
상태 다이어그램, 유즈케이스 등의 모델로 표현되어 있지 않을 경우, 명세 기반 기법을 적용하기 위해서 테스트 전문가가 요구사항 분석서와 설계서 먼저 작성한 후 tc를 작성하는 것을 고려해야 한다.
조기 테스트 설계
동작하는 sw가 없어도 명세만 있다면 명세 기반 기법으로 tc를 도출할 수 있다.
4.3.1.1 동등 분할(Equivalence partitioning)
동등 분할 영역에서 최소 하나 값을 선택하여 테스트를 수행한다.
등가 집합에서 대푯값만 선정 : 약한 동등 분할 테스팅 weak equivalence testing
각 등가 집합(equivalence class)에서 하나의 대푯값을 선택하여 tc를 구성한다.
각 세분화된 등가 집합 간의 조합을 모두 고려할 수 있다.
강한 동등 분할 테스팅(strong equivalence partitioning testing)
각 등가 집합의 모든 조합을 고려한 테스팅
4.3.1.2 경계값 분석(boundary value analysis)
아.. 날라감요 ㅠ 4.7까지 했는데
상태 다이어그램으로 시스템을 설계하는 과정에서 도출할 수 있는 결함
모델상의 결함
초기상태 누락, 전이 또는 액서 ㄴ누락, 가드를 전이 대신 상태에 표기함, 가드의 중복 또는 불일치
구현상의 결함(defects in implementation)
여분/누락/훼손 상태(extra, missing, corrupt state)
액션이 틀리거나 누락됨
스니크 패스(sneak paths), 트랩 도어(trap doors, back doors)
tc 설계 순서
상태-이벤트 테이블 구성
전이 트리 구성
반응 legal, 또는 유효 valid tc 구성
무반응 illegal 또는 비유효 invalid tc 구성
가드 guard 또는 조건 tc 구성
테스트 프로시저 구성
^ : 가드가 존재하는 상태, 가드에 있는 조건에 따라 전이 상태가 변경될 수 있다.
2) 전이 트리 구성
각 상태에서 전이 가능한 상태로 한 번씩 전이되는 경우를 모두 테스트하면 0-스위치 커버리지를 달성하게 된다.
두 번씩 연속적으로 전이될 경우를 테스트하면 1-스위치 커버리지를 달성
=> 스위치 커비리지의 수가 높아질 수록 커버하는 깊이 레벨이 높아져 더 강도 높은 테스트 하게 된다.
즉, 각 상태에서 n 번째 전이되는 경우를 모두 테스트하면 상태전이 테스팅의 n-1 스위치 커버리지를 달성하게 된다.
4) 무반응 tc 구성
비유효한 tc 도출하던 중 모호 부분 발견할 수 있다.
음료 선택 가능한 상태에서 금액 추가 넣을 경우 음료 선택이 가능해야 하지만 예제 명세에는 없다.
이 경우 결함일 가능성 높으므로 확인해야 한다.
일반적으로 명세를 테스팅한다고 표현하며, 명세를 테스팅함으로써 실제 시스템이 개발되기 전에 결함을 예방할 수 있다.
5) 가드(guard) 또는 조건 tc 구성
이벤트가 조건을 포함하고 해당 조건에 따라 기대결과가 달라지는 경우를 반영한 것이다.
가드의 조건이 동등 분할 집합을 갖는 조건문이면 도메인 기반 동등 분할 기법과 경계값 분석 기법을 적용할 수 있다.
가드가 복잡한 조건문으로 구성되어 있으면 컨디션 커버리지(MC/DC : modified condition . decision coverage) 테스팅을 할 수 있다.
누락된 조건을 테스팅하는 가드 tc 추가할 수 있다.
6) 테스트 프로시저 또는 스크립트 구성
테스트 프로시저는 테스트의 실행 순서를 나타낸 것으로 tc를 순차적으로 나열한 것이다.
테스트 프로시저를 기술한 문서를 테스트 프로시저 명세(테스트 절차 명세)라 하며 테스트 스크립트, 수동 테스트 스크립트 라고 한다.
상태전이 테스팅은 제품 개발 전 단계에서 명세만을 가지고 tc 도출한 것이다.
=> 실제 구현된 시스템을 대상으로 테스트 실행하면서 tc 작성하는 것이 아니라 명세만을 가지고도 tc를 작성할 수 있으며 이와 같은 활동 통해 결함 발견이 가능하여 미리 결함을 예방할 수 있다.
4.3.1.5 유즈케이스 테스팅
액터(유저 혹은 시스템)와 액터 사이의 상호작용을 표현하고, 해당 상호작용은 시스템 유저에게 결과값을 제공한다.
각각의 유즈 케이스는 임무 완수 후 후속 조건(post conditions - 관찰 가능한 결과와 시스템의 마지막 상태)를 가지면서 종료된다.
대게 주류 시나리오 또는 기본 흐름(mainstream scenario, basic or main flows) 과 대체 흐름(alternative branches or alternative flows)으로 구성되어 있따. 각각의 유즈 케이스는 자세하게 표현하기 위해 유즈케이스 상세(use case description)을 갖는다.
유즈케이스 기본 흐름과 대체 흐름
atm기에서 유효하지 않은 카드를 넣어 카드 판독이 불가능하거나 부정확한 암호 입력, 잔액 부족 등의 대체흐름을 포함한다.
대부분의 유즈케이스가 컴포넌트 테스팅 레벨에서 되면 시스템 레벨의 유즈케이스 테스팅에서는 활동 전이 또는 경로 커버리지를 달성하는 테스트를 통해 유즈케이스 간의 활동과 전체 시스템 차원에서의 기능적 결함이나 성능상의 결함 등 비기능적 결함을 발견하는 것에 집중한다.
경로 커버리지
모든 경로의 조합을 고려하여 tc 도출하고 실행하는 것이다.
경로에 재귀적인 반복이 있는 경우(loop)
경로의 조합 기하급수적 증가, 경로 커버리지 달성하는 것이 불가능하다.
=> 적절한 기준을 가지고 반복 횟수 줄여 제한적 경로 커버리지를 달성한다.
입력값의 파라미터가 다양하고 많은 경우
=> 동등 분할과 경계값 분석 기법 및 조합 테스팅을 활용하여 입력값의 수를 관리 가능한 범위로 줄여야 한다.
UML 에서 유즈케이스 이벤트의 흐름을 어떻게 구조화시켜 조직하고 작성하는지 제시하지 않아 테스트의 근간이 되는 유즈케이스로 ㅍ현된 것 자체가 정확하지 않고 일관성이 낮을 수 있다.
4.3.2 구조 기반 기법 (Structure-based technique)
sw 나 시스템의 구조를 중심으로 테스팅하는 것이다.
컴포넌트 레벨의 구조는 구문 statement, 결정 decision 또는 분기문 branch 등 코드 자체이다.
코드 기반 테스트 기법과 커버리지와의 관계는 명확하다.
'ISTQB CTFL' 카테고리의 다른 글
개발자도 알아야 할 소프트웨어 테스팅 실무 요약 4-3 (0) | 2023.01.11 |
---|---|
개발자도 알아야 할 소프트웨어 테스팅 실무 요약 4-2 (0) | 2023.01.11 |
개발자도 알아야 할 소프트웨어 테스팅 실무 요약3 (0) | 2023.01.08 |
개발자도 알아야 할 소프트웨어 테스팅 실무 요약2 (1) | 2023.01.08 |
개발자도 알아야할 소프트웨어 테스팅 실무 요약1 (0) | 2023.01.07 |