[ISTQB] Chapter 2. 소프트웨어 개발 수명주기와 테스팅

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

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

 

[소프트웨어 개발 활동과 테스트 활동의 관계]

- 각 개발 활동에 대응하는 테스팅 활동이 있어야 한다.

- 문서의 초기 버전이 작성되면 리뷰를 시작해야 한다.

- 각 테스트 레벨은 그 레벨에 맞는 구체적인 목적을 가진다.

- 테스트 분석과 설계는 대응하는 개발 단계에 시작해야 한다.

- 테스팅 활동은 소프트웨어 개발 수명주기의 초기 단계에 시작해야 한다.

 

 

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

 

1. 순차적 개발 모델 : sw 개발 프로세스를 1차원적 선형의 순차적 활동으로 설명함. -> 모든 단계는 이전 단계가 완료될 때 시작돼야 함.

 

2. 폭포수 모델 : 개발 활동이 순차적으로 이루어짐. -> 테스트 활동은 모든 개발 활동을 완료한 후에 이루어짐.

(V-모델은 테스팅을 초기에 시작하면 좋다는 원리를 토대로 테스트 프로세스를 전반적인 개발 프로세스에 통합함)

 

3. 점진적 개발 : 요구사항 정의, 시스템의 설계, 구축, 테스팅을 조각으로 나눠서 진행함. -> sw 기능이 점진적으로 늘어남. 늘어나는 크기는 다양하게 설정할 수 있음.

 

4. 반복적 개발 : 기능 집합을 종종 고정된 기간의 일련 주기 안에서 명시, 설계, 구축, 테스트할 때 발생함. -> 소프트웨어의 기능은 반복주기 횟수가 늘어남에 따라 점차 늘어남.

(ex) 래셔널 통합 프로세스, 스크럼, 칸반, 나선형

 

"순차적 모델과는 다르게 반복적 점진적 모델은 사용가능한 소프트웨어를 몇 주, 또는 며칠 만에 전달할 수 있다."

 

 

 

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

 

 

 

🟡 2.2 테스트 레벨

 

 

✅ 2.2.1 컴포넌트 테스팅(단위 테스팅)

 

-> 개별적으로 테스트할 수 있는 컴포넌트에 초점을 맞춤.

 

[목적]

- 리스크 완화

- 컴포넌트의 기능과 비기능 동작이 설계 및 명세와 일치하는지 여부 판단

- 컴포넌트 품질 수준에 대한 자신감 획득

- 컴포넌트에 존재하는 결함 발견

- 다음 단계로의 결함 전이 방지

 

* 점진적 반복적 개발 모델에서는 리그레션 테스트(기존 컴포넌트가 손상되지 않았다는 것을 확인)가 중요한 역할을 함.

 

 

[테스트 베이시스]

- 상세 설계

- 코드

- 데이터 모델

- 컴포넌트 명세

 

 

[테스트 대상]

- 컴포넌트, 단위, 모듈

- 코드 및 데이터 구조

- 클래스

- 데이터베이스 모듈

 

 

[대표적인 결함과 장애]

- 잘못된 기능

- 데이터 흐름 문제

- 잘못된 코드 및 논리

 

 

[구체적인 접근법과 책임]

코드를 작성하는 개발자 외에 다른 사람이 컴포넌트 테스팅을 수행하더라도, 테스트 대상 코드에 접근할 수 있게 해야함.

 

 

 

✅ 2.2.2 통합 테스팅

 

-> 컴포넌트나 시스템 간의 상호작용에 초점을 맞춰서 진행

 

[목적]

- 리스크 완화

- 인터페이스의 기능과 비기능 동작이 설계 및 명세와 일치하는지 여부 판단

- 인터페이스 품질 수준에 대한 자신감 획득

- 결함 발견

- 다음 단계로의 결함 전이 방지

 

* 컴포넌트 통합 테스팅 : 통합된 컴포넌트 간의 상호운용성과 인터페이스에 초점을 맞춤.

* 시스템 통합 테스팅 : 시스템, 패키지, 마이크로 서비스 간의 상호운용성과 인터페이스에 초점을 맞춤.

 

 

[테스트 베이시스]

- 소프트웨어 및 시스템 설계

- 시퀀스 다이어그램

- 인터페이스 및 통신 프로토콜 명세

- 유스케이스

- 컴포넌트나 시스템 레벨의 아키텍처

- 워크플로우

- 외부 인터페이스 정의서

 

 

[테스트 대상]

- 서브시스템

- 데이터베이스

- 인프라

- 인터페이스

- APIs

- 마이크로서비스

 

 

[대표적인 결함과 장애]

<컴포넌트 통합 테스팅>

- 잘못된 데이터, 누락된 데이터, 잘못된 데이터 인코딩

- 잘못된 인터페이스 콜 순서나 타이밍

- 인터페이스 불일치

- 컴포넌트 간의 통신 장애

