노년코딩

들어가기 전 알아둬야 할 4.4 용어 설명, 4.5 용어 설명
: 이해에 중점. 부족하면 용어설명 글 참고.

체크리스트 기반 리뷰 : 질문 목록이나 확인해야 하는 특성을 기반으로 수행하는 리뷰 기법.
체크리스트 기반 테스팅 : 경험, 점검, 기억에 의한 목록 또는 제품 검증 기준 맟 규칙을 상위 수준으로 나열한 목록을 숙련된 테스터가 사용하는 경험 기반 테스트 기법.

사용자 스토리 : 일상 또는 비즈니스 언어로 사용자가 필요로 하는 기능, 그것의 이유, 비기능 조건, 인구 조건 등을 포착하는 한 문장으로 구성된 사용자 또는 비즈니스 요구사항.

인수 조건 : 사용자, 고객, 기타 권한을 지닌 사람이 제품을 인수하기 위해 컴포넌트나 시스템이 만족시켜야 하는 기준.
시나리오 기반 리뷰 : 특정 시나리오를 처리할 수 있는 능력을 판단하기 위해 작업 산출물을 평가하는 리뷰 기법.
인수 테스트 주도 개발 : 팀과 고객이 고객 고유의 도메인 언어를 사용하여 컴포넌트 또는 시스템을 테스트하기 위한 베이시스를 형성하는 고객 요구사항을 이해하는 개발에 대한 협업적 접근 방식.

4.4 경험 기반 테스트 기법 
: 널리 사용하는 경험 기반 테스트 기법 3가지

• 오류 추정
• 탐색적 테스팅
• 체크리스트 기반 테스팅

4.4.1 오류 추정

< 오류 추정 >
: 테스터의 지식을 기본으로 오류, 결함, 발생을 예측하는 데 사용하는 기법.

>> 테스터의 지식
- 애플리케이션의 과거 동작.
- 개발자가 범하기 쉬운 오류 유형과 이런 오류로 인해 발생하는 결함 유형.
- 다른 유사 애플리케이션에서 발생한 장애 유형.

일반적으로 오류, 결함, 장애는 입력, 출력, 논리, 계산, 인터페이스, 데이터와 관련이 있을 수 있다.

결함 공격 - 오류 추정을 구현하는 체계적인 접근법.
: 테스터가 발생 가능한 오류, 결함, 장애 목록을 만들거나 획득해서 오류와 관련된 결함을 식별 및 노출하거나, 장애를 유발하는 테스트를 설계하도록 한다.
ex. 목록 : 올바른 입력 허용 X, 잘못된 입력 허용 O. 출력형식 올바르지 않음. / 테스터가 이 목록으로 테스팅하는 경우 결함 공격 테스트 기법 사용.

4.4.2 탐색적 테스팅
: 테스터가 가지고 있는 경험, 지식, 그리고 호기심, 창의성들이 높으면 테스팅이 효과적!

< 탐색적 테스팅 >
- 테스터가 테스트 대상에 대해 배워가면서 테스트의 설계, 실행, 평가를 동시에 하게 된다.
- 테스트 대상에 대해 더 배우고, 집중하고 있는 테스트는 더 깊이 탐색하고, 테스트되지 않은 영역에 대한 테스트를 만들기 위해 사용.
- 테스트를 체계적으로 수행하기 위해 세션 기반 테스팅을 사용하기도 함.

▶ 탐색적 테스팅은
- 명세가 부족하거나 부적합할 경우, 테스트에 시간적 압박이 심할 때 유용!
- 다른 공식 테스트 기법을 보완하기에도 유용!
- 테스터가 풍부한 경험과 도메인 지식을 가지고 있고 높은 수준의 분석 기술, 호기심, 창의성 등 필요 기술을 갖춘 경우 더욱 효과적일 수 있다.

4.4.3 체크리스트 기반 테스팅
: 자동화 항목은 포함하면 x

< 체크리스트 기반 테스팅 >
- 테스터는 체크리스트를 활용해 테스트 컨디션을 확인하는 테스트를 설계, 구현, 실행한다.
- 자동으로 점검할 수 있는 항목, 시작/ 종료 조건으로 더 적합한 항목, 너무 일반적인 항목은 체크리스트에 포함해서는 안된다.
- 체크리스트 항목을 질문 형식으로 표현하는 경우가 많음. 각 항목은 개별적이면서 직접적으로 확인할 수 있어야 한다. 이런 항목은 요구사항, 그래픽 인터페이스 속성, 품질 특성 또는 기타 유형의 테스트 컨디션일 수 있다.
- 시간이 지남에 따라 개발자가 같은 오류를 범하지 않게 됨으로 일부 체크리스트 항목은 점차 효과가 떨어질 수 있음. 결함 분석을 기반으로 정기적으로 업데이트 해야 함!!
- 구체적인 테스트 케이스가 없는 경우에 체크리스트 기반 테스팅은 일관성을 제공할 수 있다.
- 체크리스트가 상위 수준으로 작성된 경우 실제 테스트는 조금씩 달라질 수 있으며, 결국 커버리지는 높아지지만 재현 가능성은 떨어질 수 있다.

4.5 협업 기반 테스트 접근법
: 협업과 커뮤니케이션을 통한 결함 예방에 초점.

4.5.1 협업 기반 사용자 스토리 작성

• 사용자 스토리는 시스템이나 소프트웨어의 사용자 또는 구매자에게 가치를 제공하는 기능을 나타낸다.

• 협업 기반 사용자 스토리 작성은 브레인스토밍, 마인드 매핑과 같은 기법을 사용. 협업을 통해 팀원들은 비즈니스, 개발, 테스팅의 세 가지 관점을 고려해 만들어서 전달할 것에 대한 공유된 비전을 얻을 수 있다.
• 좋은 사용자 스토리는 독립적이고 협상가능하고, 가치 있고, 추정 가능하고, 테스트 가능해야 한다.

4.5.2 인수 조건

사용자 스토리의 인수 조건은 사용자 스토리 구현 결과를 이해관계자가 승인하기 위해 충족되어야 하는 조건.
이런 관점에서 인수 조건을 테스트해야 하는 테스트 컨디션으로 볼 수 있다.

인수 조건은 보통 3C중 대화를 통해 결정된다.
인수 조건은 다음을 위해 사용된다.
1. 사용자 스토리 범위 정의.
2. 이해관계자 간 합의 도출.
3. 긍정과 부정 시나리오 설명.
4. 사용자 스토리 인수 테스팅의 베이시스 제공.
5. 정확한 계획 및 추정.

