ISTQB Syllabus 2005 통합정리 (4. Test design techniques)

원문 : http://blog.naver.com/josephy74/70018639453
문제가 될 경우 바로 연락주세요. 바로 삭제하겠습니다.

4. Test design techniques

 

4.1 Identifying test conditions and designing test cases

 

테스트 조건(test conditions)과 테스트를 설계하는 것은 여러 단계로 구성된다.

 

• 테스트 조건을 정의함으로써 테스트를 설계하는 것
• 테스트 케이스를 명세하는 것
• 테스트 절차 (test procedure)를 명세하는 것

 

 

프로세스는 문서가 거의 없는 매우 비형식적인 것에서 부터 매우 형식적인 것까지(이것은 다음 섹션에서 설명될 것이다.) 여러가지 방법으로 수행될 수 있다. 형식성의 레벨은 다음과 같은 테스팅 내용에 따라 다르다. - 테스팅 조 직, 테스팅과 개발 프로세스의 성숙도(maturity), 시간 제약, 관련된 사람들

 

테스트 설계(test design) 동안에,  테스트 조건을 정의하는 것과 같이 무엇을 테스트 할지 결정하기 위하여, 테스트 기반이 되는 문서들을 분석한다. 테스트 조건은 하나 또는 그 이상의 테스트 케이스로 검증될 수 있는 항목(item)이나 이벤트로서 정의된다.(e.g 기능, 트랜잭션, 품질 특성 또는 구조 적인 요소)

 

테스트 조건에서 역으로 명세와 요구사항으로 추적성(traceability)을 만드는 것은 요구사항이 변경되었을 경우의 영향 분석과 과 테스트 셋에 대하여 결정되어야 하는 요구사항 커버리지 분석을 모두 가능하게 한다. 테스트 설계 동안에 ,상세한 테스트 기법은 여러가지 고려 사항 가운데 정의된 위험에 기반하여 구현된다.

 

테스트 케이스 명세 동안에, 테스트 설계 기법에 의하여 테스트 케이스 들과 테스트 데이터가 개발되고 상세하게 서술된다. 테스트 케이스는 입력 값의 집합(set of input values), 실행 선행조건(execution preconditions), 예상 결과(expected results) 그리고 실행 후조건(execution post-conditions)으로 구성되며, 어떤 테스트 조건(들)을 커버하기 위하여 개발된다. "소프트웨어 테스트 문서화를 위한 표준"(Standard for Software Test Documentation) (IEEE 829)는 테스트 디자인 명세와 테스트 케이스 명세의 내용을 설명한다.

 

예상결과는 반드시 테스트 케이스 명세의 일부분으로 제공되어야 하며 , 출력, 테이터와 상태의 변경사항, 그리고 테스트의 또다른 결과를 포함하여햐 한다. 만약 에상 결과가 정의되지 않는다면, 그럴듯해 보이지만 잘못된 결과가 올 바른 것으로 판단 될 수 있다.

 

테스트 케이스는 실행가능한 순서로 작성된다.; 이것이 테스트 절차(test procedure) 명세이다. 테스트 절차(또는 수동 테스트 스크립트) 명세는 테스트 실행에 대한 액션의 시퀀스를 명세한다. 만약 테스트가 테스트 실행 도구를 이용하여 실행된다면, 액션의 시퀀스는 테스트 스크립트(이것은 자동화된 테스트 절차이다.)안에 명세 된다.

 

테스트 절차나 스크립트가 누눈가에 의하여 수행될 때, 다양한 테스트 절차들과 자동화된 테스트 스크립들은  테스트 절차나 자동화된 테스트 스크립트의 순서를 정의하는 테스트 실행 스케줄을 구성한다. 테스트 실행 스케쥴은 회귀 테스트(regression test), 우선 순위화(prioritization), 그리고 기술적이고 논리적인 의존관계(dependencies)와 같은 요소들을 고려해야 한다.

 

4.2 Categories of test design techniques (K2)

 

테스트 설계 기법의 목적은 테스트 조건(test conditions)과 테스트 케이스(test cases)를 정의하는 것이다.

 

테스트 기법의 고전적인 분류 방법은 블랙 박스 테스트와 화이트 박스 테스트로 표기하는 것이다. 블랙 박스 기법(명세 기반 기법으로도 불린다)은 컴포넌트나 시스템에 대하여 내부적인 구조에 대한 참조없이, 기능과 비기능 모두 테스트 기반 문서의 분석에 기반하여, 테스트 조건과 테스트 케이스를 유도하고 선택하는 방법이다. 화이트 박스 기법(구조적 혹은 구조 기반 기법으로 불린다.)은 컴포넌트나 시스템의 내부적인 구조의 분석에 기반한 방법이다.

 

대부분의 기법들은 명확하게 하나의 범위에 속한다. 나머지들은 하나 이상의 범주 요소를 갖는다. 이 요약서에서는 블랙 박스 기법으로는 명세 기반이나 경험 기반 접근 방식을 말하며, 화이트 박스 기법으로는 구조 기반 방식을 말한다.

 

