[CSTS 요약정리] 2. 테스트 설계 기법

정적 테스트 7문제

정적 테스팅 개요

• 정적 테스트는 리뷰라고 하고 관리 리뷰, 기술 리뷰, 인스펙션, 워크쓰루, 감사로 분류
• 리뷰는 여러 전문가가 모여 프로그램을 검토하며 결함을 검출하는 방법
• TomGlib `리뷰를 이용하면 결함을 발견하고 제거하는 평균 비용을 60~80% 감소시킬 수 있다.`

리뷰

경영진 준비 > 리뷰 계획 > 리뷰 절차 개요 설명 > 작업물 개요 설명 > 개별준비 > 그룹검토 > 재작업 > 후속작업

 

관리 리뷰

• 진행 상황을 모니터하고 계획과 현재 일정 상태를 평가
• 자원, 일정이나 프로젝트 범위 변경
• 프로젝트 진행 상황 문서 :
  설치 계획, 백업 및 회복 계획, 안정성 계획, 재난 계획, 비상 대책 계획, 진행 보고서, 테스트 결과

기술 리뷰

• 유능한 인력으로 구성된 팀이 작업을 수행하여 프로젝트의 기술적 상태를 확인하는 증거로 관리자에게 제공
• 사용 적합성, 계획 법규 표준 명세, 구현 적절성, 대안 추천 및 검토
• 대상 : 소프트웨어 요구 설계 명세, 테스트 문서, 유지보수 메뉴얼, 설치 절차 등
• 관리자도 참가 가능

인스펙션(기술적 리스크)

• 동료 검토, 리뷰 중 가장 형식화된 대표적 리뷰 방식
• 주재자, 작성자, 낭독자, 기록자, 검토자
• 퍼실리레이터 : 작업 과정 설계, 참여 유도하여 결과물이 잘 나오도록 도움(보통 주재자가 담당)
• 리뷰 계획 > 인스펙션 절차 개요 설명 > 인스펙션 작업물에 대한 개요 설명 > 준비 > 검토 회의 > 재작업 > 후속 작업

워크쓰루(사업적 리스크)

• 인스펙션보다는 비형식적 결함 검출 방법
• 작성자가 회의 주재자, 기록자 역할도 담당
• 작업물을 따라 돌아다니면서 작업물에 대한 설명을 진행하고 검출된 결함에 대한 권고 및 조치 사항 기록
• 재작업 및 후속 단계에서 작성자는 모든 조치사항이 종결되었음을 확인

감사

• 소프트웨어 제품 및 프로세스가 규제, 표준, 가이드라인, 계획, 절차를 준수하는지 독립적으로 평가
• 대표 감사자, 감사자, 기록자, 개시자
• 대표 감사자가 감사 주도, 인터뷰나 문서를 점검해서 법규나 표준 등에 부함되는지 증거 수집
• 비준수 사항의 사례를 식별하고 해당팀이 교정 활동을 요구하는 보고서 산출

 

정적 분석

코딩 표준 : 코딩 표준 또는 코딩 지침은 개발자가 프로그램 작성 시 지켜야할 규약

 

복잡도 분석

• 소프트웨어 개발의 핵심은 복잡도를 통제하여 필요 이상으로 복잡도가 높지 않도록 하는 일
• McCabe가 발표한 순환 복잡도가 가장 널리 사용되고 있으며 많은 정적 도구가 이 지표를 지원함\
• 순환 복잡도 = 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~	제일 나중에 발생한 무효화		문제 없음, 정상적인 경우

---

동적 테스트 17문제

구조기반 테스팅

• 프로그램 제어 프름이나 자료 흐름 정보를 이용하여 테스트 케이스를 설계하는 방법
• 구조적 테스트, 화이트박스 테스트, 글래스 박스 테스트라고도 함
• 일부 경로만 테스트하는 방법 사용
• 가장 이상적인 것은 프로그램의 모든 경로를 최소 한 번 실행하여 테스트하는 것

 

문장 테스팅

• 프로그램의 모든 문장을 최소 한 번은 행하도록 함
• 절차
  대상 프로그램의 제어 흐름 그래프 작성 > 실행 가능한 모든 기본 블록을 지나가는 프로그램 경로 집합 식별
  > 각 프로그램 경로에 대해 1) 경로를 실행하는 입력 데이터 식별 2) 명세 등에서 해당 입력에 대한 기대 출력 식별
• 문장 커버리지

 

결정 테스팅

