8장 : 애플리케이션 테스트 관리(2과목)

1. 애플리케이션 테스트 사확개검

  • 결함을 찾아내는 일련의 행위 또는 절차를 말한다. 
  • 유형
    • 확인 (Validation) : 사용자(고객)에 초점을 맞춤
    • 검증 (Verification) : 기능에 초점을 맞춤, 개발자가 확인
  • 완벽한 테스팅은 불가능
  • 파레토 법칙 : 대부분의 결함은 특정 모듈에 집중
  • ‘살충제 패러독스 현상’을 막기 위해 지속적인 보완 및 개선해야 함
  • 오류-부재의 궤변 : 소프트웨어의 결함을 모두 제거해도, 사용자의 요구사항을 만족시키지 못하면, 해당 소프트웨어는 품질이 높다고 말할 수 없음

2. 애플리케이션 테스트의 기준

  • 프로그램 실행 여부에 따라
  • 기반에 따라
  • 시각에 따라
  • 목적에 따라 

3. 프로그램 실행 여부에 따른 테스트 ★★★

  • 정적 테스트
    • 실행하지 않음
    • 명세서나 소스 코드를 분석
    • 초기에 결함 발견 가능
    • 비용을 낮추는 데 도움
    • 종류 : 워크스루, 인스펙션, 코드 검사
  • 동적 테스트
    • 실행함
    • 소프트웨어 개발의 모든 단계에서 테스트 수행이 가능
    • 종류 : 블랙박스 테스트, 화이트박스 테스트 

 

3-1. 워크스루

  • 소프트웨어 개발자의 작업 내역을, 개발자가 모집한 전문가들이 검토하는 것
  • 검토 회의 전에 요구사항 명세서 미리 배포하여 사전 검토한 후 결함 발견하여 의견을 나누는 방법
  • 개발자가 주최
  • 오류의 조기 검출이 목적 (오류의 문제 해결이 아님)

 

3-2. 인스펙션

  • 워크스루의 발전된 형태 
  • 요구사항 명세서 작성자를 제외한 전문가들이 요구사항 명세서 검토 후 결함을 발견하는 방법
  • 소프트웨어 개발 단계에서 산출된 결과물의 품질을 평가

4. 기반에 따른 테스트

  • 명세 기반 테스트
    • 명세를 기준으로 진행
    • 종류 : 동등 분할, 경계 값 분석
  • 구조 기반 테스트
    • 논리 흐름에 따라 진행
    • 종류 : 구문 기반, 결정 기반, 조건 기반, 결정 기반
  • 경험 기반 테스트
    • 테스터의 경험을 통해 진행
    • 종류 : 에러 추정, 체크 리스트, 탐색적 테스팅 

5. 시각에 따른 테스트 ★★★

  • 확인 (Validation) 테스트 : 사용자의 시각에서 진행
  • 검증 (Varification) 테스트 : 개발자의 시각에서 진행

6. 목적에 따른 테스트

  • 회복 테스트 : 실패하게 한 후, 올바르게 복구되는지 확인
  • 안전 테스트 : 불법적인 침입으로부터 보호할 수 있는지 확인 
  • 강도 테스트 : 과부하 시 실행 가능한지 확인
  • 성능 테스트 : 실시간 성능, 전체적인 효율성 등을 확인
  • 구조 테스트 : 논리적인 경로를 확인
  • 회귀 테스트 : 수정 후 결함이 없는지 확인
  • 병행 테스트 : 변경 전, 후(버전 차이)의 소프트웨어에 동일 값을 입력하여 결과 값을 비교

7. 화이트박스 테스트 ★★★

  • 절차에 초점
  • 원시 코드를 오픈
  • 모든 경로를 테스트
  • 테스트 과정의 초기에 적용
  • 모듈 내부의 논리적인 구조를 관찰
  • 직접 관찰
  • 모든 문장을 1회 이상 실행
  • 종류 
    • 기초 경로 검사
    • 조건 검사 (in 제어검사)
    • 루프 검사 (in 제어검사)
    • 데이터 흐름 검사 (in 제어검사)
  • 검증 기준
    • 문장 검증 기준 - 모든 소스 코드가 1번 이상 실행
    • 분기(결정) 검증 기준 - 모든 조건문의 True/False가 1번 이상 실행
    • 조건 검증 기준 - 모든 조건문 안의 각각 조건식에 대한 True/False가 1번 이상 실행
    • 분기 / 조건 검증 기준 

