[ISTQB-CTFL] CTFL(Foundation Level) 정리 #2 소프트웨어 개발 수명주기와 테스팅

제 2장 소프트웨어 개발 수명주기와 테스팅

2.1소프트웨어 개발 수명주기 모델

2.1.1      소프트웨어 개발과 소프트웨어 테스팅

수명주기 모델: 모든 개발 활동은 테스팅 활동과 대응

                      각 테스트 레벨은 그 레벨에 맞는 특정한 목적 존재

                      테스팅을 준비하고 개발 중간 산출물을 리뷰

순차적 개발 모델: 소프트웨어 개발 프로세스를 1차원적 선형의 순차적, 빠른 피드백

                      완성된 기능 세트를 포함한 소프트웨어 배포 가능

폭포수 모델: 모든 개발 활동을 완료한 후 실행, 개발 활동이 순차적

V-모델: 폭포수 모델 변형, 테스트 프로세스를 전반적인 개발 프로세스에 통합

대응하는 각 개발 단계에 테스트 레벨 부여하여 조기 테스팅을 적극적으로 구현

각 레벨의 테스트는 독립적인 테스트 수명주기

요구 분석 단계에서 테스트 케이스 작성하여 인수 테스트에 도움

점진적 개발 모델: 요구사항 정의, 시스템의 설계/구축/테스팅을 조각으로 나눠 진행

반복적 개발 모델: 기능 집합을 종종 고정된 기간의 일련의 주기 안에서 명시/설계/구축/테스트

                      전체 프로젝트 범위/기존 반복 주기 동안 개발한 기능에 대한 수정

                      개발 리스크 조기↓, 소프트웨어가 배포되거나 개발이 중단될 때까지 진행

                      Ex) 민첩 개발 모델, 래피드 애플리케이션 개발, 래셔널 통합 프로세스

 

2.1.2      정황에 따른 소프트웨어 개발 수명 주기 모델

프로젝트의 정황에 따라 테스트 레벨과 테스트 활동을 조합/조정

소프트웨어 개발 수명주기 모델 자체에 조합 가능

 

2.2 테스트 레벨

테스트 레벨: 함께 분류되고 관리되는 테스트 활동의 집합

2.2.1      컴포넌트 테스팅

컴포넌트 테스팅: 모듈 자체의 내부 결함을 발견, 개별적으로 테스트할 수 있는 컴포넌트에 초점

목적: 컴포넌트의 기능/비기능 동작 설계 및 명세와 일치 여부

테스트 베이시스: 상세 설계, 코드, 데이터 모델, 컴포넌트 명세, 프로그램 상세 설명서

테스트 대상: 컴포넌트, 단위, 모듈, 코드/데이터 구조, 클래스, 데이터베이스 모듈

대표적인 결함과 장애: 잘못된 기능, 데이터 흐름 문제, 잘못된 코드 및 논리

구체적인 접근법과 책임

 

2.2.2      통합 테스팅

통합 테스팅: 컴포넌트나 시스템 간의 상호작용에 초점, 실제 시스템과 유사한 테스트 환경

목적: 인터페이스의 기능/비기능 동작이 설계 및 명세와 일치 여부

테스트 베이시스: 소프트웨어 및 시스템 설계, 시퀀스 다이어그램, 인터페이스 및 통신 프로토콜 명세, 유스케이스, 컴포넌트나 시스템 레벨의 아키텍처, 워크플로우, 외부 인터페이스 정의서

테스트 대상: 서브시스템, 데이터베이스, 인프라, 인터페이스, APIs, 마이크로서비스

일반적인 결함과 장애: 컴포넌트 통합 테스팅, 시스템 통합 테스팅

구체적인 접근법과 책임: 컴포넌트 - 개발자, 시스템 통합 테스팅 – 테스터

V-모델: 하위 레벨 테스트

 

2.2.3      시스템 테스팅

목적: 블랙박스 테스트 위주로 수행, 시스템의 기능/비기능 동작이 설계 및 명시 일치 여부

상위 테스트 레벨/생산 단계로의 전이 방지

테스트 베이시스: 시스템 및 소프트웨어 요구사항 명세, 리스크 분석 보고서, 유스케이스, 에픽과 사용자 스토리, 시스템 동작 모델, 상태 다이어그램, 시스템 및 사용자 매뉴얼, 비즈니스 프로세스

테스트 대상: 애플리케이션, 하드웨어/소프트웨어 시스템, 운영 시스템, 테스트 대상 시스템, 시스템 설정과 설정 데이터

