CSTS 요약 2 - 테스트 설계 기법

테스트 설계 기법 부분은

크게 정적테스트와 동적테스트(구조 기반 테스트, 명세 기반 테스트)로 나뉜다.

 

1. 정적 테스트

• 리뷰 : 전문가가 모여 프로그램/산출물 등을 검토하여 결함 검출. 수작업 중심의 방법
  ex) 관리 리뷰, 기술 리뷰, 인스펙션, 워크쓰루, 감사
• 정적 분석 : 자동화된 도구 지원을 받아 테스트 수행 
  ex) 코딩 표준, 코드 복잡도 분석, 자료 흐름 분석

 

리뷰 프로세스

1. 경영진 준비 : 필요한 자원 제공하고 표준 및 관련 정책의 요구에 따른 리뷰 수행 보장
2. 리뷰 계획 : 리뷰 리더가 팀을 구성하고 책임을 할당하며 리뷰에 필요한 자료/일정 제공
3. 리뷰 절차 개요 설명 : 리뷰 리더의 요청이 있을 때 수행. 리뷰 목적과 리뷰 절차 설명. 자격있는 사람이 수행(꼭 리더일 필요 X)
4. 작업물 개요 설명 : 리뷰 리더 요청 있을 때 수행. 리뷰 참가자들이 작업물 사전 이해도를 높이기 위함
5. 개별 준비 : 팀 멤버들이 개별적으로 작업물/프로세스 검토. 문제 있을 시 리뷰 리더에게 보고
6. 그룹 검토 : 모든 팀 멤버들이 참여하는 회의를 통해 작업물 상태에 관해 합의 도출
7. 재작업 : 검출된 문제를 개발자와 책임자에게 전달
8. 후속작업 : 리뷰 리더는 모든 조치 항목을 완료하였는지 확인

 

관리 리뷰

• 진행 상황을 모니터하고 계획과 현재 일정을 평가하여 필요시 자원, 일정, 범위 등을 변경
• 위의 리뷰 프로세스를 따르지만 4번(작업물 개요 설명)은 수행 X

 

기술 리뷰

• 적절하게 구현되었는지, 계획/법규/표준/명세를 지켰는지, 의도된 사용에 적합한지 등 기술적 상태를 확인
• 대표 엔지니어가 주재하며 경우에 따라 관리자도 참가
• 다른 리뷰와 다르게 관리자가 팀 멤버로 참여 가능

 

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

• 리뷰 중 가장 형식화된 대표적인 방식
• 동료 검토. 비슷한 수준/역할 가진 사람들이 코드/산출물을 검토
• 가능한 개발 초기에 검사해야함
• 장점
  • 품질 투입 비용 감소하여 개발 기간 단축
  • 코딩 전까지 일반적인 개발보다 소요 인력이 더 많이 필요. 
  • 초기 프로젝트 비용 증가하지만 개발 단계의 재작업과 투입 인력 감소
• 참가자의 역할
  1. 주재자 : 검사할 작업물을 기반으로 인스펙션 참가자를 선정하고 계획. 인스펙션 회의를 주재. 회의 후 보고서를 개발자에게 전달하고 프로세스 개선 위해 데이터를 수집. 보통 주재자는 퍼실리테이터가 담당. 
  2. 작성자 : 회의에 필요한 자료를 제출하고 회의 후 검출된 결함에 대해 재작업해야함
  3. 낭독자 : 회의에서 작업물에 대해 설명하고 이끄는 역할 수행 
  4. 기록자 : 회의의 모든 내용 기록하여 문서화. 회의에서 검토자 입장에서 참가. 
  5. 검토자 : 자료에서 결함을 찾고 기록
