difference between performance test plan
성능 테스트 계획과 테스트 전략의 차이점은 무엇입니까?
이것에 성능 테스트 시리즈 , 이전 튜토리얼에서 기능 테스트 대 성능 테스트 상세히.
=> 전체 성능 테스트 자습서 시리즈를 보려면 여기를 클릭하십시오.
이 자습서에서는 성능 테스트 계획과 테스트 전략의 차이점과 이러한 문서의 일부로 포함될 내용에 대해 알아 봅니다.
이 두 문서의 차이점을 이해하겠습니다.
학습 내용 :
성능 테스트 전략
성능 테스트 전략 문서는 테스트 단계에서 성능 테스트를 수행하는 방법에 대한 정보를 제공하는 고급 문서입니다. 비즈니스 요구 사항을 테스트하는 방법과 제품을 최종 고객에게 성공적으로 제공하기 위해 필요한 접근 방식을 알려줍니다.
여기에는 매우 높은 수준의 비즈니스 프로세스에 대한 모든 정보가 포함됩니다.
이 문서는 일반적으로 이전 경험을 바탕으로 성능 테스트 관리자가 작성합니다.이 문서는 프로젝트의 초기 단계, 즉 요구 사항 분석 단계 또는 요구 사항 분석 단계 이후에 준비되기 때문에 사용할 수있는 정보는 제한적입니다.
즉, 성능 테스트 전략 문서는 성능 테스트 목표를 달성하기 위해 수행 할 접근 방식으로 프로젝트 시작시 설정 한 방향 일뿐입니다.
일반적인 성능 테스트 전략 문서에는 테스트 대상인 성능 테스트의 전반적인 목표가 포함되어 있습니까? 어떤 환경이 사용됩니까? 어떤 도구가 사용됩니까? 어떤 유형의 테스트가 수행됩니까? 진입 및 퇴출 기준, 이해 관계자의 어떤 위험이 완화됩니까? 이 튜토리얼에서 더 자세히 살펴 보도록하겠습니다.
위의 다이어그램은 프로젝트의 요구 사항 분석 단계 중 또는 이후에 성능 테스트 전략 문서가 생성되었음을 설명합니다.
성능 테스트 계획
성능 테스트 계획 문서는 요구 사항 및 설계 문서가 거의 동결 된 프로젝트의 후반 단계에서 작성됩니다. 성능 테스트 계획 문서에는 요구 사항 분석 단계에서 설명한 전략 또는 접근 방식을 구현하기위한 일정의 모든 세부 정보가 있습니다.
현재 설계 문서는 거의 준비되었으며 성능 테스트 계획에는 테스트 할 시나리오에 대한 모든 세부 정보가 포함되어 있습니다. 또한 성능 테스트 실행에 사용되는 환경, 테스트 실행주기, 리소스, 진입-종료 기준 등에 대한 자세한 내용이 있습니다. 성능 테스트 계획은 성능 관리자 또는 성능 테스트 리드가 작성합니다.
위의 다이어그램은 성능 테스트 계획이 설계 문서의 가용성을 기반으로 프로젝트 설계 중에 또는 설계 단계 후에 작성되었음을 명확하게 설명합니다.
성능 테스트 전략 문서의 내용
이제 성능 테스트 전략 문서에 무엇이 포함되어야하는지 살펴 보겠습니다.
#1. 소개: 특정 프로젝트에 대해 성능 테스트 전략 문서에 포함되는 내용에 대한 간략한 개요를 제공합니다. 또한이 문서를 사용할 팀을 언급하십시오.
Windows 10 용 최고의 스크린 샷 앱
# 2) 범위 : 범위를 정의하는 것은 성능 테스트가 정확히 무엇인지 알려주기 때문에 매우 중요합니다. 범위 또는 다른 섹션을 정의하는 동안 매우 구체적이어야합니다.
일반화 된 것은 작성하지 마십시오. 범위는 전체 프로젝트에 대해 정확히 무엇이 테스트되는지 알려줍니다. 범위의 일부로 범위 내 및 범위 외가 있으며, 범위내는 성능 테스트를 거친 모든 기능을 설명하고 범위 외는 테스트되지 않는 기능을 설명합니다.
# 3) 테스트 접근하다: 여기서 우리는 성능 테스트를 위해 따라야 할 접근 방식에 대해 언급해야합니다. 각 스크립트가 단일 사용자로 실행되어 기준을 생성 한 다음이 기준 테스트가 나중에 벤치마킹을위한 참조로 사용되는 것처럼 테스트 실행 중 시간.
또한 각 구성 요소는 함께 통합하기 전에 개별적으로 테스트됩니다.
# 4) 테스트 유형 : 여기서는 부하 테스트, 스트레스 테스트, 내구성 테스트, 볼륨 테스트 등과 같은 다양한 유형의 테스트를 언급합니다.
# 5) 테스트 결과물 : 테스트 실행 보고서, 요약 보고서 등과 같은 프로젝트 성능 테스트의 일부로 제공되는 모든 결과물을 언급합니다.
# 6) 환경 : 여기서 우리는 환경에 대한 세부 사항을 언급해야합니다. 환경 세부 정보는 성능 테스트에 사용할 운영 체제를 설명하므로 매우 중요합니다.
환경이 프로덕션의 복제본이거나 프로덕션에서 크기가 커지거나 작아지는 경우, 또한 사이징 및 사이징 비율 (예 : 프로덕션 크기의 절반 또는 프로덕션 크기의 두 배가 될 것) ?
또한 환경 설정의 일부로 간주 될 패치 또는 보안 업데이트와 성능 테스트 실행 중에도 명확하게 언급해야합니다.
# 7) 도구 : 여기서는 결함 추적 도구처럼 사용될 모든 도구를 언급해야합니다. 관리 도구 , 성능 테스트 및 모니터링 도구. 약간 예 결함 추적을위한 도구는 지라 , Confluence와 같은 문서 관리, 성능 테스트 용 Jmeter 및 모니터링 Nagios .
# 8) 리소스 : 성능 테스트 팀에 필요한 리소스에 대한 자세한 내용은이 섹션에 설명되어 있습니다. 예를 들어 , 성능 관리자, 성능 테스트 리드, 성능 테스터 등
# 9) 엔트리 & 출구 기준 : 이 섹션에서는 진입 및 종료 기준에 대해 설명합니다.
예를 들어
입력 기준 – 성능 테스트 용 빌드를 배포하기 전에 응용 프로그램이 기능적으로 안정적이어야합니다.
종료 기준 – 모든 주요 결함이 종결되고 대부분의 SLA가 충족됩니다.
# 10) 위험 및 완화 : 성능 테스트에 영향을 미치는 모든 위험은 동일한 완화 계획과 함께 여기에 나열되어야합니다. 이렇게하면 성능 테스트 중에 발생하는 모든 위험에 도움이되거나 최소한 위험에 대한 해결 방법이 미리 계획 될 것입니다. 이는 결과물에 영향을주지 않고 정시에 성능 테스트 일정을 완료하는 데 도움이됩니다.
# 11) 약어 : 약어에 사용됩니다. 예를 들어 PT – 성능 테스트.
# 12) 문서 기록 : 여기에는 문서 버전이 포함됩니다.
성능 테스트 계획 문서의 내용
성능 테스트 계획 문서에 무엇이 포함되어야하는지 살펴 보겠습니다.
#1. 소개: 성능 테스트 전략 문서에 명시된 것과 동일하며 성능 테스트 전략 대신 성능 테스트 계획 만 언급합니다.
# 2) 목표 : 이 성능 테스트의 목적은 무엇이며 성능 테스트를 수행하여 얻을 수있는 것, 즉 성능 테스트를 수행하는 이점이 무엇인지 여기에 명확하게 언급해야합니다.
# 3) 범위 : 범위 내 및 범위 외 비즈니스 프로세스의 성능 테스트 범위가 여기에 정의되어 있습니다.
# 4) 접근 방식 : 전반적인 접근 방식이 여기에 설명되어 있습니다. 성능 테스트는 어떻게 수행됩니까? 환경 설정을위한 전제 조건은 무엇입니까? 등이 포함됩니다.
# 5) 아키텍처 : 여기서는 애플리케이션 서버, 웹 서버, DB 서버, 방화벽, 3 개와 같은 애플리케이션 아키텍처에 대한 세부 정보를 언급해야합니다.rdd 파티 애플리케이션 부하 발생기 기계 등
# 6) 종속성 : 성능 테스트 할 구성 요소가 기능적으로 안정적이며 환경이 프로덕션과 같은 프로덕션으로 확장되고 사용 가능 여부, 테스트 날짜 사용 가능 여부, 성능 테스트 도구 사용 가능 여부와 같은 모든 사전 성능 테스트 작업이 여기에 언급되어야합니다. 있는 경우 등등.
# 7) 환경 : IP 주소, 서버 수 등과 같은 시스템의 모든 세부 정보를 언급해야합니다. 또한 전제 조건, 업데이트 할 패치 등과 같이 환경을 설정하는 방법도 명확하게 언급해야합니다.
# 8) 테스트 시나리오 : 테스트 할 시나리오 목록이이 섹션에 나와 있습니다.
# 9) 작업 부하 혼합 : 워크로드 믹스는 성능 테스트의 성공적인 실행에 중요한 역할을하며 워크로드 믹스가 실시간 최종 사용자 작업을 예측하지 않으면 모든 테스트 결과가 헛되고 결국 프로덕션 성능이 저하됩니다. 애플리케이션이 실행될 때.
따라서 워크로드를 적절하게 디자인해야합니다. 사용자가 프로덕션에서 애플리케이션에 액세스하는 방법과 애플리케이션이 이미 사용 가능한지 여부를 이해하거나 비즈니스 팀에서 자세한 정보를 얻어 애플리케이션 사용을 올바르게 이해하고 워크로드를 정의하십시오.
# 10) 성능 실행주기 : 성능 테스트 실행 횟수에 대한 자세한 내용은이 섹션에서 설명합니다. 예를 들어 Base Line 테스트, Cycle 1 50 사용자 테스트 등
# 11) 성능 테스트 지표 : 수집 된 측정 항목의 세부 사항은 여기에 설명되어 있습니다. 이러한 측정 항목은 허용 기준 합의 된 성능 요구 사항으로.
# 12) 테스트 결과물 : 결과물을 언급하고 해당되는 경우 문서에 대한 링크도 통합합니다.
# 13) 결함 관리 : 여기서 우리는 결함이 어떻게 처리되는지 언급해야합니다. 심각도 수준 및 우선 순위 수준 또한 설명해야합니다.
# 14) 위험 관리 : 애플리케이션이 안정적이지 않고 우선 순위가 높은 기능적 결함이 여전히 열려있는 경우와 같은 완화 계획과 관련된 위험을 언급하면 성능 테스트 실행 일정에 영향을 미치며 앞서 언급했듯이 성능 테스트 중에 발생하는 모든 위험에 도움이됩니다. 최소한 위험에 대한 해결 방법은 미리 계획 될 것입니다.
qa 엔지니어 인터뷰 질문 및 답변
# 15) 리소스 : 역할 및 책임과 함께 팀 세부 사항을 언급합니다.
# 16) 버전 기록 : 문서 기록을 추적합니다.
# 17) 문서 검토 및 승인 : 여기에는 최종 문서를 검토하고 승인 할 사람들의 목록이 있습니다.
따라서 기본적으로 성능 테스트 전략에는 성능 테스트에 대한 접근 방식이 있으며 성능 테스트 계획에는 접근 방식의 세부 사항이 있으므로 함께 이동합니다. 일부 회사는 문서에 접근 방식이 추가 된 성능 테스트 계획 만있는 반면, 일부 회사는 전략 및 계획 문서를 별도로 가지고 있습니다.
이 문서를 개발하기위한 팁
성공적인 성능 테스트 실행을위한 전략 또는 계획 문서를 설계하는 동안 아래 지침을 따르십시오.
- 성능 테스트 전략 또는 테스트 계획을 정의하는 동안 테스트 목표와 범위에 집중해야한다는 점을 항상 기억하십시오. 테스트 전략이나 계획이 요구 사항이나 범위와 일치하지 않으면 테스트가 유효하지 않습니다.
- 시스템의 병목 현상을 식별하거나 애플리케이션의 성능을 확인하기 위해 테스트 실행 중에 캡처하는 데 중요한 메트릭을 집중하고 통합하십시오.
- 모든 시나리오를 한 번에 테스트하지 않고 시스템을 중단하지 않도록 테스트 실행을 계획합니다. 여러 번 테스트를 실행하고 시나리오와 사용자 부하를 점진적으로 늘립니다.
- 접근 방식에서 응용 프로그램에 액세스 할 모든 장치를 추가하려고하면 일반적으로 모바일 장치에 적용됩니다.
- 요구 사항이 수시로 계속 변경되므로 전략 문서에 항상 위험 및 완화 섹션이 있어야하며이 변경 사항은 고객에게 미리 해결해야하는 실행주기와 기한에 많은 영향을 미칩니다.
결론
이 튜토리얼이 성능 테스트 전략과 계획의 차이점과 그 내용, 모바일 애플리케이션 성능 테스트를위한 접근 방식 및 클라우드 애플리케이션 성능 테스트를 예제와 함께 자세하게 설명했을 것입니다.
성능 테스트를 강화하는 방법에 대해 자세히 알아 보려면 다음 튜토리얼을 확인하십시오.
=> 완전한 성능 테스트 자습서 시리즈를 보려면 여기를 방문하십시오.
이전 튜토리얼 | NEXT 튜토리얼