//구글콘솔 광고 추가가
4.4.2 구조 기반 기법
4.4.2.1 분할 방법으로 접근한 조건 / 결정 커버리지

 - 분할 

   >> 논리적 테스트 컬럼의 각각을 선택한 커버리지로 생성한 모든 논리적 조합으로 분할하여 테스트 케이스를 작성하는 방식.

   >> 모든 조합을 분할해서 나열하기 때문에 결함 원인매우 빨리 발견할 수 있지만 테스트 케이스 수가 크게 증가함.

 - 포함

   >> 논리적 테스트 컬럼의 각각의 선택한 커버리지

   >> 생성한 조합 중에서 단 하나만 선택하여 하나의 논리적 테스트 케이스로 작성하는 1:1 전환 방식(테스트 케이스 줄임)

 - 결정 테이블을 분할로도 만들수 있고 분할돼있는 걸 포함해서 다시 만들어낼 수 있음.

4.4.3 경험 기반 기법
4.4.3.1 오류 추정

 - 테스터가 테스트 할 시스템에 대하여 완전히 이해한다는 전제로 적용되는 기법.

 - 취약점 식별 작업에 기반한 테스트.

 - 테스트 프로세스의 마지막 단계에서 사용.

 - 일반적인 유용성

   >> 테스트에 참고할 명세가 없거나 불충분할 경우, 시간적인 압박이 심한 경우 유용.

   >> 다른 기법이나 공식적인 테스트보완할 때 유용하게 사용.

   >> 가장 심각한 결함을 찾았다는 확신이 필요한 경우 사용함으로써 테스트 프로세스 및 완성도확인하는 기준을 제공.

4.4.3.2 체크리스트

체크리스트

 - 테스팅 절차와 테스트 대상 기능 및 시스템 요소 등을 체크리스트로 작성함.

 - 일반 체크리스트 : 수행해야 할 테스트 목록과 절차를 나열함.

 - 기능(블랙) 체크리스트

   >> 전체 시스템의 최상위 기능 체크

   >> 개별적인 컴포넌트 기능

   >> 서로 다른 레벨의 기능과 그룹핑

 - 시스템 요소 체크리스트

   >> 상위 레벨 서브 - 시스템이나 모듈

   >> 개인 구문이나 데이터 아이템 체크

   >> 서로 다른 레벨의 시스템 요소와 그룹핑 체크

체크 리스트와 테스트 케이스 비교

 - 체크 리스트

   >> 경험과 노하우반영물이어서 테스트를 효율적으로 진행할 수 있음.

   >> 효과성은 없음.

   >> 테스트 베이시스에서 결함을 발견하는 데 주로 사용되어서 정적 테스트기법의 주요 도구 사용.

 - 테스트 케이스

   >> 동적 테스팅의 주요 도구가 됨.

   >> 기법을 적용하여 도출되는 경우가 대부분이고 기법이 보장하는 범위에서 효과성보장해줌.

4.5 테스트 기법의 선택
어떤 테스트 기법을 사용할지 결정할 때 고려할 사항
 - 시스템 유형 및 특징
 - 강제적 표준 또는 법적 기준 적용 여부
 - 고객 또는 계약상의 요구사항
 - 리스크 수준
 - 리스크 유형
 -테스트 목표
 - 문서(베이시스)의 존재 여부
 - 테스터의 지식수준
 - 시간과 예산
 - 테스트 레벨
 - 개발 생명 주기
 - 유즈케이스, 상태 다이어그램 등 개발 설계 모델 존재 여부(있다면 이용, 없다면 새로 만들어)
 - 발견된 결함 유형 등 이전의 경험

테스트 기법을 잘 사용하게 되면...

 - 테스트 전략을 구체적으로 해석해 적절한 기법을 적용

 - 임의로 테스트 케이스를 작성하는 것보다 결함을 발견할 수 있는 효과적인 테스트 케이스 작성 가능(결함 발견율 높아짐)

 - 테스트(케이스)의 높은 재사용성 보장

 - 테스트 강도(커버리지)와 품질에 대한 통찰을 제공

 


4장은 솔직히 시험에선 그렇게 안 중요하데. 시험에 잘 안 나오나 봐.

근데 중요한 내용이긴 하니까 알아두자고.

728x90

+ Recent posts