애플리케이션 테스트 관련 파트입니다.

---

1. 애플리케이션 테스트 케이스 설계

01. 애플리케이션 테스트 케이스 작성 ⭐⭐⭐

1) 소프트웨어 테스트의 이해

① 소프트웨어 테스트

• 개발된 응용 애플리케이션이나 시스템이 사용자가 요구하는 기능과 성능, 사용성, 안정성 등을 만족하는지 확인하고, 노출되지 않은 숨어있는 소프트웨어의 결함을 찾아내는 활동

② 소프트웨어 테스트 필요성

• 오류 발견 관점 : 프로그램에 잠재된 오류를 발견하고 이를 수정
• 오류 예방 관점 : 프로그램 실행 전 동료 검토, 워크 스루, 인스펙션 등을 통해 오류 사전 발견
• 품질 향상 관점 : 사용자의 요구사항 및 기대 수준 만족을 위해 반복적인 테스트를 거쳐 신뢰도 향상

③ 소프트웨어 테스트의 기본 원칙 ⭐

1. 소프트웨어 테스트 원리

   원리	설명
   결함 존재 증명	- 결함은 없을 수 없기에 존재함을 밝히고 줄이는 방향
   완벽한 테스팅은 불가능	- 무한 경로, 무한 입력값
   초기 집중	- 조기 테스트 설계 장점 : 테스팅 결과를 단시간에 알 수 있고, 재작업을 줄여 개발 기간 단축 및 결함 예방 - 요르돈의 법칙(Snowball Effect, 눈덩이 법칙)
   결함 집중	- 적은 수의 모듈에서 대다수 결함 발견 - 파레토 법칙(Pareto Principle) : 오류 80%는 전체 모듈 20% 내에서 발견
   살충제 패러독스	- 동일한 테스트 케이스에 의한 반복적 테스트는 새로운 버그 찾지 못함 - 테스트 케이스의 정기적 리뷰와 개선 필요
   정황 의존성	- 소프트웨어의 성격에 맞게 테스트 실시 - 정황과 비즈니스 도메인에 따라 테스트를 다르게 수행
   오류-부재의 궤변	- 요구사항을 충족시켜주지 못하면, 결함이 없어도 품질이 높지 않음

2. 소프트웨어 테스트 프로세스

   • 테스트 계획 → 테스트 분석 및 디자인 → 테스트 케이스 및 시나리오 작성 → 테스트 수행 → 테스트 결과 평가 및 리포팅

3. 소프트웨어 테스트 산출물

   산출물	설명
   테스트 계획서 (Test Plan)	테스트 목적과 범위, 대상 시스템 구조, 테스트 수행 절차, 테스트 일정, 조직의 역할 및 책임, 종료 조건 등 테스트 수행 계획 문서
   테스트 베이시스 (Test Basis)	분석, 설계 단계의 논리적인 Case로 테스트 설계를 위한 기준이 되는 문서 (요구사항 명세서, 관련 기준 또는 표준 등)
   테스트 케이스 (Test Case)	테스트를 위한 설계 산출물, SW가 요구사항을 준수하는지 확인하기 위해 설계된 입력값, 실행 조건, 기대 결과로 구성된 테스트 항목의 명세서
   테스트 슈트 (Test Suites)	- 테스트 케이스를 실행환경에 따라 구분해 놓은 테스트 케이스 집합 - 시나리오가 포함되지 않은 단순 테스트 케이스 모음
   테스트 시나리오 (Test Scenario)	- 테스트 되어야 할 기능 및 특징, 테스트 필요 상황 작성 문서 - 하나의 단일 테스트 시나리오가 하나/여러 케이스들 포함 가능 - 예 : Test Scenario 1. 로그인 > 상품검색 > 장바구니 담기 > 주문 >결제
   테스트 스크립트 (Test Script)	- 테스트 케이스의 실행 순서(절차) 작성 문서 - Test Step, Test Procedure라고도 함 - 예 : Test Procedure 1. 로그인, Test Procedure 2. 상품검색, Test Procedure 3. 장바구니 담기, ...
   테스트 결과서 (Test Results)	테스트 결과를 정리한 문서, 테스트 프로세스 리뷰, 테스트 결과 평가를 리포팅

2) 소프트웨어 테스트 유형 ⭐⭐

① 프로그램 실행 여부에 따른 분류

