10-1. 어플리케이션 테스트 케이스 설계

---

1. 어플리케이션 테스트 케이스 작성

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

• 소프트웨어 테스트

  • 어플리케이션이나, 사용자가 요구하는 기능과 성능, 사용성, 안정성을 만족하는지 확인
  • 노출되지 않은 소프트웨어 결함을 찾아내는 활동

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

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

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

💡 소프트웨어 테스트 원리

• 결함 존재 증명 : 테스트는 결함이 존재함을 밝히는 활동, 결함이 없다는 것은 증명 ❌
• 완벽 테스팅은 불가능 : 무한 입력값으로 완벽한 테스트는 어려움
• 초기 집중 : 개발 초기에 체계적인 분석을 하면, 테스팅 기간 단축 가능
• 결함 집중 : 파레토 법칙의 내용인 적은 수의 모듈(20%)에서 결함 (80%) 발견
• 살충제 패러독스 : 동일한 테스트 케이스에 의한 반복적 테스트는 새로운 버그 발견 ❌
• 정황 의존성 : 소프트웨어의 성격에 맞게 테스트를 수행해야함
• 오류-부재의 궤변 : 요구사항을 충족시켜주지 못하면, 품질이 높은 건 아님

💡 소프트웨어 테스트 산출물

• 테스트 계획서 : 테스트 목적과 범위 정의, 구조 파악, 수행 절차 등 테스트 수행을 계획
• 테스트 베이시스 : 테스트 설계를 위해 기준이 되는 문서 (요구사항 명세서)
• 테스트 케이스 : 설계된 입력값, 실행 조건, 기대 결과로 구성된 테스트 항목의 명세서
• 테스트 슈트 : 실행 환경에 따라 구분해 놓은 테스트 케이스의 집합
• 테스트 시나리오 : 테스트 되어야 할 기능 및 특징, 테스트가 필요한 상황을 작성
  • 단일 시나리오에서, 여러 개의 테스트 케이스를 포함
• 테스트 스크립트 : 테스트 케이스의 실행 순서를 작성한 문서
  • 특정 기능에 대한 상세 절차 / 테스트 스크립트 - 개략적
• 테스트 결과서 : 테스트 프로세스를 리뷰하고, 결과를 평가하고 리포팅

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

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

  • 정적 테스트 : 대상을 실행하지 않고, 구조 분석, 논리성 검증
  • 동적 테스트 : 소프트웨어 실행하고, 테스트를 수행하며 결함 검출

• 테스트 기법에 따른 분류

  • 화이트 박스 테스트
    - 응용 프로그램의 내부 구조와 동작 검사
    - 코드 분석과 프로그램 구조에 대한 지식 바탕, 결함 발생 가능성이 있는 모듈 테스트

    💡 화이트 박스 테스트 유형 ⭐구결조 조변다 기제데루

    • 구문 커버리지 : 모든 명령문을 적어도 한번 수행
    • 결정 커버리지 : 분기의 전체 조건식이 적어도 한번은 참과 거짓의 결과 수행
      • (x < 30 and y > 30) → 전체 조건식 참/거짓
    • 조건 커버리지 : 분기의 개별 조건식이 적어도 한번은 참과 거짓의 결과 수행
      • (x < 30) and (y > 30) → 각각 참/거짓 만족
    • 조건/결정 커버리지 : 전체 조건식 뿐만아니라 개별 조건식도 참 거짓 결과
      • (x < 30 and y > 30) / (x < 30) and (y > 30) → 모두 참 거짓
    • 변경 조건/결정 커버리지 : 개별 조건식이 다른 개별 조건식에 영향을 받지 않고, 전체 조건식에 독립적으로 영향을 주도록 함
    • 다중 조건 커버리지 : 모든 개별 조건식의 모든 가능한 조합을 100% 만족
      • (x < 30) and (y > 30) → (T,T) / (T,F) / (F,T) / (F,F)
    • 기본 경로 커버리지 : 수행 가능한 모든 경로 테스트
      • 맥케이브 순환복잡도 : V(G) = E-N+2 (간선-노드+2) / V(G) = P+1 (조건 분기문)
    • 제어 흐름 테스트 : 제어 구조를 그래프 형태로 나타냄. 내부 로직 테스트
    • 데이터 흐름 테스트 : 데이터 사용현황을 추가한 그래프
    • 루프 테스트 : 반복 구조에 초점을 맞춰 실시하는 테스트 기법

  • 블랙박스 테스트
    - 기능 및 동작 위주, 내부 구조를 알지 못해도 가능

    💡 블랙박스 테스트 유형 ⭐ 동경결상 유분페원비오

    • 동등 분할 테스트 : 데이터의 영역을 유사한 도메인 별로 유효값/ 무효값을 그룹핑
    • 경계값 분석 테스트 : 경계값을 포함하여 테스트 케이스 설계, MIN 위, MAX 아래
    • 결정 테이블 테스트 : 요구사항의 논리와 발생조건, 테이블 형태로 나열, 모두 조합
    • 상태 전이 테스트 : 객체의 상태를 구분, 상태 전이 경우의 수 테스트
    • 유스케이스 테스트 : 유스케이스로 모델링, 프로세스 흐름을 기반으로 테스트 명세
    • 분류트리 테스트 : SW 전체를 트리 구조로 분석 및 표현, 테스트 진행
    • 페어와이즈 테스트 : 데이터를 가능한 한 번씩 조합, 상대적 적은 양의 테스트 구성
    • 원인-결과 그래프 테스트 : 그래프를 활용하여, 데이터 간의 관계 및 출력의 영향
    • 비교 테스트 : 여러 버전의 프로그램에 같은 값을 넣어 테스트, 값 비교
    • 오류 추정 테스트: 개발자가 범할 수 있는 실수 추정, 결함이 검출 되도록 테스트

