[자격증] CSTS_FL 요약정리 (테스트 개요)

75점 이상을 받아야 한다…

테스트 개념 및 용어

테스트 목적

• 결함의 검출과 제품 품질 개선
• 품질 평가와 의사 결정 지원
• 개발 프로세스 개선 지원
• 요구사항 만족 여부 및 표준 준수 검증
• 소프트웨어의 품질 기준 충족 여부 확인
• 에러 발견 및 개선을 통한 품질 측정 활동

오류, 결함, 장애

오류 (Error)

• 사람에 의해 발생하는 실수
• 요구사항을 제대로 파악하지 못한 실수
• 코딩 및 타이핑 실수
• 요구사항 오류: 의사소통 장애, 요구사항 누락
• 설계 오류: 요구사항 미반영
• 코딩 오류: 개발 오류
• 기타 오류: 표준 미준수, 테스트 프로세스 부족

결함 (Defect)

• 에러로 인해 발생한 잘못된 로직
• 소프트웨어 내 장애를 유발할 수 있는 문제
• 요구사항 반영 누락 (성능, 보안, 신뢰성 등)
• 부정확한 구현
• 비관련 기능 포함 (직접적인 장애를 유발하지 않음)

장애 (Failure)

• 요구사항과 다르게 동작
• 소프트웨어 구성 요소 부족으로 발생
• 결함이 있어도 항상 장애가 발생하는 것은 아님 ex)코드를 (a x b)로 해야 하는데 (a + b)로 작성함. 오류로 인해 결함이 있지만, 입력값 a=2,b=2 입력하면 결과값은 같기에 장애가 발생하진 않음.

---

테스트 품질

• 기능 적합성: 요구되는 기능을 만족하는 능력
• 성능 효율성: 적절한 자원 사용 및 반응 속도
• 호환성: 다른 시스템과의 상호 연동 능력
• 사용성: 사용자가 이해하고 배우기 쉬운 정도
• 신뢰성: 규정된 조건에서 오작동 없이 기능 수행
• 보안성: 정보 및 데이터를 보호하는 능력
• 유지보수성: 유지보수의 용이성
• 이식성: 다양한 플랫폼에서 운영 가능 여부 ISO25000 : ISO9126(소프트웨어 품질 평가 모델)과 ISO14598(소프트웨어 평가 절차 모델) 통합

---

테스트 기본 용어

• 테스트 대상: 결함을 검출하려는 대상 소프트웨어. 규모가 클수록 어렵고, 부분 테스트 후 통합 테스트가 효과적
• 피처(Feature): 테스트하고자 하는 측면과 관점
• 테스트 설계 기법: 정적 테스트(리뷰, 정적 분석), 동적 테스트(명세 기반, 구조 기반, 경험 기반)
• 테스트 절차(Procedure): 준비 → 실행 → 결과 관찰 → 기록
• 테스트 환경: 테스트 수행에 필요한 하드웨어, 소프트웨어 및 네트워크 구성 요소
• 테스트 스크립트(Script): 자동화 도구가 해석하고 실행하는 언어
• 테스트 케이스(Test Case): 입력과 대응되는 예상 결과를 묶어 부르는 말. 입력값,입력값을 테스트 대상에게 제공하는 방법, 예상 결과,실제 결과 를 비교하는 방법도 포함됨

---

테스트 분류

테스트 레벨

• 컴포넌트/단위 테스트(모듈): 모듈별 개별 테스트
  • 시스템을 구성하는 단위 모듈을 테스트 대상으로 해서 개별 단위 모듈을 독립적으로 테스트
  • 개발자, 품질 관리자, 외부인
  • 테스트 환경을 테스트 베드라고 함
  • 컴포넌트 1을 테스트 할 때, 0과 2에 의존하지 않게 드라이버(0 대신)와 스텁(2 대신) 이용
  • 모의(mock) 객체는 스텁의 객체 지향 버전
  • FIRST 원칙 : Fast, Isolated, Repeatable, Self-Validating, Timely

