반응형
2장. 소프트웨어 개발 수명주기와 테스팅 목차
소프트웨어 개발 수명주기 모델
- 소프트웨어 개발과 소프트웨어 테스팅
- 정황에 따른 소프트웨어 개발 수명주기 모델
테스트 레벨
- 컴포넌트 테스팅
- 통합 테스팅
- 시스템 테스팅
- 인수 테스팅
테스트 유형
- 기능 테스팅
- 비기능 테스팅
- 화이트박스 테스팅
- 변경 관련 테스팅
- 테스트 유형과 테스트 레벨
유지보수 테스팅
- 유지보수가 필요한 상황
- 유지보수를 위한 영향도 분석
소프트웨어 개발 수명주기 모델
소프트웨어 개발과 소프트웨어 테스팅
모든 소프트웨어 개발 수명주기 모델에 적용하기 좋은 테스팅의 특성
- 모든 개발 활동은 그에 상응하는 테스트 활동이 있다.
- 각 테스트 레벨은 그 레벨에 맞는 구체적인 목적을 갖는다.
- 주어진 테스트 레벨에 맞는 테스트 분석과 설계는 개발 활동이 이뤄지는 동안 시작
- 테스터가 요구사항과 설계의 정의와 개선을 위한 대화에 참여하고, 작업 산출물(요구사항, 설계, 사용자 스토리)의 초안이 나오는 즉시 리뷰에 참여한다.
대표적인 소프트웨어 개발 수명주기 모델
- 순차적 개발 모델
- 개발 프로세스의 모든 단계는 이전 단계가 완료될 때 시작돼야 한다.
- 폭포수 모델에서는, 개발 활동(예: 요구사항 분석, 설계, 코딩, 테스팅)이 순차적으로 이루어진다. 이 모델에서의 테스트 활동은 모든 개발 활동을 완료한 후에 이루어진다.
- V-모델은 테스팅을 초기에 시작하면 좋다는 원리로 테스트 프로세스를 전반적인 개발 프로세스에 통합한다
- 점진적 개발 모델
- 요구사항 정의, 시스템의 설계, 구축, 테스팅을 조각으로 나눠서 진행한다. 따라서, 소프트웨어 기능은 점진적으로 늘어나게 된다.
- 반복적 개발 모델
- 기능 집합을 종종 고정된 기간의 일련의 주기 안에서 같이 명시, 설계, 구축, 테스트할 때 발생한다.
- 대표적인 예시
- 래셔널 통합 프로세스: 반복주기가 상당히 길며, 따라서 기능 증분도 상당히 큼 (연관된 기능 그룹)
- 스크럼: 반복주기가 짧으며 따라서 기능 증분도 작음 (몇 가지 개선 사항 혹은 2, 3 개의 신규 기능)
- 칸반: 반복주기 기간이 고정된 경우와 고정되지 않은 경우가 있으며, 각 반복주기는 완료 후 하나의 개선 사항이나 기능을 전달하거나 몇 개의 기능을 묶어 한번에 전달할 수도 있음
- 나선형: 실험적인 증분을 생성, 일부는 차후 개발 과정에서 상당 부분 수정되거나 심한 경우 폐기되기도 함
정황에 따른 소프트웨어 개발 수명주기 모델
SW 개발 생명주기 모델은 프로젝트의 정황과 제품 특성에 따라 선택하고 적용해야 한다.
SW 개발 모델이 프로젝트 및 제품 특성의 맥락에 맞게 조정되어야 하는 이유
- 시스템의 제품 리스크의 차이(복잡하거나 간단한 프로젝트)
- 많은 사업부가 프로젝트나 프로그램의 일부일 수 있다.(순차적 및 애자일의 조합)
- 제품의 짧은 출시 기간(테스트 레벨에서 테스트 유형의 통합 및 테스트 레벨 병합)
테스트 레벨
| 테스트명 | 테스트 설명 |
| 컴포넌트 테스트 | 단위 테스트라고도 불리며 구현 단계에서 각 모듈이 완성되었을 경우 해당 개념적 모듈을 시험 하는 것 |
| 통합 테스트 | 각 단위모듈을 통합하여 테스트하는 것, 각 모듈은 단위테스트에서 시험 했지만 모듈들이 연계 통합하는 상호작용은 시험하지 못했으므로 이를 통합테스트에서 시험함 |
| 시스템 테스트 | 모듈간의 통합 시험이 완료된 후 사용자의 요구사항이 시스템 자원(프로그램, 하드웨어, 기타환경)에 모두 반영되었는지를 시험하는 것 |
| 인수 테스트 | 시스템이 사용자에게 인수되기 바로 직전에 사용자에 의해 실시되는 시험 |
| 설치 테스트 | 프로그램, 장비 등이 잘 설치되었는지를 시험하는 것 |
컴포넌트 테스팅
| 구분 | 설명 |
| 설명 | 단위 테스트라고도 불리며 구현 단계에서 각 모듈이 완성되었을 경우 해당 개념적 모듈을 시험 하는 것 소프트웨어 개발 수명주기 모델과 시스템에 따라 개별적으로 이루어지는 경우가 많으며, 그럴 경우 목 오브젝트(mock object), 서비스 가상화(service virtualization), 하네스(harness), 스텁(stub), 드라이버(driver) 등이 필요할 수도 있다. |
| 목적 |
|
| 테스트 베이시스 |
|
| 테스트 대상 |
|
| 대표적인 결함과 장애 |
|
| 구체적 접근법과 책임 | 일반적으로 컴포넌트 테스팅은 코드를 작성한 개발자가 수행하지만, 다른 사람이 수행하더라도 최소한 테스트 대상 코드에 접근할 수 있어야 한다. |
통합 테스팅
| 구분 | 설명 |
| 설명 | 컴포넌트간의 인터페이스를 테스트 하는 것은 물론 OS, 파일시스템 등 다른 부분과 연동하는 동작 테스트 |
| 목적 |
|
| 테스트 베이시스 |
|
| 테스트 대상 |
|
| 대표적인 결함과 장애 |
|
| 구체적 접근법과 책임 | 통합 테스트는 통합 자체에 집중해야 한다. 모듈 A 와 모듈 B 를 통합하는 경우, 모듈 간의 커뮤니케이션에 테스트를 집중해야 하며 컴포넌트 테스팅에서 커버했어야 할 개별 모듈의 기능에 초점을 맞춰서는 안 된다. |
시스템 테스팅
| 구분 | 설명 |
| 설명 | 시스템 테스트는 시스템 전체를 테스트하는 것을 의미하며 시스템이 예상대로 작동하는지 확인하기 위해 모든 모듈 / 구성 요소가 통합됩니다. |
| 목적 |
|
| 테스트 베이시스 |
|
| 테스트 대상 |
|
| 대표적인 결함과 장애 |
|
| 구체적 접근법과 책임 | 시스템 테스팅은 일반적으로 명세에 과도하게 의존하는 독립적인 테스터가 수행한다. 명세 결함(예: 누락된 사용자 스토리, 잘못 기술된 비즈니스 요구사항 등)은 기대하는 시스템 동작에 대한 이해 부족이나 의견 불일치를 가져올 수 있다. |
인수 테스팅
| 구분 | 설명 |
| 설명 | 인수 테스트란, 실제 사용자 환경에서 사용자의 입장으로 테스트를 수행하는 것을 말하며 시스템의 인수를 위해 기능적/비기능적 요구사항을 사용자가 직접 테스트하여 개발이 완료되었음을 증명하는 테스트이다. |
| 목적 |
|
| 형태 |
|
| 테스트 베이시스 |
|
| 테스트 대상 |
|
| 대표적인 결함과 장애 |
|
| 구체적 접근법과 책임 | 인수 테스팅은 주로 고객, 비즈니스 사용자, 제품 소유자, 혹은 시스템 운영자가 담당하며, 기타 이해관계자가 참여하는 경우도 있다. |
테스트 유형
| 테스트명 | 테스트 설명 |
| 기능 테스팅 | 고객의 기능적 요구사항을 중점적으로 테스트 하는 것이며 요구사항에 따른 기능의 구현 여부 및 동작 여에 대해 테스트한다. |
| 비기능 테스팅 | 고객의 성능적 요구사항을 중심적으로 테스트하며 비기능적 요소인 성능, 신뢰성, 안전성, 유요성, 적합성 등을 테스트한다. |
| 화이트 박스 테스팅 | 제품의 내부 요소들이 명세서에 따라 수행되고 충분히 실행되는가를 보장하기 위한 테스트이다. |
| 변경 관련 테스팅 | 결함, 수정 또는 기능 추가, 개선 등과 같은 이유로 시스템 변경 시 해당 변경이 결함을 제대로 수정했는지, 기능을 올바르게 구현했는지 또 예상치 못한 부작용이 발생하진 않았는지 확인하기 위한 테스트이다. |
유지보수 테스팅
소프트웨어와 시스템이 생산 환경으로 배포되고 나면 유지보수가 필요하다. 배포된 소프트웨어와 시스템에 대한 다양한 변경은 거의 필연적으로 발생한다. 이런 변경으로는 운영 중 발견한 결함 수정, 신규 기능 추가, 기존 기능의 삭제나 개선 등이 있다. 유지보수는 컴포넌트나 시스템의 수명 동안 그것의 비기능 품질 특성을 보존 혹은 개선하기 위해서도 필요하다. 특히 성능 효율성(performance efficiency), 호환성(compatibility), 신뢰성(reliability), 보안성(security), 이식성(portability)에 대한 보존이나 개선이 필요하다.
유지보수가 필요한 상황
계획됐든 계획되지 않았든, 소프트웨어 유지보수, 즉 유지보수 테스팅이 이루어지게 되는 원인은 다양하다.
유지보수의 계기의 분류
- 현재 시스템을 개선하거나 수정, 긴급적으로 변경, 운영 환경을 변경(업그레이드), 결함 및 취약성을 위한 패치 등 다양한 요인으로 인해 유지 보수가 필요한 경우가 있다.
- 하나의 플랫폼에서 다른 플랫폼으로 이관하는 경우 신규 환경에 대한 운영 테스트가 필요할 수 있으며 해당 신규 환경에 적합한 데이터 전환 테스트 등이 필요하다.
- 현재 릴리즈 중인 애플리케이션이 해당 휴대폰 기종에 적합하지 않을 경우(예: 단종), 데이터 이관이나 장시간의 데이터 유지가 필요하면 보관 처리에 대한 테스팅이 필요할 수 있다. (차후 복원/회수 절차에 대한 테스팅도 필요)
유지보수를 위한 영향도 분석
영향도 분석은 유지보수 릴리스에 포함된 변경을 평가해서, 의도한 결과뿐만 아니라 변경으로 인해 발생할 수 있는 예견된 부작용을 식별하고, 변경의 영향을 받는 시스템 영역을 식별하기 위해 실시한다. 영향도 분석은 변경이 기존 테스트에 미치는 영향을 식별하기 위해 사용할 수 있다.
영향도 분석이 어려운 경우
- 명세(예: 비즈니스 요구사항, 사용자 스토리, 아키텍처)가 너무 오래 됐거나 없는 경우
- 테스트 케이스가 문서화되어 있지 않거나 너무 오래된 경우
- 테스트와 테스트 베이시스 간 양방향 추적성이 유지되지 않은 경우
- 도구 활용이 적거나 없는 경우
- 연관된 인원이 도메인이나 시스템 지식을 가지고 있지 않은 경우
- 소프트웨어의 개발 중 유지보수성에 충분히 신경을 쓰지 못한 경우
반응형
'자격증 > CTFL' 카테고리의 다른 글
| [ISTQB] 6장 테스트 관리 (0) | 2022.12.30 |
|---|---|
| [ISTQB] 5장 테스트 관리 (0) | 2022.12.30 |
| [ISTQB] 4장 테스팅 기법 (0) | 2022.12.30 |
| [ISTQB] 3장 정적 테스팅 (0) | 2022.12.29 |
| [ISTQB] 1장 테스팅의 기초 요약 (0) | 2022.12.29 |