ISTQB) Part4 테스트 설계 기법

* 이 글은 개발자도 알아야할 소프트웨어 테스팅 실무 제3판을 토대로 작성되었습니다.

* 책에 실린 내용 외 추가적인 정의가 있으며 교재 목차와 순서가 다소 다를 수 있습니다.

* 2차 가공 및 재배포는 금지합니다.

* 잘못된 개념 혹은 오탈자는 댓글로 알려주세요.

 

1. 테스트 설계 및 구현 프로세스

[ 테스트 명세서 종류 ]

* 테스트 설계 명세서

   - 설계 명세서 식별자, 테스트 대상 특성, 세부 접근 방법, 테스트 식별 및 특성의 성공/실패 기준

 

* 테스트 케이스 명세서

   - 식별한 테스트 케이스를 정의하는 문서

 

* 테스트 프로시저 명세서

   - 테스트 케이스 실행을 위한 단계를 명시하고 있는 문서

 

[ 테스트 설계 구현 프로세스 ]

* 우선 순위 선정 및 배치

   - 테스트 프로시저 명세서를 만듦

 

* 테스트 실행 스케줄 구성

   - 작성된 테스트 프로시저와 자동화된 테스트 스크립트를 언제 누가 수행할 것인지에 대해 구성

 

* 테스트 케이스 작성

   - 테스트 수행 절차를 얼마나 상세하게 작성할지를 결정해야 함

 

2. 테스트 설계 기법의 종류

[ 소프트웨어(시스템) 내부 구조(코드) 참조 여부에 따른 구분 ]

* 블랙박스 테스팅 ( Black-Box Testing )

   - 기능 테스팅, 사용자 관점에서의 테스트 방법

   - 명세 기반 기법과 경험 기반 기법 포함

   - 작동 원리를 모르는 상태에서 동작을 검사하는 방식

   - 기능이 오류없이 작동하고 명세에 맞게 작동하는지 시험하는데 사용

 

* 화이트박스 테스팅 ( White-Box Testing )

   - 구조 기반 기법, 개발자 관점에서의 단위 테스팅 기법

   - 소프트웨어 내부 소스 코드를 보면서 필요한 정보들을 사용

   - 컴포넌트(단위) 또는 소프트웨어의 구조를 중심으로 테스트 케이스를 도출

 

[ 테스트 설계의 근원을 기준으로 구분 ]

* 명세 기반 기법

   - 주어진 명세를 빠뜨리지 않고 테스트 케이스화하는 것

   - 커버리지 측정이 가능하나 구조 기반 기법의 커버리지에 비해 제한적

 

* 구조 기반 기법

   - 소프트웨어 코드나 설계 등 구조를 보여주는 정보로부터 테스트 케이스를 도출

   - 커버리지를 높이기 위해 테스트 케이스를 시스템적으로 도출 추가 가능

 

* 경험 기반 기법

   - 테스터, 개발자, 사용자 등의 지식이나 경험으로 테스트 케이스 도출

 

3. 기본, 고급 설계 기법

[ 명세 기반 기법 기본 ( Specification-based technique ) ]

* 명세 기반 기법 ( Specification technique )

   - 시스템에서 제공하는 기능 및 메뉴 등 명세를 기반으로 테스트 케이스를 설계하는 기법

 

* 동등 분할 ( Equivalence partitioning )

   - 동일한 영역 내에서는 어떠한 값을 선택해도 항상 같은 결과를 기대

   예) 성적 등급 계산 범위, 휴대폰 배터리 잔량 표시 (입력값)

        - 0 ≤ 점수 ≤ 49 (30) | 50 ≤ 점수 ≤ 69 (60) | 70 ≤ 점수 ≤ 89 (80) | 90 ≤ 점수 ≤ 100 (95)

        - 같은 범위안에서는 어떠한 입력값을 입력하더라도 동일한 결과가 나옴

 

* 경계값 분석 ( Boundary value analysis )

   - 입력 조건의 중간 값보다 경계값에서 에러가 발생될 확률이 높다는 점을 이용하여 테스트 케이스 생성

   예) 위의 예시 이어서

        - two-value : ( -1, 0 ), ( 49, 50 ), ( 69, 70 ), ( 89, 90 ), ( 100, 101 )

        - three-value : ( -1, 0, 1 ), ( 48, 49, 50, 51 ), ( 68, 69, 70, 71 ), ( 88, 89, 90, 91 ), ( 99, 100, 101 )

 

   - 동등 분할에서 데이터 선택은 특성상 테스트 결과가 달라질 수 있음

   - 테스터의 오류가 아닌 기법에서 제한적 테스트를 하기 때문

 

   - 경계값 분석에서 데이터 선택은 파티션의 최대/최소 값을 선택하는 경우 누가 선택해도 같은 값이 나오게 됨

 

