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

정적테스트

• 리뷰 : 여러 전문가가 모여 프로그램을 검토하여 결함을 검출 (요구사항 명세서, 설계 명세서, 테스트 계획서 등) 
  • 관리 리뷰 : 진행 상황을 모니터, 계획과 일정 상태 평가 > 일정이나 프로젝트 범위 등 변경
  • 기술 리뷰 : 대표 엔지니어가 주재, 관리자 참가 가능
  • 인스펙션(동료 검토) : 가장 형식화된 대표적인 리뷰 방식.
    • 비슷한 수준이나 역할을 가진 사람들이 검토하는 방식. 가능한 한 초기에 검사해야함.
    • 개별적으로 체크리스트를 사용
    • 참가자
      • 주재자 : 검사할 작업물을 기초로 참가자들 선정, 인스펙션 계획, 검토 목표 달성 여부 판단.
        회의 주재 담당. 회의가 끝난 뒤 어떤 후속 조치가 필요한지 결정
      • 작성자 : 인스펙션에 필요한 자료를 제출, 설명 또는 대답. 주재자 될 수 없음
      • 낭독자 : 자신의 이해 및 해석을 바탕으로 회의를 이끌어감
      • 기록자 : 인스펙션 회의에서 논쟁, 모든 질문 및 답변을 기록. 주재자는 기록자 역할도 가능
      • 검토자 : 객관적인 관점에서 회의 참여. 주어진 자료에서 결함을 찾아내고 기록. 관리자 직책은 참여 금지

• • 워크쓰루 : 비형식적인 결함 검출 + 참가자들의 교육이나 지식 공유.
    
    • 작성자 본인이 회의 주체, 기록자 역할도 가능
    • 관리자 직책 참여 금지
  • 감사 : 소프트웨어 제품 및 프로세스가 규제, 표준, 가이드라인, 계획, 절차를 준수하고 있는지 독립적으로 평가
• 정적 분석 : 도구의 지원을 받아 정적 테스트를 수행하는 것
  • 코딩 표준 부합, 코드 복잡도 계산(순환 복잡도), 자료 흐름 분석
  • 식별할 수 있는 결함 유형 ; 초기화하지 않고 사용한 변수, 선언 후 사용하지 않은 함수, 선언 후 사용하지 않은 변수

 

구조 기반 테스트

= 구조적 테스트, 화이트 박스 테스트, 글래스 박스 테스트

프로그램 제어 흐름이나 자료 흐름 정보를 이용하여 테스트 케이스를 설계하는 방법
모든 가능한 경로를 테스트 하는 대신 일부 경로만 테스트

• 문장 테스트 ; 모든 실행 가능한 문장을 최소한 한 번은 실행
  • 프로그램 경로 집합 유일하지 않음
  • 존재하는 가능한 모든 경우들을 검증하지 못함
  • 문장 커버리지 = (실행된 문장의 수 / 전체 실행 가능한 문장의 수) * 100
• 결정 테스트 ; 모든 결정문의 결과가 참 또는 거짓이 되는 경우를 최소한 한 번은 실행
  • 항상 결정문의 결과로 true 와 false 2개의 값만을 가지진 않음
  • 프로그램 경로 집합은 유일하지 않음
  • 결정 커버리지 = (실행된 결정문의 결과 수 / 전체 프로그램의 결정문 결과 수) * 100
    • 결정 테스트를 만족하는 테스트 케이스 집합은 문장테스트를 만족함(포용함)
• 조건 테스트 ; 모든 조건이 참 또는 거짓이 되는 경우 모두 발생하게 하는 입력 데이터를 테스트 집합으로 사용
  • 조건 ; 관계 연산자(=, < >, <=)만을 적용하거나 Boolean변수로만 이루어진 식
  • 조건 커버리지 = (실행된 개별 조건의 결과 수 / 전체 프로그램 개별 조건의 결과 수) * 100
    • 조건 테스트와 결정 테스트는 서로 포용하지 않음(조건커버리지는 만족하지만,결정커버리지는 만족하지 않을 수 있음)
• 결정/조건 테스트 ; 결정테스트와 조건 테스트를 모두 만족하는 테스트 케이스 집합
  • 결정/조건 커버리지 = (실행된 결정문과 개별 조건의 결과 수 / 전체 프로그램 결정문과 결과 수) * 100
