노년코딩

5.1.1 테스트 조직과 독립성

** 테스팅은 테스터 뿐만 아니라 프로젝트 관리자, 품질 관리자, 비즈니스와 해당 분야 전문가, 인프라 또는 IT 운영자 등 다른 조직에 의해서도 수행 가능.

▶ 테스트 조직 생성 및 운영 시 고려할 사항

 - 개발 프로젝트와 조직의 목적에 부합하는 독립성 수준을 결정

 - 개발팀과 테스트 팀과의 의사소통 계획이 적절하게 수립

 - 독립성 수준을 정할 때 개발 산출물의 오픈 가능성을 고려

 - 조직의 규모에 따라 여러 형태의 독립성 수준의 테스트 조직을 운영

 - 개발팀과 테스트팀 간의 갈등을 초례할 수 있는 부분을 고려하여 테스트 정책을 수립하고 배포

5.1.2 테스트 리더와 테스터의 임무

▶ 테스트 리더(테스트 매니저, 팀 리더, 분석가)

 - 테스팅 활동과 업무를 계획하고 모니터링하고 제어하는 역할.

   >> 테스트 전략과 계획을 프로젝트 관리자 및 이해 관계자와 조정

   >> 프로젝트 테스트 전략과 조직의 테스트 정책을 작성하고 검토

   >> 테스팅 관점으로 통합적인 계획 활동 등 프로젝트 활동에 기여

   >> 정황과 테스트 목적, 리스크를 고려해 테스트 계획을 수립

   >> 테스트 명세(설계), 준비, 구현과 실행, 테스트 모니터링 및 완료 조건 평가등의 시작을 주도

   >> 테스트 결과와 진척에 따라 계획을 조정하고 문제점 보안을 위해 제어 활동 수행

   >> 추적성 확보에 필요한 테스트웨어 형상 관리 체계(시스템)를 구성

   >> 테스트 진척 및 품질 평가에 필요한 메트릭(점수를 도입할수 있는 평가표)을 도입
   >> 테스트 자동화 대상, 범위 방법을 결정
   >> 테스트 자동화 도구를 선택하고 관련 교육을 계획
   >> 테스트 환경 관련 사항을 결정
   >> 수집한 정보를 근거로 테스트 요약 보고서 작성

▶ 테스터(테스트 분석가, 수행가, 네비게이터)

 - 수립된 테스트 전략과 방형, 계획 및 테스트 리더의 지침에 따라 테스트 명세(설계)를 구현하고 실행하는 역할 수행

   >> 테스트 계획을 검토하고 테스트 계획을 이행

   >> 사용자 요구사항, 명세, 모델 등을 분석하여 테스트 용이성을 평가

   >> 테스트 명세를 작성

   >> 필요시 시스템 또는 네트워크 관리 조직과 협의하여 테스트 환경 구축

   >> 테스트 데이터를 준비하고 수집

   >> 모든 테스트 레벨에서 테스트를 구현하고, 테스트를 실행하고 기록하며, 실행 결과를 분석하여 기대 결과와의 차이를 문서화.

   >> 필요시 테스트 운영 및 관리 도구, 테스트 모니터링 도구를 사용.

   >> 테스트를 자동화(개발자나 테스트 자동화 전문가로부터 지원받음)

   >> 컴포넌트나 시스템의 성능을 측정(성능 측정 결과가 필요한 경우)

   >> 동료가 작성한 테스트를 리뷰

5.2.1 테스트 계획

▶ 테스트 계획

 - 테스팅 목적, 테스트 범위, 필요한 자원 그리고 일정을 결정하는 등의 업무를 수행하는 활동

 - 조직 차원의 테스트 정책 및 전략, 테스트 범위, 목적, 제품의 리스크, 프로젝트 리스크, 제약사항, 심각성, 테스트 용이성 그리고 자원의 가용성에 영향을 받음

 - 테스트 생명주기 전반에 관여하는 지속적인 작업

