[2011 실라버스 - Chapter.2] 소프트웨어 수명주기 와 테스팅에 대해서 알아보자

※ "개발자도 알아야 할 소프트웨어 테스팅 실무"를 기반으로 요약 ※ 

Part 2. 소프트웨어 수명주기와 테스팅

2.1 소프트웨어 개발 모델

2.1.1 V-모델

요구사항 분석    ----------------------------------------------    인수 테스팅

         논리 설계  ---------------------------------    시스템 테스팅

      물리 설계 ----------------  통합 테스팅

                          코딩 --  컴포넌트(단위) 테스팅

 

 

개발 초기에 테스팅을 수행 한다는 것은 개발 산출물을 리뷰 형태로 검토하면서 결함을 발견하는 정적 테스팅을 의미한다. 정적 테스팅 동안 테스터는 테스팅 관점에서 테스트케이스를 만들면서 결함을 발견하여 리뷰에 기여 할 수 있다.

- 베리피케이션(Verification) : 개발 단계의 산출물이 그 단계의 초기에 설정된 조건을 만족하는지 여부를 검증하는 프로세스를 의미한다. 정적, 동적 테스팅 모두에서 검증 가능

- 벨리데이션(Validation) : 개발 중에 또는 개발단계 말에 명시된 또는 명시되지 않았지만 사용자의 관점에서의 요구사항이 만족하는지를 평가하는 프로세스를 의미한다. 정적, 동적 테스팅 모두에서 검증 가능

2.1.2 반복적-점증적 개발 모델

- 요구사항 분석 ,시스템 설계, 구현 및 테스팅하는 갭라 주기가 짧게 연속적으로 반복하는 활동으로 이루어 진다. 이 개발 방법론은 주로 초기 반복 단계에서 리스크가 높은 모듈이나 주요 아키텍처에 해당하는 시스템 일부를 우선적으로 개발하고 테스팅을 통해 결함이나 장애를 조기에 발견하고 제거할 수 있는 기회를 확보하기 때문에, 개발 리스크를 조기에 감소시킬 수 있는 장점을 가지고 있다.

2.1.3 개발 수명주기 모델에서의 테스팅

성공적인 테스팅을 위해서는 그 개발 수명주기 모델에 관계 없이 다음과 같은 요건들이 필요하다.

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

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

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

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

 

2.2 테스트 레벨

2.2.1 컴포넌트 테스팅

단위 테스팅이라고도 불리는 컴포넌트 테스팅은 테스트가 가능한 최소 단위로 나누어진 소프트웨어 내에서 결함을 찾고 그 기능을 검증하는 것이다.
1. 테스트 레벨의 일반적인 목표
- 기본 경로를 확인
- 모든 오류 처리 경로를 확인
- 컴포넌트 내의 인터페이스 확인
- 로컬 데이터 확인, 경계값 확인

2. 테스트 케이스를 도출해 내는데 참조되는 개발 산출물(테스트 베이시스)
- 컴포넌트 명세서, 소프트웨어 상세 , 데이터 모델등과 같은 개발 산출물

 

3. 테스트 대상

- 모듈 , 프로그램 ,객체 , 클래스 등... 

 

4. 테스트 하네스(드라이버/스텁) 필요 여부와 툴 지원의 필요성
- 테스트 하네스 필요 / 단위 테스트 프레임웍 또는 디버킹 툴 같은 개발환경의 지원 필요

 

5. 상세한 테스트 접근법

- 구조기반 테스팅 - 제어흐름 / 조건/결정 / 커버리지 / 최소 비교 테스팅 
- 동등 분활&경계값 분석 테스팅

 

6. 테스트 수행 주체 또는 조직
- 해당 개발자 , 타 개발자나 제 3자가 수행

2.2.2 통합 테스팅

통합 테스팅은 컴포넌트간의 인터페이스를 테스트 하는 것은 물론, OS, 파일 시스템, 하드웨어 또는 시스템간 인터페이스와 같은 시스템의 각기 다른 부분과 상호 연동하는 동작을 테스트한다.

 

<통합테스트 레벨의 통합 접근법>

	백본	빅뱅	상향식	하향식