• 다중 조건 테스트 ; 프로그램의 결정들에 사용된 모든 조건(논리) 조합을 테스트 할 수 있는 입력 데이터들을 테스트 집합으로 사용
  
  • 다중 조건 커버리지 = (실행된 조건들의 조합 수 / 전체 프로그램 개별 조건들의 조합 수) * 100
    • 문장 테스트, 결정 테스트, 조건 테스트, 결정/조건 테스트 포용함

 

명세 기반 테스트

= 블랙박스 테스트

프로그램의 내부 논리 구조 참조하지 않고, 사용자의 요구사항 명세서나 설계정보 등으로 테스트 케이스 개발
명세 정보를 얻을 수 있는 한, 적용 대상 제한 없이 컴포넌트 ~ 통합 ~ 시스템 및 인수 테스트 등 전 과정에 걸쳐 사용 가능

프로그램 내부 구조를 전혀 모르는 사람이 수행하는 것이 좋다.

• 동등 분할
  • 테스트를 효과적으로 수행하며, 테스트 케이스의 개수를 줄이는 방법 
  • 몇 개의 영역으로 분할하여(동등 클래스) 각 클래스에서 하나의 값을 선택 > 테스트 케이스로 이용
    • 분할된 동등 클래스들의 합집합은 입력 영역 그 자체이며, 서로 공통된 값이 없어야 함
    • 유효한 입력 및 출력만을 고려하는 것이 아닌 유효하지 않은 입력 및 출력도 고려해야 함
  • One-to-One 동등분할 ; 하나의 테스트 케이스와 하나의 동등분할 클래스(1:1)
  • 최소화 동등분할 ; 하나의 테스트 케이스에 여러개의 클래스 (1:n)
• 경곗값 분석
  • 입력 영역 경계 근처 값들을 이용해 테스트 케이스 설계(경계와 경계 근처에 있는 값들을 이용)
• 조합 테스트
  • 여러 클래스 또는 값으로 분할 하였을 때 이들을 조합하여 테스트 케이스를 구성
    • Each choice 테스트 ; 각 입력 인자의 분할된 클래스에서 하나의 입력값이 테스트 케이스에 포함
      • Each choice 테스트의 수 < All combinations 테스트 수 = 각 입력 인자의 클래스가 
    • 페어와이즈 테스트 ; 각 인자의 값(클래스)과 다른 인자의 값(또다른 클래스)을 최소한 한 번은 조합하여 테스트
      • 모든 입력 값의 모든 짝(pair)을 테스트
        즉, 모든 상호작용을 고려하지 않고, 두 개의 입력 간 모든 상호작용만을 고려
    • All combinations 테스트 ; 모든 입력 인자의 모든 가능한 클래스 조합을 테스트 케이스에 포함
      
      • 입력 인자가 늘어날수록 테스트 케이스가 기하급수적으로 증가하게 된다. 
    • Base choices 테스트 ; 기반이 되는 테스트 조합을 미리 선정하여 테스트 케이스 생성하는 방법
• 결정표 테스트
  • 결정표를 이용하여 테스트 케이스 설계 (조건을 기술하는 부분 + 조건의 조합에 대해 취하는 행위)
  • 각 규칙이 최소한 한 번은 테스트 할 수 있도록 테스트 케이스를 생성
  • 가능한 조건 조합 중 어떤 경우가 누락되었는지 알 수 있음
• 상태전이 테스트
  • 시스템을 상태 전이도(STD)로 모델링 한 후 테스트 케이스를 상태 전이도에서 선정
    • 상태 테스트 ; 상태 전이도의 모든 상태를 최소한 한 번 방문하는 테스트 케이스를 설계
    • 단일 전이 테스트 ; 상태 전이도의 모든 유효한 전이들을 최소한 한 번 방문하는 테스트 케이스를 설계
    • All transaitions 테스트 ; 유효한 전이 + 유효하지 않은 전이들도 최소한 한 번 방문하는 테스트 케이스를 설계
    • 다중 전이 테스트 ; 상태 전이도에 있는 N+1 개의 전이 시퀀스들을 최소한 한 번 방문하는 테스트 케이스를 설계