* 결정 테이블 테스팅 ( Decision table testing )

   - 요구사항의 논리와 발생 조건에 따라서 생성될 수 있는 결과를 테이블의 형태로 나열한 것

   - 조건과 처리를 논리적 관계로 표현할 수 있는 모델에 적용

   - 조건은 원인, 처리는 결과로 참과 거짓으로 표현

   예) 휴대폰에 탑재되는 은행 업무 소프트웨어의 접속 부분

        - 칩 유효성, 유효한 비밀번호, 정상 계좌, 은행 업무의 메뉴를 이용 등

   - 장점 : 요구사항 등 테스트 베이시스의 문제점을 발견하는데 효과적인 테스트 케이스 생성 가능

   - 단점 : 작성에 많은 노력과 시간이 소요될 수 있음

 

* 상태 전이 테스팅 ( State transition testing )

   - 시스템에 반영되는 이전의 상태가 무엇인지, 상태간의 전이, 상태를 변화시키는 이벤트와 입력값을 파악

   - 상태 전이 다이어그램 사용

   예) MP3 동작 테스트, 음료 자판기 동작 테스트 등

 

* 유즈케이스 테스팅 ( Use case testing )

   - 실제 시스템의 동작을 사용자 입장에서 표현한 시나리오

   - 시스템에 관련한 요구사항을 알아내는 과정

 

[ 명세 기반 기법 고급 ]

* 분류 트리 기법 ( Classification Tree Method - CTM )

   - 소프트웨어의 일부 또는 전체를 트리 구조로 분석 및 표현하여 테스트 케이스를 설계하는 기법

   - 트리 구조를 시각화하여 테스트 케이스를 설계하므로 불필요한 중복 및 누락을 회피할 수 있음

   예) 모바일 뱅킹의 계좌 이체 : 이체 앱 → 비밀번호 | 입금계좌 | 이체금액 | 의뢰인 등

 

* 페어와이즈 조합 테스팅 ( Pairwise testing )

   - 대부분의 결함은 많아야 두 개 요소의 상호 작용에 의해 야기된다는 관찰에 기반하고 있는 기법

   - 장점 : 모든 조합에 비해 상대적으로 적은 양의 테스트 세트 구성 가능

   - Flat 조합 : 테스트 데이터 개수가 가장 많은 변수를 기준으로 단순 조합한 것

   - A) 1, 2, 3 | B) 4, 5

   - Flat) (1,4), (2,5), (3,4) | Pairwise (1,4), (1,5), (2,4), (2,5), (3,4), (3,5)

 

* 직교 배열 테스팅 ( Orthogonal array testing )

   - 잠재된 조합의 거대한 양을 처리하기 위한 테스트 케이스를 선정하는데 도움을 주는 통계적 테스팅 기법

   - 어느 행의 조합도 서로 다른 행의 조합과 서로 다르고, 어느 열의 조합도 서로 다른 열의 조합과 서로 다름

 

[ 구조 기반 기법 기본 ]

* 구조 기반 기법 ( Structure-based technique )

   - 코드와 개발 설계 등의 소프트웨어 구현 정보를 기반으로 테스트 케이스를 설계하는 기법

 

* 구문 테스팅과 커버리지 ( Statement testing and coverage )

   -  프로그램 내의 모든 문장들을 한 번 이상 수행하도록 테스트 케이스를 설계하는 기법

 

* 결정 테스팅과 커버리지 ( Decision testing and coverage )

   - 프로그램 내의 각 분기들을 한 번 이상 수행하도록 테스트 케이스를 설계하는 기법

   - 전체 조건식이 최소한 참이 한 번 그리고 거짓이 한 번 선택되었는지 측정하여 퍼센트로 표현

* 조건 테스팅과 커버리지 ( Condition testing and coverage )

   - 조건들이 참이 되는 경우와 거짓이 되는 경우를 모두 수행하도록 테스트 케이스를 설계하는 기법

   - 전체 조건식의 결과와 관계없이 각 개별 조건식이 참 한번, 거짓 한 번을 모두 갖도록 함

* 다중 조건 커버리지 ( Multiple condition coverage )

   - 프로그램 내의 모든 개별 조건식의 모든 가능한 논리적 조합을 고려한 강력한 커버리지

   - 출시 전에 반드시 100% 결함을 제거해야 하는 제품 테스트에서 주로 사용

* 변형 조건/결정 커버리지 ( Modified Condition/Decision Coverage )

   - 각 개별 조건식이 다른 개별 조건식에 무관하게 전체 조건식의 결과에 독립적으로 영향을 줌

[ 구조 기반 기법 고급 ]

* 분할 ( Splitting ) 방법으로 접근한 조건/결정 커버리지

   - 분할 ( Splitting ) : 생성한 모든 논리적 조합을 분할하여 테스트 케이스를 작성하는 방식

   결함의 원인 판단은 빠르지만 테스트 케이스 수가 크게 증가하게 됨

 