• 테스트 시각에 따른 분류

  • 검증 : 개발 과정을 테스트, 개발 규격과 요구를 충족시키는지 판단
  • 확인 : 소프트웨어 결과 테스트, 제대로 동작하는지 확인

• 테스트 목적에 따른 분류

  • 회복 테스트 : 실패를 유도하고, 시스템 정상적 복귀 여부 테스트
  • 안전 테스트 : 소스 코드 내 보안적 결함을 미리 점검하는 테스트 기법
  • 성능 테스트 : 시스템이 응답하는 시간, 처리 업무량 , 반응하는 속도 등을 테스트
  • 구조 테스트 : 내부 논리 경로, 소스 코드의 복잡도 평가
  • ⭐회귀 테스트 : 코드 수정에 의해 새롭게 유입된 오류가 없는지 일종의 반복 테스트 기법
  • 병행 테스트 : 변경된 시스템과 기존 시스템에 동일한 데이터를 입력 후 결과 비교

• 성능 테스트 상세 유형

  • 부하 테스트 : 부하를 계속 증가시키면서, 시스템의 임계점 찾기
  • 강도 테스트 : 임계점 이상의 부하를 가하여 비정상적인 상황에서 시스템 동작 상태 확인
  • 스파이크 테스트 : 짧은 시간에 사용자가 몰릴 때 시스템의 반응 측정
  • 내구성 테스트 : 오랜 시간동안 높은 부하를 가하여 시스템의 반응 테스트

(3) 정적 테스트

• 리뷰 : 소프트웨어의 진행 상황 점검하기 위한 활동

  • 동료 검토 : 2~3명 진행, 작성자가 요구사항 명세를 설명하고, 이해관계자가 결함 발견
  • 인스펙션 : 코드를 작성하지 않은 다른 전문가가 문제를 찾아내는 방식
  • 워크 스루 : 검토 자료를 회의 전에 배포, 사전 검토 후 짧은 시간동안 회의 진행

• 정적 분석 : 자동화된 도구 이용, 산출물의 결함 검출, 복잡도

  • 코딩 표준 부합, 코드 복잡도 계산, 자료 흐름 준석

(4) 동적 테스트