• 과정 : 리뷰 계획 → 인스펙션 절차 개요 설명 → 인스펙션 작업물에 대한 개요 설명 → 준비 → 검토 회의 → 재작업 → 후속작업  
  1. 리뷰 계획 : 리뷰 리더인 주재자가 팀 구성 후 리뷰 일정/필요한 자료 준비
  2. 인스펙션 절차 개요 설명 : 참가자 역할 할당하고 최소 준비시간, 원하는 인스펙션 수행률 등을 전달
  3. 인스펙션 작업물에 대한 개요 설명 : 작성자가 검토자들에게 작업물 설명.
  4. 준비 : 리뷰 회의 전 팀원들은 작업물 검토하고 문제 있을시 주재자에게 전달. 중재자는 검출된 문제를 작성자에게 전달
  5. 검토 회의 : 작업물의 개별 검토가 완료되면 회의 시작. 낭독자가 참가자들에게 작업물 설명. 작성자는 검토자의 질문을 답함.
  6. 재작업 : 검출된 문제를 작성자에게 전달하면 작성자는 실제 작업물에서 문제를 해결하는 작업 수행(ex. 코드/설계 변경)
  7. 후속작업 : 주재자는 모든 문제에 대해 재작업이 충분히 이루었는지 확인
     
     

 

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

• 비형식적인 결함 검출 방법
• 작성자가 작업물을 따라 돌아다니면서(Walkthroughs) 설명도 하고 결함에 대한 권고 조치사항도 기록하며 후속단계도 확인.
• 검출 뿐만 아니라 교육 및 지식 공유를 위해서도 수행
• 작성자 본인이 회의를 주재하며 기록자 역할도 담당하지만 인스펙션과 동일하게 관리자는 팀 멤버로 참여 불가능.

 

감사

• SW/프로세스가 규제/표준/계획/절차를 준수하는지 독립적으로 평가
• 비준수 사항 사례를 식별하고 교정 활동을 요구하는 보고서 산출

 

 

정적 분석

1. 코딩 표준 : 개발자가 코드 작성시 지켜야 하는 규약
2. 코드 복잡도 분석 : SW는 복잡도가 높지 않아야함. 순환 복잡도 이용하여 분석
3. 자료 흐름 분석 : 자료 흐름에 이상이 있는지 분석 (ex. 변수가 정의되었는가?)
   • 자료 흐름 이상 패턴
     • d : defined
     • k : killed
     • u : used
     • ~x : 모든 선행 행위가 x(d,k,u)와 관련 없음
     • x~ : x 이후 행위들이 x 와 관련 없음

 

 

 

2. 구조 기반 테스트

• 프로그램 제어 흐름 or 자료 흐름 정보를 이용하여 TC 설계
• 구조 기반 테스트 = 화이트 박스 테스트 = 글래스 박스 테스트
• 가장 이상 적인 구조 기반 테스트 : 프로그램 모든 경로를 최소 1번씩 실행
• but 한계가 있어 일부 경로만 테스트
  ex) 문장 테스트, 분기 테스트, 조건 테스트, 다중 조건 테스트, MCDC 등
  1. 문장 테스트 : 프로그램의 모든 문장을 최소한 한 번은 실행
     
     • 문장 커버리지 : 실행된 문장 수 / 전체 실행 가능한 문장 수 * 100
  2. 결정 테스트 : 프로그램의 모든 결정문의 참/거짓되는 경우를 최소한 한 번은 실행
     • 결정 커버리지 : 실행된 결정문의 결과 수 / 전체 결정문의 결과 수 * 100
       
       ※ 분기 테스트 : 분기들이 최소한 한 번은 실행
  3. 조건 테스트 : 기본 조건식의 결과값 참/거짓을 적어도 한 번 이상 실행 (결정 테스트와 서로 포용X)
  4. 다중 조건 테스트 : 테스트 강도가 가장 높으며, 기본 조건식의 가능한 논리 조합이 적어도 한 번 이상 실행
  5. 결정 조건 테스트 : 각 기본 조건식 및 전체 조건식의 결과값 참/거짓 적어도 한 번 이상 실행
  6. 변형된 조건/결정 테스트 (MCDC) : 조건 테스트와 결정 테스트 모두 만족
  7. 기본 경로 테스트 : 프로그램 경로 중 기본 경로를 테스트

 

