먼저 성능 테스트를 수행하는 이유는 무엇입니까?
성능이 좋지 않은 앱은 일반적으로 기업이 기대하는 이익을 달성하지 못하고 많은 시간과 비용이 들지만 사용자들 사이에서 신뢰도를 잃습니다.
기능 테스트 및 승인 테스트에 비해 성능 테스트는 간과되기 쉽고 출시 후 성능 및 확장성 문제가 발생한 후에야 그 중요성이 실현되는 경우가 많습니다.
특정 웹사이트 성능 테스트 사례 공유
웹사이트는 멤버십 템플릿 다운로드, 업로드, 구매, 결제 및 기타 기능을 제공합니다. 현재 성능 테스트 단계에 진입하고 있으며 성능 요구 사항을 통해 다음 성능 지표를 테스트해야 함을 알 수 있습니다.
● 제품 페이지 새로 고침 성능
● 제품 업로드 성능
● 제품 다운로드 성능
현재 표시된 지표는 다음과 같습니다.
지연:
테스트 항목 응답 시간 지터 노트
제품 페이지 새로 고침 제품 다운로드 응답 시간 처리량:
번호가 매겨진 항목 처리량
Perf.T.1 로그인한 모든 사용자의 온라인 상태 변경 빈도는 10분마다 한 번입니다.
Perf.T.2 일일 평균 페이지 방문 횟수는 60,000회
Perf.T.3 일일 다운로드 50,000
Perf.T.4 하루 평균 신규 회원 수는 500명입니다
Perf.T.5 동일한 템플릿의 최대 다운로드 볼륨은 동시 다운로드 사용자 100명입니다.
Perf.T.6 다양한 템플릿의 최대 다운로드 볼륨 동시 사용자 다운로드 수는 150입니다
용량:
번호가 매겨진 항목 용량
Perf.C.1 사용자 수 <= 100만
Perf.C.2 활성 사용자 수 10,000
Perf.C.3 총 템플릿 센터 사용자 수 < ;= 250,000
위의 성능 요구 사항과 데이터를 바탕으로 성능 테스트 케이스와 시나리오를 어떻게 설계해야 할까요? (주어진 성능 요구 사항은 쓰레기이고 전혀 가치가 없다고 할 수 있지만 할 수밖에 없습니다.)
우선 요구되는 성능에는 관심이 없습니다. 특정 테스트 환경에서 시스템을 테스트하기 위해 스트레스 테스트를 수행하고 각 성능 지표의 중요 지점을 찾으면 됩니다.성능 지표에 도달했는지 여부는 성능 요구 사항을 기반으로 테스트 보고서를 작성하면 됩니다.
따라서 성능 테스트가 필요한 페이지에 대해 분석을 수행하고 시스템 성능을 최대한 정확하게 반영하도록 시나리오를 설계하는 방법을 살펴보겠습니다.
먼저 검색 페이지에 대해 이야기해 보겠습니다.
검색 페이지는 다음과 같습니다. 프로젝트에 대한 이해를 바탕으로 검색 후, 조건에 맞는 모든 결과를 순회하여 전경에 표시합니다. 각 페이지에 표시된 숫자는 확실하며, 초과된 부분은 페이지에 표시됩니다. 위의 설명에 따르면 검색 결과는 조건을 충족하는 모든 결과 집합을 첫 페이지로 보내는 것을 볼 수 있으며, 페이지 표시의 성능 소모는 데이터 전송, SQL 실행 및 응용 프로그램에서 발생한다는 점을 무시할 수 있습니다. 서버의 처리 프로세스이므로 다음 두 가지 측면에서 시나리오를 설계할 수 있습니다.
a. 가상 사용자가 확실하고 데이터베이스의 크기가 서로 다른 경우 검색 성능이
가상 사용자 수를 결정하는 방법이 됩니다. 키를 고객에게 정기적으로 제공하도록 요청할 수 있습니다. 이 경우 매일 방문하는 사용자 수(참고할 실제 데이터가 없는 경우 제품 계획에서 예상 사용자 수로 대체될 수 있음)를 제공합니다. 이 사용자 수를 테스트에 사용합니다. 시스템이 1년 동안 작동하는 경우 다양한 데이터베이스 규모를 분석해 보겠습니다. 제품 데이터의 양이 50,000이면 그에 따라 1W, 3W, 5W, 10W 및 20W의 데이터 볼륨을 사용합니다. 이 값을 테스트용으로 설정하므로(구체적인 분할 방법은 실제 상황에 따라 결정될 수 있음), 이 테스트 목표를 위해 5가지 시나리오를 설계할 수 있습니다.
가상 사용자 수 데이터베이스 규모 기록 페이지의 동시 사용자 수 실행 time 생각시간
100 10000 참여를 위한 30분 동안 검색페이지가 랜덤하게 생성됩니다. 생각시간
100 30000 참여를 위한 30분 동안 검색페이지가 랜덤하게 생성됩니다. 생각시간
100 50000 검색페이지가 랜덤하게 생성되어 참여시간이 30분 추가됩니다
100 100000 검색 페이지가 무작위로 30분 생성되어 사고 시간 추가
100 200000 검색 페이지가 무작위로 30분 생성되어 사고 시간 추가
b 특정 데이터베이스 규모, 다양한 가상 사용자 수 상황에 따라 검색 성능
을 설정했습니다. 정기적인 데이터베이스 데이터 볼륨, 데이터 볼륨이 변하지 않은 상태에서 가상 사용자 수를 점진적으로 늘리고 다양한 가상 사용자 압력 하에서 시스템 성능을 테스트합니다.
가상 사용자 수는 데이터베이스 및 기록 페이지 동시성 순입니다. 사용자 실행 시간 생각 시간
50 50000 검색 페이지가 무작위로 30분을 생성하여 생각 시간 추가
80 50000 검색 페이지가 무작위로 30분을 생성하여 생각 시간 추가
100 50000 검색 페이지가 무작위로 30분을 생성하여 생각 시간 추가
120 50000 검색 페이지 30분을 무작위로 생성하여 사고 시간을 추가합니다
150 50000 검색 페이지에서 무작위로 30분을 생성하여 사고 시간을 추가합니다
상품 업로드
업로드 성능에 영향을 미치는 주요 요인은 업로드된 파일의 크기와 업로드된 요청 수이므로 저희는 디자인합니다. 이 두 가지 측면의 사용 사례.
a. 가상 사용자 수는 일정하며 다양한 크기의 파일을 업로드할 수 있습니다.
가상 사용자 수 업로드 파일 크기 녹화 페이지 동시 사용자 수 실행 시간 생각 시간
50 100k 업로드 페이지는 30분 동안 무작위로 생성됩니다. 생각 시간
50 300k 업로드 페이지는 30분 동안 무작위로 생성됩니다. 생각 시간을 취소하는 데는 분
50 500k 업로드 페이지는 생각 시간을 취소하는 30분을 무작위로 생성합니다
50 800k 업로드 페이지는 생각 시간을 취소하는 30분을 무작위로 생성합니다
50 1M 업로드 페이지는 취소하기 위해 30분의 시간을 무작위로 생성합니다.
b 업로드되는 파일의 크기는 일정하며, 양은 다릅니다. 가상 사용자
가상 사용자 수 업로드 파일 크기 동시 사용자 기록 페이지 수 실행 시간 생각 시간
20 300k 업로드 페이지는 30분 동안 무작위로 생성됩니다. 취소 대기 시간
50 300k 업로드 페이지는 30분 동안 무작위로 생성됩니다. 취소 대기 시간
80 300k 업로드 페이지는 무작위로 생성되어 사고 시간 취소 30분
100 300k 업로드 페이지는 30분의 취소 사고 시간을 무작위로 생성합니다
제품 다운로드
다운로드 성능에 영향을 미치는 주요 요소는 다운로드 파일의 크기와 다운로드 요청 횟수이므로 이 두 가지 측면에서 사용 사례를 설계합니다
a, 가상 사용자 수는 일정하며 다양한 크기의 파일을 다운로드합니다.
가상 사용자 수 다운로드 파일 크기 녹화 페이지 동시 사용자 수 실행 시간 Thinking time
50 100k 다운로드 페이지에서 무작위로 30분의 취소 Think Time이 생성됩니다.
50 300k 다운로드 페이지에서 무작위로 30분의 취소 사고 시간 생성
50 500k 다운로드 페이지에서 무작위로 30분의 사고 취소 시간 생성
50 800k 다운로드 페이지에서 무작위로 30분의 사고 취소 시간 생성
50 1M 다운로드 페이지에서 무작위로 30분의 사고 취소 시간 생성 시간
b. 다운로드 파일 크기는 일정하며, 가상 사용자 수는 다릅니다
다운로드하는 가상 사용자 수 파일 크기 녹화 페이지의 동시 사용자 수 실행 시간 생각 시간
20 300k 다운로드 페이지는 30분을 무작위로 생성합니다. 취소 사고 시간
50 300k 다운로드 페이지에서 취소 사고 시간 30분을 무작위로 생성
80 300k 다운로드 페이지에서 취소 사고 시간 30분을 무작위로 생성
100 300k 다운로드 페이지에서 취소 사고 시간 30분을 무작위로 생성
위 내용은 웹 성능 테스트 사례 설계 분석의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!