[CSTS 요약 정리] 1. 테스트 개요

테스트 개념 및 용어 7문제

테스트 목적

• 결함의 검출과 제품 품질 개선
• 품질 평가와 의사 결정 지원
• 개발 프로세스 개선 지원
• 정해진 요구사항을 만족하는지 확인, 주어진 표준을 준수하는지 검증하기 위해 수행
• 소프트웨어가 다양한 품질 기준에 맞춰서, 프로그램으로서 잘 실행되고 그 결과가 올바른지 판단하는 과정
• 에러를 발견하고, 그 에러를 개선하면서 소프트웨어의 전체적인 품질을 측정하는 일련의 활동

오류, 결함, 장애

오류

• 사람에 의해 발생하는 실수
• 요구사항을 제대로 파악하지 못한 실수
• 요구사항의 불이행, 코딩 및 타이핑 실수
• 요구사항 오류 : 사용자의 요구사항을 제대로 정의하지 못함, 의사소통 장애, 고의적 요구사항 누락
• 설계 오류 : 요구사항 설계 반영 시 누락 및 반영하지 못함
• 코딩 오류 : 개발을 잘 못함, 잘못된 요구사항 개발
• 기타 오류 : 기타 표준 사항을 준수하지 못함, 테스트 프로세스가 충분하지 않음

결함

• 에러로 발생한 잘못된 로직
• 소프트웨어 내에 장애를 유발할 수 있는 문제
• 누락 : 요구사항이 시스템의 구현에 반영되지 않은 결함/ 성능, 보안, 안전, 신뢰도 등 품질 요소에 관한 누락
• 부정확한 구현 : 요구사항이 부정확하게 반영 / 성능, 보안, 안전, 신뢰도 등 품질 요소에 관한 누락
• 비관련 : 요구 명세와 관련되지 않은 구현/ 직접적인 장애를 불러일으키지는 않음

장애

• 요구사항과 다르게 동작
• 소프트웨어를 구성하는 요소에 부족한 점이 있어서 발생
• 오작동은 결함에 의해 발생하지만, 결함이 있다고 반드시 오작동이 발생하는 것은 아님

 

 

테스트 품질

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

테스트 기본 용어

• 테스트 대상 : 규모가 클수록 難, 부분 테스트 후 통합하여 테스트 하는 게 효과적
• 피처 : 테스트하고자 하는 측면, 관점/ 테스트 계획 수립 시 식별되어 테스트 범위로 기술, 설계 활동으로 구체화
• 테스트 설계 기법 : 정적 테스트(리뷰, 정적분석), 동적 테스트(명세 기반, 구조 기반, 경험 기반)
• 테스트 절차 : 준비, 실행, 결과 관찰, 기록 / 검출된 결함 재연 시에도 사용 / 자동화 도구가 작성한 건 스크립트
• 테스트 환경 : 컴포넌트/단위 테스트 시 드라이브와 스텁 用, 도구도 테스트 환경에 포함

 

---

테스트 분류 11문제

테스트 분류 개요

• 테스트 레벨 : 컴포넌트/단위 테스트, 통합 테스트, 시스템 테스트, 인수 테스트
• 테스트 유형 : 기능 테스트, 품질 테스트
• 테스트 설계 : 정적 테스트, 동적 테스트

 

테스트 레벨

요구사항 정의 -> 분석- > 설계 -> 개발에 따라 적합한 테스트 유형이 있음

V 모델

컴포넌트/단위 테스트(모듈)

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

 

통합 테스트(설계)

점진적 방식

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

 

시스템 테스트(분석)

• 전체 시스템을 테스트 대상으로 함
• 요구사항 명세서에 명시된 대로 시스템이 동작하는지 확인하는 데에 초점
• 개발자, 품질 관리자, 외부인

인수 테스트(요구사항 정의)

• 전체 시스템을 하나의 단위로 보고 테스트 진행
• 시스템 테스트와 달리 고객/사용자의 관점에서 고객이 기대하는 방식으로 동작하는지 확인
• 사용자
• 알파 테스트 : 선택된 사용자가 개발자 환경에서 통제된 상태로 수행
• 베타 테스트 : 일정 수의 사용자에게 소프트웨어를 사용하게 하고 피드백을 받음(보통 개발자 참여X)

 

테스트 유형

• 기능 적합성 테스트 : 사용자의 요구사항을 만족하는 기능이 제공되는 정도. (완전성, 정확성 타당성) 
• 성능 효율성 테스트 : 시스템 응답 시간이나 처리량 테스트. (시간 행동, 자원 활용성, 수용성)
• 호환성 테스트 : 다른 시스템과의 상호 연동 능력이나 공존성 테스트. (공존성, 상호 운용성)
• 사용성 테스트 : 사용자가 이해하고 배우기 쉬운 정도 테스트. 
  (타당성 식별력, 학습성, 운용 용이성, 사용자 오류 보호, 사용자 인터페이스 미학, 접근성)
