시험 분석 및 시험의 기초
토마스 해밀턴
⚡ 스마트 요약
테스트 분석(테스트 기초라고도 함)은 요구사항, 설계 문서 및 기타 산출물을 체계적으로 검토하여 테스트 가능한 조건을 도출하는 과정입니다. 이 글에서는 테스트 분석의 출처, 단계별 워크플로, 그리고 V-모델에서의 위치를 설명합니다.
테스트 분석(테스트 기초라고도 함)은 테스트 수명 주기의 맨 처음 단계에 있습니다. 모든 테스트 조건과 테스트 케이스는 궁극적으로 이 단계에 기반합니다. trac다시 그 주제로 돌아갑니다. 아래 섹션에서는 해당 용어를 정의하고, 출처를 설명하고, 분석 워크플로를 안내하고, V-모델에 적용하는 방법을 설명합니다.
시험 분석이란 무엇인가요?
테스트 분석 소프트웨어 테스트에서 입력값 검토는 테스트 조건과 테스트 케이스를 도출하는 데 사용되는 입력값을 검토하는 과정입니다. 이러한 입력값, 즉 명세, 요구사항, 설계 문서, 사용자 스토리 및 유사한 산출물들을 통틀어 입력값 검토라고 합니다. 테스트 아티팩트테스트 분석의 목표는 다음과 같습니다.trac테스트 목표는 각각 명확한 테스트 조건으로 변환될 수 있을 만큼 충분히 명확해야 합니다. 분석된 자료는 모든 테스트가 도출되는 기초를 형성하기 때문에 이러한 용어로도 불립니다. 테스트 기반.
테스터가 테스트 정보를 얻는 일반적인 출처는 다음과 같습니다.
- SRS — 소프트웨어 요구사항 명세
- BRS — 비즈니스 요구사항 명세
- 기능적 디자인 문서
- 사용자 스토리, 승인 기준 및 와이어프레임
테스터는 테스트 대상 애플리케이션을 직접 탐색하거나 과거 경험을 활용하여 테스트 조건을 생성할 수도 있지만, 대부분의 경우 테스트 케이스 테스트 결과물에서 파생되어 유지 관리됩니다. trac능력.
👉 무료 라이브 소프트웨어 테스팅 프로젝트에 등록하세요
테스트 기반 접근 방식이 중요한 이유는 무엇일까요?
테스트 기준은 테스트 스위트가 실제 결함을 잡아낼지 아니면 허구의 결함을 찾아낼지를 결정하는 가장 중요한 요소입니다. 테스트 기준을 선택 사항으로 취급하는 것이 버그가 프로덕션 환경으로 넘어가는 가장 흔한 원인입니다. 견고한 테스트 분석은 다음과 같은 네 가지 구체적인 이점을 제공합니다.
- 추적성: 모든 테스트 케이스는 특정 요구사항과 연결될 수 있으므로 변경 영향 분석이 신속하고 감사 검토가 간편합니다.
- 보도 내용 명확성: Rev기본 표면 검토를 통해 지정되지 않은 오류 상태, 누락된 예외 상황, 정의되지 않은 비기능적 임계값과 같은 격차를 프로덕션 환경에서 문제가 발생하기 전에 파악할 수 있습니다.
- 이해 관계자 정렬: 테스트 팀이 개발 팀이 빌드에 사용하는 동일한 문서에서 조건을 도출할 때, 양측은 "완료"에 대한 공통된 정의를 갖게 됩니다.
- 초기 결함 감지: 요구사항상의 결함(모호성, 모순, 누락된 승인 기준)은 코드를 작성하기 훨씬 전인 테스트 분석 단계에서 많이 발견됩니다. 따라서 테스트 분석 단계는 이러한 결함을 수정하는 데 가장 비용이 적게 드는 단계입니다.
시험 근거의 일반적인 출처
다양한 산출물은 다양한 테스트 수준에 활용됩니다. 테스트 케이스를 작성할 때 어떤 문서를 참조해야 할지 빠르게 결정하려면 아래 표를 활용하세요.
| 소스 아티팩트 | 최고의 적합 대상 | 당신이 전하는 것tract |
|---|---|---|
| 비즈니스 요구 사항 사양(BRS) | 인수 테스트 및 시스템 테스트 | 엔드투엔드 비즈니스 규칙, 규제 제약, 성공 기준 |
| 소프트웨어 요구 사항 사양(SRS) | 시스템 테스트 | 측정 가능한 임계값을 포함하는 기능적 및 비기능적 요구사항 |
| 기능/기술 설계 문서 | 통합 테스트 | 모듈 인터페이스, 데이터 흐름, 오류 처리 사양 |
| 사용자 스토리 및 승인 기준 | 애자일 스프린트 테스트 | 행동 기대치를 "주어진 조건-조건-그러면" 형식으로 표현 |
| 와이어프레임 및 UI 목업 | UI/사용성 테스트 | 레이아웃, 탐색, 입력 유효성 검사 규칙 |
| 테스트 대상 애플리케이션 (탐색적) | 탐색적 테스트 및 회귀 테스트 | 문서화되지 않은 동작, 실제 워크플로, 예외 상황 |
테스트 분석을 단계별로 수행하는 방법
효과적인 테스트 분석은 프로젝트 규모나 방법론에 관계없이 반복 가능한 5단계 워크플로를 따릅니다.
- 시험 기준을 수집하고 목록화하십시오. 의도된 동작을 설명하는 모든 자료(SRS, BRS, 설계 문서, 사용자 스토리, 목업 등)를 수집하세요. 각 요구사항이 어떤 문서에 속하는지 기록해 두세요. trac안정성은 그대로 유지됩니다.
- Rev테스트 가능성을 위한 검토. 각 산출물을 읽을 때 다음 세 가지 질문을 염두에 두세요. 이 설명은 측정 가능한가요? 모호하지 않나요? 완전한가요? 이 세 가지 조건 중 하나라도 충족하지 못하는 요구사항은 표시해 두고, 테스트를 작성하기 전에 작성자에게 다시 문의하세요.
- 테스트 조건을 파악합니다. 테스트 가능한 모든 명제에 대해 검증이 필요한 조건(긍정 경로, 부정 경로, 경계값, 오류 처리, 보안, 성능)을 나열하십시오. 테스트 조건은 절대적인 기준입니다.tract “무엇” — 예를 들면, "수량이 0인 주문은 시스템에서 거부됩니다." — 테스트 케이스의 구체적인 "방법"과는 구별됩니다.
- 질환의 우선순위를 정하고 그룹화하세요. 각 조건을 위험도와 사용 빈도에 따라 분류합니다. 위험도가 높고 사용 빈도가 높은 조건에는 상세한 분석을 제공하고, 위험도가 낮은 조건은 통합하거나 샘플링하여 분석할 수 있습니다. 또한, 자동화 대상 조건을 결정하는 단계이기도 합니다.
- 조건을 테스트 케이스로 변환합니다. 우선순위가 높은 각 조건은 하나 이상이 됩니다. 테스트 케이스 사전 조건, 단계, 테스트 데이터 및 예상 결과를 포함합니다. 요구 사항을 유지 관리합니다. trac모든 테스트 케이스를 해당 요구사항과 연결하는 가능성 매트릭스.
이 순서를 따르면 가장 흔한 테스트 분석 오류, 즉 명확한 근거 없이 테스트 케이스를 작성하는 것, 부정적인 시나리오를 놓치는 것, 결함 분류 과정에서 요구 사항과 연결할 수 없는 테스트를 생성하는 것을 방지할 수 있습니다.
V-모델에서의 테스트 분석
V-모델은 모든 개발 활동을 해당 테스트 활동과 짝지어줍니다. 테스트 분석은 개발 수명주기의 각 단계에서 해당 시점에 사용 가능한 문서를 활용하여 수행됩니다.
그림 1: 단계별 테스트 분석 V-모델.
사례 연구: 고객 요구사항으로부터 테스트 케이스 도출하기
고객이 다음과 같은 한 줄짜리 요구사항을 보낸다고 가정해 보겠습니다.
Client requirement: Add search functionality to an eCommerce Store
애플리케이션이 아직 개발되지 않았더라도 테스터는 요구사항이 암시하는 바를 분석하여 여러 테스트 조건을 도출할 수 있습니다. 여기에는 정상적인 동작과 클라이언트가 명시적으로 언급하지 않은 오류 발생 가능성이 모두 포함됩니다. 몇 가지 예는 다음과 같습니다.
- 키워드를 입력하지 않았을 때의 검색 결과를 확인하십시오.
- 입력한 키워드와 일치하는 제품이 없을 경우 검색 결과를 검증하십시오.
- 키워드에 대해 일치하는 제품이 여러 개 있는 경우 검색 결과를 검증하십시오.
- 특수 문자, 앞뒤 공백, 그리고 매우 긴 입력값에 대한 동작을 검증하십시오.
- 대소문자 구분 및 부분 일치 동작을 확인합니다.
- 예상 사용자 부하 조건에서 검색 응답 시간을 확인하십시오.
테스터는 클라이언트 요구사항(테스트 근거)을 받아 분석하고, 이를 테스트 조건으로 변환합니다. 이러한 패턴은 V-모델의 각 단계에서 반복되며, 테스트 계획과 테스트 케이스는 해당 단계에서 사용 가능한 문서를 활용하여 생성됩니다.
영상: 시험 분석 설명
동영상이 로드되지 않으면 바로 시청하세요. YouTube.