- 컴포넌트 간의 통신 실패처리 누락 및 오류

- 컴포넌트 간 주고받는 데이터의 의미, 단위, 경계에 대한 잘못된 가정

 

<시스템 통합 테스팅>

- 시스템 간의 일관적이지 않은 메시지 구조

- 잘못된 데이터, 누락된 데이터, 잘못된 데이터 인코딩

- 인터페이스 불일치

- 시스템 간의 통신 장애

- 시스템 간의 통신 실패처리 누락 및 오류

- 시스템 간 주고받는 데이터의 의미, 단위, 경계에 대한 잘못된 가정

- 필수 보안 규정 준수 실패

 

 

 

[구체적인 접근법과 책임]

-> 통합 자체에 집중해야 함. 기능, 비기능, 구조적 테스트 유형이 적용될 수 있음.

-> 통합을 점진적으로 진행해야 함.(결함 격리를 좀 더 수월하게 하고 결함을 일찍 발견하기 위함)

 

컴포넌트 통합 테스팅 : 개발자의 책임

시스템 통합 테스팅 : 테스터의 책임

 

 

 

✅ 2.2.3 시스템 테스팅

 

-> 전체 시스템 또는 제품의 동작이나 능력에 초점을 맞추고 시스템이 수행할 엔드-투-엔드 작업과 비기능 동작을 고려함.

 

[목적]

- 리스크 완화

- 시스템의 기능과 비기능 동작이 설계 및 명세와 일치하는지 여부 판단

- 전체 시스템 품질 수준에 대한 자신감 획득

- 결함 발견

- 상위 테스트 레벨이나 생산 단계로의 결함 전이 방지

- 완성된 시스템이 기대한 대로 동작하는지 확인

 

 

[테스트 베이시스]

- 시스템 및 소프트웨어 요구사항 명세

- 리스크 분석 보고서

- 유스케이스

- 에픽(epic)과 사용자 스토리

- 시스템 동작 모델

- 상태 다이어그램

- 시스템 및 사용자 매뉴얼

 

 

[테스트 대상]

- 애플리케이션

- 하드웨어/소프트웨어 시스템

- 운영 시스템

- 테스트 대상 시스템

- 시스템 설정과 설정 데이터

 

 

[대표적인 결함과 장애]

- 잘못된 기능

- 데이터 흐름 문제

- 잘못된 코드 및 논리

 

 

[구체적인 접근법과 책임]

- 시스템의 end-to-end 동작

- 명세에 의존하는 독립적인 테스터가 시스템 테스팅을 수행

- 웹 페이지의 모든 경로를 확인(화이트박스 테스팅)

 

 

 

✅ 2.2.4 인수 테스팅

 

[목적]

- 시스템의 기능과 비기능 동작이 명세대로 작동하는지 검증

- 컴포넌트의 기능과 비기능 동작이 설계 및 명세와 일치하는지 여부 판단

- 완성된 시스템이 기대한 대로 동작하는지 확인

 

* 인수 테스팅 종류 *

1) 사용자 인수 테스팅(UAT) : 실제 또는 시뮬레이션된 운영 환경에서 사용자가 사용하기에 얼마나 적합한지 확인

2) 운영 인수 테스팅(OAT) : 생산 환경에서 이루어지는 테스트(운영자 또는 시스템 관리 직원에 의해 수행됨)

 

 

3) 계약 및 규제 인수 테스팅 : 계약서에 명시된 인수 조건을 가지고 수행

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 유지보수를 위한 영향도 분석

 

영향도 분석 : 유지보수 릴리스에 포함된 변경을 평가해서, 의도한 결과 뿐 아니라 변경으로 인해 발생할 수 있는 예견된 부작용을 식별하고 변경의 영향을 받는 시스템 영역을 식별하기 위해 실시

"변경이 기존 테스트에 미치는 영향을 식별하기 위해 사용"

 

<영향도 분석이 어려운 경우>

- 명세가 너무 오래됐거나 없는 경우

- 테스트 케이스가 문서화되어 있지 않거나 너무 오래된 경우

- 테스트와 테스트 베이시스 간 양방향 추적성이 유지되지 않은 경우

- 도구 활용이 적거나 없는 경우

- 연관된 인원이 도메인이나 시스템 지식을 가지고 있지 않은 경우

- 소프트웨어의 개발 중 유지보수성에 충분히 신경을 쓰지 못한 경우

 

 

 

 

 

 

Reference

ISTQB CTFL Syllabus 2018 V 3.1.1_한글_v1.0

 

위 책 내용을 챕터별 중요한 포인트 위주로 정리한 자료입니다.

스스로 공부하기 위한 요점정리 노트이므로 상업적인 사용 목적은 전혀 없음을 알려드립니다:)

 

이 시험에 대한 정보 및 각종 자료는 아래 사이트에서 확인하실 수 있습니다. ⬇⬇⬇

http://www.kstqb.org/sw/sw3.asp