2. 소프트웨어 수명주기와 테스팅

1. 테스트 유형

테스팅의 목적과 품질 특성에 따라 테스트 방식을 분류한 것이다.

대표적으로 다음과 같이 구분한다.

• 기능 테스트
• 비기능 테스트
• 구조적 테스트
• 변경 관련 테스트 (확인 테스트 / 리그레션 테스트)

---

1.1 기능 테스팅

여기서 기능이란 시스템이나 컴포넌트가 무엇을 수행하는가(What) 를 의미한다.

기능 테스팅은 주로 명세 기반 테스트를 통해 테스트 조건과 테스트 케이스를 설계하며, 소프트웨어의 외부적인 동작(블랙박스 관점)을 중심으로 검증한다.

기능 테스트는 모든 테스트 레벨에서 수행될 수 있다.

ISO/IEC 9126 기능성 품질 특성

• 적합성 (Suitability)
  제공된 기능이 사용자의 목적과 요구사항에 적절한지 여부 (예: 검색 기능이 실제 원하는 데이터를 찾을 수 있는가)

• 정확성 (Accuracy)
  기능이 정확한 결과를 제공하는지 여부 (예: 결제 금액 계산이 정확한가)

• 상호운용성 (Interoperability)
  다른 시스템이나 서비스와 정상적으로 연동되는지 여부 (예: 외부 결제 API 연동)

• 보안성 (Security)
  권한 없는 접근이나 데이터 유출을 방지하는 능력 (예: 인증 없이 관리자 페이지 접근 불가)

• 준수성 (Compliance)
  관련 표준, 법률, 규정을 준수하는지 여부 (예: 개인정보 처리 규정 준수)

---

1.2 비기능 테스트

여기서 비기능이란 시스템이나 컴포넌트가 어떻게 동작하는가(How) 를 의미하며 기능 자체보다는 품질 특성, 성능, 사용성, 안정성 등을 검증하는 테스트이다.

주로 측정 가능한 지표(응답시간, 처리량, 오류율 등)를 기반으로 평가한다.

비기능 테스트 역시 모든 테스트 레벨에서 수행될 수 있다.

대표적인 유형

• 성능 테스트
  시스템의 응답시간, 처리량 등을 측정하여 성능 요구사항을 만족하는지 확인하는 테스트

• 부하 테스트
  예상되는 사용자 수 또는 트래픽 상황에서 시스템이 정상 동작하는지 확인

• 스트레스 테스트
  시스템의 한계를 넘어서는 부하를 가해 장애 발생 시점을 확인

• 사용성 테스트
  사용자가 시스템을 쉽고 편리하게 사용할 수 있는지 평가 (예: UI 이해도)

• 신뢰성 테스트
  장시간 실행 시 시스템이 안정적으로 동작하는지 확인

• 유지보수성 테스트
  시스템 수정이나 개선이 얼마나 쉽게 이루어질 수 있는지 평가

• 이식성 테스트
  다른 운영체제, 환경, 플랫폼에서 정상적으로 동작하는지 확인

ISO/IEC 9126 비기능 품질 특성

• 신뢰성
  장애 없이 일정 시간 동안 안정적으로 동작하는 능력 (예: 서버가 장시간 다운 없이 운영)

• 사용성
  사용자가 시스템을 이해하고 사용하는 데 필요한 노력의 정도 (예: 직관적인 UI)

• 효율성
  시스템이 자원을 얼마나 효율적으로 사용하는지 (예: CPU, 메모리 사용량)

• 유지보수성
  시스템 수정이나 개선이 얼마나 쉽게 이루어질 수 있는지

• 이식성
  다른 환경에서도 시스템을 쉽게 실행할 수 있는 능력

---

1.3 구조적 테스팅

소프트웨어 내부 구조(코드 구조)를 기반으로 테스트를 설계하는 방식으로 테스트의 목적은 코드 구조에 대한 커버리지를 측정하여 테스트의 충분성을 평가하는 것이다.

커버리지 : 코드나 테스트 대상 중 실제로 테스트 실행이 이루어진 비율

대표적인 커버리지 유형

• 구문 커버리지 (Statement Coverage)
  코드의 각 실행 문장이 최소 한 번 이상 실행되었는지를 측정

• 분기 커버리지 (Branch Coverage)
  조건문의 모든 분기(true/false)가 최소 한 번 이상 실행되었는지를 측정

• 조건 커버리지 (Condition Coverage)
  복합 조건문에서 각 개별 조건이 true와 false를 모두 가지는지 확인

필요한 경우 커버리지 목표(예: 80%, 100%)를 만족하도록 추가 테스트 케이스를 설계하기도 한다.

구조적 테스트 역시 모든 테스트 레벨에서 수행될 수 있지만 주로 컴포넌트 테스트에서 많이 사용된다.

---

1.4 확인 테스트 / 리그레션 테스트

확인 테스트 (Confirmation Testing)

결함이 수정된 이후 해당 결함이 실제로 수정되었는지 확인하기 위한 테스트이며, 일반적으로 동일한 테스트 케이스를 다시 실행하여 검증한다.

리그레션 테스트 (Regression Testing)

결함 수정이나 코드 변경 이후 기존에 정상 동작하던 기능에 문제가 발생하지 않았는지 확인하는 테스트이다.

즉 변경으로 인해 발생할 수 있는 부작용(side effect)을 확인하는 것이 목적이다.

리그레션 테스트는 기능 테스트, 비기능 테스트, 구조적 테스트 등 모든 테스트 유형에 적용될 수 있으며 모든 테스트 레벨에서 수행될 수 있다.

