ISTQB Syllabus 2005 통합정리 (2. 소프트웨어 개발주기와 테스팅)

원문 : http://blog.naver.com/josephy74/70018639453
문제가 될 경우 바로 연락주세요. 바로 삭제하겠습니다.

2. 소프트웨어 개발주기와 테스팅

 

2.1 Software Development Models

 

테스팅은 따로 존재하지 않는다. 다시 말하면 테스트 액티비티들은 소프트웨어 개발 액티비티와 관련이 있다. 여러가지 수명주기 모델들은 테스팅을 위한 각기 다른 접근 방식을 필요로 한다.

 

2.1.1 V-모델

 

비록 V-모델의 여러가지 변형들이 존재하지만, 일반적인 형태의 V 모델은 4개의 개발 레벨에 관련된 4개의 테스티 레벨을 사용한다.

 

이 요약서에서 사용하는 4가지 레벨은 다음과 같다.

 

• 컴포넌트(단위) 테스팅 (component(unit) testing)
• 통합테스팅 (integration testing)
• 시스템 테스팅 (system testing)
• 승인 테스팅 (acceptance testing)

 

실제로 V모델에서는 소프트웨어 제품과 프로젝트에 따라서, 개발과 테스팅 레벨에 변화를 주거나 특정 레벨을 추가 또는 삭제 할 수도 있다. 예를 들어, 컴포넌트 테스트 후에 컴포넌트 통합 테스팅이 있을 수 있으며, 시스템 테스팅 후에 시스템 통합 테스팅이 있을수 있다.

 

개발 동안에 만들어진 소프트웨어 작업 산출물들(비지니스 시나리오 혹은 유스케이스, 요구사항 명세, 설계 문서, 코드)등은 때때로 하나 혹은 그 이상의 테스트 레벨에서의 테스팅의 기반이 된다. 일반적인 작업 산출물을 위한 참고에 CMMI나 'Software life cycle processes'(IEEE/IEC 12207)를 포함한다. 검증(Verification)과 유효성 검사(Validation) (그리고 초기 테스트 설계)은 소프트웨어 작업 산출물 개발 동안에 수행되어져야 한다.

 

2.1.2 반복 개발 모델(Iterative development models) (K2)

 

반복 개발은 요구사항 작업, 설계, 시스템의 구축과 테스팅 프로세스를 작은 개발의 시리즈로 행하는것이다. 반복 개발의 예로서는 프로토타입핑(Prototyping), RAD(Rapid Application Development), RUP(Rational Unified Process) 그리고 에자일(agile) 개발 모델이 있다.  반복동안에 만들어진 추가 부분은 개발의 한 부분으로써 여러가지 레벨에서 테스트 될 것이다.

이전에 개발된 다른 부분에 추가된, 점정 증가하는 부분적인 시스템을 형성하는, 추가 개발 부분 역시 테스트 되어야 한다.

 

회귀 테스팅(Regression testing)은 첫번째 반복 이후의 모든 반복에서 중요성이 증가한다. 검증(Verification)과 유효성 검사(Validation)은 각각의 인크리먼트(Increment)에서 수행되어야 한다.

 

2.1.3 개발 주기 모델에서의 테스팅(K2)

 

모든 개발 주기 모델에는, 좋은 테스팅의 몇가지 특성이 있다.

 

• 모든 개발 액티비티와 관련있는 테스팅 액티비티가 있다.
• 각각의 레벨은 그 레벨에 맞는 테스트 목표를 가진다.
• 주어진 레벨에 대한 테스트의 분석과 설계는 관련된 개발 액티비티 동안에 시작되어야 한다.
• 개발 수명 주기 모델에서 문서들의 배포판들이 이용가능하게 되면,  문서 리뷰시 반드시 테스터들이 포함되야 한다.

 

테스트 레벨들은 시스템 아키텍쳐나 프로젝트의 본질에 의존하여 조합되거나 재조직되어야 한다. 예를 들어, 사용 소프트웨어 제품의 시스템의 통합을 위해, 구매자는 시스템 레벨의 통합 테스트(예를 들어 다른 시스템과 기반 구조(Infrastructure)에 대한 통합 혹은 시스템 배치(Deployment))와 승인 테스트(기능/비기능 테스트, 그리고 사용자/운영 테스팅)를 수행해야 한다.

 

============================================================================

 

Validation

* 정의 :

  명시된 요구사항들을 만족하는지 여부를 확인하기 위해 개발단계 말이나 중간에 구성요소나 시스템을 평가하는 프로세스(IEEE/ANSI)
* 특징 :

  컴퓨터 기반 테스팅(Compoter-Based Testing) - 실제적으로 소프트웨어를 실행한다.

* 종류 :

  하위 레벨 테스팅 (Low-Level-Testing)과 상위 레벨 테스팅(High-Level-Testing)
    - 하위 레벨 테스팅 - 단위 테스팅(Unit Testing)과 통합 테스팅(Integration Testing)
    - 상위 레벨 테스팅 - 사용성 테스팅(Usability Testing), 기능 테스팅(Function Testing), 시스템 테스팅(System Testing), 인수 테스팅(Acceptance Testing)

