학습 / 용어집
소프트웨어 테스트 용어집
QA 엔지니어와 SDET가 매일 쓰는 용어를 쉽게 풀어 설명합니다. 각 용어마다 예시와 함께 관련 레슨, 실습 랩, 면접 질문 링크를 제공합니다.
용어 77개 · 테스트 기초 26 · 테스트 설계 5 · UI 자동화 18 · API 테스트 8 · CI/CD와 DevOps 5 · 성능 5 · 보안 4 · 테스트 분야의 AI 6
테스트 기초
- 검증과 확인(V&V) Verification and validation 검증(verification)은 명세 기준으로 "제품을 올바르게 만들고 있는가?"를, 확인(validation)은 실제 요구 기준으로 "올바른 제품을 만들고 있는가?"를 묻습니다.
- 단위 테스트 Unit test 함수나 클래스 같은 작은 코드 단위를 데이터베이스, 네트워크, 다른 서비스와 격리한 상태에서 검사하는 자동화 테스트입니다.
- 리스크 기반 테스트 Risk-based testing 장애 발생 가능성과 영향도에 따라 테스트 노력의 우선순위를 정해, 가장 위험한 영역을 가장 먼저 가장 깊게 테스트하는 전략입니다.
- 뮤테이션 테스트(변이 테스트) Mutation testing 코드에 작은 버그(뮤턴트)를 의도적으로 심고 테스트를 다시 실행해, 테스트 스위트가 결함을 실제로 잡아내는지 측정하는 기법입니다.
- 버그 심각도 Bug severity 결함이 시스템이나 사용자에게 미치는 영향의 정도로, 전체 크래시나 데이터 손실부터 외관상 문제까지 나뉘며 보통 QA가 정합니다.
- 버그 우선순위 Bug priority 결함을 다른 작업에 비해 얼마나 시급하게 고쳐야 하는지를 비즈니스 관점에서 정한 것으로, 보통 프로덕트 오너나 버그 트리아지에서 결정합니다.
- 블랙박스 테스트 Black-box testing 내부 코드나 설계를 보거나 의존하지 않고, 요구사항을 기준으로 입력과 출력만으로 시스템을 테스트하는 방식입니다.
- 사용자 인수 테스트(UAT) User acceptance testing 실제 사용자나 현업 담당자가 시스템이 자신들의 요구를 충족하고 릴리스를 승인할 준비가 되었는지 확인하는 마지막 테스트 단계입니다.
- 새니티 테스트 Sanity testing 버그 수정이나 작은 변경 후, 해당 기능이 동작하고 주변 영역도 정상인지 빠르게 집중 확인하는 테스트입니다.
- 스모크 테스트 Smoke testing 새 빌드에 대해 핵심 기능을 넓고 얕게 빠르게 확인해, 더 자세히 테스트할 만큼 안정적인 빌드인지 판단하는 테스트입니다.
- 시프트 레프트 테스트 Shift-left testing 테스트와 품질 활동을 개발 주기의 앞쪽, 즉 요구사항·설계·개발 단계로 옮겨 결함을 더 일찍, 더 저렴하게 찾는 접근 방식입니다.
- 요구사항 추적 매트릭스(RTM) Requirements traceability matrix 각 요구사항을 이를 검증하는 테스트 케이스와 그 결과에 연결한 표로, 커버리지 공백과 변경의 영향 범위를 한눈에 보여 줍니다.
- 인수 조건 Acceptance criteria 사용자 스토리나 기능이 완료된 것으로 프로덕트 오너에게 인정받기 위해 충족해야 하는 구체적이고 테스트 가능한 조건입니다.
- 코드 커버리지 Code coverage 테스트 실행 중에 실행된 소스 코드(라인, 구문, 분기, 함수)의 비율로, 무엇이 잘 테스트되었는지가 아니라 무엇이 테스트되지 않았는지를 보여 줍니다.
- 탐색적 테스트 Exploratory testing 테스터가 테스트를 설계하고 실행하는 일을 동시에 하며, 각 결과에서 드러난 것을 바탕으로 다음에 무엇을 시도할지 정하는 테스트 방식입니다.
- 테스트 계획서 Test plan 릴리스나 프로젝트 테스트의 범위, 접근 방식, 자원, 일정, 환경, 리스크, 시작·종료 기준을 정의하는 문서입니다.
- 테스트 더블 Test double 테스트에서 실제 의존성을 대신하는 더미, 스텁, 페이크, 스파이, 목 같은 객체로, 테스트 대상 코드를 빠르고 예측 가능하게 실행하게 합니다.
- 테스트 시나리오 Test scenario "저장된 카드로 결제 확인"처럼 테스트할 사용자 목표나 기능을 상위 수준에서 한 줄로 기술한 것으로, 이후 테스트 케이스로 세분화됩니다.
- 테스트 오라클 Test oracle 명세, 이전 버전, 참조 모델, 규칙처럼 테스트가 출력의 정답 여부를 판단할 때 기준으로 삼는 진실의 원천입니다.
- 테스트 케이스 Test case 시스템의 한 가지 동작을 검증하기 위한 사전 조건, 입력 데이터, 단계, 기대 결과의 구체적인 조합으로, 명확한 통과·실패 판정을 냅니다.
- 테스트 피라미드 Test pyramid 빠른 단위 테스트를 바닥에 많이, 그 위에 통합 테스트를 적게, 꼭대기에 엔드투엔드 테스트를 소수 두어 자동화 스위트의 균형을 잡는 모델입니다.
- 통합 테스트 Integration test 서비스와 데이터베이스, 또는 두 API처럼 둘 이상의 컴포넌트가 실제 인터페이스를 통해 올바르게 함께 동작하는지 확인하는 테스트입니다.
- 플래키 테스트(Flaky Test) Flaky test 코드 변경이 없는데도 같은 코드에서 통과와 실패를 오가는 테스트로, 주로 타이밍, 공유 상태, 테스트 순서, 불안정한 환경 때문에 발생합니다.
- 화이트박스 테스트 White-box testing 분기, 조건, 경로 같은 내부 코드에 대한 지식을 바탕으로 설계해, 구현이 올바르게 동작하는지 확인하는 테스트입니다.
- 회귀 테스트 Regression testing 변경 후 기존 테스트를 다시 실행해 이미 동작하던 기능이 여전히 동작하는지, 수정이나 신규 기능이 다른 곳을 망가뜨리지 않았는지 확인하는 테스트입니다.
- E2E 테스트(엔드투엔드 테스트) End-to-end test 완전히 배포된 실제 시스템에서 UI나 공개 API부터 데이터베이스까지 전체 사용자 여정을 처음부터 끝까지 실행하는 테스트입니다.
테스트 설계
- 결정 테이블 테스트 Decision table testing 조건의 조합과 각 조합이 일으켜야 할 동작을 표로 정리해, 모든 비즈니스 규칙에 테스트가 하나씩 대응되도록 하는 테스트 설계 기법입니다.
- 경계값 분석 Boundary value analysis 유효 범위의 경계와 그 바로 주변 값을 테스트 입력으로 선택하는 블랙박스 테스트 설계 기법으로, off-by-one 결함이 몰리는 지점을 노립니다.
- 동등 분할 Equivalence partitioning 시스템이 똑같이 처리해야 하는 입력을 그룹으로 나누고, 각 그룹에서 대표값 하나씩만 테스트하는 테스트 설계 기법입니다.
- 상태 전이 테스트 State transition testing 시스템을 상태와 상태 사이를 이동시키는 이벤트로 모델링한 뒤, 유효한 전이와 유효하지 않은 전이를 테스트하는 테스트 설계 기법입니다.
- 페어와이즈 테스트 Pairwise testing 모든 파라미터 값의 쌍이 적어도 한 번은 함께 나타나도록 소수의 테스트 케이스를 고르는 조합 테스트 기법입니다.
UI 자동화
- 데이터 주도 테스트 Data-driven testing 같은 테스트 로직을 여러 입력과 기대 결과 세트로 실행하는 방식으로, 데이터를 각 테스트에 복사하지 않고 테이블, 파일, 데이터 소스에 보관합니다.
- 로케이터(Locator) Locator UI 테스트가 페이지에서 요소를 찾을 때 쓰는 쿼리로, 역할과 이름, 테스트 ID, CSS 셀렉터, XPath 식 등이 있습니다.
- 명시적 대기(Explicit Wait) Explicit wait 요소가 클릭 가능해지는 것처럼 특정 조건 하나를 타임아웃까지 폴링하며 기다리는 대기 방식으로, Selenium에서는 WebDriverWait로 작성합니다.
- 시각적 회귀 테스트 Visual regression testing UI 스크린샷을 승인된 기준 이미지와 비교해 레이아웃 틀어짐, 스타일 누락, 요소 겹침 같은 의도치 않은 시각적 변화를 잡아내는 테스트입니다.
- 암시적 대기(Implicit Wait) Implicit wait 모든 findElement 호출이 NoSuchElementException을 던지기 전에 정해진 시간까지 계속 폴링하게 만드는 Selenium의 전역 설정입니다.
- 웹 퍼스트 어설션 Web-first assertion 값을 한 번만 확인하지 않고, 로케이터를 받아 기대 조건이 충족되거나 타임아웃이 끝날 때까지 재시도하는 Playwright 어설션입니다.
- 자동 대기(Auto-waiting) Auto-waiting 고정된 sleep에 의존하지 않고, 요소가 표시·안정·활성화되는 등 준비될 때까지 기다린 뒤 동작을 수행하는 프레임워크 기능입니다.
- 테스트 격리 Test isolation 각 테스트가 자신의 상태를 직접 준비해 단독으로, 어떤 순서로든, 병렬로도 통과하며 다른 테스트에 의존하거나 영향을 주지 않는 성질입니다.
- 테스트 샤딩 Test sharding 테스트 스위트를 샤드(shard)라는 조각으로 나눠 여러 머신에서 동시에 실행해, 긴 스위트를 훨씬 짧은 시간에 끝내는 기법입니다.
- 테스트 픽스처 Test fixture 브라우저 페이지, 미리 생성한 사용자, 데이터베이스처럼 테스트 실행 전에 필요한 고정된 준비 상태와 실행 후 정리 작업을 말합니다.
- 페이지 객체 모델(POM) Page Object Model UI의 각 페이지나 컴포넌트를 클래스로 감싸, 테스트가 로케이터를 반복하지 않고 의도를 드러내는 메서드를 호출하게 하는 디자인 패턴입니다.
- 행위 주도 개발(BDD) Behavior-Driven Development 비즈니스, 개발, 테스트가 구체적인 예시로 동작을 합의하고, 이를 주로 Gherkin으로 작성해 자동화하는 협업 방식입니다.
- 헤드리스 브라우저 Headless browser 화면에 창을 띄우지 않고 실행되는 실제 브라우저 엔진으로, 디스플레이가 없는 CI 서버 등에서 UI 테스트를 실행할 때 사용합니다.
- CSS 셀렉터 CSS selector 태그, id, 클래스, 속성, 위치로 요소를 찾는 CSS 언어의 패턴으로, 빠르고 읽기 쉬운 UI 테스트 로케이터로 널리 쓰입니다.
- Gherkin(거킨) Gherkin .feature 파일에 BDD 시나리오를 작성할 때 쓰는 Given-When-Then 형식의 평문 문법으로, Cucumber 같은 도구가 자동화 테스트로 실행합니다.
- Selenium Grid Selenium 테스트를 원격 머신의 브라우저로 보내 여러 브라우저와 OS에서 병렬로 실행할 수 있게 해 주는 서버입니다.
- StaleElementReferenceException 찾아 둔 WebElement의 DOM 노드가 재렌더링 등으로 제거·교체된 뒤 테스트가 그 요소를 사용할 때 Selenium이 던지는 예외입니다.
- XPath XML이나 HTML 문서에서 노드를 선택하는 쿼리 언어로, UI 자동화에서 구조·속성·텍스트로 요소를 찾는 데 사용합니다.
API 테스트
- 계약 테스트 Contract testing API 제공자와 소비자가 주고받는 요청과 응답에 합의하고 있는지를, 둘을 함께 배포해 E2E 테스트하지 않고 검증하는 테스트입니다.
- 레이트 리미팅(Rate Limiting) Rate limiting 클라이언트가 일정 시간 동안 API에 보낼 수 있는 요청 수를 제한하고, 초과 요청은 보통 429 Too Many Requests와 Retry-After 헤더로 거부하는 방식입니다.
- 멱등성 Idempotency 같은 요청을 한 번 보내든 여러 번 보내든 서버가 같은 상태로 남는 성질로, GET, PUT, DELETE는 멱등하고 POST는 멱등하지 않습니다.
- HTTP 상태 코드 HTTP status code 모든 HTTP 응답에 포함된 세 자리 숫자로, 요청이 성공했는지, 리디렉션되었는지, 클라이언트나 서버 문제로 실패했는지를 알려 줍니다.
- JSON Schema(JSON 스키마) JSON Schema 타입, 필수 필드, 형식 등 JSON 데이터가 가져야 할 구조를 기술하는 JSON 어휘로, API 응답을 검증하는 데 사용합니다.
- JWT(JSON Web Token) JWT header.payload.signature 형태의 간결한 서명 토큰으로, 사용자 ID, 만료 시간, 대상(audience) 같은 클레임을 담는 JSON Web Token입니다.
- OAuth 2.0 애플리케이션이 비밀번호를 다루지 않고도 사용자나 자기 자신을 대신해 API를 호출할 수 있도록 제한된 액세스 토큰을 발급받게 하는 인가 프레임워크입니다.
- REST API URL로 식별되는 리소스를 GET, POST, PUT, PATCH, DELETE 같은 표준 메서드로 다루며, 요청마다 상태를 유지하지 않는 HTTP API 설계 방식입니다.
CI/CD와 DevOps
- 지속적 통합(CI) Continuous integration 작은 변경을 공유 브랜치에 자주 병합하고, 푸시할 때마다 자동으로 빌드와 테스트를 실행해 문제를 몇 분 안에 드러내는 개발 방식입니다.
- 품질 게이트 Quality gate 테스트 통과나 기준 이상의 커버리지처럼, 코드를 머지하거나 배포하기 전에 반드시 통과해야 하는 파이프라인의 자동 합격/불합격 검사입니다.
- 피처 플래그 Feature flag 배포 없이 런타임에 코드 경로를 켜고 끄는 스위치로, 미완성 기능을 숨긴 채 배포하고 점진적으로 출시하며 빠르게 롤백할 수 있게 합니다.
- Docker 컨테이너 Docker container 앱이나 서비스를 의존성과 함께 패키징한 Docker 이미지의 격리된 실행 인스턴스로, 노트북에서도 CI에서도 똑같이 동작합니다.
- Testcontainers 데이터베이스, 메시지 브로커, 브라우저 같은 실제 의존성을 테스트 코드에서 일회용 Docker 컨테이너로 띄우고 끝나면 제거하는 라이브러리입니다.
성능
- 백분위 지연 시간(p95·p99) Percentile latency p95나 p99처럼 해당 비율의 요청이 그 시간 안에 완료되었음을 나타내는 응답 시간 지표로, 평균이 가리는 느린 꼬리 구간을 드러냅니다.
- 부하 테스트 Load testing 시스템에 실제로 예상되는 트래픽을 걸어 응답 시간, 오류율, 처리량이 합의된 목표를 충족하는지 확인하는 성능 테스트입니다.
- 소크 테스트(내구성 테스트) Soak testing 평상시 수준의 부하를 몇 시간 이상 지속적으로 걸어 메모리 누수, 자원 고갈, 점진적인 성능 저하를 찾아내는 성능 테스트입니다.
- 스트레스 테스트 Stress testing 예상 수준을 넘는 부하를 가해 한계점을 찾고, 시스템이 어떻게 실패하며 이후 정상으로 복구되는지 확인하는 성능 테스트입니다.
- 처리량(Throughput) Throughput 시스템이 단위 시간당 처리하는 작업량으로, 보통 초당 요청 수나 트랜잭션 수로 나타내며 지연 시간·오류율과 함께 측정합니다.
보안
- 크로스 사이트 스크립팅(XSS) Cross-site scripting 신뢰할 수 없는 입력이 다른 사용자의 브라우저에서 실행 가능한 스크립트로 렌더링되어, 공격자가 그 사용자인 척 행동할 수 있게 되는 취약점입니다.
- IDOR(안전하지 않은 직접 객체 참조) IDOR 요청의 ID만 바꾸면 다른 사용자의 데이터를 읽거나 수정할 수 있게 되는 접근 제어 결함으로, Insecure Direct Object Reference의 약자입니다.
- OWASP Top 10 OWASP가 발표하는 가장 치명적인 웹 애플리케이션 보안 위험 10개 범주 목록으로, 보안 테스트와 코드 리뷰의 범위를 정하는 데 널리 쓰입니다.
- SQL 인젝션 SQL injection 사용자 입력이 SQL 쿼리에 그대로 이어 붙여져 공격자가 쿼리 로직을 바꿔 데이터를 조회·변경·삭제할 수 있는 취약점입니다.
테스트 분야의 AI
- 골든 데이터셋 Golden dataset 검증된 기대 출력과 짝을 이룬 입력을 선별하고 버전 관리하는 데이터셋으로, 모델·프롬프트·파이프라인 회귀 테스트의 고정 벤치마크로 씁니다.
- 셀프 힐링 로케이터 Self-healing locator 원래 로케이터가 요소를 찾지 못하면 저장된 속성 정보로 가장 비슷한 요소를 찾아 대신 사용하는 UI 테스트 로케이터입니다.
- 프롬프트 인젝션 Prompt injection 사용자가 직접 입력하거나 LLM이 읽는 콘텐츠에 숨겨진 텍스트가 개발자의 지시를 덮어써 모델의 동작을 바꾸는 공격입니다.
- LLM 평가(LLM Evaluation) LLM evaluation 출력이 매번 달라 정확한 어설션이 맞지 않는 LLM 기반 기능의 품질을, 고정된 입력 세트와 기준으로 체계적으로 측정하는 것입니다.
- LLM-as-judge(LLM 심사) LLM-as-judge 작성된 루브릭에 따라 언어 모델이 다른 모델의 출력을 채점하게 하는 방식으로, 확장성은 높지만 편향이 있는 사람 검토의 대체 수단입니다.
- MCP(Model Context Protocol) Model Context Protocol MCP는 AI 어시스턴트와 에이전트를 브라우저, 저장소, 테스트 관리 시스템 같은 외부 도구와 데이터에 연결하는 개방형 프로토콜입니다.