또한 다음과 같은 경우에도 수행된다.

• 시스템 환경 변경
• 라이브러리 변경
• 인프라 변경
• 설정 변경

리그레션 테스트 범위는 일반적으로 리스크 기반으로 결정된다.

---

2. 유지보수 테스팅

유지보수 테스팅은 이미 운영 중인 시스템에 변경이 발생했을 때 수행되는 테스트이다.

예를 들어 기능 변경, 기능 개선, 시스템 마이그레이션, 플랫폼 변경, 시스템 단종 등의 상황에서 수행된다.

이때 변경된 부분에 대한 테스트뿐 아니라 기존 기능이 영향을 받지 않았는지 확인하기 위한 리그레션 테스트가 매우 중요하다.

유지보수 테스팅 역시 모든 테스트 유형과 모든 테스트 레벨에서 수행될 수 있다.

영향도 분석 (Impact Analysis)

영향도 분석은 변경 사항이 시스템의 어떤 부분에 영향을 줄 가능성이 있는지 분석하는 활동이다.

이를 통해

• 어떤 테스트를 다시 수행해야 하는지
• 리그레션 테스트 범위
• 테스트 우선순위

등을 결정할 수 있다.

예를 들어 로그인 모듈이 변경되었다면 회원 인증, 세션 관리, 권한 처리, API 인증 기능 등에 영향이 발생할 수 있으며 이러한 영역을 중심으로 추가 테스트가 수행된다.

---

3. 테스트 레벨

테스트 레벨(Test Level)은 소프트웨어 개발 과정에서 테스트를 수행하는 단계별 구분을 의미한다.

전체 테스트를 관리하는 상위 계획을 마스터 테스트 계획(Master Test Plan)이라고 한다.

각 테스트 레벨은 서로 일정한 종속 관계를 가지므로 다음 테스트 단계로 진행하기 위해서는 종료 조건(Exit Criteria)과 시작 조건(Entry Criteria)을 만족하는 것이 바람직하다.

각 테스트 레벨에서는 다음 요소들이 서로 다르게 정의된다.

• 테스트 목적
• 테스트 대상
• 테스트 베이시스(개발 산출물)
• 발견 가능한 결함 유형
• 테스트 환경 및 도구
• 테스트 수행 주체

대표적인 테스트 레벨은 컴포넌트 테스트, 통합 테스트, 시스템 테스트, 인수 테스트가 있다.

---

4. 소프트웨어 개발 모델

테스트 활동은 소프트웨어 개발 활동과 밀접하게 연결되어 있다. 따라서 개발 생명주기 모델에 따라 테스트 접근 방식도 달라진다.

---

4.1 V 모델

대표적인 순차적 개발 모델이다.

개발 단계와 대응되는 테스트 레벨이 V 형태로 연결되는 구조를 가진다.

요구사항 분석 ----------- 인수 테스트
      ↓                        ↑
시스템 설계 ----------- 시스템 테스트
      ↓                        ↑
아키텍처 설계 -------- 통합 테스트
      ↓                        ↑
구현(코딩) ----------- 컴포넌트 테스트

개발 과정에서 생성되는 요구사항, 설계 문서, 코드 등의 산출물은 상위 테스트 레벨의 테스트 베이시스(Test Basis)가 된다.

실무에서는 제품 특성에 따라 테스트 단계가 추가되거나 비대칭 구조가 나타날 수 있으며 예를 들어 컴포넌트 테스트 이후 컴포넌트 통합 테스트나 시스템 통합 테스트가 별도로 수행되기도 한다.

---

4.2 반복적 점증적 개발 모델

반복적 점증적 개발 모델은 요구사항 분석, 설계, 구현, 테스트 과정을 반복적으로 수행하며 시스템을 점진적으로 완성해 나가는 개발 방식이다.

초기 단계에서는 핵심 아키텍처나 중요한 기능을 우선 구현하고 테스트를 수행하여 결함과 위험 요소를 조기에 발견할 수 있다.

각 반복 단계에서 개발된 기능이 기존 시스템과 결합되면서 부분적인 시스템이 형성되고 이 과정에서 자연스럽게 리그레션 테스트가 반복적으로 수행된다.

이 방식은 전통적인 순차적 개발 방식과 달리 테스트가 개발과 함께 지속적으로 이루어지며 초기 설계에 대한 부담이 상대적으로 적고 다양한 역할의 구성원이 테스트에 참여할 수 있다.

요구사항 → 설계 → 구현 → 테스트
   ↑                         ↓
   ←────── 반복 / 개선 ──────

---

5. V&V

Verification과 Validation은 소프트웨어 개발 수명주기의 여러 단계에서 수행되는 품질 검증 활동이다.

Verification

Verification은 개발 과정에서 산출물이 미리 정의된 요구사항과 설계 기준을 충족하는지 확인하는 활동이다.

즉 "우리가 제품을 올바르게 만들고 있는가?"를 확인하는 과정이며 주로 개발자나 내부 조직의 관점에서 수행된다.

예를 들어 설계 문서 리뷰, 코드 리뷰, 단위 테스트 등이 이에 해당한다.

Validation

Validation은 개발된 제품이 실제 사용자 요구사항과 기대를 충족하는지 평가하는 활동이다.

즉 "우리가 올바른 제품을 만들었는가?"를 확인하는 과정이며 사용자 관점에서 시스템의 유효성을 검증한다.

대표적인 예로 시스템 테스트, 인수 테스트 등이 있다.