load testing complete guide
초보자를위한 완벽한 부하 테스트 가이드 :
이 자습서에서는로드 테스트를 수행하는 이유, 그 결과 달성되는 사항, 아키텍처,로드 테스트를 성공적으로 실행하기 위해 따라야 할 접근 방식,로드 테스트 환경 설정 방법, 모범 사례 및 시장에서 사용 가능한 최고의 부하 테스트 도구.
기능 및 비 기능 테스트 유형에 대해 들어 봤습니다. 비 기능 테스트에는 성능 테스트, 보안 테스트, 사용자 인터페이스 테스트 등과 같은 다양한 유형의 테스트가 있습니다.
따라서 부하 테스트는 성능 테스트의 하위 집합 인 비 기능 테스트 유형입니다.
따라서 우리가 성능을 위해 애플리케이션을 테스트한다고 말할 때 우리는 여기서 무엇을 테스트하고 있습니까? 부하, 부피, 용량, 스트레스 등에 대한 애플리케이션을 테스트하고 있습니다.
학습 내용 :
부하 테스트 란 무엇입니까?
부하 테스트는 여러 사용자가 동시에 애플리케이션에 액세스하는 것을 시뮬레이션하여 다양한 부하 조건에서 시스템의 응답을 테스트하는 성능 테스트의 하위 집합입니다. 이 테스트는 일반적으로 애플리케이션의 속도와 용량을 측정합니다.
따라서 부하를 수정할 때마다 다양한 조건에서 시스템의 동작을 모니터링합니다.
예 :로그인 페이지에 대한 클라이언트 요구 사항이 2 ~ 5 초이고이 2 ~ 5 초는로드가 5000 명의 사용자가 될 때까지 전체적으로 일관되어야한다고 가정 해 보겠습니다. 그렇다면 우리는 무엇을 관찰해야합니까? 시스템의 부하 처리 기능일까요 아니면 응답 시간 요구 사항일까요?
대답은 둘 다입니다. 모든 동시 사용자에 대해 2 ~ 5 초의 응답 시간으로 5000 명의 사용자 부하를 처리 할 수있는 시스템을 원합니다.
그렇다면 동시 사용자와 가상 사용자는 무엇을 의미할까요?
동시 사용자는 애플리케이션에 로그인하고 동시에 일련의 활동을 함께 수행하는 동시에 애플리케이션에서 로그 오프하는 사용자입니다. 반면에 가상 사용자는 다른 사용자 활동에 관계없이 시스템에 들어갔다 나가면됩니다.
부하 테스트 아키텍처
아래 다이어그램에서 여러 사용자가 애플리케이션에 액세스하는 방법을 볼 수 있습니다. 여기서 각 사용자는 인터넷을 통해 요청을하고 나중에 방화벽을 통과합니다.
방화벽 후에는로드 밸런서를 웹 서버에 분산 한 다음 애플리케이션 서버로 전달한 다음 나중에 사용자 요청에 따라 필요한 정보를 가져 오는 데이터베이스 서버로 전달하는로드 밸런서가 있습니다.
부하 테스트는 도구를 사용하거나 수동으로 수행 할 수 있습니다. 그러나 더 적은 부하에 대해 애플리케이션을 테스트하지 않으므로 수동 부하 테스트는 권장되지 않습니다.
예: 각 사용자 클릭에 대한 응용 프로그램의 응답 시간을보기 위해 온라인 쇼핑 응용 프로그램을 테스트한다고 가정 해 보겠습니다. 즉, Step1 – URL 시작, 응답 시간, 응용 프로그램에 로그인하고 응답 시간 등을 확인합니다. 제품, 카트에 추가, 결제 및 로그 오프. 이 모든 작업은 10 명의 사용자가 수행해야합니다.
따라서 이제 10 명의 사용자에 대한 애플리케이션 부하를 테스트해야 할 때 도구를 사용하는 대신 다른 컴퓨터에서 10 명의 실제 사용자가 수동으로 부하를 가하여이를 달성 할 수 있습니다. 이 시나리오에서는 도구에 투자하고 도구에 대한 환경을 설정하는 것보다 수동 부하 테스트를 수행하는 것이 좋습니다.
1500 명의 사용자에 대한 부하 테스트가 필요한 경우 애플리케이션이 구축 된 기술과 프로젝트 예산에 따라 사용 가능한 도구를 사용하여 부하 테스트를 자동화해야합니다.
예산이 있으면 Load runner와 같은 상용 도구를 사용할 수 있지만 예산이 많지 않으면 JMeter와 같은 오픈 소스 도구를 사용할 수 있습니다.
신입생을위한 SQL 인터뷰 질문 및 답변 pdf
상용 도구이든 오픈 소스 도구이든, 도구를 완성하기 전에 세부 사항을 클라이언트와 공유해야합니다. 일반적으로 개념 증명이 준비되어 도구를 사용하여 샘플 스크립트를 생성하고 도구를 완성하기 전에 도구 승인을 위해 클라이언트에게 샘플 보고서를 보여줍니다.
자동화 된 부하 테스트에서 우리는 실시간 사용자 작업을 모방하는 자동화 도구의 도움으로 사용자를 대체합니다. 로드를 자동화함으로써 리소스와 시간을 절약 할 수 있습니다.
다음은 도구를 사용하여 사용자를 대체하는 방법을 나타내는 다이어그램입니다.
부하 테스트를하는 이유
정상적인 영업일 동안 꽤 잘 작동하는 온라인 쇼핑 웹 사이트가 있다고 가정 해 봅시다. 즉, 사용자가 애플리케이션에 로그인하고, 다른 제품 카테고리를 탐색하고, 제품을 선택하고, 장바구니에 항목을 추가하고, 체크 아웃하고 내부에서 로그 오프 할 수 있습니다. 허용 가능한 범위이고 페이지 오류나 큰 응답 시간이 없습니다.
한편, 성수기, 즉 추수 감사절을 가정 해 보자고 시스템에 로그인 한 수천 명의 사용자가 있습니다. 시스템이 갑자기 중단되고 사용자는 매우 느린 응답을 경험합니다. 사이트에 로그인하면 일부는 장바구니에 추가하지 못했고 일부는 체크 아웃하지 못했습니다.
따라서이 중요한 날에 회사는 많은 고객과 많은 비즈니스를 잃어 버리면서 막대한 손실에 직면해야했습니다. 이 모든 것은 회사 웹 사이트에서 부하 테스트가 수행되지 않았을 것이라고 예측 했더라도 피크 날의 사용자 부하를 예측하지 않았기 때문에 발생했습니다. 따라서 애플리케이션이 처리 할 수있는 부하를 알지 못합니다. 성수기에.
따라서 이러한 상황을 처리하고 막대한 수익을 극복하려면 이러한 유형의 애플리케이션에 대한 부하 테스트를 수행하는 것이 좋습니다.
- 부하 테스트는 강력하고 안정적인 시스템을 구축하는 데 도움이됩니다.
- 시스템의 병목 현상은 애플리케이션이 작동하기 전에 미리 확인됩니다.
- 응용 프로그램의 용량을 식별하는 데 도움이됩니다.
부하 테스트 중에 무엇을 얻을 수 있습니까?
적절한 부하 테스트를 통해 다음 사항을 정확하게 이해할 수 있습니다.
- 시스템이 처리 할 수 있거나 확장 할 수있는 사용자 수입니다.
- 각 트랜잭션의 응답 시간.
- 전체 시스템의 각 구성 요소는 응용 프로그램 서버 구성 요소, 웹 서버 구성 요소, 데이터베이스 구성 요소 등로드에서 어떻게 작동합니까?
- 부하를 처리하는 데 가장 적합한 서버 구성은 무엇입니까?
- 기존 하드웨어가 충분한 지 또는 추가 하드웨어가 필요한지 여부.
- CPU 사용률, 메모리 사용률, 네트워크 지연 등과 같은 병목 현상이 식별됩니다.
환경
테스트를 수행하려면 전용 부하 테스트 환경이 필요합니다. 대부분의 경우 부하 테스트 환경은 프로덕션 환경과 동일하고 부하 테스트 환경에서 사용 가능한 데이터는 동일한 데이터는 아니지만 프로덕션과 동일합니다.
SIT 환경, QA 환경 등과 같은 여러 테스트 환경이있을 것입니다. 이러한 환경은 동일한 프로덕션이 아닙니다. 부하 테스트와 달리 기능 테스트 또는 통합 테스트를 수행하는 데 그렇게 많은 서버 나 테스트 데이터가 필요하지 않기 때문입니다.
예:
프로덕션 환경에는 3 개의 애플리케이션 서버, 2 개의 웹 서버 및 2 개의 데이터베이스 서버가 있습니다. QA에는 애플리케이션 서버 1 개, 웹 서버 1 개, 데이터베이스 서버 1 개만 있습니다. 따라서 프로덕션과 동일하지 않은 QA 환경에서 부하 테스트를 수행하면 테스트가 유효하지 않고 잘못된 것이므로 이러한 결과를 따를 수 없습니다.
따라서 항상 프로덕션 환경과 유사한 부하 테스트 전용 환경을 갖도록 노력하십시오.
또한 시스템에서 호출 할 타사 애플리케이션이있는 경우도 있습니다. 따라서 이러한 경우에는 데이터 새로 고침이나 기타 문제 또는 지원을 위해 타사 공급 업체와 항상 협력 할 수 없기 때문에 스텁을 사용할 수 있습니다.
환경을 재 구축 할 때마다 시간 관리에 도움이되는이 스냅 샷을 사용할 수 있도록 준비가되면 환경의 스냅 샷을 찍으십시오. Puppet, Docker 등과 같은 환경을 설정하기 위해 시장에서 사용할 수있는 몇 가지 도구가 있습니다.
접근하다
부하 테스트를 시작하기 전에 부하 테스트가 이미 시스템에서 수행되었는지 여부를 이해해야합니다. 이전에로드 테스트를 수행 한 경우 응답 시간, 수집 된 클라이언트 및 서버 메트릭, 사용자로드 용량 등을 알아야합니다.
또한 현재 응용 프로그램 처리 능력이 얼마인지에 대한 정보가 필요합니다. 새로운 애플리케이션 인 경우 요구 사항, 목표 부하, 예상 응답 시간 및 실제로 달성 가능한지 여부를 이해해야합니다.
기존 애플리케이션 인 경우 서버 로그에서로드 요구 사항 및 사용자 액세스 패턴을 가져올 수 있습니다. 그러나 새로운 응용 프로그램 인 경우 모든 정보를 얻으려면 비즈니스 팀에 문의해야합니다.
요구 사항이 확보되면 부하 테스트를 실행하는 방법을 식별해야합니다. 수동으로 수행합니까 아니면 도구를 사용합니까? 부하 테스트를 수동으로 수행하려면 많은 리소스가 필요하며 비용도 많이 듭니다. 또한 테스트를 몇 번이고 반복하는 것도 힘들 것입니다.
따라서이를 극복하기 위해 오픈 소스 도구 또는 상용 도구를 사용할 수 있습니다. 오픈 소스 도구는 무료로 사용할 수 있습니다. 이러한 도구에는 다른 상용 도구와 같은 모든 기능이 없을 수 있지만 프로젝트에 예산 제약이있는 경우 오픈 소스 도구를 사용할 수 있습니다.
상용 도구에는 많은 기능이 있지만 많은 프로토콜을 지원하고 매우 사용자 친화적입니다.
부하 테스트 접근 방식은 다음과 같습니다.
# 1) 부하 테스트 허용 기준 식별
예를 들어:
- 로그인 페이지의 응답 시간은 최대로드 조건에서도 5 초를 넘지 않아야합니다.
- CPU 사용률은 80 %를 넘지 않아야합니다.
- 시스템의 처리량은 초당 100 개의 트랜잭션이어야합니다.
# 2) 테스트해야 할 비즈니스 시나리오를 식별합니다.
모든 흐름을 테스트하지 말고 프로덕션에서 발생할 것으로 예상되는 주요 비즈니스 흐름을 이해하십시오. 기존 애플리케이션 인 경우 프로덕션 환경의 서버 로그에서 정보를 얻을 수 있습니다.
새로 빌드 된 애플리케이션 인 경우 비즈니스 팀과 협력하여 흐름 패턴, 애플리케이션 사용 등을 이해해야합니다. 때로는 프로젝트 팀이 워크샵을 실시하여 애플리케이션의 각 구성 요소에 대한 개요 또는 세부 정보를 제공합니다.
애플리케이션 워크숍에 참석하고 부하 테스트를 수행하는 데 필요한 모든 정보를 기록해야합니다.
# 3) 작업 부하 모델링
비즈니스 흐름, 사용자 액세스 패턴 및 사용자 수에 대한 세부 정보를 확보 한 후에는 프로덕션에서 실제 사용자 탐색을 모방하거나 애플리케이션이 출시 될 때 예상되는 방식으로 워크로드를 설계해야합니다. 생산 중입니다.
워크로드 모델을 설계하는 동안 기억해야 할 핵심 사항은 특정 비즈니스 흐름을 완료하는 데 걸리는 시간을 확인하는 것입니다. 여기서는 사용자가보다 현실적인 방식으로 애플리케이션을 탐색 할 수있는 방식으로 생각 시간을 할당해야합니다.
작업 부하 패턴은 일반적으로 램프 업, 램프 다운 및 안정 상태입니다. 시스템을 천천히로드해야하므로 램프 업 및 다운이 사용됩니다. 정상 상태는 일반적으로 Ramp가 15 분이고 Ram이 15 분인 1 시간 부하 테스트입니다.
워크로드 모델의 예를 살펴 보겠습니다.
애플리케이션 개요 – 사용자가 애플리케이션에 로그인하여 다양한 드레스를 쇼핑하고 각 제품을 탐색 할 수있는 온라인 쇼핑을 가정 해 보겠습니다.
각 제품에 대한 세부 정보를 보려면 해당 제품을 클릭해야합니다. 제품의 가격과 제조사가 마음에 들면 장바구니에 담아 결제하고 결제하여 제품을 구매할 수 있습니다.
다음은 시나리오 목록입니다.
- 검색 – 여기서 사용자는 응용 프로그램을 시작하고 응용 프로그램에 로그인하고 다른 범주를 탐색하며 응용 프로그램에서 로그 아웃합니다.
- 찾아보기, 제품보기, 장바구니에 추가 – 여기에서 사용자는 응용 프로그램에 로그인하고, 다른 범주를 탐색하고, 제품 세부 정보를보고, 제품을 카트에 추가하고, 로그 아웃합니다.
- 찾아보기, 제품보기, 장바구니에 추가 및 결제 –이 시나리오에서 사용자는 응용 프로그램에 로그인하고, 다른 범주를 탐색하고, 제품 세부 정보를보고, 제품을 카트에 추가하고, 체크 아웃하고 로그 아웃합니다.
- 찾아보기, 제품보기, 장바구니에 담기 결제 및 결제하기 – 여기에서 사용자는 응용 프로그램에 로그인하고, 다양한 범주를 탐색하고, 제품 세부 정보를보고, 제품을 카트에 추가하고, 결제하고, 결제하고, 로그 아웃합니다.
| S. 아니 | 비즈니스 흐름 | 거래 수 | 가상 사용자로드 | 응답 시간 (초) | 허용되는 실패율 % | 시간당 거래 |
|---|---|---|---|---|---|---|
| 1 | 검색 | 17 | 1600 년 | 삼 | 2 % 미만 | 96000 |
| 두 | 찾아보기, 제품보기, 장바구니에 추가 | 17 | 200 | 삼 | 2 % 미만 | 12000 년 |
| 삼 | 찾아보기, 제품보기, 장바구니에 추가 및 결제 | 18 | 120 | 삼 | 2 % 미만 | 7200 |
| 4 | 찾아보기, 제품보기, 장바구니에 담기 결제 및 결제하기 | 이십 | 80 | 삼 | 2 % 미만 | 4800 |
위의 값은 다음 계산을 기반으로 파생되었습니다.
- 시간당 트랜잭션 = 사용자 수 * 한 사용자가 한 시간 동안 수행 한 트랜잭션.
- 사용자 수 = 1600.
- 찾아보기 시나리오의 총 트랜잭션 수 = 17.
- 각 트랜잭션에 대한 응답 시간 = 3.
- 단일 사용자가 17 개의 트랜잭션을 완료하는 데 걸린 총 시간 = 17 * 3 = 51을 60 초 (1 분)로 반올림했습니다.
- 시간당 트랜잭션 = 1600 * 60 = 96000 트랜잭션.
# 4) 부하 테스트 설계- 부하 테스트는 지금까지 수집 한 데이터 (예 : 비즈니스 흐름, 사용자 수, 사용자 패턴, 수집 및 분석 할 메트릭)로 설계되어야합니다. 또한 테스트는 훨씬 현실적인 방식으로 설계되어야합니다.
# 5) 부하 테스트 실행 – 부하 테스트를 실행하기 전에 응용 프로그램이 실행 중인지 확인하십시오. 부하 테스트 환경이 준비되었습니다. 응용 프로그램은 기능적으로 테스트되었으며 안정적입니다.
부하 테스트 환경의 구성 설정을 확인하십시오. 프로덕션 환경과 동일해야합니다. 모든 테스트 데이터를 사용할 수 있는지 확인하십시오. 테스트 실행 중에 시스템 성능을 모니터링하는 데 필요한 카운터를 추가해야합니다.
항상 낮은 부하로 시작하여 점차적으로 부하를 늘리십시오. 최대 부하로 시작하고 시스템을 중단하지 마십시오.
# 6) 부하 테스트 결과 분석 – 항상 다른 테스트 실행과 비교하기위한 기준 테스트가 있습니다. 테스트 실행 후 메트릭 및 서버 로그를 수집하여 병목 현상을 찾습니다.
일부 프로젝트에서는 애플리케이션 성능 모니터링 도구를 사용하여 테스트 실행 중에 시스템을 모니터링합니다. 이러한 APM 도구는 근본 원인을보다 쉽게 식별하고 많은 시간을 절약하는 데 도움이됩니다. 이러한 도구는 문제의 위치를 정확히 파악할 수있는 넓은 시야를 제공하므로 병목 현상의 근본 원인을 찾기가 매우 쉽습니다.
시장에 나와있는 일부 APM 도구에는 DynaTrace, Wily Introscope, App Dynamics 등이 있습니다.
# 7)보고 – 테스트 실행이 완료되면 모든 메트릭을 수집하고 관찰 및 권장 사항과 함께 테스트 요약 보고서를 관련 팀에 보냅니다.
모범 사례
다음은 부하 테스트의 모범 사례 중 일부입니다.
#1) 부하 테스트를 시작하기 전에 항상 애플리케이션 안정성을 확인하십시오. 애플리케이션은 기능 테스트 팀에 의해 기능적으로 안정적으로 서명되어야하며 빌드가로드 테스트 환경에 복사되기 전에 모든 주요 결함을 수정하고 테스트해야합니다.
#두) 로드 테스트 환경이 복제본이거나 서버 수,로드 밸런서, 서버 구성 및 방화벽을 포함하여 프로덕션 환경과 가까운 지 확인하십시오.
#삼) 테스트 데이터가 고유하고 부하 테스트를 수행하기 전에 모든 테스트 데이터가 부하 환경에 복사되었는지 확인합니다.
# 4) 프로덕션에서 발생하는 실시간 사용자 작업을 모방하는 방식으로 테스트 시나리오를 설계합니다.
# 5) 프로덕션 사용자 부하 및 비즈니스 흐름을 기반으로 워크로드를 설계하고 이전 애플리케이션의 경우 비즈니스 흐름 및 사용자 부하와 관련하여 비즈니스 팀과의 새로운 대화인지 확인합니다.
# 6) 응답 시간, 초당 적중, 처리량, CPU, 메모리, 네트워크 및 실행중인 Vusers와 같은 모든 중요한 메트릭을 수집합니다.
추천 읽기 => 시장에서 사용 가능한 성능 테스트 도구 목록 독점 부하 테스트를 수행합니다.
결론
이 자습서에서는 부하 테스트가 애플리케이션의 성능 테스트에서 중요한 역할을하는 방법, 애플리케이션의 효율성 및 기능을 이해하는 데 도움이되는 방법 등을 배웠습니다.
또한 애플리케이션에 추가 하드웨어, 소프트웨어 또는 튜닝이 필요한지 여부를 예측하는 것이 어떻게 도움이되는지 알게되었습니다.
행복한 독서 !!