노년코딩

4.4.2 구조 기반 기법
4.4.2.1 분할 방법으로 접근한 조건 / 결정 커버리지

 - 분할 

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

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

 - 포함

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

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

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

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

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

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

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

 - 일반적인 유용성

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

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

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

4.4.3.2 체크리스트

▶ 체크리스트

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

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

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

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

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

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

 - 시스템 요소 체크리스트

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

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

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

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

 - 체크 리스트

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

   >> 효과성은 없음.

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

 - 테스트 케이스

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

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

4.5 테스트 기법의 선택

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

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

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

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

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

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

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

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

4.3.1.5 유즈케이스 테스팅

▶ 유즈케이스 테스팅

 - 액터와 액터 사이의 상호작용을 표현 --> 유저에게 결과값 전달.

 - 시스템(SW)이 유즈케이스로 모델링 되었을 때, 유즈 케이스를 활용해 테스트 케이스를 도출하는 테스트 설계 기법.

   >> 유즈케이스를 어떻게 작성하느냐에 따라 유즈 케이스의 테스트 용이성이 달라짐 --> 잘못 만들면 테스팅하기 어려울 수 있음

 - 프로세스 흐름을 기술

   >> 기본 흐름

   >> 대체 흐름

 - 유즈케이스 상세(description) 

 - 시나리오를 짬

 - 프로세스 흐름 기술

 - 유즈케이스를 통해 생성된 테스트 케이스를 통해 시스템이 실제 사용되는 프로세스 흐름에서 결함을 발견하는 데 유용.

 - 고객이나 유저 그룹을 참여시키는 인수 테스트를 설계할 때 유용.

 - 통합 테스트 단계에서 컴포넌트 사이의 통합 결함을 찾는데 도움.

▶ 테스트 순서

 - 유즈케이스 상세를 문장별로 분석하여 테스트 케이스 도출 -- > 누락을 최소화하고 일정 수준의 보장성을 확보

1.  어떤 흐름을 테스트 할지 고려하여 테스트 시나리오 구성
2.  유즈케이스 상세에서 테스트에 필수적인 상황 선택
3.  유즈케이스 상세 내용을 입력값, 출력값, 상황 처리 등으로 분류하여 테스팅에 관여하는 상황을 선택.
4.  각각의 상황에 ID 부여
5.  각각의 상황에 가능한 값을 결정

▶ 컴포넌트(단위) 레벨 유즈케이스 테스팅

 - 유즈케이스 각각을 테스팅하는 방법

▶ 시스템 레벨 유즈케이스 테스팅

 - 유즈케이스 상호 간의 활동을 테스트

 - 상태관점에서 파악하고 활동의 흐름을 전이로 간주하여 상태 전이 테스팅 기법의 컨셉을 활용.

   >> 활동 기반 커버리지 : 각각의 활동만을 테스팅

   >> 전이 기반 커버리지 : 활동의 흐름을 테스팅

   >> 경로 기반 커버리지 : 재귀적인 흐름도 고려한 테스팅

   >> 활동 기반 ⊂ 전이 기반 ⊂ 경로 기반 --> 포함관계 존재

4.3.2 구조기반 기법(Structure -based)

▶ 화이트 박스 테스팅 --> 시스템의 구조를 중심으로 테스팅

 - SW코드나 설계 등 구조를 표현하는 정보로부터 테스트 케이스 도출

 - 작성한 테스트 케이스들로부터 커버리지를 측정할 수 있으며, 커버리지를 높이기 위해 테스트 케이스를 체계적으로 추가

   >> 제어 흐름 테스트, 기본 경로 테스트, x커버리지 테스팅

 - 구문 커버리지 (statement coverage)
   >> 테스트 스위트(테스트 케이스 모아둔 거)에 의해 실행된 구문이 몇 퍼센트(%)인지 측정(가장 약함)
 - 결정 커버리지 (decision coverage)
   >> 실행된 결정 포인트 내의 전체 조건식이 최소한 참이 한 번 그리고 거짓이 한 번씩 선택되었는지 측정하여 퍼센트로 표현
 - 조건 커버리지
   >> 전체조건식의 결과와 관계없이 각 개별 조건식이 참 한번, 거짓 한 번을 모두 갖도록 개별조건식을 조합 (결정 커버리지 보다 강력) 

4.3.2.1 구문 테스팅과 커버리지

▶ 구문 커버리지

 - 테스트 스위트에 의해 실행된 구문이 몇 퍼센트 인지 측정

   >> 존재하는 가능한 경우를 모두 검증 못하는 보장성이 낮은 커버리지

 - 구문 테스팅은 구문 커버리지를 늘리기 위해 특정 구문을 테스트하는 테스트 케이스 도출

   >> 코드의 모든 구문을 실행할 수 있는 입력값이나 이벤트 등의 테스트 데이터를 제공해 주면 달성됨.

