노년코딩

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을 식별하는 것은 테스트 설계 단계에서 나올 수도, 나오지 않을 수도 있음 -- > 시스템 설계에 의존적.
▶ 결정 테이블 장단점

3.1.1 리뷰의 이점과 목적

▶ 정적기법
 - SW를 실행하지 않고 테스팅 하는 기법
 - 동적 테스팅과 달리 장애보다는 장애의 원인(결함)을 발견
▶ 리뷰
 - 코드를 포함하여 SW개발 및 테스트 산출물을 검토하고 테스팅 하는 방법.
 - 동적 테스팅 전에 수행 --> 초기 결함의 수정은 비용 절감
 - 대상
   >> 요구사항 명세, 설계 명세, 코드, 테스트 계획, 테스트 명세, 테스트 케이스, 테스트 스크립트, 사용자 가이드, 웹페이지 등 모든 SW개발 및 테스트 산출물.
- 리뷰의 이점
   >> 조기 결함 발견 및 수정
   >> 개발 생산성 향상
   >> 개발 기간 단축
   >> 테스팅 비용 감소 및 시간 단축
   >> 개발 생명 주기 전체에 걸친 비용 감소
   >> 결함 감소(품질 향상)
   >> 커뮤니케이션 향상
 - 리뷰를 통해 발견하기 쉬운 결함
   >> 표준 위반, 요구사항 결함, 개발 설계 결함, 불충분한 유지보수성, 부정확한 인터페이스 명세.
 

3.1.2 리뷰와 테스팅

▶ 최근 테스팅
 - 결함 예방 활동 강조
 - 조기 테스트 설계 -- > 초기에 결함을 줄임
   >> 시스템 명세(요구사항 문서, 설계 기준서)에 대한 테스트 케이스 생성
   >> 요구사항 분석서를 통한 테스트 케이스 -- > 시스템 또는 인수 테스팅에 사용
 - 프로젝트 초기 모든 테스트 케이스 생성은 부적절
 - BUT, 리스크가 높거나 중요한 기능에 한해 테스트 케이스를 도출 하면서 문서를 테스트 -- > 조기 발현 중요.
 

3.2 리뷰 프로세스

▶ 리뷰 목적
 - 결함 발견, 이해도 증진, 합의에 의한 결정과 이를 위한 토론
 - 체계적인 리뷰를 통해 고품질 SW 개발과 비용 절감은 물론 개발 기간 단축의 효과
 - 페이건 스펙션
   >> 초기에 많은 인력, 코딩 단계 부터 인력이 줄게 됨, 품질 비용이 감소하고 개발 기간 단축.
 

3.2.1 공식적 리뷰의 단계

▶ 정적 테스트 활동의 중요성이 높아지고 있음
▶ 정적 테스트 프로세스
 - 정적 테스트 준비 단계
 - 리뷰 / 분석 단계
 - 후속 처리 확인 단계
   >> 비공식적인 리뷰도 일반적인 프로세스를 준수하는 것이 좋음
▶ 공식적 리뷰의 절차
 - 계획 활동 -- > 시작 -- > 개별 준비 -- > 리뷰 미팅 -- > 재작업 -- > 후속 처리 확인

3.2.2 역할과 책임

▶ 역할과 책임
 - 관리자(Manager)
   >>리뷰 진행 결정, 프로젝트 일정에 리뷰 시간 할당, 리뷰의 목적 달성 여부 확인하고 승인
 - 중재자(Moderator)
   >> 리뷰 회의 리드(리뷰 계획, 미팅 진행, 미팅 후속 조치 추적 관리 등)
   >> 다양한 관점을 중재하는 자로 리뷰의 성패를 좌우
 - 저자(Author)
   >> 리뷰 대상 문서(산출물)의 작성자 또는 책임자
 - 검토자(Reviewer) - 테스트 전문가 참여
   >> 리뷰 대상 제품에서 인시턴트를 발견하고 기술할 사람(검사자 또는 인스펙터) - 기술적 또는 비즈니스 배경을 갖춘자
   >> 리뷰어는 다양한 관점과 역할을 대표하도록 선택되어야 함
 - 기록자(Scribe or recorder)
   >> 리뷰 미팅에서 발견된 모든 이슈, 문제점, 미해결점 등을 기록하고 문서화함
