본문 바로가기

💻 개발IT/기타

CSTS 요약 1 - 테스트 개요

테스트 개요는 총 7장으로 이루어져 있다.

(7장 내 겹쳐진 내용이 많아 여기선 3장으로 요약하였다)

 

1. 테스트 개요

테스트 목적

  • 결함 검출
  • SW 품질 개선
  • SW 품질 평가
  • SW에 대한 의사 결정 지원 (품질 평가 결과 기반)
  • 개발 프로세스 개선 지원 (개발 단계의 결함 분석하여 개선)

 

오류, 결함, 장애

  1. 오류
    • 결함을 생기게 한 "개발자의 행위"
      ex) 사용자의 요구사항을 잘못 이해, 오타, 문법 잘못 이해 등
  2. 결함
    • 장애를 유발할 수 있는 문제
    • 결함 때문에 장애 발생하지만 결함이 있다하여 반드시 장애가 발생하는 것은 아님
    • 3가지 결함 종류
      1. 누락 : 요구사항(기능/성능/보안 등 품질 요소도 포함)에 대한 누락  ex) 요구사항이 구현되지 않음
      2. 부정확한 구현 : 요구사항이 부정확하게 반영 
      3. 비관련 결함 : 요구사항과 무관한 구현
    • 소스 코드 뿐만 아니라 개발 산출물에도 존재  ex) 설계 결함
  3. 장애 : SW 실제 동작과 요구사항에 (관찰 가능한) 차이가 있음

 

테스팅, 디버깅, 재테스팅

  1. 테스팅 : SW 실제 동작과 요구사항과의 차이를 확인. 외부
  2. 디버깅 : 테스팅을 통해 결함 확인 후 수행되고, 결함 위치를 파악하고 제거하는 행위. 내부 관련자가 수행
  3. 재테스팅 : 실제로 결함이 제거되었는지 초기와 동일한 TC를 통해 확인

 

테스트의 진화 과정

5개의 레벨로 나누어져 있음

  • 레벨 1 : 테스트와 디버깅에 뚜렷한 차이 없어 우연히 발견된 결함 정도 수정
  • 레벨 2 : SW가 올바르게 동작한다는 사실 입증을 위해 테스트 수행
  • 레벨 3 : 결함이 있다는 것을 보여주기 위해 테스트 수행
  • 레벨 4 : 코드 뿐만 아니라 SW 개발 전 단계에서 결함 발견 위해 평가
  • 레벨 5 : 결함을 예방하고 테스트 용이하도록 SW 설계 (TDD)

 

테스트와 품질 평가

SW 품질을 평가(비기능 테스트)할 때 주로 보는 유형

기능 적합성 요구한 기능 만족시켰는지?
성능 효율성 자원 사용이 적절했는지? 반응시간 괜찮은지?
호환성 다른 SW 연동 능력
사용성 사용자가 SW 이해하기 쉬운지? 만족하는지?
신뢰성 정해진 조건/기간 동안 오동작 없는지?
보안성 데이터 안전한지?
유지보수성 운영 용이한지?
이식성 다양한 플랫폼에서 운영될 수 있는지?

1. 기능 적합성 

  • 기능 완전성 : 모든 요구사항을 제공하는가? (명세 기반 테스트)
  • 기능 정확성 : 정확한 결과를 제공하는가? (명세/구조 기반 테스트)
  • 기능 적절성 : 기능이 목적 달성에 도움을 주었는가?