인수 조건 작성법 두가지
시나리오 기반	행위 주도 개발에서 사용하는 Given/ When/ Then.
규칙 기반	베리피케이션이 필요한 목록 또는 표로 표현된 입력-출력 매핑.

- 대부분의 인수조건은 이 두 가지 형식 중 하나로 문서화할 수 있다.

4.5.3 인수 테스트 주도 개발(ATTD)
: 테스트 우선 접근법.

테스트 케이스는 사용자 스토리 구현 전에 만들어진다. 고객, 개발자, 테스터 등 서로 다른 관점을 가진 팀원들이 테스트 케이스를 만든다.

첫 번째 단계 : 명세 워크숍으로 팀원들은 여기서 사용자 스토리와 인수조건을 분석하고 토론해서 작성. 이 과정에서 사용자 스토리의 불완전성, 모호성, 결함을 해결하게 된다.
두 번째 단계 : 테스트 케이스를 만드는 것. 이 작업은 팀 전체가 수행하거나 테스터가 개별적으로 수행할 수 있다. 테스트 케이스는 인수 조건을 기반으로 하며, 소프트웨어가 어떻게 작동하는지에 대한 예제로 볼 수 있다. 이는 팀이 사용자 스토리를 올바르게 구현하는데 도움을 준다.

일반적으로 첫 번째 테스트 케이스는 예외나 오류 조건 없이 올바른 동작을 확인하고 모든 것이 예상대로 진행될 경우 실행되는 일련의 활동으로 구성된 긍정/유효 테스트 케이스이다.
유효 테스트 케이스를 끝내고 나면 팀은 비유효/부정 테스트를 수행해야 한다.
마지막으로 팀은 비기능 품질 특성도 다뤄야 한다. 테스트 케이스는 이해관계자가 이해할 수 있는 방식으로 표현되어야 하며, 일반적으로 테스트 케이스는 필요한 전제 조건, 입력값, 사후 조건을 포함하며 자연어 문장으로 구성한다.
테스트 케이스는 사용자 스토리의 모든 특성을 다뤄야 하며 스토리를 벗어나면 안 된다. 또한 두 개 이상의 테스트 케이스가 사용자 스토리의 같은 특성을 설명해서는 안된다.
테스트 자동화 프레임 워크가 지원하는 형식으로 작성하면 개발자는 사용자 스토리에서 설명하는 기능을 구현할 때 필요한 코드를 작성해 테스트 케이스를 자동화할 수 있다. 그러면 인수 테스트가 실행 가능한 요구사항이 된다.

들어가기 전 알아둬야 할 4.2 용어 설명, 4.3 용어 설명
: 이해에 중점. 부족하면 용어설명 글 참고.

동등분할 테스트 정의 및 원리 :
- 테스트 항목의 입력과 출력이 여러 개의 독립된 영역으로 구분되는 경우에 적용.
- 동일한 영억 내에서는 어떠한 값을 선택해도 결과가 항상 같다는 원리 이용.
- 모든 영역에서 최소 하나 이상의 (대표) 값을 선택해 테스트.
ex> 배터리 용량 테스트, 성적 학점 결과 60점 밑 F, 70점 밑 D,... C, B, A.

경계값 분석 : 2개 선택, 3개 선택이 있음.
- 2 value일 경우 최댓값과 최솟값의 바로 밖(1,10이면 0.9, 1, 10, 10.1).
- 3 value일 경우 최대값과 최소값의 안, 밖(1, 10이면 0.9, 1, 1.1, 9.9, 10, 10.1)

결정 테스트는 모순되는 규칙을 찾을 수 있어야 함.

구문 테스팅 : 테스트 케이스가 구문을 실행하도록 설계하는 화이트박스 테스트 설계 기법.
결정 테스팅 : 테스트 케이스가 결정 결과값을 실행하도록 설계하는 화이트박스 테스트 기법.
* 결정 테이블 테스팅은 블랙박스 설계 기법(테스트 케이스가 결정 테이블에 표시된 조건과 결과 행위 조합을 실행하도록 설계)
다중 조건 테스팅 : 테스트 케이스가 원자 조건의 결과 조합을 실행하도록 설계된 화이트박스 테스트 기법.
조건 테스팅 : 테스트 케이스가 원자 조건의 결과를 실행하도록 설계된 화이트박스 테스트 기법.

분기 테스팅 : 프로그램을 제어 흐름 그래프로 변환했을 때 제어 흐름 그래프의 모든 간선을 최소한 한 번은 실행하는 테스트 케이스가 테스트 케이스 집합에 포함되도록 요구. 분기 커버리지를 만족하면 문장 커버리지를 만족함(반대로는 안돼.) - 모든 간선 실행 시 모든 노드를 실행하기 때문.

슈도 코드(== 의사 코드) : 프로그램을 작성할 때 각 모듈이 작동하는 논리를 표현하기 위한 언어.
개념 : 프로그램 코드를 작성할 때 사용하기 위해, 프로그램의 진행 과정을 단계별로 기록해 놓은 것. 알고리즘이 수행될 내용을 인간의 언어로 간략하게 설명해 놓은 것을 말한다. (pseudo(가짜의, 유사) + code)

4.2 블랙박스 테스트 기법
: 많이 사용되는 블랙박스 테스트 기법 4가지

• 동등 분할
• 경계값 분석
• 결정 테이블 테스팅
• 상태 전이 테스팅

4.2.1 동등 분할

동등 분할 : 
- 테스트 대상이 하나의 분할(== 동등 분할)에 포함된 모든 요소를 동일한 방식으로 처리할 것이라는 가정하에 데이터를 분할 단위로 나눈다.
근거 이론: 동등 분할에 속한 특정 값을 테스트하는 테스트 케이스로 결함을 식별할 수 있다면, 같은 동등 분할의 다른 어떤 값을 테스트하는 테스트 케이스라도 해당 결함을 식별할 수 있어야 한다는 것.
>> 따라서 각 분할에 대해 하나의 테스트만 수행하면 충분하다.
- 입력, 출력, 형상 항목, 내부 값, 시간 관련 값, 인터페이스 매개변수 등 테스트 대상과 관련된 모든 데어터 요소에 대해 식별할 수 있다. 분할은 연속적이거나, 연속적이지 않을 수도 있으며, 정렬돼 있거나, 유한 또는 무한일 수도 있다. 분할은 서로 겹치지 않아야 하며, 값이 없는 공집합일 수는 없다.
- 테스트 대상이 단순하다면 동등 분할을 적용하기가 쉬울 수도 있지만 실제로는 테스트 대상이 다양한 값을 어떻게 처리하는지 이해하기 어려울 때가 많아서 분할 식별은 신중하게 해야 한다.

