테스트 레벨

• 테스트 레벨
  - 소프트웨어의 개발 단계에 따라 분류되는 테스트 단계
  - 애플리케이션 테스트는 소프트웨어의 개발 단계에서부터 테스트를 수행하므로 단순히 소프트웨어에 포함된 코드 상의 오류뿐만 아니라 요구 분석의 오류, 설계 인터페이스 오류 등도 발견할 수 있음
  - 애플리케이션 테스트와 소프트웨어 개발 단계를 연결하여 표현한 것을 V-모델이라 함

• 단위 테스트 (Unit Test)
  - 코딩 직후 소프트웨어 설계의 최소 단위인 모듈이나 컴포넌트에 초점을 맞춰 테스트하는 것
  - 인터페이스, 외부적 I/O, 자료 구조, 독립적 기초 경로, 오류 처리 경로, 경계 조건 등을 검사
  - 사용자의 요구사항을 기반으로 한 기능성 테스트를 최우선으로 수행
  - 주로 구조 기반 테스트를 이용하여 테스트 수행
  - 발견 가능한 오류 : 알고리즘 오류에 따른 원치 않은 결과, 무한루프, 틀린 계산 수식에 의한 잘못된 결과 ...

테스트 방법	테스트 내용	테스트 목적
구조 기반 테스트	프로그램 내부 구조 및 복잡도를 검증하는 화이트박스 테스트 시행	제어 흐름, 조건 결정
명세 기반 테스트	목적 및 실행 코드 기반의 블랙박스 테스트 시행	동등 분할, 경계 값 분석

 

Q. 다음 중 단위 테스트 도구로 사용될 수 없는 것은?

1. CppUnit

2. JUnit

3. HttpUnit

4. IgpUnit

 

-> CppUnit : C++ 프로그래밍 언어용 단위 테스트 도구

JUnit : JAVA 프로그래밍 언어용 단위 테스트 도구

HttpUnit : 웹 브라우저 없이 웹 사이트 테스트를 수행하는 오픈 소스 소프트웨어 테스트 도구

IgpUnit : 존재하지 않음

• 통합 테스트 (Integration Testing, 결합 테스트)
  - 단위 테스트가 완료된 모듈들을 결합하여 하나의 시스템으로 완성시키는 과정에서의 테스트
  - 모듈 간 또는 통합된 컴포넌트 간의 상호 작용 오류를 검사
  
  
• 시스템 테스트 (System Testing)
  - 개발된 소프트웨어가 해당 컴퓨터 시스템에서 완벽하게 수행되는가를 점검하는 테스트
  - 환경적인 장애 리스크를 최소화하기 위해서는 실제 사용 환경과 유사하게 만든 테스트 환경에서 테스트 수행

테스트 방법	테스트 내용
기능적 요구사항	요구사항 명세서, 비즈니스 절차, 유스케이스 등 명세서 기반의 블랙박스 테스트 시행
비기능적 요구사항	성능 테스트, 회복 테스트, 보안 테스트, 내부 시스템의 메뉴 구조, 웹 페이지의 네비게이션 등 구조적 요소에 대한 화이트박스 테스트 시행

 

• 인수 테스트 (Acceptance Testing)
  - 개발한 소프트웨어가 사용자의 요구사항을 충족하는지에 중점을 두고 테스트하는 방법
  - 개발한 소프트웨어를 사용자가 직접 테스트
  - 문제가 없으면 사용자는 소프트웨어를 인수하고 프로젝트는 종료

테스트 종류	설명
사용자 인수 테스트	사용자가 시스템 사용의 적절성 여부를 확인
운영상의 인수 테스트	시스템 관리자가 시스템 인수 시 수행하는 테스트 기법으로 백업/복원 시스템, 재난 복구, 사용자 관리, 정기 점검 등을 확인
계약 인수 테스트	계약상의 인수/검수 조건을 준수하는지 여부를 확인
규정 인수 테스트	소프트웨어가 정부 지침, 법규, 규정 등 규정에 맞게 개발되었는지 확인
알파 테스트	개발자의 장소에서 사용자가 개발자 앞에서 행하는 테스트 기법 통제된 환경에서 행해지며 오류와 사용상의 문제점을 사용자와 개발자가 함께 확인하면서 기록
베타 테스트 = 필드 테스팅 (Field Testing)	선정된 최종 사용자가 여러 명의 사용자 앞에서 행하는 테스트 기법 실업무를 가지고 사용자가 직접 테스트하는 것으로, 개발자에 의해 제어되지 않은 상태에서 테스트가 행해지며 발견된 오류와 사용상의 문제점을 기록하고 개발자에게 주기적으로 보고

 

 