일반적인 결함과 장애, 블랙박스 테스트 위주로 수행

구체적인 접근법과 역할: 엔드-투-엔드 동작, 명세에 의존하는 독립적 테스터, 개발자가 수행

 

2.2.4      인수 테스팅

목적: 전체 시스템 또는 제품의 동작이나 능력에 초점 (백업, 유지보수, 보안 취약성 포함)

           테스트 베이시스가 확보되는 개발 초기 단계부터 시작, 비기능적 특성에 확신

사용자 인수 테스팅: 실제/시뮬레이션된 운영 환경에서 예정된 사용자가 사용하기 적합한지 확인

운영 인수 테스팅: 운영자 또는 시스템 관리자가 예외적이고 어려운 조건에서 정상 유지

계약 인수 테스팅: 사용자나 독립적인 테스터, 명시된 인수 조건을 가지고 수행

규제 인수 테스팅: 사용자나 독립적인 테스터, 준수해야하는 모든 규제를 수행

 

알파 및 베타 테스팅: 출시 전에 피드백을 받기

알파 테스팅: 신규/기존 고객, 운영자, 독립적인 테스터, 공장 인수 테스팅

베타 테스팅: 신규/기존 고객, 운영자가 실제 자신의 환경에서, 사이트 인수 테스팅

 

테스트 베이시스: 모든 형태의 인수 테스팅, 운영 인수 테스팅

일반적인 테스트 대상: 테스트 대상 시스템, 시스템 설정/데이터, 통합된 시스템의 비즈니스 프로세스, 복원 시스템이나 비즈니스 연속성 및 긴급 복구 테스팅을 위한 핫 사이트, 운영 및 유지보수 프로세스, 양식, 보고서, 기존/전환된 생산 데이터

구체적인 접근법과 역할

 

2.3 테스트 유형

테스트 유형: 특정 테스트 목적을 위해 소프트웨어 시스템이나 시스템의 일부 특정 속성을 테스트하는 활동의 집합

2.3.1      기능 테스팅

기능 테스팅: 시스템이 해야 하는 “무엇”, 시스템이 수행해야 하는 기능을 평가하기 위한 테스트

요구사항: 테스트 용이성, 작업 산출물에 설명, 문서를 기록되지 않는 경우도 존재

블랙박스 기법: 시스템의 기능에 대한 테스트 컨디션과 테스트 케이스 도출을 위해

 

2.3.2      비기능 테스팅

비기능 테스팅: 시스템이 “얼마나 잘” 동작, 시스템 특성을 평가(성능, 사용성, 유지보수성 등)

블랙박스 기법: 비기능 테스팅을 위한 테스트 컨디션과 테스트 케이스 도출을 위해

 

2.3.3      화이트박스(구조) 테스팅

화이트박스 테스팅: 시스템의 내부 구조나 구현을 기반으로 도출, 제어 흐름/메뉴 구조 모델

구조 커버리지: 특정 구조 요소가 테스트에 의해 어느 정도 실행되었는지

코드 커버리지: 컴포넌트 테스팅 레벨

 

2.3.4      변경 관련 테스팅

변경 관련 테스팅: 결함 수정, 기능 추가/개선이든 시스템이 변경되면 확인하기 위한 테스팅

확인 테스팅: 불합격했던 모든 테스트 케이스를 재실행

리그레션 테스팅: 결함 마스킹이나 변경 후에 다른 시스템에서 의도하지 않은 부작용 발견

 

2.3.5      테스트 유형과 테스트 레벨

기능 테스트:

비기능 테스트:

화이트박스 테스트:

변경 관련 테스트:

컴포넌트 테스팅, 컴포넌트 통합 테스팅, 시스템 테스팅, 시스템 통합 테스팅, 인수 테스팅에 적용

 

2.4 유지보수 테스팅

유지보수: 컴포넌트나 시스템의 수명 동안 비기능 품질 특성을 보존/개선하기 위해

성능 효율성, 호환성, 신뢰성, 보안성, 이식성에 대한 보존이나 개선

 

2.4.1      유지보수가 필요한 상황

개선을 위한 변경

이관을 위한 변경: 단종, 장시간의 보관이 필요한 경우 복원/회수 절차, 리그레션 테스팅

 

2.4.2      유지보수를 위한 영향도 분석

영향도 분석: 유지보수 릴리스에 포함된 변경을 평가, 변경이 기존 테스트에 미치는 영향을 식별