3. 테스트 분류 개요

​
​

3-1. 테스트 분류 개요

​

• 테스트 분류

  • 테스트 레벨

    • 단위(컴포넌트) 테스트
    • 통합 테스트
    • 시스템 테스트
    • 인수 테스트

  • 테스트 유형

    • 기능 테스트

    • 비기능 테스트

      • 성능 테스트
      • 보안 테스트
      • 신뢰도 테스트
      • etc

​

• 테스트 레벨에 의한 분류

  테스트 레벨	의미
  컴포넌트/단위 테스트	단위 모듈을 테스트 대상으로 하여 개별단위 모듈을 독립적으로 테스트
  통합 테스트 (Integration)	단위모듈이 정확하게 통합되었는지에 초점. 시스템내부 구성모듈과 이들간의 관계를 정의한 구조 설계 명세서를 바탕으로 테스트
  시스템 테스트	전체 시스템을 테스트 대상으로 하여 테스트. 요구사항 명세서에 명시된 방식으로 시스템이 동작하는지 확인
  인수 테스트 (Acceptance)	전체 시스템을 하나의 단위로 보고 테스트 진행. 시스템 테스트와 달리 고객/사용자 관점에서 고객이 기대하는 방식으로 작동하는지 확인

  ​
  • V모델 (=V&V 모델)
    

​

• 테스트 유형에 따른 분류

  • 테스트를 통해 확인하고자 하는 기준은 요구사항 명세서에 정의

    • 요구사항 명세는 기능 요구사항과 품질 요구사항을 포함

  • 비기능(Non-functional) 테스트

    • 성능 효율성 테스트, 신뢰성 테스트같이 개별 품질 특성에 초점을 두고 수행하는 테스트

  • 유형 테스트(Type test)

    • 기능 테스트와 각각의 비기능 테스트 (ISO 29119 표준)

    • 테스트 유형

      기능 테스트	결함 검출 및 충족 여부 확인 목적 모든 테스트 레벨에서 진행
      비기능 테스트	품질 요구사항 시스템 , 인수 테스트에서 진행

    • ISO 25010 품질 모델

      주특성	부특성
      기능 적합성	완전성 / 정확성 / 적절성
      신뢰성	성숙성 / 가용성 / 결함 허용성 / 복구성
      사용성	적합 인식성 / 학습 용이성 / 운용 용이성 / 사용자 오류방지성 사용자 인터페이스 심미성 / 접근성
      호환성	공존성 / 상호운영성
      성능 효율성	시간 반응성 / 자원 활용성 / 수용성
      보안성	기밀성 / 무결성 / 부인방지성 / 책임성 / 인증성
      유지보수성	모듈성 / 재사용성 / 변경 용이성 / 분석성 / 테스트 용이성
      이식성	적응성 / 설치 용이성 / 대치 용이성