4.3.2.2 결정 테스팅과 커버리지

▶ 결정 커버리지

 - 분기 테스팅과 관련

 - 테스트 스위트(suite, 묶음)에 의해 실행된 조건문 분기 (if문의 참/거짓)가 전체 가능한 분기의 몇 퍼센트인지를 측정하고 평가

 - 결정 포인트 내의 전체조건식이 참과 거짓의 모든 값을 갖게 되어 모든 분기로 흐르게 되면 달성

▶  결정 테스팅

 - 결정 커버리지를 늘리기 위해 특정 조건문의 분기를 테스트하는 테스트 케이스를 도출하는 것

 - 제어 흐름 테스트

▶ 제어 흐름 테스트

 - 구조 기반 테스트 --> 코드 레벨의 커버리지 개념 필요

 - 프로그램 구조 테스트

 - 공식적인 화이트 박스 테스트 -- > 단위 / 통합 테스트에서 사용

   >> 테스트 깊이 레벨에 따라 강도 존재

   >> 테스트 케이스를 선택된 흐름에 따라 연속적인 구문의 집합으로 기술

   >> 테스트 깊이가 깊을수록 제품의 커버리지는 높아지는 반면 테스트 케이스가 기하급수적으로 많아져 비용, 시간, 리소스 많이 소요됨.

4.3.2.3 조건 테스팅과 커버리지

▶ 조건 커버리지

 - 결정 포인트 내에 있는 개개의 개별 조건식이 참 / 거짓의 모든 값을 갖게 되면 달성

 - 조건 커버리지(강력, 견고한 테스트) > 결정 커버리지

▶ 조건/ 결정 커버리지(응용버전)

 - 항상 결정과 조건 커버리지를 모두 만족시키는 것보다 강력

 - 결정과 조건 커버리지를 최소한 조합으로 달성하는 경우

   >> 항상 모든 개별 조건식이 참이고 이에 따른 전체 조건식이 참인 경우

   >> 모든 개별 조건식이 거짓이면서 이에 다른 전체 조건식이 거짓인 경우

▶ 커버리지 레벨(depth level) - 밑으로 갈수록 완화됨

 - 다중 조건 커버리지(Multiple condition coverage) -- > 가장 강력

   >> 결정 포인트 내의 개별 조건식 결과(참/거짓)에 대한 모든 가능한 논리적인 조합을 적어도 한 번 수행.

 - 변형 조건/ 결정 커버리지(MC/DC)

   >> 결정 포인트 내에 다른 개별 조건식의 결과와는 독립적으로 해당 개별 조건식이 전체 조건식의 결과에 영향을 줌.

 - 조건/ 결정 커버리지 (COndition/ decision coverage)

   >> 모든 개별 조건식이 전체 조건식 판단문의 결과값 확정에 관여하는 경우를 모두 고려함.

 - 조건 커버리지(Condition coverage)

   >> 프로그램 내에 있는 결정 포인트 내의 모든 각 개별 조건식에 대한 모든 가능한 결과(참/ 거짓)에 대해 적어도 한번 수행.

▶ 다중 조건 커버리지

 - 결정 포인트 내에 있는 모든 개별 조건식의 모든 가능한 논리적인 조합을 고려하여 100% 커버리지를 보장

 - 출시 전 모든 결함을 제거해야 하는 제품 테스트에서 주로 사용. 

4.3.2.4 변형 조건/ 결정 커버리지(MC/ DC)

▶ 변형 조건 / 결정 커버리지(Modified Condition/ Decision)

 - 각 개별 조건식이 다른 개별 조건식에 영향을 받지 않고 전체 조건식의 결과에 독립적으로 영향을 주도록 함

 - 조건/ 결정 커버리지를 향상 시킴

 - 조건 커버리지나 결정 커버리지 보다 강력

   >> 프로그램에 있는 모든 결정 포인트 내의 전체 조건식은 적어도 한 번 모든 가능한 결과값(참, 거짓)을 취한다.

   >> 프로그램에 있는 결정 포인트 내의 모든 개별 조건식은 적어도 한번 모든 가능한 결과값(참,거짓)을 취한다.

   >> 결정 포인트에 있는 각각의 개별 조건식은 다른 개별 조건식에 영향을 받지 않고 그 결정 포인트의 결과값에 독립적으로 영향을 준다.

 - 가능한 의미 있게 조합의 수를 줄여 테스트 수행.