• 정적 테스트
  : 테스트 대상 실행 X, 구조 분석
  • 리뷰, 정적 분석
• 동적 테스트
  : 소프트웨어를 실행
  • 블랙박스 테스트(명세 기반 테스트)
  • 화이트박스 테스트(구조 기반 테스트)
  • 경험기반 테스트

② 테스트 기법에 따른 분류 ⭐

• 화이트박스 테스트
  : 코드 분석, 프로그램 구조
  • 구분=문장(Statement Coverage)
  • 결정=선택(Decision Coverage)=분기 커버리지(Branch Coverage)
  • 조건(Condition Coverage)
  • 조건/결정(Condition/Decision Coverage)
  • 변경 조건/결정(Modified Condition/Decision Coverage)
  • 다중 조건(Multiple Condition Coverage)
  • 기본 경로=경로(Base Path Coverage)
  • 제어 흐름(Control Flow Coverage)
  • 데이터 흐름(Data Flow Coverage)
  • 루프(Loop Coverage)
• 블랙박스 테스트
  : 요구사항 명세 수행
  • 동등분할=동치 분할, 균등 분할=동치 클래스 분해(Equivalence Partitioning Testing)
  • 경곗값 분석(Boundary Value Analysis Testing)
  • 결정 테이블(Decision Table Testing)
  • 상태 전이(State Transition Testing)
  • 유스케이스(Use Case Testing)
  • 분류 트리(Classification Tree Testing)
  • 페어와이즈(Pairwise Testing)
  • 원인-결과 그래프(Cause-Effect Testing)
  • 비교(Comparison Testing)
  • 오류 추정(Error Guessing Testing)

1. 화이트박스 테스트(White-Box Test)

   • 응용 프로그램의 내부 구조와 동작을 검사
   • 구조 기반 테스트, 코드 기반 테스트, 로직 기반 테스트, 글래스(Glass) 박스 테스트라고 불림

   유형	설명
   구문 커버리지 =문장 커버리지 (Statement Coverage)	- 프로그램 내 모든 명령문을 적어도 한 번 수행 - 조건문 결과와 관계없이 구문 실행 개수로 계산
   결정 커버리지 =선택 커버리지 (Decision Coverage) =분기 커버리지 (Branch Coverage)	- (각 분기의) 결정 포인트 내의 전체 조건식이 적어도 한 번은 참과 거짓의 결과를 수행 - 구문 커버리지 포함
   조건 커버리지 (Condition Coverage)	- (각 분기의) 결정 포인트 내의 개별 조건식이 적어도 한 번은 참과 거짓의 결과가 되도록 수행 - 구문 커버리지 포함
   조건/결정 커버리지 (Condition/Decision Coverage)	전체 조건식 뿐만 아니라 개별 조건식도 적어도 한 번은 참과 거짓의 결과가 되도록 수행
   변경 조건/결정 커버리지 (Modified Condition/ Decision Coverage)	개별 조건식이 다른 개별 조건식에 영향을 받지 않고, 전체 조건식에 독립적으로 영향을 주어 조건/결정 커버리지를 향상
   다중 조건 커버리지 (Multiple Condition Coverage)	결정 조건 내 모든 개별 조건식이 모든 가능한 조합 100% 보장
   기본 경로 커버리지 =경로 커버리지 (Base Path Coverage)	수행 가능한 모든 경로 테스트
   제어 흐름 커버리지 (Control Flow Coverage)	프로그램 제어 구조를 그래프 형태로 나타내어 새부 로직 테스트
   데이터 흐름 커버리지 (Data Flow Coverage)	제어 흐름 그래프에서 데이터 사용현황 추가한 그래프를 통해 테스트
   루프 커버리지 (Loop Coverage)	프로그램의 반복(Loop) 구조