명세 기반 기법(Specification-based techniques)의 일반적인 특징은 다음과 같다.

• 소프트웨어나 소프트웨어 컴포넌트의 모델들은, 형식적이건 비형식적이건 모두 풀어야 할 문제의 명세를 위해 사용된다.
• 이러한 모델로 부터 테스트 케이스들은 체계적으로 유도될 수 있다.

구조 기반 기법(Structure-based techniques)의 일반적인 특징은 다음과 같다.

• 소프트웨어가 어떻게 구성되었는가에 대한 정보, 예를 들어 코드와 디자인은 테스트 케이스들을 유도하는데 사용된다.
• 소프트웨어 커버리지 범위는 존재하는 테스트 케이스로 측정할 수 있다. 커버리지를 증가시키기 위해서 더 많은 테스트 케이스들이 규칙적으로 유도될 수 있다.

경험 기반 기법(Experience-based techniques)의 일반적인 특징은 다음과 같다.

• 경험과 지식이 있는 사람들이 테스트 케이스를 추출한다.
    - 테스터, 개발자, 사용자와 여러 이해 당사자(stakeholders)의 소프트웨어, 소프트웨어의 사용과 환경에 대한 지식
    - 있음직한 결함(defect)과 분포에 대한 지식

 

===============================================================================

 

◆ 테스트 설계 기법 분류

 

▪ 명세기반 기법
  - 일반적으로 공식적/비공식적 모델이 명세화를 위해 사용됨
  - 테스트 케이스를 모델로부터 체계적으로 도출
  - 문서기반

  - Equivalence Partitioning, Boundary value analysis, Decision table testing, State transition testting, Use case testing

 

▪ 구조기반 기법
  - SW 코드나 설계 등 구조를 보여주는 정보로부터 테스트 케이스 도출
  - 소프트웨어의 커버리지 정도가 기존 테스트 케이스로부터 측정되고 커버리지를 늘리기 위하여 추가적 테스트 케이스가 체계적으로 도출

 

▪ 경험기반 기법
 - 테스터, 개발자, 사용자 등의 지식활용
 - 발생가능한 결함과 그 분포 등에  대한 지식
 - 문서화 필요

 

4.3 Specification-based or black-box techniques

 

4.3.1 동등 분할  (Equivalence partitioning) (K3)

 

소프트웨어나 시스템의 입력은 비슷한 행위를 가지는 그룹으로 나뉘어지며 같은 그룹에 속하는 입력들은 같은 방법으로 처리 된다. 동등 분할(또는 분류)은 유효한 데이터와 유효하지 않은 데이터, 예를 들어 거부되어야 하는 값들에서 발견 될 수 있다. 분할(partitions)들은 결과, 내부적인 값들, 시간에 관련된 값들(e.g 이벤트 전후의), 그리고 인터페이스 파라미터(e.g 통합 테스팅 동안의)에 대하여도 정의된다. 테스트는 분할들을 커버할 수 있도록 설계되어야 한다. 동등 분할(EP)은 모든 레벨의 테스팅에 적용이 가능하다.

 

기법으로써의 동등 분할은 입력과 출력 커버리지를 얻기 위하여 사용될 수 있다. 이것은 사람을 통한 입력, 인터페이스를 통한 시스템에 대한 입력, 또는 통합 테스팅에서의 인터페이스 파라미터들에 적용될 수 있다.

 

4.3.2 경계값 분석 (Boundary value analysis) (K3)

 

 각각의 동등분할의 경계에서의 행위는 더욱 잘못될 경우가 많다. 따라서 경계(boundaries)들은 결함(defect)을 포함할 것 확률이 높은 테스팅 영역이다. 분할 부분의 최대값과 최소값이 분할된 부분의 경계값이다. 유효한 분할 부분의 경계값은 유효한 경계값이다. 마찬가지로 유효하지 않은 분할 부분의 경계값은 유효하지 않은 경계값이다. 테스트는 유효한 경계값과 유효하지 않은 경계값 모두를 커버하도록 설계될 수 있다. 테스트 케이스를 설계할 때, 각각의 경계에 대한 값이 선택되어야 한다.

 

경계값 분석은 모든 단계의 테스트에 적용될 수 있다. 이것은 일반적으로 적용하기 쉬우며, 결함(defect)를 발견하는 능력이 높다.; 자세한 명세는 도움이 된다.

이 기법은 종종 동등 분할의 확장으로 간주된다. 그리고 인간에 의한 입력은 물론, 시간이나 테이블 경계들에 대한 입력에도 사용될 수 있다. 또한 경계값은 테스트 데이터 선택을 위하여 사용될 수도 있다.  

 

4.3.3 의사결정 테이블 (Decision table testing) (K3)

 