• 테스트 설계 기법에 따른 분류

  정적 테스트와 동적 테스트로 분류
  정적 테스트 => [리뷰 / 정적 분석]
  동적 테스트 => [명세 기반 테스트 / 구조 기반 테스트 / 경험 기반 테스트]

  • 정적 테스트
    대상을 실행하지 않는 방식으로 테스트
    이는 동적 테스트 방법에서 검출하기 힘든 오류 검출 가능.
    개발 초기에 오류를 찾아내어 품질을 향상시키실 수 있으며,
    프로그램 개발 단계에서 산출되는 결과물에서 결함 검출 가능

    • 리뷰
      • 소프트웨어의 다양한 산출물에 존재하는 결함을 검출하거나
        프로젝트의 진행 상황을 점검하기 위한 활동으로,
        전문가 그룹이 수행
        • 관리 리뷰, 기술 리뷰, 인스펙션, 워크쓰루, 감사
    • 정적 분석
      • 산출물의 구조적 속성을 이용하여 자동화된 방식으로 도구에 의해서 수행
        • 코딩표준 , 복잡도측정 , 자료흐름 분석

    ​
    ​
    

  • 동적 테스트
    대상을 실행하여 결함을 검출하는 방법
    => 테스트 케이스 결정 필요

    • 명세 기반 테스트

      • 소스 코드를 참고하지 않고 테스트 케이스를 결정

        • 예를 들어 임의의 입력값을 생성하여 테스트하는 임의 테스트 방법도 소스코드를 이용하지 않으므로
          명세 기반 테스트

      • 시스템의 명세 정보를 얻을 수 있는 한, 적용 대상에 제한이 없으며
        단통시인 전 과정에 걸쳐 사용 가능

      • EX. 동등 분할, 분류 트리 기법, 경곗값 분석, 신택스 테스트, 조합 테스트, 상태 전이 테스트, 인과 그래핑,
        결정표 테스트, 시나리오 테스트

    • 구조 기반 테스트

      • 구현된 소스 코드를 참고해서 테스트 케이스를 결정
        • 만약, 소스 코드의 특정 문장 또는 특정 경로(Path)를 실행하기 위한 입력값을 결정한다면
          구조 기반 테스트
      • EX. 문장, 결정, 조건, 결정/조건, 다중 조건, 변형 조건/결정(MCDC), 기본 경로 테스트

    • 경험 기반 테스트
      테스트 경험, 테스트 대상이 되는 시스템 및 해당 도메인에 대한 경험 등을 바탕으로 수행하는 테스트 방법
      애자일 방법을 사용하는 웹 응용 시스템의 테스트에 적합
      세션 기반 테스팅을 사용하여 테스트를 구조화

      • 오류 추정(Error guessing)

        • 개발자가 범할 수 있는 실수를 추정하고 이에 따른 결함이 검출되도록 테스트 케이스를 설계하는 방법

        • 매우 직관적이고 상황에 따라 적합한 방식으로 수행되므로 일반화된 기법과 절차를 정의 X

        • 명세 기반 테스트의 동등 분할이나 경곗값 분석 방법과 함께 사용이 가능

        • 특정 소프트웨어에 대해 테스터의 직관과 경험을 활용하여
          어떤 유형의 결함이 발생할 것을 예측하여 테스트하는 방법

      • 탐색적 테스트

        • 사전에 구체적으로 테스트 케이스를 설계하여 기록하고 이를 바탕으로 테스트를 수행하는 방식이 아니라,
          테스트 대상에 대한 이해, 테스트 케이스 설계, 테스트 실행을 병행하는 방식

        • 테스트 대상에 대한 이해를 바탕으로 즉석에서 테스트 케이스를 결정한 후,
          문서화 없이 해당 테스트를 바로 수행

        • 테스터의 지식에 의존

---

4. 테스트 레벨

​
​

4-1. 컴포넌트(단위) 테스트

​
개별적인 모듈의 테스트를 말하며, 구현 단계에서 각 모듈을 구현한 후에 수행
모듈을 단독으로 실행할 수 있는 환경이 필요
다른 테스트의 비해 쉽게 수행 가능
테스트 수행에 따른 피드백이 빠름
결함이 발견되었을 때 결함을 발생시키는 부분을 쉽게 식별하여 수정가능

• 테스트 환경
  • = 테스트 베드(Test bed)
  • 구성요소
    • 드라이버
    • 스텁
      

• 모의 객체 생성 프레임워크
  모의 객체는 스텁의 객체 지향 버전

  • 모의 객체

    • 더미 객체 (Dummy)

      • 테스트할 때 객체만 필요하고 해당 객체의 기능까지는 필요하지 않은 경우에 사용
      • 더미 객체의 메서드가 호출되면 정상 동작은 수행하지 않고 예외를 던짐.

    • 가짜 객체 (Fake)

      • Ex) mock 객체
      • 실제 협력 클래스의 기능을 대체해야 할 경우에 사용
      • 실제 협력 클래스의 기능 중 전체나 일부를 훨씬 단순하게 구현
      • 실제 협력 클래스가 구현되지 않았거나 너무 느리거나 테스트 환경에서는 사용할 수 없을 때 사용

    • 테스트 스텁 (Stub)

      • 더미 객체 + 단순한 기능을 작성
        • 추가 객체의 특정 상태를 가정해서
          특정한 값을 리턴하거나 특정한 메시지를 출력

    • 테스트 스파이 (Spy)

      • 주로 테스트 대상 클래스(CUT)와 협력하는 클래스로 가는 출력을 검증하는데 사용
      • CUT가 실행되는 동안 특정 협력 클래스로의 호출을 잡아내 실행이 끝난 후 정상 호출되었는지 검사

​