8. 블랙박스 테스트 ★★★

  • 기능 테스트
  • 특정 기능에 초점
  • 테스트 과정의 후반부에 적용
  • 종류
    • 동치 분할 검사
    • 경계값 분석
    • 원인 효과 그래프 검사
    • 오류 예측 검사
    • 비교 검사

9. 개발 단계에 따른 어플리케이션 테스트 ★★★

V-Model of Software Life Cycle

9-1. 단위 테스트 (Unit Test) 블랙/화이트박스

  • 코딩 직후 수행
  • 최소 단위인 모듈이나 컴포넌트에 초점
  • 사용자의 요구사항을 기반으로 한 기능성 테스트를 최우선
  • 구조 기반 테스트(화이트 박스 테스트)를 주로 사용
  • 종류
테스트 방법 테스트 내용 테스트 목적
구조 기반 테스트  화이트 박스 테스트  제어 흐름, 조건 결정
명세 기반 테스트  블랙 박스 테스트  동등 분할, 경계 값 분석

 

9-2. 통합 테스트 (Integration Test) 상드하스(상드클/하스)

  • 단위 테스트 후, 모듈들을 결합하여 하나의 시스템으로 완성시키는 과정에서 수행(인터페이스 관리)
  • 모듈 간 상호 작용 오류를 검사
  • 종류
테스트 방법 설명
비점진적 통합 방식 단계적으로 통합하는 절차 없이,
모든 모듈이 미리 결합되어 있는 프로그램 전체를 테스트하는 방법

규모가 작은 소프트웨어에 유리

전체 프로그램을 대상으로 하기 때문에, 오류의 발견 및 수정이 어려움
점진적 통합 방식 단계적으로 통합하며 진행

하향식, 상향식, 혼합식 통합 방식

오류 수정이 용이
구분 수행 방법 장점 단점

상향식
(Bottom-Up)

 - 가장 하부의 모듈부터 통합
- 하위 레벨 모듈이 '클러스터'로 결합
- 상위 모듈에서 '드라이버'를 작성		 - 결함의 격리가 쉬움
- 하위 모듈을 충분히 테스트 가능		 - 중요한 결함이 상부에 있을 수 있음

하향식
(Top-Down)

 - 가장 상부의 모듈부터 통합
- BFS, DFS 방식 사용
- 하위 레벨 모듈에서 '스텁'으로 결합		 - 결함의 격리가 쉬움
- 결함을 빨리 발견 가능		 - 중요한 결함이 하부에 잇을 수 있음

백본
(Backbone)

 - 리스크가 높은 모듈로 초기 통합 형성 - 결함의 격리가 쉬움
- 리스크가 높은 결함을 초기에 발견 가능		 - 테스트 시간이 오래 걸릴 수 있음

빅뱅
(Big Bang)

 - 모든 테스트 모듈을 동시 통합 - 단시간 테스트 가능 - 결함의 격리가 어려움

*클러스터: 동일한 성격의 데이터를 동일한 블럭에 함께 저장해 놓는 것

 

9-3. 시스템 테스트 (System Test) 기능/비기능

  • 해당 컴퓨터 시스템에서 완벽하게 수행되는가 점검
  • 실제 사용 환경과 유사하게 만든 환경에서 진행
  • 종류
테스트 방법 테스트 내용
기능적 요구사항 블랙 박스 테스트
비기능적 요구사항  화이트 박스 테스트

9-4. 인수 테스트 (Acceptance Test) 알파/베타

  • 사용자가 직접 테스트한다.
  • 종류
    • 사용자 인수 테스트
    • 운영상의 인수 테스트
    • 계약 인수 테스트
    • 규정 인수 테스트
    • 알파 테스트 : 선택된 사용자가, 개발자 앞에서, 통제된 환경에서 검사
    • 베타 테스트 : 최종 선정된 사용자가, 여러 명의 사용자 앞에서, 제어되지 않은 상태에서 검사

10. 하향식 통합 테스트 ★★★ 테스트 스텁

  • 상위 모듈에서 하위 모듈 방향으로 통합하면서 테스트를 진행한다. 
  • DFS, BFS를 사용한다. 
  • 테스트 초기에 사용하므로, 사용자에게 시스템의 구조를 보여줄 수 있다. 
  • 상위 모듈에서는 부적절하다. 
  • 회귀 테스트를 실시한다. 

11. 상향식 통합 테스트 ★★★ 테스트 드라이버

  • 하위 모듈에서 상위 모듈 방향으로 통합하면서 테스트
  • 스텁은 필요 없지만, 클러스터(하나의 주요 제어 모듈과 관련된 종속 모듈의 그룹)는 필요하다. 
  • 드라이버(Driver)를 작성한다. 

11-1. 상향식 통합 테스트의 과정 ★★★