• 화이트박스 테스트
  • 구조 기반 테스트, 코드 기반 테스트, 로직 기반 테스트, 글래스 박스 테스트라고도 불림
  • 테스트 커버리지 : 테스트 수행의 완벽성 측정 도구, 테스트 품질 측정 기준
    • ⭐ 기라코 → 기존 라인은 코발트 색으로 칠함
    • 기능 기반 커버리지 : 전체 기능을 모수로 설정, 수행된 기능의 수 측정
    • 라인 커버리지 : 라인 수를 모수로 설정, 테스트 시나리오가 수행한 코드의 라인 수 측정
    • 코드 커버리지 : 소스 코드의 구문, 조건, 결정, 구조 코드 자체가 얼마나 테스트 되었나
      • 일반적 테스트 커버리지는 코드 커버리지
  • 테스트 커버리지의 구정
    • 구문, 결정, 조건, 결정 포인트(분기 노드)
  • 구문 커버리지 : 모든 명령문을 적어도 한번 수행
  • 결정 커버리지 : 결정 포인트 내에 전체 조건식이 적어도 적어도 한 번 참, 거짓 결과 수행

    if x>1 or y>3:
    	z *= x
    	
    if x<2 or y>1:
    	z += 1

    테스트 케이스	(x>1) or (y>3)	x<2 or y>1
    x=1.5, y=2, z=2	T	T
    x=3, y=2, z=1	T	F
    x=1, y=3, z=3	F	T

    → 순서대로 수행한다면 모든 테스트 케이스를 수행해야 결정 커버리지 만족함
  • 조건 커버리지 : 결정 포인트 내의 개별 조건식이 적어도 한번은 참, 거짓의 결과 수행 (코드는 위와 동일) → 테스트 케이스 순차적 수행

    테스트 케이스	x > 1	y > 3	x < 2	y > 1
    x=3, y=0.5, z=2	T	F	F	F
    x=1, y=3, z=3	F	F	T	T
    x=0.5, y=4, z=1	F	T	T	T

    → y > 3 부분에서 테스트 케이스 3번째까지 가야 조건 커버리지 만족
    

• 블랙박스 테스트

  • 동등분할 테스트 : 유사한 도메인 별로 유효값/무효값 그룹핑
    • 구간 별의 대표값을 선정해서 테스트 진행함
    1. 사전 고려
    2. 동일한 출력 결과를 가지는 입력 조건 식별
    3. 동등 클래스 분할
    4. 동등 클래스의 대표값 선정
       
       
  • 경계값 분석 테스트 : 경계값을 포함하여 테스트 케이스 설계
    • 2 - value : 경계에 있는 값 / 위 또는 아래 중 하나의 값
    • 3 - value : 경계에 있는 값 / 위의 값 / 아래 값
      
      
  • 결정 테이블 테스트 : 요구사항의 논리와 발생조건을 테이블 형태로 나열
    • 조건과 행위를 모두 조합하여 테스트
      
      
  • 상태 전이 테스트 : 어느 한 상태에서 다른 상태로 전이되는 경우의 수를 테스트
    • 상태 전이도로 모델링
      
      
  • 유스케이스 테스트 : 프로세스 흐름을 기반으로 테스트 케이스 명세화
  • 분류 트리 테스트 : SW의 전체를 트리 구조로 분석 및 표현
    • 동등분할 영역을 구분하는 것과 유사함
  • 페어와이즈 테스트 : 테스트 데이터값들 간에 최소한 한번씩 조합하는 방식
  
  

• 경험 기반 테스트

  • 탐색적 테스트 : 테스트 케이스를 문서로 작성하지 않고 경험에 바탕을 두고 기능 수행
    • 테스트를 수행하며 테스트 대상 이해, 설계, 실행을 병행함
  • 오류 추정 : 개발자의 실수를 추정, 결함이 검출되도록 테스트 케이스 설계
  
  

(5) 테스트 케이스

• 특정 요구사항에 준수하는지를 학인하기 위해 개발된 입력 값, 실행 조건, 예상된 결과

• 공통 작성 항목 요소

  • 테스트 단계명, 작성자, 송인자, 작성 일자, 대상 시스템, 변경 여부, 테스트 범위 등..

• 개별 작성 항목 요소

  • 테스트 ID, 테스트 목적, 테스트할 기능, 테스트 데이터, 예상 결과, 테스트 환경
  • 테스트 조건, 성공/실패 조건, 기타 요소
  
  

(6) 테스트 오라클

• 사전에 정의된 참값을 입력하여 비교하는 기법
• 종류
  • 참 오라클 : 모든 입력값에 대하여 결과 생성, 발생된 오류를 모두 검출 가능
  • 샘플링 오라클 : 특정한 몇 개의 입력값에 대해서만 결과 제공
  • 휴리스틱 오라클 : 특정 입력 값에 대해 결과 제공, 일부는 휴리스틱(추정) 함
  • 일관성 검사 오라클 : 어플리케이션 변경 시, 수행 전과 후의 결과 값이 같은지 확인