- 테스트 목적/ 목표 설정 및 대상 연구
- 테스트 전략 개발 : 리스크 분석, 전략 수립
- 테스트 종료 조건
- 테스트 추정
- 조직 구성
- 테스트 계획
- 테스트 관리 및 제어
- 모니터링(리포팅) : 리포팅 계획 / 설계, 진행 리포팅 

 - 여러 레벨의 테스팅 또는 비기능 테스팅 등을 총괄적으로 지휘하고 조율하며 통제하는 목적을 가짐.

▶ 레벨 테스트 계획

 - 마스터 테스트 계획 (인수 테스트, 시스템 테스트, 통합 테스트, 단위 테스트, 이식성 테스트, 성능 테스트, 사용성 테스트, 보안 테스트)

 - 각 테스트 레벨에서 수행할 테스트 활동을 기술(마스터 테스트 계획의 내용을 상세하게 기술, 테스트 레벨의 계획서를 별도로 작성)

 - 마스터 테스트 계획에서 다루지 않는 세부 스케줄, 업무, 마일스톤 등을 작성.

 - 각 테스트 레벨에서의 테스트 세부사항은 각각의 레벨 테스트 계획에서 다룸.

 - 비공식적인 프로젝트나 운영환경에서는 주로 하나의 테스트 레벨만 운용하며 이러한 경우 하나의 테스트 계획 문서에 레벨 테스트 계획과 마스터 테스트 계획 내용이 모두 다루어짐. 

5.2.2 테스트 계획 활동 내용

▶ 테스트 계획의 주요 활동

 - 테스트를 성공적으로 수행하기 위한 전략을 수립하는 것과 소프트웨어 생명주기 단계별로 적합한 테스팅 관련 작업들을 결정하고, 테스트 대상, 범위 그리고 전략에 기반한 투입자원 및 일정을 계획하는 활동을 포함.

   >> 테스트 범위와 리스크, 테스팅의 목적을 식별 및 결정

   >> 테스트 접근법 정의(테스트 레벨, 테스트 시작/ 종료 조건)

   >> 테스트에 필요한 리소스의 결정(인원, 테스트 환경, PC 등)

   >> 테스트 분석과 설계 작업의 스케줄링

   >> 테스트 구현, 실행 및 평가의 스케쥴링

   >> SW 개발주기(계획)에 테스트 활동 통합(구매, 공급, 개발, 운영, 유지보수)

   >> 테스트 업무와 역할, 테스트 대상, 테스트 업무 종료 방법, 테스트 결과 평가 방법 등 결정

   >> 테스트 문서의 분량, 상세 정도, 문서 구조와 템플릿 정의

   >> 테스트 준비와 실행, 결함 해결과 발생 등의 프로젝트 리스크에 대한 모니터링과 제어에 필요한 메트릭(평가방법 표) 결정

   >> 원활한 테스트 준비와 실행을 위해 테스트 프로시저(절차) 상세 수준을 결정

5.2.3 완료 조건

 - 테스트 시작 기준 : 테스트 수행 시작 시점과 테스트 수행 준비 조건을 정의

 - 테스트 종료 기준: 테스팅 종료 시점과 테스트 수행 목표 달성 조건 정의

 - 리스크 레벨(수준) 별로 테스트 종료 기준 수립

 - 각 테스트 레벨 별로 종료 기준 수립

5.2.4 테스트 추정

▶ 테스트 추정

 - 테스트 노력을 산정

 - 테스트 매니지먼트의 일환으로, 테스트 프로세스에 관여하는 모든 작업들에 대한 비용, 노력, 기간을 결정.

▶ 기능 정수 TPA

 - 기능 점수 : 개발에 어려움 정도를 반영 ( 라인수, 비용 사정에 사용 )

 - TPA(Test Point Analysis): 테스트의 어려움 분석( 어려움을 분석하여 테스트의 노력을 체계적으로 산정 )

5.2.5 테스트 접근법, 전략

▶ 테스트 접근법 또는 전략

 - 테스트 레벨, 유형, 사람, 도구, 절차, 방법, 자원 등 테스트 필요 요소들에 대한 접근 방법을 타당한 근거를 기반으로 결정.

 - 방법 : 

   >> 예방적 접근법 : 가능한 프로젝트 초반에 즉, 개발이 완료되기 전에 테스트를 설계

   >> 사후 접근법 : 소프트웨어 또는 시스템이 개발된 이후에 테스트를 설계

