소프트웨어 테스트 실무 가이드 -테스트 케이스 설계 방법/탐색적 테스팅

 

소프트웨어 테스트 실무 가이드 국내도서 저자 : NIPA(정보통신산업진흥원),STA테스팅컨설팅 출판 : STA테스팅컨설팅 2012.09.14 상세보기

01. 요약정리

 

◎ 테스트 케이스 : 테스트 케이스는 테스트를 실행하는 수단이며 테스트 항목이다. 테스트 케이스는 요구 명세, 아키텍처 및 설계 문서, 기능 목록 등 다양한 개발 산출물로부터 도출, 발견된 결함을 참고해 경험적으로도 도출할 수 있다. 

◎ 테스트 설계 : 테스트 설계는 테스트 케이스와 테스트 데이터 등을 구상하고 이를 구체적으로 명세화하는 활동이다. 

◎ 가드 : 가드는 이벤트가 발생했을 때 상태가 전이되는 조건을 의미한다. 가드에 따라 전이되는 상태가 달라지므로 이를 테스트하기 위해 가드 테스트 케이스를 작성한다. 

◎ 동등 분할 : 동등 분할 기법은 입력과 출력 값의 영역을 유한 개의 상호 독립적인 집합으로 구분한 후, 각 집합의 원소 중 대표값을 선택해 테스트 작성한다. 동등 분할 클래스는 유효한 입력은 물론 유효하지 않은 입력도 포함할 수 있다. 

◎ 결정 테이블 : 결정 테이블은 요구사항을 논리적인 조건이나 상황으로 정리하거나 시스템 설계 또는 시스템이 구현해야 할 비즈니스 규칙을 문서화하는데 매우 유용하다. 

◎ 페어와이즈 : 조합 테스팅 기법 중 페어와이즈는 소프트웨어 결함 대부분이 두 요소의 상호작용에 기인한다는 것에 착안해 두 요소의 모든 조합을 테스트 케이스로 도출하는 기법이다. 즉 페어와이즈 조합은 테스트 입력값들이 다른 입력값과 최소한 한번씩은 조합을 이룬다는 의미다.

◎ 테스트 케이스는 테스트를 실행하는 수단이며 테스트 항목이다. 테스트 케이스는 요구 명세, 아키텍쳐 및 설계 문서, 기능 목록 등 다양한 개발 산출물로부터 도출, 발전된 결함을 참고해 경험적으로도 도출할 수 있다. 개발 산출물로부터 테스트 케이스를 도출할 경우에는 이미 입증된 테스트 설계 기법을 활용하면 더 체계적으로 테스트 케이스를 도출할 수 있다. 테스트 케이스는 설계 활동의 최종 산출물이다. 

◎ 테스트 설계는 테스트 케이스와 테스트 데이터 등을 구상하고 이를 구체적으로 명세화하는 활동이다. 테스트 설계 목적은 아래와 같다.

- 결함을 발견할 수 있는 효과적인 테스트 케이스 작성

- 적은 테스트 케이스로 원하는 테스트 커버리지 달성

체계적으로 테스트를 설계하고 테스트 케이스를 만들어 테스트 한다면 테스트 대상을 어느 수준까지 테스트했는지 파악할 수 있다. 

◎ 개발 과정에서 체계적이고 정형화된 산출물을 작성하며 잘 갖춰진 테스트 조직과 내재화된 테스트 프로세스가 있는 조직이 하면 대체로 테스트 설계를 공식적으로 진행할 수 있다. 반면 개발 관련 산출물의 완성도가 낮고 개발 일정과 인력이 부족하다면 테스트 설계를 체계적으로 진행하기 어려울 것이다. 즉 조직의 개발 및 테스트 성숙도 수준, 일정과 지원 확보 여부 등에 따라 테스트 설계 방법과 완성도는 달라진다. 