Verfication

 * 정의 :

   개발 단계의 산출물이 그 단계의 초기에 설정된 조건을 만족하는지 여부를 결정하기 위해 구성 요소나 시스템을 평가하는 프로세스 (IEEE/ANSI) , 본격적인 구축(Implementation) 단계 이전에 요구사항 명세서, 설계 명세서, 코드등과 같은 산출물을 대상으로 평가(Evaluating), 검토(Reviewing) 점검(Inspecting)등을 하는 프로세스
  * 특징 :

    인간에 의한 테스팅(Human Testing) - 주로 산출물 위주의 검토 형태
* 종류 :

   점검(Inspection), 워크스루(Walkthrough), 동료에 의한 검토(Buddy Checks)

============================================================================

V-Model

 

2.2 Test levels (K2)

 

각각의 테스트 레벨에 대하여 다음의 것들이 정의될 수 있다.: 테스트 레벨의 일반적인 목표들, 테트 케이스를 유도하기 위하여 참조되는 작업 산출물(e.g 테스트 기반), 테스트 목표(예를 들어 무엇이 테스트 되어야 하는가?), 발견되어야 하는 일반적인 결점(defects)과 실패(failures), 테스트 설비 요구사항과 도구 지원, 그리고 특정 테스트 방법과 책임들

 

2.2.1 컴포넌트 테스팅(Component Testing) (K2)

컴포넌트 테스팅은 개별적으로 테스트가능한 소프트웨어(예를 들어, 모듈, 프로그램, 객체, 클래스 등)안의 결점을 찾고, 기능을 검증한다. 컴포넌트 테스팅은 시스템의 나머지 부분과 고립되어 실행되며, 개발 생명 주기와 시스템의 내용(context)에 의존한다. 스텁(stub), 드라이버(drivers) 그리고 시뮬레이터(simulators)가 사용될 수 있다.

 

컴포넌트 테스팅은 기능적인 특성과 자원의 작용(예를 들어, 메모리 누수)과 같은 비기능적인 특성이나 견고성(robustness) 테스팅, 구조적인(structual) 테스팅(예를 들어 브랜치 커버리지)도 포함할 수 있다. 테스트 케이스들은 컴포넌트 명세(specification), 소프트웨어 설계(design) 혹은 데이터 모델과 같은 작업 산출물로부터 유도된다.

 

일반적으로, 컴포넌트 테스팅은 실제로 테스트 되는 코드를 가지고 단위 테스트 프레임윅(unit test framework) 혹은 디버깅 도구 같은 개발 환경의 지원하에 하며, 일반적으로 코드를 작성한 프로그래머를 포함시킨다. 결점(defects)들은  부가사항(incident)의 기록없이(기록할 필요 없이) 발견 되자마자 바로 수정된다.

 

컴포넌트를 테스팅하는 한가지 방법은 코딩전에 테스트 케이스를 준비하고 자동화시키는 것이다. 이것은 테스트 우선 접근방법(test-first approach) 혹은 테스트 주도 개발(test-driven development)이라 불린다. 이러한 접근 방법은 매우 반복적이며 테스트 케이스 개발의 주기(cycle)에 기반한다. 따라서 작은 코드의 조각들을 생성하고 통합하고 그들이 패스할 때까지 컴포넌트 테스트를 실행한다.

 

2.2.2 통합 테스팅(Integration Testing) (K2)

 

통합 테스팅은 컴포넌트들 사이의 인터페이스, 운영 시스템, 파일 시스템, 하드웨어나 시스템 사이의 인터페이스와 같은 시스템의 여러 부분에 대한 상호작용(interactions)을 테스트한다.

한 단계의 이상의 통합 테스팅이 될 수(하나 이상의 통합 테스팅 단계가 있을 수) 있으며 다양한 크기의 테스트 객체에 대하여 수행될 수 있다.

 

예를 들어;

 • 컴포넌트 통합 테스팅은 소프트웨어 컴포넌트 사이의 상호작용을 테스트한다. 그리고 컴포넌트 테스팅 후에 행해진다.
 • 시스템 통합 테스팅은 여러가지 시스템 사이의 상호작용을 테스트하며 시스템 테스팅 후에 행하여진다.  이러한 경우, 개발 조직은 인터페이스의 한쪽만 통제하기 때문에 변경사항은 불안정 해질수 있다. 비즈니스 프로세스(business processes)는 시스템의 시리즈에 포함 될 수 있는 워크플로(workflow)로써 구현된다. 교차 플랫폼 문제가 중요해질 수 있다.

 

통합되는 범위(scope)이 커질수록, 특정 시스템이나 컴포넌트로부터 위험을 증가시킬 수 있는 실패들(failures)을 고립(isolate)시키는 것이 더욱 어려워진다.

 