의사결정 테이블(decision table)은 논리적인 조건을 포함하고 있는 시스템의 요구사항을 찾아내고, 내부적인 시스템의 설계를 문서화하는 좋은 방법이다. 의사결정 테이블들은 시스템이 구현해야 하는 복잡한 업무규칙(bisiness rule)을 기록하기 위하여 사용할수도 있다. 명세가 분석되고, 시스템의 조건과 동작(actions)이 정의된다. 입력 조건과 행위는 대부분의 경우 true나 false 모두를 가질 수 있는 방법(Boolean)으로 지정된다. 의사결정 테이블은 트리거 조건, 모든 입력 조건들에 대한 true, false의 조합, 그리고 각각의 조건의 조합에 대한 결과 행위를 포함한다. 테이블의 각 컬럼은 규칙과 연관된 행위의 실행의 결과로 나타나는 조건들의 유일한 조합을 정의하는 업무규칙(bisiness rule)과 관련이 있다. 일반적으로 의사결정 테이블 테스팅에 사용되는 커버리지 표준은 일반적으로 트러거 되는 조건들의 모든 조합을 커버하는 것을 포함하는 각 컬럼마다 하나의 테스트 케이스를 갖는 것이다.

 

의사결정 테이블 테스팅의 강점은 테스팅 동안에 실행되지 않을 수 있는 조건들의 조합을 만들어낸다는 것이다. 의사결정 테이블 테스팅은 몇가지 논리적인 결정들에 의존하는 소프트웨어의 동작(action)때의 모든 상황에 적용 할 수 있다.

 

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

 

시스템은 현재의 조건이나 이전 히스토리(시스템의 상태)에 의존하는 각기 다른 결과를 보여줄 수 있다. 이러한 시스템의 측면은 상태 전이 다이어그램으로 보여질 수 있다. 상태 전이 다이어그램은 테스터가 시스템을 시스템의 상태, 상태들 사이의 전이, 상태의 변화(트랜잭션)을 일으키는 입력이나 사건 그리고 이러한 트랜잭션의 결과가 될 수 있는 행위의 관점에서 보는 것을 가능하게 한다.

 

테스트시의 시스템 상태 또는 객체들은 분리 될 수 있고, 식별이 가능해야 하며, 그 수가 제한된다.상태 테이블은 상태와 입력 사이의 관계를 보여주고, 무효화 될 가능성이 있는 트랜잭션을 강조하여 보여줄 수 있다. 테스트는 전형적인 상태의 시퀀스를 커버하고, 모든 상태를 커버하고, 모든 트랙잭션을 실행하고, 특정 트랜잭션의 시퀀스를 실행하거나 유효하지않은 트랜잭션을 테스트 하도록 설계 될 수 있다.

 

상태 전이 테스팅은 일반적으로 기술적인 자동화와 임베디드 소프트웨어 산업분야에서 더 많이 사용된다. 그러나, 이러한 기법은 특정 상태를 갖는 비지니스 객체의 모델링이나 화면 형식의 대화형 플로우 테스팅(testing screen-dialog flows)(e.g 인터넷 응용 프로그램이나 업무 시나리오)에 대해서도 역시 적용가능하다.

 

4.3.5 유스케이스 테스팅 (Use case testing) (K2)

 

테스트들은 유스케이스나 업무 시나리오에서 명세 될 수 있다. 유스케이스는 시스템 사용자에 대하여 가치있는 결과를 생산하는 시스템과 사용자를 포함하는 액터들 사이의 상호작용을 묘사한다. 각각의 유스케이스는 유스케이스가 성공적으로 작동하기 위하여 만족시켜야 하는 선행조건(preconditions)을 가진다. 각각의 유스케이스는 관찰 가능한 시스템의 상태와 결과를 가진 후행조건(post-conditions)으로 종료된다. 일반적으로 유스케이스는 하나의 주된(i.e 가장 있음직한) 시나리오와 때때로의 분기점들을 갖는다.

 

유스케이스는 실제로 있음직한 시스템의 사용을 통하여 "프로세스 흐름(process flows)"을 묘사한다. 따라서 유스케이스에서 유도된 테스트 케이스들은 시스템 실사용 동안의 프로세스 흐름내에 존재 할 수 있는 결함들(defects)을 발견하는데 유용하게 사용된다. 유스케이스는 종종 시나리오로서 언급되며, 고객/사용자가 참여하는 승인 테스트를 설계하는데 매우 유용하다. 유스케이스는 개별적인 컴포넌트 테스팅에서는 볼 수 없는 여러가지 컴포넌트의 간섭과 상호작용이 원인이 되는 커버되지 않는 통합적인 결함(integration defects)를 고치는데 도움이 된다.

 

===============================================================================

정적 블랙 박스 테스트 : 명세서 테스트

 

명세서를 테스트 하는 것은 정적 블랙박스 테스트에 해당한다. 명세서를 테스트하는 것은 명세서에 대한 개괄적인 검토를 하는 첫번째 단계와 명세서에 대한 세부적인 검토를 하는 2단계로 나눌수 있다.

 

[명세서에 대한 개괄적인 검토]

