소프트웨어 테스팅 기법 (2) - 정적 테스팅의 종류

S/W 테스팅 기법 2

정적 테스팅	동적 테스팅
	블랙 박스 테스팅 (명세 기반)	화이트 박스 테스팅 (구조 기반)
- Inspection  - Orthogonal Array Testing - Prior Defect History Testing - Risk-Based Testing  - Run Chart - Statistical Profile Testing	- Boundary Value Testing  - Cause-Effect Graphing - Control Flow Testing  - CRUD Testing - Decision Tables Testing - Equivalence Class Partitioning  - Exception Testing  - Finite State Testing  - Free Form Testing - Positive and negative Testing  - Prototyping  - Random Testing - Range Testing   - Regression Testing - State Transition Testing - Thread Testing	- Basis Path Testing - Branch Coverage Testing - Condition Coverage Testing - Data Flow Testing - Loop Testing - Mutation Testing - Sandwich Testing - Statement Coverage Testing

정적 테스팅의 종류

1. 익스펙션 (Inspection)

가장 일반적으로 사용되는 동료검토 형식으로, 오류 탐지를 위하여 체 크리스트(checklist)를 사용하는 것이다. 체크리스트는 어떠한 오류 타입이 과거에 비해 더 혹 은 덜 빈번하게 발생하는지를 통계량으로 나타내주며, 일반적으로 inspection은 제품 설계와 코딩 단계에서 많이 수행된다.

50~100라인 정도의 명세나 설계의 inspection은 15분에서 한 시간 정도의 시간이 소요되며, 복잡한 컴포넌트는 2시간 이상이 소요되므로 이러한 경우 덜 효율적이기 때문에 inspection으로 검토하는 것은 피해야 한다. 

일반적으로 inspection은 생명 주기에서 다음 단계의 해당 참가자, 즉 리더(reader)에 의해 수 행되고 inspection의 참가자들은 검토할 대상에 대해 미리 조사해야 한다. 예를 들어, 요구사 항 분석에 대한 검토는 설계자에 의해 이루어지고, 설계 단계에 대한 검토는 구현자에 의해 이루어지며, 예외적으로 코드 검토는 설계자에 의해 이루어진다. 

리더는 표준을 왜곡하는 등 의 일반적인 오류 타입을 식별하기 위한 체크리스트를 사용하여, 제품 컴포넌트를 검토한다.

Inspection의 마지막 단계에서는 그룹에 의해 수용되거나 거부된 결정이 제시되며, 코디네이 터(coordinator)는 발견된 오류와 문제점을 요약하여 모든 참가자들에게 리스트 형태로 제공 한다. 

또한 inspection을 수행했던 참가자(설계자, 구현자, 테스터)는 이 리스트를 토대로 제 품에 대한 리비전(revision)을 코디네이터에게 제출하고, 코디네이터는 리비전 요약 보고서를 작성하며, 이 요약 보고서는 다음 inspection을 위한 체크리스트를 갱신하는데 사용된다. 

효율적인 inspection 체크리스트를 생성하기 위해 다음이 제안된다.

1. 체크리스트는 결함 분석에 기초해서 정규적으로 갱신되어야 한다. 

: 정규적으로 갱신됨으로써, 검토자는 체크리스트를 쉽게 읽고 사용할 수 있을 것이다. 

2. 체크리스트는 한 페이지보다 길지 않아야 한다. 

: 한 페이지 분량의 체크리스트는 책상에 놓여 져 프로덕트를 검토하는 동안 근접한 곳에서 읽혀질 수 있다. 

3. 체크리스트 아이템은 질문의 형태로 표현되어야 한다.

: 예) 각 변수는 처음 사용되기 전에 적절하게 초기화되었는가?

 그 이유는 모든 질문 형태의 체크리스트 아이템은 명령문으로 재표현될 수 있기 때문이다 (예로, 각 변수가 처음 사용되기 전에 적절히 초기화된 것을 확인하라).

