CSTS 3장 소프트웨어 개발 단계와 테스트

테스트 레벨	컴포넌트/단위 테스트 통합 테스트 시스템 테스트 인수 테스트		명세바탕 컴포넌트 간의 인터페이스 전체 시스템이 목적을 만족시키는지 테스트 사용자의 요구사항을 만족하는지 확인
테스트 설계	정적테스트 (소스코드 O)	리뷰	관리리뷰 기술리뷰 워크쓰루 인스펙션 감사
		정적 분석	코딩 표준 복잡도 측정 자료 흐름 분석
	동적테스트 (소스코드 X)	명세기반테스트	동등 분할 분류 트리 기법 경계값 분석 신텍스 테스트 조합 테스트 상태 전이 테스트 인과 그래핑 결정표 테스트 시나리오 테스트
		구조 기반 테스트	문장 테스트 결정 테스트 조건 테스트 결정/조건 테스트 다중 조건 테스트 변형 조건/결정 테스트 (MCDC) 기본 경로 테스트
		경험 기반 테스트	오류 추정 탐색적 테스트
테스트 유형	기능 테스트		기능적 요구사항측면의 결함 검출 및 충족 여부를 확인
	비기능 테스트   기성호사신보유이	기능 적합성	사용자의 요구사항을 만족하는 기능이 제공되는 정도
		성능 효율성	응답시간, 처리량
		호환성	다른 시스템과의 상호 연동 능력, 공존성
		사용성	사용자가 이해하고 배우기 쉬운 정도
		신뢰성	규정된 조건/기간에 오동작없이 수행하는 능력
		보안성	시스템의 정보 및 데이터 보호 능력
		유지보수성	소프트웨어 유지보수 용이성
		이식성	다양한 플랫폼에서 운영될 수 있는 능력

 

이 표는 처음에는 이상했는데 쪼개서 외우다가 한 번에 보면 괜찮아집니다.  처음에는 어질어질.. ㅠㅠ 

구조를 알아야 문제 풀기가 쉬워요 .

 

 

컴포넌트 테스트
단독으로 실행할 수 있는 환경이 필요 (테스트 환경 = 테스트 베드)
개벌적인 모듈, 컴포넌트의 기능이 올바르게 작동하는지 테스트
[단위 테스트 드라이버]  → [컴포넌트0]  →  [컴포넌트 1의 스텁] :
  컴포넌트 0에서 컴포넌트 1을 호출하는 대신에 스텁을 호출

모의 객체 생성 프레임워크 
  스텁의 객체 지향 버전. 모의 객체를 만들어 컴포넌트 테스트를 수행. 아래의 4가지가 모의 객체

① 더미(Dummy) : 객체는 테스트할 때 객체만 필요하고 해당 객체의 기능까지는 필요하지 않은 경우에 사용
② 테스트 스텁(Stub): 더미 객체에 단순한 기능성을 작성. 추가 객체의 특정 상태를 가정해서 특정한 값을 리턴,
③ 테스트 스파이(Spy): 테스트 대상 클래스(CUT)와 협력하는 클래스로 가능 출력을 검증하는 데 사용
④ 가짜(Fake): 실체 협력 클래스의 기능을 대체해야 할 경우에 사용. 실체 협력 클래스의 기능 중 전체나 일부를 훨씬 단순하게 구현 (실제 협력 클래스가 미구현, 느리거나 테스트 환경 사용할 수 없을 때 사용)
☞ 보기로 나오는 경우가 있어서 개념을 알아두면 됩니다. 

 

컴포넌트 테스트를 잘 수행하기 위한 FIRST 원칙 (외우기)
Fast : 컴포넌트 테스트는 빠르게 수행되어야 한다.
Isolated : 컴포넌트 테스트가 다른 컴포넌트 테스트에 의존하지 않도록 해야 한다.
Repeatable : 테스트를 몇 번 실행해도 동일한 결과가 나오도록 해야 한다.
Self-Validating: 사람의 개입없이 테스트가 통과되었는지 알 수 있도록 작성해야 한다. 자동화하여 사람이 개입할 필요 없도록
Timely : 컴포넌트 테스트는 제때 수행되어야 한다. 예) TDD 에서는 코드 작성 바로 전 테스트 수행

 

통합테스트
컴포넌트 간의 상호 연동이 제대로 수행되는지 검사
통합테스트의 목적 1) 컴포넌트간 연결성의 정확성 2) 기능적인 측면
예) 컴포넌트 1, 2 간의 데이터 연결에만 초점을 두는 경우
     ☞ 데이터 누락, 데이터 변경, 데이터 전달 순서 변경에 테스트 수행
예) 컴포넌트 간 기능적인 측면에서 적합성 확인하는 경우

 

점진적 통합
┌ 빅뱅 - 전체 컴포넌트를 한 번에 통합하여 테스트. 오작동의 원인이 되는 컴포넌트를 찾기 어렵다.
├ 점진적 방식 – 적은 수의 컴포넌트를 차례로 통합. (단점: 테스트 드라이버, 스텁을 여러 번 개발)
├ 상향식 통합 – 호출 관계의 하위에 있는 컴포넌트들을 시작으로 해서 상위에 있는 컴포넌트들을 통합
              테스트 드라이버를 작성하여 테스트 . 여러 모듈의 묶음을 클러스터 또는 빌드
              (장점)하위 컴포넌트를 충분하게 테스트.+ 하향식 통합에서 필요한 테스트 스텁 비용 들지 않음