유효 분할 : 유효한 값을 포함하는 분할.
비유효 분할 : 유효하지 않은 값을 포함하는 분할.
!! 유효한 값과 유효하지 않은 값의 정의는 팀과 조직마다 다를 수 있다. !!
>> 테스트 대상이 처리해야 하는 값 또는 명세에 처리가 정의된 값을 유효값으로 해석가능. 비유효 값은 테스트 대상이 무시하거나 거부해야 하는 값, 또는 테스트 대상 명세에 처리 방법이 정의되어 있지 않은 값으로 해석할 수 있음.

동등 분할에서 커버리지 항목은 각 분할이 된다!
>> 이 기법으로 100% 커버리지를 달성하려면 테스트 케이스로 각 분할을 최소 한 번씩 다뤄서 식별한 모든 분할(비유효 분할 포함)이 실행되도록 해야 함.
>> 커버리지는 하나 이상의 테스트 케이스로 실행한 분할 수를, 식별한 총 분할 수로 나눈 값으로 측정하며 백분율로 표시함.

대부분의 테스트 대상은 여러 분할 집합을 가지고 있기 때문에 하나의 테스트 케이스는 여러 분할 집합에 속한 분할을 다루게 된다. 분할 집합이 다수인 경우 가장 간단한 커버리지 기준을 이치 초이스 커버리지라고 한다.
이치 초이스 커버리지는 테스트 케이스가 모든 분할 집합의 각 분할을 최소 한 번은 실행할 것을 요구하며, 분할의 조합을 고려하지 않는다.

4.2.2 경계값 분석

경계값 분석 : 동등 분할의 경계 실행을 기반으로 하는 기법. 정렬된 분할에만 사용가능. 분할의 최솟값과 최댓값이 경계값이 됨. 경계값 분석에서 두 값이 같은 분할에 속하는 경우, 둘 사이의 모든 값도 해당 분할에 속해야 함.

분할의 경계에 있는 값을 개발자가 다룰 때 오류를 범할 가능성이 높기 때문에 경계값 분석은 분할의 경계에 있는 값에 초점을 두게 됨.
>> 경계값 분석으로 많이 찾는 결함 : 구현된 경계가 의도한 위치보다 위나 아래에 잘못 배치됐거나 아예 누락된 결함.

실러버스에서 다루는 경계값 분석 2가지 유형 - 두 개 선택(2-value), 세 개 선택(3-value) 경계값 분석.
>> 100% 커버리지 달성을 위해 실행해야 하는 경계별 커버리지 항목의 수에서 차이가 남.

두 개 선택 경계값 분석	- 각 경계값에 대해 두 개의 커버리지 항목을 도출. - 경계값과 인접 분할에 속한 가장 가까운 값이 커버리지 항목. - 100% 커버리지를 달성하려면, 테스트 케이스로 모든 커버리지 항목, 즉 식별한 모든 경계값을 실행해야 한다. - 커버리지는 실행한 경계값의 수를 식별한 경계값의 총수로 나눈 값으로 백분율로 표시한다.
세 개 선택 경계값 분석	- 각 경계값에 대해 세 개의 커버리지 항목을 도출. - 경계값과 이웃한 양쪽의 값 모두가 커버리지 항목. >> 세 개 선택 경계값 분석에서는 경계값이 아닌 커버리지 항목도 있을 수 있음. - 100% 커버리지를 달성하려면, 테스트 케이스로 모든 커버리지 항목, 즉 식별한 경계값과 그 이웃 값을 실행해야 한다. - 커버리지는 실행한 경계값과 이웃한 값의 수를, 식별한 경계값과 이웃 값의 총수로 나눈 값으로 측정하며 백분율로 표시한다.
세 개 선택 경계값 분석은 두개 선택 경계값 분석으로 발견하지 못한 결함을 식별할 수 있으므로 두개 선택 경계값 분석보다 더 엄격하다고 할 수 있다.

4.2.3 결정 테이블 테스팅

결정 테이블 : 다중 조건 조합으로 달라지는 결과를 나타내는 시스템 요구사항이 제대로 구현되었는지 테스트하는 데 사용. 비즈니스 규칙과 같은 복잡한 논리를 기록하는 효과적인 방법.

결정 테이블을 만들 때 조건들과 그에 따른 시스템의 동작 결과를 정의하며 이것이 테이블의 행을 구성한다. 열은 각각 하나의 결정 규칙을 나타내며, 어떤 고유한 조건 조합을 연관 동작과 함께 정의한다.

제한-입력 결정 테이블 : 모든 조건과 동작 결괏값(관련 없거나 실행 불가능한 값 제외)을 부울값으로 표시.
확장-입력 결정 테이블 : 조건 및 동작 결괏값의 일부 또는 전부가 복수의 값(ex> 숫자 범위, 동등 분할, 불연속 값)을 취할 수 있다.

< 조건의 표기법 >
▶ T : 참- 조건이 충족 O. 
▶ F : 거짓- 조건 충족 X.
▶ - : 조건값이 결과에 영향 X.
▶ N/A : 해당 규칙에서 조건이 실행 불가능함을 의미.
< 결과 동작 >
▶ X : 동작이 발생해야 함을 의미.
▶ 공백 : 동작이 발생하지 않아야 함을 의미.

전체 결정 테이블에는 모든 조건 조합을 포함할 수 있는 충분한 열이 있다. 실현 불가능한 조건 조합열을 삭제해 테이블을 더 단순화할 수 있다. 일부 조건이 결과에 영향을 미치지 않는 열들을 하나로 병합해 테이블을 최소화할 수 있다.
결정 테이블 테스팅에서 커버리지 항목은 실현 가능한 조건 조합을 가진 열이 된다. 이 기법으로 100% 커버리지를 달성하려면, 테스트 케이스가 이런 열을 모두 실행해야 한다.
커버리지는 실행된 열의 수를 실행 가능한 열의 총수로 나눈 값으로 측정하며 백분율로 표시한다.

결정 테이블 테스팅의 강점 :
>> 간과했을 수도 있는 조합을 포함한 모든 조건 조합을 식별하는 체계적인 방법을 제공한다는 점.
>> 누락되거나 모순되는 요구사항을 찾는 데 도움.
결정 테이블 테스팅의 단점 :
>> 조건의 수에 따라 규칙의 수는 기하급수적으로 늘어나기 때문에, 조건이 많으면 모든 결정 규칙을 실행하는 데 오랜 시간이 걸릴 수 있음.
>> 보완 : 실행해야 하는 규칙의 수를 줄이기 위해 결정 테이블을 최소화하거나, 리스크 기반 접근법을 사용. 

4.2.4 상태 전이 테스팅