2. 블랙박스 테스트(Black-Box Test)

   • 기능 및 동작 위주의 테스트

   유형	설명
   동등분할= 동치 분할, 균등 분할= 동치 클래스 분해 (Equivalence Partitioning)	입력 데이터 영역을 유사한 도메인 별로 유효값/무효값 그룹핑, 대푯값 테스트 케이스 도출
   경곗값 분석 (Boundary Value Analysis)	경곗값 포함하여 테스트 케이스 설계
   결정 테이블 (Decision Table)	요구사항의 논리와 발생 조건을 테이블 형태로 나열, 조건과 행위를 모두 조합하여 테스트
   상태 전이 (State Transition)	테스트 대상, 시스템, 객체의 상태를 구분, 이벤트에 의해 상태가 전이되는 경우의 수 수행
   유스케이스 (Use Case)	유스케이스가 모델링 되어 있을 때 프로세스 흐름을 기반으로 테스트 케이스 명세화 수행
   분류 트리 (Classification Tree)	SW의 일부 또는 전체를 트리 구조로 분석 및 표현
   페어와이즈 (Pairwise)	테스트 데이터 값들을 최소 한 번씩 조합, 테스트 범위를 줄임
   원인-결과 그래프 (Cause-Effect)	그래프로 입력 데이터 간의 관계 및 출력에 미치는 영향 분석, 효용성 높은 테스트 케이스 선정
   비교 (Comparison)	여러 버전 프로그램에 같은 입력값을 넣어 동일한 결과가 나오는지 비교
   오류 추정 (Error Guessing)	개발자 실수 추정, 다른 블랙박스 테스트 기법 보완

③ 테스트 시작에 따른 분류

• 검증(Verification)
• 확인(Validation)

유형	설명
검증(Verification)	- 소프트웨어 개발 과정 테스트 - 올바른 제품 생산 검증 - 이전 단계에서 설정된 개발 규격과 요루 충족 판단 - 개발자 혹은 시험자의 시각으로 명세화된 기능을 올바로 수행하는지 알아보는 과정
확인(Validation)	- 소프트웨어 결과 테스트 - 만들어진 제품이 제대로 동작하는지 확인 - 최종 사용자 요구 또는 소프트웨어 요구에 적합 판단 - 사용자 시각으로 올바른 소프트웨어가 개발되었는지 입증하는 과정

④ 테스트 목적에 따른 분류

• 회복(Recovery)
• 안전(Security)
• 성능(Performance)
  • 부하(Load) : 부하 증가, 시스템 임계점 찾고, 병목 현상 제거
  • 강도(Stress) : 처리 능력 이상 부하에서 시스템 동작 상태 확인
  • 스파이크(Spike) : 짧은 시간에 사용자가 몰릴 때 시스템의 반응 측정
  • 내구성(Endurance) : 오랜 시간 동안 높은 부하를 가하여 시스템 반응 확인
• 구조(Structure)
• 회귀(Regression)
• 병행(Parallel)

유형	설명
회복(Recovery)	시스템에 고의로 실패 유도, 시스템 정상 복귀 여부 테스트
안전(Security)	불법적인 소프트웨어 접근 예방을 위해, 소스 코드 내의 보안적인 결함 미리 점검
성능(Performance)	사용자 이벤트에 시스템 응답 시간, 특정 시간 내 처리하는 업무량 등을 측정
구조(Structure)	시스템의 내부 논리 경로, 소스 코드의 복잡도 평가
회귀(Regression)	오류를 제거하거나 수정한 시스템에서 새로이 유입된 오류가 없는지 확인하는 반복 테스트
병행(Parallel)	변경된 시스템과 기존 시스템에 동일한 데이터 입력 결과 비교

⑤ 테스트 종류에 따른 분류

• 명세 기반 테스트(블랙박스 테스트)
• 구조 기반 테스트(화이트박스 테스트)
• 경험 기반 테스트(블랙박스 테스트)
  : 유사 소프트웨어나 유사 기술 평가에서 테스터의 경험을 토대로 수행
  • 탐색적 테스트(Exploratory Test)
    : 문서 X, 휴리스틱한 능력, 구성요소(테스트 차터, 시간 제한, 노트, 회고)
  • 오류 추정(Error Geussing)
    : 개발자 실수 추정

3) 정적 테스트

① 리뷰(Review)

1. 동료 검토(Peer Review)
   • 2~3 명이 진행하는 리뷰 형태로, 요구사항 명세서 작성자가 요구사항 명세서를 설명하고, 이해관계자들이 설명을 들으면서 결함 발견
2. 인스펙션(Inspection)
   • 저작자 외의 다른 전문가 팀이 검사하여 문제 식별 및 해결
   • 개발 초기에 검사해야만 개발 초기 작업물에서 문제 발견
   • 관리자 직책 담당은 멤버 참여 금지