• 통합 테스트(설계): 모듈 간 통합 후 상호 작용 검증

  • 시스템을 구성하는 단위 모듈을 정확하게 통합했는지에 초점
  • 시스템 내부 구성 모듈과 이들 간의 관계를 정의한 구조 설계 명세서를 바탕으로 테스트 진행
  • 개발자, 품질 관리자, 외부인
  • 여러 모듈의 묶음을 클러스터 또는 빌드라고 함
  • 점진적 - 상향식 통합 : 하위 컴포넌트 충분히 테스트, 스톱을 제공하는 비용이 들지 않음
  • 점진적 - 하향식 통합 : 테스트 스텁이 실제 모듈로 대치, 리그레션 테스트 수행, 테스트 스텁 필요
  • 샌드위치 통합

• 시스템 테스트(분석): 전체 시스템이 요구사항을 충족하는지 확인,개발자,품질 관지라,외부인 (명세서 기반 테스트)

• 인수 테스트(요구사항 정의): 사용자 관점에서(요구사항 정의) 시스템 검증 (알파/베타 테스트) 알파 : 선택된 사용자가 개발자 환경에서 통제된 상태로 수행
  베타 : 일정 수의 사용자에게 소프트웨어를 사용하게 하고 피드백을 받음(보통 개발자 참여X)

테스트 유형

• 기능 테스트: 요구사항 만족 여부 확인
• 성능 테스트: 응답 시간, 처리량 검증
• 호환성 테스트: 다른 시스템과의 연동 능력
• 사용성 테스트: 사용자 친화성 평가
• 신뢰성 테스트: 특정 조건에서 안정적 동작 여부 확인
• 보안성 테스트: 정보 보호 및 접근 제어 검증
• 유지보수성 테스트: 유지보수 용이성 평가
• 이식성 테스트: 다양한 환경에서의 실행 가능성 확인

테스트 설계

• 정적 테스트(Static Testing): 실행 없이 분석하는 테스트 기법,코드 리뷰, 워크스루, 인스펙션, 정적 분석 도구 사용,문서 검토 및 요구사항 검토 포함
• 동적 테스트(Dynamic Testing): 실제 프로그램을 실행하여 결함을 찾는 테스트 기법,명세 기반 테스트, 구조 기반 테스트, 경험 기반 테스트 포함,테스트 케이스 실행 후 결과 확인

---

테스트 방법

마이어스 원칙

• 테스트는 개발자와 독립된 그룹이 수행해야 함
• 모든 경우를 고려하여 테스트해야 함
• 결함이 발견된 부분에서 추가 결함 가능성 높음 (파레토 법칙)
• 체계적인 테스트 케이스 관리 필요

갤퍼린과 헤첼 5단계

1. 디버깅: 개발 환경에서 오류 해결
2. 기능 검증: 올바른 동작을 입증
3. 결함 탐색: 오류가 있음을 보여주는 테스트 수행
4. SDLC 전 단계 테스트
5. 결함 예방: 테스트 용이성 고려한 개발

재테스팅 및 리그레션 테스트

• Retest-All: 기존 테스트 케이스 전부 수행 (비용, 시간 많이 소요)
• 선택적 리그레션 테스트: 변경 영향이 있는 부분만 테스트
• 테스트 최소화: 중복 제거 후 최소 테스트 케이스 유지
• 테스트 우선순위화: 우선순위 높은 테스트 케이스 먼저 수행 (APFD 사용)
  APFD (Average Percentage of Faults Detected, 평균 결함 검출율)

• ( n ): 전체 테스트 케이스 개수
• ( m ): 발견된 전체 결함 개수
• ( T_i ): i번째 결함이 처음 발견된 테스트 케이스의 위치

APFD 값의 범위:

• 0 ≤ APFD ≤ 1
• APFD 값이 1에 가까울수록 테스트 케이스의 결함 검출 효율이 높음

---

소프트웨어 생명주기 모델과 테스팅

폭포수 모델(Waterfall Model) (순차적 모델)

• 요구사항 분석 → 설계 → 구현 → 테스트
• 요구사항 분석 : 요구사항을 수집하고 이해, 명세화. 산출물로는 요구사항 명세서가 있음
• 구조 설계 단계 : 소프트웨어의 전체적인 구조를 결정하는 단계. 시스템의 전체적인 아키텍처를 보여주는 설계 명세
• 상세 설계 단계 : 각 모듈의 알고리즘 세부사항, 데이터 표현, 루틴과 데이터 간 인터페이스 결정, 상세 설계 명세
• 코딩 : 주요 산출물은 프로그램
• 테스팅 : 완성된 시스템의 결함을 검출하기 위해 테스트 수행
• 개발 완료 후 테스트 수행