상태 전이 테스팅 : 가능한 상태와 유효한 상태 전이를 표시해 시스템 동작을 모델링.
전이는 하나의 이벤트에 의해 발생, 별도의 가드 조건이 있을 수 있다. 즉각적인 것으로 간주되며 가끔 소프트웨어의 어떤 동작으로 연결되기도 함.
< 전이를 표시하는 형식 >
: "이벤트 [가드 조건] /동작". 가드 조건과 동작이 없거나 테스터와 관련 없는 경우 생략 가능.

상태 테이블은 상태 전이 다이어그램을 다르게 표현한 모델.
- 행은 상태를 나타내고, 열은 이벤트(가드 조건이 있다면 함께)를 나타낸다. 테이블의 각 항목은 전이를 나타내며, 목표 상태는 물론 가드 조건, 정의된 경우에는 결과 동작도 포함된다.
- 상태 테이블은 유효하지 않은 전이를 빈 항목으로 명확하게 보여준다.

상태 전이 다이어그램이나 상태 테이블을 기반으로 하는 테스트 케이스는 보통 일련의 이벤트 순서와 그 결과로 생기는 상태 변화로 표현된다. 하나의 테스트 케이스는 대부분의 경우 여러 개의 상태 전이를 포함.

< 상태 전이 테스팅의 세 가지 커버리지 측정 기준 >
모든 상태 커버리지	커버리지 항목 : 상태들. - 100% 달성하려면 테스트 케이스로 모든 상태를 확인해야 함. - 커버리지는 확인한 상태 수를 상태 총수로 나눈 값으로 측정하고 백분율 표시.
유효 전이 커버리지 (가장 널리 사용하는 커버리지 조건)	커버리지 항목 : 유효 전이. - 100% 달성하려면 테스트 케이스가 모든 유효 전이를 실행해야 함. - 커버리지는 실행된 유효 전이 수를 총 유효전이 수로 나눈 값으로 측정하고 백분율로 표시.
모든 전이 커버리지	커버리지 항목 : 상태 테이블에 표시된 모든 전이들. - 100%를 달성하려면 테스트 케이스로 모든 유효 전이를 실행하고, 유효하지 않은 비 유효 전이의 실행도 시도해야 함. - 커버리지는 실행된 테스트 케이스로 수행하거나, 커버하려고 시도한 유효 및 비 유효 전이 수를 총 유효 및 비유효 전이 수로 나눈 값으로 측정하고 백분율로 표시.

모든 상태 커버리지는 일반적으로 모든 전이를 실행하지 않고도 달성할 수 있기 때문에, 유효 전이 커버리지보다 약하다.
모든 전이 커버리지를 100% 달성하면, 모든 상태 커버리지와 유효 전이 커버리지도 모두 보장된다.

4.3 화이트박스 테스트 기법
: 간단하면서 널리 사용되는 화이트박스 테스트 기법 2가지.

• 구문 테스팅
• 분기 테스팅

4.3.1 구문 테스팅과 구문 커버리지

< 구문 테스팅 > 
- 커버리지 항목: 실행 가능한 구문.
- 목적: 코드 구문을 실행하는 테스트 케이스를 설계해서 허용할 수 있는 수준의 커버리지를 달성하는 것.
- 커버리지는 테스트 케이스가 실행한 구문 수를 코드의 실행 가능한 구문 총수로 나누어 계산하며 백분율로 표시.

100% 구문 커버리지를 달성하면 코드의 모든 실행 가능한 구문을 적어도 한 번은 실행했다는 것이 보장.
But, 테스트 케이스로 구문을 실행했다고 해서 결함이 반드시 식별되는 것은 X.
ex. 데이터에 종속적인 결함(예: 분모를 0으로 설정한 경우에만 실패하는 나눗셈)은 식별하지 못할 수 있음.
100% 구문 커버리지가 모든 결정 논리를 테스트했다고 보장하는 것도 X.
ex. 코드의 모든 분기가 실행되지 않았을 수도 있음.

4.3.2 분기 테스팅과 분기 커버리지

< 분기 테스팅 >
- 커버리지 항목 : 분기.
- 목적 : 코드의 분기를 실행하는 테스트 케이스를 설계해서 허용할 수 있는 수준의 커버리지를 달성하는 것.
- 커버리지는 테스트 케이스가 실행한 분기 수를 분기 총수로 나눈 값으로 측정하며 백분율로 표시.

100% 분기 커버리지를 달성하면 코드의 모든 분기를 테스트 케이스로 실행하게 됨.
But, 테스트 케이스로 분기를 실행한다고 해서 반드시 결함을 식별할 수 있는 것은 X.
ex. 코드의 특정 경로를 실행해야 하는 결함은 감지하지 못할 수 있음.

분기 커버리지는 구문 커버리지를 포함한다. 
100% 분기 커버리지를 달성하는 테스트 케이스 집합은 100% 구문 커버리지도 달성. 그 반대는 성립 X.

4.3.3 화이트박스 테스팅의 가치

화이트박스 테스팅의 강점	테스트 중 전체 소프트웨어 구현을 고려하므로 소프트웨어 명세가 모호하거나 뒤떨어지고 불완전한 경우에도 결함을 쉽게 감지할 수 있음.
화이트박스 테스팅의 단점	소프트웨어가 하나 이상의 요구사항을 구현하지 않는 경우, 화이트박스 테스팅은 그것이 누락됐다는 결함을 식별하지 못할 수 있음.

화이트박스 기법은 정적 테스팅에 사용할 수 있다.
아직 실행할 준비가 되지 않은 코드 외에도 슈도 코드 또는 제어 흐름 그래프로 모델링할 수 있는 기타 상위 수준 및 하향식 논리를 검토하는 데 적합.

블랙박스 테스팅만 수행해서 실제 코드 커버리지 측정치를 얻을 수 없다. 
화이트박스 커버리지 측정치는 객관적인 커버리지 측정값을 제공하고 커버리지를 높이기 위해 추가로 필요한 테스트를 만들기 위해 필요한 정보를 제공해서 결국 코드 신뢰도를 높일 수 있게 해 줌.

들어가기 전 알아둬야 할 4.1 용어 설명
: 이해에 중점. 부족하면 용어설명 글 참고.

블랙박스 테스트 기법 : 개발자 입장이 아닌 사용자 입장에서 바라본 제품의 요구사항이 일치하는지 확인하는 테스트 기법. 명세 기반 기법.
화이트박스 테스트 기법 : 개발자 입장에서 바라본 로직에 대한 설계로 구현이 제대로 되었는지 확인하는 테스트 기법. 구조 기반 기법.
경험 기반 테스트 기법 : 탐색적 테스팅.
테스트 케이스 : 테스트 베이시스를 토대로 만들어짐. 블랙박스와 경험기반 테스트의 주요 차이점은 테스트 베이시스가 다른 거야. 블랙박스는 명세, 경험기반은 탐색.