시스템적인 통합 전략들은 시스템 아키텍쳐(하향식과 상향식), 기능적인 작업, 트랜잭션 프로세싱 시퀀스, 시스템 혹은 컴포넌트의 다른 측면들에 기반을 둘 수 있다. 늦은 결점 발견의 위험을 줄이기 위하여 통합은 한번에 모든 것을 끝내는 것(big-bang)보다는 일반적으로 점증적이어야한다.

 

특정 비기능적인 특성들(예를 들어 성능)의 테스팅은 통합 테스팅에 포함될 수 있다.

 

각각의 통합 단계에서, 테스터들은 오직 통합 그 자체에만 집중해야한다. 예를 들어, 테스터들이 모듈 A를 모듈 B와 통합한다면, 그들은 이 모듈들 사이의 커뮤니케이션을 테스팅하는데 관심을 가져야하며, 각각의 모듈의 기능에 관심을 가지면 안된다. 기능적인 접근 방법과 구조적인 접근 방법 모두 사용될 수 있다.

 

이상적으로, 테스터들은 아키텍쳐와 통합 계획에 영향을 주는 것을 이해하여야 한다. 만약 컴포넌트나 시스템들이 구축되기 전에 통합 테스트가 계획된다면, 테스터들은 가장 효과적인 테스팅 순서를 정할수 있다.

 

2.2.3 시스템 테스팅(System Testing) (K2)

 

시스템 테스팅은 개발 프로젝트나 프로그램의 범위에 의하여 정의된 전체 시스템/제품의 행위에 관심을 둔다. 

 

시스템 테스팅에서, 테스트 환경은 환경으로 인한(environment-specific) 실패의 위험이 발견되지 않도록 가능한한  최종 타켓이나 생산 환경과 연관되어야 한다.

 

시스템 테스팅은 요구사항 명세, 비즈니스 프로세스, 유스케이스, 혹은 시스템 행위의 상위 레벨의 묘사, 운영 시스템과의 상호작용 그리고 시스템 자원이나 위험에 기반한 테스트들을 포함한다.

 

시스템 테스팅은 시스템의 기능요구사항과 비기능 요구사항 모두를 반드시 조사해야 한다. 요구사항은 텍스트와/혹은 모델들로 존재할 수 있다. 또한 테스터들은 불완전하거나 문서화되지 않은 요구사항도 다루어야 할 필요가 있다. 시스템의 기능 요구사항 테스팅은  테스트 되어야 하는 시스템 측면에 대한 가장 적당한 규격 기반(블랙박스) 기술을 사용하여 시작한다.  예를 들어, 의사 결정 테이블(decision table)은 비즈니스 규칙들에 설명된 효과의 조합들을 위해 만들어 질 수 있다. 그런 다음, 메뉴 구조나 웹 페이지 네비게이션과 같은 구조 기반의 기술(화이트 박스)은 구조적인 요소의 측면에서 테스팅한 성능을 평가하는데 사용될 수 있다. (See Chapter 4)

 

독립적인 테스트 팀이 종종 시스템 테스팅을 수행한다.

 

2.2.4 승인 테스팅(Acceptance Testing) (K2)

승인 테스팅은 주로 시스템의 사용자나 고객의 책임이다. 물론 다른 이해당사자가 포함될 수 있다. 승인 테스팅의 목적은 시스템, 시스템의 부분이나 시스템의 특정 비기능적인 특성들에 대한 확신을 갖는 것이다. 결점을 발견하는 것이 승인 테스팅의 중점사항은 아니다. 승인 테스팅은 비록 절대적으로 시스템의 최종 단계의 테스팅은 아니지만, 시스템의 사용과 배치를 위한 시스템의 준비정도를 평가할 수 있다. 예를 들어, 대규모 시스템의 통합 테스팅은 시스템에 대한 승인 테스팅 다음에 할 수 있다. 

 

승인 테스팅은 단일 테스트 레벨보단 여러 레벨에서 일어날 수 있다. 예를 들어

 

 • 상용 소프트웨어 제품(COTS software product)은 설치되거나 통합되기 전에 승인 테스팅을 받을 수 있다.
 • 컴포넌트의 가용성(usablity) 승인 테스팅은 컴포넌트 테스팅 동안에 행해질 수 있다.
 • 새로운 기능 향상을 위한 승인 테스팅은 시스템 테스팅 전에 행할 수 있다.

 

승인 테스팅의 전형적인 형식은 다음을 포함한다.

 

사용자 승인 테스팅(User acceptance testing)
일반적으로 비즈니스 사용자에 의하여 시스템의 사용에 대한 적합성(fitness)을 검증한다.

운영 (승인) 테스팅 (Operational (acceptance)testing) 시스템 관리자에 의하여 행하여지는 시스템의 승인 테스팅은 다음을 포함한다.

 • 백업과 복원(restore)의 테스팅
 • 재난시 복구(recovery)
 • 사용자 관리
 • 관리 작업
 • 주기적인 보안 취약점의 확인.

 

계약, 규정 승인 테스팅 (Contract and regulation acceptance testing)

