테스트 유형(test type)은 테스트 대상의 특정 특성에 초점을 맞춘 테스트다.[1][2] ISO/IEC/IEEE 29119-1:2022는 테스트 유형을 특정 품질 특성에 초점을 둔 테스트로 정의하고, 보안 테스트, 기능 테스트, 사용성 테스트, 성능 테스트를 예로 든다. 이 정의의 Note는 테스트 유형을 한 테스트 레벨에서 수행할 수도, 여러 테스트 레벨에 걸쳐 수행할 수도 있다고 제시하고, 단위 테스트 레벨과 시스템 테스트 레벨에서 수행하는 성능 테스트를 예로 든다.[1]
CTFL의 네 유형
ISTQB CTFL 강의계획서는 많은 테스트 유형 가운데 네 유형을 다룬다.[3]
| 유형 | 내용 | 주목표 |
|---|---|---|
| 기능 테스트 | 컴포넌트나 시스템이 수행해야 할 기능, 곧 테스트 대상이 “무엇을” 하는지를 평가한다. | 기능 완전성, 기능 정확성, 기능 적절성의 확인 |
| 비기능 테스트 | 컴포넌트나 시스템의 기능 특성이 아닌 속성, 곧 시스템이 “얼마나 잘” 동작하는지를 평가한다. | 비기능 품질 특성의 확인 |
| 블랙박스 테스트 | 명세에 바탕을 두고, 테스트 대상의 내부 구조와 관계없는 문서에서 테스트를 끌어낸다. | 시스템의 동작을 명세에 비추어 확인하는 것 |
| 화이트박스 테스트 | 구조에 바탕을 두고, 시스템의 구현이나 내부 구조에서 테스트를 끌어낸다. | 테스트로 밑바탕 구조를 받아들일 만한 수준까지 덮는 것 |
네 유형은 모든 테스트 레벨에 쓸 수 있지만 레벨마다 초점이 다르다.[3]
비기능 테스트
ISTQB 용어집은 비기능 테스트(non-functional testing)를 컴포넌트나 시스템이 비기능 요구사항을 지키는지 평가하는 테스트 유형으로 정의한다.[4]
CTFL 강의계획서에 따르면 비기능 테스트는 소프트웨어 개발 생명주기 초기에, 예를 들어 리뷰나 컴포넌트 테스트의 일부로 시작하는 것이 알맞을 때가 있다. 많은 비기능 테스트는 기능 테스트를 그대로 쓰되, 기능을 수행하는 동안 비기능 제약이 지켜지는지 확인하는 식으로 기능 테스트에서 끌어낸다. 예를 들어 기능이 정해진 시간 안에 수행되는지 확인한다. 비기능 결함을 늦게 발견하면 프로젝트의 성공을 크게 위협할 수 있고, 비기능 테스트에는 사용성 테스트를 위한 사용성 실험실처럼 아주 특정한 테스트 환경이 필요하기도 하다.[3]
ISO/IEC/IEEE 29119-1이 정의하는 테스트 유형
ISO/IEC/IEEE 29119-1:2022는 다음 테스트 유형을 정의한다.[1]
| 테스트 유형 | 평가하는 것 |
|---|---|
| 성능 테스트(performance testing) | 테스트 항목이 시간과 다른 자원의 주어진 제약 안에서 지정된 기능을 해내는 정도를 평가한다. |
| 부하 테스트(load testing) | 성능 테스트의 한 유형으로, 예상한 부하가 대개 낮은 사용, 보통 사용, 최대 사용 사이에서 바뀌는 조건에서 테스트 항목의 동작을 평가한다. |
| 스트레스 테스트(stress testing) | 성능 효율 테스트의 한 유형으로, 예상하거나 명시한 용량 요구를 넘는 부하나, 명시한 최소 요구에 못 미치는 자원 가용성 조건에서 테스트 항목의 동작을 평가한다. |
| 신뢰성 테스트(reliability testing) | 테스트 항목을 명시한 조건에서 정해진 기간 동안 쓸 때 요구 기능을 수행하는 능력을 평가한다. failure가 일어나는 빈도의 평가도 포함한다. |
| 호환성 테스트(compatibility testing) | 테스트 항목이 공유 환경에서 다른 독립 제품과 함께 제대로 동작하는지(공존성), 그리고 필요하면 다른 시스템이나 컴포넌트와 정보를 주고받는지(상호운용성)를 본다. |
| 보안 테스트(security testing) | 허가받지 않은 사람이나 시스템은 테스트 항목과 관련 데이터·정보를 쓰거나 읽거나 고치지 못하고, 허가받은 사람이나 시스템은 접근을 거부당하지 않도록 보호되는 정도를 평가한다. |
| 유지보수성 테스트(maintainability testing) | 테스트 항목을 고칠 수 있는 효과성과 효율성의 정도를 평가한다. |
| 이식성 테스트(portability testing) | 테스트 항목을 한 하드웨어나 소프트웨어 환경에서 다른 환경으로 옮기기 쉬운 정도를 평가한다. 여러 환경에서 실행하려고 고쳐야 하는 정도도 포함한다. |
품질 특성별 초점
ISTQB CTAL-TA(Certified Tester Advanced Level Test Analyst) 강의계획서는 ISO/IEC 25010:2023의 품질 모델을 길잡이로 삼아, 테스트 분석가가 초점을 두는 품질 특성의 테스트를 다음처럼 다룬다.[5]
| 테스트 | 초점 |
|---|---|
| 기능 테스트 | 기능 적합성의 세 부특성을 다룬다. 기능 완전성 테스트는 요구한 것이 모두 구현됐는지, 기능 정확성 테스트는 유효한 입력과 무효한 입력에서 실제 결과가 맞는지, 기능 적절성 테스트는 구현한 것이 사용자의 요구를 채우는지 본다. |
| 사용성 테스트 | 대개 상호작용 능력(interaction capability), 사용자 경험, 접근성을 평가한다. |
| 이식성 테스트(flexibility testing, portability testing이라고도 부른다) | 테스트 대상이 사용 맥락이나 시스템 환경의 변화에 맞춰질 수 있는지 검증한다. 부특성은 적응성(adaptability), 확장성(scalability), 설치성(installability), 대체성(replaceability)이다. |
| 호환성 테스트 | 상호운용성 테스트와 공존 테스트로 나눌 수 있다. 상호운용성 테스트는 테스트 대상이 함께 동작하도록 의도한 컴포넌트나 시스템과 호환되는지 검증하며, 대개 블랙박스 기능 테스트다. 공존 테스트는 다른 컴포넌트나 시스템과 목표 환경을 간섭 없이 함께 쓸 수 있는지 검증한다. |
신뢰성 테스트와 운용 프로파일
ISTQB 용어집은 운용 프로파일(operational profile)을 컴포넌트나 시스템의 실제 사용 패턴이나 예측한 사용 패턴으로 정의한다.[6]
SWEBOK V4.0a에 따르면 신뢰성 테스트는 결함을 찾아 고치며 테스트 대상의 신뢰성을 평가한다. 운용 중인 테스트 대상을 관찰하거나, 여러 사용자의 행동을 나타낸 통계 모델인 운용 프로파일에 따라 테스트 케이스를 실행한다. 운용 프로파일에 바탕을 둔 테스트는 테스트 대상의 신뢰성을 추정할 테스트 케이스를 만들어, 관찰한 테스트 결과에서 소프트웨어를 쓸 때의 신뢰성을 추론하려는 것이다. 추정한 신뢰성은 운용 프로파일에 크게 좌우되므로, 이 접근의 주된 어려움과 비용은 운용 프로파일을 끌어내는 데서 온다. 한 가지 해법은 실제 운용에서 일어나는 빈도에 따라 입력에 확률이나 프로파일을 매기는 것이다.[7]
ISTQB 용어집은 신뢰성 성장 모델(reliability growth model)을 결함을 없앤 결과로 컴포넌트나 시스템의 신뢰성이 시간에 따라 높아지는 것을 보이는 모델로 정의한다.[8] SWEBOK V4.0a에 따르면 신뢰성 테스트에서 신뢰성은 대개 신뢰성 성장 모델로 평가한다. 발표된 신뢰성 성장 모델이 많으며, 크게 failure-count 모델과 time-between-failure 모델로 나뉜다.[7] 결함을 고칠 때 일정한 확률로 새 결함이 들어갈 수 있다고 가정해, 수정이 불완전한 경우를 받아들이는 신뢰성 성장 모델도 있다.[9]
테스트 사분면
ISTQB 용어집은 테스트 사분면(testing quadrants)을 테스트 유형과 테스트 레벨을 네 사분면으로 나누는 분류 모델로 정의한다. 사분면은 테스트 목표의 두 차원, 곧 제품 팀을 지원하는지 제품을 비평하는지와, 기술 쪽인지 비즈니스 쪽인지에 따라 정해진다.[10]
CTFL 강의계획서에 따르면 테스트 사분면은 Brian Marick이 정의한 것으로, 애자일 소프트웨어 개발에서 테스트 레벨을 알맞은 테스트 유형, 활동, 테스트 기법, 작업 산출물과 묶는다. 이 모델은 테스트 관리에서 알맞은 테스트 유형과 테스트 레벨이 개발 생명주기에 모두 들었는지 보이게 하고, 어떤 테스트 유형이 특정 테스트 레벨에 더 관련 있다는 것을 이해하는 데 쓴다. 개발자, 테스터, 비즈니스 대표를 비롯한 모든 이해관계자에게 테스트 유형을 구분해 설명하는 방법도 준다.[3]
테스트는 비즈니스 쪽(business facing)이거나 기술 쪽(technology facing)이고, 팀을 지원하거나(support the team, 곧 개발을 이끔) 제품을 비평한다(critique the product, 곧 동작을 기대에 비추어 잰다). 두 관점을 엮으면 네 사분면이 정해진다.[3]
Q1(기술 쪽, 팀 지원)에는 컴포넌트 테스트와 컴포넌트 통합 테스트가 들고, 이 테스트는 자동화해 지속적 통합 과정에 넣어야 한다. Q2(비즈니스 쪽, 팀 지원)에는 기능 테스트, 예제, 사용자 스토리 테스트, 사용자 경험 프로토타입, API 테스트, 시뮬레이션이 들고, 인수 기준을 확인하며 수동이나 자동으로 한다. Q3(비즈니스 쪽, 제품 비평)에는 탐색적 테스트, 사용성 테스트, 사용자 인수 테스트가 들고, 사용자 중심이며 흔히 수동으로 한다. Q4(기술 쪽, 제품 비평)에는 스모크 테스트, 그리고 사용성 테스트를 뺀 비기능 테스트가 들고, 흔히 자동화한다.[3]