4.6 소프트웨어 특성에 따른 테스팅

▶ ISO/ IEC 9126 품질 모델의 품질 특성 기준

 - 특성 테스팅(6가지 테스팅 - 기능성 >> 기능적인 테스팅, 나머지 5개 >> 비기능적인 테스팅)

   >> 기능성(35%) /신뢰성 (15%)/ 효율성(25%)/ 사용성(10%)/ 이식성(10%)/ 유지보수성(5%)

 - 기능성 

   >> 요구되는 기능 및 성능을 만족시키는 능력(수치 데이터).

   >> 제품에 대한 기술 문서인 제품 기능 정의서와 사용자 요구 문서 등에 언급된 모든 기능을 테스트 케이스로 작성 --> 기능 하나하나에 대해 작성.

   >> 기능성에 해당하는 품질 부특성.(이런 게 있나 보다 정도로 알고 있으면 돼)

- 신뢰성

   >> 규정된 시스템 환경에서 결함 없이 의도한 기능 및 작업을 수행하는 소프트웨어의 능력.

   >> 여러 상황의 조합 또는 예외 상황의 처리 능력을 확인하는 절차를 테스트 케이스로 작성

   >> 신뢰성에 해당하는 품질 부특성

 - 사용성

   >> 사용자가 이해하고 배우기 쉬운 정도를 의미

   >> UI나 어떤 기능을 실행하기 위한 순서, 내용 및 처리 메시지가 적절한지 등을 확인하기 위한 테스트 케이스 작성.

   >> 사용성에 해당하는 품질 부특성

 - 효율성

   >> 자원의 적절한 사용 및 적정한 반응시간 정도로 정의

   >> 어떤 기능을 수행하거나 정보를 출력할 때 처리 시간과 자원 사용량이 적절한지를 확인하는 내용을 테스트 케이스로 작성.

   >> 효율성에 해당하는 품질 부특성

 - 유지보수성

   >> 소프트웨어의 수정 및 변경의 용이성

   >> 소프트웨어상에서 변경이 발생하거나 기존의 시스템을 다른 시스템으로 교체하는 경우에 작업 절차가 용이한지에 대해 확인하는 과정을 테스트 케이스로 작성

   >> 유지보수성에 해당하는 품질 부특성

-이식성

   >> 지원하는 다양한 운영환경에서 운영될 수 있는 소프트웨어의 능력

   >> 지원하는 모든 시스템 환경에서 제품이 정상적으로 실행되는지 확인하는 과정과 해당 운영 환경에서 실행되고 있는 다른 프로그램과의 호환성에 대한 내용을 테스트 케이스로 작성

   >> 이식성에 해당하는 품질 부특성

** 테스트 종류에 대한 용어 정리

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

 - 분할 

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

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

 - 포함

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

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

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

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

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

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

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

 - 일반적인 유용성

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

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

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

4.4.3.2 체크리스트

▶ 체크리스트

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

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

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

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

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

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

 - 시스템 요소 체크리스트

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

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

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

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

 - 체크 리스트

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

   >> 효과성은 없음.

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

 - 테스트 케이스

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

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

4.5 테스트 기법의 선택

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

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

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

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

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

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

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

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

유튜브 김기태의 java를 자바의 sw 테스팅을 보면서 공부를 하고 있는데 아무래도 예전 강의라 그런지 실라버스에 있는 내용과 약간씩 달라지는 내용이 있는 것 같다. 올라와 있는 강의를 다 보고 최신 버전으로 나온 실라버스로 다시 정리를 하면서 공부를 해야겠다. 그래도 이쪽 공부를 새롭게 하다 보니 점점 재밌어지고 있어서 나름 만족감과 즐거움을 느끼고 있다.

4.4.1.2 명세기반 기법 - 페어와이즈 조합 테스팅