◎ 명세 기반 기법은 명세를 바탕으로 '명세대로 동작하지 않음'을 증명하기 위해 테스트 케이스를 도출한다. 다음은 명세 기반 테스트 주요 기법들이다.

- 동등 분할

- 경곗값 분석

- 결정 테이블 테스팅

- 상태 전이 테스팅

- 조합 테스팅

◎ 구조 기반 테스팅은 소프트웨어나 시스템의 구조를 중심으로 테스트 케이스를 도출한다. 프로그램이나 시스템의 구조를 중심으로 테스트하므로 테스트의 충분함을 정량적으로 표시할 수 있는 커버리지를 산출할 수 있다.  구조 기반 테스트는 주로 단위 테스트 단계에서 코드의 구조를 테스트하지만 통합 테스팅, 시스템 테스팅 단계 등에서도 테스트 대상에 따라 다양하게 수행할 수 있다.

◎ 일반적으로 코드레벨의 테스트는 특정 구조의 커버리지를 달성하기 위해 테스트를 설계하고 테스트 케이스를 작성한다. 예를 들어 결정 커버리지 100%가 목표라면 코드 내 모든 결정문을 분석한 후 모든 분기를 커버할 수 있도록 테스트 케이스를 만들어 테스트한다. 

그리고 일부 코드 커버리지는 상호 간 포함관계를 가진다. 예를 들어 결정 커버리지를 100% 달성한 테스트 케이스는 구분 커버리지도 100% 보장한다. 커버리지는 다양한 종류가 있으면 그 강도와 보장 범위가 다르다. 보장성과 테스트 강도가 높은 커버리지를 리스크가 높은 시스템과 기능 테스트에 적용한다면 완성도 높은 테스트를 할 수 있다.  

◎ 제어흐름 테스트는 일반적으로 코드의 제어 흐름도를 이용해 테스트를 설계하는 구조 기반 테스트 설계 기법이다. 그러나 코드 외에도 순서도나 업무흐름도, 호출 그래프 등과 같이 구조를 나타내는 명세들을 이용해 제어흐름 테스트를 할 수 있다. 

◎ 경험 기반 테스트 기법은 이전에 테스터가 다뤘던 유사 어플리케이션이나 기술에서 경험, 직관, 테스터의 기술 능력으로부터 테스트 케이스를 추출해내는 기법이다. 공식적인 기법으로 다루기 어려운 특별한 테스트 케이스를 찾아내고 실행하는데 유용하다. 공식적인 테스트 기법과 경험 기반 테스트 기법으로 구현된 테스트 케이스는 찾아낼 수 있는 결함의 종류가 다르기 때문에 경험기반 테스트 기법이 의미를 갖는다. 그러나 이 기법은 테스터의 경험에 따라 효율성 및 효과성의 정도가 매우 달라질 수 있다. 

◎ 탐색적 테스팅은 테스트 실행을 강조한다. 테스트를 실행하고 결과를 통해 제품을 파악한 후 테스트를 설계하고 필요하면 계획을 세우거나 수정 후 다시 테스트를 실행한다. 이러한 과정을 반복한다. 제품 정보가 부족한 상태에서 테스트를 해야 한다면 탐색적 테스팅은 아주 효과적인 접근법이다. 물론 이미 잘 알고 있는 제품인 경우에도 테스터의 지적 능력과 경험을 적극 활용해 더욱 효과적인 테스트를 할 수 있다. 

 

02. 테스트 설계 기법의 종류로 옳지 않은 것은 무엇인가?

    명세 기반

2)    사례 기반

   구조 기반

   경험 기반

 

 

 

---

 

 

 

 

03. 다음 괄호에 공통으로 들어갈 말은 무엇인가?

 (       )는 이벤트가 발생했을 때 상태가 전이되는 '조건'을 의미한다. (       )에 따라 전이되는 상태가 달라지므로 이를 테스트 하기 위해 (        ) 테스트 케이스를 작성한다.

1)    가드

   유효

   요구

   스위치