3. 워크 스루(Walk Throughts)
   • 검토 자료를 회의 전 배포하여 사전 검토 후, 짧은 시간 동안 회의 진행
   • 결함 검출 및 참가자 교육, 지식 공유
   • 작성자 본인이 회의를 주재하며, 관리자 직책 담당은 멤버 참여 금지

② 정적 분석(Static Analysis)

• 도구의 지원을 받음
• 자동화된 도구를 이용하여 산출물의 결함 검출, 복잡도 측정
• 코딩 표준 부합, 코드 복잡도 계산, 자료 흐름 분석

4) 테스트 오라클

• 테스트의 결과가 참인지 거짓인지 판단하기 위해 사전 정의된 참값을 입력하여 비교하는 기법

  유형	설명
  참(True) 오라클	모든 입력값에 대해 기대 결과를 생성, 발생된 오류 모두 검출
  샘플링(Sampling) 오라클	특정한 몇 개 입력값에 대해 기대하는 결과를 제공
  휴리스틱(Heuristic) 오라클	샘플링 오라클 개선, 특정 입력값에 올바른 결과 제공, 나머지 값은 휴리스틱(추정)으로 처리
  일관성 검사(Consistent) 오라클	APP 변경 시, 수행 전과 후 결괏값이 동일한지 확인

02. 애플리케이션 테스트 시나리오 작성 ⭐⭐

1) 테스트 레벨

① 테스트 레벨(Test Level)

• 함께 편성되고 관리되는 테스트 활동 그룹
• 프로젝트에서 책임과 연관
• 각각의 테스트 레벨은 서로 독립적

② 테스트 레벨 종류

• 단위 테스트
  • 정적 테스트
  • 동적 테스트
• 통합 테스트
  • 하향식 테스트
  • 상향식 테스트
  • 빅뱅 테스트
  • 샌드위치 테스트
• 시스템 테스트
  • 기능적 테스트
  • 비기능적 테스트
• 인수 테스트
  • 알파 테스트 : 사용자가 개발자 환경에서 함께 수행
  • 베타 테스트 : 실제 환경에서 사용자가 사용

[qwerty] [NCS학습모듈/지필] 애플리케이션 테스트 관리

종류	설명	기법
단위 테스트	사용자 요구사항에 대한 단위 모듈, 서브루틴 테스트	정적, 동적 테스트
통합 테스트	인터페이스, 통합된 컴포넌트 간의 상호 작용 검증	빅뱅, 샌드위치, 상향식, 하향식 테스트
시스템 테스트	통합된 단위 시스템의 기능이 시스템에서 정상 수행되는지	기능, 비기능 요구사항 테스트
인수 테스트	요구사항 만족 확인	알파, 베타 테스트

2. 애플리케이션 통합 테스트

01. 애플리케이션 테스트 수행

1) 단위 테스트

① 단위 테스트(Unit Test)

• 개별적인 모듈(또는 컴포넌트) 테스트
• 구현 단계에서 각 모듈을 구현한 후 수행
• 개별적인 모듈에 대해 컴포넌트 테스트를 수행하려면 모듈을 단독으로 실행할 수 있는 테스트 배드 환경 필요

② 단위 테스트 수행 도구

• 테스트 드라이버(Test Driver)
  • 모듈 테스트 수행 후 결과를 도출하는 시험용 모듈
  • 필요 테스트를 인자로 넘겨주고, 테스트 완료 후 그 결괏값을 받는 역할을 하는 가상 모듈
  • 하위 모듈을 호출하는 상위 모듈
• 테스트 스텁(Test Stub)
  • 일시적으로 필요한 조건만 가지고 임시로 제공되는 시험용 모듈
  • 상위 모듈에 의해 호출되는 하위 모듈

2) 통합 테스트

① 통합 테스트(Integration Test)

• 소프트웨어 각 모듈 간의 인터페이스 관련 오류 및 결함을 찾아내기 위함
• 단위 테스트가 끝난 모듈 또는 컴포넌트 단위의 프로그램이 설계 단계에서 제시한 애플리케이션과 동일한 구조와 기능으로 구현된 것인지 확인

② 하향식 통합

• 메인 제어 모듈로부터 아래 방향으로 이동하면서 통합하면서 테스트 진행
• '깊이-우선' 또는 '너비-우선' 방식으로 통합

[해솔] 정보처리기사 실기 : 19강 애플리케이션 테스트 관리 (애플리케이션 통합 테스트하기)

③ 상향식 통합