2. 어플리케이션 테스트 시나리오 작성

(1) 테스트 레벨

• 태스트 레벨은 함께 편성되고 관리되는 테스트 활동의 그룹

• 테스트 레벨 종류

  • V 모델과 테스트 레벨
    • 요구 사항 분석 - 인수 테스트
    • 기계 명세 분석 - 시스템 테스트
    • 설계 - 통합 테스트
    • 개발 - 단위 테스트
  • 테스트 레벨 종류
    • 단위 테스트 : 단위 모듈, 서브루틴 등을 테스트하는 단계
      • 블랙박스 박스, 화이트박스 테스트 (주로 화이트박스 테스트 함)
    • 통합 테스트 : 통합된 컴포넌트 간의 상호 작용을 검증하는 테스트
    • 시스템 테스트 : 통합된 단위 시스템이 시스템에서 정상 작동하는지 테스트
    • 인수 테스트 : 요구사항이 만족되었는지 확인하는 테스트
      • 알파 테스트 : 개발자 환경에 통제된 환경에서 개발자와 함께하는 인수 테스트
      • 베타 테스트 : 실제 환경에서 사용자가 사용하고 피드백 받는 인수 테스트
  
  

(2) 테스트 시나리오

• 여러 테스트 케이스의 집합, 테스트 케이스의 동작 순서를 기술한 문서

10-2. 어플리케이션 통합 테스트

---

1. 어플리케이션 테스트 수행

(1) 단위 테스트

• 단위 테스트 개념

  • 개별적인 모듈을 테스트함, 구현 단계에서 각 모듈을 구현한 후 수행함.

• 단위 테스트 수행 도구

  • 테스트 드라이버 : 하위 모듈을 호출하는 상위 모듈 역할, 인자를 통해 넘겨줌, 결과 값 전달
  • 테스트 스텁 : 상위 모듈에 의해 호출되는 하위 모듈의 역할, 시험용 모듈
  
  

(2) 통합 테스트 개념

• 단위 테스트가 끝난 모듈에 대해서 설계 단계에서 제시한 기능으로 구현되었는지 확인

• 통합 테스트 방식

  1. 하향식 통합 테스트 : 상위 모듈에서 하위 모듈 방향으로 통합하면서 테스트, 스텁 사용
  2. 상향식 통합 테스트 : 하위 모듈에서 상위 모듈 방향으로 통합하면서 테스트, 드라이버 사용
  3. 빅뱅 통합 테스트 : 모든 모듈을 동시에 통합 후 테스트, 실제 모듈로 테스트
  4. 샌드위치 통합 테스트 : 상향식과 하향식을 결합함, 병렬 테스트 가능
  
  

(3) 테스트 자동화 도구

• 테스트 도구를 활용하여 반복적인 테스트 작업을 스크립트 형태로 구현

• 테스트 자동화 도구의 장단점

  • 장점
    • 테스트 재입력 작업의 자동화
    • 사용자 요구 기능의 일관성 검증에 유리
    • 테스트 결괏값에 대한 객관적인 평가 기준 제공
    • 테스트 결과의 통계 작업과 그래프 등 다양한 표시 혀애 제공
  • 단점
    • 도구 도입 후 도구 사용 방법에 대한 교육 및 학습 필요
    • 도구를 프로세스 단계 별로 적응하기 위한 시간, 노력 필요
    • 상용 도구의 경우 고가, 유지 관리 비용이 높아 추가 투자 필요

• 테스트 자동화 도구 유형

  • 정적 분석 도구
    • 어플리케이션을 실행하지 않고 분석하는 도구
    • 소스 코드에 대한 코딩 표준, 코딩 스타일, 코드 복잡도 및 남은 결함 발견
  • 성능 테스트 도구
    • 어플리케이션 처리량, 응답시간, 경과시간, 자원 사용률 에 대한 성능 목표 테스트
  
  