• 신뢰성 테스트 : 규정된 조건, 기간에 오작동 없이 수행하는 능력 테스트. (성숙성, 가용성, 장애 허용성, 회복 가능성)
• 보안성 : 시스템의 정보 및 데이터를 보호하는 능력 테스트 (기밀성, 무결성, 부인 방지, 책임성, 전문성)
• 유지보수성 : 소프트웨어 유지보수의 용이성 테스트 (모듈성, 재사용성, 분석성, 변경 용이성, 테스트 용이성)
• 이식성 : 다양한 플랫폼에서 운영될 수 있는 능력 테스트 (적응성, 설치 용이성, 대치 용이성)

 

---

테스팅 방법 7문제

테스트 방법

마이어스 원칙

• 테스트는 반드시 개발자와 무관한 그룹이 수행
• 결함이 발견되지 않으리라는 가정 하에 계획을 수립하면 안됨(갤퍼린과 헤첼 레벨 3)
• 타당한 경우 뿐만 아니라 타당하지 않고 예상하지 못한 경우도 테스트 수행
• 어떤 부분에 결함이 남을 확률은 그 부분에서 이미 발견된 결함의 수와 비례(파레토8020)
• 테스트 케이스를 체계적으로 관리
• 각각의 테스트 결과를 철저하게 점검

갤퍼린과 헤첼 5단계

• 레벨 1 : 디버깅, 개발 환경에서의 오류 해결
• 레벨 2 : 올바른 동작을 입증
• 레벨 3 : 오류가 있음을 보여주는 테스트
• 레벨 4 : Software Development Life Cycle 전 단계에서 오류 테스트
• 레벨 5 : 사전에 결함을 예방, 테스트 용이성 고려

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

유지보수 단계에서도 소프트웨어가 수정된 후 변경이 올바르게 되었는지 검사하기 위해 수행

유지보수 단계의 수정 : 결함 수정, 기능 보강, 적응, 예방

• Retest-All
  기존 개발된 모든 테스트 케이스 사용
  복잡한 테스트 절차를 요구하지는 않지만 많은 시간과 비용 필요
• 선택적 리그레션 테스트
  기존 테스트 케이스 중 일부만 선정하는 방식
  슬라이싱 기법, 자료 흐름 분석 기법같은 변경 영향 분석으로 다른 결과를 출력하는 테스트 케이스 식별
• 테스트 최소화
  중복된 테스트 케이스를 제거해서 테스트 케이스 수를 줄이는 방식, 커버리지 방식 사용
  영향을 받는 부분을 테스트 할 테스트 케이스가 제거될 위험이 있음
• 테스트 우선순위화
  테스트 케이스에 우선순위를 두고 우선 순위가 높은 테스트 케이스만 활용
  가능한 빨리 결함을 검출할 수 있도록 테스트 케이스의 실행 순서 결정 APFD 사용

APFD

 

 

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

• 순차적 생명 주기 모델일 경우 테스트 구현이 완료된 시점에 1회 수행
• 에자일 모델처럼 반복적이고 점진적인 모델에서는 테스트도 반복적, 점진적으로 수행
• 폭포수 모델에서는 개발 완료 후 테스트 시작
• V 모델은 개발 시작과 함께 테스트도 시작, 각 개발 단계에서 발생하는 결함을 검출할 수 있는 테스트 레벨 존재
• 진화적 개발 모델은 이터레이션과 점진적인 방식으로 개발 진행
  각 이터레이션은 순차적 모델처럼 요구사항 분석, 설계, 구현, 테스트와 같은 단계로 구성

 

모델 기반 테스팅

순차적 모델 - 폭포수 모델

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

순차적 모델 - V 모델

• V 모델의 V는 Verification & Validation 의미
• 컴포넌트/단위 테스트, 통합 테스트, 시스템 테스트, 인수 테스트

진화적 모델 - 나선형 모델

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

애자일 모델

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

테스트 주도 개발 TDD

• 테스트 케이스 작성을 가장 먼저 함
• 테스트를 통과하는 코드 작성 ( 필요 시 TDD 수행 중 리펙토링 수행 )
• 지속적 통합(CI)는 TDD와 더불어 애자일 개발에서 중요한 실천 규칙
• 리펙토링 : 기능을 변경하지 않고 코드 내부 구조를 개선하는 것
• 지속적 통합 : 빠른 결함 발견, 통합 지연X, 항상 빌드 가능한 소프트웨어 버전이 있어 품질에 대한 확신有