정보처리기사: 소프트웨어 테스트, 테스트 오라클 (1) 완전 정복!!

소프트웨어 테스트

소프트웨어의 결함을 찾는 활동

 

소프트 웨어의 테스트의 필요성 ★

• 오류 발견 관점
• 오류 예방 관점
• 품질 향상 관점

 

소프트 웨어의 테스트 기본 원칙 ★★

• 완벽한 테스팅은 불가능하다.
• 테스팅 개발 초기에 시작
• 결함집중
• 소수의 특정한 모듈에 집중되어 존재한다.
• 파레토법칙 : 전체 결과의 80%가 전체 원인의 20%에서 일어나는 현상
• 살충제의 패러독스 : 반복적인 테스트로는 새로운 결합을 찾기 어렵다.
• 테스팅 방법은 특정상황에 의존적이다.
• 오류 부재의 궤변 : 오류가 없다해도 사용자 요구사항을 충족 못하면 품질이 좋다고 할수없다.

프로세스

테스트 계획- 분석 및 디자인 - 케이스및 시나리오 작성 - 수행 - 결과 및 평가 리포팅

 

 

테스트 산출물

산출물	설명
테스트 계획서	테스트의 전반적인 계획 및 목적, 범위, 절차, 일정, 역할 및 책임 등을 정의한 문서
테스트 케이스 ★	테스트 항목의 입력, 실행 조건 및 기대 결과를 포함한 명세서
테스트 시나리오	테스트 케이스의 동작 순서를 기술한 문서
테스트 결과서	테스트의 결과와 평가를 정리한 문서

 

 

테스트 오라클 ★★★(서술형도 출제 가능)

테스트 결과가 참인지 거짓인지를 판단 하기 위해 미리 정의된 참값을 입력하여 비교하는 방법

 

유형	설명
참 오라클 (True)	- 모든 입력 값에 대해 정확한 결과를 생성하는 오라클 - 오류를 완벽하게 검출할 수 있으며, 크리티컬한 시스템(항공기, 임베디드 시스템, 발전소 소프트웨어 등)에서 사용 [모두 일일이 참인지 체크하는 테스트]
샘플링 오라클 (Sampling)	- 제한된 입력 값들에 대해서만 예상되는 결과를 제공하는 오라클 - 대부분의 일반적인 소프트웨어(업무용, 게임, 오락 등)에서 사용 [몇개 샘플만 찍어서 테스트하는 테스트]
휴리스틱 오라클 (Heuristic)	- 특정 입력 값들에 대해서는 정확한 결과를 제공하나, 그 외의 값들에 대해서는 근사적인(추정) 결과를 제공하는 오라클 [특정 값에서만 정확하고 나머지는  샘플링 오라클인 테스트]
일관성 검사 오라클 (Consistent)	- 소프트웨어의 변경 전후로 테스트 결과의 일관성을 검증하는 오라클 - 소프트웨어의 변경이 있을 때, 변경 전후의 결과가 동일한지를 확인 [소프트 변경이 있을떄 일관성 검사 테스트]

 

 

 

테스트 레벨 ★★

① 단위 테스트(Unit Test)

• 구성요소의 기능적,비기능적 측면을 검증하는 테스트 프로세스의 첫단계
• 목적 : 코드의 효율성 (정적) , 코딩표준준수(정적),기능의정확성(동적)등을 검증
• 개별모듈간 구현 테스트
• CppUnit,JUnit,HttpUnit

② 통합테스트(Integration Test)

• 여러 모듈또는 서브시스템을 통합하고 상호작용 검증
• 목적 : 인테페이스간 오류 및 모듈간 상호작용 문제점 검출

③ 시스템 테스트(System Test)

• 완전히 통합된 소프트웨어의 사양간 일치성 검증
• 기능적 요구사항뿐만 아니라 비기능적 요구사항도 포함

④ 인수테스트(Acceptance Test)

• 시스템을 배포하거나 사용할 준비가 되었나 평가