• FIRST 원칙

  • 컴포넌트 테스트를 잘 수행하기 위한 5가지 규칙

    • Fast : 빠르게 수행
    • Isolated : 다른 컴포넌트 테스트에 의존 X
    • Repeatable : 재테스트해도 동일한 결과
    • Self-Validating : 사람의 개입 없이 테스트가 통과되었는지 확인가능
    • Timely : 테스트 대상이 되는 코드가 작성되는 시점에 수행

​
​

---

4-2. 통합 테스트

​
모듈을 통합하는 과정에서 사용되는 인터페이스를 대상으로 상호 작용이 올바르게 이루어지는지 검증하는 테스트
컴포넌트를 통합하는 과정에서 수행되는 테스트
컴포넌트 간의 상호 연동이 제대로 수행되는지 검사하는 테스트

• 단, 컴포넌트 테스트를 거치고 왔더라도 통합 시 결함이 발생하는 경우도 존재.
• 자료에 따라 통합 테스트가 두 컴포넌트 간 연결의 정확성에만 초점을 두기도 하며
  연결된 두 컴포넌트의 기능적인 측면에 초점을 두기도 함

두 관점이 존재
1. 점진적 통합 (상향식과 하향식)
2. 빅뱅 방식

​

• 빅뱅 방식
  • 전체 컴포넌트를 한 번에 통합하여 테스트 하는 방식
  • 테스트의 오작동이 발생하였을 때 그 결함을 찾기 어려움
    • 물론 빠르게 테스팅을 진행할 수 있는 장점을 가지고 있으나 선호 X
      • 점진적(Incremental) 방식을 적용하는 것이 효과적

• 점진적 통합

  • 점진적 통합 단점

    • 오작동 원인을 찾기 쉬우나 테스트 드라이브와 스텁 필요

  • 점진적 통합 순서
    

    • 상향식/하향식 정리

      통합테스트 종류	특징
      상향식 통합	하위에서 상위로 통합 모듈의 묶음을 클러스트 OR 빌드 라고 함 하위 컴포넌트를 충분하게 테스트할수 있음 스텁 필요 X 하위 컴포넌트를 반복적으로 테스트하기 때문에 빠름.
      하향식 통합	상위에서 하위로 통합 스텁이 실제 모듈로 대체되면 리그레션 테스트 수행 많은 스텁이 필요함 설계오류를 빠른 시점에 발견 가능
      샌드위치 통합	상향식+하향식 통합을 동시에 진행

    • 샌드위치 통합
      

​
​

---

4-3. 시스템 테스트

​

• 전체 시스템이
  시스템 명세에 따라 개발되었는지
  검증하기 위해 수행하는 테스트

• 컴포넌트 테스트나 통합 테스트는 기능이 올바르게 수행되는지
  검증하는 것에 중점을 두지만,
  시스템 테스트는 시스템의 기능 측면뿐만 아니라
  성능, 호환성, 사용성, 신뢰성, 보안성, 유지보수성, 이식성 등과 같은
  비기능적인 요구사항을 만족하는지도 검증
  ​
  ​

---

4-4. 인수 테스트

​

• 인수 테스트의 주 목적은 결함 검출이 아니라
  시스템을 인수해도 되는지 고객의 입장에서 평가

  • 개발자가 수행한 테스트로 발견되지 않은 결함이 인수 테스트 단계에서 발견될 가능성 존재

• 테스트 유형

  • 알파 테스트

    • 선택된 사용자가 개발자 환경에서 통제된 상태로 수행

  • 베타 테스트

    • 일정 수의 사용자에게 소프트웨어를 사용하게 하고 피드백

---

5. 테스트 유형

​
​

5-1. 기능 적합성 테스팅

​
사용자의 요구사항을 시스템이 얼마나 만족하는지에 대한 정보를 제공

• 기능 적합성
  ​

  • 기능 완전성

    • 명시된 요구사항을 포괄하는 정도

    • 모든 명시된 기능을 제공하는 정도

      • 명세 기반 테스트 방법으로 가능

  • 기능 정확성

    • 명시된 요구사항이 얼마나 정확하게 동작하는지
      • 명세기반 / 구조기반 방법 모두 사용가능

  • 기능 적절성

    • 사용자의 사용목적을 달성하는데 도움을 주는 정도

​
​

---

5-2. 성능 효율성 테스팅

​