• 테스트 하네스

  • 테스트를 자동화하거나 제어하기 위한 코드 및 도구의 집합
  • 구성요소
    • 테스트 드라이버 / 테스트 스텁
    • 테스트 슈트 : 테스트 케이스의 집합
    • 테스트 케이스
    • 테스트 시나리오 : 테스트가 되어야 할 기능이나 상황을 작성한 문서
    • 테스트 스크립트 : 자동화된 테스트 실행 절차에 대한 명세
    • 목 오브젝트 : 사용자의 행위를 조건부로 사전에 입력해 두면, 행위 수행

• 결함 : 개발자가 설계한 것과 다르게 동작하거나 다른 결과가 발생하는 현상

  • 결함 관련 용어
    • 오류 : 결함의 원인이 되는 것, 일반적으로 사람에 의해 생성된 실수
    • 결점 : 개발 활동을 수행함에 있어서, 시스템이 고장을 일으키게 함
    • 버그 : 프로그램 오류로 인해 예상치 못한 결과가 나는 현상
    • 고장 / 문제 : 결함이 실행될 때 발생하는 현상
  
  
  

10-3. 어플리케이션 성능 개선

---

1. 어플리케이션 성능 분석

(1) 어플리케이션 성능 점검 개요

• 어플리케이션 성능 측정 지표

  ⭐ 처응경자 : 처의 응원을 받은 경호 자원봉자사

  • 처리량 : 주어진 시간에 처리할 수 있는 트랜잭션의 수, 웹의 경우 시간당 페이지 수
  • 응답시간 : 사용자 입력 후, 어플리케이션의 응답 출력이 개시될 때까지의 시간
  • 경과 시간 : 요구를 입력한 시점 부터, 트랜잭션을 처리, 결과의 출력이 완료할 때까지 시간
  • 자원 사용률 : 트랜잭션을 처리하는 동안 사용하는 CPU, 메모리, 네트워크 사용량

• 유형별 성능 분석 도구
  - 성능/부하/스트레스 점검 도구 : 성능 점검을 위해 가상의 사용자를 점검 도구 상에서 테스트
  - 모니터링 도구 : 어플리케이션 실행 시, 자원 사용량 확인하고 분석 가능한 도구
  - 성능 모니터링, 성능 저하 원인 분석, 시스템 부하량 분석 등을 지원하는 도구
  
  

2. 어플리케이션 성능 개선

(1) 소스코드 최적화

• 소스 코드 최적화

  • 읽기 쉽고 변경 및 추가가 쉬운 클린 코드를 작성하는 것

• Bad Code : 개발자가 로직을 이해하기 어렵게 작성한 코드, 서로 얽혀 있는 스파게티 코드 등

  • 외계인 코드 : 오래되거나 참고문서 또는 개발자가 없어 유지보수 작업이 어려운 코드
  • 스파게티 코드 : 사람이 읽으며 작동을 파악하기 어려운 코드

• Clean Code : 가독성이 높고, 단순, 의존성을 줄이고, 중복을 최소화

  • 중복 코드 제거로 어플리케이션 설계가 개선
  • 가독성이 높으므로 어플리케이션의 기능에 대해 쉽게 이해할 수 있다.
  • 작성 원칙 ⭐ 가단의 중추 : 가구 단지는 중추절에 논다
    • 가독성 : 이해하기 쉬운 용어를 사용, 코드 작성 시 들여쓰기 기능을 사용
    • 단순성 : 한 번에 한 가지 처리만 수행, 클래스/메소드/함수를 최소 단위로 분리
    • 의존성 최소 : 영향도를 최소화, 코드의 변경이 다른 부분에 영향이 없게 작성
    • 중복성 제거 : 중복된 코드를 제거, 공통된 코드를 사용
    • 추상화 : 클래스/메소드/함수에 대해 동일한 수준의 추상화 구현

• 리팩토링 : 기능을 변경 ❌, 복잡한 소스 코드를 수정, 보완하여 가용성 및 가독성을 높이는 기법

  • 목적
    • 유지 보수성 향상 / 유연한 시스템 / 생산성 향상 / 품질 향상

(2) 소스 코드 품질 분석

• 소스코드에 대한 코딩 스타일, 설정된 코딩 표준, 코드의 복잡도, 메모리 누수 현황등을 발견
• 정적 분석 도구 : 코드를 실행하지 않고, 코드 자체만으로 결함을 발견
• 동적 분석 도구 : 코드를 실행하여. 메모리 누수나 스레드 결함 분석