. "AJAX 테스팅"은 HTTP 요청이 만들어지는 점에서 전혀 다르지 않다는 것이 맞습니다. 그러나 그렇게 간단하지는 않습니다. Ajaxian.com의 내 기사를 Why Load Testing Ajax is Hard에 게시하십시오.
JMeter, Pylot 및 The Grinder는 모두 HTTP 요청을 생성하는 데 훌륭한 도구입니다 (개인적으로 Pylot을 권장합니다). 그러나 핵심은 브라우저와 자바 스크립트로 작동하지 않기 때문에 기록적인 시간에 본 트래픽을 재생한다는 것입니다. AJAX 요청이 해당 세션에 대해 고유 한 것이면 대용량으로 재생하기에 적합하지 않을 수 있습니다.
사실 더 많은 로직이 브라우저에 푸시 다운되면 기존로드 테스트 도구를 사용하여 트래픽을 올바르게 시뮬레이션하는 것이 훨씬 더 어려워집니다 (불가능하지는 않지만).
필자는 1000 개의 다른 검색어 (로드 테스트 중 중요한 목표)를 쿼리하려는 경우 구글 홈 페이지와 같은 것을 테스트하는 것이 얼마나 어려운 지 간단한 예를 들어 설명합니다.JMeter/Pylot/Grinder를 사용하면 도구의 모국어로 AJAX 코드의 일부를 다시 작성할 수 있습니다.
사용자가 감지 한 응답 시간을 측정하는 것이 목표 인 경우 훨씬 더 복잡해집니다 (이는 하루가 끝날 때 가장 중요한 것임). Comet/"Reverse Ajax"(오랜 시간 동안 열린 소켓을 유지하는 기술)를 사용하는 정말로 복잡한 응용 프로그램의 경우 기존의로드 도구가 전혀 작동하지 않습니다.
내 회사 인 BrowserMob은 Selenium으로 구동되는 Firefox 브라우저를 사용하여 수백 또는 수천 개의 실제 브라우저를 구동하여 브라우저에 표시되는 시각적 요소의 성능을 측정하고 시간을 측정 할 수 있습니다. 또한 전통적인 가상 사용자 (블라인드 HTTP 트래픽)와 가상 브라우저 (HtmlUnit 경유)를 지원합니다.
일반적으로 BrowserMob과 같은 서비스와 전통적인 부하 테스트를 혼합하면 올바른 접근 방식이라고 할 수 있습니다. 즉, 실제 브라우저는 완전한 충실도 테스트에 적합하지만 "가상 사용자"만큼 경제적이지는 않습니다. RAM과 CPU가 10 ~ 100 배 더 필요하기 때문입니다. simulate or not to simulate virtual users에 대한 최신 블로그 게시물을 참조하십시오.
희망 하시겠습니까?