명세서에 대한 개괄적인 검토는 당장에 버그를 찾아내는 것이 아니라 넓은 범위에서 명세서의 근본적인 문제나 간과한 부분, 누락된 부분을 찾아내는 것이다. 이러한 조사는 소프트웨어의 역할에 대한 이해를 돕는다. 이 단계에서의 가이드라인은 다음과 같다.

 

• 사용자 입장에서 생각하라.
  고객의 요구사항을 이해하는 것은 중요하다. 이러한 요구사항을 이해한 다음에 테스트를 하여야한다. 추측은 금물이다. 이해하지 못한 부분이 있다면 반드시 이해하도록 노력해야 한다. 
• 존재하는 표준과 지침을 조사하라.
   - 존재하는 표준과 지침으로는 회사내의 용어 및 관례, 업계의 요구 사항, 정부 기준(특히 국방 관련), GUI, H/W 및 네트워크 표준
• 유사한 소프트웨어 검토 및 테스트 - 이 작업은 테스트 상황과 접근법을 생가해 보는데 도움을 준다.

 

[명세서에 대한 세부적인 검토]

제품 명세에 대한 고수준의 검토가 끝나면 제품의 종류와 어떤 외부적 요소가 설계에 고려되었는지 이해가 될 것이다. 이 정보를 참고하여 좀 더 자세한 테스트를 할 수 있다.

 

• 일반적으로 잘 만들어진 명세서는 다음의 속성을 가진다. 
   - 완결성, 정확성, 정밀함, 명백함, 일관성, 연관성, 실행 가능성,코드의 배제, 테스트 가능성
   - 이러한 속성을 충족시키지 않는 부분이 버그이며, 이는 보고의 대상이 된다.
• 명세서를 검토하는 동아나 명세에 쓰여진 용어 역시 적절한가를 검토해야 한다. 명세서에서 명확히 정의되어 있는 경우는 문제가 되지 않지만 모호한 경우는 버그로 생각해야 한다. 

 

동적 블랙박스 테스트

 

코드의 세부 사항에 대한 통찰 없이 소프트웨어를 테스트하는 것이 동적 블랙 박스 테스트이다. 이 경우 고객이 사용하는 것처럼 프로그램을 실행하기 때문에 동적이며, 작동 방법에대해서는 모르는 상태이기 때문에 블랙 박스 테스트이다. 일반적으로 동작 테스트라고 불리며, 효과적으로 수행하기 위해서는 소프트웨어의 역할에 대한 정의 즉 요구사항 문서 또는 제품 명세서가 필요하다. 여기서는 소프트웨어 내부에서의 동작은 알 필요가 없이 입력에 대한 출력 만을 알면된다.

 

[통과 테스트 (Test to Pass)와 실패 테스트 (Test to Fail)]

 

통과 테스트의 경우 소프트웨어가 최소한 작동한다는 사실이 확인되어야 한다. 여기에서는 소프트웨어의 성능은 시험하지 않는다. 따라서 가장 단순하고 간단한 테스트 케이스만을 적용하여 테스트한다.  테스트 케이스를 설계하고 실행할 때 항성 성공 테스트를 먼저해야 한다. 보통의 상황에서 소프트웨어가 지정된 대로 작동한다는 것을 확실히 확인한 다음에는 예외 상황 즉, 정도를 벗어난 극단적인 방법으로 소프트웨어를 취급하여 버그를 찾아야 한다. 실패 테스트는 소프트웨어의 일반적인 약점을 조사하기 위하여 전략적으로 선택된 케이스들이다.

 

[동등분할 (Equivalence Partitioning)]

 

동등 분할의 목표는 가능한 테스트 케이스의 수를 테스트하기에 충분하게 작고 처리하기 쉬운 수로 축소하는 것이다. 단 테스트 케이스의 수를 줄이려고 노력하는 동등 분할 작업을 너무 많이 하다보면 버그를 발견할 수 있는 테스트를 생략할 가능성이 있다. 또한 동등 분할은 주관적이다. 따라서 다른 작업자들이 분할을 검토하여 충분히 소프트웨어를 테스트 할 수 있는지를 판단해야 한다.

 

▪ Input/output space를 유한개의 상호 독립적인 집합(mutual disjoint subset)들로 나누어 관리
▪ 등가 집합을 만든 후 각 등가집합의 원소 중 하나의 대표값을 선택하여 testcase를 선정한다.
▪ Weak Equivalence Class Testing : 등가집합의 각각에 대하여 하나의 대표값을 이용하여 test case 구성
▪ Strong Equivalence Class Testing : 각 domain의 등가 집합들 사이의 조합으로 나타낼 수 있는 모든 경우의 수를 고려

 

[데이터 테스팅 (Data Testing)]

 

소프트웨어에 대한 간단한 견해는 데이터와 프로그램 영역으로 나누는 것이다. 데이터를 소프트웨어로 테스트하는 경우 사용자가 입력하는 정보, 얻게 되는 결과, 소프트웨어 내부의 모든 중간 결과가 정확하게 취급되는지 확인하게 된다. 복잡한 프로그램을 테스트 할 수 있게 만들어주는 비결은 경계 조건, 하위 경계조건, 잘못된 데이터 등 몇몇 개념에 기초한 동등 분할에 의하여 테스트 사례의 수를 줄이는 것이다.

 

