SW Testing - Part2. 소프트웨어 수명주기와 테스팅

• 아래 내용들은 ISTQB FL 시험준비 & 테스팅공부를 위해 다음 출처의 자료들로 공부하며 정리한 것 입니다 *

• 출처 : 개발자도 알아야할 소프트웨어 테스팅 실무 제3판

• 출처 : 문제로 배우는 소프트웨어 테스팅 2

• 출처 : Certified Tester Foundation Level Syllabus version 2011 Korean

[1] 소프트웨어 개발 모델

테스팅은 소프트웨어 개발활동과 독립적으로 존재하지않고 밀접하게 연계되어있으므로,

개발수명주기모델에 기반하여 테스트 접근법을 다르게 적용해야한다

​

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)

: 개발 중 또는 개발단계 말에 명시된 사용자의 관점에서의 '요구사항'이 만족하는 지를 평가하는 프로세스

​

​

2. 반복적-점증적 개발모델 (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)

​

<애자일 테스팅 특징>

• 테스트를 미리 설계하지 않을 수 있으며, 누구나 테스트에 적극참여가능 (사용자,테스터,개발자)

• 결함을 최대한 빨리 발견가능 (요구사항을 개발과 동시에 발견가능)

• 문서를 최소화한다

• 테스트는 개발과 같이시작되거나 먼저시작되므로, 개발완료 = 테스트완료 이다.

​

​

3. 개발 수명주기 모델 (Life Cycle)에서의 테스팅

• 테스트 레벨은 프로젝트, 시스템아키텍쳐의 성격에 따라 재조정, 합쳐질 수 있다

(예) 상용(COTS : Commercial Off The Shelf)소프트웨어 제품을 시스템에통합할때

• 구매자는 시스템레벨에서 통합테스팅 / 인수테스팅을 수행할 수 있다

• 통합테스팅 : 인프라나 다른 시스템에 통합, 배포된 시스템에 통합

• 인수테스팅 : 기능적 테스팅, 비기능적 테스팅, 사용자 테스팅, 운영 테스팅 등 수행

​

<성공적인 테스팅 요건>

• 모든 개발 활동은 이에 상응하는 테스팅활동을 동반한다

• 각 테스트 레벨은 그 레벨에 맞는 특정한 목적을 가지고 있다

• 주어진 테스트 레벨에 맞는 테스트의 분석과 설계는 대응되는 개발활동 동안에 시작​되어야 한다

• 개발산출물 리뷰 : 개발 수명주기 동안에 개발 산출물의 초안이 작성되면, 테스터는 이러한 문서를 리뷰하는 활동에 참가해야 한다.

​

​

​

​

​

[2] 테스트 레벨(Test Levels)

< 각 테스트레벨 특징에 맞게 정의&식별되는 항목>

• 일반적인 목표 : 목적

• 테스트 케이스를 도출해내는데 참조되는 개발산출물 : 테스트베이시스

• 테스트 대상 : 테스트할 그 무엇

• 발견된 전형적 결함, 장애

• 테스트 하네스 (드라이버,스텁), 툴 필요여부

• 상세한 테스트 접근법

• 테스트 수행주체, 조직

​

<화이트박스&블랙박스 테스팅>

• 컴포넌트 테스팅 - 화이트박스

• 시스템 테스팅 - 블랙박스

​

​

1. 컴포넌트 테스팅(Component Testing) = 단위 테스팅(Unit Testing) = 모듈 테스팅 = 프로그램 테스팅

: 테스트가 가능한 최소단위로 나누어진 소프트웨어 (모듈,프로그램,객체,클래스 등) 내에서 결함을 찾고 그 기능을 검증하는 것

​

• 개발 수명주기의 정황과 시스템에 의존적이면서도 시스템의 다른부분에서 격리하여 독립적으로 수행할 수 있다.

이떄, 스텁, 드라이버, 시뮬레이터가 사용될 수 있다.

• 테스트케이스는 개발산출물에서 도출된다 : 컴포넌트명세, 소프트웨어상세설계, 데이터모델과 같은 개발산출물

• 일반적으로 코드를 중심으로 수행하며, 개발환경의 지원을 필요로 한다 : 단위테스트프레임웍, 디버깅 툴과 같은 개발환경

• 실무에서 개발자가 직접 테스트에 참여하여 결함을 바로수정하며, 기록과정은 일반적으로 생략한다.

그러나 프로세스관리,개선을 위해 결함에 대한 통계적 데이터가 필요한 경우는 인시던트(결함) 기록과정이 필요하다

