Software Test 종류와 방법

테스트 유형(Test Type) : The targets of testing

테스팅 하는 목적 및 품질 특성을 염두에 두고 소프트웨어 시스템(또는 시스템 일부분)을 검증하는 일련의 테스트 활동입니다.

기능 테스팅(Functional testing)

실행되어야 하는 (서브) 시스템 또는 컴포넌트의 기능은 요구사항 명세, 유스케이스 또는 기능적인 명세와 같은 개발 산출물에 기술되어 있거나 문서화되지 않을 수 있습니다.
기능은 시스템이 수행하는 그 무엇을 의미합니다.
ISO/IEC 9126에서는 기능성이라는 품질 특성에 적합성, 정확성, 준수성, 상호운용성, 보안성 등의 부특성을 포함시키고 있습니다.

비기능 테스팅(Non-functional testing)

비기능 테스트는 성능 테스팅, 부하 테스팅, 스트레스 테스팅, 사용성 테스팅, 유지보수 테스팅, 신뢰성 테스팅, 그리고 이동성 테스팅 등을 포함하는 개념입니다.
이는 소프트웨어 제품 특성 테스팅이라고도 하며 시스템이 어떻게 동작하는 가를 테스팅합니다.
비기능 테스팅은 모든 테스트 레벨에서 수행될 수 있습니다. 다양한 척도 또는 비율로 정량화 가능한 소프트웨어나 시스템 특성을 측정하는 테스트를 의미합니다.

구조적 테스팅(Structural testing)

구조적 테스팅은 특정 유형의 구조에 대한 커버리지를 평가하여 테스팅의 보장성 또는 충분함(Thoroughness)을 측정하는 것이 목적인 테스트 유형입니다.
커버리지는 시스템 또는 소프트웨어의 구조가 test suites에 의해 테스트된 정도를 말하며 구조 종류에 대해 커버된 퍼센트로 표시합니다.
모든 테스트 레벨에서 수행이 가능하며, 특히 컴포넌트 테스트 레벨과 컴포넌트 통합 테스트 레벨에서 프로그램 코드의 수행 커버리지를 높이는 목적으로 구조적 테스트 기법(화이트 박스 테스트 기법)을 적용할 수 있습니다.

확인(재)/ 리그레션 테스팅(Confirmation(re-testing) and regression testing)

확인 테스팅
- 결함이 발견되고 수정된 후에 소프트웨어는 원래의 결함이 성공적으로 제거되었는지 확인하기 위해 다시 테스트되어야 합니다.
- 여기서 디버깅은 개발 활동이며 테스팅 활동으로 보지 않습니다.
리그레션 테스팅
- 이미 테스트된 프로그램의 테스팅을 반복하는 것입니다.
- 결함 수정 이후 변경의 결과로 새롭게 만들어지거나, 이전 결함으로 인해 발견되지 않았던 또 다른 결함을 발견하는 것입니다.
- 환경이 변해도 수행되어야 합니다.
- 모든 테스트 레벨에서 수행할 수 있으며, 기능, 비기능 그리고 구조적 테스팅이 적용할 수 있습니다.

유지보수 테스팅 (Maintenance testing)

소프트웨어 시스템이 일단 배포되면, 일반적으로 수년~수십 년 정도 서비스됩니다. 이 기간 동안 시스템과 그 환경은 수정되고 변경되거나 확장됩니다.
유지보수 테스팅은 이미 운영되고 있는 시스템에서 수행되며, 소프트웨어나 시스템이 변경, 단종되었거나 마이그레이션 될 때 발생합니다.
유지보수 테스팅은 변경된 부분에 대한 테스팅 이외에도 변경되지 않은 시스템 요소에 대한 방대한 리그레션 테스팅도 고려합니다.
유지보수 테스팅의 범위는 변경 사항의 리스크 및 크기, 기존 시스템의 크기와 관련이 있습니다. 변경된 내용에 따라서, 유지 보수 테스팅은 모든 테스트 유형에 대해 모든 테스트 레벨에서 수행할 수 있습니다.

📌 테스트 설계 기법의 종류

블랙박스 기법
- 명세기반 기법, 경험기반 기법을 포함합니다.
- 테스트 대상의 내부구조(코드)를 참조하지 않고 테스트 베이시스, 개발자와 사용자들의 결험을 바탕으로 기능적 혹은 비기능적 테스트 케이스를 도출하고 선택하는 방법입니다.
화이트박스 기법
- 구조기반 기법을 포함합니다.
- 컴포넌트(단위) 또는 소프트웨어(시스템)의 구조(코드)를 중심으로 테스트 케이스를 도출하는 방법입니다.

