[정처기/실기] 10단원(애플리케이션 테스트 관리) 요약

* 수제비 정보처리기사 실기 책을 보고 직접 정리한 내용입니다.

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

[1-1] 소프트웨어 테스트 원리

결함 존재 증명

• 결함이 존재함을 밝히는 활동, 결함을 줄이는 활동
• 결함이 없다는 것을 증명할 수X

완벽 테스팅은 불가능

• 완벽하게 테스팅하려는 시도는 불필요함 → 무한 경로, 무한 입력값으로 인해 테스트 어려움

초기 집중

• 조기 테스트 설계 시 장점 : 테스트 결과를 단시간에 알 수 있고, 테스팅 기간 단축, 재작업을 줄여 개발 기간 단축 및 결함 예방
• SW 개발 초기 체계적인 분석 및 설계X → 프로젝트 후반에 영향, 비용 커짐 = 요르돈의 법칙(Snowball Effect, 눈덩이 법칙)

결함 집중

• 적은 수의 모듈에서 대다수의 결함이 발견됨
• SW 테스트에서 오류의 80%는 전체 모듈의 20% 내에서 발견
• 파레토 법칙(Pareto Principe)의 내용인 80대 20 법칙 적용

살충제 패러독스

• 동일한 테스트 케이스에 의한 반복적 테스트는 새로운 버그 찾지X → 테스트 케이스의 정기적 리뷰, 개선이 필요

정황 의존성

• 소프트웨어의 성격에 맞게 테스트 실시
• 정황과 비즈니스 도메인에 따라 테스트를 다르게 수행

오류-부재의 궤변

• 요구사항을 충족시켜주지 못한다면, 결함이 없다고 해도 품질이 높다고 볼 수X

[1-2] 소프트웨어 테스트 산출물

테스트 계획서	테스트 목적과 범위 정의, 대상 시스템 구조 파악, 테스트 수행 절차, 테스트 일정, 조직의 역할 및 책임, 종료 조건 등 테스트 수행을 계획한 문서
테스트 베이시스	분석, 설계 단계의 논리적인 Case로 테스트 설계를 위한 기준이 되는 문서
테스트 케이스	요구사항 준수 확인을 위해 설계된 입력값, 실행 조건, 기대 결과로 구성된 테스트 항목 명세서
테스트 슈트	테스트 케이스의 집합, 시나리오 포함X 단순 테스트 케이스의 모음
테스트 시나리오	테스트 되어야 할 기능 및 특징, 테스트가 필요한 상황을 작성한 문서. 하나의 테스트 시나리오가 하나 또는 여러 개의 테스트 케이스들을 포함할 수O
테스트 스크립트	테스트 케이스의 실행 순서를 작성한 문서(= 테스트 스텝, 테스트 절차서)
테스트 결과서	테스트 결과를 정리한 문서

[2-1] 소프트웨어 테스트 유형

프로젝트 실행 여부에 따른 분류

• 정적 테스트
  • 테스트 대상을 실행X 구조 분석해 논리성 검증
  • 유형 : 리뷰, 정적 분석
• 동적 테스트
  • SW를 실행해 결함 검출
  • 유형 : 화이트박스 테스트(구조 기반), 블랙박스 테스트(명세 기반), 경험기반 테스트

테스트 기법에 따른 분류

• 화이트박스 테스트(= 구조 기반 테스트, 코드 기반 테스트, 로직 기반 테스트, 글래스(Glass) 박스 테스트)
  • 코드 분석, 프로그램 구조에 대한 지식 바탕 → 모듈 내부를 테스트
  • 소스 코드의 모든 문장을 한 번 이상 수행함으로써 진행, 실행과정 확인 가능
• 블랙박스 테스트(=명세 테스트)
  • 프로그램 외부 사용자의 요구사항 명세를 보면서 수행
  • 소프트웨어의 특징, 요구사항, 설계 명세서 등에 초점을 맞춰 테스트
  • 기능 및 동작 위주의 테스트 → 내부 구조나 작동 원리를 알지 못해도 가능

테스트 시각에 따른 분류

• 검증(Verification)
  • 소프트웨어 개발 과정을 테스트
  • 올바른 제품을 생산하고 있는지 검증
  • 이전 단계에서 설정된 개발 규격과 요구를 충족시키는지 판단
  • 개발자/시험자의 시각 → 명세화된 기능을 올바로 수행하는지?
• 확인(Validation)
  • 소프트웨어 결과를 테스트
  • 만들어진 제품이 제대로 동작하는지 확인
  • 최종 사용자 요구 또는 소프트웨어 요구에 적합한지 판단
  • 사용자 시각 → 올바른 소프트웨어가 개발되었는지?