계약 승인 테스팅은 맞춤형으로 개발된 소프트웨어에 대하여 생산된 계약자의 승인 특성(acceptance criteria)에 대하여 수행된다. 규정 승인 테스팅은 정부나 법률 혹은 안전 규정과 같은 반드시 지켜야 하는  모든 규정(regulations)에 대하여 수행된다.

 

알파, 베타(또는 필드) 테스팅 (Alpha and beta (or field) testing)

시장제품, 상용제품, 또는 소프트웨어의 개발자는  때때로  시장에 소프트웨어 제품을 상업적으로 판매하기에 앞서, 잠재고객이나 기존의 고객들로부터 피드백을 받기를 원한다. 알파 테스팅은 개발 조직의 사이트에서 수행된다. 배타 테스팅 혹은 필드 테스팅은 사람들에 의하여 그들이 있는 장소에서 수행된다. 두가지 제품의 개발자가 아니라 모두 잠재적인 고객에 의해여 수행된다. 여러 조직들에서는 고객 사이트에 이동하기 전과 후에 테스트 되어야 하는 시스템에 대하여 제조 승인 테스팅(factory acceptance testing)과 사이트 승인 테스팅(site acceptance testing)과 같은 다른 용어를 사용할 수 있다.

 

===========================================================================

◆ 테스트 레벨
 
▪ 한번에 총체적으로 조직화되고 관리되는(하는) 테스트 활동
      - Unit, Integration, System, Acceptance Test Level 
      - SW/HW 모두 포함한다.
▪ 독립적 테스트 계획
▪ 독립적으로 테스트 된다.
▪ 독립적 테스트 환경

 

알파 릴리즈

몇몇 주요 고객 또는 마케팅 시연 목적으로 제한된 숫자만 배포되는 초기 빌드. 실제 사용을 위해 제작된 빌드는 아니다. 알파 릴리즈를 사용하게 될 사용자는 빌드의 정확한 컨텐트와 제한된 품질 수준을 이해하고 있어야 한다.

 

베타 릴리즈

잠재적 고객에게 광범위하게 배포되는 공식적인 빌드. "버그 파티 및 베타 테스트"에서 베타 테스트를 수행하는 특정한 이유를 정의해야 한다는 점을 기억하라

 

테스팅은 소프트웨어 개발 공정 중에서 가장 노력과 비용이 집중적으로 투자되는 작업으로 기능과 성능을 확인하는 작업이다. 일반적으로 오류의 종류와 프로그램이 비교 테스트되는 기준에 따라 단위 테스팅, 통합 테스팅, 시스템 테스팅, 인수 테스팅과 같은 네가지 성격의 테스팅 방법이 있다.

 

1. 단위 시험  (Unit Testing, Component Testing)

 

단위 시험은 소프트웨어 설계의 기본 단위인 모듈 내부적인 오류를 발견하기 위한 시험이다. 단위 시험은 화이트 박스 방식과 블랙 박스 방식으로 수행할 수 있으며 일반적으로 화이트 박스 중심의 시험을 사용한다.

단위 시험시 결과 테이터 구조에 대한 조사, 제어 흐름에 정확성에 대한 조사, 최대점, 최소점 바로 위와 아래의 데이터 값들의 조사하는 테스트 케이스들은 오류를 쉽게 발견할 수 있다는 것을 알 수 있다. 모듈은 독립형 프로그램이 아니기 때문에 시험시 드라이버나 스텁이 필요하다. 그러나 드라이버와 스텁은 개발될 소프트웨어에 포함될 사항이 아니므로 시험시의 오버헤드에 해당한다. 하지만 오버헤드를 줄이기 위해 간단하게 드라이버와 스텁을 구성하는 것은 적절한 시험을 불가능하게 한다.

 

▪ 하나의 소프트웨어 모듈이 정상적으로 기능을 수행하는지의 여부를 테스트

▪ 원시 코드를 시험 대상으로 하며 주된 테스트 방법은 화이트 박스 테스트임

▪ 단위 프로그램별로 설계서 상에 정의된 기능을 제대로 수행하는지 검증

▪ 해당 개발자에 의해서도 수행될 수 있으나 타개발자나 3자에 의해서도 실시

▪ 개발 과정에서 수행하는 테스트

▪ 소프트웨어 각각의 단위(모듈)을 다른 부분과의 연계성을 고려치 않고 격리하여 테스트

 

목적  

 

▪ 기본적 패스(path)를 확인

▪ 모든 에러 핸들링 패스를 확인

▪ 모듈 인터페이스 확인

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

 

◆ 단위 테스트 기법
    - Control flow 테스트

    - Condition decision (branch)

    - 커버리지 테스트 (Elementary comparison test)

    - 등가 분할 & 경계값 테스트

 

◆ 단위 테스트 완료 조건
 ▪ AI(Application Integrator)가 통합 테스트로의 entry criteria를 만족시켰다고 판단하는 경우 (품질 수준을 개발 프로젝트 리더, 팀 리더가 결정)
     - 기 결정한 테스트 커버리지 달성
     - 특정 테스트 기법 사용 확인
     - 단위 테스트 케이스와 결과 검토 및 워크스루를 통해 결정
 ▪ QA enterance 조건을 만족시킴 (통합테스트와 단위테스트를 구별하지 않는 경우)
 ▪ 개발 관리자가 완료로 결정함(일반적인 경우)

 