* 포함 ( Including ) : 생성한 조합 중 단 하나만 선택하여 하나의 논리적 테스트 케이스를 작성

   결함의 원인 판단이 느리지만 적당한 커버리지 만족과 테스트 케이스 수를 가짐

 

[ 경험 기반 기법 기본 ]

* 경험 기반 기법 ( Experience-based technique )

   - 테스터, 개발자, 사용자 등의 지식이나 경험으로 테스트 케이스 도출

   - 공식적인 기법으로 다루기 어려운 특별한 케이스를 찾아 실행

 

* 탐색적 테스팅 ( Exploratory testing )

   - 테스트 디자인, 수행, 기록, 학습이 동시에 진행

   - 테스트 목적을 담고 있는 테스트 차터를 기반으로 제한 시간 내에 수행하는 것

   - 테스트 케이스를 먼저 설계하지 않고, 테스트 대상 제품을 실행과 동시에 테스트 케이스 작성 및 수행

테스트 케이스 기반 테스팅	탐색적 테스팅
테스트가 먼저 설계됨	테스트가 설계됨과 동시에 수행
테스트 실행 관리	테스트 설계 향상
실행 전 테스트 케이스 작성	프로젝트 기반 내내 테스트 계획, 설계, 실행 반복
한 번에 완벽한 테스팅 수행	점진적이고 주기적으로 테스팅 수행

 

* 오류 추정 ( Error Guessing )

   - 테스터가 테스트 대상 시스템을 완전히 이해하고 있다는 전제로 진행함 ( 테스트 마지막 단계에서 수행 )

   - 가능한 결함을 나열하고 결함이나 오류를 추정에 의해 검출 및 수정

   - 유용성 : 참고 명세가 거의 없거나 불충분할 경우, 시간적 압박이 심한 경우 등

 

* 체크 리스트 ( Checklists )

   - 테스트하고 평가해야 할 내용과 경험을 분류하여 나열해 놓은 체크리스트를 기반으로 테스트 수행

테스트 케이스	체크 리스트
입력값, 예상 결과 등의 집합	테스트 항목을 예/아니오로 답할 수 있게 나열할 목록
동적 테스팅의 주요 도구	정적 테스팅 기법의 주요 도구
예시
사전 조사 / 실행 절차 / 기대 결과 / 실행 결과	이러한 기능이 있는가? (예/아니오) 등록이 되는가? (예/아니오)

 

4. 기법 선택 및 특성에 따른 테스팅

[ 테스트 기법의 선택 ]

* 고려되어야 할 요인

   - 시스템 유형

   - 고객 또는 계약상의 요구사항

   - 리스크 수준 및 유형

   - 테스터의 지식 수준

   - 시간과 예산

   - 유즈케이스, 상태 다이어그램 등 모델 존재 유무

 

* 테스트 기법은 여러가지가 동시에 복합적으로 선택되어 사용됨

 

[ 소프트웨어 특성에 따른 테스팅 ]

* 기능성

   - 요구되는 기능 및 성능을 만족시키는 능력

   - 기능 하나 하나에 대해 테스트 케이스 작성

   - 부특성 : 적합성, 정확성, 상호운영성, 보안성, 준수성(기능성 관련 표준, 규정, 관례 등을 따르는 능력)

   예) 메신저나 어플리케이션의 조건이 기대한 결과가 나오는지

 

* 신뢰성

   - 규정된 시스템 환경에서 결함없이 의도한 기능 및 작업을 수행하는 소프트웨어 능력

   - 여러 상황의 조합 또는 예외 상황의 처리 능력을 확인하는 절차를 테스트 케이스로 작성

   - 부특성 : 성숙성(사용자의 오류를 피하는 능력), 오류 허용성, 회복성, 준수성

   예) 사용자가 로그인 화면에 암호를 입력할 때 최대 입력 길이가 되는 20자 이상 입력시 경고음 나오는 것

 

* 사용성

   - 사용자가 이해하고 배우기 쉬운 정도

   - 부특성 : 이해성, 학습성, 운용성, 친밀성, 준수성

   예) 윈도우 기본 글꼴 정해놓기 ( 통일 )

 

* 효율성

   - 자원의 적절한 사용 및 적정한 반응시간

   - 부특성 : 시간의 효율성, 자원 효율성, 준수성

   예) 메신저 동시 접속자 수 혹은 목록 검색 시 3초 이내로 DB 목록이 검색되는 것

 

* 유지보수성

   - 소프트웨어의 수정 및 변경의 용이성

   - 부특성 : 분석성, 변경성, 안정성, 시험성, 준수성

   예) 메신저 서버 장애 시 문제 상황을 로그 파일에 기록하는 것

 

* 이식성

   - 지원하는 다양한 운영환경에서 운영될 수 있는 소프트웨어의 능력

   - 부특성 : 적응성, 설치성, 대체성, 공존성, 준수성

   예) 윈도우 영문버전이 설치되면 정상적으로 영어가 나오는지, 서로 다른 메신저끼리 충돌이 일어나지 않는 것