테스트 목적에 따른 분류

• 회복 테스트(Recovery Testing) : 고의로 실패 유발 → 시스템의 정상 복귀 여부 테스트
• 안전 테스트(Security Testing) : 소스 코드 내 보안적인 결함 미리 점검
• 성능 테스트(Performance Testing) : 응답 시간, 처리 업무량, 반응 속도 등 측정
  • 부하 테스트(Load Testing) : 시스템의 임계점을 찾으며 병목 현상 제거 반복
  • 강도 테스트(Stress Testing) : 임계점 이상의 부하 → 동작 상태 확인
  • 스파이크 테스트(Spike Testing) : 짧은 시간 사용자가 몰릴 때 반응 측정
  • 내구성 테스트(Endurance Testing) : 오랜 시간 높은 부하 가해 반응 테스트
• 구조 테스트(Structure Testing) : 시스템의 내부 논리 경로, 소스 코드 복잡도 평가
• 회귀 테스트(Regression Testing) : 오류 제거/수정에 의해 새로 유입된 오류 확인(일종의 반복 테스트)
• 병행 테스트(Parallel Testing) : 변경된 시스템과 기존 시스템에 동일한 데이터 입력 → 결과 비교

테스트 종류에 따른 분류

• 명세 기반 테스트(블랙박스 테스트)
• 구조 기반 테스트(화이트박스 테스트)
• 경험 기반 테스트(블랙박스 테스트)
  • 유사 소프트웨어나 유사 기술 평가에서 테스터의 경험을 토대로 한, 직관과 기술 능력을 기반으로 수행
  • 유형 : 탐색적 테스트, 오류 추정

[2-2] 정적 테스트

리뷰

• 동료 검토(Peer Review)
  • 2~3명이 진행하는 리뷰의 형태
  • 요구사항 명세서 작성자가 요구사항 명세서를 설명하고 이해관계자들이 설명을 들으며 결함을 발견하는 형태
• 워크 스루(Walk Through)
  • 회의 전에 사전 검토한 후 짧은 시간 동안 회의 진행하는 비형식적 검토 기법
  • 결함을 검출할 뿐만 아니라 참가자들의 교육이나 지식 공유를 위해 수행
• 인스펙션(Inspection)
  • 다른 전문가 또는 팀이 검사해 문제 식별, 해결을 찾아내는 형식적 검토 기법
  • 개발 초기에 검사해야만 개발 초기 작업물에서 문제 발견 가능

정적 분석

• 자동화된 도구의 지원을 받아 정적 테스트를 수행하는 방법
• 코딩 표준 부합, 코드 복잡도 계산, 자료 흐름 분석 등

[2-3] 동적 테스트

화이트박스 테스트(구조 기반 테스트)

블랙박스 테스트(명세 기반 테스트)

[2-4] 테스트 케이스

• 테스트 케이스(Test Case) :특정 요구사항에 준수하는지 확인하기 위해 개발된 입력값, 실행 조건, 에상된 결과의 집합

테스트 케이스 작성 절차

1. 테스트 계획 검토 및 자료 확보
2. 위험 평가 및 우선순위 결정
3. 테스트 요구사항 정의
4. 테스트 구조 설계 및 테스트 방법 결정
5. 테스트 케이스 정의 및 작성
6. 테스트 케이스 타당성 확인 및 유지보수

테스트 케이스 필요 항목

• 공통 작성 항목 요소
  • 테스트 단계명, 작성자, 승인자, 작성 일자, 문서 버전
  • 대상 시스템
  • 변경 여부
  • 테스트 범위
  • 테스트 조직
• 개별 테스트 케이스 항목 요소
  • 테스트 ID
  • 테스트 목적
  • 테스트할 기능
  • 테스트 데이터(=입력 데이터) : 테스트 실행 시 입력할 데이터(입력값, 선택 버튼, 체크리스트 값 등) 작성
  • 예상 결과(=기대 결과) : 테스트 실행 후
  • 테스트 환경
  • 테스트 조건(=전제 조건) : 테스트 간의 종속성, 테스트 수행 전 실행되어야 할 고려사항 등을 작성
  • 설공/실패 기준

[2-5] 테스트 오라클

• 테스트 오라클(test Oracle) : 테스트의 결과가 참인지 거짓인지를 판단하기 위해 사전에 정의된 참값을 입력하여 비교하는 기법
• 테스트 오라클 종류

