[CSTS] PART 02. 테스트 설계기법

8장 정적 테스트

리뷰

• 여러 전문가가 모여 프로그램을 검토하여 결함을 검출하는 방법
• 관리 리뷰, 기술 리뷰, 인스펙션, 워크쓰루, 감사

리뷰를 성공시키기 위해 필요한 요소

• 리뷰 참석자는 리뷰 기법에 대한 교육 훈련이 제공되어야 하며, 주재자는 별도의 교육을 필수로 이수해야 함
• 소프트웨어 개발 산출물과 검토자의 수준 등을 고려하여 리뷰 기법을 적절히 적용
• 결함의 발견에 부정적이지 않으며, 발견된 결함은 객관적으로 표현되어야 함
• 효과적이고 효율적인 결함 발견을 위해 필요 시 체크리스트를 활용할 수 있음

 

8.2 리뷰 프로세스

1. 경영진 준비
2. 리뷰 계획
3. 리뷰 절차 개요 설명
4. 작업물 개요 설명
5. 개별 준비
6. 그룹 검토
7. 재작업
8. 후속작업

 

8.3 관리 리뷰

• 진행 상황을 모니터하고 계획과 현재 일정 상태를 평가하여 필요하다면 자원, 일정이나 프로젝트 범위 등을 변경하는 것
• 관리 리뷰 후에는 해당 계획이 적절히 변경되었는지 확인할 필요가 있음

 

8.4 기술 리뷰

• 프로젝트의 기술적 상태를 확인하는 증거로 관리자에게 제공
• 의도된 사용에 적합한지 평가
• 계획, 법규, 표준이나 명세를 충실히 지키는지 평가
• 변경 사항이 적절하게 구현되었는지 평가하고 변경 명세에 식별된 영역에만 해당 변경이 영향을 미치는지 평가
• 여러 대안을 추천하거나 대안들을 검토
• 대표 엔지니어가 주재하며 경우에 따라 관리자도 참여할 수 있음

 

8.5 인스펙션

• 가장 형식화된 대표적인 리뷰 방식
• 가능한 한 개발 초기에 검사해야만 개발 초기 작업물에서 문제를 찾아낼 수 있음
• 결과적으로 품질에 투입되는 비용이 감소하며 개발 기간이 단축됨
• 코딩 전까지는 일반적으로 개발보다 소요 인력이 더 많이 필요할 수 있음
• 초기 프로젝트 비용이 증가하지만, 개발 단계의 재작업과 투입 인력이 감소
• 참가자의 역할이 명확, 체크리스트 사용
• 인스펙션 참가자 역할
  • 주재자 : 공식 검토를 계획하고 공식 검토 회의를 운영하며, 회의 종료 후 사후 관리
  • 작성자 : 검토 대상 산출물 작성자로서 문서에 대한 책임이 있으며, 검토 시 해당 산출물에 관해 설명
  • 낭독자 : 산출물에 대한 자신의 이해 및 해석을 바탕으로 작업물에 대해 회의 참가자들에게 설명하며 인스펙션 회의를 이끄는 역할
  • 기록자 : 회의 내용을 기록하고 모든 이슈 상황, 결함, 정의되어야 할 문제점 등을 문서화
  • 검토자 : 산출물을 충분히 검토하고 인스펙션 회의를 준비, 주어진 자료에서 결함을 찾아내고 기록, 결함에 대해 의견 제시
• 인스펙션 과정
  1. 리뷰 계획
  2. 인스펙션 절차 개요 설명
  3. 인스펙션 작업물에 대한 개요 설명
  4. 준비
  5. 검토 회의
  6. 재작업
  7. 후속작업

 

8.6 워크쓰루

• 인스펙션보다는 비형식적인 결함 검출 방법
• 결함을 검출할 뿐만 아니라 참가자들의 교육이나 지식 공유를 위해 수행되기도 함
• 보통은 개발자에 의해 회의가 진행
• 회의를 주재하기 위해 별도의 훈련을 필요로 하지 않음
• 회의의 결과가 잘 처리되었는지 확인하는 작업을 생략할 수 있음
• 관리자 직책 담당하는 사람은 팀 멤버로 참여 금지

 

