4.1 테스트 기법의 종류
테스트 기법의 선택은 다음과 같은 여러 요소를 기반으로 이루어짐.
- 컴포넌트나 시스템의 복잡도
- 규제 기준
- 고객 또는 계약 요구사항
- 리스크 수준과 유형
- 사용 가능한 문서
- 테스터의 지식과 역량
- 사용 가능한 도구
- 시간과 예산
- 소프트웨어 개발 수명 주기 모델
- 컴포넌트나 시스테에서 에상되는 결함 유형
4.1.1 테스트 기법의 종류와 특성
이 실라버스에서는 테스트 기법을 블랙박스, 화이트박스, 경험 기반으로 분류.
블랙박스 테스트 기법 특징 -테스트 대상의 내부 구조를 고려하지 않고, 입력과 출력에 집중
- 테스트 컨디션, 테스트 케이스, 테스트 데이터는 소프트웨어 요구사항, 명세서, 유스케이스, 사용자 스토리와 같은 테스트 베이시스로 부터 도출.
- 테스트 케이스는 요구사항과 요구사항 구현 결과물 간 차이와 편차를 식별하는 데 사용
- 커버리지는 테스트 베이시스에서 테스트된 항목과 테스트 베이시스에 적용한 기법을 기반으로 측정.
화이트박스 테스트 기법 특징 - 테스트 대상의 내부 구조와 처리에 집중
- 테스트 컨디션, 테스트 케이스, 테스트 데이터는 코드, 소프트웨어 아키텍처, 상세 설계 또는 소프트웨어 구조와 관련된 기타 정보를 포함한 테스트 베이시스로부터 도출.
- 커버리지는 선택한 구조 ( 코드나 인터페이스) 내에서 테스트한 항목과 테스트 베이시스에 적용된 기법을 기준으로 측정
경험 기반 테스트 기법 특징 - 개발자, 테스터, 사용자의 경험을 활용하여 테스트를 설계, 구현, 실행. 이 기법은 화이트박스 및 블랙박스 테스트 기법과 결합해서 사용하는 경우가 많음.
- 테스트 컨디션, 테스트 케이스, 테스트 데이터는 테스터, 개발자, 사용자, 기타 이해관계자의 지식과 경험과 같은 테스트 베이시스로부터 도출.
4.2 블랙박스 테스트 기법 - 동등분할 , 경계값 분석, 결정 테이블 테스팅, 상태 전이 테스팅, 유스케이스 테스팅
4.2.1 동등분할 - 특정 파티션의 모든 변수는 동일한 방식으로 처리된다는 가정으로 파티션( 동등 클래스)에 데이터를 분할. 유효한 값과 비유효한 값 모두에 대해 동등 분할 구성.
- 유호값이란 컴포넌트나 시스템에 입력되는 값. 유효한 값을 포함하는 동등한 파티션을 "유효 동등 분할"이라고 함
- 비유효값이란 컴포넌트나 시스템이 거부하는 값. 유효하지 않은 값을 포함하는 동등한 파티션을 "비유효 동등 분할"이라고 함.
- 분할은 입력값, 출력값, 내부값, 시간관련, 인터페이스 매개변수를 포함하여 테스트 대상과 관련된 모든 데이터 요소에 대해 식별.
- 필요한 경우 모든 파티션은 하위 파티션으로 나눌 수 있음.
- 모든 값은 동등 분할에 포함되어야 하며, 하나의 값은 하나의 동등 분할에만 속해야 함.
- 비유효 동등 분할을 테스트 케이스로 만들 때는 장애가 마스크 즉, 가려지는 것을 방지하기 위해 개발적으로 테스트해야 하며, 다른 비유효 동등 분할과 조합하지 않아야 함.
4.2.2 경계값 분석 - 동등 분할의 확장 형태이지만 각 파티션이 순서화되어 있고, 숫자 또는 연속 데이터로 구성된 경우에만 적용. 분할의 최소값과 최대값은 해당 분할의 경계값이 됨.
예제) 유효 범위는 1이상 5이하 일때 3개의 동등 분할이 존재. 비유효(너무 낮음), 유효; 비유효(너무 높음) 유효 동등 분할의 경계값은 1과 5. 비유효(너무 높음) 분할의 경값은 6이다. 비유효(너무 낮음)은 0이 경계값이 된다. 이 예제에서는 각 경계에 대해 두개값을 식별했다. 비유효(너무낮음)과 유효는 0 ,1 이고 유효와 비유효(너무높음)에는 5,6을 선택 . 이 기법의 여러 유형 중에는 경계당 세 개의 경계값을 식별하는 것도 있다. 경계직전값, 경계 해당값, 경계직후의 값 0 1 2 , 4 5 6 이 됨.
4.2.3 결정 테이블 테스팅 - 시스템이 구현해야 하는 복잡한 비즈니스 규칙을 기록하기에 좋은 방법. 결정 테이블을 작성할 때 테스터는 시스템의 조건(주로 입력)과 예상 동작(주로 출력) 을 식별. 이것들은 테이블의 행을 형성하며 일반적으로 조건은 위쪽에, 기대 결과는 아래쪽에 둔다. 각 열은 하나의 결정규칙으로 특정 조건의 고유한 조합과 연관된 기대 결과로 정의. 조건과 기대 결과의 값은 일반적으로 참 또는 거짓으로 표기 하거나, 빨간색 녹색 파란색등과 같은 비연속 값을 표기하지만 숫자나 숫자 범위로 표현하는 경우도 있음.
일반적인 표기법
조건 :
- Y, 조건이 참이라는 것을 의미 ( T또는 1로 표기할 수 있음)
- N, 조건이 거짓이라는 것을 의미(F 또는 0으로 표기)
- ㅡ, 조건의 값이 중요하지 않다는 것을 의미(N/A 표기가능)
기대 결과 :
- X, 행동이 일어난다는 것을 의미(Y,T,1로 표기 가능)
- 공백 행동이 일어나지 않음을 표기(ㅡ, N, F, 0으로 "")
4.2.4 상태 전이 테스팅 - 컴포넌트나 시스템은 현재 조건이나 기존 이력( 예를 들어, 시스템이 초기화되고 난 후 발생한 이벤트) 에 따라 이벤트에 대해 다르게 반응할 수 있다. 기존 이력은 상태라는 개념을 활용해서 요약 가능. 상태 전이다이어그램은 소프트웨어의 가능한 상태뿐만 아니라 소프트웨어가 상태 간에 어떻게 진입하고 빠져나오는지에 대한 전이 방법을 보여줌. 전이는 이벤트에 의해 시작(예를 들어, 사용자가 입력 필드에 값을 입력), 이 이벤트는 전이라는 결과를 가져옴. 하나의 이벤트에 의해 동일한 상태로부터 두 개 이상의 다른 전이가 발생할 수 있다. 상태 변화로 소프트웨어가 특정 행동을 할 수도 있다.(예 연산결과 오류 메시지 출력). 상태전이 테이블은 상태 간의 모든 유효 전이와 잠재적인 비유효 전이뿐만 아니라, 유효 전이와 관련된 이벤트, 결과 조치를 보여줌. 상태 전이 다이어그램은 일반적으로 유효한 전이만 보여주며, 비유효 전이는 표시하지 않는다.
테스트는 상태의 일반적인 순서를 커버하거나, 모든 상태를 실행하거나 모든 상태 전이를 실행하거나 특정한 상태 전이 순서를 실행하거나 또는 불가능한 상태 전이를 테스트하도록 설계 할 수 있다.
4.2.5 유스케이스 테스팅 - 유스케이스에서 테스트를 도출할 수 있으며, 이것은 소프트웨어 항목 간의 상호작용을 설계하는 특정 방법. 유스케이스는 소프트웨어 기능에 대한 요구사항을 통합한다. 유스케이스는 엑터( 즉 사용자, 외부 하드웨어, 기타 컴포넌트나 시스템)와 대상(유스케이스를 적용하는 컴포넌트나 시스템)간의 관계
각 유스케이스는 대상이 하나 이상의 엑터와 협력하여 수행할 수 있는 동작들을 명시하고 있다.유스케이스를 상호작용과 활동으로 설명하기도 하고, 적절한 경우 사전조건, 사후조건 및 자연어로 설명할 수도 있다. 엑터와 대상 간의 상호작용으로 대상의 상태가 변경될 수 있다. 상호작용은 워크플로우, 활동다이어그램, 비지니스 프로세스 모델로 시각화 할 수 있다. 유스케이스에는 예외 동작 및 오류 처리를 포함한 기본동작의 가능한 변형이 포함.
4.3 화이트박스 테스트 기법 - 구문 테스팅과 커버리지, 결정 테스팅과 커버리지
4.3.1 구문 테스팅과 커버리지 - 잠재적으로 실행 가능한 구문을 실행한다. 테스트로 실행한 구문의 수를 테스트 대상의 모든 실행 가능한 구문의 수로 나눠서 계산
4.3.2 결정 테스팅과 커버리지 - 코드에 존재하는 결정문을 실행하고 결정문의 결과에 따라 실행하는 코드를 테스트함. 이것을 달성하기 위해 테스트 케이스는 결정문에서 시작되는 제어 흐름을 따라 실행된다.(예를 들어 , IF문에서 결과가 참인 경우와 거짓인 경우 ; CASE 문에서 기본 결과를 포함한 가능한 모든 결과를 필요로 하는 테스트 케이스).
결정문 결과의 수를 테스트 대상의 가능한 모든 결정문 결과의 수로 나눠서 계산.
4.3.3 구문 및 결정 테스팅의 가치 - 구문 커버리지는 다른 테스트에 의해 실행되지 않은 코드의 결함을 찾는데 도움이 된다. 결정 커버리지는 다른 테스트가 참과 거짓 결과 모두를 테스트하지 않은 코드의 결함을 찾는데 도움이 된다. 100% 결정 커버리지는 100%구문 커버리지를 보장하지만 반대의 경우는 성립하지 않는다.
4.4 경험 기반 테스트 기법 - 경험 기반 테스느 기법을 적용할 경우 테스트 케이스는 테스터의 기술 역량과 직관 그리고 유사한 에플리케이션과 기술에 대한 경험을 기반으로 도출.
4.4.1 오류 추정
오류 추정은 다음을 포함한 테스트 지식을 기반으로 오류, 결함 및 장애 발생을 예측하는 데 적용하는 기술
- 애플리케이션의 과거 동작
- 발생하기 쉬운 오류의 유형
- 다른 애플리케이션에서 발생한 장애
4.4.2 탐색적 테스팅 - 탐색적 테스팅에서는 비공석(사전에 정의되지 않은) 테스트를 테스트 실행 중에 동적으로 설계, 실행, 기록하고 평가. 테스트 결과는 컴포넌트나 시스템에 대해 더 많이 학습하고, 더 많은 테스트가 필요한 영역에 대한 테스트를 작성하는 데 활용. 탐색적 테스팅은 때로 세션기반 테스팅을 사용하여 활동을 구성. 정해진 시간동안 수행하며, 테스터는 테스트 목적이 포함된 테스트 차터를 활용해 테스트 방향을 설정.테스터는 테스트 세션 시트에 수행 단계와 발견 사항 기록.
탐색적 테스팅은 명세가 충분하지 않거나 적은 경우 또는 테스팅에 상당한 시간적 압박이 있을 때 가장 유용. 또한, 탐색적 테스팅은 다른 보다 공식적인 테스팅 기법을 보완하는 데도 유용.
4.4.3 체크리스트 기반 테스팅 - 체크리스트에 기록된 테스트 컨디션을 커버하기 위해 테스터가 테스트를 설계, 구현, 실행한다. 테스터는 분석의 일환으로 새로운 체크리스트를 작성하거나 기존 체크리스트를 확장할 수 있지만, 기존 체크리스트를 수정하지 않고 그대로 사용하는 경우도 있다. 체크리스트는 경험, 사용자에게 무엇이 중요한지에 대한 지식 또는 소프트웨어가 실패하는 이유와 방법에 대한 이해를 기반으로 작성할 수 있다. 체크리스트는 기능 및 비기능 테스팅을 포함한 다양한 테스트 유형을 지원하기 위해 작성할 수 있다. 구체적인 테스트 케이스가 없는 경우, 체크리스트 기반 테스팅은 대략적인 지침과 일관성을 제공할 수 있다. 이런 체크리스트는 상위 수준으로 작성되기 때문에 실제 테스팅에서 어느 정도의 가변성이 있기 마련이며, 따라서 커버리지는 늘어날 수 있지만 재현 가능성은 줄어들 수 있다.