• 프로그램 상에 나타난 모든 결정문의 결과가 참이 되는 경우와 거짓이 되는 경우를 최소 한 번 실행하도록 함
• 절차
  제어 흐름 그래프 작성 > 아직 실행되지 않은 결정의 결과에 도달하는 프로그램 경로 집합 식별
  > 각 프로그램 경로에 대해 1) 경로를 실행하는 입력 데이터 식별 2) 명세 등에서 해당 입력에 대한 기대 출력 식별
  > 모든 결정의 결과가 실행될 때까지 반복
• 결정 커버리지

 

조건 테스팅

• 모든 조건이 true가 되는 경우와 false가 되는 경우 모두 발생하게 하는 입력 데이터를 테스트 케이스 집합으로 사용
• 절차
  제어 흐름 그래프 작성 > 아직 실행되지 않은 조건의 결과에 도달하는 프로그램 경로 집합 식별
  > 각 프로그램 경로에 대해 1) 경로를 실행하는 입력 데이터 식별 2) 명세 등에서 해당 입력에 대한 기대 출력 식별
  > 모든 조건의 결과가 실행될 때까지 반복
• 조건 테스트와 결정 테스트는 서로 포용하지 않음
• 조건 커버리지

 

조건/결정 테스팅

• 결정 테스트와 조건 테스트를 모두 만족하는 테스트 케이스 집합을 설계하도록 요구
• 모든 개별 조건식이 전체 판단문의 결과값 확정에 영향을 줌
• 변형 조건/결정 커버리지 : 개별 조건식의 결과와 독립적으로 전체 조건식의 결과에 영향을 주는 경우
• 절차
  제어 흐름 그래프 작성 > 아직 실행되지 않은 결정과 조건의 결과에 도달하는 프로그램 경로 집합 식별
  >각 프로그램 경로에 대해 1) 경로를 실행하는 입력 데이터 식별 2) 명세 등에서 해당 입력에 대한 기대 출력 식별
  > 모든 결정과 조건의 결과가 실행될 때까지 반복
• 결정/조건 커버리지

 

다중 조건 테스팅

• 결정이 가질 수 있는 경우뿐 아니라 결정을 구성하는 기본 조건들이 가질 수 있는 모든 가능한 조합까지 검증
• 프로그램의 결정들에 사용된 모든 조건의 조합을 테스트할 수 있는 입력 데이터를 테스트 케이스로 선정
• 문장 테스트, 결정 테스트, 조건 테스트, 결정/조건 테스트 모두 포용
• 절차
  제어 흐름 그래프 작성 > 아직 실행되지 않은 조건의 조합을 실행하는 프로그램 경로 식별
  > 각 프로그램 경로에 1) 경로를 실행하는 입력 데이터 식별 2) 명세 등에서 해당 입력에 대한 기대 출력 식별
  > 모든 결정에 포함된 조건들의 조합이 실행될 때까지 반복
• 다중 조건 커버리지

 

명세기반 테스팅

 

• 내부 논리 구조를 참조하지 않음. 코드 내부 구조를 전혀 모르는 사람이 수행하는 것이 더 좋음
• XP 테스트 주도 개발에서는 개발자가 먼저 테스트 케이스 작성 후 코드 구현

 

동등 분할

• 소프트웨어 테스트의 근간을 이루는 방법
• 테스트 케이스의 개수를 줄이는 방법
• 절차
  명세에서 입력과 출력 식별 > 각 입출력 영역을 동등 클래스들로 분할 > 대푯값을 선정해서 반영하고 테이블 작성
• 동등 클래스 입력 영역 분할 규칙
  범위, 특정 값에 대한 조건 만족/불만족을 두 클래스로 분할, 
  집합의 원소일 때 그 원소만으로 이루어진 경우와 그렇지 않은 클래스로 분할
  어떤 개체가 존재하는지 따지는 경우에는 있는 경우와 없는 경우로 클래스 분할
• one-to-one 동등 분할
  테스트 케이스와 분할한 클래스 간 일대일 관계를 명시적으로 보여줌
  입력으로 받아들이지 않으면 테스터 입장에서는 어떤 필드가 잘못됐는지 알 수 없음
  유효하지 않은 테스트 케이스 설계 시 한 번에 하나의 필드만 유효하지 않은 입력으로 구성하는 것이 바람직
• 최소화 동등 분할
  하나의 테스트 케이스에 여러 개의 클래스가 포함되도록 함

 

경곗값 분석