📌 명세기반 기법(Specification-based technique)

해결할 문제를 명세하기 위해 공식적이거나 비공식적인 모델을 사용합니다.
이러한 모델에서 테스트 케이스를 시스템적으로 도출하는 것이 가능합니다.
커버리지를 측정할 수 있지만 그 의미가 구조기반 기법의 커버리지에 비해 제한적입니다. (상태전이 커버리지, 결정 테이블 커버리지, 요구사항 커버리지 등)

동등 분할

대상의 입력값은 입력의 결과로 나타날 결과값이 동일한 경우 하나의 동등 분할 클래스로 간주하고 이 클래스 내 입력값은 내부적으로 같은 방식으로 처리 됨을 나타냅니다.
유효한 데이터, 잘못된 데이터, 거부할 데이터 모두에 가능합니다.
입력값 외에도 출력값, 시간값, 내부값, 인터페이스 파라미터 대해서도 정의 가능합니다.
입력값 또는 출력값에 대한 특정 커버리지를 달성하기 위해 사용됩니다.

경계값 분석

동등 분할의 경계 부분에 입력값에서 결함이 내부 입력 값에서보다 발견될 확률이 높다는 것을 이용하여 경계값도 포함하여 테스팅합니다.
해당 분할 영역의 최대값 최소값이 바로 경계값입니다.

결정 테이블 테스팅

결정 테이블은 논리적 조건이나 상황을 구현하는 시스템 요구사항을 도출하거나 내부 시스템 디자인을 문서화하는 유용한 도구입니다.
즉 비지니스 규칙을 문서로 만드는데 유용합니다.
결정 테이블 작성시 명세서를 분석하고 컨디션과 시스템의 조건은 식별됩니다.
즉 입력조건과 동작을 T/F로 나타내어 각 예상 결과, 심지어 조합에 대해서 예상 결과 까지 포함합니다.
테이블의 컬럼이 비지니스 규칙과 대응됩니다.
테이블의 컬럼은 조건의 조합을 정의합니다.
컬럼당 하나의 테스트 케이스를 생성합니다.

상태전이 테스팅

상태전이 다이어그램을 통해 표현합니다.
즉 상태와 상태 관계, 전이, 상태 전이를 일으키는 이벤트와 입력값, 상태 변화로 유발되는 동작을 정의합니다.
전형적인 상태의 순서를 커버하는 방식, 모든 상태를 커버하는 방식, 모든 상태전이를 실행하는 방식, 특정 상태전이를 실행하는 방식으로 나뉩니다.

유즈케이스 테스팅

유즈케이스는 액터와 액터 사이 상호작용, 해당 상호작용은 고객에게 결과값을 제공합니다.
성공적으로 수행하기 위해 전제 조건과 수행 완료 후 후속조건을 통해 종료됩니다.
시나리오, 대체 흐름, 기본 흐름으로 구성됩니다.
인수테스트를 설계할 때 유용합니다.

📌 구조 기반 기법

코드와 개발 설계 등의 소프트웨어 구현 정보를 기반으로 테스트 케이스를 도출합니다.
수행된 테스트 케이스를 바탕으로 테스트 커버리지를 측정할 수 있으며, 커버리지를 높이기 위해 테스트 케이스를 시스템적으로 도출해 추가할 수 있습니다.

❓ 커버리지(coverage) : 시스템 또는 소프트웨어의 구조가 테스트 스위트에 의해 테스트 된 정도
커버리지를 달성하는 테스팅 기법은 컴포넌트 테스트 이외의 다른 테스트 레벨에서도 활용가능합니다.
통합 테스팅에서는 모듈, 컴포넌트, 클래스가 특정 조건에 따른 인터페이스를 가지고 있을 경우, 시스템/인수 테스팅에서는 기능 또는 비즈니스 로직이 특정 조건에 따라 동작할때 동일한 기법을 응용하여 적용할 수 있습니다.

구문 테스팅과 커버리지

테스트 케이스 묶음에 의해 실행한 구문이 몇 퍼센트인지 측정합니다.

구문 테스팅은 구문 커버리지를 늘리기 위해 테스트 케이스를 도출합니다.

구문 커버리지 = 테스트 케이스가 커버하는 실행 가능 구문 수 / 테스트중 모든 실행 가능 구문의 수

결정 테스팅과 커버리지

분기문과 관련있습니다.
테스트 케이스 묶음에 의해 실행된 조건문 분기가 몇 퍼센트인지 측정합니다. ( if 구문의 참 거짓)
```
결정 커버리지 = 테스트 케이스가 커버하는 결과값들의 수 / 테스트중 모든 가능한 결과값의 수
```