2. 통합 시험

 

각 모듈들에게 서비스를 요청하고 그 결과를 정확하게 연결시켜 주는 부분의 역할이 중요하다. 문제점은 모든 모듈을 하나로 만드는 인터페이싱이다. 통합 시험은 이와 같은 인터페이싱과 관련된 오류를 발견하는 시험을 수행하고 동시에 프로그램 구조를 구성하는 체계적인 기법이다. 이 시험의 목적은 모듈이 시험한 단위를 택하여 설계에서 지시한 프로그램 구조로 구성하는 것이다.

 

모든 모듈을 사전에 미리 결합하고 전체 프로그램을 하나로 시험하게 되면, 대단히 혼란스러운 결과가 나타나고 많은 오류가 발생한다. 전체 프로그램이 광범위해서 생기는 여러 원인을 제거하는 작업이 복잡하기 때문에 수정 작업도 어렵다. 일단 이러한 오류들이 수정되면, 새로운 오류들이 나타나고 끝도 없이 이러한 과정이 지속된다. 이와 같은 문제점을 제거하기 위해서는 체계적인 접근이 필요하며 조금씩 통합하고, 통합 후 시험하는 작업을 반복하는 것이 현명한 방법이 된다. 점증적 통합(Incremental Integration)을 이용하여 프로그램을 작은 단위로 추가해가면 시험해 나가면 오류를 정확히 찾아낼 수 있으며, 수정하는 것도 쉽고, 인터페이스를 완벽하게 시험할 수 있어서 체계적인 시험 접근법을 적용시킬 수 있다.

 

▪ 시스템이나 시스템 구성요소(component) 또는 소프트웨어 프로그램의 데이터 및 기능의 인터페이스가 정상적으로 작동하는지에 중점을 두고 수행하는 테스트
 ▪ 단위 테스트들 통과한 개발 소프트웨어/하드웨어 컴포넌트(모듈)간 인터페이스 및 연동 기능 등을 구조적으로 접근하여 테스트 하는 방법
▪ 개발자가 효과적(effective)으로 테스트 할  수 있는 방법 단위 테스트로 개발자가 테스트에 흥미를 잃을 수 있음
▪ 테스트 라이프사이클에서 단위 레벨과 시스템 레벨의 중간 레벨을 테스트

◆ 통합 테스트 종류

 - 빅뱅 통합
 - Bottom up 통합
 - Top down 통합
 - 백본 (Backbone) 통합
 - 중심(Central) 통합, 협업(Collaboration) 통합, 계층(Layer) 통합, C/S 통합

3. 시스템 시험

 

소프트웨어는 대형 컴퓨터 시스템의 하나의 요소일 뿐이다. 소프트웨어는 다른 시스템 요소인 하드웨어, 정보들과 통합되어 일련의 시스템 통합과 검증 시험이 수행된다. 이러한 시험은 소프트웨어 개발자가 단독으로 수행하는 것이 아니다. 그러나 소프트웨어 설계와 시험동안에 수행된 단계들은 대형 시스템에서 성공적인 시스템 통합의 가능성을 크게 향상시킨다.

 

시스템 시험은 컴퓨터 시스템을 완벽하게 검사하는 주요 목적을 가진 일련의 또 다른 시험 방법이다. 비록 시험이 다른 목적을 갖고 있어도 모든 작업은 모든 시스템 요소가 적절히 통합되고 할당된 기능을 수행하는지를 검증한다.

 

▪ 실 사용 환경과 동일한 모의 시스템을 구성
   ==> Environment Specific failure을 일으킬 risk를 최소화
▪ 시스템 성능과 관련된 고객의 요구사항이 완벽하게 수행되는지를 테스트
▪ 시스템 시험을 성공적으로 수행하기 위해서는 성능 요구사항을 명확히 하여야 함
▪ 현장에서 적용 가능한 시스템 테스트: 스트레스 테스트와 볼륨 테스트
▪ 단위/통합 시험이 완료되어 기능상 문제가 없는 상태여야 함
▪ 개발 조직과 테스트 조직이 원활히 정보를 공유하고 협력하여야 함

 

◆ 시스템 테스팅의 기반
- 요구사항 명세서

  (요구사항은 주로 텍스트 또는 모델의 형태로 존재하지만 불완전하고 문서화하지 않은 요구사항이 대부분이다.)
- 리스크 분석 결과
- 비지니스 절차
- 유스케이스
- 상위 레벨의 시스템 행동 기록 문서
- OS, 시스템 리소스와의 상호작용

 

◆ 시스템 테스팅은 기능적 요구사항과 비기능적 요구사항을 커버

▪ 기능적 요구사항 테스트 기법
   - 명세 기반 기법(Black-box) : Decision Table