▪ 테스트 대상 시스템의 입력 혹은 출력 영역의 경계 값에 초점을 맞추어 테스트 케이스 도출

 

▪ 경계조건(Boundary Condition) : 한 소프트웨어가 성능의 한계점에서도 잘 동작한다면 보통의 상황에서도 잘 동작할 것이다. 경계조건의 유형으로는 숫자, 속도, 문자, 위치, 장소, 크기, 양 등이 있으며, 동등 분할에 어떤 데이터를 포함할 지 결정했다면 경계에 해당하는 데이터를 선택하는 것이 좋다.
▪ 하위 경계 조건(Sub-Boundary Conditions) : 소프트웨어 내부에 있는 어떤 경계는 최종 사용자에게 나타나지 않지만 소프트웨어 테서트의 확인이 필요한 경우가 있다. 이것을 하위 경계 조건 또는 내부 경계 조건이라 한다.

 

[상태 테스팅 (State Testing)]

 

소프트웨어 테스터는 프로그램의 상태와 상태 사이의 전환 과정을 테스트해야 한다.

 

▪ 소프트웨어의 논리적 흐름 테스팅 : 소프트웨어의 상태와 논리적 흐름을 테스트하는 것은 동일한 문제로 모든 상태를 테스트하는 것은 간단한 프로그램을 제외하고는 불가능하다. 이런 경우 먼저 상태 도표를 만들어야 한다. 상태 도표에는 소프트웨어가 처할 수 있는 고유한 상태, 한 상태에서 다른 상태로 전환하는 입력 또는 상태, 상태가 입력 또는 선택될 때의 조건과 해당 출력 설정이 포함되어야 한다. 도표가 만들어졌다면 많은 수의 가능성을 작업 가능한 크기의 테스트 케이스로 다음 기준을 참고삼아 축소해야 한다.

              - 각 상태를 최소한 한 번 거친다.
              - 가장 흔하고 많이 쓰이는 상태 사이의 변환을 테스트 한다.
              - 상태에 이르는 거의 사용되지 않는 경로를 테스트한다.
              - 모든 오류 상태를 확인하고 오류 상태에서 원래대로 돌아오는지 확인한다.
              - 무작위로 상태 변환을 확인한다.

▪ 실패 상태 테스트 : 이 경우는 소프트웨어가 장애를 일으키는 테스트 케이스를 찾는 것으로 다음의 경우이다. 

              - 경쟁 상태 및 잘못된 타이밍
              - 반복, 스트레스, 부하 테스트
    

    이 경우 고려해야 하는 사항으로는 다음의 두가지 사항이 있다.
    

            - 팀의 프로그래머 또는 프로젝트 매니저는 소프트웨어를 파괴하려는 당신의 노력에 우호적이지 않다.
            - 프로그램을 열고 닫는 수많은 반복 작업을 수행하는 것이 불가능할지도 모른다.

 

▪ 이벤트, 액션, 활동, 상태, 상태, 상태전환 사이의 관계를 검증하는 테스팅 기법(모든 상태/이벤트 조합을 커버-both legal and illegal)
▪ 시스템/소프트웨어 상태기밥 행위가 명세된 내용과 일치함을 검증
▪ 상태기반 시스템의 결함은 상태, 상태전환, 가드, 이벤트 결함 등으로 분류
▪ 결함은 "구현이 잘못된 경우"와 "명세가 잘못된 경우"가 존재
▪ 테스팅 절차
   1. 상태-이벤트 테이블 구성
   2. 전환 트리 구성
   3. Legal 테스트 스크립트-테스트 케이스 구성
   4. Illegal 테스트 스크립트-테스트 케이스 구성
   5. 테스트 스크립트-가드 구성
▪ 모델상의 결함(Faults in model)
   -• 초기 상태 누락 
   -• 가드(guards)가 "전환" 대신 상태에 표기
   -• 가드의 중복
   -• ... 인스펙션, 정적 분석(도구)로 결함 발견
▪ 구현상의 결함(Faults in implementation)
   -• Extra/missing/corrupt state
   -• 액션이 틀리거나 누락
   -• 스니크 패스(Sneak paths); 트랩 도어(trap doors)..
   -• ... 테스트 만이 결함을 발견하는 방법
• 테스트 스크립트 가드 구성시
   - 가드가 경계값을 갖는 조건문으로 구성되어 있으면 "경계값 분석" 기법 적용
   - 가드가 복잡한 조건문으로 구성되어 있으면 "Modified condition/decision coverage" 기법 적용

4.4 Structure-based or white-box techniques (K3)

 

구조 기반 기법/화이트 박스 테스팅은 다음의 예제에서 보여지듯 시스템이나 소프트웨어의 정의된 구조에 기반한다.

 

• 컴포넌트 레벨 (Component Level) :