4. 체크리스트 아이템은 너무 일반적이지 않아야 한다. (예로, 모든 요구사항이 완전하고 일관성 있고 명백한가?)

2. 직교배열 테스팅 (Orthogonal Array Testing) 

잠재적으로 조합 요소의 거대한 양을 처리하기 위한 테스트 케이스를 선정하는데 도움을 주는 통계적 테스팅 기법이다. 요구되는 테스트 케이스의 이상 적인 개수를 계산하고 입력값과 조건의 차를 식별하여 테스트 케이스 선정 프로세스에서 최 대 커버리지를 가지는 최소 개수의 테스트 케이스를 제공하는데 도움을 준다. 

Orthogonal array testing은 모든 선택된 변수의 pair-wise combination을 테스팅 하는 것을 보장 함으로써, 모든 변수의 모든 조합을 테스팅 하는 것보다 적은 수의 테스트 케이스로 효율적 이고 간결한 테스팅을 수행할 수 있게 해준다. 

3. 사전결함 이력테스트 (Prior Defect History Testing)

시스템에서 이전에 행하였던 모든 defect에 대한 테스트케이스가 다시 만들어져야 하며, 이에 대해 다시 테스팅을 수행하여야 한다. defect가 밀 집되어 있고, 기존에 발생했던 문제점이 또다시 나타나기 쉬운 경향을 가진다는 점에 착안 하여 고안되었다. 

이 기법은 defect matrix를 이용하는 것이 효율적인데, 이전 단계에서 해당 테스트케이스를 수행하는 동안 defect가 발견 되었으므로 다시 테스트 되어야 한다는 표시를 이 matrix안의 check entry에 표시함으로써 이를 이용하게 되며, Prior defect history testing에서 많은 수의 defect가 발견될 경우, 어떠한 단계에서의 defect는 이에 대한 테스트를 반복적으로 수행해야 하므로 경제적이지 않다.

리스크 기반 테스트 (Risk-Based Testing)

테스트 대상에 비해서 테스트 자원이 부족한 경우, 우선순위를 나눠서 테스트 자원을 효율적으로 분배하기 위한 전략으로 리스크를 정의하고, 정의된 리스크를 분석하고, 분석된 리스크에 대하여 회피 전략을 세우고, 전략에 따라 테스트를 수행하는 과정을 통하여 리스크 기반 테스팅을 할 수 있다. 

(RBT에서 리스크는 "리스크 발생 가능성" × "발생했을 때 영향력"으로 정의한다.)

risk에 기반 한 테스트를 수행함으로써 합리성을 갖고 가장 심각 한 결과를 초래할 수 있는 시스템의 일부를 선택할 수 있게 되어 risk에 주의를 집중시킬 수 있게 된다. Risk-based testing은 높은 risk를 가지는 어플리케이션을 식별해낸 후, risk분석을 통 해 해당 어플리케이션에서 에러가 발생하기 쉬운 컴포넌트를 식별하여, 식별한 컴포넌트에 만 테스트를 집중시킨다. 

이 때 잘못된 risk분석을 하게 되면, 우연적으로나 필연적으로 시스 템의 취약성을 증가시키게 되므로, 보다 엄격한 취약성 분석과 취약성 분석을 기반으로 한 테스팅이 요구된다.

런 차트 (Run Chart)

시간을 가지는 품질 특성에 대한 다양성을 그래프로 표현하는 것이다. Run chart는 변화 기록과 패턴을 보여주고, 변화가 영구적인 개선을 가져왔는지를 보기 위한 변화 프로세스의 마지막 부분에서 사용되기도 한다.  

통계 프로파일 테스트 (Statistical Profile Testing)

시스템 profile의 사용 빈도에 기반 하여 자동적으로 테스트 세트를 생성해 주는 기법으로 같은 항목을 여러 번 수행하는 기존의 테스팅 기법의 약점을 보 완하는 하나의 방안이 될 수 있다.