▪ 비기능적 요구사항 테스트 기법
   - 구조기반 기법(White-box) : 메뉴 구조 또는 웨 페이지 네비게이션 등의 구조적 요소에 대한 테스팅 커버리지(thoroughness)
   - 성능 테스트
   - 보안 테스트

 

4. 인수 시험

 

주문 소프트웨어가 고객을 위하여 구축된 경우, 고객의 모든 요구사항을 만족하는지 확인하도록 하는 인수 시험(Acceptance test)가 수행된다. 인수 시험은 시험 드라이브에서 계획적이고 체계적으로 수행되는 일련의 시험까지 포함되어 실시된다. 대부분의 소프트웨어 개발자는 최종 사용자만이 찾을 수 있는 오류를 발견하기 위하여 알파 테스트와 베타 테스트를 수행한다. 알파 테스트는 고객이 개발자의 위치에서 실행하는 시험이다. 이때 소프트웨어 개발자가 참여하여 오류와 사용법 문제를 기록하면서 사용자에게 도움을 줄 수 있는 통제된 환경에서 수행된다. 반면에 베타 테스트는 개발자가참여하지 않은 상황에서 실질적으로 프로그램을 실행하여 사용하는 환경에서 수행된다. 고객은 베타 시험에서 발생한 문제를 기록하여 개발자에게 보고하고, 개발자는 이를 바탕으로 소프트웨어를 수정한다. 

 

▪ 계약상의 요구 사항이 만족되었는지를 확인하기 위해, 설치 후 구입자 운영 환경에서 납품자도 참가하여 구입자에 의하여 실시되는 시스템 또는 기능 단위의 공식 테스트
▪ 이 결과를 기초로 고객(구매자)이 개발된 시스템을 인수할 것인지를 결정

 

승인 테스트 계획은 반드시 다음 사항을 포함하고 있어야 한다.

 

 ▪ Acceptance Description
 ▪ Project Description
 ▪ User Responsibilities
 ▪ Administrative Procedures

===========================================================================

 

2.3 Test types : the targets of testing

 

여러 종류의 테스트 액티비티들의 목적은 특정 이유나 테스팅의 대상에 기반한 소프트웨어 시스템(또는 시스템의 일부분)을 검증하는 것이 이다.

 

한 테스팅의 타입은 특정한 테스트 목표에 초점을 두며, 소프트웨어에 의하여 수행되어야 하는 기능을 테스팅할 수 있다 - 신뢰성(reliability)또는 가용성(usability)와 같은 비기능적인 특성들, 또는 소프트웨어나 시스템의 아키텍쳐(architecture)나 구조(structure), 또는 관련된 변경사항들, 예를 들어 결함(defect)가 고쳐졌다는 다는 것을 확인하는 것 (확인 테스팅)과 의도되지 않은 변경 사항을 찾는 것(회귀 테스팅)등을 테스팅 할 수 있다.

 

소프트웨어의 모델은 개발될  수 있으며 구조적 테스팅(structural testing)과 기능적 테스팅(functional testing)에 사용될 수 있다.  기능 테스팅에서의 프로세스 플로우 모델(process flow model), 상태 전이 모델(state transition model) 또는 일반적인 언어 명세, 그리고 구조적인 테스팅에서의 컨트롤 플로우 모델(control flow model) 또는 메뉴 구조 모델(menu structure model)을 예로 들 수 있다.

 

2.3.1 기능 테스팅 (functional testing) (K2)

 

시스템, 서브 시스템, 또는 컴포넌트의 기능(function)이 수행하여야 하는 것은 요구사항 명세, 유스케이스 또는 기능 명세나 문서화되지 않은 무엇과 같은 작업 산출물(work product)에 설명되어 있을 수 있다. 이러한 기능들(functions)들은 시스템이 무엇(what)을 하는가 이다.

 

기능 테스트들은 (문서에 기술되어 있거나 테스터에 의하여 이해된) 이러한 기능(functions)과 특성(features)에 기반하며, 모든 테스트 레벨에서 수행되어 질 수 있다. (예를 들어, 컴포넌트에 대한 테스트는 컴포넌트 명세에 기반할 수 있다.)

 

소프트웨어나 시스템의 기능으로 부터 테스트 조건(test conditions)과 테스트 케이스를 유도하는데에 명세 기반 기법들(specification-based technique)이 사용될 수 있다. (4장을 보라). 기능 테스팅은 소프트웨어의 외부적인 동작을 고려한다. (블랙 박스 테스팅)

 

기능 테스팅의 한 타입인 보안 테스팅(security testing)은 악의적인 외부(mailcious outsiders)로 부터의 바이러스와 같은 위협의 감지와 관련된 기능을 조사한다.

 

2.3.2 소프트웨어 제품 특성의 테스팅 (non-functional testing) (K2)

 

비기능 테스팅(Non-functional testing)은 성능 테스팅(performance testing), 부하 테스팅(load testing), 스트레스 테스팅(stress testing), 사용성 테스팅(usability testing), 상호연동 테스팅(interoperability testing), 유지보수성 테스팅(maintainability testing), 그리고 이식성 테스팅(portability testing)을 포함하지만, 이러한 것들에 의하여 제한되지는 않는다. 이것은 시스템이 어떻게(how) 동작하는가에 대한 테스팅이다.

 