여기서의 구조는 코드 그 자체의 구조이다. i.e 문장(statements), 결정(decision), 분기(branches)

• 통합 레벨 (Integration Level) :

여기서의 구조는 호출 트리(Call tree)가 될 수 있다. (다른 모듈을 호출하는 모듈을 내부에 가진 다이어그램)

• 시스템 레벨 (System Level) :

 여기서의 구조는 메뉴 구조, 업무 프로세스 구조나 웹 페이지 구조가 될 수 있다.

 

이번 섹셕에서, 문장, 결정에 기반한, 두가지 코드와 관련된 구조적인 기법이 논의된다. 결정 테스팅(decision testing)에 대해서는, 컨트롤 플로우 다이어그램이 각각의 결정에 대한 선택사항을 가시화하기 위하여 사용될 수 있다.

 

4.4.1 문장 테스팅과 커버리지 (Statement testing and coverage)(K3)

 

컴포넌트 테스팅에서 문장 커버리지는 테스트 케이스 슈트(test case suite)에 의하여 동작된 실행 가능한 문장을 페센티지(%)로 평가한 것이다. 일반적으로 문장 커버리지를 증가시키기 위하여, 문장 테스팅은 특정 문장의 실행을 위한 테스트 케이스를 유도한다.

 

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

 

분기 테스팅과 관련된 결정 커버리지는 테스트 슈트에 의하여 실행된 결정 결과(e.g IF문에서의 true, false 옵션)들의 백분율(%)를 평가하는 것이다. 일반적으로 결정 커버리지를 증가시키기 위하여, 결정 테스팅은 특정 결정 결과를 실행하기 위한 테스트 케이스를 유도한다.

 

결정 테스팅은 결정 지점(decision point)을 통하여 특정 컨트롤 플로우를 생성시키는 컨트롤 플로우 테스팅(control flow testing)의 한 형식이다. 결정 커버리지는 문장 커버리지보다 강력하다.  100% 결정 커버리지는 100% 문장 커버리지를 보증하지만 반대는 그렇지 않다.

 

4.4.3 다른 구조 기반 기법들 (Other structure-based techniques)(K1)

 

조건 커버리지와 다중 조건 커버리지와  같은 결정 커버리지를 넘어서는 강력한 레벨의 구조적인 커버리지가 있다.

 

물론 커버리지 개념은 테스트 케이스 슈트(test case suite)에 의하여 실행된 모듈, 컴포넌트, 또는 클래스의 퍼센티지는 모듈 커버리지, 컴포넌트 커버리지, 클래스 커버리지로 표현될 수 있는 것처럼, 다른 테스트 레벨(e.g 통합 레벨)에도 적용 될 수 있다.

코드의 구조적인 테스팅에는 도구의 지원이 유용하다.

===============================================================================

 

정적 화이트 박스 테스트

 

정적 화이트 박스 테스트는 소프트웨어를 실행하지 않은 채 설계, 구조 또는 버그의 코드를 주의 깊고 조직적으로 검토하는 방법이다. 때로는 구조 분석이라 불리며, 정적 화이트 박스 테스트를 수행하는 이유는 조기에 버그를 발견하고, 나중에 수습하기 어려운 버그나 동적 블랙박스 테스트로는 발견하기 어려운 버그를 찾아내기 위해서이다. 소프트웨어를 검토하는 사람이 독립적일수록 이 방법이 효과적이며, 특히 개발 주기의 초기 단계에서의 개략적인 테스트에 효과적이다.

 

[공식적인 검토(Formal Reviews)]

 

공식적인 검토는 아래의 네가지 필수 요소가 있다.

 

▪ 문제 찾기    - 틀린 항목만이 아니라 누락된 항목도 포함되며 모든 비판은 코드 작성자가 아닌 코드 자체에 집중되어야 한다. 참가자들은 비난을 개인적으로 받아들여서는 안된다.
▪ 규칙 준수   -  규칙을 따라야 한다. 규칙은 검토해야 할 코드의 양, 소요시간, 회의 내용등을 결정

                      한다.
▪ 준비           - 각각의 참가자는 검토에 대하여 준비하고 도움을 주어야 한다.
▪ 보고서 작성 - 검토 작업의 결과를 요약하는 문서를 작성해야 하며 이 보고서를 제품 개발 팀의 나머지 구성원에 공개하여야 한다.

 

확립된 절차를 따라야 공식적인 검토의 효과를 볼 수 있다. 검토가 제대로 이루어진다면 이 작업이 초기에 버그를 발견하는 데 많은 도움이 된다는 것을 증명할 수 있다. 이외에 다음과 같은 간접적인 이점을 얻을 수 있다.

 

- 의사소통
- 품질
- 동료의식
- 솔루션

 

▪ Peer Reviews (동료들의 검토)
▪ Walkthroughs (워크스루)
▪ Inspection(인스펙션) - 가장 형식적인 과정으로 참가자에 대한 교육이 필요하다.

 

[코딩의 표준 및 지침]

 

