difference between test plan
예제를 통해 테스트 계획, 테스트 전략, 테스트 케이스, 테스트 스크립트, 테스트 시나리오 및 테스트 조건의 차이점을 알아보십시오.
소프트웨어 테스팅에는 모든 소프트웨어 테스터가 알아야 할 몇 가지 기본 개념과 중요한 개념이 포함됩니다.
이 기사에서는 소프트웨어 테스팅의 다양한 개념을 비교와 함께 설명합니다.
테스트 계획 대 테스트 전략, 테스트 케이스 대 테스트 스크립트, 테스트 시나리오 대 테스트 조건 및 테스트 절차 대 테스트 스위트 이해하기 쉽도록 자세히 설명되어 있습니다.
=> 전체 테스트 계획 튜토리얼 시리즈를 보려면 여기를 클릭하십시오.
Sasi C.가 질문 한 위의 질문은 소프트웨어 테스팅 클래스 그리고 저는 항상 참가자들에게 경험을 통해이 단어들을 거의 알아 차리지 못하고 우리 어휘의 일부가된다고 말합니다.
그러나 종종 혼동이 이들을 둘러싸고 있으며이 기사에서는 일반적으로 사용되는 용어를 몇 가지 정의하려고합니다.
다양한 소프트웨어 테스트 개념
아래에 나열된 것은 다양한 소프트웨어 테스트 개념과 비교입니다.
시작하자!!
학습 내용 :
테스트 계획과 테스트 전략의 차이점
테스트 전략 및 테스트 계획은 모든 프로젝트의 테스트 수명주기에서 두 가지 중요한 문서입니다. 여기에서는 테스트 전략 및 테스트 계획 문서에 대한 심층적 인 지식을 제공하려고합니다.
테스트 계획
테스트 계획은 소프트웨어 응용 프로그램을 테스트하는 범위, 목표 및 접근 방식을 정의하는 문서로 정의 할 수 있습니다. 테스트 계획은 용어이자 결과물입니다.
테스트 계획은 QA 프로젝트의 모든 활동을 나열하고, 일정을 정하고, 프로젝트 범위, 역할 및 책임, 위험, 진입 및 종료 기준, 테스트 목표 및 기타 생각할 수있는 모든 것을 정의하는 문서입니다.
테스트 계획은 내가 알아야 할 것과 필요한 모든 것을 나열하는 '슈퍼 문서'라고 부르는 것입니다. 부디 이 링크를 확인 자세한 정보와 샘플은.
테스트 계획은 요구 사항에 따라 설계됩니다. 테스트 엔지니어에게 작업을 할당하는 동안 몇 가지 이유로 인해 테스터 중 하나가 다른 테스터로 대체됩니다. 여기에서 테스트 계획이 업데이트됩니다.
테스트 전략은 테스트 접근 방식과이를 둘러싼 다른 모든 것을 설명합니다. 테스트 전략은 테스트 계획의 일부일 뿐이라는 점에서 테스트 계획과 다릅니다. 어느 정도 일반적이고 정적 인 하드 코어 테스트 문서입니다. 어떤 레벨에서 테스트 전략이나 계획이 사용되는지에 대한 논쟁도 있습니다. 그러나 나는 어떤 분별력있는 차이를 보지 못했습니다.
예: 테스트 계획은 누가 언제 테스트 할 것인지에 대한 정보를 제공합니다. 예를 들어, 모듈 1은“X 테스터”에 의해 테스트됩니다. 테스터 Y가 어떤 이유로 X를 대체하는 경우 테스트 계획을 업데이트해야합니다.
테스트 계획 문서
테스트 계획은 소프트웨어 프로젝트와 관련된 테스트 작업에 대한 완전한 정보를 제공하는 문서입니다. 테스트 범위, 테스트 유형, 목표, 테스트 방법론, 테스트 노력, 위험 및 우발 상황, 릴리스 기준, 테스트 결과물 등과 같은 세부 정보를 제공합니다. 코딩 후 시스템에서 실행될 가능한 테스트를 추적합니다.
테스트 계획은 분명히 변경 될 예정입니다. 처음에는 그 당시의 프로젝트 명확성을 바탕으로 테스트 계획 초안이 개발됩니다. 이 초기 계획은 프로젝트가 진행됨에 따라 수정됩니다. 테스트 팀 관리자 또는 테스트 리드는 테스트 계획 문서를 준비 할 수 있습니다. 이는 사양을 설명하며 동일하게 변경 될 수 있습니다.
테스트 대상, 테스트시기, 테스트 대상 및 테스트 방법은 테스트 계획에 정의됩니다. 테스트 계획은 문제, 종속성 및 근본적인 위험 목록을 정렬합니다.
테스트 계획의 유형
테스트 계획은 테스트 단계에 따라 다른 유형이 될 수 있습니다. 처음에는 전체 프로젝트 실행에 대한 마스터 테스트 계획이 있습니다. 시스템 테스트, 시스템 통합 테스트, 사용자 승인 테스트 등과 같은 특정 테스트 유형에 대해 별도의 테스트 계획을 만들 수 있습니다.
또 다른 접근 방식은 기능 및 비 기능 테스트에 대해 별도의 테스트 계획을 세우는 것입니다. 이 접근 방식 성능에서 테스트에는 별도의 테스트 계획이 있습니다.
시험 계획서 내용 ( IEEE-829 테스트 계획 구조 )
테스트 계획에 대한 명확한 형식을 그리는 것은 어렵습니다. 테스트 계획 형식은 프로젝트에 따라 다를 수 있습니다. IEEE는 IEEE-829 테스트 계획 구조로 설명되는 테스트 계획에 대한 표준을 정의했습니다.
표준 테스트 계획 내용에 대한 IEEE 권장 사항을 아래에서 찾으십시오.
- 테스트 계획 식별자
- 소개
- 테스트 항목
- 소프트웨어 위험 문제
- 테스트 할 기능
- 테스트하지 않을 기능
- 접근하다
- 품목 합격 / 불합격 기준 (또는) 수락 기준
- 정지 기준 및 재개 요건
- 결과물 테스트
- 테스트 작업
- 환경 요구 사항
- 인력 및 교육 요구
- 책임
- 시간표
- 승인
추천 읽기 => 테스트 계획 튜토리얼 – 완벽한 가이드
테스트 전략
테스트 전략은 테스트 설계를 설명하고 테스트 수행 방법을 결정하는 일련의 지침입니다.
예: 테스트 전략에는 '테스트 팀 구성원이 개별 모듈을 테스트해야합니다'와 같은 세부 정보가 포함됩니다. 이 경우 누가 테스트하는지는 중요하지 않습니다. 따라서 일반적이고 팀 구성원의 변경 사항을 업데이트 할 필요가 없어 정적으로 유지됩니다.
테스트 전략 문서
테스트 전략의 목적은 테스트 접근 방식, 테스트 유형, 테스트 환경 및 테스트에 사용할 도구를 정의하고 테스트 전략이 다른 프로세스와 어떻게 조정되는지에 대한 높은 수준의 세부 정보를 정의하는 것입니다. 테스트 전략 문서는 살아있는 문서로 작성되었으며 요구 사항, SLA 매개 변수, 테스트 환경 및 빌드 관리 접근 방식 등에 대해 더 명확하게 파악하면 업데이트됩니다 **.
테스트 전략은 프로젝트 스폰서, 비즈니스 SME, 애플리케이션 / 통합 개발, 시스템 통합 파트너, 데이터 변환 팀, 기술 리드, 아키텍처 리드, 배포 및 인프라 팀과 같은 빌드 / 릴리스 관리 팀으로 구성된 전체 프로젝트 팀을 대상으로합니다.
** 어떤 사람들은 일단 정의 된 테스트 전략을 업데이트해서는 안된다고 주장합니다. 대부분의 테스트 프로젝트에서는 일반적으로 프로젝트가 진행됨에 따라 업데이트됩니다.
다음은 테스트 전략 문서에 포함되어야하는 중요한 섹션입니다.
# 1) 프로젝트 개요
이 섹션은 조직의 개요를 제공하고 프로젝트에 대한 간략한 설명을 제공하는 것으로 시작할 수 있습니다. 아래 세부 정보를 포함 할 수 있습니다.
- 프로젝트의 필요성은 무엇 이었습니까?
- 프로젝트가 달성 할 목표는 무엇입니까?
약어 표 : 문서를 참조하는 동안 문서 판독기가 제시 할 수있는 약어가있는 표를 포함하는 것이 좋습니다.
# 2) 요구 사항 범위
요구 사항 범위에는 응용 프로그램 범위 및 기능 범위가 포함될 수 있습니다.
적용 범위 테스트중인 시스템과 새로운 기능이나 변경된 기능으로 인해 시스템에 미치는 영향을 정의합니다. 관련 시스템도 정의 할 수 있습니다.
| 체계 | 영향 (신규 또는 변경된 기능) | 관련 시스템 |
|---|---|---|
| 테스트 방법, 테스트시기, 테스트 대상 및 테스트 대상을 설명합니다. | 따라야 할 기술 유형과 테스트 할 모듈에 대해 설명합니다. | |
| 시스템 A | 새로운 개선 사항 및 버그 수정 | • 시스템 B • 시스템 C |
기능적 범위 시스템 내의 다른 모듈에 미치는 영향을 정의합니다. 여기에서는 기능과 관련된 각 관련 시스템에 대해 설명합니다.
| 체계 | 기준 치수 | 기능성 | 관련 시스템 |
|---|---|---|---|
| 시스템 C | 모듈 1 | 기능 1 | 시스템 B |
| 기능 2 | 시스템 C |
# 3) 고급 테스트 계획
테스트 계획은 별도의 문서입니다. 테스트 전략에는 높은 수준의 테스트 계획이 포함될 수 있습니다. 높은 수준의 테스트 계획에는 테스트 목표와 테스트 범위가 포함될 수 있습니다. 테스트 범위는 범위 내 활동과 범위 외 활동을 모두 정의해야합니다.
# 4) 테스트 접근법
이 섹션에서는 테스트 수명주기 동안 따라야 할 테스트 방법에 대해 설명합니다.
위의 다이어그램에 따라 테스트는 테스트 전략 및 계획 및 테스트 실행의 두 단계로 수행됩니다. 테스트 전략 및 계획 단계는 전체 프로그램에 대해 한 번 진행되는 반면 테스트 실행 단계는 전체 프로그램의 각주기에 대해 반복됩니다. 위의 다이어그램은 실행 접근 방식의 각 단계에서 다양한 단계와 결과물 (결과)을 보여줍니다.
테스트 접근 방식에는 아래 하위 섹션이 포함되어야합니다.
a) 시험 일정 : 이 하위 섹션에서 제안 된 프로젝트 일정을 설명하십시오.
b) 기능 테스트 접근법 : 이 하위 섹션을 사용하면 각 단계와 각 진입 및 종료 기준에 대한 개요가 제공됩니다. 다른 테스트 단계는 단위 테스트, 시스템 테스트, 시스템 통합 테스트, 사용자 수락 테스트 및 종단 간 테스트입니다.
c) 핵심 성과 지표 테스트 :
- 테스트 케이스 우선 순위 : 시간 제약이있는 경우 테스트 팀이 우선 순위가 높은 시나리오를 실행할 수 있도록 테스트 사례 우선 순위 지정 방식을 정의합니다. 계획된 모든 시나리오를 실행하지 않을 때 발생할 수있는 위험에 대해 프로젝트 이해 관계자들간에 합의가 있어야합니다.
- 결함 우선 순위 : 결함 우선 순위 지정 전략은 여기서 다룰 다음 주제입니다. 우선 순위 수준을 정의하고 중요, 높음, 중간 등과 같은 각 수준에 대한 설명을 제공합니다. 또한
- 결함 처리 시간 : 결함 처리 시간은 결함이 처음 제기 된 시간과 결함이 수정되어 재 테스트를 위해 오는 시간 사이의 시간으로 정의됩니다. 신속한 처리는 신속한 테스트와 프로젝트 일정 준수를 보장합니다. 각 결함 우선 순위 레벨에 대해 처리 시간을 정의하십시오.
| 우선 순위 수준 | 결함 처리 시간 |
|---|---|
| 1-중요 | 응답 시간: 2 시간 이내 마이그레이션 준비 수정 : 영업일 기준 1 일 이내 |
# 5) 테스트 범위
이 섹션에서는 테스트 시나리오 및 테스트 사례에서 비즈니스 / 기능 요구 사항의 적용 범위를 최적화하기 위해 QA 팀이 따라야 할 프로세스에 대해 설명합니다. 요구 사항 추적 성 매트릭스 : (RTM)을 사용하여 각 테스트 시나리오 및 테스트 사례로 모든 요구 사항을 추적 할 수 있습니다.
# 6) 테스트 환경
사용 가능한 다양한 QA 환경을 정의합니다. 어떤 환경에서 누가 어떤 테스트를 수행할지 언급하십시오. 응급 상황을 처리하기위한 환경 백업 계획을 만듭니다. 각 환경에 대한 액세스는 규제되고 명확하게 표시되어야합니다.
사용될 테스트 도구도이 섹션에서 언급 할 수 있습니다.
| 활동 | 수단 | 비고 |
|---|---|---|
| 테스트 관리 | HP ALM | 이 도구를 사용하는 이유를 언급하십시오. |
| 결함 관리 | 지라 | 이 도구를 사용하는 이유를 언급하십시오. |
# 7) QA 결과물 및 지표
모든 QA 결과물 나열
| S. 아니. | 결과물 |
|---|---|
| 1 | 테스트 전략 문서 |
| 두 | 요구 사항 추적 성 매트릭스 |
| 삼 | ST 테스트 스크립트 |
| 4 | 테스트 요약 보고서 |
| 5 | 자동화 가능 시나리오 목록 |
모든 QA 측정 항목 나열
| # | 메트릭 이름 | 메트릭 정의 | 메트릭 공식 | 미터법 측정 단위 | 사용할 메트릭이있는 보고서 |
|---|---|---|---|---|---|
| 1 | RCM (Requirements Coverage Metrics) | QA의 요구 사항 범위 | 확인 된 요구 사항 수에 대한 테스트 요구 사항 수의 비율 | % | 주간 QA 상태 보고서, 테스트 요약 보고서 |
| 두 | 테스트 범위 | 실행 된 테스트 케이스의 범위 | 실행 된 테스트 케이스 수 / 계획된 테스트 케이스 수 비율 | % | 일일 실행 보고서, 주간 QA 상태 보고서, 테스트 요약 보고서 |
# 8) 결함 관리
결함 워크 플로우, 결함 추적 방법론 및 결함 분류 프로세스를 생성하여 결함 관리 전략을 명확하게 정의합니다. 각 테스터의 역할에 대한 결함 책임을 언급합니다. 주기적인 결함 분석 및 근본 원인 분석은 전반적인 테스트 품질을 향상시킵니다.
# 9) 커뮤니케이션 관리
상태 보고서, 상태 회의 및 현장-해외 통신에 대한 지침을 설정합니다.
# 10) 가정, 위험 및 종속성
프로젝트의 기반이되는 가정을 설명하십시오. 여기에는 타이밍, 리소스 및 시스템 기능이 포함될 수 있습니다. 다른 프로젝트, 임시 자원의 가용성, 프로젝트에 영향을 줄 수있는 기타 기한과 같은 종속성을 설명합니다.
# 11) 부록
이 섹션에 역할 및 책임, 근무 시간대 및 참조와 같은 항목을 포함합니다.
추가 읽기=> 좋은 테스트 전략 문서 작성 가이드 .
테스트 계획 대 테스트 전략
| 테스트 계획 | 테스트 전략 |
|---|---|
| 소프트웨어 요구 사항 사양 (SRS)에서 파생됩니다. | 비즈니스 요구 사항 문서 (BRS)에서 파생되었습니다. |
| 테스트 리드 또는 관리자가 준비합니다. | 프로젝트 관리자 또는 비즈니스 분석가가 개발합니다. |
| 테스트 계획 ID, 테스트 할 기능, 테스트 기술, 테스트 작업, 기능 통과 또는 실패 기준, 테스트 결과물, 책임 및 일정 등이 테스트 계획의 구성 요소입니다. | 목표 및 범위, 문서 형식, 테스트 프로세스, 팀보고 구조, 클라이언트 커뮤니케이션 전략 등은 테스트 전략의 구성 요소입니다. |
| 새로운 기능이 있거나 요구 사항이 변경되면 테스트 계획 문서가 업데이트됩니다. | 테스트 전략은 문서를 준비하는 동안 표준을 유지합니다. 정적 문서라고도합니다. |
| 테스트 계획을 개별적으로 준비 할 수 있습니다. | 소규모 프로젝트에서 테스트 전략은 종종 테스트 계획의 한 부분으로 발견됩니다. |
| 프로젝트 수준에서 테스트 계획을 준비 할 수 있습니다. | 여러 프로젝트에서 테스트 전략을 사용할 수 있습니다. |
| 테스트 계획을 사용하여 사양에 대해 설명 할 수 있습니다. | 테스트 전략은 일반적인 접근 방식에 대해 설명합니다. |
| 테스트 계획은 프로젝트 과정에서 변경됩니다. | 테스트 전략은 일반적으로 승인되면 변경되지 않습니다. |
| 테스트 계획은 요구 사항 승인 후 작성됩니다. | 테스트 계획 전에 테스트 전략이 만들어집니다. |
| 테스트 계획은 다른 유형일 수 있습니다. 시스템 테스트 계획, 성능 테스트 계획 등과 같은 다양한 유형의 테스트에 대한 마스터 테스트 계획과 별도의 테스트 계획이 있습니다. | 프로젝트에 대한 테스트 전략 문서는 하나만 있습니다. |
| 테스트 계획은 명확하고 간결해야합니다. | 테스트 전략은 프로젝트에 대한 전반적인 지침을 제공합니다. |
이 두 문서의 차이점은 미묘합니다. 테스트 전략은 프로젝트에 대한 높은 수준의 정적 문서입니다. 반면에 테스트 계획은 테스트 대상, 테스트시기 및 테스트 방법을 지정합니다.
테스트 케이스와 테스트 스크립트의 차이점
제 생각에이 두 용어는 서로 바꿔서 사용할 수 있습니다. 네, 차이가 없다는 것입니다. 테스트 케이스는 애플리케이션에서 특정 테스트를 수행하는 데 도움이되는 일련의 단계입니다. 테스트 스크립트도 동일합니다.
이제 테스트 케이스는 수동 테스트 환경에서 사용되는 용어이고 테스트 스크립트는 자동화 환경에서 사용된다는 생각의 학파가 있습니다. 이는 부분적으로는 해당 분야의 테스터의 편의 수준과 도구가 테스트를 참조하는 방식 (일부는 테스트 스크립트를 호출하고 일부는 테스트 케이스를 호출) 때문에 부분적으로 사실입니다.
따라서 실제로 테스트 스크립트와 테스트 사례는 모두 수동 또는 자동화를 통해 기능을 검증하기 위해 애플리케이션에서 수행해야하는 단계입니다.
추가 읽기=> 효과적인 테스트 케이스를 작성하는 방법? 과 테스트 케이스 예제 템플릿 .
| 테스트 케이스 | 테스트 스크립트 |
|---|---|
| 애플리케이션을 순서대로 테스트하기위한 기본 양식입니다. | 개발이 완료되면 스크립트는 요구 사항이 변경 될 때까지 여러 번 실행합니다. |
| 응용 프로그램을 테스트하는 데 사용되는 단계별 절차입니다. | 응용 프로그램을 자동으로 테스트하기위한 일련의 지침입니다. |
| 테스트 케이스라는 용어는 수동 테스트 환경에서 사용됩니다. | 테스트 스크립트라는 용어는 자동화 테스트 환경에서 사용됩니다. |
| 수동으로 수행됩니다. | 스크립팅 형식으로 수행됩니다. |
| 템플릿 형태로 개발되었습니다. | 스크립팅 형태로 개발되었습니다. |
| 테스트 케이스 템플릿에는 테스트 슈트 ID, 테스트 데이터, 테스트 절차, 실제 결과, 예상 결과 등이 포함됩니다. | 테스트 스크립에서는 다른 명령을 사용하여 스크립트를 개발할 수 있습니다. |
| 응용 프로그램을 테스트하는 데 사용됩니다. | 응용 프로그램을 테스트하는데도 사용됩니다. |
| 예 : 애플리케이션에서 로그인 버튼을 확인해야합니다. 단계는 다음과 같습니다. a) 응용 프로그램을 시작합니다. b) 로그인 버튼이 표시되는지 확인합니다. | 예 : 애플리케이션에서 이미지 버튼을 클릭하려고합니다. 스크립트에는 다음이 포함됩니다. a) 이미지 버튼을 클릭합니다. |
테스트 시나리오와 테스트 조건의 차이점
테스트 시나리오 : 애플리케이션을 테스트하는 가능한 모든 방법을 정의하는 방법입니다. 응용 프로그램을 테스트 할 수있는 모든 방법을 다루는 단일 문입니다.
테스트 조건 : 테스트 조건은 테스터가 애플리케이션을 테스트하기 위해 따라야하는 사양입니다.
이것은 테스터가 테스트 설계 단계의 초기 전환 단계로 만드는 한 줄 포인터입니다. 이것은 대부분 특정 기능과 관련하여 테스트 할 '무엇'에 대한 한 줄 정의입니다. 일반적으로 테스트 시나리오는 테스트 케이스 작성을위한 입력입니다.
애자일 프로젝트에서 테스트 시나리오는 유일한 테스트 설계 출력이며 다음과 같은 테스트 사례가 작성되지 않습니다. 테스트 시나리오는 여러 테스트로 이어질 수 있습니다.
테스트 시나리오의 예:
- 관리자가 새 국가를 추가 할 수 있는지 확인
- 관리자가 기존 국가를 삭제할 수 있는지 확인
- 기존 국가를 업데이트 할 수 있는지 확인
반면에 테스트 조건은 더 구체적입니다. 특정 테스트의 목표 / 목표로 대략 정의 할 수 있습니다.
테스트 조건 예: 위의 예에서 시나리오 1을 테스트하려면 다음 조건을 테스트 할 수 있습니다.
- 국가 이름을“India”(유효)로 입력하고 국가 추가를 확인합니다.
- 공백을 입력하고 국가가 추가되는지 확인하십시오.
- 각 경우에 특정 데이터가 설명되고 테스트의 목표가 훨씬 더 정확합니다.
추가 읽기=> 웹 및 데스크톱 애플리케이션 테스트를위한 180 개 이상의 샘플 테스트 시나리오.
| 테스트 시나리오 | 테스트 조건 |
|---|---|
| 이것들은 우리가 테스트 할 내용을 설명하는 한 줄 문장입니다. | 테스트 조건은 애플리케이션 테스트의 주요 목표를 설명합니다. |
| 가능한 모든 방법으로 애플리케이션을 테스트하는 프로세스입니다. | 테스트 조건은 응용 프로그램을 테스트하기 위해 따라야하는 정적 규칙입니다. |
| 테스트 시나리오는 테스트 케이스 작성을위한 입력입니다. | 응용 프로그램을 테스트하는 주요 목표를 제공합니다. |
| 테스트 시나리오는 애플리케이션을 테스트 할 수있는 모든 가능한 경우를 다룹니다. | 테스트 조건은 매우 구체적입니다. |
| 복잡성을 줄입니다. | 시스템 버그를 없애줍니다. |
| 테스트 시나리오는 단일 또는 테스트 케이스 그룹 일 수 있습니다. | 테스트 케이스의 목표입니다. |
| 시나리오를 작성하면 응용 프로그램의 기능을 쉽게 이해할 수 있습니다. | 테스트 조건은 매우 구체적입니다. |
| 예제 테스트 시나리오 : # 1) 관리자가 새 국가를 추가 할 수 있는지 확인합니다. # 2) 관리자가 기존 국가를 삭제할 수 있는지 확인합니다. # 3) 기존 국가를 업데이트 할 수 있는지 확인합니다. | 테스트 조건의 예 : # 1) 국가 이름을“India”로 입력하고 국가가 추가되었는지 확인합니다. # 2) 빈 칸을 남겨두고 국가가 추가되는지 확인하십시오. |
테스트 절차와 테스트 스위트의 차이점
테스트 절차는 엔드-투-엔드 상황 또는 그 효과에 대한 실행과 같은 특정 논리적 이유에 기반한 테스트 케이스의 조합입니다. 테스트 케이스가 실행되는 순서는 고정되어 있습니다.
테스트 절차 : 테스트 라이프 사이클에 불과합니다. 테스트 라이프 사이클에는 10 단계가 있습니다.
그들은:
- 노력 추정
- 프로젝트 시작
- 시스템 연구
- 테스트 계획
- 디자인 테스트 케이스
- 테스트 자동화
- 테스트 케이스 실행
- 결함보고
- 회귀 테스트
- 분석 및 요약 보고서
예를 들어 , Gmail.com에서 이메일 전송을 테스트하는 경우 테스트 절차를 구성하기 위해 결합 할 테스트 케이스의 순서는 다음과 같습니다.
- 로그인 확인 테스트
- 이메일 작성 테스트
- 하나 이상의 첨부 파일을 첨부하는 테스트
- 다양한 옵션을 사용하여 필요한 방식으로 이메일 서식 지정
- 받는 사람, 숨은 참조, 참조 필드에 연락처 또는 이메일 주소 추가
- 이메일을 보내고 '보낸 메일'섹션에 표시되는지 확인
위의 모든 테스트 사례는 끝에서 특정 목표를 달성하기 위해 그룹화됩니다. 또한 테스트 절차에는 어느 시점에서든 결합 된 몇 가지 테스트 케이스가 있습니다.
반면에 테스트 스위트는 테스트주기 또는 회귀 단계 등의 일부로 실행해야하는 모든 테스트 케이스의 목록입니다. 기능에 따른 논리적 그룹화는 없습니다. 구성 테스트 케이스가 실행되는 순서는 중요 할 수도 있고 중요하지 않을 수도 있습니다.
테스트 스위트 : Test Suite는 테스터가 테스트 실행 상태를 실행하고보고하는 데 도움이되는 테스트 세트가있는 컨테이너입니다. 활성, 진행 중, 완료 등 세 가지 상태 중 하나를 취할 수 있습니다.
테스트 스위트의 예 : 응용 프로그램의 현재 버전이 2.0 인 경우. 이전 버전 1.0에는 전체 테스트를 위해 1000 개의 테스트 케이스가있을 수 있습니다. 버전 2의 경우 새 버전에 추가 된 새 기능을 테스트하기위한 500 개의 테스트 케이스가 있습니다.
따라서 현재 테스트 스위트는 회귀와 새로운 기능을 모두 포함하는 1000 + 500 테스트 케이스입니다. 제품군도 조합이지만 목표 기능을 달성하려고하는 것은 아닙니다.
테스트 스위트에는 100 개 또는 1000 개의 테스트 케이스가 포함될 수 있습니다.
| 테스트 절차 | 테스트 스위트 |
|---|---|
| 테스트 절차 생성은 종단 간 테스트 흐름을 기반으로합니다. | 테스트 스위트는주기 또는 범위를 기반으로 작성됩니다. |
| 애플리케이션을 테스트하기위한 테스트 케이스의 조합입니다. | 애플리케이션을 테스트하기위한 테스트 케이스 그룹입니다. |
| 기능을 기반으로 한 논리적 그룹입니다. | 기능을 기반으로하는 논리적 그룹이 없습니다. |
| 테스트 절차는 소프트웨어 개발 프로세스에서 제공 가능한 제품입니다. | 테스트주기 또는 회귀의 일부로 실행됩니다. |
| 실행 순서는 고정되어 있습니다. | 실행 순서는 중요하지 않을 수 있습니다. |
| 테스트 절차에는 종단 간 테스트 사례가 포함됩니다. | 테스트 스위트에는 모든 새로운 기능과 회귀 테스트 케이스가 포함되어 있습니다. |
| 테스트 절차는 TPL (Test Procedure language)이라는 새로운 언어로 코딩됩니다. | 테스트 스위트에는 수동 테스트 케이스 또는 자동화 스크립트가 포함되어 있습니다. |
결론
소프트웨어 테스팅 개념은 소프트웨어 테스팅 수명주기에서 중요한 역할을합니다.
모든 소프트웨어 테스터가 테스트 프로세스를 효과적으로 수행하려면 위에서 논의한 개념과 비교를 명확하게 이해하는 것이 매우 중요합니다.
일반적으로 이와 같은 기사는 더 깊은 토론을위한 훌륭한 출발점입니다. 따라서 아래 의견에 귀하의 생각, 동의, 의견 불일치 및 기타 사항을 제공하십시오. 여러분의 의견을 기다리겠습니다.
또한 일반적인 소프트웨어 테스트 또는 테스트 경력과 관련된 모든 것에 대한 질문을 환영합니다. 우리는 같은 시리즈의 다음 포스트에서 더 자세히 다룰 것입니다.
행복한 독서 !!
컴파일러를 사용한 C ++ IDE
=> 전체 테스트 계획 자습서 시리즈를 보려면 여기를 방문하십시오.