* 프로세스 능력 평가 모델

• SW-CMM (SW-Capability Maturity Model)
  - 프로젝트 개발 조직에서 프로세스 성숙도가 높은 조직이 성숙도가 낮은 조직보다 높은 품질의 소프트웨어를 생산할 수 있다는 모델
  - CMM은 소프트웨어 공급자의 강점과 약점을 평가하는 수단으로, 개발자가 프로세스의 능력을 스스로 평가하고 평가 결과에 따른 개선 방향을 설정하는 데도 사용
• CMMI
  - 프로세스 표준화의 기준과 방향을 제시하므로 조직 프로세스에 대한 측정뿐 아니라 평가 지표로도 활용할 수 있는데, 이때 능력을 평가하거나 성숙도를 평가할 수 있음
  - C (Capability; 능력) : 소프트웨어 개발에서 능력이란 개발 목표를 달성할 수 있는 힘인데 능력이 있는 조직은 개발 목표를 달성할 수 있으나 능력이 없는 조직은 개발 기간이 연장되거나 비용이 추가하는 등 품질이 떨어지는 소프트웨어를 개발하여 개발 목표를 달성하지 못함
  - M (Maturity; 성숙도) : 소프트웨어 개발에서 성숙도가 높은 조직이란 책임감이 있는 조직으로서 고품질의 소프트웨어를 개발하기 위해 개발 과정에서 객관적이고 정량적인 근거에 따라 프로세스가 측정되고 지속적인 개선이 이루어지는 조직이나 성숙하지 못한 조직은 책임감이 떨어지는 조직으로 개발 프로세스가 객관적인 근거에 의해 진행되지 않음
  - M (Model; 모델) : 프로세스를 감사하는 의미로 사용하며 기준대로 하고 있는지 아닌지를 검사하는데 조직이 프로세스 개선을 원한다면 CMMI는 그 조직이 무엇을 해야 하는지에 대해 '수행 지침'(기준)을 통해서 알려주나 구체적인 개선 방안은 조직의 역량에 맡김
  - I (Intergration; 통합) : 소프트웨어 개발 생명주기의 각 단계 (기획부터 유지보수까지) 모든 과정을 통합한 모델이라는 의미

* CMM과 CMMI의 비교

단계	CMM	CMMI
1	초기	초기
2	반복	관리
3	정의	정의
4	관리	정량적 관리
5	최적화	최적화

 

* CMMI 5단계 (소프트웨어 프로세스 성숙도)

단계	프로세스	내용
1. 초기(initial) 단계	프로세스 없음	예측 / 통제 불가능
2. 관리(managed) 단계	프로젝트를 위한 규칙화된 프로세스	기본적인 프로젝트 관리 체계 수립
3. 정의(defined) 단계	조직을 위한 표준화된 프로세스	조직 차원의 표준 프로세스를 통한 프로젝트 지원
4. 정량적 관리(quantitative managed) 단계	예측 가능한 프로젝트	정량적으로 프로세스가 측정 / 통제됨
5. 최적화(optimizing) 단계	지속적 개선 프로세스	프로세스 개선 활동

 

Q. CMMI(Capability Maturity Model Integration)의 단계에 대한 설명 으로 옳지 않은 것은?

1. 관리(managed)-프로젝트 진행 비용, 일정, 기능에 대한 추적이 가능한 단계

2. 정의(defined) - 소프트웨어 개발과정이 임시방편이거나 무질서하여 이를 정의해야 하는 단계

3. 최적화(optimizing) -정량적인 피드백과 기술을 통해 소프트웨어 개발 프로세스가 지속적으로 개선되는 단계

4. 정량적 관리(quantitatively managed) -소프트웨어 프로세스와제품의 품질에 대해 정량적 측정이 이루어지는 단계

 

 -> 정의 단계는 조직을 위한 프로세스가 잘 되어 조직별로 상황에 맞게 승인을 받아 지원을 받는 단계이며 해당 설명은 오히려 초기단계에 가까운 설명이다.