4.1 테스트 기법 개요
:테스트 설계와 분석에 적용할 활동들을 공부해보자고!

테스트 기법이란?
- 테스터의 테스트 분석(무엇을 테스트할지)과 테스트 설계(어떻게 테스트할지) 작업을 지원.
- 적은 수이지만 충분한 테스트 케이스를 체계적인 방식으로 개발할 수 있도록 해줌.
- 테스터가 테스트 분석과 설계에서 테스트 컨디션을 정의하고, 커버리지 항목과 테스트 데이터를 식별하는데 도움을 줌.

용어 정리
: 용어부터 정리해 두고 봐야 이해가 쉬움.
▼ 혹시나 더 찾아보고 싶은 단어가 있다면 여기로 가서 찾아보기 ▼
++ https://glossary.istqb.org/ko_KR/

인수 조건 : 사용자, 고객, 기타 권한을 지닌 사람이 제품을 인수하기 위해 컴포넌트나 시스템이 만족시켜야 하는 기준.
인수 테스트 주도 개발 : 팀과 고객이 고객 고유의 도메인 언어를 사용하여 컴포넌트 또는 시스템을 테스트하기 위한 베이시스를 형성하는 고객 요구사항을 이해하는 개발에 대한 협업적 접근 방식.

경계값 분석 : 경계값을 기반으로 테스트 케이스를 설계하는 블랙박스 테스트 기법.

분기 커버리지 : ==결정 커버리지. 결정된 결과값에 대한 커버리지. 

체크리스트 기반 테스팅 : 경험, 점검, 기억에 의한 목록 또는 제품 검증 기준 및 규칙을 상위 수준으로 나열한 목록을 숙련된 테스터가 사용하는 경험 기반 테스트 기법.

커버리지 : 커버리지 항목이 식별되거나 테스트 스위트에 의해 수행된 정도를 백분율로 표시한 것.
커버리지 항목 : 테스트 실행의 완전성을 측정할 수있는 테스트 기법을 사용해 하나 이상의 테스트 컨디션에서 도출하는 속성 또는 속성들의 결합체.

결정 테이블 테스팅 : 테스트 케이스가 결정 테이블에 표시된 조건과 결과 행위 조합을 실행하도록 설계하는 블랙박스 설계 기법.

동등 분할 : 명세에 따라 모든 값이 동일하게 취급될 것으로 예상되는 컴포넌트 또는 시스템 내의 변수 값 도메인의 하위 집합.

오류 추정 : 과거 장애에 대한 테스터의 지식이나 장애 형태에 대한 일반적인 지식에 기초하여 테스트 케이스를 도출하는 테스트 기법.

탐색적 테스팅 : 테스터가 자신의 지식, 테스트 항목에 대한 탐색과 이전 테스트 결과를 기반으로 테스트를 동적으로 설계하고 실행하는 테스트 접근 방식.
상태 전이 테스팅 : 테스트 케이스가 상태 전이 모델의 개별 요소를 실행하도록 설계된 블랙박스 테스트 기법.

구문 커버리지 : 실행 가능한 구문에 대한 커버리지.

테스트 기법 : 테스트 조건을 정의하고, 테스트 케이스를 설계하고, 테스트 데이터를 지정하는 데 사용되는 절차.

블랙박스 테스트 기법 : 컴포넌트나 시스템의 명세에 대한 분석을 기반으로 하는 테스트 기법.

화이트박스 테스트 기법 : 컴포넌트 또는 시스템의 내부 구조에만 기반을 둔 테스트 기법.

경험 기반 테스트 기법 : 테스터의 경험, 지식, 직관에만 기반을 둔 테스트 기법.

4장의 내용은 엄청 많으면서 엄청 중요한 내용이다. 테스트 기법에 대해서도 알아야 되고 분석 문제도 풀 줄 알아야 된다.

샘플문제도 많이 풀어보고 발품팔아 구글링이랑 네이버 블로그 뒤적거려서 문제도 많이 찾아보고 풀어보는 게 좋다.

용어 정리
: 용어부터 정리해 두고 먼저 읽어봐야 이해가 쉬움.
▼ 혹시나 더 찾아보고 싶은 단어가 있다면 여기로 가서 찾아보기 ▼
++ https://glossary.istqb.org/ko_KR/

이상 사항 : ==이상 현상. 요구사항 명세서, 설계 문서, 사용자 문서, 표준 또는 누군가의 인식이나 경험 등에 기반한 기댓값에서 벗어난 상태를 말한다. 이상 현상은 리뷰, 테스팅, 분석, 비교, 혹은 소프트웨어 제품이나 해당 문서의 사용 도중에 발견할 수 있지만, 이에 국한되지는 않음.

동적 테스팅 : 테스팅 항목의 실행과 관련된 테스트.

공식 리뷰 : 공식 산출물로 정의된 프로세스를 따르는 리뷰 유형.
비공식 리뷰 : 정의된 프로세스를 따르지 않고 문서화된 공식 결과가 없는 리뷰 유형.

인스펙션 : 작업 산출물의 이슈를 식별하기 위한 공식리뷰 유형. 리뷰 프로세스와 소프트웨어 개발 프로세스를 개선하는 데 필요한 정보를 제공.

리뷰 : 결함을 발견하거나 개선 사항을 제공하기 위해 한 명 이상의 개인이 작업 산출물 또는 프로세스를 평가하는 정적 테스팅 유형.

정적 분석 : 형식이나 구조, 내용, 문서를 기반으로, 컴포넌트나 시스템을 실행하지 않으면서 평가하는 프로세스.

정적 테스팅 : 테스트 항목의 실행을 수반하지 않는 테스팅.

기술 리뷰 : 작업 산출물의 품질을 검사하고 명세 및 표준과의 불일치를 식별하는 기술 전문가의 공식 리뷰.

위크 쓰루 : == 워크스루. 작성자가 작업 산출물에 대한 리뷰를 주도하고, 참가자들은 발생 가능 이슈에 대한 질문과 의견을 제시하는 리뷰 유형.

3장은 공부시간이 80분으로  6장 테스트 지원도구(20분) 외에 가장 짧은 시간이 필요하다. 읽어보면서 이해하고 넘어가야 80분의 시간 안에 끝낼 수 있다. 아무 생각 없이 읽기만 반복한다면 뫼비우스의 띠처럼 글씨, 글씨, 글씨로 시간이 줄줄이 흘러가 버려지는 시간이 늘어날 수 있다. 도저히 집중이 안된다 싶다면 문제를 풀어보면서 해설을 읽으며 공부해도 좋은 구역이다.

