노년코딩

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.3 경험 기반 기법(Experience-based)

▶ 경험 기반 테스팅
 - 이전에 테스터가 다루었던 유사 어플이나 기술에서의 경험, 직관, 테스터의 기술 능력으로부터 테스트 케이스 추출.
 - 공식적인 방식 아닌 특별한 테스트 케이스를 찾아내고 실행하는 데 유용 -- > 공식적인 기법과 같이 사용해야 효과적
 - 경험에 따라 효율성 및 효과성의 정도가 매우 달라짐(일관성 떨어짐)
 - 테스트 케이스를 문서화함
 - 또 다른 말로 에러 추정(Error guessing) 또는 탐색적 테스팅(Exploratory Testing) 접근법이라 함

4.3.3.1 탐색적 테스팅 기법

▶ 탐색적 테스팅 : 기법이 아닌 접근법
 - 테스트 케이스 작성 시간을 최소화하고 테스트 엔지니어의 발견적인(heuristic) 지적능력을 최대한 활용하여 테스트 수행
 - 다른 명칭으로 에드혹, 게릴라, 직관적 테스팅과 유사한 개념
   >> But, 정해진 임무와 목표, 결과물이 존재
 - 테스트를 먼저 작성하지 않고, 테스트 대상 제품을 실행하면서 익숙해지는 동시에 테스트를 설계하고 테스트를 계획한다.
   >> 테스트 차터를 기반으로 수행(60 ~ 120분 동안 몰입해서 수행)
   >> 제한된 시간(time-boxing)내에 테스팅의 목적을 정한 후  몰입하여 최소한의 설명 가능한 기록(note)을 남기며 테스트 수행하고, 수행 후 요약보고(debriefing)를 하는 것을 강조.
▶ 탐색적 테스팅
 - 경험적인 요소를 많이 반영하고 있는 체계화된 테스팅 접근법
 - 테스트 케이스 작성(문서화)하는데 들이는 노력을 최소화
 - 테스트 설계와 실행 최대화
 - 점진적 & 주기적 테스팅
▶ 탐색적 테스팅 절차
 - 제품의 목적 식별
 - 기능 식별
 - 잠재적으로 불안정한 부분 식별
 - 각각의 기능 테스트 및 문제점 기록
 - 일관성 검증 테스트 설계 및 기록
▶ 탐색적 테스팅의 구성 요소 (테스터 차터 >> 테스트 노트 >> 타임 박싱 >> 회고)
 - 테스터 차터
   >> 제품의 어느 부분을 어떻게 테스트하고 어떤 것을 중점적으로 봐야 할지 등을 기록한 테스트 명령지
   >> 각 세션에 대해 명확한 임무를 설정
 - 테스터가 수행할 내용
   >> 정확한 리포팅
   >> 유연성 있는 일정 관리
   >> 테스트 방향 정정
   >> 견고한 테스팅
   >> 효율적인 요약 보고
- 테스트 노트
   >> 테스트 실행과 동시에 계획, 설계, 테스트 케이스 작성 --> 노트화 함
   >> 테스트 기록 및 발견 특이사항과 실행시간 등 기재 --> 테스트 케이스
   >> 내용 : 테스트한 제품에 대한 노트 및 기록, 발견한 결함과 장애에 대한 노트 및 기록, 어떻게 테스트하였는지를 기술하는 요약된 문서.
- 타임 박싱(60분 ~ 120분)
   >> 테스트 집중력을 높이기 위해 테스트 시간을 제한
   >> 테스트 시간을 제한하면 집중력이 높아지며, 테스트 일정 수립도 쉬움
- 회고(요약보고 - debriefing)
   >> 테스트 중 발견했던 결함과 이슈사항에 대해 보고
   >> 테스터의 경험과 지식을 공유
   >> 문서화 
▶ 테스트 케이스 기반 테스팅과 탐색적 테스팅 비교
 - 테스트 제품을 파악해 가면서 테스트 실시
 - 탐색적 테스트는 테스터의 성향에 많이 의존적임
 - 문서화 정도와 지적 능력의 활용 정도에 따른 비교 

   >> 테스팅 케이스 기반(연설문을 만든다 -문서화하는 능력) - 문서화가 잘 돼있을수록 테스트케이스 기반 테스팅 할 수 있음.
   >> 탐색적 테스팅(경험에 의해 하는거 - 지적 능력) - 지적능력이 있을수록 탐색적 테스팅할 수 있음.
 - 테스트 케이스 기반 테스팅과 탐색적 테스팅의 비교 (밑에 표)

▶ 리스크 기반 테스팅과 연계한 탐색적 테스팅의 활용
 - 리스크 기반 전략에서의 탐색적 테스팅 접근법 활용 
테스트 전력 수립 시 제품의 리스크가 가장 높은 곳에 탐색적 테스팅을 추가, 그다음 높은 곳에 선택적 탐색적 테스팅 추가. 리스크가 가장 높은 곳에 테스팅 경험이 풍부하고 능력 있는 테스트 엔지니어가 탐색적 테스팅을 수행하여야 함. 반대로 리스크가 가장 낮은 곳에 경험과 능력이 상대적으로 부족한 테스트 엔지니어가 수행.
▶ 탐색적 테스팅 효과
 - 경험적 테스팅을 체계화 시킬 수 있음.
 - 테스트 케이스 작성 시간을 줄여 좀 더 많은 테스트 가능
 - 테스터 또는 테스트 엔지니어의 역량을 강화할 수 있음.
 - 적은 테스트 인력으로 많은 테스트를 수행할 수 있음.
 - 명세가 없고 시간 부족인 경우 테스트를 효과적으로 효율적으로 수행할 수 있음.

4.4.1 명세 기반 기법 - 분류 트리 기법

▶ 분류 트리 기법
 - 소프트웨어 일부 또는 전체를 트리구조로 분석 및 표현하고 이를 바탕으로 테스트 케이스를 도출하는 기법.

 < 분류 트리의 장점 >
1. 시각화해서 테스트 케이스 작성에 용이.
2. 트리 구조이므로 중복되거나 빠지는 테스트가 없음.
3. 복잡한 시스템이나 어플리케이션의 일부 또는 전체를 테스팅.
4. 개발 설계를 체크하는 용도로 사용이 가능함.
5. 테스트 케이스 개수와 트리의 복잡도를 근거로 테스트 비용을 추정하는 것이 가능함.