CH2. 테스트 설계 방법 및 관리

■ 테스트 설계 방법

■ 소프트웨어 테스트 케이스 개발 기법

• SW Testing 설계기법 선택 시 고려사항 및 팁

  →회사에서 요구사항 명세서와 설계문서를 기반으로 TC를 작성하고 있지 않다면 다른 설계 기법은 일단 다음에 고려하는 것이 정상
  →기본적으로 명세기반기법에 의해 요구사항 대비 TC를 90%이상 도출하고 있다면 도구를 도입하여 구조기반 기법 사용을 고려해 볼 것
  →경험기반기법은 회사 내 Testing 전문 인력(10년차 내외)이 있을 경우 명세기반기법 또는 구조기반기법과 병행해서 사용해 볼 것

• 각 기법 별 주요 내용
  명세기반기법

  →일반적으로 공식적/비공식적 모델의 명세화를 위해 사용
  →TC를 모델 및 사양서 기반으로부터 체계적으로 도출
  →일반적으로 문서(사양서 및 설계서)기반 테스트로 커버리지 측정이 제한적

구조기반기법

→코드나 개발 설계 등 소프트웨어 구조를 보여주는 정보로부터 TC 도출
→소프트웨어 커버리지 정도가 기존 TC로부터 측정되고 커버리지를 늘리기 위해 추가적 TC가 체계적으로 도출

경험기반기법

→테스터, 개발자, 사용자 등의 전문 지식 활용
→소프트웨어에서 발생 가능한 결함과 그 분포 등에 대한 지식

● 명세 기반 테스트
-명세, 사양 등 Specification에 기반한 테스트 설계 기법
-Unit Test의 경우 단위 설계 명세서, Integration Test의 경우 아키텍처 설계서가 테스트 베이시스가 됨

-단점: 명세/사양서 등이 존재하지 않으면 TC 설계 불가, 명세/사양서와 소스코드 사이의 불일치가 발생할 경우 테스트 수행 결과가 부정확 할 수 있음

• 블랙 박스 테스팅
  -시스템에 영향을 주는 이벤트, 입력 값, 조건을 기반으로 테스트 수행
  -동작, 출력 값과 시스템이 보여주는 행위를 점검
  

• 화이트 박스 기법
  -설계 및 구현 세부 정보(소스코드)를 기반으로 테스트를 수행
  -데어 흐름, 데이터 흐름, 약점
  

• 페어와이즈 테스팅
  →개념
  -수행의 행렬에서 많이 사용되는 직교 배열을 적용하여, 모든 입력 값의 최소 조합을 TC로 추출하는 기법
  →특징
  -직교배열의 각 열과 행은 Pair-wise 함
  -pair-wise: 둘다 소수인 쌍, 두 수의 공약수가 1밖에 없는 관계, 각 행 및 열에 선택 가능한 입력 값들이 반드시 한 번 이상은 들어감
  →배경
  -대부분의 결함은 2개 요소의 상호작용에 기인한다는 것에 착안, Pair-wise되는 조합을 TC로 하여 최소화

● 구조 기반 기법
-소프트웨어의 경로, 구조와 구현에 기반한 테스트 설계 기법
-일반적으로 프로그래밍 스킬이 필요함

→단점
-실행 경로가 너무 많아 모든 경우의 수를 고려한 테스트 진행은 어려움
-명세/사양서 자체의 오류를 검증하기 어려움(내부 구조 상 결함에 집중)
-추가적인 테스트 코드 및 수행환경을 설정해야 함

○ 코드 커버리지: 소스 코드가 테스트된 정도

-Decision(결정)은 하나 이상의 Condition(조건)으로 이루어짐
-ex) if(x>0 && y==0) / if문 자체는 결정 / x>0,y==0은 조건

• Statement Coverage(문장 커버리지)

  →100% 문장 커버리지는 테스트 중에 프로그램 내의 모든 문장이 적어도 한 번 실행된다는 의미
  

• Decision Coverage(결정 커버리지)

  →100% 결정 커버리지는 테스트 중에 프로그램 내의 모든 결정의 분기가 적어도 한 번씩은 실행됨을 의미
  →100% 결정 커버리지는 100% 문장 커버리지를 보장
  

• Condition Coverage(조건 커버리지)

  →100% 조건 커버리지는 테스트 중에 프로그램 내의 각 결정을 구성하는 조건의 결과가 한 번씩은 나타남을 의미
  →일반적으로 결정 커버리지보다 좋지만 결정 커버지리를 완전히 만족하지 않을 수 있음
  

• Decision Condition Coverage(결정 조건 커버리지)

  →100% 결정 조건 커버리지는 모든 결정을 포함하고 결정 내의 모든 조건의 결과를 나타냄을 의미
  

• Path Coverage(경로 커버리지)

  →100% 경로 커버리지는 프로그램의 모든 실행 가능한 경로가 실행되었음을 의미
  →프로그램이 loop를 포함하면 기하급수적으로 실행 경로가 증가됨
  →실무적으로 이러한 loop을 테스트 할 때는 적절히 loop수를 줄임

• Modified Condision Decision Coverage(MC/DC, 변형된 조건 결정 커버리지)

  

• Function Coverage & Call Coverage

  →함수의 수행 정도와 함수를 호출하는 정도를 측정하기 위한 척도
  →function coverage가 100%가 되지 않았다면, 그 이유는 아무런 Dependency 없이 고립되어 있는 컴포넌트가 존재한다는 것과 아직 아키텍처 레벨에서 충분한 테스트가 이루어지지 않았으므로 추가적인 테스트가 이루어져야 된다는 것을 의미
  