2. 성능 효율성 - 시간 반응성, 자원 효율성, 수용성(동시 사용자 수, 트랜잭션 처리량 등의 최대 한계가 충족하는가?)

  • 성능 테스트 방법
    • 벤치마크(Benchmark) 테스트 : 다른 SW과 성능을 비교/평가
    • 부하 테스팅 : 부하를 계속 증가시쳐 임계점을 찾음
    • 스트레스 테스팅 : 임계점 이상의 부하를 가하면서 기능/처리 등을 테스트
    • 스파이크 테스팅 : 짧은 시간에 사용자가 몰릴 때 시스템 반응 테스트
    • 내구성 테스팅 : 오랜 시간 동안 높은 부하를 가하여 반응 테스트
  • 리틀의 법칙(Little's law) : SW에 오랜기간 있는 고객의 평균 수치 = 오랜 시간동안 걸친 평균 실제 도착률 * 시스템에서 고객이 머문 평균 시간
    • 목표 처리량에 요구되는 동시 사용자 수를 산정할 때 사용

3. 호환성

  • 공존성 : 다른 SW와 효율적으로 자원을 공유하면서 기능 수행하는가?
  • 상호운영성 : 정보를 교환하고 교환된 정보를 사용할 수 있는지?

4. 사용성

  • 적합 인식성 : 사용자가 필요한 시스템인지?
  • 학습 용이성 : 배워서 쓸 수 있는지?
  • 운영 용이성 : 시스템을 쉽게 조작할 수 있는지?
  • 사용자 오류 방지성
  • 사용자 인터페이스 심미성
  • 접근성 : 사용자 특성이나 능력(연령, 장애 등) 관계없이 시스템 사용할 수 있는지?


  • 사용성 테스트 방법 - 휴리스틱 평가(전문가가 체크리스트 통해 문제점 도출), FGI(그룹 인터뷰), 인지적 워크쓰루(교육없이 SW 사용하는 것 확인)
  • 사용성 테스트는 시스템 개발의 전 주기에 걸쳐 진행되어야함

5. 신뢰성

  • 성숙성 : 정상 작동 상태에서 신뢰성 충족시키는 정도
  • 가용성 : 사용자가 시스템 사용하고자 할 때 사용 및 접근이 가능한 정도
  • 결함 허용성 : 결함이 있어도 시스템이 의도대로 작동하는 정도
  • 복구성 : 장애 나도 데이터 복구하고 상태를 재설정할 수 있는지?


  • 신뢰성 테스트 방법 - 통계적 테스트(운영 프로파일 사용하여 TC 생성)

6. 보안성 - 기밀성, 무결성(데이터 변경/접근 방지), 부인 방지성, 책임성(사용자 행위 기록하여 추적), 인증성

  • 보안성 테스트 방법 - 침입 테스트(해커 관점에서 취약성 찾기), 정적 분석

7. 유지보수성 - 모듈성, 재사용성, 분석성(결함 분석 등), 변경 용이성, 테스트 용이성

  ※ 테스트 용이성 - 제어 용이성, 관찰 가능성(내부상태 파악), 단순성, 분할 용이성, 운영용이성(결함있어도 테스트 가능하도록 설계), 안정성(테스트 동안 변경 자주 없도록 설계), 이해 용이성(설계 조직/쉽게 접근 가능하도록) 

 

8. 이식성 - 적응성, 설치 용이성, 대체 용이성

 

 

테스트와 품질 보증

테스트 < V&V(Verification검증&Validation확인) < 품질 보증

더보기

※ V&V

  • 검증 : 시스템이 명세를 만족하는지 검사 = 시스템을 올바르게 만들고 있니?
  • 확인 : 시스템이 사용자의 요구사항을 만족하는지 검사 = 우리가 올바른 시스템을 만들고 있니?

 

 

 

테스트 기본 용어

  • 테스트 대상 : 결함을 검출하려는 SW로 규모가 클수록 어려워 일부분 먼저 테스트 후 통합테스트 진행
  • 피처 : 테스트 대상 중 테스트하고자 하는 측면 or 관점으로 이를 기준으로 TC 및 테스트 절차 개발
  • 테스트 설계 기법 
    • 정적 테스트 : 실행 하지 않고 테스트  ex) 리뷰, 정적 분석
      • 장점 : 실행환경 불필요, 산출물에 대한 테스트 가능, 소스 코드 작성 후 디버깅하는 것보다 경제적, 테스트 자동화 가능 
    • 동적 테스트 : SW 실행하여 테스트  ex) 명세 기반 방법, 구조 기반 방법, 경험 기반 테스트
      • 장점 : 소스 코드가 없어도 테스트 가능
  • 테스트 케이스 : 입력과 예상 결과의 묶음
  • 테스트 절차 : 말 그대로 테스트 준비/실행/결과 관찰 및 기록하는 테스트 절차
  • 테스트 환경 : 테스트 대상을 실행하는 모든 환경  
    ex) 외부 연동 시스템, 테스트 도구, 운영체제 포함한 시스템 SW, 공존하는 응용SW 등

 

 

 

2. 테스트 분류와 테스팅 방법

테스트 분류