제어 흐름 그래프

• 프로그램 구조를 효과적으로 나타냄
• 순환 복잡도 = 분기문 수 + 1

 

 

3. 명세 기반 테스트

• 명세 기반으로 TC 개발 (명세 기반 테스트 = 블랙박스 테스트)
• 테스트 전 레벨에서 사용 가능
• 코드 내부 구조를 모르는 사람이 하는게 좋으나 XP에서는 개발자가 할 수 있음
• 장점 : 규모가 큰 시스템도 효과적으로 적용 가능, 구현 관련 지식이 없어도 수행 가능, 사용자 관점에서 수행해서 효과적으로 결함 검출 가능, 코드가 구현될 때까지 기다릴 필요 X

 

동등 분할

• 프로그램 입력 or 출력을 몇 개 영역(=동등 클래스)으로 분할하여 각 클래스에서 임의로 하나의 값을 선택하여 TC로 이용
• 분할된 동등 클래스의 합집합은 입력 영역 그 자체고 동등 클래스들은 서로 공통된 값이 없어야함

 

분류 트리 기법

• 테스트 대상 프로그램 행위에 영향을 줄 수 있는 특성들을 도메인 지식, 경험, 명세 등을 이용하여 식별 → 이에 따라 입력, 출력 등 관심 영역을 여러 클래스로 분할 

 

경곗값 분석

• 입력 영역 경계 근처에 있는 값들 통해 TC 설계
• 동등 분할과 마찬가지로 입력/출력 영역을 여러 클래스로 분할하지만 경곗값 분석은 클래스의 경계 or 경계 근처에 있는 값을 사용

 

조합 테스트

• 테스트 대상 프로그램 내 여러 클래스의 각 입력 인자를 동등 분할이나 BVA 등의 방법으로 여러 클래스/값으로 분할하였을 때 이들을 조합하여 TC를 구성하는 방식
• 종류
  1. Each choice 테스트 : 각 입력 인자의 분할된 클래스에서 최소한 하나의 입력값이 TC에 포함
  2. 페어와이즈 테스트 : 각 인자의 값(or 클래스)과 다른 인자의 값(or 클래스)을 최소한 한 번은 조합을 하여 테스트
  3. All combinations 테스트 : 모든 입력 인자의 모든 가능한 클래스 조합이 TC들에 포함
  4. Base choice 테스트 : 기반이 되는 테스트 조합을 미리 선정하고 선정된 기반 테스트에서 하나의 인자에만 변경을 주며 나머지는 기반 테스트 값으로 고정하여 TC 생성

 

 

결정표 테스트

• 결정표를 이용하여 TC를 설계
• 논리적으로 의존적인, 가능한 모든 조건의 조합을 생성하여 누락된 요구사항을 검사하고자 할 때 효과적임

 

 

상태 전이 테스트

• 시스템을 상태 전이도로 모델링한 후 TC들을 상태 전이도에서 체계적으로 선정하는 방법
• 상태 전이도 : 시스템 외부에서 들어오는 일련의 이벤트들에 대해 시스템 상태가 어떻게 전이되고 어떤 식으로 반응하는가 나타냄
• 종류
  1. 상태 테스팅 : 상태 전이도의 모든 상태를 최소한 한 번은 방문
  2. 단일 전이 테스트 (0-switch) : 상태 전이도의 모든 유효한 전이들을 최소한 한 번은 방문
  3. 다중 전이 테스트 (N-switch) : 상태 전이도에 있는 N+1개의 전이 시퀀스들을 최소한 한 번은 방문
  4. All transitions 테스트 : 유효한 전이를 포함하여 유효하지 않은 전이들도 최소한 한 번은 방문

 

시나리오 테스트 

• 기존의 요구사항 명세서에서 각 개별 기능에 대한 상세한 내용이 시나리오 형태로 기술하여 기능 테스트 수행