• 적절한 자원의 사용 및 적정한 반응시간 정도에 대한 정보를 제공

  • 성능 평가 시 CPU사이클, 리소스의 사용,
    주어진 시간 동안 처리할 수 있는 작업량, 자원이 할당되기를 기다리는 테스트의 수 등을 고려
    ​

• 성능 효율성

  • 시간 반응성
    • 기능 수행시 응답,처리 시간 및 처리율이 요구사항을 충족하는 정도
  • 자원 효율성
    • 기능 수행시 사용하는 자원이 요구사항을 충족하는 정도
  • 수용성
    • 시스템 매개 변수의 최대 한계가 요구사항을 충족하는 정도

• 성능 테스팅

  종류	설명
  부하 테스트	부하를 계속 증가시키면서 임계점을 찾는 테스트
  스트레스 테스트	임계정 이상의 부하로 비정상적인 상황에서의 처리를 테스트
  스파이크 테스트	짧은 시간에 사용자가 몰릴때 테스트
  내구성 테스트	오랜시간 높은 부하로 테스트

  • 성능 테스팅 비교
    

​

• 리틀의 법칙(Little's law)

  목표 처리량에 요구되는 동시 사용자 수를 산정할 때 사용
  ​

  • 동시사용자
    • Concurrent user
      • 현재 시스템을 이용중인 사용자
    • 처리량(TPS) x 요청 간격 (Request interval)
    • 처리량(TPS) x (요청간격 + 씽크타임)
  • 활성사용자
    • Active user
      • 요청 후에 응답을 기다리는 사용자
    • 처리량(TPS) x 응답시간 (Response time)
  • 비활성사용자
    • Inactive user
      • 세션 정보를 가지고 있지만 요청을 보내지 않는 사용자
    • 처리량(TPS) x 씽크 타임

​
​

---

5-3. 호환성 테스팅

​
다른 시스템과의 상호 연동 능력에 대한 정보를 제공
서로 다른 시스템과의 상호연동능력을 확인하기 위한 테스트
다른 제품과 공통으로 환경 및 자원을 공유하면서
그 제품에 유해한 영향을 미치지 않고
올바른 기능을 수행할 수 있는지 확인하는 테스트

• 호환성

  • 공존성

    • 다른 소프트웨어와 환경 및 자원을 공유하면서
      서로 간섭없이 독립적으로 요구된 기능을 효율적으로 수행하는 정도

    • 시스템의 장애 발생이 인명 손실이나 막대한 재산 피해,
      또는 치명적인 환경 파괴를 가져올 수 있는
      안전성 필수(Safety – critical) 시스템에서 매우 중요

  • 상호운영성

    • 여러 시스템이 정보를 교환하거나 교환된 정보를 성공적으로 사용할 수 있는 정도
    • 시스템 또는 제품이 다른 시스템과 함께 잘 동작할 수 있는 능력
    • LISI 능력 모델
      • 시스템 간의 정보 교환을 설명
        

​
​

---

5-4. 신뢰성 테스팅

​
특정 조건에서 특정 기간 동안 시스템이 요구되는 서비스를 오동작 없이 제공하는 정도

• 신뢰성

  • 성숙성

    • 시스템 또는 구성 요소가 정상 작동 상태에서 신뢰성 요구를 충족시키는 정도

  • 가용성

    • 사용자가 시스템 또는 구성 요소를 사용하고자 할 때 사용 및 접근이 가능한 정도

  • 결함 허용성

    • H/W, S/W 결함이 있는데도 의도한 대로 작동

  • 복구성

    • = 회복 가능성
    • 중단 또는 장애가 발생한 경우 데이터를 복구하고 상태를 재설정할 수 있는 정도

​
​

• 일반적으로 가용성과 MTTF 척도로 정량화 가능

  • MTTF
    • (Mean Time To Failure)
    • 시스템이 운영된 후 오류가 발생할 때까지 걸리는 평균 동작 시간
      • MTTF가 100이라면 100시간 마다 1개의 오류가 발생

  ​

• 일반적으로 신뢰성을 테스트하기 위해서는 통계적 테스트 방법 사용

  • 자주 사용하는 운영 프로파일을 사용하여 테스트 케이스 생성
    ​
    ​

---

5-5. 보안성 테스팅

​
시스템이 정보 및 데이터를 보호하는 정도
정적 분석으로 검증 가능

• 보안성

  • 기밀성

    • 접근 권한이 있는 사람에게만 데이터 엑세스 허용

  • 무결성

    • 시스템의 무단 접근 방지

  • 부인 방지성

    • 사건 및 행위 후에 부인하지 못하도록 행동 및 사건 입증

  • 책임성

    • 개인을 유일하게 식별하여 행위를 기록하고 추적

  • 인증성

    • 사건 및 행동에 대해 실제 행위자임을 증명

​

• CWE

  • (=Common Weakness Enumeration)
  • 소스코드에 존재할 수 있는 신뢰성 및 보안성과 관련된 코딩 규칙 목록을 정의한 것

• 침입 테스트

  • (=Penetration test)
  • 침입자의 관점에서 취약성을 찾는 테스트
  • 시스템 안전성에 관해 경험과 지식이 많은 사람이 진행.

​
​

---

5-6. 유지보수성 테스팅

​
시스템이 변경 요구를 만족시키는 능력
요구사항을 만족하도록 얼마나 쉽게 변경할 수 있는지 테스트

• 유지보수성

  • 모듈성

    • 하나의 구성요소의 변경이 다른 구성요소에 미치는 영향이 최소화되도록 구성
    • fan-in, fan-out 으로 계산

  • 재사용성

    • 하나 이상의 시스템에서 사용 될 수 있는 정도

  • 분석성

    • 부분에 의도된 변경이 전체 시스템에 미치는 영향을 평가
    • 결함 원인에 대해 제품을 진단해서
      수정될 부분을 식별

  • 변경 용이성

    • 결함이나 품질저하 없이 효율적으로 변경될수 있는 정도

  • 테스트 용이성

    • 테스트 수행이 용이한 정도

​

• 정적 테스트로 검증 가능

  • 실제 소요되는 시간이나 비용을 계산하여 요구사항과 비교하는 방식으로
    동적 테스트 가능성도 존재

• 모듈의 결합도는 낮게 , 응집도는 높게 하는 것이 목표
  ​
  ​

---

5-7. 이식성 테스팅

​
하드웨어 및 소프트웨어 환경이 달라도
동등한 서비스를 제공하는지 테스트

• 이식성

  • 적응성

    • 시스템이 다른 환경에 효과적이고 효율적으로 적용될 수 있는 정도

  • 설치 용이성

    • 특정 환경에서 시스템을 성공적으로 설치 및 제거할수 있는 정도

  • 대체 용이성

    • 동일한 환경에서 동일한 목적으로 다른 S/W제품으로 대체될 수 있는 정도

​

• 크로스 브라우징 테스트

  • 상이한 운영체제에서 동작하거나 브라우저에서 채택하는 렌더링 엔진이 다르기 때문에
    동일한 애플리케이션이 동작하더라도 브라우저마다 다르게 보일 수 있으므로
    를 수행하는 작업

• 테스트를 자동화 하기 위해 Selenium Grid, QTP, RFP와 같은 도구를 사용

​
​

---

5-8. 사용성 테스팅

​
특정한 사용자들이 주어진 사용 환경에서 특정한 목적을 달성하기 위해
제품이나 시스템을 사용할 때 얻게 되는 효율성과 효과성 및 만족도로 정의

• 사용성

  • 적합 인식성

    • 사용자가 자신의 필요에 시스템이 적합한지 인식할수 있는 정도

  • 학습 용이성

    • 사용자가 사용법을 배워 목적을 달성 할 수 있는 정도

  • 운영 용이성

    • 쉽게 조작하고 제어할수 있는 정도

  • 사용자 오류 방지성

    • 사용자가 오류를 범하지 않게 하는 정도

  • 사용자 인터페이스 심미성

    • 사용자에게 만족스러운 인터페이스를 보여주는 정도

  • 접근성

    • 사용자의 특성이나 능력에 관계없이 시스템을 사용할수 있게 하는 정도

• 사용성 평가 품질 특성
  

• 사용성 평가 방법

  방법	설명
  휴리스틱 평가	체크리스트를 통해 사용성에 관한 문제점 도출 3~5명의 전문가들이 실시
  FGI	그룹 인터뷰 방식 공통점이 있는 사용자들을 그룹화하여 의견 교류
  인지적 워크쓰루	아무것도 안알려주고 사용자들에게 써보라고 하고 행동 관찰 학습 용이성 분석에 중점을 둔 방법