아래 내용들은 ISTQB FL 시험준비 & 테스팅공부를 위해 다음 출처의 자료들로 공부하며 정리한 것 입니다 *
출처 : 개발자도 알아야할 소프트웨어 테스팅 실무 제3판
출처 : 문제로 배우는 소프트웨어 테스팅 2
출처 : Certified Tester Foundation Level Syllabus version 2011 Korean
[1] 소프트웨어 개발 모델
테스팅은 소프트웨어 개발활동과 독립적으로 존재하지않고 밀접하게 연계되어있으므로,
개발수명주기모델에 기반하여 테스트 접근법을 다르게 적용해야한다
- V-모델 (순차적 개발 모델)
※ 참고 : 폭포수모델
폭포수 모델은 개발이 종료된 후 테스팅을 시작한다
폭포의 물이 위에서 아래로 떨어지듯이 계획, 분석, 설계, 구현, 테스트, 유지보수의 각 단계가 하향식(top-down)으로 진행되며, 병행되거나 거슬러 반복되지 않는다. 각 단계가 끝날 때마다 확실히 매듭을 짓고 그 결과를 확인한 후에 다음 단계로 진행한다.
https://terms.naver.com/entry.nhn?docId=3532871&cid=58528&categoryId=58528&expCategoryId=58528
폭포수 모델의 개발 절차
폭포수 모델에서는 폭포의 물이 위에서 아래로 떨어지듯이 계획, 분석, 설계, 구현, 테스트, 유지보수의 각 단계가 하향식(top-down)으로 진행되며, 병행되거나 거슬러 반복되지 않는다. 각 단계가 끝날 때마다 확실히 매듭을 짓고 그 결과를 확인한 후에 다음 단계로 진행한다. 폭포수 모델을 적용한 개발 절차에서는 요구 사항 분석 단계가 끝나면 '요구 분석 명세서'라는 문서가 산출된다. 이 명세서를 기준으로 사용자에게 이상 유무를 확인받고 다음 단계인 설계 절차로 넘어간다. 이렇게 각 단계에서 생성되는 산출물에 대해 확인 절차를 거...
terms.naver.com
https://terms.naver.com/entry.nhn?docId=3532872&cid=58528&categoryId=58528&expCategoryId=58528
폭포수 모델의 장점과 단점
폭포수 모델은 각 단계마다 요구 분석 명세서, 설계 사양서, 코드 문서, 데이터베이스 매뉴얼, 사용자 매뉴얼, 운영 매뉴얼 등의 상세한 문서가 생성되는 문서 중심의 모델이라 할 수 있다. 또 각 단계가 명확히 구분되어 있다. 각 단계에서는 산출물이 만들어지고 이 산출물은 다음 단계의 입력 자료로 사용된다. 따라서 해당 단계의 오류를 수정하지 않고 다음 단계로 넘어가면 그 오류가 끝까지 남을 수 있으므로 초기 단계에서 오류를 해결하는 것이 매우 중요하다. 소프트웨어 개발에서 폭포수 모델을 사용했을 때의 장점은 다음과 같다. ■ 관리가...
terms.naver.com
[출처 : 네이버 지식백과 (쉽게 배우는 소프트웨어 공학, 2015. 11. 30., 한빛아카데미(주))]
<V-모델>
※V-모델 그림 참고 (p.49)
폭포수 개발모델에 근간
개발 단계에 대응하는 테스트레벨이 별도로 존재. 하지만, 일대일 대응은 아니다.
각각의 개발단계에서 테스팅을 접근하는 방법을 간략히 모델화한 것
개발단계와 테스팅활동이 어떻게 통합될수 있는지 설명한다.
실제업무에 적용시에는 특성에 맞게 변형하여 사용한다.
- 실업무에서 프로젝트,소프트웨어제품의 특성에 따라 v모델에서의 개발단계 및 테스트레벨을 더 많이 혹은 더 적게 구성할 수 있다.
(에) 컴포넌트 테스팅 이후에 컴포넌트통합테스팅이있을 수 있고, 시스템테스팅 이후에 시스템통합테스팅이 존재할 수 있다.
- 소프트웨어 개발기간중의 '개발산출물(Work products)'은 하나이상의 테스트레벨에서 '테스트베이시스'가 된다.
(예) 일반적인 개발산출물 : CMMI, 소프트웨어 라이프 사이클 프로세스 참고. ??
- 테스트분석가는 요구사항을 명세화하는 시점에 맞춰 테스트분석,설계를 시작한다
<V-모델을 통한 테스팅의 기본개념>
1) 테스트레벨
- V-모델에서 제시하는 테스트레벨
(1) 컴포넌트(단위) / 통합 - 하위레벨
(2) 시스템 / 인수 테스팅 - 상위레벨
각 테스트레벨은 서로 독립적인 테스트 수명주기를 가진다. : 각각 다른 테스트전략,계획,기법,목적,수행주체,완료기준 등을 가진다.
각 테스트레벨은 서로 종속성을 지닌다. : 하나의 테스트레벨에서 다른 테스트레벨로 옮겨가기 위한 종료/시작조건을 갖춰야 한다.
2) 개발 초기 단계에서 테스팅을 수행
→ 정적 테스팅 (리뷰 등)
개발 산출물을 리뷰(Review)형태로 검토하면서 결함을 발견
개발이 시작됨과 동시에 진행한다
테스터는 테스팅관점에서 테스트케이스를 만들면서 결함을 발견하여 리뷰에 기여한다.
요구분석단계에서 테스트케이스를 작성해두면 인수테스팅시 많은 도움이 된다.
정적테스팅 : 결정테이블테스팅, 상태전이 테스팅, 유즈케이스 테스팅 ※4장. 설계기법 참고
3) 결함 예방차원에서의 테스팅
개발초기에 발견한 결함은 수정비용이 저렴
개발초기에 테스트 베이시스가 되는 개발 산출물을 리뷰, 조기에 테스트를 설계하여, 결함을 사전에 예방
4) V&V (베리피케이션 & 벨리데이션)
소프트웨어 개발 수명주기의 전(모든) 단계에서 수행가능
정적테스팅(인스펙션과 같은 리뷰활동) 또는 동적테스팅 모두에서 검증가능
(1)베리피케이션(Verification)
: 개발 단계의 산출물이 그 단계의 '초기에 설정된 조건'을 만족하는지 여부를 검증하는 프로세스
주어진 개발 단계의 제품이 그 단계에서 정의한 대로 조건을 만족하는지, 시스템이나 컴포넌트를 평가하는 프로세스.
ISO9000 : 명세된 요구사항이 충족됐는지를 조사에 의해서나 객관적증거제공으로 확인하는 것
수명주기초기에 발생하는 중간산출물에 대해 베리피케이션을 실시하여, 처음에 정의한 대로 조건을 만족하는 시스템이나 컴포넌트가 구현됐는지 사전에 일부검토가 가능하다.
이점 : 결함을 예방
(2)벨리데이션(Validation)
: 개발 중 또는 개발단계 말에 명시된 사용자의 관점에서의 '요구사항'이 만족하는 지를 평가하는 프로세스
- 반복적-점증적 개발모델 (Iterative-incremental)
※ 모델 그림 참고 (p.53)
개발주기(요구사항분석-시스템설계-구현 및 테스팅)가 짧게 연속적으로 '반복'하는 활동으로 이루어진다
초기반복단계에서 리스크가 높은 모듈이나 주요 아키텍처에 해당하는 시스템 일부를 우선적으로 개발, 테스팅한다
단위 테스트 프레임 워크 도구를 이용해 개발자가 테스트 주도 개발을 하는 것이 매우 중요하다.
(ex) 테스트 자동화 도구 도입을 통한 테스팅
하나의 반복단계에서 생성한 산출물(프로그램,시스템)은 일반적으로 테스트레벨을 거치면서 검증된다.
이전 반복단계에서 개발한 결과물은 현재의 반복에서 추가개발한 증분(증가된 부분)에 의해 규모가 커져 부분시스템(Partial system)을 형성한다.
이때, 현재반복단계의 증분도 테스팅해야하지만, 부분시스템역시 리그레션여부의 확인목적으로 테스팅해야한다.
리그레션테스팅 : 반복단계가 거듭될수록 중요해진다.
베리피케이션, 벨리데이션 : 각 증분산출물(부분시스템)을 대상으로 수행될 수 있다.
< 장점 >
(1) 조기에 결함과 장애를 발견하고 제거가능하다. (개발리스크를 조기에 감소)
(2) 요구사항이 변경되었을 때 빠르게 반영가능하다.
< 반복적 개발모델에서의 테스팅 이슈 >
: 초기개발단계에서의 테스팅 및 테스트환경과 개발이 반복진행되면서, 테스팅 및 테스트환경이 변경된다.
제한된 세트의 집중된 테스트에서, 광범위한 세트의 분산된 테스트로 확장
테스트 대상 컴포넌트가 점차 증가
단순한 테스트환경에서, 복잡한 테스트환경으로 변화
시간이 지남에 따라 개별 유즈케이스 테스팅에서, 유스케이스간의 통합 테스팅으로 변화
< 주요 모델 > : 반복적으로 개발하는 모델들
애자일 개발 모델 (민첩) (Agile) : XP(eXtreme Programming) , SCRUM 등
래셔널 통합 프로세스 : RUP (Rational Unified Process)
래피드 애플리케이션 개발 : RAD (Rapid Application Development)
이해 관계자 중심의 소프트웨어 개발 (Outside-in Software Development)
프로토타이핑 (Prototyping)
<애자일 테스팅 특징>
테스트를 미리 설계하지 않을 수 있으며, 누구나 테스트에 적극참여가능 (사용자,테스터,개발자)
결함을 최대한 빨리 발견가능 (요구사항을 개발과 동시에 발견가능)
문서를 최소화한다
테스트는 개발과 같이시작되거나 먼저시작되므로, 개발완료 = 테스트완료 이다.
- 개발 수명주기 모델 (Life Cycle)에서의 테스팅
- 테스트 레벨은 프로젝트, 시스템아키텍쳐의 성격에 따라 재조정, 합쳐질 수 있다
(예) 상용(COTS : Commercial Off The Shelf)소프트웨어 제품을 시스템에통합할때
구매자는 시스템레벨에서 통합테스팅 / 인수테스팅을 수행할 수 있다
통합테스팅 : 인프라나 다른 시스템에 통합, 배포된 시스템에 통합
인수테스팅 : 기능적 테스팅, 비기능적 테스팅, 사용자 테스팅, 운영 테스팅 등 수행
<성공적인 테스팅 요건>
모든 개발 활동은 이에 상응하는 테스팅활동을 동반한다
각 테스트 레벨은 그 레벨에 맞는 특정한 목적을 가지고 있다
주어진 테스트 레벨에 맞는 테스트의 분석과 설계는 대응되는 개발활동 동안에 시작되어야 한다
개발산출물 리뷰 : 개발 수명주기 동안에 개발 산출물의 초안이 작성되면, 테스터는 이러한 문서를 리뷰하는 활동에 참가해야 한다.
[2] 테스트 레벨(Test Levels)
< 각 테스트레벨 특징에 맞게 정의&식별되는 항목>
일반적인 목표 : 목적
테스트 케이스를 도출해내는데 참조되는 개발산출물 : 테스트베이시스
테스트 대상 : 테스트할 그 무엇
발견된 전형적 결함, 장애
테스트 하네스 (드라이버,스텁), 툴 필요여부
상세한 테스트 접근법
테스트 수행주체, 조직
<화이트박스&블랙박스 테스팅>
컴포넌트 테스팅 - 화이트박스
시스템 테스팅 - 블랙박스
- 컴포넌트 테스팅(Component Testing) = 단위 테스팅(Unit Testing) = 모듈 테스팅 = 프로그램 테스팅
: 테스트가 가능한 최소단위로 나누어진 소프트웨어 (모듈,프로그램,객체,클래스 등) 내에서 결함을 찾고 그 기능을 검증하는 것
- 개발 수명주기의 정황과 시스템에 의존적이면서도 시스템의 다른부분에서 격리하여 독립적으로 수행할 수 있다.
이떄, 스텁, 드라이버, 시뮬레이터가 사용될 수 있다.
테스트케이스는 개발산출물에서 도출된다 : 컴포넌트명세, 소프트웨어상세설계, 데이터모델과 같은 개발산출물
일반적으로 코드를 중심으로 수행하며, 개발환경의 지원을 필요로 한다 : 단위테스트프레임웍, 디버깅 툴과 같은 개발환경
실무에서 개발자가 직접 테스트에 참여하여 결함을 바로수정하며, 기록과정은 일반적으로 생략한다.
그러나 프로세스관리,개선을 위해 결함에 대한 통계적 데이터가 필요한 경우는 인시던트(결함) 기록과정이 필요하다
테스트 중심의 개발방법론 (Test-first approach / test driven development) : 코딩전 테스트케이스를 준비하고 자동화하는 방법이다. 반복적성향이 매우 강한 접근법으로 테스트케이스를 개발한 후 작은 규모의 코드를 작성, 통합하고 테스트가 통과할 떄까지 반복수행한다.
V모델에서 하위레벨 테스트에 속한다.
테스팅
주된 테스팅 방식 : 구조기반테스팅(화이트박스)
구조적 : 분기커버리지등
기능성
비기능성 : 리소스 메모리유출 관련, 강건성 테스팅 등..
- 수행주체
: 주로 개발자가 직접, 타개발자, 제3자 테스터
<목적>
기본경로(Path)확인
모든 오류처리경로(Error handling path) 확인
컴포넌트 내의 인터페이스 확인
로컬 데이터 확인, 경계값 확인
<테스트 베이시스>
컴포넌트 요구사항
상세설계 / 프로그램 상세 설명서
코드
<테스트 대상>
컴포넌트
프로그램
데이터변환, 마이그레이션 프로그램
데이터베이스 모듈
- 통합 테스팅 (Intergration Testing)
: 컴포넌트간의 인터페이스를 테스트하는 것
: 시스템의 각기 다른 부분과 상호 연동하는 동작을 테스트 하는 것 (OS,파일,시스템,하드웨어,시스템간 인터페이스)
단위간의 결합과 인터페이스를 중점적으로 검증한다.
개별모듈의 내부 기능성에는 관심을 두지 않는다.
컴포넌트테스팅은 개별모듈의 기능에 관심을 두지만, 통합테스트는 두개 모듈사이의 커뮤니케이션에 관심을 둔다.
??? 통합의 각 단계에서 테스터는 통합 그 자체에만 집중(실라버스) / 통합그자체에만 집중하는 오류를 범하지 말아야 한다(책)
이상적으로는 테스터가 이키텍처에 대한 이해를 바탕으로 통합테스팅계획에 관여해야한다.
컴포넌트 또는 시스템이 만들어지기 전에 통합테스트를 계획한다면, 테스팅을 가장 효율적으로 수행할 수 있도록 컴포넌트 개발순서를 계획할 수도 있다.
V모델에서 하위레벨 테스트에
테스팅
기능적 / 비기능적(성능,연결성) 특성을 테스팅해야한다
테스팅설계 : 기능적 / 구조적 접근법 모두 사용하여, 통합 그 자체만 집중하는 오류를 범하지 말아야 한다.
- 수행주체
: 테스터
- 하나이상의 테스트 레벨이 있을 수 있으며, 다양한 크기의 테스트 대상에 대해 수행될 수 있다.
1) 컴포넌트 통합 테스팅 : 소프트웨어 컴포넌트 사이의 상호작용을 테스트하며 컴포넌트 테스팅 이후에 수행된다
2) 시스템 통합 테스팅 : 서로 '다른 시스템간' 또는 하드웨어, 소프트웨어간 상호작용을 테스트하며, 시스템 테스팅 이후에 수행된다.
타 시스템과의 연동 테스트
개발조직은 한쪽 시스템에 국한되어 제어 권한을 갖고, 이는 리스크로 간주됨 : 변경발생시 시스템전체차원에서 불안정유발
비즈니스 프로세스가 시스템간의 업무흐름을 가지고 있는 경우, 시스템간 교차점에서 중대한 문제를 야기가능
통합하는 범위가 크면 클수록 장애,결함의 위치를 찾아 격리하기가 어렵다. → 개발리스크/문제해결(Troubleshooting)시간 증가
통합하는 범위가 클수록, 특정 컴포넌트나 시스템에서기인하므로.
(ex) 빅뱅 접근법 : 점진적 통합방식에 비해 결함발견이 늦어져 리스크로 작용할 확률이 높다
따라서, 결함을 쉽게 격리하고 조기발견하기위해서 순차적, 체계적인 통합전략(Incremental approach)을 사용해야 한다
빅뱅전략 x / 상향식, 하향식, 백본 o
시스템 통합 전략은 시스템아키텍처 (상향식/하향식), 기능적테스트, 트랜잭션 처리순서, 시스템 또는 컴포넌트의 다른 측면등에 기반을 둘 수 있다
< 통합 테스트 레벨의 통합 접근법>
※표 참고 (P.56)
1) 백본(Backbone) : 가장 중요,리스크가 높은 모듈로 초기통합형성
장점 : 결함 격리 쉬움 / 리스크가 높은 결함을 초기에 발견
단점 : 시간이 오래 걸림
드라이버/스텁 : 필요에 따라 만들어 사용
2) 빅뱅(Big bang) : 모든 테스트 모듈을 동시에 통합
장점 : 단시간 테스트
단점 : 결함 격리 어려움
드라이버/스텁 : 없다. 실제모듈로 테스트
3) 상향식(Bottom up) : 가장 하부모듈부터 통합해가면서
장점 : 결함 격리 쉬움 / 하위모듈을 충분히 테스트
단점 : 수정이 어려운 중요결함을 상부구조에서 발견가능 / 비즈니스 로직반영이 어려움
드라이버/스텁 : 테스트 드라이버가 필요
4) 하향식(Top down) : 가장 상부모듈부터 통합해가면서
장점 : 결함 격리 쉬움 / 설계쌍의 결함을 빨리 발견
단점 : 수정이 어려운 중요결함을 하부에서 발견가능 (ex)디자인결함을 가진 db
드라이버/스텁 : 테스트스텁이 필요
<테스트 베이시스>
소프트웨어와 시스템 설계
아키텍쳐
워크플로우(Workflows)
유즈케이스
<테스트대상>
서브 시스템
데이터베이스 구축
기반환경
인터페이스
시스템 구성과 구성 데이터
- 시스템 테스팅 (System Testing)
: 개발 프로젝트 차원(범위)에서 정의된 '전체 시스템 또는 제품의 동작'(시스템 성능)에 대해 테스트 하는 것
테스팅 범위 : 해당 테스트레벨의 마스터/레벨테스트 계획에 명확하게 정의되어 있어야 한다.
단위 및 통합테스트가 완료돼 기능상 문제가 없는 상태에서 수행할 수 있다.
실제 최종 사용환경 또는 이와 유사한 환경에서 수행해야한다. : 환경특성장애(Environment-specific failure)리스크를 최소화하기 위해서
전체 기능상의 결함발견, 비기능적 품질 특성확인을 목적으로 한다
테스트엔지니어는 불완전, 문서형태를 갖추지못한 요구사항을기반으로 테스트하는 경우도 고려해야한다.
시스템 성능(시스템,제품의 동작)과 관련된 고객의 요구사항이 성공적으로 수행되었는지를 확인한다.
V모델에서 상위레벨 테스트에 속한다
- 완료조건 : 오픈돼있는(처리되지않은) 심각한 결함이 없음 / 모든 기능,비기능테스트아이템을 테스트함
테스팅
기능 요구사항 / 비기능 요구사항 / 데이터 품질특성 등을 모두 검증해야한다
[ 기능적]
- 주된 테스팅 방식 : 명세기반테스팅(블랙박스)
(예) 결정테이블 기법 : 비즈니스 룰에 표현된 결과들의 조합을 테스트하기 위해 사용
[비기능적(구조적)]
구조기반기법 : 메뉴구조나 웹페이지 내비게이션같은 구조적(비기능적)요소에 결함문제가 없는지 평가
기능적 품질특성 외 나머지부분 검증을 수행
(예) 성능테스트, 가용성테스트, 보안성 테스트
- 수행주체
: 주로 독립적인 테스트 팀이 진행 (하지만 개발팀도 수행가능)
< 테스트 베이시스(개발산출물) >
리스크 분석서(리포트)
요구사항 명세 : 시스템 및 소프트웨어
기능 명세
비지니스 프로세스
유즈 케이스
기타 비지니스 레벨의 시스템 동작 명세
OS 및 시스템 리소스와의 상호작용 명세
<테스트대상>
시스템, 사용자메뉴얼, 운영메뉴얼
시스템구성, 구성데이터
- 인수 테스팅 (Acceptance Testing)
: 시스템이 인수조건을 만족시키는지, 사용자나 고객이 시스템을 인수할지 결정할 수 있도록
사용자의 필요, 요구, 비지니스 프로세스를 고려해 수행하는 테스팅이다.
요구분석단계에서 테스트케이스를 작성해두면 인수테스팅시 많은 도움이 된다.
테스트 베이시스가 확보되는 개발 초기단계(요구사항정의단계)에서 시작한다
최종 단계의 테스팅이라고 보기 어렵다
(예) 대규모의 시스템 통합 테스트를 개별시스템에 대한 인수테스트 이후에 실행할 수도 있다.
- V모델에서 상위레벨 테스트에 속한다
< 목적 >
: 시스템이나 시스템의 일부 또는 특정한 비기능적인 특성에 대해 '확신'을 얻는 것.
결함을 찾는 것은 주된 관심사가 아니다.
사업적 리스크(Business Risk)에 집중해 테스트한다
프로젝트 전(모든) 개발 과정에서 수행할 수 있다.
상용(COTS)소프트웨어 제품은 설치, 통합되면 - 인수테스팅을 수행할 수 있다
프로그램 유지보수성에 대한 인수테스팅은 - 컴포넌트테스트 실행전에 수행할 수 있다
컴포넌트의 사용성에 대한 인수테스팅은 - 컴포넌트테스팅 동안에 수행할 수 있다
새로운 기능상의 개선에 대한 인수 테스팅은 - 시스템 테스팅전에 수행할 수 있다
- 수행주체
: 시스템을 사용하는 고객이나 사용자가 전담하여 수행하는게 대부분 / 다른관련자도 참여가능
<인수 테스팅의 전형적인 형태>
1) 사용자 인수 테스팅
- 일반적으로 비즈니스 사용자가 시스템 사용의 적절성을 확인한다
2) 운영상의 인수 테스팅
시스템관리자에 의한 테스트활동이다.
테스트항목
백업/복원테스팅
재난 복구
사용자 관리
유지보수 작업
보안취약성에 대한 정기점검
데이터로드, 마이그레이션 작업
3) 계약 / 규정 인수테스팅
계약 인수테스팅 : 맞춤식개발(Custom-developed) 소프트웨어가 계약상의 인수통과조건을 준수하는지확인하는 테스팅으로, 인수자가 계약에 동의할 때 인수통과된다
규정 인수테스팅 : 정부지침, 법률, 안정규정 등 준수해야 하는 규정에 맞게 개발되었는지 확인하는 테스팅
4) 알파 / 베타(필드) 테스팅
- 상용소프트웨어개발자는 종종 소프트웨어가 상업적으로 판매되기 전에 목표시장의 기존 고객이나 잠재고객으로 피드백을 받고 싶어한다.
(1) 알파테스팅 = 공장 인수 테스팅(Factory acceptance testing)
개발 조직 내에서 고객에 의해 수행된다
고객사의 사이트로 이동하기 전에 개발완료후 테스팅
(2) 베타(필드)테스팅 = 사이트 인수 테스팅(Site acceptance testing)
실제 환경에서 사용자, 잠재고객에 의해 수행된다
고객사이트로 이동한 후에 테스팅
<테스트 베이시스>
리스크 분석 리포트
사용자 요구사항 : 테스트케이스구성을 위한 베이시스
시스템 요구사항
유즈케이스
비지니스 프로세스
<테스트 대상>
완전히 통합된 시스템의 비즈니스 프로세스
운영 및 유지보수 프로세스
사용자 절차
양식
보고서
구성 데이터
<검수 테스팅>
실무에서는 시스템테스팅 - 인수테스팅사이에 출시여부를 결정하기위한 검수테스팅이 존재하는 경우가 있다
품질평가형태로 이루어진다
<개발과정 테스팅>
- 소프트웨어의 결함을 찾고 수정하기 위해 가능한 많은 장애의 원인을 발생시킨다
<SW 품질평가 테스팅>
- 신뢰성, 가용성 같은 시스템의 특성을 평가한다
[3] 테스트 유형 (Test types)
테스팅하는 목적 및 품질특성을 염두에 두고, 소프트웨어 시스템(시스템일부)을 검증하는 일련의 테스트활동을 말한다.
테스트의 구체적인 이유, 대상에 따라 특정테스트 활동 묶음을 소프트웨어 시스템(또는 시스템의일부)을 확인하기 위해 실행할 수 있다.
<테스트유형은 다음의 테스트목적에 중점을 둔다>
소프트웨어가 수행하는 기능에 대한 테스팅
비기능적인 품질 특성 테스팅 : 호환성, 신뢰성, 사용성과 같은
소프트웨어나 시스템의 구조나 아키텍쳐에 대한 테스팅
변경내용에 대한 테스팅 : 확인테스팅 / 리그레션 테스팅
<테스트 용이성 (Testability)>
- 테스터는 품질속성 중 제품요구사항을 리뷰할 때(테스트 전에/개발(코딩) 전에), 제품에 대한 테스트용이성을 먼저 평가해야 한다.
- 기능 테스팅 (Functional Testing)
: 시스템이 수행하는 그 '무엇' = 기능
[블랙박스]테스팅
모든 테스트 레벨에서 수행가능
블랙박스 테스팅 : 명세기반기법을 이용해 소프트웨어, 시스템기능에서 테스트조건,테스트케이스를 도출하고 소프트웨어의 외부적인 행동을 고려한다.
프로세스 흐름 모델, 상태 전이 모델, 평문 언어 명세 등을 이용가능
실행되어야하는 (서브)시스템,컴포넌트의 기능은 개발산출물(요구사항명세, 유즈케이스, 기능적명세)에 기술되어 있거나, 문서화되지 않을 수 있다.
기능테스팅은 문서화되어있거나 테스터가 알고 있는 기능과 특징, 그것들과 특별한 시스템과의 상호운용성을 고려하여 수행한다.
(예) 컴포넌트 테스트 레벨에서의 기능테스팅 - 컴포넌트 명세를 기반으로함
<품질특성 : 기능성>
- 품질부특성 : 적합성,정확성, 준수성, 상호운용성, 보안성 [적.정.보.상.준]
1) 보안성 테스팅 (Security Testing)
: 악의적인 코드(바이러스등)와 같은 외부로부터의 위협을 감지해내는 것과 관련이 있는 기능(방화벽)을 확인하는 테스팅
보안정책확인
시스템으로 침투하는 보호되지 않는 진입점(트랩도어) 파악
가용성, 무결성, 기밀성, 부인방지 등의 보안관련 평가
2) 상호운용성 테스팅(Interoperability)
: 하나 또는 여러개의 명시된 컴포넌트나 시스템이 서로 상호작용하는 소프트웨어 제품의 능력을 평가하는 테스팅
- 비기능 테스팅 (Non-Functional Testing) = 소프트웨어 제품 특성 테스팅(Testing of software product characteristics)
: 시스템이 '어떻게' 동작하는가를 테스팅
[블랙박스]테스팅
성능, 부하, 스트레스, 사용성, 유지보수성, 신뢰성, 이동성 테스팅을 포함하는 개념이다.
모든 테스트 레벨에서 수행가능
(성능테스팅에서의 응답시간과 같이) 다양한 척도,비율(Scale)로 정량화가능한 소프트웨어, 시스템의 특성을 측정하는 테스트이다.
외부로 표출되는 소프트웨어의 습성을 확인할 목적으로 실행된다.
블랙박스 테스트 설계기법을 활용한다
<부하 테스팅(Load Testing)>
실제 환경을 가정하고 일반적으로 요구사항에서 제시하는 부하의 최대치를 발생시켜 시스템이 안정적으로 작동하는 지를 확인하는 테스트.
<비기능성>
- 품질특성 : 신뢰성, 사용성, 효율성, 유지보수성, 이식성 [유.효.이.신.사]
- 구조적 테스팅 (Structural Testing)
: 특정 유형의 구조에 대한 커버리지를 평가하여 테스팅의 보장성, 충분함(Thoroughness)을 측정하는 테스팅
[화이트박스]테스팅
제어 흐름 모델, 메뉴구조 모델 등을 이용가능
구조기반(화이트 박스) 테스팅 : 코드커버리지 높임
모든 테스트 레벨에서 수행가능 : 시스템, 시스템 통합, 인수 테스팅
(예) 비즈니스 모델이나 메뉴구조도 활용하여 구조적 테스트 설계를 통해 수행이 가능하다.
명세기반기법을 적용한 다음에 사용할 떄 가장 좋은 결과를 보여준다.
컴포넌트 테스팅/컴포넌트 통합 테스팅 레벨에서 프로그램 코드 커버리지를 높이는 용도로 사용한다.
((자동화)도구사용하여 선언,구문(Statements) 혹은 결정문(Decisions)과 같은 커버리지 요소를 측정)
- 코드레벨뿐만아니라, 호출 체계/구조(Hierarchy)와 같은 시스템의 아키텍처에 기반을 두고 수행가능하다.
<커버리지>
: 시스템, 소프트웨어 구조가 테스트수트에 의해 테스트된 정도
- 만일 커버리지가 100%가 아니라면, 누락된 아이템을 테스트하기위해 더많은 테스트를 설계하여 커버리지를 높일 수 있다
- 확인 테스팅 (Confirmation Testing) = 재 테스팅 (Re Testing)
: 결함이 발견되고 수정된 후에 소프트웨어는 원래의 결함이 성공적으로 제거되었는지 확인하기 위해 다시 테스트하는 것
- 디버깅(결함의 원인을 찾거나 수정하는 활동)은 개발활동이며, 테스팅활동이 아니다.
- 리그레션 테스팅 (Regression Testing) = 회귀 테스팅
: 결합수정 이후 변경의 결과로 새롭게 만들어지거나, 이전 결함으로 인해 발견되지 않았던 또다른 결함을 발견하기 위해
이미 테스트된 프로그램의 테스팅을 반복하는 것. 퇴행(Regression)여부를 확인하는 테스팅
모든 테스트 레벨에서 수행가능
기능, 비기능, 구조적 테스팅에 적용할 수 있다
반복수행되므로 '자동화'대상으로 고려가능 : 리그레션 테스트 수트는 여러번 반복수행되며 대개는 서서히 변경되므로
테스트 대상 : 변경된 소프트웨어뿐만아니라 환경이 변경되어도 수행되어야 한다.
결함은 테스트중인 소프트웨어에 존재할 수 있고, 관련이 없는 다른 소프트웨어 컴포넌트에도 있을 수 있다.
테스트 범위/정도 : 리스크에 바탕을 둔다
위험성이 높으면 리그레션 테스팅을 넓은범위로, 보다 상세하고 철저하게 수행 (Intensive and higher-depth)
- 테스트가 확인테스팅으로 쓰이거나, 리그레션 테스팅을 보조한다면 그 테스트는 반복적인 성향을 갖는다.
- 결함 마스킹은 리그레션 테스팅으로 찾을 수 있다.
<결함 마스킹(Fault Masking)>
: 어떤 이유로 결함이 가려져서 해당 결함을 발견할 수 없는 상태
- 결함이 있는 프로그램 부분이 실행되지 않았거나, 다른 결함이나 장애로 해당 결함이 드러나지 않는 등 여러 이유로 결함이 존재하지만 발견되지 않을 수 있다.
[4] 유지보수 테스팅 (Maintenance Testing)
: 소프트웨어 또는 시스템이 변경, 단종, 마이그레이션될 때, 이미 운영되고 있는 시스템에서 수행하는 테스팅
개발과정에서 변경작업이 일어나는 경우, 새로운 결함이 유입됐는지 확인한다.
모든 테스트 유형 / 모든 테스트 레벨에서 수행가능
명세(Specifications)가 매우 오래되었거나 없다면 명세서를 근간으로 수행하기는 어렵다
사전에 출시계획을 세우는 것이 유지보수 테스팅의 성공여부에 중대한 영향을 미친다.
- 테스트 대상 : 변경된 부분에 대한 테스팅 이외에도 변경되지 않은 시스템 요소에 대한 방대한 리그레션 테스팅도 고려해야한다
- 테스트 범위/정도 : 변경사항의 리스크 및 크기, 기존시스템의 크기
영향도 분석(Impact analysis) : 변경으로 인해 기존시스템이 어떻게 영향을 받는지 결정하는 것
얼마나 많은 리그레션 테스팅을 수행할지 결정하는 데 이용한다
1) 변경(Modification)
출시(릴리즈)기반으로 계획된 개선활동에 의한 변경, 요구사항 변경에 의한 수정과 긴급변경, 환경의 변경 등
계획된 OS 또는 DB 업그레이드 / 계획된 상용소프트웨어 업그레이드 / OS의 새로 드러난 취약점 패치
2) 마이그레이션 = 변환
한 플랫폼에서 다른 플랫폼으로 옮기는 작업
변경되는 소프트웨어에 대한 운영테스트 + 새로운 환경에서의 운영테스트 필요
운영되고 있는 시스템에서 다른 응용프로그램의 데이터가 마이그레이션될때도 필요
3) 단종
데이터를 마이그레이션하는 테스팅 포함
데이터 저장관련 테스팅 : 데이터의 보유기간이 필요할경우
- 유지보수테스팅 vs 유지보수성테스팅 비교하기! - 다른개념이다
< (비교) 유지보수성 테스팅(Maintainability Testing)>
: 소프트웨어 및 시스템이 변경을 고려해 얼마나 잘 개발했는지 밝히는 테스팅
- 유지보수성이 낮은 시스템은 작은 변경에도 취약하다 ( 코드의 많은 부분을 수정하는 등 재작업,리소스 투입이 많음)
[출처] Part2. 소프트웨어 수명주기와 테스팅|작성자 Eugene
'프로젝트관리' 카테고리의 다른 글
리스크 관리.. 리스크 의미와 대응 (0) | 2023.03.06 |
---|---|
조정자 vs 촉진자 (0) | 2019.12.17 |
확인과 검증(V&V, Verification and Validation) (0) | 2019.06.22 |
검증(Validation)과 확인(Verification) (0) | 2019.05.25 |
RISK 관리란 (0) | 2016.06.26 |
댓글