들어가기 전 알아둬야 할 2.2 용어, 2.3 용어 설명
: 사전적으로 설명 정리한 건 용어 설명 글 ㄱㄱ, 여기는 이해 쉽게 봐보자.

테스트 레벨 : 테스트 프로세스 중의 특정 예시 단계. 
테스트 유형 : 컴포넌트나 시스템의 특성을 목표로 하는 구체적인 테스트 목적에 기반한 테스트 활동의 집합.

컴포넌트 : 개별적으로 테스트할 수 있는 시스템의 최소 구성단위.
엔드 투 엔드 테스팅 : 생산 환경과 유사한 환경에서 비즈니스 프로세스를 처음부터 끝까지 테스트하는 테스팅 유형.
테스트 명세 : 특정 테스트 항목에 대한 테스트 설계, 테스트 케이스, 테스트 스크립트를 모두 담고 있는 문서.

< 기능 테스트 & 비기능 테스트의 기능과 비기능 해석 >
기능 : 무엇을 해야 하는지.
비기능 : 얼마나 잘 돌아가는지.

확인 테스팅 : 원래 결함이 성공적으로 수정됐는지 확인.
리그레션 테스팅 : 변경으로 인해 부정적인 영향 있는지 확인. 확인 테스팅 이후에 리그레션 테스팅하는 거임.

운용 환경 : 움직이는 환경으로 이해 ㄱㄱ.

2.2 테스트 레벨과 테스트 유형

- 테스트 레벨은 함께 구성하고 관리하는 테스트 활동 집합이다.
: 각 테스트 레벨은 특정 개발 단계의 소프트웨어와 관련해 수행하는 테스트 프로세스의 인스턴스이다.
단계에 따라 소프트웨어는 개별 컴포넌트부터 완성된 시스템에 이를 수 있으며, 경우에 따라서는 시스템의 시스템일 수 있다.
- 테스트 레벨은 소프트웨어 개발수명주기 내의 다른 활동과 연관성을 가진다.
: 순차적 소프트웨어 개발수명주기 모델은 한 레벨의 완료 조건이 다음 레벨의 시작 조건에 포함되도록 테스트 레벨을 정의하는 경우가 많다.

- 테스트 유형은 특정 품질 특성 관련 테스트 활동의 집합으로, 이런 테스트 활동은 대부분 모든 테스트 레벨에서 수행할 수 있다.

2.2.1 실러버스에서 다루는 테스트 레벨 5가지

• 컴포넌트 테스팅(== 단위 테스팅) : 컴포넌트를 개별적으로 테스트하는 데 중점. 테스트 하네스 또는 단위 테스트 프레임워크와 같은 구체적인 지원 수단이 필요한 경우가 많음. 일반적으로 개발자가 자신의 개발 환경에서 수행함.
• 컴포넌트 통합 테스팅(== 단위 통합 테스팅) : 컴포넌트 간의 인터페이스와 상호 작용을 테스트하는 데 중점. 상향식, 하향식, 빅뱅 등 통합 전략 접근법에 따라 크게 달라진다.
• 시스템 테스팅 : 전체 시스템 또는 제품의 전반적인 동작과 기능에 중점. 엔드 투 엔드 동작에 대한 기능 테스팅과 품질 특성에 대한 비기능 테스팅을 포함하는 경우가 많음. 독립 테스트팀이 수행할 수 있으며, 시스템의 명세와 관련이 있음.
• 시스템 통합 테스팅 : 다른 시스템 또는 외부 서비스와 테스트 대상 시스템의 인터페이스를 테스트하는 데 중점. 가급적 운영 환경과 유사한 적절한 테스트 환경을 사용함.
• 인수 테스팅 : 밸리데이션과 배포할 준비, 즉 시스템이 사용자의 비즈니스에 필요한 사항을 충족하는지를 확인하는 데 중점. 실제 사용자가 수행하는 것이 이상적. 주요 유형으로 사용자 인수 테스팅, 운영 인수 테스팅, 계약 및 규제 인수 테스팅, 알파 테스팅, 베타 테스팅이 있음.

▶ 테스트 레벨은 테스트 활동의 중복을 피하기 위해 다양한 속성 "테스트 대상, 테스트 목적, 테스트 베이시스, 결함과 장애, 접근법과 역할"들을 고려해 구분한다.

2.2.2 실러버스에서 다루는 테스트 유형 4가지

• 기능 테스팅 : 컴포넌트 또는 시스템이 수행해야 하는 기능을 평가. 기능은 테스트 대상이 "무엇을" 해야 하는지를 의미. 주요 목적 - 기능 성숙도(완전성), 기능 정확성, 기능 타당성(적합성)을 확인하는 것.
• 비기능 테스팅 : 컴포넌트 또는 시스템의 기능 특성 이외의 속성을 평가. "시스템이 얼마나 잘 동작하는지" 테스트하는 것. 주요 목적 - 비기능 소프트웨어 품질 특성을 확인하는 것.

ISO/IEC 25010 표준은 비기능 소프트웨어 품질 특성을 다음과 같이 분류함.
- 수행 효율성.
- 호환성.
- 유용성.
- 신뢰도.
- 보안.
- 유지 가능성.
- 이동성.

수명 주기 초기에 비기능 테스팅을 시작하는 것이 바람직할 때가 있다.
기능 테스트에서 비기능 테스트를 도출하는 경우도 많다. 이때 기능 테스트에서 기능이 수행되는 동안 비기능 제약 조건의 충족 여부를 확인하게 된다. 비기능 결함을 늦게 발견하면 프로젝트의 성공에 심각한 위협이 될 수 있다.

• 블랙박스 테스팅 : 명세를 기반으로 하며, 테스트 대상 외부에 있는 문서에서 테스트를 도출. 주요 목적 - 명세와 비교해 시스템의 동작을 확인하는 것.
• 화이트박스 테스팅 : 구조 기반이며, 시스템의 구현 또는 내부 구조에서 테스트를 도출. 주요 목적 - 테스트를 통해 내부 구조를 인수에 필요한 수준까지 충분히 커버하는 것.

2.2.3 확인 테스팅 및 리그레션 테스팅

일반적으로 컴포넌트나 시스템을 변경하는 이유는 새로운 기능을 추가해 개선하거나 결함을 제거해 수정하기 위함이다. 이때는 테스팅에 확인 테스팅과 리그레션 테스팅을 추가할 필요가 있다.