8.7 감사

• 소프트웨어 제품 및 프로세스가 규제, 표준, 가이드라인, 계획, 절차를 준수하고 있는지를 독립적으로 평가하는 것으로 규정
• 감사는 소프트웨어 제품의 제공자, 소비자, 또는 제 3기관에서 필요에 따라 요구될 수 있음

 

8.8 정적 분석

정적 분석 : 도구의 지원을 받아 정적 테스트를 수행하는 것

코딩 표준(코딩 지침) : 개발자가 프로그램을 작성할 때 지켜야 하는 규약

코딩 스타일

BSD	K&R	GNU
if (...) {           doSomething(); }	if (...) {        doSomething(); }	if (...)       {                    doSomething();       }
블록을 if문 아래 작성하고 들여쓰기를 하지만 중괄호는 들여쓰기 X	블록의 여는 중괄호를 if와 같은 행에 배치	블록을 if문 아래에 작성하고 들여쓰기

 

복잡도 분석 : 복잡도를 통제하여 필요 이상으로 복잡도가 높지 않도록 함, 복잡도가 높은 프로그램은 신뢰성, 테스트 비용, 유지보수성 측면에서 좋지 않은 결과를 가져옴

순환 복잡도 : 프로그램을 이해하고 테스트 및 유지보수가 얼마나 어려운지를 판별하는 기준

• 순환 복잡도 = E(간선 개수) - N(노드 개수) + 2
• 순환 복잡도 = 닫힌 영역의 개수 + 1
• 순환 복잡도 = 분기 노드들의 개수 + 1

자료 흐름 분석

• 프로그램의 자료 흐름에 이상이 있는지 분석
• 자료 흐름이상의 발생은 프로그램이 올바르게 수행되는 것을 방해하는 원인이 됨

자료 흐름 쓰임새 패턴

패턴		설명
~d	처음 정의됨	문제없음
du	define-use	문제없음. 정상적인 경우
dk	define-kill	잠재적 결함. 전혀 자료가 사용되지 않음
~u	처음 사용됨	잠재적 결함. 자료가 정의되지 않고 바로 사용됨
ud	use-define	문제없음. 자료가 사용된 후 다시 정의됨
uk	Use-kill	문제없음
~k	처음으로 무효화	잠재적 결함. 자료가 정의되지 않고 바로 무효화됨
ku	kill-use	심각한 결함. 무효화되었는데 사용
kd	kill-define	문제없음. 무효화된 후에 다시 정의가 됨
dd	define-define	잠재적 결함. 두 번 연이어 정의됨
uu	use-use	문제없음. 정상적인 경우
kk	kill-kill	잠재적 결함
d~	제일 나중에 발생한 정의	잠재적 결함
u~	제일 나중에 발생한 참조	문제없음
k~	제일 나중에 발생한 무효화	문제없음. 정상적인 경우

• d : defined
• k : killed
• u : used
• ~x : 모든 선행 행위가 x와 관련이 없다는 사실을 나타냄 
• x~ : x이후에 행위들이 xd와는 관련이 없다는 사실을 나타냄

 

---

 

9장 구조 기반 테스트

구조 기반 테스트

• 프로그램 제어 흐름이나 자료 흐름 정보를 이용하여 테스트 케이스를 설계하는 방법
• 프로그램의 내부 구조 정보를 기반으로 테스트 케이스 설계

 

9.4 문장 테스트

• 프로그램의 모든(실행 가능한) 문장을 최소한 한 번은 행하도록 요구

 

9.5 결정 테스트

• 프로그램상 나타난 모든 결정문의 결과가 참과 거짓이 되는 경우를 최소한 한 번은 실행하도록 요구

• 문장 < 결정

 

9.6 조건 테스트

• 프로그램의 조건에 나타난 모든 조건이 true, false가 되는 경우 모두를 발생하게 하는 입력 테스트 집합으로 사용할 것을 요구

 

