validation testing ultimate guide
검증 테스트의 중요성 살펴보기 :
학습 내용 :
검증 테스트 란 무엇입니까?
유효성 검사 테스트는 테스트 및 개발 된 소프트웨어가 클라이언트 / 사용자 요구를 충족하는지 확인하는 프로세스입니다. 비즈니스 요구 사항 논리 또는 시나리오를 자세히 테스트해야합니다. 애플리케이션의 모든 중요 기능을 여기서 테스트해야합니다.
테스터로서 제공된 비즈니스 로직 또는 시나리오를 확인하는 방법을 아는 것은 항상 중요합니다. 기능을 자세히 평가하는 데 도움이되는 방법 중 하나는 유효성 검사 프로세스입니다.
검증 테스트를 수행하라는 요청을받을 때마다 사용자 요구 사항에 따라 모든 중요한 비즈니스 요구 사항을 테스트해야하므로 큰 책임이 따릅니다. 사용자가 요구하는 요구 사항을 단 한 번도 놓치면 안됩니다. 따라서 검증 테스트에 대한 예리한 지식이 매우 중요합니다.
테스터는 테스트 실행 결과가 요구 사항 문서에 언급 된 내용을 준수하는지 평가해야합니다. 모든 편차는 즉시보고해야하며 그 편차를 버그라고합니다.
HP Quality Centre, Selenium, Appium 등과 같은 도구를 사용하여 검증 테스트를 수행하고 여기에 테스트 결과를 저장할 수 있습니다. 적절한 테스트 계획, 테스트 실행 실행, 결함 보고서, 보고서 및 메트릭은 제출해야 할 중요한 결과물입니다.
회사 관점에서 간단하게 검증 테스트는 다음 단계에 따라 수행됩니다.
- 최종 사용자로부터 유효성 검사 테스트를위한 비즈니스 요구 사항을 수집합니다.
- 사업 계획을 준비하고 관련 현장 / 이해 관계자에게 승인을 위해 보냅니다.
- 계획이 승인되면 필요한 테스트 케이스를 작성하고 승인을 위해 보냅니다.
- 승인되면 필요한 소프트웨어, 환경으로 테스트를 완료하고 클라이언트가 요청한대로 결과물을 보냅니다.
- 결과물 승인시 클라이언트가 UAT 테스트를 수행합니다.
- 그 후 소프트웨어가 생산됩니다.
블랙 박스 테스트 란 무엇인가요?
이제 유효성 검사에 대해 자세히 살펴 보겠습니다.
검증과 검증의 차이점
간단한 예를 들어 이해합시다.
예:
클라이언트 요구 사항 :
제안 된 주사의 무게는 2cm를 넘지 않아야합니다.
검증 테스트 :
- 체크리스트, 검토 및 디자인을 사용하여 주입이 2cms를 초과하지 않는 주입인지 확인합니다.
검증 테스트 :
- 수동 또는 자동 테스트를 사용하여 주사의 무게가 2cm를 초과하지 않는지 확인합니다.
- 적절한 테스트 방법 (기능 및 비 기능적 방법)을 사용하여 사출 중량과 관련된 가능한 모든 시나리오를 확인해야합니다.
- 2cm 미만 및 2cm 이상 측정을 확인하십시오.
| 확인 | 확인 |
|---|---|
| 프로세스는 디자인, 코드 및 프로그램을 확인합니다. | 코드를 포함한 전체 제품을 평가해야합니다. |
| 검토, 연습, 검사 및 데스크 확인이 포함됩니다. | 기능적 및 비 기능적 테스트 방법이 포함됩니다. 제품에 대한 심층 점검이 완료되었습니다. |
| 사양으로 소프트웨어를 확인합니다. | 소프트웨어가 사용자 요구를 충족하는지 확인합니다. |
관련된 단계
- 디자인 자격 : 여기에는 비즈니스 요구 사항에 따라 테스트 계획을 만드는 것이 포함됩니다. 모든 사양은 명확하게 언급되어야합니다.
- 설치 자격 : 여기에는 요구 사항에 따른 소프트웨어 설치가 포함됩니다.
- 운영 자격 : 여기에는 사용자 요구 사항 사양에 따른 테스트 단계가 포함됩니다.
여기에는 다음이 포함될 수 있습니다. 기능 테스트 :
-
- 단위 테스트 – 블랙 박스, 화이트 박스, 그레이 박스.
- 통합 테스트 – 하향식, 상향식, 빅뱅.
- 시스템 테스트 – 온 전성, 연기 및 회귀 테스트.
- 성능 자격 : UAT (User Acceptance testing) - 알파 및 베타 테스트.
- 생산
디자인 자격
디자인 자격은 단순히 사용자 사양을 충족하는 방식으로 소프트웨어 디자인을 준비해야 함을 의미합니다. 주로 당신은 얻을 필요가 사용자 요구 사항 사양 (URS) 문서 클라이언트로부터 디자인을 진행합니다.
테스트 전략 :
이 문서는 테스트 계획을 준비하기위한 기반을 형성합니다. 일반적으로 프로젝트의 팀장 또는 관리자가 준비합니다. 테스트를 진행하고 원하는 목표를 달성하는 방법을 설명합니다.
모든 절차를 통합하려면 적절한 계획을 설계하고 이해 관계자의 승인을 받아야합니다. 따라서 테스트 계획의 구성 요소를 알려주십시오.
일부 프로젝트에서는 테스트 계획과 테스트 전략을 단일 문서로 통합 할 수 있습니다. 복잡한 프로젝트 (주로 자동화 기술)를위한 별도의 전략 문서도 준비됩니다.
검증 테스트 계획의 구성 요소 :
- 프로젝트 설명
- 요구 사항 이해
- 테스트 범위
- 테스트 수준 및 테스트 일정
- 계획 생성 실행
- 하드웨어 소프트웨어 및 인력 요구 사항
- 역할과 책임
- 가정 및 종속성
- 위험 및 완화
- 보고서 및 지표
프로젝트 설명 : 여기에서 테스트를 위해 부여 된 응용 프로그램에 대한 모든 설명을 설명해야합니다. 앱의 모든 기능을 포함해야합니다.
요구 사항 이해 : USR을 받으면 이해 한 요구 사항을 귀하 측에서 언급해야합니다. 설명이있는 경우이를 제기 할 수도 있습니다. 이것은 테스트를위한 기본 또는 테스트 기준입니다.
테스트 범위 : 범위에는 상위 수준의 기능과 함께 세부적인 모듈이 포함되어야합니다. 테스트에서 다루는 모든 요구 사항을 고객에게 알려야합니다.
비즈니스 관점에서 응용 프로그램의 중요한 요구 사항을 수행하기 위해 유효성 검사 테스트를 요청할 수 있습니다. 단순히 보장 할 내용과 그렇지 않은 내용을 말합니다. .
테스트 수준 및 테스트 일정 : 몇 번의 테스트를 수행해야하는지 언급해야합니다. 테스트 프로젝트에 대한 전반적인 노력은 테스트 케이스 포인트 (TCP) 추정 등과 같은 표준 추정 기법을 사용하여 추정됩니다.
이름에서 알 수 있듯이 시험 일정 테스트가 수행되는 방법을 설명합니다. 또한 승인 및 검토가 수행되는 방법과시기를 명시해야합니다.
예:
웹 페이지의 디자인은 고려되는 프로젝트입니다.
테스트 수준은 다음과 같습니다.
레벨 1: 연기 테스트
2 단계: 단위 테스트
레벨 3 : 통합 테스트
레벨 3 : 시스템 테스트
레벨 3 : 수락 테스트
시험 일정 :
- 계획 제출 – 1 일차
- 테스트 케이스 설계 – 2 일차
- 드라 이런 및 버그 수정 – 4 일차
- 리뷰- 5 일차
- 공식 실행 – 6 일차
- 승인을 위해 전송 된 결과물 – 8 일차
- 보고서 – 10 일차
계획 생성 실행 : 실행 계획은 테스트에 필요한 실행 수를 표시합니다. 오프 사이트에서 수행하는 모든 실행은 온 사이트 팀에 의해 기록됩니다.
예를 들어, 당신이 사용할 때 HP Quick Test Professional 도구 실행을 위해 테스트 계획의 실행 탭에 실행 횟수가 표시됩니다.
하드웨어 소프트웨어 및 인력 요구 사항 :
Java에서 배열을 어떻게 뒤집습니까?
- 프로젝트에 필요한 장치, 브라우저 버전, IOS, 테스트 도구와 같은 하드웨어 및 소프트웨어 요구 사항.
- 인력 배치는 테스트에 필요한 사람을 지정하는 것을 의미합니다. 여기에서 팀 수를 언급 할 수 있습니다.
- 추가 테스트 멤버가 필요한 경우 테스트 범위에 따라 현장에서 요청할 수 있습니다. 단순히 테스트 케이스 수가 증가하면이를 실행하기 위해 더 많은 팀 구성원이 필요함을 의미합니다.
역할과 책임: 이는 다양한 수준의 테스트를 수행하는 관련 역할에 작업을 할당하는 것을 의미합니다.
예를 들어,
4 개의 유효성 검사 프로토콜을 실행하려면 4 명의 구성원으로 구성된 팀에서 앱을 테스트해야하며 다음과 같이 책임을 위임 할 수 있습니다.
- 테스트 리드 : 테스트 계획 설계
- 팀원 1 : 프로토콜 설계 및 실행 1,2.
- 팀원 2 : 프로토콜 설계 및 실행 3,4.
- 팀 구성원: 보고서, 검토 및 메트릭 준비.
가정 및 종속성 : 즉, 설계 중에 만들어진 가정과 테스트를 위해 식별 된 종속성이 여기에 포함됩니다.
위험 및 완화 : 완화 및 비상 계획과 함께 원하는 환경의 가용성, 빌드 등과 같은 테스트 계획과 관련된 위험.
보고서 및 측정 항목 : 테스트 및 이해 관계자에게보고하는 데 사용 된 요소가 여기에 언급되어야합니다.
모바일 앱의 예는 다음과 같습니다.
설치 자격
- 설치 자격에는 사용되는 테스트 환경과 수, 각 환경의 테스터에게 필요한 액세스 수준과 필요한 테스트 데이터와 같은 세부 정보가 포함됩니다. 여기에는 브라우저 호환성, 실행에 필요한 도구, 테스트에 필요한 장치 등이 포함될 수 있습니다. 개발중인 시스템은 사용자 요구 사항에 따라 설치해야합니다.
- 일부 응용 프로그램을 테스트하려면 테스트 데이터가 필요할 수 있으며 적절한 사람이 제공해야합니다. 필수 전제 조건입니다.
- 일부 응용 프로그램에는 데이터베이스가 필요할 수 있습니다. 우리는 사양을 검증하기 위해 테스트에 필요한 모든 데이터를 데이터베이스에 보관해야합니다.
예를 들어, 새로운 앱은 모바일 (Android 4.3.1) 및 브라우저 (Chrome 54)에서 'abc'를 테스트해야한다고 말합니다.이 경우 다음 사항을 추적해야합니다.
- 앱 'abc'의 사이트를 확인하기 위해 적절한 권한이 부여되었는지 확인하십시오.
- 모바일 (android / ios), 브라우저 -Chrome, 필요한 버전이있는 Internet Explorer와 같이 앱 테스트에 사용 된 장치를 사용할 수 있는지 확인합니다.
- 지정된 버전 (예 : Chrome 54, Android 버전 4.3.1)으로 올바르게 설치되었는지 확인하십시오.
- 브라우저와 모바일 모두에서 앱에 액세스 할 수 있는지 확인하십시오.
운영 자격
운영 자격은 테스트중인 애플리케이션 용으로 설계된 모든 모듈과 하위 모듈이 원하는 환경에서 예상대로 올바르게 작동하도록 보장합니다.
일반적으로 유효성 검사 테스트는 다음 계층 구조에서 수행됩니다.
기능 테스트는 검증 테스트에서 중요한 역할을합니다. 이는 언급 된 모든 중요 요구 사항에 따라 애플리케이션의 기능을 검증해야 함을 의미합니다. 이를 통해 기능 사양 문서에 언급 된 요구 사항을 매핑하고 제품이 언급 된 모든 요구 사항을 충족하는지 확인할 수 있습니다.
기능 테스트 및 유형
이름에서 알 수 있듯이 기능 테스트는 기능, 즉 소프트웨어가 수행해야하는 작업을 테스트하는 것입니다. 소프트웨어의 기능은 요구 사항 사양 문서에 정의됩니다.
유형에 대해 간략히 살펴 보겠습니다.
# 1) 단위 테스트 :
단위 테스트는 주어진 시스템의 개별 단위 / 모듈 / 구성 요소 / 방법을 테스트하는 것입니다. 필드 유효성 검사, 레이아웃 제어, 디자인 등은 코딩 후 다른 입력으로 테스트됩니다. 코드의 각 줄은 개별 단위 테스트 사례에 대해 유효성을 검사해야합니다.
단위 테스트는 개발자가 직접 수행합니다. 다른 레벨의 테스트에 비해 버그 수정 비용이 더 적습니다.
예:
함수에 대한 코드 루프를 평가하면 성별 선택이 단위 테스트의 예라고 말합니다.
# 2) 블랙 박스 테스트 :
시스템의 내부 세부 사항에 초점을 맞추지 않고 요구 사항에 대해 원하는 기능에 대해 애플리케이션의 동작을 테스트하는 것을 블랙 박스 테스트라고합니다. 일반적으로 독립 테스트 팀이나 응용 프로그램의 최종 사용자가 수행합니다.
애플리케이션은 관련 입력으로 테스트되고 시스템이 원하는대로 작동하는지 검증하기 위해 테스트됩니다. 이것은 기능적 요구 사항과 비 기능적 요구 사항을 모두 테스트하는 데 사용할 수 있습니다.
# 3) 화이트 박스 테스트 :
화이트 박스 테스트 코드별로 프로그램 코드를 자세히 검사하는 것입니다. 애플리케이션의 전체 작업은 작성된 코드에 따라 다르므로 코드를 매우 신중하게 테스트해야합니다. 단계적으로 모든 유닛과 전체 모듈의 통합을 확인해야합니다.
프로그래밍 지식이있는 테스터는 여기서 필수 기준입니다. 이를 통해 응용 프로그램의 워크 플로에 편차가 있는지 명확하게 알 수 있습니다. 개발자와 테스터 모두에게 유용합니다.
# 4) 회색 상자 테스트 :
그레이 박스 테스트는 화이트 박스와 블랙 박스 테스트의 조합입니다. 테스트 할 장치의 구조 또는 코드에 대한 부분적인 지식이 여기에 알려져 있습니다.
통합 테스트 및 유형
단위 테스트에서 이미 테스트 된 소프트웨어의 개별 구성 요소는 모듈 간의 데이터 흐름을 보장하기 위해 전체적으로 기능을 테스트하기 위해 통합 및 테스트됩니다.
이것은 개발자 자신 또는 독립적 인 테스트 팀에 의해 수행됩니다. 두 개 이상의 장치를 테스트 한 후에 수행 할 수 있습니다.
하향식 접근 방식 :
이 접근 방식에서는 최상위 단위를 먼저 테스트 한 다음 하위 수준 단위를 단계별로 테스트합니다. 사용할 수있는 테스트 스텁은 초기 단계에서 사용할 수없는 하위 수준 단위를 시뮬레이션하는 데 필요합니다.
상향식 접근 방식 :
이 접근 방식에서는 맨 아래 장치가 먼저 테스트되고 통합 된 다음 상위 레벨 장치가 테스트됩니다. 사용할 수있는 테스트 스텁은 초기 단계에서 사용할 수없는 상위 레벨 단위를 시뮬레이션하는 데 필요합니다.
시스템 테스트 및 유형
전체 시스템 / 소프트웨어를 테스트하는 것을 시스템 테스트라고합니다. 이 시스템은 기능 요구 사항 사양에 대해 완전히 테스트됩니다. 시스템 테스트는 기능 및 비 기능 요구 사항 모두에 대해 수행됩니다. 이러한 유형의 테스트에는 일반적으로 블랙 박스 테스트가 선호됩니다.
YouTube에서 오디오를 다운로드하는 가장 좋은 방법
# 1) 연기 테스트 :
빌더가 처음에 테스트 할 빌드를 제공 할 때 빌드를 철저히 테스트해야합니다. 이것을 연기 테스트라고합니다. 빌드가 추가 테스트가 가능한지 여부를 명시해야합니다.
유효성 검사를 수행하려면 적절한 빌드가 필요합니다. 따라서 연기 테스트는 먼저 테스트 팀에서 수행합니다. 테스트 된 응용 프로그램의 워크 플로는 테스트 케이스를 포함하거나 포함하지 않고 테스트해야합니다. 전체 흐름을 다루는 테스트 케이스는이 테스트에 유용합니다.
# 2) 온 전성 테스트 :
온 전성 테스트에서는 테스트중인 애플리케이션 모듈의 주요 기능이 테스트됩니다. 3 개의 탭 (예 : 프로필 생성, 교육, 로그인 등)이있는 웹 사이트를 테스트 할 때 IRCTC ,이 모든 탭의 주요 기능은 자세히 살펴 보지 않고 확인해야합니다.
메뉴, 하위 메뉴, 탭은 모든 모듈에서 테스트해야합니다. 테스트는 심층이 아닌 주요 흐름에 대해서만 수행되므로 회귀 테스트의 하위 집합입니다.
# 3) 회귀 테스트 :
프로젝트의 모든 릴리스에 대해 개발 팀은 특정 변경 사항을 도입 할 수 있습니다. 새로 도입 된 변경 사항이 시스템의 작업 흐름에 영향을주지 않았는지 확인하는 것을 회귀 테스트라고합니다. 여기서는 새로운 요구 사항과 관련된 특정 테스트 사례 만 테스트해야합니다.
성능 자격
UAT (사용자 수락 테스트) :
이것은 시스템이 지정된 요구 사항에 따라 필요에 따라 작동하는지 확인하기 위해 수행되는 마지막 테스트 단계입니다. 이것은 클라이언트에 의해 수행됩니다. 클라이언트가 시스템 테스트를 인증하고 통과하면 제품을 배포 할 수 있습니다.
알파 및 베타 테스트 :
알파 테스트는 소프트웨어 개발 사이트에서 출시되기 전에 응용 프로그램에 대한 개발자가 수행합니다. 여기에는 흑백 상자 테스트가 포함됩니다. 베타 테스트는 제품이 개발되고 배포 된 후 고객 측에서 수행됩니다.
샘플 검증 테스트 케이스 또는 프로토콜
경험상 Gmail 로그인을 위해이 프로토콜을 작성했습니다.
다루는 로그인 기능에 대한 심층 검사는 실제로 유효성 검사가 무엇인지입니다. 그러나 사용되는 문장 열의 스타일이 완전히 다를 수 있으며 클라이언트 요구 사항에 따라 달라질 수 있음을 언급하고 싶습니다.
=> 샘플 검증 테스트 사례 다운로드 : Gmail 로그인 테스트 사례
결론
글쎄, 유효성 검사는 제품의 기능을 자세히 분석하는 것입니다. 검증 테스터는 테스트에서 최적의 결과를 얻으려면 항상 편차를보고해야합니다.
작성된 모든 테스트 케이스는 평범한 사람도 선명하고 간결하며 이해할 수 있어야합니다. 검증 테스터는 지정된 요구 사항에 따라 올바른 제품이 개발되고 있는지 확인해야합니다.
유효성 검사 테스트 가이드로서 유효성 검사와 관련된 프로세스를 다루었습니다.
검증 계획을 포함하는 설계 자격, 하드웨어 소프트웨어 설치에 대해 설명하는 설치 자격, 전체 시스템 테스트를 포함하는 운영 자격, 생산에 대한 권한을 제공하는 사용자 승인 테스트를 포함하는 성능 자격.
이 기사가 검증 테스트 개념에 대한 지식을 풍부하게 해주기를 바랍니다 !!