테스트는 1 테스트 레벨, 2 테스트 유형, 3 테스트 설계 기법에 따라 분류 가능

 

  1. 테스트 레벨로 분류 - 컴포넌트(단위) 테스트, 통합테스트, 시스템 테스트, 인수 테스트
    • 컴포넌트(단위)테스트 : 개별 단위 모듈을 독립적으로 테스트
      • 모듈을 단독으로 실행할 수 있는 환경 필요 → 모듈을 테스트할 때 다른 연관되는 모듈은 스텁으로 이용

        ※ 테스트 베드 : 테스트 환경
        • 테스트 드라이버, 테스트 스텁
        • Mock(모의) 객체 : 스텁의 객체지향 버전. 
      • 다른 레벨 테스트보다 쉽게 수행 + 결함을 쉽게 식별 + 테스트 수행에 따른 피드백 빠름
      • 컴포넌트 테스트를 잘 수행하기 위한 FIRST 원칙
        • Fast : 빠르게 수행되어야 함 (모의 객체 등을 이용하여 시간 단축)
        • Isolated : 테스트가 다른 컴포넌트 테스트에 의존하지 않아야함
            → 전체 테스트 집합 실행해도 개별적으로 실행한 결과와 달라서는 안 됨
        • Repeatable : 몇 번 실행해도 동일한 결과 
        • Self-Validating : 사람 개입 없이 테스트가 통과되었는지 알 수 있어야함 
        • Timely : 테스트는 코드가 작성되는 시점에 수행되어야함 
    • 통합 테스트 : 모듈과 이들 간의 관계들(인터페이스) 테스트. 구조 설계 명세서 기반으로
      • 통합테스트 방법 
        • 빅뱅 방식 : 통합해야할 컴포넌트가 많은 경우, 전체 컴포넌트를 한 번에 통합하여 테스트
        • 점진적 방식 : 적은 수의 컴포넌트를 차례로 통합하여 테스트
          • 상향식 통합 : 하위 컴포넌트 먼저 테스트하여 상위에 있는 컴포넌트들을 통합. 
          • 하향식 통합 : 상위 컴포넌트부터 시작하여 하위에 있는 컴포넌트 통합 (스텁 필요. 리그레이션 테스트 진행)
          • 샌드위치 통합 : 상향식 + 하향식
      • 2가지 목적
        • 컴포넌트 간 연결의 정확성
        • 연결된 두 컴포넌트의 기능적 측면 확인
    • 시스템 테스트 : 시스템이 명세에 따라 개발되었는지 전체 테스트. 요구사항 명세서 기반으로 기능 + 비기능 요구사항 모두 확인
    • 인수 테스트 : 시스템 테스트와 동일하나 인수 테스트는 고객/사용자의 관점에서 SW가 동작하는지 확인. 보통 고객 또는 사용자가 테스트
      • 알파 테스트 : 선별된 사용자가 개발자 환경에서 통제된 상태로 수행
      • 베타 테스트 : 일정 수의 사용자에게 SW를 사용하게 하고 피드백 받음. 보통 개발자 참여 X
  2. 테스트 유형으로 분류 - 기능 테스트, 비기능 테스트
    • 기능 테스트 : 기능 측면 테스트. 모든 테스트(컴포넌트/통합/시스템/인수 테스트)에서 진행
    • 비기능 테스트 : 품질 요구사항 측면 테스트. 보통 시스템/인수 테스트에서 진행 
  3. 테스트 설계 기법으로 분류 - 정적 테스트, 동적 테스트
    • 정적 테스트 : 실행하지 않고 테스트
      • 리뷰 : 산출물에 존재하는 결함 검출 or 프로젝트 진행상황 점검. 보통 전문가 그룹이 수행
        ex) 관리 리뷰, 기술 리뷰, 인스펙션, 워크 쓰루, 감사 
      • 정적 분석 : 산출물(주로 코드)의 구조적 속성을 이용하여 자동화된 방식으로 수행
    • 동적 테스트 : 실행하여 테스트
      • 명세 기반 테스트 : 코드를 참고하지 않고 명세를 통해 TC 결정. 명세 정보가 있는 전 단계에서 사용
      • 구조 기반 테스트 : 코드 참고하여 TC 결정
      • 경험 기반 테스트 : 경험 바탕으로 테스트      ex) 오류 추정, 탐색적 테스트 등

 

테스팅 방법 