▶ 어떤 테스트 레벨이라도 해당 레벨에서 결함을 수정하거나 변경을 적용한 경우, 테스트 대상에 대한 확인 테스팅과 리그레션 테스팅이 필요하다.

2.3 유지보수 테스팅

유지보수에는 여러 범주가 있다. 문제를 수정하기 위한 유지보수, 환경 변화에 적응, 성능 또는 유지보수성을 개선하기 위한 것도 있기 때문에 유지보수는 계획된 릴리스/배포 또는 계획되지 않은 릴리스/배포 모두와 연관돼 있다.
운용환경에서 시스템의 변경사항을 테스트하는 것에는 변경 구현의 성공을 검증하는 것과, 변경되지 않은 시스템 영역(보통은 시스템 대부분)에서 발생할 수 있는 리그레션을 확인하는 작업이 모두 포함된다.

▶ 유지보수 테스팅의 범위는 일반적으로 "변경의 리스크 수준, 기존 시스템의 크기, 변경사항의 크기"에 따라 달라진다.

< 유지보수와 유지보수 테스팅의 계기 >

• 계획된 개선사항, 수정을 위한 변경, 핫픽스와 같은 수정사항.
• 운영 환경의 업그레이드나 마이그레이션 하는 경우, 변경된 소프트웨어뿐만 아니라 새로운 환경 관련 테스트가 필요할 수 있으며, 다른 애플리케이션의 데이터를 유지보수 중인 시스템으로 마이그레이션 할 때, 데이터 변환 테스트가 필요할 수 있다.
• 애플리케이션의 수명이 다하는 등의 단종. 시스템을 단종할 때 데이터 보존 기간이 길면 데이터 보관 테스팅이 필요할 수 있다. 보관기간 중 데이터가 필요한 경우를 대비해, 보관 이후 복원 및 복구 절차 테스팅이 필요할 수 있다. 

들어가기 전 알아둬야 하는 2.1 용어 설명
: 사전적으로는 용어설명 글 참고 ㄱㄱ, 여긴 간단하게 봐보자.

리그레션 테스팅 : 수정으로 기존에 있던 프로그램에 새로운 결함이 생겼는지 테스팅.
프랙티스 : 관리 활동.
시프트 레프트 전략 == 조기 테스팅원리.
인수 테스트 주도 개발 >> 대표적인 테스트 우선 개발 접근법.
명세 : 자세한 내용.
테스트 하네스 : 자동화된 테스트 지원도구.
회고 : 프로젝트 종료 후 회의.

테스트 주도 개발 : 테스트 케이스가 개발되고 많은 경우 자동화된 다음 해당 테스트 케이스에 합격하도록 소프트웨어를 점진적으로 개발하는 소프트웨어 개발 기법.
>> 테스트가 주도하는 개발 방법론을 의미.

인수 테스트 주도 개발 : 팀과 고객이 고객 고유의 도메인 언어를 사용하여 컴포넌트 또는 시스템을 테스트하기 위한 베이시스를 형성하는 고객 요구사항을 이해하는 개발에 대한 협업적 접근 방식.
>> 인수테스트가 주도하는 개발 방법론을 의미.

행위 주도 개발 : 팀이 테스트의 베이시스를 형성하는 고객을 위한 컴포넌트 또는 시스템의 기대 동작을 제공하는 데 집중하는 개발에 대한 협업적 접근 방식.
>> 시스템 동작의 행위를 기반. 행위에 대한 명세를 작성하는 것이라 생각하면 이해가 쉬움.

비기능 테스트 : 기능이 아닌 거. 테스트 결과가 기능 테스트처럼 Yes/No로 판단하기 힘듦.
ex> 로그인 기능 테스트. 버튼 클릭시 로그인은 되는데 지연이 10초 이상 되었다가 로그인이 될 때.(기능은 정상 작동하지만 뭔가 문제가 있지.)

2.1 소프트웨어 개발수명주기에서의 테스팅

소프트웨어 개발수명주기(SDLC) 모델은 상위 수준에서 소프트웨어 개발 프로세스를 추상화해서 표현한 것이다.
소프트웨어 개발수명주기(SDLC) 모델의 예 :
순차적 개발 모델(ex> 폭포수 모델, V - 모델), 반복적 개발 모델(ex> 나선형 모델, 프로토 타이핑), 점진적 개발 모델(ex> 통합 프로세스)등이 있다.

2.1.1 소프트웨어 개발수명주기(SDLC)가 테스팅에 미치는 영향

• 테스트 활동 범위 및 시기(ex> 테스트 레벨 및 테스트 유형)
• 테스트 문서 상세화 수준
• 테스트 기법 및 테스트 접근법 선택
• 테스트 자동화 범위
• 테스터의 역할과 책임

2.1.2 소프트웨어 개발수명주기(SDLC)와 우수한 테스팅 프랙티스
: 선택한 소프트웨어 개발수명주기 모델에 상관없이 다음과 같은 우수한 테스팅 프랙티스가 있다.

• 모든 소프트웨어 개발 활동에 상응하는 테스트 활동을 두어 모든 개발 활동이 품질 제어의 대상이 되게 한다.
• 테스트 레벨마다 구체적이면서 독립적인 테스트 목적을 설정해, 중복은 피하고, 적절하면서 포괄적인 테스팅이 가능하게 한다.
• 특정 테스트 레벨을 위한 테스트 분석과 설계를 소프트웨어 개발수명주기의 상응하는 각 개발 단계에서 시작해 (테스팅 원리 중) 조기 테스팅 원칙을 준수할 수 있게 한다.
• 테스터가 문서 초안이 가용한 즉시 작업 산출물 리뷰에 참여하도록 해서, 시프트-레프트 전략 지원을 위한 조기테스팅과 결함 발견이 가능하도록 한다.

2.1.3 소프트웨어 개발 주도를 위한 테스팅

테스트 주도 개발, 인수 테스트 주도 개발, 행위 주도 개발은 서로 유사한 개발 접근법으로 개발 방향 결정을 위한 수단으로 테스트를 정의한다.
이런 접근법은 코드 작성 전에 테스트를 정의하므로 조기 테스팅 원리를 구현하고 시프트-레프트 접근법을 따르게 한다. 반복적 개발 모델을 지원함.

2.1.4 데브옵스(DevOps)와 테스팅