▶ 페어와이즈 조합 테스팅

 - 페어와이즈 관찰 결과 대부분의 결함이 2개 요소의 상호 작용에 기인하여 나타남.

 - 페어와이즈는 테스트 하는데 필요한 각 값들이 다른 파라미터의 값과 최소한 한 번씩은 조합을 이루게 된다는 것.

 - 3개의 파라미터가 각 5,4,5가지 값을 가질 때 100가지에서 만약 테스트를 100가지 경로로 하게 되면 10000개의 테스트를 실행해야 함 --> 조합을 최소화 함.

* 동작 모드와 설정 파라미터의 각 값들을 중복되지 않게 배열하고, 이퀄라이저의 값을 동작모드와 설정 값과 순차적으로 중복되지 않게 배정하기.

4.4.1.3 직교 배열 테스팅 (거의 잘 안 써서 이런 게 있다 정도로만 알아두면 돼)

▶ 직교 배열 테스팅

 - 6-시그마 기법에 이용되고 있으며 소프트웨어 테스트에 적용하여 사용되고 있음.

(6-시그마 : 프로세스의 품질을 개선하기 위한 방법. 결함을 최소화하고 효율성을 높이기 위해 사용되는 통계적인 기법)

 - 직교 배열의 원리를 소프트웨어 테스트에 적용하여 조합의 수를 줄임으로써 테스트 케이스의 수를 합리적으로 줄임.

 - 직교 배열에서 열과 행이 페어와이즈 하다는 것은 직교 배열의 각 행과 열의 조합이 서로 다르다는 것을 의미함.

 - L4(2^3) 

궁금해서 찾아본 < L(런 수)(수준 수 ^ 요인 수) 표기 >
 - L(런 수) = 런 수 = 조합수(라인수) == 배열의 행 수. 즉 생성될 테스트 사례 수
 - (수준 수 ^ 요인 수) = 각 요인의 수준 수 ^ 요인 수
런수 : 조합수(라인수).
요인 : 처리할 수 있는 최대 변수 수로 변환되는 배열의 열 수. (파라미터)
수준 : 단일 요인에 사용할 수 있는 최대 값 수. (값)
ex) L8 설계에는 런이 8개 있음. (2^3) 또는 (2 3)은 수준이 2개인 요인이 3개 있음을 나타냄.
L(런 수)(숫자 ^ 지수 개수 ^ 지수) 형태의 표기인 경우 혼합 수준 설계를 나타낸다.
L18(2^1 3^7)은 설계에 런 18개와 수준이 2개인 요인 하나와 수준이 3개씩인 요인 7개가 있음을 나타낸다.

*참고 자료 - 직교 배열 테스트란 무엇인가.
https://www.guru99.com/ko/orthogonal-array-testing.html

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. 테스트 케이스 개수와 트리의 복잡도를 근거로 테스트 비용을 추정하는 것이 가능함.

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)

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

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

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

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

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

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

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

4.3.1.4 상태 전이 테스팅

▶ 상태 전이 테스팅 (state trasition)

 - 이벤트, 액션, 상태, 가드, 상태전이 사이의 관계를 검증.

 - 시스템/SW의 상태 기반 행위가 명세화(글자로 쓰여있던)된 내용과 일치함을 검증.

 - 상태기반 시스템의 결함은 상태, 상태전이, 가드, 이벤트 결함 등으로 분류.

 - "구현이 잘못된 경우"와 "명세가 잘못된 경우"의 결함으로 구분.

 - 모델(명세)상의 결함 -- > 인스펙션, 정적 분석으로 결함 발견.

   >> 초기 상태 누락

   >> 전이 또는 액션의 누락

   >> 가드를 "전이" 대신 상태에 표기

   >> 가드의 중복 또는 불일치

 - 구현상의 결함 -- > 테스트를 통해 결함 발견

   >> 여분/ 누락/ 훼손 상태(extra/ missing/ corrupt state)

   >> 액션이 틀리거나 누락됨

   >> 스니크 패스(sneak paths), 트랩 도어(trap doors)

      - 설계할 때 의도하지 않았으나 발생하여 정상적인 작동에 손상을 주는 경로.

• 상태 다이어그램 표기법

• 상태: [대기], [금액 투입], [음료 선택]
• [대기] 이벤트 : ev 금액투입[투입금액 < 가격], ev 금액투입[투입금액 >= 가격]
• [금액 투입] 이벤트 : ev 취소, ev 금액투입[투입금액 >= 가격], ev 금액투입[투입금액 < 가격]
• [음료 선택] 이벤트 : ev 취소, ev 음료버튼 선택