9.7 결정/조건 테스트

• 결정 테스트 + 조건 테스트 모두 만족하는 테스트 케이스 집합을 설계하도록 요구

 

9.8 다중 조건 테스트

• 프로그램의 결정들에 사용된 모든 조건의 조합을 테스트 할 수 있는 입력 데이터들을 테스트 데이터 집합으로 선정

 

9.9 변형된 조건/결정 테스트

• 조건 테스트 + 결정 테스트 + 결정을 구성하는 각 조건이 독립적으로 결정의 결과에 영향을 미쳐야 함

 

* 심볼릭 실행

• 프로그램을 추상적으로 실행하는 방법
• 프로그램이 비슷한 입력에 대해 추상적으로 실행되는 방식을 고려, 테스팅을 일반화
• 프로그램 테스트 데이터 자동 생성, 실행 불가능한 경로 검출, 주어진 경로가 실행 가능한지 검사

 

---

 

10장 명세 기반 테스트

명세 기반 테스트(블랙박스 테스트)

• 프로그램의 내부 논리 구조를 참조하지 않고 사용자의 요구사항이 기술된 명세나 설계 정보 등을 이용하여 테스트 케이스 개발
• 적용 대상에 제한이 없으며 테스트 전 과정(컴포넌트, 통합, 시스템, 인수 테스트)에 걸쳐 사용될 수 있음
• 명세를 바탕으로 테스트 케이스를 설계하므로 규모가 큰 단위에도 효과적으로 적용
• 테스터가 구현에 관한 지식 없이도 테스트 수행 가능, 사용자 관점에서 테스트 수행 하므로 효과적으로 결함 검출 기회 제공
• 누락 결함을 검출할 가능성을 높여줌
• 테스트 대상이 상태 의존적인 동작을 가지는 경우 : 시나리오 테스팅, 상태 전이 테스팅이 적합

 

10.2 동등 분할

동등 분할

• 테스트를 효과적으로 수행하면서도 테스트 케이스의 개수를 줄이는 방법
• 프로그램 입력이나 출력 영역을 동등 클래스라 불리는 몇 개 영역으로 분할하여 각 클래스에서 하나의 값을 선택하여 테스트 케이스로 이용
• 유효 입력 및 출력 뿐만 아니라 유효하지 않은 입력 및 출력까지도 고려해야 함

동등 분할 클래스 조합 방법

• One-to-One 동등 분할
  • 분할한 클래스들과 테스트 케이스 간 일 대 일 관계
  • 유효하지 않은 케이스를 설계하는 경우에는 한 번에 하나의 필드만 유효하지 않은 입력으로 구성해야 함(어떤 필드가 문제가 되었는지 알 수 없기 때문)
• 최소화 동등 분할
  • 하나의 테스트 케이스에 여러 개의 클래스가 포함되도록 함

➡️ 유효하지 못한 테스트 케이스는 One-to-One 방식으로 설계하고, 유효한 테스트 케이스는 최소화 동등 분할 방식을 이용하여 테스트 케이스를 설계하는 것도 고려할만 함

 

10.3 분류 트리 기법

분류 트리 기법

• 테스트 대상 프로그램 행위에 영향을 줄 수 있는 특성들을 도메인 지식, 경험이나 프로그램의 명세 등을 이용하여 식별

분류 트리

• 루트 노드 : 테스트 대상 프로그램의 입력, 출력 등을 포함한 전체 영역
• 말단 노드 : 테스트 케이스를 구성하는 클래스 또는 값을 표현, 동등 분할 테스트 영역에서 분할된 개개의 클래스에 해당함

 

10.4 경계값 분석

경계값 분석

• 입력 영역 경계 근처에 있는 값들을 이용하여 테스트 케이스를 설계하는 테스트 방법
• 클래스의 경계와 경계 근처에 있는 값들을 사용하여 테스트 케이스를 설계
• 경계값 부근에 있는 것을 테스트로 사용하여 결함 발견 효용성을 높여줌

 

10.5 조합 테스트

조합 테스트