• 입력 영역 경계 근처에 있는 값들을 이용하여 테스트 케이스 설계
• 동등 분할과 마찬가지로 입출력 영역을 여러 클래스로 분할
• 절차
  명세에서 입출력 식별 > 동등분할 수행 > 분할된 클래스의 경곗값 식별
  >2-value BVA or 3-value BVA에 따라 경곗값 분석 > 얻은 각 값에 대해 기대 출력을 구하여 테스트 케이스 설계
• 테스트 케이스 구성 시 일대일 방법이나 최소화 방식 사용

 

조합 테스팅

• 여러 클래스 또는 값으로 분할했을 때 이들을 조합해서 테스트 케이스를 구성하는 방식
• each choice test : 각 입력 인자의 분할된 클래스에서 최소한 하나의 입력 값이 테스트 케이스에 포함
• 페어와이즈 테스트 : 각 인자의 값과 다른 인자의 값을 최소한 한 번은 조합하여 테스트
• all combination test : 모든 입력 인자의 모든 가능한 클래스 조합이 테스트 케이스에 포함
• base choice test :  기반이 되는 테스트 조합을 미리 선정
  사용자 관점에서 선택될 빈도가 가장 높고, 정상 동작을 할 수 있는 것으로 선정
  선정된 기반 테스트에서 한 인자에만 변경을 주고 나머지는 기반 테스트 값으로 고정하여 테스트 케이스 생성
• 절차 
  테스트 대상 프로그램의 입력 식별 > 각 입력 인자를 동등 분할이나 BVA로 여러 값이나 클래스로 분할
  > 적절한 조합 테스트 방법을 선정하여 입력 값 조합 > 각 입력 조합에 대해 명세를 분석하고 기대 결과를 할당

 

결정표 테스팅

• 결정표는 조건을 기술하는 부분과 조건의 조합에 대해 취하는 행위를 기술하는 부분으로 구성
• 절차
  모든 조건 분석 > 모든 조건 조합의 행위 결정 > 결정표 생성 > 불가능한 조건의 조합 배제
  > 결정표 축약 가능성 파악 > 각 규칙이 최소한 한 번은 테스트될 수 있도록 테스트 케이스 생성

 

상태 전이 테스팅

• 시스템을 상태 전이도로 모델링하고 테스트 케이스들을 상태 전이도에서 체계적으로 선정하는 방법
• 상태 테스트 : 상태 전이도의 모든 상태를 최소 한 번 방문하는 테스트 케이스들을 설계
• 단일 전이 테스트 : 상태 전이도의 모든 유효한 전이들을 최소 한 번 방문하는 테스트 케이스 설계
• all transition test : 유효한 전이를 포함해 유효하지 않은 전이들도 최소 한 번 방문하는 테스트 케이스 설계
• 다중 전이 테스트 : 상태 전이도에 있는 N+1개의 전이 시퀀스들을 최소 한 번 방문하는 테스트 케이스 설계
• 절차
  상태 전이도의 초기 상태를 전이 트리의 루트 노드로 함 > 전이 목적 상태에 해당하는 노드 추가하고 루트 노드와 간선 연결 > 목적 상태가 전이 트리에 이미 나와있거나 종료 상태가 아니면 같은 과정을 각 목적 상태에 수행

 

경험기반 테스팅

• 이전에 테스터가 다루었던 유사한 기술에서의 경험, 직관, 기술 능력으로부터 테스트 케이스를 추출
• 공식적인 기법과 같이 사용해야 효과적
• 경험에 따라 효율성 및 효과성 정도가 매우 달라짐(일관성X)

 

오류 추정

 

탐색적 테스팅

• 테스트 케이스 작성 시간을 최소화, 발견적인(휴리스틱) 지적능력을 최대한 활용하여 테스트 수행
• 테스트 차터를 기반으로 수행
  테스트 차터 : 어느 부분을 어떻게 테스트하고 어떤 것을 중점적으로 볼지 기록한 테스트 명령지
• 테스트 노트 : 테스트 실행과 동시에 계획, 설계, 테스트 케이스 작성을 문서화한 것
• 타임 박싱 : 60~120분, 테스트 집중력을 높이기 위해 테스트 시간 제한
• 제한된 시간 내에 테스팅 목적을 정하고 몰입하여 최소한의 설명 가능한 기록을 남기고 수행, 요약보고
• 에드혹, 게릴라, 직관적 테스팅과 유사한 개념 / 점진적, 주기적 테스팅
• 절차
  제품의 목적 식별 > 기능 식별> 잠재적으로 불안정한 부분 식별
  > 각 기능 테스트 및 문제점 기록 > 일관성 검증 테스트 설계 및 기록
• 테스트 차터 > 테스트 노트 > 타임 박싱 > 회고