대표적인 테스트 수행 방법 

  • 리그레션 테스트 : SW 변경 후에 수행되는 테스트로 변경이 결함을 만들었는지 요구사항 충족하는지 검증
    • 개발 단계에서 사용된 TC 그대로 이용
    • 컴포넌트 테스트, 통합 테스트, 시스템 테스트, 유지보수 등 모든 단계에서 수행
    • 리그레션 테스트 방법
      1. Retest-All : 기존에 개발된 모든 TC 사용. but 너무 많은 시간 자원 필요
      2. 선택석 리그레션 테스트 : 결과가 다르게 나올 수 있는 TC만 일부만 선정하여 테스트  
      3. 테스트 최소화 : 커버리지 통해 중복된 TC 제거하여 테스트 수를 줄이기 
      4. 테스트 우선순위화 : ADFD 방식을 사용하여 TC에 우선순위를 두어 높은 것만 활용 
        ※ ADFD 방식 = 테스트 케이스 실행 수 대비 검출된 결함의 비율
                                 테스트 케이스 수, 결함 수, 실행 순서로 계산
  • 소프트웨어 생명 주기 모델과 테스트
    1. 순차적 개발 모델 : 요구사항이 초반에 완전하게 정의되어있을 때 사용
      • 폭포수 모델
        • 가장 오래된 전통적인 모형
        • 요구사항 분석 → 구조 설계 → 상세 설계 → 코딩 → 테스팅 → 운영
        • 장점 : 개발 과정 후 테스트를 하기 때문에 테스트 작업에 필요한 정보 쉽게 얻음. 
        • 단점 : 전체 프로젝트의 비용 및 일정에 심각한 영향 (개발 중심 모델 : 테스트를 코딩 이후의 한 단계로만 생각)
      • V-모델
        • V = V&V
        • 폭포수와 달리 테스트를 개발과 동등하게 취급 → 테스트 계획 및 설계는 개발 시작됨과 동시에 시작
        • 개발 단계별 테스트 유형이 대응하여 정의 
          (요구사항 ↔ 인수 테스트, 요구사항 분석  시스템 테스트, 구조설계  통합 테스트, 상세설계  단위 테스트) 
    2. 진화적 개발 모델 : 요구사항이 명확하지 않을 때 적용 
      • 핵심 부분을 우선 개발 후, 추가 요구사항을 여러 이터레이션(Iteration)을 통해 개선 및 발전
      • 각 이터레이션마다 테스트 수행 계획 작성하여 수행
      • 나선형 모델 : 기술적으로 어렵거나 고객이 중요하게 생각하는 요구사항에 대해 우선 프로토타입 개발하고, 프로토타입에 대한 테스트 및 사용자의 평가를 거쳐 개발 주기 시작
    3. 애자일 개발 모델  ex) XP, TDD
  • 위험 기반 테스트 : 위험 수준이 높은 것들 우선 테스트 
    • 위험 분석
      1. 테스트가 필요한 피처들을 모두 나열하고 명확하고 구체적으로 기술
      2. 발생 가능성, 심각성, 긴급성(자주쓰는기능?) 바탕으로 위험도 산정
         - 위험도 = 장애가 발생할 가능성 * 영향도
      3. 피처 별로 테스트 강도 선택하여 테스트에 투입할 자원 비용 등을 결정
         - 고강도 테스트 > 균형적 테스트 > 부가적 테스트 > 결험 보고(가장 낮은 등급. 보통 테스트 범위 X)
      4. 테스트 레벨/유형 결정 (보통 고강도는 테스트 레벨 전체. 피처에 따라 기능/비기능 나눠짐)
      5. 테스트 대상 선정 
      6. 테스트 범위 설정 
      7. 테스트 전략 결정 : 위험 강도에 따라 테스트 설계 기법, 종료 기준, 재테스팅 및 리그레션 테스팅 여부 또는 방법 결정
      8. 테스트 설계/구현 및 테스트 환경 : 위험 수준에 따라 테스트 환경 구축하고 TC 설정
      9. 테스트 실행 및 결함 보고 : 위험 수준이 높은 테스트에서의 결함은 우선순위로 보고하여 재테스팅 수행
      10. 테스트 모니터링/제어 및 테스트 종료 : 위험 수준 높은 테스트는 상세하게 모니터링 수행하고 별도로 결과 보고 정리
    • 위험 관리 : 잠재 위험이 문제로 발현되기 전 대응책을 생각해 내는 과정
  • 모델 기반 테스트 : 모델(UML, 자연어, 순서도 등) 기반으로 자동으로 TC 생성

 

3.  테스트 자동화 

테스트 자동화

  • 도구를 사용하여 테스트 프로세스 일부 또는 전부를 자동화
  • 자동화를 위해 상당한 초기 투자 비용 발생

 

테스트 자동화 분야 및 테스트 도구

  1. 테스트 설계 도구 : TC 생성 도구
    • 명세 기반 테스트 설계 도구 : 명세서 기반으로 TC 생성
    • 구조 기반 테스트 설계 도구 : 코드 기반으로 TC 생성
  2. 테스트 환경 구축 도구 
  3. 테스트 실행 도구
  4. 이슈 관리 도구   ex) Jira

 

테스트 도구 선정

  • 요구사항 정의 → 도구 조사 → 도구 평가 → 파일럿 프로젝트 → 도구 선정 → 도구 도입

 

반응형