비기능 테스팅은 모든 테스팅 레벨에서 수행될 수 있다. 비기능적인 테스팅이란 용어는 성능 테스팅에서의 응답 시간(response time)과 같이 다양한 규모의 수량화(quantified) 될 수 있는 시스템과 소프트웨어의 특성들의 측정을 요구하는 테스트를 말한다. 이러한 테스트들은 "소프트웨어 공학-소프트웨어 제품 품질"(ISO 9126)에 정의된 것과 같은 품질 모델(Quality Model)을 참조할 수 있다.

 

2.3.3. 소프트웨어 구조/아키텍쳐의 테스팅 (structure testing) (K2)

 

구조 테스팅(화이트 박스)은 모든 테스트 레벨에서 수행될 수 있다. 구조적인 기법들(structural techniques)은 한 종류의 구조의 커버리지 측정을 통하여 테스팅이 완벽한가를 측정하기 위하여  명세 기반 기법(specification-based technique) 다음으로 가장 많이 사용된다.

 

커버리지(Coverage)는 테스트 슈트(test suite)에 의하여 테스트 된 구조의 범위로, 처리된 항목의 퍼센티지(%)로 표현된다. 만약 커버리지가 100%가 아니라면, 더 많은 테스트들이 테스트에서 빠진 항목의 테스트를 위하여 설계되어야 한고 이러한 방식으로 커버리지가 증가한다. 커버리지 기법들은 4장에서 처리한다.

 

모든 테스트 레벨에서, 특히 컴포넌트 테스팅과 컴포넌트 통합 데스팅에서 문장(statements)이나 분기(decisions)와 같은 요소들의 코드 커버리지를 측정하는데 도구를 사용할 수 있다. 구조적인 테스팅은 호출 계층 구조(calling hierachy)와 같은 시스템의 아키텍쳐에 기반을 둘 수 있다.  

구조적인 테스팅 접근 방법은 시스템, 시스템 통합 또는 승인 테스트 레벨에도 역시 적용할 수 있다. (예를 들어 비지니스 모델이나 메뉴 구조)

 

2.3.4 변경 사항에 관련된 테스팅(confirmation and regression testing)

 

결함이 검출되고 고쳐진 다음, 소프트웨어는 반드시 원래의 결점이 성공적으로 제거되었는지 확인하기 위하여 다시 테스트되어야 한다. 이것을 확인 테스팅(confirmation testing)이라고 부른다. 디버깅(결점의 수정)은 개발 액티비티이지, 테스팅 액티비티가 아니다.

 

회귀 테스팅(regression testing)은 이미 테스트된 프로그램을 변경(modification)후에 변경(들)의 결과로 커버되지 않았거나 발견되지 않은 결점을 발견하기 위하여 반복해서 테스팅하는 것이다. 이러한 결점들은 테스트 된 소프트웨어 내에 있거나 다른 연관된 소프트웨어 컴포넌트나 연관되지 않은 소프트웨어 내에 있을 수 있다. 회귀 테스팅은 소프트웨어나 환경(environment)이 변경되었을 때 수행된다. 회귀 테스팅의 확장은 이전 부터 동작해 왔던 소프트웨어 내의결점을 발견하지 못하는 위험(risk)에 기반한다.

 

확인 테스팅을 사용하고, 회귀 테스팅을 지원하기 위해서는 테스트는 반복적이어야 한다.

회귀 테스팅은 모든 테스트 레벨에서 수행될 수 있다. 그리고 기능, 비기능, 구조적 테스팅에 적용된다. 회귀 테스트 슈트(regression test suite)는 여러 번 수행되고 일반적으로 천천히 진화된다. 따라서 회귀 테스팅은 자동화를 위한 강력한 후보이다.

 

===========================================================================

블랙 박스 테스트(Black-Box test)와 화이트 박스 테스트(White-Box test)

 

블랙 박스 테스트에서 테스터는 소프트웨어가 가져야할 기능을 알고 있지만, 이 기능이 어떻게 작동되는지는 볼 수 없다. 어떤 내용을 입력 했을 때 특정 출력을 얻게 되지만 테서트는 작동 원리와 이유에 대해서는 모르고 있다. 블랙 박스 테스트에서는 소프트웨어가 어떤 과정을 거쳤는지는 중요하지 않다. 결과만이 중요하다.

 

화이트 박스 테스트에서 소프트웨어 테스터는 프로그램의 코드에 접근하여 결과에 대한 원인을 살펴볼 수 있다. 조사한 결과에 기초하여 테스터는 특정 종류의 입력에서 오류가 발생할 가능성이 있는지 없는지에 대한 여부를 판단하고 이 정보에 따라 테스트를 수행할 수 있다.

 

정적 테스트(Static test)와 동적 테스트(Dynamic test)

 

정적 테스트는 실행 중이 아닌 제품을 테스트하는 것, 즉 조사하거나 검토하는 것을 뜻한다.