▶ 상태전이 테스트 케이스 절차

1. 상태-이벤트 테이블 구성
2. 전이 트리 구성
3. 반응(Legal, 또는 유효(Valid)) 테스트 케이스 구성
4. 무반응(Illegal, 또는 비유효(Invalid)) 테스트 케이스 구성
5. 가드(Guard) 또는 조건 테스트 케이스 구성
6. 테스트 프로시저(Test procedure) 구성

자판기로 상태전이 테스트 케이스를 알아보자.

1. 상태-이벤트 테이블

* 동일한 이벤트지만 가드가 다르면, 서로 다른 이벤트로 구분해 상태-이벤트 테이블을 작성한다.

2. 전이 트리 구성

3. 반응(유효) 테스트 케이스

* 음료가격 700원으로 가정

4. 무반응(비유효) 테스트 케이스

불가능한 상황들을 만들어서 테스트를 해보는 것.

5. 가드 테스트 케이스

* 음료가격 700원으로 가정 / 조건에 따라 기대결과가 달라짐.

6. 테스트 프로시저 구성  ( *가능한 겹치지 않으면서 내가 할 수 있는 모든 테스트 케이스를 만들어야 돼. )

• TP1 = V001 -> IV001 -> IV002 -> V002 -> V003 -> V006 -> V007 -> V010
• TP2 = V004 -> IV003 -> V011 -> V005
• TP3 = V008 -> V009 -> V013 -> V016 -> V012
• TP4 = V014 -> V004 -> G001 -> G002
• TP5 = V015 -> IV004 -> IV005

슬슬 한번씩 더 읽어봐야 이해가 되는 부분이 왔다. 그래도 꽤 재밌구만!!

4.1 테스트 설계 및 구현 프로세스

▶ 테스트 설계의 진행 방식
 - 테스트 조직 구성
 - 테스팅과 개발 프로세스의 성숙도
 - 시간 절약
 - 참여인원 등 테스트 정황에 따라 달라짐
▶ 무엇을 테스트할지 결정하기 위해 테스트 베이시스 문서 분석
 - 테스트 베이시스 - 요구사항 명세서, 개발 설계서 등
▶ 테스트 조건
 - 기능, 트랜잭션, 품질 특성 또는 구조적 요소
▶ 테스트 설계 과정
 - 테스트 설계 기법을 이용하여 테스트 케이스와 테스트 데이터를 설계하고 명세화 함
▶ 테스트 케이스
 - 입력 값의 묶음
 - 실행 사전 조건
 - 기대 결과와 실행 사후 조건으로 구성
▶ 테스트 표준 문서
 - 소프트웨어 테스트 문서 표준(IEEE 829)
 - 테스트 설계 명세와 테스트 케이스의 표준 양식 제안
▶ 테스트 용이성 평가

 
▶ 테스트 분석, 설계, 구현