├ 하향식 통합 – 가장 상위에 있는 컴포넌트에서 시작하여 하위에 있는 컴포넌트들을 점진적으로 통합
├ 깊이 우선 방식/ 너비 우선 방식을 사용 à 테스트 스텁을 하나씩 실제 컴포넌트로 대치. 그 후에 리그레션 테스트 수행
└ 샌드위치 통합 – 상향식과 하향식 두 방법을 결합
* 스텁과 드라이버 → P54, 55 그림 참조

 

상위 컴포넌트는 시스템의 기능을 결정하고 하위 컴포넌트는 시스템이 제공하는 기능을 보조하는 역할을 한다.
상위 컴포넌트의 결함은 시스템 설계의 문제가 나타난 것으로 해석.
상위 컴포넌트의 결함은 상위 컴포넌트를 반복적으로 테스트하는 하향식 통합 테스트 방식으로 빠르게 발견할 수 있다.
하향식 통합 테스트 방법은 많은 수의 테스트 스텁이 필요하므로 테스트 스텁 비용이 많이 든다면 효과적이지 않다.

 

시스템 테스트
통합 테스트가 완료된 후에 전체 시스템이 시스템 명세에 따라 개발되었는지 검증
시스템의 기능 측면뿐만 아니라 성능, 호환성, 사용성, 신뢰성, 보안성, 유지보수성, 이식성 등 비기능적인 요구사항을 만족하는지도 검증한다.

 

인수 테스트
실제 사용자의 요구사항을 만족하는지 확인
결함 검출이 아니라 시스템을 인수해도 되는지 고객의 입장에서 평가하는 것
TC는 사용자 또는 소프트웨어 구입자가 제기할 수도 있고, 시스템 테스트에서 사용했던 TC를 사용할 수도 있다.
개발자가 수행한 테스트로 발견되지 않은 결함이 테스트 단계에서 발견될 가능성이 있다.

 

알파테스트 : 선택된 사용자 회사내의 다른 사용자 또는 실제 사용자가 개발자 환경에서 통제된 상태로 수행

베타테스트 : 일정 수의 사용자에게 소프트웨어를 사용하게 하고 피드백을 받는다. 베타 테스트에는 개발자가 참여 X

 

리그레션 테스트

 

유지보수 단계에서 소프트웨어 수정하는 이유 4가지(기출)
  - 결함 수정 작업
  - 기능 보강 작업 : 기능 추가, 성능 개선
  - 적응 작업: 소프트웨어 시스템을 새로운 운영환경에 적응시키기 위해 소프트웨어를 변경하는 유지보수 활동
  - 예방 작업: 더 나은 유지보수를 위해 기존의 소프트웨어 시스템에 대한 문서를 준비하거나 시스템 구조를 유지보수하기      
    용이한 새로운 구조로 변경하는 작업 활동 예) REGACY CODE 제거 -> 예방작업
  - 리그레션 테스트에서 중요하게 고려할 점은 ‘테스트 케이스의 규모 &  시간이 갈수록 새로운 기능이 추가되는 시스템은 테스트에 소요되는 비용과 시간도 늘어날 것이다.

 

리그레션 테스트 4가지
┌ Retest-All : 모든 테스트 케이스를 사용 but 너무나 많은 시간과 자원이 필요하다.
├ 선택적 리그레션 테스트: 기존의 테스트 케이스 일부만 선정하는 방식
  예) 슬라이싱 기법, 자료 흐름 분석과 변경 영향 분석을 통해 프로그램과 변경된 프로그램이 서로 다른 결과를 출력할 가능성이 있는 테스트 케이스를 식별하여 리그레션  테스트를 수행한다.
├ 테스트 최소화 방식 :
  중복된 케이스르 제거하여 테스트 케이스를 줄이는 방식
  커버리지 개념 사용
   실제 테스트 케이스가 제거될 수 있다.
   변경되는 부분이나 변경에 의하여 영향받는 부분을 테스트하는 TC가 제거될 위험이 있으므로 주의

└ 테스트 우선 순위화 방식 – 
     TC에 우선 순위를 두어 우선 순위가 높은 테스트 케이스만을 활용
     가능한 한 빨리 많은 결함을 검출할 수 있도록 TC의 실행 순서를 결정한다.
     테스트 유지보수 단계에는 더 이상 필요없는 테스트 케이스를 제거하는 과정이 있다.
     Cf) 스모크 테스트 : 빌드가 테스트할 수준인지 확인하는 테스트 (보기로 나오는 경우가 있다.) 

* APFD( Average Percentage of Faults Detected)
테스트 우선 순위 효과성을 평가하기 위한 척도
APFD가 높다는 것은 더 적은 수의 TC를 실행하여 많은 결함을 빠르게 검출할 수 있다.
테스트 케이스 실행 비율 대비 검출된 결함의 비율을 측정
테스트 케이스의 수, 결함의 수, 실행 순서로 계산
리그레션 테스트의 우선순위를 결정하는 데 사용
APFD =  (P61참고)