Nie zgadzam się z Nathanem i Freddy do pewnego stopnia. Mają rację, że "testowanie AJAX" tak naprawdę nie różni się tym, że tworzone są żądania HTTP. Ale to nie jest takie proste. Zobacz mój artykuł na Ajaxian.com na Why Load Testing Ajax is Hard.
JMeter, Pylot i The Grinder są świetnymi narzędziami do generowania żądań HTTP (ja osobiście polecam Pylota). Ale w swojej istocie nie działają jako przeglądarka i nie przetwarzają kodu JavaScript, co oznacza, że wszystko, co robią, odtwarza ruch, który widzieli w rekordowym czasie. Jeśli żądania AJAX były unikalne dla tej sesji, mogą nie być odpowiednie/poprawne, aby odtwarzać w dużych ilościach.
Faktem jest, że w miarę przesuwania logiki do przeglądarki staje się o wiele trudniejsza (o ile nie niemożliwa) odpowiednia symulacja ruchu za pomocą tradycyjnych narzędzi do testowania obciążenia.
W tym artykule podam prosty przykład tego, jak trudno jest przetestować coś w rodzaju strony głównej Google, gdy chcesz zapytać 1000 o różne wyszukiwane hasła (ważny cel podczas testowania obciążenia).Aby to zrobić za pomocą JMeter/Pylot/Grinder, efektywnie skończysz przepisywanie części kodu AJAX (w twoim przypadku w/jQuery) w ojczystym języku narzędzia.
To staje się jeszcze bardziej złożone, jeśli celem jest zmierzenie czasu reakcji postrzeganego przez użytkownika (co jest prawdopodobnie najważniejszą rzeczą pod koniec dnia). W przypadku bardzo złożonych aplikacji wykorzystujących Comet/"Reverse Ajax" (technika, która utrzymuje otwarte gniazda przez długi czas), tradycyjne narzędzia ładujące w ogóle nie działają.
Moja firma, BrowserMob, zapewnia load testing service który używa przeglądarek Firefox, zasilanych przez Selenium, jechać setki lub tysiące prawdziwych przeglądarek, co pozwala mierzyć czas i wykonanie elementów wizualnych, jak widać w przeglądarce. Obsługujemy również tradycyjnych użytkowników wirtualnych (ślepy ruch HTTP) i symulowaną przeglądarkę (przez HtmlUnit).
Wszystko, co powiedzieliśmy, to zwykle połączenie usługi takiej jak BrowserMob z tradycyjnym testowaniem obciążenia. Oznacza to, że prawdziwe przeglądarki doskonale sprawdzają się na pełnym obciążeniu, ale nigdy nie będą tak ekonomiczne jak "wirtualni użytkownicy", ponieważ wymagają 10-100 razy więcej pamięci RAM i procesora. Zobacz mój ostatni wpis na blogu dotyczący tego, czy to simulate or not to simulate virtual users.
Nadzieję, że pomaga!