표준이나 지침을 따라야 하는 이유는 다음과 같다.

 

1. 표준이나 지침에 따라 코드를 작성하는 것이 신뢰도가 더 높다.
2. 표준이나 지침을 따른 코드가 읽고 이해하기 쉬우며, 유지 관리가 쉽다.
3. 쉽고 간단하게 다른 플랫폼으로 코드를 이전할 수 있다.

 

[일반적인 코드 검토 점검표]

 

코드 검토 점검표는 표준이나 지침과 코드를 비교하고, 코드가 프로젝트의 설계 요구 사항을 충족하는지를 확읺는 것으로 다음의 사항이 포함된다.

 

▪ 데이터 참조 오류
▪ 데이터 선언 오류
▪ 계산 오류
▪ 비교 오류
▪ 제어 흐름 오류
▪ 서브루틴 파라미터 오류
▪ 입력/출력 오류
▪ 다른 검사 사항

 

동적 화이트 박스 테스팅

 

동적 화아트박스 테스트는 코드의 역할과 작동 방법을 관찰하여 얻은 정보를 사용하여 테스트 할 대상과 테스트에서 배재할 대상, 테스트 접근 방법등을 결정하는 것이다. 동적 화이트 박스는 구조적 테스팅이라고도 불리는데 이는 코드의 근본적인 구조를 관찰하고 이를 사용하여 테스트를 설계하고 수행하기 때문이다. 동적 화이트 박스 테스트는 코드의 역할을 살펴보는데 그치지 않는다. 이 테스트에서는 직접 테스트를 해보고 소프트웨어를 제어해 본다. 화이트 박스에 포함되는 네가지 영역은 다음과 같다.

 

1. 직접 기능, 프로시저, 서브루틴, 라이브러리를 테스트한다.
2. 최종 단계에서 완결된 프로그램의 형태로 소프트웨어를 테스트한다. 하지만 이때 소프트웨어의 동작에 대한 지식에 기초하여 테스트 사례를 조정한다.
3. 생각대로 테스트가 진행되고 있는지 살펴보기 위하여 소프트웨어에서 변수 및 상태 정보를 읽을 수 있도록 액세스 한다. 보통 테스트에서는 수행하기 어려운 동작을 소프트웨어에서 수행해 볼 수 있다.
4. 테스트 수행시 얼마나 많은 코드를 대상으로 하는지, 특히 어떤 코드를 대상으로 하게 되는지 측정한 다음 중복되는 테스트 사례를 제거하고 누락된 것을 추가하는 등 테스트를 조정한다.

 

[동적 화이트 박스 테스트 대 디버깅]

 

동적 화이트 박스 테스트의 목표는 버그 발견이다. 디버그의 목표는 버그의 수정이다. 하지만 버그가 발생하는 장소, 원인을 분리하려는 영역에서는 중복된다.

 

[데이터 영역(Data Coverage)]

 ▪ 데이터 흐름
 ▪ 하위 경계
 ▪ 공식과 방정식
 ▪ 오류만들기
 ▪ 오류 메시지 만들기

 

[코드 영역(Code Coverage)]

 

소프트웨어의 모든 모듈을 시작하고 종료하고, 코드의 모든 라인을 조사하고,모든 논리와 결정 경로를 조사해야 한다. 이렇게 세부적인 수준으로 소프트웨어를 조사하는 것은 코드 영역 분석이라 부른다. 코드 영역 분석에 액세스 하여 테스트 케이스를 실행할 때 소프트웨어의 어떤 부분을 통과하는지 봐야 한다는 점에서 동적 화이트 박스 테스트 기법이 된다. 코드 영역 분석의 가장 단순한 형태는 컴파일러의 디버거를 사용하여 프로그램에 접근할 때 방문하는 코드의 라인을 살펴보는 것이다.

▪ 프로그램 문장 및 라인 영역 (Program Statement and Line Coverage)
▪ 분기 영역 (Branch Coverage)
▪ 조건 영역(Condition Coverage)

 

- Statement Coverage  :

   프로그램내의 모든 명령문을 적어도 한번 수행하도록 테스트 케이스를 산출

- Decision Coverage  :

   프로그램 내의 결정 명령문이 적어도 한번은 "true"와 "false"의 결과가 되도록 테스트 케이스를 산출
- Condition Coverage :

   결정 명령문 내의 각 조건이 적어도 한번은 "true"와 "false"의 결과가 되도록 테스트 케이스를 산출한다.
- Decision/Condition Coverage :

   결정 명령문 및 명령문내의 각 조건이 적어도 한번은 "true"과 "false"을 취하고 모든 명령문이 적어도 한번은 수행하도록 테스트 케이스 산출
- All Path Coverage  :

  모든 경로를 적어도 한번 수행하도록 테스트 케이스 산출

 

4.5 Experience-based technique (K2)

 