▶ 테스트 케이스
 - 정의
   >> 특정 프로그램 경로의 실행, 구체적인 요구사항과의 일치 여부 확인을 위해 디자인된 입력 값의 묶음.
   >> 실행 사전 조건, 기대 결과와 실행 사후 조건의 집합
   >> 테스트 돼야 하는 Test Condition((상황)을 입력 값과 기대결과로 표현
 - 작성 목적
   >> 요구되는 보장성을 갖는 최소개의(최적의) 테스트 케이스로 가능한 많은 결함을 발견할 수 있도록 정의한 목표 수준의 테스트 보장성 확보

< 테스트 케이스의 목적 >
1. 최소한의 테스트 케이스로 많은 결함을 발견하는 것.
2. 테스트 대상을 가능한 빠짐없이 테스트하여 테스트 보장성을 확보할 수 있도록 설계되어야 함.
3. 공식적 기법과 경험 기반의 비공식적 기법을 모두 이용해야 함.
 - 공식적 기법을 먼저 작성한 후에 비공식적인 기법으로 보완이 필요함.

 
  - 예시 테스트 케이스                                                                                                            결과값, 데이터나 상태 변화

▶ 테스트 케이스 개발 및 작성
 >> 테스트 케이스 개발 시 우선순위 선정 - 테스트 프로시져 명세서(테스트 케이스의 실행 순서) 만듦 - 테스트 실행 스케쥴 작성(테스트 실행도구를 사용하여 테스트를 수행하면 테스트 프로시저는 테스트 스크립트로 기술할 수 있음)
▶ 테스트 수행 절차
 >> 얼마나 상세하게 작성하는 것이 좋을 지 작성해야 함 - 테스터의 스킬, 능력, 해당시스템에 대한 이해를 고려하여 테스트 케이스의 상세함을 조절해야 함.
 >> 만약 외주를 주는 경우는 자주 테스터가 바뀌더라도 작업을 수행할 수 있도록 상세하게 수행 절차를 기록하여야 함.
▶ 테스트 케이스 작성
 >> 테스트 수행 절차를 얼마나 상세하게 작성하는 것이 적절한 지 결정해 주어야 함(테스트 케이스당 7스탭이내로 수행 절차를 작성하는 것이 바람직)
 >> 7스텝이 넘을 경우는 두 개로 분리하여 관리하는 것이 좋음

4.2 테스트 설계 기법의 종류

▶ 블랙박스 기법 VS. 화이트박스 기법

 
▶ 테스트 설계의 근원(Origin)을 기준
 - 명세 기반 기법, 구조 기반 기법, 경험 기반 기법으로 분류

명세가 나오면 블랙박스, 구조가 나오면 화이트박스

4.3.1 명세 기반 기법(Specification - based)

▶ 명세 기반 기법

 - 종류 : 동등 분할, 경계값 분석, 조합 테스팅, 결정 테이블 테스팅, 상태전이 테스팅, 유즈케이스 테스팅.

4.3.1.1 동등 분할

▶ 동등 분할
 - 입력 / 출력값 영역을 유한개의 상호 독립적인 집합으로 나누어 수학적인 등가 집합을 만든 후, 각 등가 집합의 원소 중 대표값을 선택하여 테스트 케이스를 도출하는 방법.
 - 동일한 입력에 대해 항상 동일한 결과를 갖도록 클래스 구분
 - 적용 방법
   >> 주어진 시스템 정보를 분석해 입력/ 출력 영역을 유사한 특징을 가진 클래스로 분할
   >> 분할된 클래스에서 각 클래스를 대표하는 테스트 케이스 도출
   >> 모든 Valid equivalence class(유효)가 커버될 때까지 테스트 케이스 생성
   >> 모든 Invalid equivalence class가 커버될 때까지 테스트 케이스 생성

4.3.1.2 경계값 분석

▶ 경계값 분석
 - 동등 분할의 경계에서 결함이 발견될 확률이 높기 때문에 결함을 예방하기 위해 경계값까지 포함하여 테스트
 - 분할 영역의 최대값과 최소값이 그 영역의 경계값
 - 동등 분할과 마찬가지로 모든 테스트 레벨, 테스트 유형에 적용
 - 동등 분할의 확장으로 여겨지며 동일한 방식으로 커버리지 보장

4.3.1.3 결정 테이블 테스팅

▶ 결정 테이블
 - 시스템의 동작을 결정하는 비즈니스 규칙을 정의하는 방법
 - 입력 값들이 논리적인 관계(Binary Condition - 참과 거짓)를 갖는 경우, 입력 값을 원인 / 결과로 나누어 기술
    -- > 테스트 케이스 작성
 - 구현이나 명세에 잠재된 오류를 찾는 데 효과적으로 이용
▶ 특징
 - 테이블 분석을 통해 중복, 발생 불가능한 상황, 모순이 생기는 상황을 제외시키고 나머지의 결정과 액션 조합
 - 좋은 테스트 데이터 선택을 위해, 경계 값 또는 동등 분할 기법 사용
 - 불가능한 Rule을 식별하는 것은 테스트 설계 단계에서 나올 수도, 나오지 않을 수도 있음 -- > 시스템 설계에 의존적.
▶ 결정 테이블 장단점