유형	설명
알파 테스트	- 개발자의 통제 하에 사용자가 개발 환경에서 수행하는 테스트
베타 테스트 (필드 테스팅)	- 개발된 소프트웨어를 사용자가 실제 운영 환경에서 수행하는 테스트

 

알파테스트 : 개발자와 사용자가

베타테스트: 사용자가

 

 

소프트웨어 테스트 기법

1. 정적 테스트

• 프로그램을 실행하지않고 설계문서등을 분석해 문제점을 찾는 방식
• 경로 분석, 제어흐름,데이터흐름등을 수행

다시 한번 알아야할것

요구사항  검증 방법 ★

종류	설명
동료검토 (Peer Review)	- 2~3명이 진행하는 리뷰의 형태 - 요구사항 명세서 작성자가 요구사항 명세서를 설명하고, 이해 관계자들이 설명을 들으면서 결함을 발견해 나가는 형태
워크스루 (Walk Through)	- 시스템 개발 단계마다 실시하는 비정형 검토회의 형태 - 오류의 조기 발견이 목적 - 검토 자료를 회의 전에 배포해서 사전 검토 후 짧은 시간 동안 회의를 진행하여 결함을 발견해 나가는 형태 -개발자가 주최
인스펙션 (Inspection)	- 명세서 작성자를 제외한 다른 검토 전문가들이 명세서를 확인하여 결함을 발견해 나가는 형태 - 계획 → 개관 → 준비 → 검토회의 → 재작업 → 추적

 

2. 동적 테스트

• 소프트웨어를 실행하여 문제점을 찾는 방식

① 화이트 박스 테스트 / 글래스 박스

- 소프트 웨어 내부의 구조와 동작을 중점해서 검사 [개발자 관점]

 

기법	설명	검증
문장 검증	프로그램의 모든 문장을 한번 수행하여 검증	1,2,3,4,5,6,7
선택 검증	선택하는 부분만 검증	1,2,3,4,5,6,7 1,2,3,4,5,6,1
경로 검증	수행 가능한 모든 경로 검사	1,2,3,4,5,6,7 1,2,3,4,5,6,1 1,2,4,5,6,7 1,2,3,5,6,1
조건 검증	조건이나 반복문 내 조건식을 검사	x > 1 or y<10일경우

기법 위주로 외울것.

 

 

ⓐ 화이트 박스 테스트 계산

 

식외우지 말고 면 +1 만 외울것. 오른쪽 보면 면이3개니까 3+1 = 4개

 

② 블랙 박스 테스트★★

- 요구사항 명세를 보면서 테스트 주로 기능 테스트 [사용자 관점]

기법	설명
동등 분할 기법 (Equivalence Partitioning Testing)	- 입력 자료에 초점을 맞춰 테스트 케이스를 만들어 검사하는 방법 90~100 이면 95로 테스트
경계값 분석 (Boundary Value Analysis)	입력 값의 중간값보다 경계값에서 오류가 발생할 확률이 높다는 점을 이용해 입력 조건의 경계값을 테스트 케이스로 선정한다. 80~90의 입력 조건이 있을 때, 79,80,81, 89,90,91을 테스트 값으로 선정한다.
원인-효과 그래프 검사 (Cause-Effect Graphing Testing)	- 입력 데이터 간의 관계와 출력에 영향을 미치는 상황을 체계적으로 분석한 다음 효용성이 높은 테스트 케이스를 선정하여 검사하는 기법
오류 예측 검사 (Error Guessing)	- 과거의 경험이나 테스터의 감각으로 테스트하는 기법
비교 검사 (Comparison Testing)	- 여러 버전의 프로그램에 동일한 테스트 자료를 제공하여 동일한 결과가 출력되는지 테스트하는 기법이다.
상태전이 검사 (State Transition Testing)	- 시스템에 반영되는 이전의 상태가 무엇인지, 상태 간 전이, 상태를 변화시키는 이벤트와 입력값을 파악한다.