● 경험 기반 기법
-이전에 테스터가 다루었던 유사 어플리케이션이나 기술에서의 경험, 직관, 테스터의 기술 능력으로부터 TC 도출
-탐색적 테스팅 접근법, 분류 트리 기법, 체크리스트, 특성 테스팅
-빠른시간 안에 많은 결함을 찾는데 유용하지만, 인력의존도가 높은 부분이 단점

• 탐색적 테스팅

  →사전에 준비, 디자인 하는 것이 아니라, 수행과 동시에 계획, 디자인, 실행하는 것임
  →명확한 요구사항 명세 뿐 아니라 암묵적인 요구사항들도 테스트
  →시스템이 잘 동작 또는 동작하지 않는다는 증거를 찾기 위한 추론에 집중
  →탐색적 테스팅은 설계,수행,계획,기록 및 학습을 동시에 수행하는 휴리스틱한 테스팅 접근법
  -TC 작성 시간 최소화
  -체크리스트 최소화
  -Test 엔지니어의 발견적(heuristic) 지적능력을 최대한 활용(전문인력)
  -테스트 대상 제품을 실행하면서 익숙해지는 것과 동시에 테스트 설계, 계획
  -Test Charter를 기반으로 1~2시간 동안 집중 수행하고 기록을 남기고, 수행 후 요약 보고 작성
  -TC 기반의 공식적 테스팅과는 반대되는 개념

  →한계
  -탐색적 테스트 엔지니어의 기술과 능력에 심히 의존
  -자동적인 회귀 테스트에 대한 근거를 적게 제공
  -수행된 테스트 범위에 제한된 증거를 이해당사자들에게 줌
  →장점
  -명세가 거의 없고 시간이 부족한 경우, 공식적인 기법을 보충할 경우 유용
  -정해진 임무와 목표, 결과물이 존재
  -초보자가 아닌 전문가에 의해 수행
  -경험치 높은 인력의 활용과 데이터를 기반으로 객관성 확보 및 최적화** 가능

• Error Guessing(오류 추정 기법)
  →개념
  -테스트 중인 컴포넌트가 시스템에서 유입된 오류의 결과로 어떤 결함이 발생할 것인지를 테스터의 경험을 사용하여 예측하고, 해당 결함만을 중점적으로 검출하는 테스트를 설계하는 테스트 설계기법
  →특징
  -단독적으로 사용되는 것이 아니라, 다른 기법과 접목되어 사용될 때 보다 효과적인 검증활동이 가능
  -유사 어플리케이션이나 기술에서의 경험, 직관, 테스터의 기술 능력으로부터 TC를 추출
  -에러 추정 기법을 구조적으로 사용하려면 가능한 결함 또는 오류를 모두 나열하고 이런 유형의 결함 또는 오류를 공격할 수 있도록 테스트 디자인 필요
  -가능한 결함(에러,장애)은 상식, 기존 경험, 결함과 정애 데이터, 왜 소프트웨어가 실패하는지에 대한 일반적인 지식을 통해 도출 가능

■ 테스트 관리

■ 소프트웨어 관리

• 테스트 계획서
  →목적
  -테스트 활동 범위, 접근방법, 자원, 일정 등에 대하여 정의
  →내용
  -테스트 계획서 식별자, 개요, 테스트 항목
  -테스트 대상 특성, 테스트되지 않는 특성, 접근방법
  -항목의 성공/실패 기준, 테스트 중지 기준 밑 재개 요구사항
  -테스트 산출물, 테스트 작업 및 환경 요구사항
  -책임, 자격 및 교육 요건
  -일정, 리스크 및 비상 대처 계획, 승인

• 테스트 케이스 명세서
  →목적
  -테스트 설계 명세서에 의해 식별한 TC를 정의
  →내용
  -TC 명세서 식별자
  -테스트 항목
  -입력 명세서
  -출력 명세서
  -환경 요구사항
  -특별 절차 요구사항
  -TC 간 내부 의존성

• 테스트 결과 보고서
  →목적
  -지정된 테스트 활동의 경과를 요약하고, 그 결과에 근거하여 평가를 제공
  →내용
  -테스트 요약 보고서 식별자
  -테스트 수행 결과 요약
  -차이(설계 명세서,테스트 계획서,테스트 설계,TC와의 차이)
  -전반적인 평가(테스트 계획서에서 제시한 평가기준에 따라 평가
  -결과 요약(테스트 활동의 결과, 해결/미해결 문제점 결과 요약)
  -승인 여부(보고서 승인과 관련된 모든 사람들의 이름, 직책, 날짜, 사인 등)

• 테스팅 조직의 역할
  -제품에 대한 테스트 프로세스 진행 및 산출물 관리
  -제품에 대한 품질 향상을 위한 계획, 관리 및 개선활동 수행

1. Test 계획과 제어(통제)
   산출물: 테스트 계획서 - 테스트 리더

   

2. Test 분석과 설계
   산출물 TC - 테스트 리더, 테스터

   

3. Test 구현과 실행
   산출물: TC - 테스트 리더, 테스터

   

4. Test 완료 조건과 리포팅
   산물물: 테스트 결과 보고서 - 테스트 리더, 테스터

   →테스트 실행결과(log)가 완료 조건을 만족하는지 확인
   →추가 테스트가 필요한지, 아니면 명시된 테스트 완료 조건을 변경해야 하는지에 대한 평가 수행
   →보고서 작성

• 결함 관리 시스템(Bug Management System)
  -결함 생명 주기 관리
  -결함 관련 헙업(업무 할당)
  -결함 History 관리
  -결함 추적성 관리
  -결함 Trend 파악
  -결함 보고서 자동 생성
  -별함 분석을 통한 개선 사항 도출