• 테스트 중심의 개발방법론 (Test-first approach / test driven development) : 코딩전 테스트케이스를 준비하고 자동화하는 방법이다. 반복적성향이 매우 강한 접근법으로 테스트케이스를 개발한 후 작은 규모의 코드를 작성, 통합하고 테스트가 통과할 떄까지 반복수행한다.

• V모델에서 하위레벨 테스트에 속한다.

​

• 테스팅

• 주된 테스팅 방식 : 구조기반테스팅(화이트박스)

• 구조적 : 분기커버리지등

• 기능성

• 비기능성 : 리소스 메모리유출 관련, 강건성 테스팅 등..

​

• 수행주체

: 주로 개발자가 직접, 타개발자, 제3자 테스터

​

<목적>

• 기본경로(Path)확인

• 모든 오류처리경로(Error handling path) 확인

• 컴포넌트 내의 인터페이스 확인

• 로컬 데이터 확인, 경계값 확인

​

<테스트 베이시스>

• 컴포넌트 요구사항

• 상세설계 / 프로그램 상세 설명서

• 코드

​

<테스트 대상>

• 컴포넌트

• 프로그램

• 데이터변환, 마이그레이션 프로그램

• 데이터베이스 모듈

​

​

2. 통합 테스팅 (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)

• 유즈케이스

​

<테스트대상>

• 서브 시스템

• 데이터베이스 구축

• 기반환경

• 인터페이스

• 시스템 구성과 구성 데이터

​

​

3. 시스템 테스팅 (System Testing)

: 개발 프로젝트 차원(범위)에서 정의된 '전체 시스템 또는 제품의 동작'(시스템 성능)에 대해 테스트 하는 것

​

• 테스팅 범위 : 해당 테스트레벨의 마스터/레벨테스트 계획에 명확하게 정의되어 있어야 한다.

• 단위 및 통합테스트가 완료돼 기능상 문제가 없는 상태에서 수행할 수 있다.

• 실제 최종 사용환경 또는 이와 유사한 환경에서 수행해야한다. : 환경특성장애(Environment-specific failure)리스크를 최소화하기 위해서

• 전체 기능상의 결함발견, 비기능적 품질 특성확인을 목적으로 한다

• 테스트엔지니어는 불완전, 문서형태를 갖추지못한 요구사항을기반으로 테스트하는 경우도 고려해야한다.

• 시스템 성능(시스템,제품의 동작)과 관련된 고객의 요구사항이 성공적으로 수행되었는지를 확인한다.

• V모델에서 상위레벨 테스트에 속한다

​

• 완료조건 : 오픈돼있는(처리되지않은) 심각한 결함이 없음 / 모든 기능,비기능테스트아이템을 테스트함

​

• 테스팅

• 기능 요구사항 / 비기능 요구사항 / 데이터 품질특성 등을 모두 검증해야한다

[ 기능적]

• 주된 테스팅 방식 : 명세기반테스팅(블랙박스)

(예) 결정테이블 기법 : 비즈니스 룰에 표현된 결과들의 조합을 테스트하기 위해 사용

[비기능적(구조적)]

• 구조기반기법 : 메뉴구조나 웹페이지 내비게이션같은 구조적(비기능적)요소에 결함문제가 없는지 평가

• 기능적 품질특성 외 나머지부분 검증을 수행

(예) 성능테스트, 가용성테스트, 보안성 테스트

​

• 수행주체

: 주로 독립적인 테스트 팀이 진행 (하지만 개발팀도 수행가능)

​

< 테스트 베이시스(개발산출물) >

• 리스크 분석서(리포트)

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

• 기능 명세

• 비지니스 프로세스

• 유즈 케이스

• 기타 비지니스 레벨의 시스템 동작 명세

• OS 및 시스템 리소스와의 상호작용 명세

​

<테스트대상>

• 시스템, 사용자메뉴얼, 운영메뉴얼

• 시스템구성, 구성데이터

​

​

4. 인수 테스팅 (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)>

• 테스터는 품질속성 중 제품요구사항을 리뷰할 때(테스트 전에/개발(코딩) 전에), 제품에 대한 테스트용이성을 먼저 평가해야 한다.

​

1. 기능 테스팅 (Functional Testing)

: 시스템이 수행하는 그 '무엇' = 기능

• [블랙박스]테스팅

• 모든 테스트 레벨에서 수행가능

• 블랙박스 테스팅 : 명세기반기법을 이용해 소프트웨어, 시스템기능에서 테스트조건,테스트케이스를 도출하고 소프트웨어의 외부적인 행동을 고려한다.