▶ 체크리스트 활용
 - 효과적 /효율적인 리뷰를 위해 사용자, 유지보수 담당자, 테스터, 시스템 운영자 등 다양한 관점의 체크리스트 또는 문서 유형별 체크리스트 이용 및 개발 권고
▶ 테스트 케이스 -- > 시간과 노력 많이 필요
 - 변경된 요구사항과 설계 반영을 위해 지속적으로 업데이트 필요  (초반에 다 만들지 않아. 계속해서 업데이트)
 

3.2.3 리뷰의 유형

▶ 리뷰에 리스크 분석을 연계한 사례

 
▶ 워크쓰루(Walkthrough) -- > 이해 향상과 결함 발견
 - 저자(Author: 산출물 작성자)에 의한 진행 및 제어
 - 성격 : 시나리오 사용, 예행 연습(Dry runs), 동료 그룹 검토
 - 시간 및 인원수 등에 제한이 없고 상황에 따라 변경할 수 있는(Open - ended) 세션
 - (선택적) 미팅 전 준비 과정 거침 -- > 역할 지정(검토자, 기록자 등), 리뷰 리포트 준비, 인시던트(조사가 요구되는 이벤트) 목록 준비
 - 실무에서는 비공식적 또는 공식적일 수 있음.
 - 주요 목적 : 학습, 시스템에 대한 이해 향상, 결함 발
▶ 인스펙션(Inspection) --> 결함 발견
 - 저자가 아닌 중재자가 주도적으로 진행 및 제어
 - 주로 동료 검사
 - 역할이 정의되어 있음
 - 메트릭(측정 척도와 방법)을 수집하고 활용함
 - 체크리스트와 규칙을 기반으로 시작과 종료 조건이 있는 정식 프로세스 존재
 - 미팅 전 준비 과정 필요
 - 인스펙션 리포트와 발견 사항(인시턴트(조사가 요구되는 이벤트)) 리스트 산출
 - 정식적인 후속 처리 확인(Follow -up) 프로세스 존재
 - (선택적) 리뷰 프로세스 개선 활동 수행
▶ 인스펙션 대상
 - 모든 개발 산출물과 테스트 산출물
 - 리스크 분석 결과를 활용하여 장애 발생 가능성이 높고 발생한 장애로 인한 영향이 심각할 수 있는 부분을 중심으로 진행
   >> 비즈니스와 연관성이 높거나, 복잡도, 변경율, 결함률이 높은 부분이 이에 해당.
 - 리스크 기반 테스트 전략 -- > 리뷰 강도 조절
▶ 워크쓰루 vs. 인스펙션 
 - 사업적 리스크가 높은 영역 - 워크쓰루
 - 기술적 리스크가 높은 영역 - 인스펙션이나 기술적 리뷰
 

3.2.4 리뷰의 성공 요소

3.3 도구에 의한 정적 분석

- 정적 분석 특징
   >> 정적 분석은 동적 테스팅으로 찾기 힘든 결함을 발견
   >> 리뷰와 마찬가지로 정적분석은 장애보다는 결함을 발견함 > 코드를 돌리기 전에 문제점을 찾아내자!!
   >> 도구의 도움을 받아 수행
   >> 정적 분석 도구는 프로그램 코드를 분석하는 것은 물론, HTML이나 XML과 같이 생성된 결과물도 분석
 - 정적 분석의 가치
   >> 테스트 실행 전 조기 결함 발견
   >> 의심스러운 코드와 설계에 대한 조기 경보(프로그램 복잡도- 메트릭)
   >> 동적 테스팅으로 발견하기 어려운 결함 발견
   >> SW 모델상의 의존도와 불일치성 발견
   >> 코드와 설계의 유지보수성 향상
   >> 결함 예방 가능
 - 정적 분석을 통해 발견될 수 있는 결함
   >> 정의되지 않은 값으로 변수 참조
   >> 모듈과 컴포넌트 간의 일관되지 않은 인터페이스
   >> 사용되지 않는 변수
   >> 사용되지 않는 코드
   >> 코딩 표준 위반
   >> 보안 취약성
   >> 코드와 소프트웨어 모델의 구문 규칙 위반
 - 정적 분석 도구
   >> 기 정의된 규칙이나 코딩표준을 준수하는지 확인하는 용도로 컴포넌트 테스팅과 통합 테스팅 동안에 주로 개발자에 의해 사용.
   >> SW 모델링하는 동안 설계자에 의해 사용.