V 모델(V-Model) (순차적 모델)

• 개발 시작과 함께 테스트도 병행 수행
• 각 단계에서 발생할 수 있는 결함을 검출
• V 모델의 V는 Verification & Validation 의미
• 컴포넌트/단위 테스트, 통합 테스트, 시스템 테스트, 인수 테스트

나선형 모델(Spiral Model) (진화적 모델)

• 핵심 기능 개발 후 반복적 개선
• 위험 분석 및 프로토타입 개발 반복
• 요구사항이 명확하지 않은 경우 사용
• 각 이터레이션마다 테스트 수행 계획을 작성하고 이 계획에 따라 테스트 수행
• 요구사항 분석 단계와 설계 단계에서 테스트 대상은 요구사항 문서나 설계 문서
• 반복적으로 요구사항을 정제하고 확장하는 과정에서 사용자가 받아들일 수 있는 완전한 시스템 개발까지 반복
• 프로토 타입을 개발하고 그에 대한 테스트 및 사용자의 평가를 거쳐 다음 개발 주기 시작
• 이 과정이 반복되면서 기능이 파악되는 시점에 V 모델에 따라 시스템 개발

애자일 모델(Agile Model)

• 반복적이고 점진적인 개발
• 사용자의 빠른 피드백 반영 가능
• XP(extreme programming), 스크럼 등이 포함됨
• IID는 소프트웨어 개발 주기를 여러 개의 이터레이션으로 구분
• 요구분석, 설계, 구현, 및 테스트와 같은 활동들로 구성된 소규모 프로젝트라고 볼 수 있음
• 이터레이션에서 산출된 시스템은 내부 개발자가 관리하는 것
• 사용자에게 외부적으로 릴리즈되는 것은 최종 반복 주기의 산출물
• 이터레이션이 짧아서 고객이 실제 동작하는 것을 빠르게 볼 수 있어 일의 진척 정도를 눈으로 확인할 기회가 많음
• 애자일 방법 중 XP(extreme programming)는 프로그래머가 과도한 작업을 피하는 것을 매우 중요하게 봄
• 짝 프로그래밍을 통해 개발자 간의 지식 전달 및 공유를 꾀함

프로토타입 모델(Prototype Model)

• 사용자의 요구사항을 명확히 하기 위해 초기에 시제품(프로토타입)을 빠르게 개발
• 요구사항이 불확실하거나 변경 가능성이 큰 프로젝트에 적합
• 사용자와 지속적인 피드백을 주고받으며 점진적으로 개선
• 프로토타입을 바탕으로 최종 시스템을 개발하여 품질 향상
• 개발 과정에서 설계와 구현이 반복적으로 이루어짐
• 최종 시스템이 확정되기 전까지 문서화가 부족할 가능성이 있음
• 과도한 수정 및 반복으로 인해 개발 비용과 시간이 증가할 위험 존재
• 초기 프로토타입은 실제 시스템과 성능 차이가 있을 수 있음
• UI/UX 중심의 개발 프로젝트에서 자주 활용됨

---

테스트 주도 개발 (TDD)

1. 테스트 케이스 작성 → 2. 코드 작성 → 3. 테스트 실행 및 리팩토링
   • 지속적 통합 (CI)과 함께 사용
   • 빠른 결함 발견 및 코드 품질 개선

---

정리

테스트 개념	설명
오류 (Error)	사람의 실수로 인해 발생하는 문제
결함 (Defect)	에러로 인해 발생한 로직상의 문제
장애 (Failure)	소프트웨어가 정상적으로 동작하지 않는 현상
기능 적합성	요구사항 충족 여부
성능 효율성	반응 속도 및 자원 활용도
호환성	다른 시스템과의 연동 가능 여부
유지보수성	유지보수 용이성
테스트 레벨	단위 테스트, 통합 테스트, 시스템 테스트, 인수 테스트
테스트 방법	정적 테스트, 동적 테스트
생명주기 모델	폭포수, V 모델, 나선형 모델, 애자일