수행 방법	가장 중요하고 리스크가 높은 모듈로 초기 통합 형성	모든 테스트 모듈을 동시에 통합	가장 하부의 모듈부터 통합해 가면서	가장 사부의 모듈부터 통합해 가면서
드라이버/스텁	드라이버/스텁을 필요에 따라 만들어 사용	드라이버/스텁 없이 실제 모듈로 테스트	테스트 드라이버가 필요하며 점차 개발되고 테스트된 상부 모듈로 대치	테스트 스텁이 필요하며 점차 개발되고 테스트된 하부 모듈로 대치
장점	결함 격리 쉬움 리스크가 높은 결함 발견을 초기에 발견	단시간 테스트	결함 격리 쉬움 하위 모듈을 충분히 테스트	결함 격리 쉬움 설계상의 결함을 빨리 발견
단점	테스트 시간이 오래 걸릴 수 있음	결함 격리 어려움	수정이 어려운 중요한 결함(설계상 결함)을 상부 구조에서 발견 가능 비지니스 로직 반영 어려움	수정이 어려운 중요한 결함을 하부에서 발견 가능

2.2.3 시스템 테스팅

시스템 테스팅은 개발 프로젝트 차원에서 저으이된 전체 시스템 또는 제품의 동작에 대해 테스트 하는 것이다.

 

1. 테스트 케이스를 도출해 내는데 참조되는 개발 산출물(테스트 베이시스)

- 리스크 분석서 / 요구사항 명세 / 비즈니스 프로세스 / 유즈 케이스 / 기타 비즈니스 레벨의 시스템 동작 명세 / OS 및 시스템 리소스와의 상호작용 명세

 

2. 상세한 테스트 접근법

- 기능적 요구사항은 명세기반(블랙박스) 기법을 수행한다.

- 비기능적 요구사항은 소프트웨어의 기능적 품질특성 외의 나머지 부분에 대한 요구사항 검증을 수행

 

3. 테스트 수행 주제 또는 조직

- 독립적인 테스트 팀

2.2.4 인수 테스팅

1. 테스트 레벨의 일반적인 목표
- 시스템이나 시스템의 일부 또는 특정한 비기능적인 특성에 대해 확신을 얻는 것이다.
- 인수 테스팅은 프로그램의 모든 개발 과정에서 수행할 수 있다.

2. 인수 테스팅의 전형적인 형태
- 사용자 인수 테스팅 - 일반적으로 비지니스 사용자가 시스템 사용의 적절성을 확인한다.
- 운영상의 인수 테스팅

3. 시스템 관리자에 의한 테스트 활동으로 일반적인 테스트 항목은 다음과 같다.
- 백원/복원 테스팅
- 재난 복구
- 사용자 관리
- 유지보수 작업
- 보안 취약성에 대한 정기적인 점검

4. 계약 인수 테스팅과 규정 인수 테스팅
- 계약 인수 : 계약 조건 충족 확인
- 규정 인수 : 정부 지침 , 법률 또는 안전 규정을 준수했는지 확인

5. 알파 테스팅과 베타 테스팅
- 알파 : 개발 조직 내에서 고객에 의해 수행 = 공장 인수 테스팅
- 베타 : 실제 환경에서 사용자 혹은 잠재 고객에 의해 수행 = 사이트 인수 테스팅

 

2.3 테스트 유형

2.3.1 기능 테스팅

- 적합성 ,정확성 , 준수성 ,상호운용성 , 보안성

2.3.2 비기능 테스팅

- 성능 , 부하 , 스트레스 , 사용성 , 유지보수성 , 신뢰성 , 이동성 테스팅 등...
- 신뢰성 , 사용성 , 효율성 , 유지보수성 , 이식성

2.3.3. 구조적 테스팅

- 특정 유형의 구조에 대한 커비리지를 평가하여 테스팅의 보장성 또는 충분함을 측정하는 것이 목적인 테스트 유형이다.

2.3.4 확인(재) / 리그레션 테스팅

1.확인 테스팅 : 결함이 발견되고 수정된 후에 원래의 결함이 성공적으로 제거되었는지 확인하기 위해 다시 테스트 하는 것. 여기서 결함의 원인을 찾거나 결함을 수정하기 위한 디버깅은 개발활동이며 테스트 활동으로 보지 않는다.

 

2. 리그레션 테스팅 : 이미 테스트된 프로그램의 테스팅을 반복하는 것으로 결함 수정 이후 변경의 결과로 새롭게 만들어 지거나 , 이전 결함으로 인해 발견되지 않았던 또 다른 결함을 발견하는 것이다. 모든 테스트 레벨에서 수행 가능하며, 기능 , 비기능 , 구조적 테스팅에 적용할 수 있다.

 

Related References

- 도서 : 개발자도 알아야 할 소프트웨어 테스팅 실무

- 도서 : 개발자도 알아야 할 소프트웨어 테스팅 패키지(전2권)

 

ISTQB

요약 : iso 표준, 국제 표준 iso, 국내 표준, 표준, istqb, kstqb, 웹 qa, 모바일 qa, 앱 qa, test web