• 프로세스 흐름 모델, 상태 전이 모델, 평문 언어 명세 등을 이용가능

​

• 실행되어야하는 (서브)시스템,컴포넌트의 기능은 개발산출물(요구사항명세, 유즈케이스, 기능적명세)에 기술되어 있거나, 문서화되지 않을 수 있다.

• 기능테스팅은 문서화되어있거나 테스터가 알고 있는 기능과 특징, 그것들과 특별한 시스템과의 상호운용성을 고려하여 수행한다.

(예) 컴포넌트 테스트 레벨에서의 기능테스팅 - 컴포넌트 명세를 기반으로함

​

<품질특성 : 기능성>

• 품질부특성 : 적합성,정확성, 준수성, 상호운용성, 보안성 [적.정.보.상.준]

1) 보안성 테스팅 (Security Testing)

: 악의적인 코드(바이러스등)와 같은 외부로부터의 위협을 감지해내는 것과 관련이 있는 기능(방화벽)을 확인하는 테스팅

• 보안정책확인

• 시스템으로 침투하는 보호되지 않는 진입점(트랩도어) 파악

• 가용성, 무결성, 기밀성, 부인방지 등의 보안관련 평가

2) 상호운용성 테스팅(Interoperability)

: 하나 또는 여러개의 명시된 컴포넌트나 시스템이 서로 상호작용하는 소프트웨어 제품의 능력을 평가하는 테스팅

​

​

2. 비기능 테스팅 (Non-Functional Testing) = 소프트웨어 제품 특성 테스팅(Testing of software product characteristics)

: 시스템이 '어떻게' 동작하는가를 테스팅

• [블랙박스]테스팅

• 성능, 부하, 스트레스, 사용성, 유지보수성, 신뢰성, 이동성 테스팅을 포함하는 개념이다.

• 모든 테스트 레벨에서 수행가능

​

• (성능테스팅에서의 응답시간과 같이) 다양한 척도,비율(Scale)로 정량화가능한 소프트웨어, 시스템의 특성을 측정하는 테스트이다.

• 외부로 표출되는 소프트웨어의 습성을 확인할 목적으로 실행된다.

• 블랙박스 테스트 설계기법을 활용한다

​

<부하 테스팅(Load Testing)>

실제 환경을 가정하고 일반적으로 요구사항에서 제시하는 부하의 최대치를 발생시켜 시스템이 안정적으로 작동하는 지를 확인하는 테스트.

​

<비기능성>

• 품질특성 : 신뢰성, 사용성, 효율성, 유지보수성, 이식성 [유.효.이.신.사]

​

​

3. 구조적 테스팅 (Structural Testing)

: 특정 유형의 구조에 대한 커버리지를 평가하여 테스팅의 보장성, 충분함(Thoroughness)을 측정하는 테스팅

• [화이트박스]테스팅

• 제어 흐름 모델, 메뉴구조 모델 등을 이용가능

• 구조기반(화이트 박스) 테스팅 : 코드커버리지 높임

• 모든 테스트 레벨에서 수행가능 : 시스템, 시스템 통합, 인수 테스팅

(예) 비즈니스 모델이나 메뉴구조도 활용하여 구조적 테스트 설계를 통해 수행이 가능하다.

​

• 명세기반기법을 적용한 다음에 사용할 떄 가장 좋은 결과를 보여준다.

• 컴포넌트 테스팅/컴포넌트 통합 테스팅 레벨에서 프로그램 코드 커버리지를 높이는 용도로 사용한다.

((자동화)도구사용하여 선언,구문(Statements) 혹은 결정문(Decisions)과 같은 커버리지 요소를 측정)

• 코드레벨뿐만아니라, 호출 체계/구조(Hierarchy)와 같은 시스템의 아키텍처에 기반을 두고 수행가능하다.

​

<커버리지>

: 시스템, 소프트웨어 구조가 테스트수트에 의해 테스트된 정도

• 만일 커버리지가 100%가 아니라면, 누락된 아이템을 테스트하기위해 더많은 테스트를 설계하여 커버리지를 높일 수 있다

​

​

4. 확인 테스팅 (Confirmation Testing) = 재 테스팅 (Re Testing)

: 결함이 발견되고 수정된 후에 소프트웨어는 원래의 결함이 성공적으로 제거되었는지 확인하기 위해 다시 테스트하는 것

• 디버깅(결함의 원인을 찾거나 수정하는 활동)은 개발활동이며, 테스팅활동이 아니다.

​

​

5. 리그레션 테스팅 (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