동적 테스트는 우리가 흔히 테스트 작업 이라고 생각하는 것, 즉 소프트웨어를 실행한 다음 테스팅하는 것을 뜻한다.

 

◆ Quality Model

 

▪ Functionality (기능성) : 규정된 기능 및 성능을 정확하게 충족시키는 능력
▪ Reliability (신뢰성) : 고장없이 성능 수준을 지속적으로 유지시키는 능력
▪ Usability (사용성) :사용자가 쉽게 이해하고 배울 수 있게 하는 능력
▪ Efficieny (효율성) : 부하변동에 대한 자원의 효율적인 운영 능력
▪ Maintainability (유지보수성) : 소프트웨어의 수정, 개선을 용이하게 하는 능력
▪ Portability (이식성) : 다양한 운영 환경에 적응할 수 있는 능역

 

◆ 테스트 종류

 

▪  기능 테스팅
▪  비기능 테스팅
▪ 구조적 테스팅 (Testing of SW structure/architecture)
▪ 확인/회귀 시험 (Testing related to changes)

 

◆ 기능 테스팅 (Functional Testing)

 

▪ 소프트웨어 기능 중심의 테스팅
▪ 테스트 케이스 (대부분을 차지함)
    - 메뉴, 사용자 매뉴얼 챕터 제목이나 목차에서 기능 추출
    - 각각의 기능에 대해 기준, 출력, 내부 조건, 내부 상태를 파악하여 테스트 케이스 작성

 

◆ 비기능 테스팅 (Non-functional Testing)

 

▪ 소프트웨어 제품 특성을 테스팅
▪ 성능 테스팅, 부하 테스팅, 스트레스 테스팅
▪ 사용성 테스팅
▪ 호환성 테스팅, 유지보수 테스팅, 신뢰성 테스팅, 이식성 테스팅
▪ 보안성 테스팅

 

◆ Stress, Load, Performance Testing

 

▪ 스트레스 테스트
  - 시스템을 의도적으로 규정된 한계치 이상의 스트레스를 가하는 테스트
  - 시스템이 다운될 때까지 스트레스를 가하여 최대로 견디는 지점 파악
  - 시스템이 설계된대로 복원하는지 확인
▪ 부하 테스트
  - 실제 환경을 가정하고 일반적으로 부하의 최대치를 발생시켜 시스템이 안정적으로 작동하는지를 확인하는 테스트
▪ 성능 테스트
 - 비지니스 사용자가 기 정의한 성능 기대 레벨과 비교하여 측정하는 시험
 - 일반적으로 모든 성능 관련 테스트를 총칭하는 용어로 쓰임

===========================================================================

 

2.4 Maintenance testing

 

소프트웨어 시스템은 한번 배치되면(deployed), 종종 수년이나 수십년 동안 운용된다. 이 기간 동안에 시스템과 시스템의 환경은 자주 수정되고(corrected), 변경되거나(changed) 확장된다(extended). 유지보수 테스팅(Maintenance testing)은 기존의 운영되는 시스템에서 행하여지며, 소프트웨어 시스템의 변경(modification), 이전(migration) 혹은 퇴역(retirement)에 의하여 유발된다.

 

변경(Modification)은 계획된 성능 향상을 위한 변경(e.g 릴리즈에 기반한), 수정(corrective)에 의한 변경사항과 긴급한 변경사항, 그리고 계획된 운영 시스템이나 데이터베이스의 업그레이드, 새로 나타나거나 발견된 운영 시스템의 취약성에 대한 패치와 같은 환경의 변경을 포함한다.

 

이전(Migration)(e.g 한 플랫폼에서 다른 플랫폼으로)을 위한 유지보수 테스팅은 반드시 변경된 소프트웨어는 물론 새로운 환경에 대한 운영 테스트를 포함하여야 한다.

 

퇴역(retirement)하는 시스템에 대한 유지보수 테스팅은 긴 시간의 데이터 유지기간이 필요하다면 테이터 이전 혹은 저장에 대한 테스팅을 포함할 수 있다.

 

무엇이 변경되었는지에 대한 테스팅에 더하여, 유지보수 테스팅은 변경되지 않은 시스템의 부분들에 대한 대규모의 회귀 테스팅을 포함한다. 유지보수 테스팅의 범위(scope)는 기존 시스템의 크기(size)와 변경의 위험(risk)과 관련된다. 변경에 종속되어, 유지보수 테스팅은 모든 테스트 레벨에서 행하여 질 수 있으며, 일부 혹은 모든 테스트 종류에 대하여 행하여 질 수 있다.

 

변경 사항에 의하여 기존의 시스템이 어떻게 영향을 받는가를 결정하는 것은 영향 분석(impact analysis)라고 부른다. 그리고 영향 분석은 얼마나 많은 회귀 테스팅을 해야 하는가를 결정하는 것을 돕는다.

 

만약 명세서(specifications)들이 오래 되었거나 분실되었다면, 유지보수 테스팅은 어려워 질 수 있다.