순서 과정
1 낮은 수준의 모듈들을 클러스터로 결합한다. 
2 드라이버라는 제어 프로그램을 작성한다. 
3 클러스터를 검사한다. 
4 클러스터를 상위로 결합한다. 

12. 드라이버(driver)와 스텁(stub) ★★★

구분 드라이버 스텁
필요 시기 상위 모듈 없이, 하위 모듈이 있는 경우 상위 모듈은 있지만, 하위 모듈이 없는 경우
테스트 방식 상향식 테스트 하향식 테스트
공통점 소프트웨어 개발과 테스트를 병행할 경우 이용
차이점 개발이 완료되면, 드라이버는 본래의 모듈로 교체  일시적, 임시적인 가짜 모듈 역할

드라이버보다 작성이 쉬움

 

13. 테스트 케이스

  • 입력 값, 실행 조건, 예상 결과 등으로 구성된 테스트 항목에 대한 명세서
  • 오류 방지
  • 자원 낭비 방지
  • 시스템 '설계' 시 작성

14. 테스트 시나리오

  • 여러 개의 테스트 케이스를 묶은 집합이다. 
  • 테스트 절차를 명세한 문서이다. 

15. 테스트 오라클 (Test Oracle) ★★★

  • 테스트 결과가 올바른지 판단하기 위해, 사전에 정의된 참 값을 대입
  • 테스트 결과가 올바른지를 판단하는 근거
  • 모든 테스트 케이스에 적용할 수 없음
  • 종류
구분 설명
참 오라클 모든 입력 값에 대한 결과 값을 검출할 수 있는 오라클
샘플링 오라클 특정 몇 개의 입력 값만을 대상으로 하는 오라클
전 범위 테스트가 불가한 경우 사용
휴리스틱 오라클 샘플링 오라클의 개선
특정 몇 개의 입력 값을 대상을로 하고, 나머지는 휴리스틱(추정)으로 처리
일관성 검사 오라클 애플리케이션의 변경이 있을 때, 전후 값이 동일한지 확인하는 오라클
회귀 테스트 시 사용

16. 어플리케이션 성능 측정 지표 처응경자

  • 처리량 (Throughput) : 일정 시간 내의 처리하는 일의 양
  • 응답 시간 (Response Time) : 요청 시간 ~ 응답 시간
  • 경과 시간 (Turn Around Time) : 작업 의뢰 시간 ~ 처리 완료 시간
  • 자원 사용률 (Resource Usage) : CPU 사용량 등

17. 산업 범용 소프트웨어 구분

구분 설명
시스템 소프트웨어 응용 소프트웨어를 실행하기 위한 플랫폼 제공
컴퓨터 하드웨어를 동작, 접근할 수 있도록 설계
예 : OS, DBMS 등
미들웨어 응용 소프트웨어가 OS로부터 제공받는 서비스 이외의 추가적으로 이용할 수 있는 서비스 제공
예 : WAS, 실시간 데이터 처리 등
응용 소프트웨어 OS에서 실행되는 모든 소프트웨어
예 : 영상 처리 소프트웨어 등

18. 소프트웨어 결함

  • 에러(Error) / 오류
    • 결함의 원인
    • 사람이 발생시키는 결함
  • 결함 / 결점 / 버그(Bug)
    • 에러 또는 오류의 원인
    • 소프트웨어 제품에 포함되어 있는 결함
    • 이를 해결하지 않으면, 소프트웨어의 실패 또는 문제가 됨
  • 실패 / 문제
    • 소프트웨어 제품에 포함된 결함이 실행될 때 발생되는 현상

19. 테스트 커버리지 (Test Coverage)

  • 주어진 테스트 케이스에 의해 수행되는 소프트웨어의 테스트 범위를 측정하는 테스트 품질 측정 기준
  • 테스트의 정확성과 신뢰성을 향상시키는 역할을 함
구분 설명
라인 커버리지
(Line Coverage)		 애플리케이션의 전체 소스 코드의 Line 수를 모수로 테스트 시나리오가 수행한 소스 코드의 Line 수를 측정하는 방법
코드 커버리지
(Code Coverage)		 프로그램의 소스코드가
얼마나 테스트되었는지를 나타내는 지표		 구문(Statement) 커버리지 모든 구문에 대해 1회 이상 테스트
조건(Condition) 커버리지 모든 조건식에 대해 테스트
결정(Decision) 커버리지 모든 분기문에 대해 테스트
변형 조건/결정 커버리지 전체 결과에 독립적으로 수행
 
저작자표시 비영리 변경금지

티스토리툴바