• 최하위 레벨 모듈 또는 컴포넌트로부터 위쪽 방향으로 구축 및 테스트

[해솔] 정보처리기사 실기 : 19강 애플리케이션 테스트 관리 (애플리케이션 통합 테스트하기)

④ 샌드위치 통합

• 상향식 + 하향식 통합 테스트 결합
• 하위 프로젝트가 있는 큰 규모의 통합 테스트에서 사용
• 병렬 테스트 가능, 시간 절약, 기용 소모

⑤ 통합 테스트 수행 방법 간 비교

테스트 방안	빅뱅 테스트	상향식 테스트	하향식 테스트	샌드위치 테스트
테스트 수행 방법	- 모든 모듈 통시 통합	- 최하위 모듈 부터	- 최상위 모듈부터	- 상위는 하향식+ 하위는 상향식
드라이버 /스텁	- 실제 모듈	- 테스트 드라이버	- 테스트 스텁	- 스텁+드라이버
장점	- 단시간 테스트 가능 - 작은 시스템에 유리	- 장애 위치 파악 쉬움 - 모든 모듈 개발 시간 낭비 없음	- 장애 위치 파악 쉬움 - 이른 프로토타입 가능 - 중요 모듈 선 테스트	- 병렬 테스트 가능 - 시간 절약 - 큰 규모 통합 테스트
단점	- 장애 위치 파악 어려움 - 모든 모듈 개발 필요	- 중요 모듈 마지막 테스트 - 이른 프로토타입 어려움	- 많은 스텁 필요 - 하위 모듈의 불충분 테스트	- 큰 비용

3) 테스트 자동화 도구

• 테스트 도구를 활용하여 반복적인 테스트 작업을 스크립트 형태로 구현함으로써, 테스트 시간 단축, 인력 투입 비용 최소화

① 정적 분석 도구(Static Analysis Tools)

• 만들어진 APP을 실행하지 않고 분석하는 도구
• 소스 코드에 대한 코딩 표준, 코딩 스타일, 코드 복잡도 및 남은 결함 발견을 위해 사용
• 테스트를 수행하는 사람이 작성된 소스 코드에 대한 이해를 바탕으로 도구를 이용하여 분석

② 테스트 실행 도구(Test Execution Tools)

• 테스트를 위해 작성된 스크립트 실행, 각 스크립트 마다 특정 데이터와 테스트 수행 방법 포함
• 데이터 주도 접근 방식 : 테스트 데이터
• 키워드 주도 접근 방식 : 테스트 수행 동작 키워드

③ 성능 테스트 도구(Performance Test Tools)

• APP의 처리량, 응답 시간, 경과 시간, 자원 사용률에 대해 가상의 사용자를 생성하고 테스트를 수행

④ 테스트 통제 도구(Test Control Tools)

• 테스트 계획 및 관리를 위한 테스트 관리 도구
• 테스트 수행에 필요한 데이터와 도구를 관리하는 형상 관리 도구
• 테스트에서 발생한 결함에 대해 관리하거나 협업을 지원하기 위한 결함 추적/관리 도구

⑤ 테스트 하네스

• APP 컴포넌트 및 모듈을 테스트하는 환경의 일부분, 테스트 지원 코드 및 데이터, 단위 또는 모듈 테스트에 사용하기 위해 코드 개발자가 작성

  구성요소	설명
  테스트 드라이버 (Test Driver)	테스트 대상 하위 모듈 호출, 파라미터 전달, 테스트 수행 후 결과 도출 등 상향식 테스트에 필요
  테스트 스텁 (Test Stub)	제어 모듈이 호출하는 타 모듈의 기능을 단순히 수행하는 도구로 하향식 테스트에 필요
  테스트 슈트 (Test Suites)	테스트 대상 컴포넌트나 모듈, 시스템에 사용되는 테스트 케이스 집합
  테스트 케이스 (Test Case)	입력값, 실행 조건, 기대 결과 등의 집합
  테스트 시나리오 (Test Scenario)	테스트 되어야 할 기능 및 특징, 테스트가 필요한 상황 작성 문서, 여러 개 테스트 케이스 포함 가능
  테스트 스크립트 (Test Script)	자동화된 테스트 실행 절차에 대한 명세
  목 오브젝트 (Mock Object)	사용자의 행위를 조건부로 사전에 입력해 두면, 그 상황에 예정된 행위를 수행하는 객체