• 테스트 대상 프로그램 내 여러 클래스의 각 입력 인자를 여러 클래스 또는 값으로 분할하였을 때 이들을 조합하여 테스트 케이스를 구성하는 방식

조합 테스트 방법

• Each choice 테스트
  • 최소한 하나의 입력값이 테스트 케이스에 포함되도록 함
  • 테스트 케이스를 줄일 수는 있지만, 입력 인자들의 상호 작용에 따른 결함이 발생하는 경우는 테스트하지 않음
• 페어와이즈 테스트
  • 각 인자의 값(또는 클래스)과 다른 인자 값(또는 클래스)을 최소한 한 번은 조합을 하여 테스트하는 방법
  • All combinations 테스트에 비해 테스트 케이스의 수를 줄이면서 Each choice 테스트로 검출하지 못한 결함을 검출할 수 있음
• All combinations 테스트
  • 모든 입력 인자의 모든 가능한 클래스 조합이 테스트 케이스들에 포함되도록 하는 것
  • 입력 인자가 늘어날수록 테스트 케이스가 기하급수적으로 증가함
• Base choice 테스트 : 기반이 되는 테스트 조합을 미리 선정, 사용자의 관점에서 선택될 빈도가 가장 높고, 일반적으로 정상 동작 할 수 있는 것을 선정하고 선정된 기반 테스트에서 하나의 인자만 변경을 주며 나머지는 기반 테스트의 값으로 고정하여 테스트 케이스 생성

 

10.6 결정표 테스트

결정표 테스트

• 결정표를 이용하여 테스트 케이스를 설계하는 테스트 방법
• 조건을 기술하는 부분과 조건의 조합에 대해 취하는 행위를 기술하는 부분으로 구성

결정 테이블

• 입력 조건의 모든 조합에 대한 시스템의 행동을 고려하여 테스트 케이스를 도출하는 기법
• 복잡한 논리적 관계를 표현하기에 좋은 기법
• 누락된 요구사항이 있는지 검사하는데 좋은 기법

 

10.7 상태 전이 테스트

상태 전이 테스트

• 시스템을 상태 전이도로 모델링한 후 테스트 케이스들을 상태 전이도에서 체계적으로 선정하는 방법
• 시스템 외부에서 들어오는 일련의 이벤트들에 대해 시스템 상태가 어떻게 전이되고 어떤 식으로 반응하는가를 나타내기 좋은 명세 수단

상태 전이 테스트 방식

• 상태 테스트 : 상태 전이도의 모든 상태를 최소한 한 번 방문하는 테스트 케이스들를 설계
• 단일 전이 테스트(0-switch 테스트) : 상태 전이도의 모든 유효한 전이들을 최소한 한 번 방문하는 테스트 케이스들을 설계
• All transitions 테스트 :  유효한 전이를 포함하여 유효하지 않은 전이들도 최소한 한 번 방문하는 테스트 케이스들을 설계
• 다중 전이 테스트(N-switch 테스트) : 상태 전이도에 있는 N+1개의 전이 시퀀스들을 최소한 한 번 방문하는 테스트 케이스들을 설계

 

10.8 시나리오 테스트

시나리오 테스트

• 기존의 요구사항 명세서에 각 개별 기능에 대한 상세한 내용이 시나리오 형태로 기술되어 있다면 이를 이요해 기능테스트를 수행할 수 있음
• 시나리오에 기반한 테스트 수행을 위해서는 요구사항에 기록된 기능의 동작 흐름을 분석하여 테스트 시나리오를 결정해야 함
• 결정된 테스트 시나리오를 기반으로 테스트를 수행하여 시스템이 요구사항에서 요구된 대로 동작하는지 확인
• 테스트 시나리오는 초기에 정의된 요구사항 시나리오를 바탕으로 보완되거나 확장되는 것이 일반적
• 기본 시나리오 : 정상적인 시나리오 / 대안 시나리오 : 그 외의 각 상황

 

 

---

 

📚 참고 문헌 : 소프트웨어 테스트 전문가(CSTS) 가이드