참 오라클	모든 입력값에 대해 기대하는 결과 생성 → 발생된 오류 모두 검출 가능
샘플링 오라클	특정한 몇 개의 입력값에 대해서만 기대하는 결과 제공
휴리스틱 오라클	샘플링 오라클을 개선한 오라클. 특정 입력값에 대해 올바른 결과 제공하고 나머지 값들에 대해서는 휴리스틱(추정)으로 처리
일관성 검사 오라클	변경이 있을 때, 수행 전과 후의 결괏값이 동일한지 확인

[3-1] 테스트 레벨

단위 테스트(Unit Test)

• 소프트웨어 설계의 최소 단위인 모듈이나 컴포넌트에 초점을 맞춘 테스트
• 사용자 요구사항을 기반으로 한 기능성 위주의 테스트 수행
• 주로 구조 기반 테스트 위주로 수행
• 자료 구조 테스트, 실행 경로 테스트, 오류 처리 테스트, 인터페이스 테스트

통합 테스트(Integration Test)

• 소프트웨어 각 모듈 간의 인터페이스 관련 오류 및 결함을 찾아내기 위한 체계적인 테스트 기법
• 단위 테스트가 끝난 프로그램이 설계 단계에서 제시한 애플리케이션과 동일한 구조와 기능으로 구현된 것인지 확인
• 빅뱅 테스트, 샌드위치 테스트, 상향식 테스트, 하향식 테스트

시스템 테스트(System Test)

• 통합된 단위 시스템의 기능이 시스템에서 정상적으로 수행되는지 검증
• 기능/비기능 요구사항 테스트

인수 테스트(Acceptance Test)

• 최종 사용자와 업무의 이해관계자 등이 테스트 수행함으로써 개발 제품에 대해 운영 여부 결정
• 인수 테스트 종류
  • 알파 테스트 : 선택된 사용장가 개발자 환경에서 통제된 상태로 개발자와 함께 수행하는 인수 테스트
  • 베타 테스트 : 실제 환경에서 일정 수의 사용자에게 대상 소프트웨어를 사용하게 하고 피드백을 받는 인수 테스트

[3-2] 테스트 시나리오

• 테스트 수행을 위한 여러 테스트 케이스의 집합으로서, 테스트 케이스의 동작 순서를 기술한 문서
• 테스트 수행 절차를 미리 정함으로써 테스트 항목을 빠짐없이 테스트
• 유의점
  • 테스트 시나리오 분리 작성
  • 고객 요구사항과 설계 문서 등을 토대로 작성

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

[1-1] 단위 테스트

• 모듈을 단독으로 실행할 수 있는 테스트 배드(Test Bed)라는 환경 필요
• 단위 테스트 수행도구
  • 테스트 드라이버(Test Driver) : 테스트 완료 후 결괏값을 받는 역할을 하는 가상의 모듈, 하위 모듈을 호출하는 상위 모듈의 역할
  • 테스트 스텁(Test Stub) : 일시적으로 필요한 조건만을 가지고 임시로 제공되는 시험용 모듈, 상위 모듈에 의해 호출되는 하위 모듈의 역할
• 단위 테스트 원칙
  • 빠르게 수행되어야 하고, 다른 컴포넌트에 의존하지 않도록 해야함
  • 테스트를 몇 번 실행해도 동일한 결과가 나와야 하고, 사람의 개입 없이 테스트가 통과되었다는 것을 알 수 있도록 작성

[1-2] 통합 테스트

• 통합 테스트(Integration Test)
• 통합 테스트 수행 방법 분류
  • 점증적 방식
    • 하향식 통합 방식
    • 상향식 통합 방식
  • 비점증적 방식
    • 빅뱅 방식 : 모든 컴포넌트를 사전에 통합하여 전체 프로그램을 한꺼번에 테스트

하향식 통합(Top Down)

• 테스트 스텁 필요
• 장점
  • 장애 위치 파악 쉬움
  • 이른 프로토타입 가능
  • 중요 모듈의 선 테스트 가능
• 단점
  • 많은 스텁이 필요
  • 하위 모듈들의 불충분한 테스트 수행

상향식 통합(Bottom Up)

• 테스트 드라이버 필요
• 장점
  • 장애 위치 파악 쉬움
  • 모든 모듈 개발 시간 낭비 필요X
• 단점
  • 중요 모듈들이 마지막 테스트 가능성 높음
  • 이른 프로토 타입 어려움

샌드위치 통합

• 상향식 + 하향식 통합 테스트 방식
• 테스트 스텁, 드라이버 필요
• 장점
  • 병렬 테스트 가능, 시간 절약
  • 큰 규모에 통합 테스트에 활용
• 단점
  • 많은 비용 소모