- 테브옵스는 개발(테스팅 포함)과 운영이 협력해 공통된 목표를 달성하도록 시너지 창출을 목표로 하는 조직 차원의 접근법이다.
- 데브옵스는 개발(테스팅 포함)과 운영이 가진 생각의 차이를 줄임과 동시에 각자 하는 일의 가치를 서로 동등하게 보도록 조직문화의 변화가 필요하다.
- 데브옵스는 팀의 자율성, 빠른 피드백, 통합 도구 체인, 지속적 통합과 지속적 배포와 같은 기술 실천법을 장려한다.
- 팀은 데브옵스 배포 파이프라인을 통해 높은 품질의 코드를 더 빠르게 빌드/ 테스트/ 릴리스할 수 있다.

2.1.5 시프트 레프트 접근법

조기 테스팅 원리는 테스트를 소프트웨어 개발수명주기 초기에 수행하도록 하는 접근법이기 때문에 시프트 레프트라고도 지칭하기도 한다.
시프트 레프트는 테스트를 더 일찍 수행해야 한다는 것을 의미하지만, 그렇다고 소프트웨어 개발수명주기 후반의 테스트를 무시해도 된다는 의미는 아니다.

< 테스팅에서 시프트 레프트를 달성하는 좋은 일부 프랙티스>

• 테스팅 관점에서 명세를 리뷰. - 모호성, 불완정성, 불일치 등 잠재적인 결함을 발견하는 경우가 많다.
• 코드를 작성하기 전에 테스트 케이스를 작성하고, 코드 구현 중 코드를 테스트 하네스에서 실행한다.
• 빠른 피드백을 제공하고, 코드 저장소에 소스 코드를 저장할 때 자동 컴포넌트 테스트를 함께 제출하도록 하는 지속적인 통합, 가능하다면 지속적인 배포까지 적용한다.
• 동적 테스팅 전 또는 자동화된 프로세스의 일부로 소스 코드의 정적분석을 완료한다.
• 가능한 한 컴포넌트 테스트에서부터 비기능 테스팅을 수행한다. 비기능 테스트는 완성 시스템과 실제 환경을 대변하는 테스트 환경이 가용한 소프트웨어 개발수명주기 후반에 수행하는 경향이 있으므로, 이는 일종의 시프트 레프트가 된다.

>> 시프트 레프트 접근법은 프로세스 초기에 훈련, 공수, 비용이 추가로 들지만, 프로세스 후반의 공수와 비용의 절감을 기대할 수 있다. 이해관계자들의 개념을 이해하고 받아들이는 것이 중요하다.

2.1.6 회고 및 프로세스 개선
: 회고 = 프로젝트 종료 후 회의 또는 프로젝트 회고라고 함.

회고는 프로젝트나 반복 주기가 끝날 때, 릴리스 마일스톤에서, 또는 필요시 진행할 수 있다. 회고의 시기와 구성은 사용 중인 소프트웨어 개발수명주기 모델에 따라 달라진다.
결과는 기록해야 하며 이를 테스트 완료 보고서에 포함하는 경우가 많다. 회고는 지속적인 개선을 성공적으로 구현하기 위해 반드시 필요하며, 권장된 모든 개선 사항에 대한 후속 조치가 이루어지는 것이 중요.

>> 회고와 최종사용자는 관련이 없어.

< 테스팅 관점에서 일반적인 이점 >

• 테스트 효과성/ 효율성 향상(ex> 프로세스 개선 권고 사항 구현을 통해)
• 테스트웨어 품질 향상(ex> 테스트 프로세스를 함께 검토함으로써)
• 팀의 결속 및 학습 향상(ex> 문제를 제기하고, 개선점을 제안할 기회를 제공함으로써)
• 테스트 베이시스 품질 개선(ex> 요구사항의 범위나 품질에서 부족한 점을 발견하고, 수정함으로써)
• 개발(개발자로부터 피드백)과 테스팅 간의 협업 개선(ex> 정기적으로 협업 과정을 검토하고 최적화함으로써) 

전체적으로 외우지 말고 계속 읽어보는 게 공부가 되는 구역. 

용어 정리
: 용어부터 알아둬야 문제 이해가 쉬움.
▼ 혹시나 더 찾아보고 싶은 단어가 있다면 여기로 가서 찾아보기 ▼
++ https://glossary.istqb.org/ko_KR/

테스트 대상: 테스트할 작업 산출물. 

테스트 유형: 컴포넌트나 시스템의 특성을 목표로 하는 구체적인 테스트 목적에 기반한 테스트 활동의 집합.

테스트 레벨: 테스트 프로세스 중의 특정 예시 단계.

인수 테스팅: 시스템을 승인할지 여부를 결정하는 데 초점을 둔 테스트 레벨.

컴포넌트 테스팅: 개별 하드웨어 또는 소프트웨어 컴포넌트에 초점을 둔 테스트 레벨.

통합 테스팅: 컴포넌트 또는 시스템 간의 상호작용에 중점을 둔 테스트 레벨.

시스템 통합 테스팅: 시스템 간의 상호작용에 초점을 둔 테스트 레벨.

시스템 테스팅:  전체로 봤을 때 시스템이 명시된 요구사항을 충족하는지 확인하는 데 초점을 둔 테스트 레벨.

블랙박스 테스팅: 소프트웨어의 내부 구조나 작동 원리를 모르는 상태에서 동작을 검사하는 방식의 테스팅.

화이트 박스 테스팅: 컴포넌트나 시스템의 내부 구조 분석에 기반한 테스팅.

컴포넌트 통합 테스팅: 통합된 컴포넌트 간의 인터페이스와 상호작용에서의 결함을 노출시키기 위한 테스팅.

기능 테스팅: 컴포넌트 또는 시스템이 기능 요구사항을 충족하는지 평가하기 위해 수행되는 테스트.

비기능 테스팅: 컴포넌트 또는 시스템이 비기능적 요구사항을 충족하는지 평가하기 위해 수행되는 테스트.

유지보수 테스팅: 운영 중인 시스템에 대한 변화, 또는 운영 중인 시스템에 미치는 환경 변화의 영향에 대한 테스팅.

확인 테스팅: 결함을 수정한 후 해당 결함으로 인해 발생한 장애가 다시 나타나지 않는지 확인하기 위해 수행하는 변경 관련 테스트 유형. 

리그레션 테스팅: 소프트웨어의 변경되지 않은 영역에 결함이 도입 또는 발현되었는지 여부를 감지하기 위한 변경 관련 테스트 유형.

시프트- 레프트: 소프트웨어 개발 라이프 사이클(SDLC)에서 가능한 빨리 보안을 도입하는 것을 의미.

시프트레프트는 위에 말한 사이트에서 찾을 수 없어서 구글로 검색해 봤는데 생각보다 이해해 두고 넘어가는 게 중요할 것 같아서 참고할 만한 블로그를 찾았다. 한번 읽어 보고 넘어가는 걸 추천.

https://katalon.com/resources-center/blog/shift-right-testing