아마도 가장 널리 쓰이는 테스팅 기법은 에러를 추정하는 것일 것이다. 테스트는 테스터(tester)의 기술(skill)과 직관 그리고 유사한 시스템(similar system)과 기술에 대한 경험으로 부터 유도된다.  체계적인 기법을 확대하여 사용할 때, 직관적인 테스팅은 매우 형식적인 방법을 적용한 후에 정형적인 기법으로 쉽게 찾을 수 없는 특별한 테스트들을 정의하는데 유용할 수 있다. 하지만 이 기법은 테스터의 경험에 의존하기 때문에 효용성의 정도는 다양할 수 있다. 에러를 추정하는 기법에 대한 구조적인 접근 방식은 가능한 에러의 리스트를 열거하고 이러한 에러들을 찾아내는 테스트들을 설계하는 것일 것이다. 이러한 결점과 실패 리스트는 경험, 이용가능한 결함(defect)과 실패(failure)의 자료, 그리고 소프트웨어가 왜 실패하는가에 대한 일반적인 지식에 기반하여 만들 수 있다.

 

탐색적인 테스팅(Exploratory testing)은  테스트 설계(test design), 테스트 실행, 테스트 로깅과 지식의 습득을 동반하며, 테스트 목표들을 포함하는 테스트 문서에 기반하고, 타임 박스 안에서 수행된다. 이러한 접근 방식은 소량이거나 불충분한 명세와 심각한 시간의 압박이 있는 경우, 또는 매우 형식적인 테스팅을 확대하거나 보층할 때 유용하다. 이 기법은 대부분의 심각한 결함이 발견되었다는 것을 확인 할 수 있는 테스트 프로세스 점검용으로도 사용될 수 있다.

===============================================================================

 

경험기반 기법

 

▪ 유사 SW나 기술에의 경험을 바탕으로 직감적으로 테스트하는 기법
▪ Formal 기법과 같이 사용
▪ Formal 기법이 찾기 어려운 결함 발견 기나능
    - 테스트의 경험에 따라 효과가 다르기 때문에 리관성이 떨어지면 관리가 어렵다.

 

▪ 탐색적 테스팅 (Exploratory Testing)
   ◦ 테스트 목표를 포함하는 테스트 차터(charter)를 기반으로 정해진 시간내에 테스트 설계, 수행, 기록과 학습하는 테스팅 기법
   ◦ 명세가 거의 없고 시간이 부족한 경우
   ◦ Formal 기법을 보충할 경우
   ◦ 가장 심각한 결함을 모두 발견했다는 것을 확인하는 목적으로 사용하는 경우 적합

▪ Error guessing
   ◦ 가능한 결함을 리스트업하고 이를 발견하기 위한 테스트케이스 작성
   ◦ 가능한 결함(에러, 오류)은 상식, 기존 경험과 기존 데이터를 통해 도출가능

▪ 일반적인 경험과 노하우의 반영믈 - 체크리스트
   ◦ 문서 기반의 테스트 케이스를 작성시에도 체크리스트의 경험과 노하우를 반영하는 노력 요구

 

◆ Classification Tree Method

▪ 블랙 박스 기반
▪ 명세가 없는 경우
▪ 비공식적 - 비공식적이라고 나쁜 기법이 아니다.
▪ 테스트 아이디어 시각화
▪ 복잡성 처리 - 중복성을 피하고 한가지 기능만 테스트 하는 경우 회피 가능
▪ 개발 설계 체크
▪ 테스트 비용 측정 가능

 

◆ 통계적 사용기반 기법

▪ 어떤 상황에서 어떤 동작이 수행될 가능성이 높은가?
▪ 상태와 이벤트 조합 확률에 의존 (Operational profiles)
▪ 다수의 테스트 케이스 ; Operational profiles에 비례
▪ Rare Event Testing은 확률이 낮은 이벤트에 집중

 

그레이 박스 테스팅

 

그레이 박스 테스팅은 블랙박스 테스트와 화이트 박스 테스트의 혼합한 형태로, 두 가지 테스트 형태의 경계에 존재한다. 여기서는 소프트웨어를 블랙 박스 형태로 테스트하며, 화이트 박스와 같이 상세하지는 않지만 소프트웨어의 작동 원리에 대해 알아보는

 

4.6 Choosing test techniques (K2)

 

사용하기 위한 테스트 기법의 선정은 시스템 타입, 표준의 준수, 고객 또는 계약 요구사항, 위험 레벨, 테스트 목적, 문서화 가능여부, 테스터의 지식, 시간과 예산, 개발 주기, 유스케이스 모델과 발견된 결함 타입에 대한 이전 경험을 포함하는 인자(factor)의 수에 의존한다.  

 

===============================================================================

 

◆ 테스트 기법 선정 기준

 

◦ 시스템 타입
◦ 법적 기준
◦ 고객 또는 계약 요구사항
◦ 위험 수준 및 위험 타입
◦ 테스트 목표
◦ 문서 존재 유무
◦ 테스트 레벨
◦ 테스터의 지식 수준
◦ 시간과 예산
◦ 개발 생명 주기
◦ 유스케이스 모델
◦ 발견된 결함 타입에 대한 기존 경험