Tag: zakodowane

Niezależnie od rozmiaru projektu, firmy lub zastosowanej technologii, można zauważyć te same rodzaje błędów związanych z testowaniem wydajności oprogramowania.Nie jest to rzecz zaskakująca, ponieważ ludzka natura jest taka sama niezależnie od firmy, a każde środowisko projektowe i biznesowe ma terminy i deadliney, których musi dotrzymać. Czasami sytuacja wymaga tego, że testowaniem zajmujemy się bardzo szybko i wykonujemy je pobieżnie.  Niestety droga „na skróty” może prowadzić do kosztownych błędów i niedopatrzeń.
Jednak dzięki odrobinie samoświadomości i kilku pomocnym narzędziom towarzyszącym można w łatwy sposób wyeliminować te błędy.

1. Nieadekwatny User Think Time – czas od zakończenia jednego żądania do rozpoczęcia następnego żądania

Bombardowanie aplikacji czy programu setkami lub tysiącami żądań na sekundę bez żadnego czasu na przetworzenie zapytań (think time) powinno być stosowane tylko w rzadkich przypadkach, w których konieczne jest zasymulowanie tego typu zachowania – ataku Denial of Service (atak na system komputerowy lub usługę sieciową w celu uniemożliwienia działania poprzez zajęcie wszystkich wolnych zasobów). 99% osób nie testuje jednak tego scenariusza tylko próbują sprawdzić, czy ich strona może obsłużyć obciążenie docelowe. W takim przypadku czas przetworzenia informacji (think time) jest bardzo ważny.

Wiele osób przeprowadza testy bez uwzględniania czasu przetworzenia informacji (think time) z tysiącami użytkowników a następnie zadaje pytanie: dlaczego moje czasy odpowiedzi są wolne? Kiedy ręcznie odwiedzam witrynę za pomocą mojej przeglądarki, wydaje się, że odpowiada ona dobrze.

Dość łatwo można rozwiązać ten problem, dodając pewnego rodzaju czas oczekiwania/oczekiwania pomiędzy krokami użytkownika wirtualnego, skutecznie spowalniając użytkownika do bardziej realistycznego tempa. Prawdziwy użytkownik nigdy nie wykonałby żądań strony w ciągu 1 sekundy. Czas myślenia pozwala dodać ludzką pauzę, naśladując prawdziwą osobę, która będzie czekać kilka sekund, zanim wejdzie w interakcję z witryną. Prostym rozwiązaniem jest użycie losowego zegara Gaussa podczas projektowania testów, który pozwala użytkownikom na interakcję w sposób losowy, tak jak w rzeczywistym świecie.

2. Używanie niedokładnego modelu obciążenia

Model obciążenia jest szczegółowym planem, zgodnie z którym powinno się programować kolejne funkcjonalności aplikacji czy strony internetowej. Model ten powinien zawierać opis procesów biznesowych, wymaganych kroków, liczby użytkowników, liczby transakcji na użytkownika i obliczonego tempa dla każdego użytkownika.

Posiadanie dokładnego modelu obciążenia ma kluczowe znaczenie dla ogólnego sukcesu testów i późniejszego działania systemu w ogóle. Często łatwiej to powiedzieć, niż zrobić, ponieważ wymagania biznesowe nie były uważane za wykraczające poza stwierdzenie, że „system powinien być szybki”.

W przypadku istniejących aplikacji czy sklepów internetowych zawsze warto mieć dostęp do statystyk, które pokażą wiele informacji, takich jak:
• Jakie są najczęstsze/najbardziej popularne transakcje?
• Ile transakcji odbywa się w typowy dzień roboczy?
• Ile z każdego rodzaju transakcji odbywa się w szczytowych okresach aktywności użytkowników?
• Jakie są ogólne czasy lub okresy, w których transakcje te występują?
• Jakie transakcje wiążą się z wysokimi kosztami biznesowymi, jeśli miałyby zawieść w przypadku dużego obciążenia?

Na podstawie tych kryteriów można stworzyć obraz modelu obciążenia, który należy symulować.
W przypadku nowych systemów/sklepów internetowych ogólną zasadą jest jak największa współpraca z przedstawicielami biznesu. Celem tego jest ustalenie realnych i uzgodnionych danych, które są dobrze zdefiniowane, proste i możliwe do przetestowania.

Po pierwszym cyklu związanym z testowaniem i uruchomieniu aplikacji, bieżące monitorowanie użycia zasobów pomoże uzyskać informacje zwrotne dla następnej rundy związanym z testowaniem, w której model obciążenia systemu może być dalej dostosowywany.

3. Konfigurowanie niewłaściwego monitorowania infrastruktury

Wyniki testów wykonywalności, takie jak przepustowość, czasy odpowiedzi transakcji i informacje o błędach, nie są zbyt pomocne, chyba że można zobaczyć, w jaki sposób infrastruktura docelowa radzi sobie ze scenariuszem.

Jest to powszechny problem. Wielu testerów zadaje sobie pytanie, dlaczego czas reakcji zajmuje minuty zamiast sekund. Problem może leżeć albo w generowaniu obciążenia, albo w docelowej infrastrukturze aplikacji.

Jak sobie z tym poradzić? Idealnym rozwiązaniem jest posiadanie niestandardowych pulpitów kontrolnych dla całej infrastruktury generowania obciążenia na żądanie. Niektóre platformy związane z testowaniem, takie jak Tricentis Flood, udostępniają niestandardowe raporty monitorowania. Umożliwiają one przeglądanie wykorzystania zasobów systemowych podczas wykonywania testów, zapewniając, że nie występują żadne „wąskie gardła” po stronie infrastruktury systemu.

Po stronie docelowej aplikacji można zaimplementować je, aby zdiagnozować problemy lub spowolnienia działania aplikacji / systemu podczas testów. W tej chwili dostępnych jest co najmniej 100 usług monitorowania aplikacji – wszystkie z różnymi cenami i funkcjami. Korzystając z wielu popularnych usług, takich jak New Relic, AppDynamics i Splunk należy pamiętać, że mogą być one dość kosztowne w przypadku opcji pełnego monitorowania. Istnieje również kilka darmowych alternatyw open-source, takich jak Nagios i InspectIT. Nie są tak dopracowane, ale przy odrobinie wiedzy i czasu poświęconego na ich ustawienie, rozwiązanie to może być bardziej opłacalne.

4. Używanie zakodowanych danych w każdym zapytaniu

Używanie tych samych danych w żądaniu HTTP dla każdego użytkownika nie jest realistycznym scenariuszem użycia systemu. Często inteligentne aplikacje i istniejąca technologia baz danych rozpoznają identyczne żądania i automatycznie je buforują, dzięki czemu ogólny system wydaje się szybszy niż jest. Prowadzi to do nieprawidłowego testu wydajności.

Pomyślmy o prostej czynności rejestrowania nowego użytkownika dla typowej witryny zakupów on-line. Większość (jeśli nie wszystkie) strony nie pozwalają na zarejestrowanie tego samego użytkownika więcej niż jeden raz bez podania konkretnych informacji.

Nie będziemy w stanie dalej przesyłać tego żądania do witryny sklepowej, ponieważ wymagana jest pewna weryfikacja, szczególnie w polach numeru kontaktowego czy adresu e-mail.
Zamiast tego możemy uczynić te dwa pola unikalnymi, więc za każdym razem uda nam się pomyślnie uruchomić test. Dzięki open-sourcowemu programowi JMeter możemy łatwo korzystać z wbudowanych generatorów liczb losowych. Aby pola takie jak numery telefonów i adresy e-mail były niepowtarzalne.

Kiedy uruchamiamy aplikację w teście obciążenia, każde pojedyncze żądanie będzie miało inny numer telefonu komórkowego i adres e-mail. Ten prosty przykład użycia dynamicznych danych dla wszystkich żądań może zaoszczędzić wielu nieprawidłowych testów.

5. Ignorowanie błędów systemu lub skryptu, ponieważ czasy odpowiedzi i przepustowość wyglądają dobrze

Bardzo łatwo jest wyeksponować szczegóły, które mogą mieć ogromny wpływ na ważność testu. Oto typowy scenariusz:

Test obciążenia działa z docelową liczbą użytkowników, a tester widzi, że czasy odpowiedzi i poziomy błędów mieszczą się w dopuszczalnych zakresach. Oczekiwana przepustowość jest jednak niższa, niż zakładano. Jak to możliwe, gdy platforma związana z testowaniem obciążenia zgłasza bardzo mało błędów związanych z transakcjami?

Może się zdarzyć, że napotkamy błędy systemowe, które nie są zgłaszane w liczbie transakcji/nieudanych transakcji – dlatego wszystko wygląda dobrze na pierwszy rzut oka. Niższa niż oczekiwana liczba transakcji na minutę lub wartość RPM jest znakiem rozpoznawczym tego problemu.

Przejście do dzienników „run time” ujawni problem po stronie skryptów, który można następnie naprawić. Kiedy czas odpowiedzi, liczba błędów i przepustowość znajdują się w oczekiwanej strefie, czy można myśleć, że wszystko jest ok?

Jeszcze nie teraz. Niemal zawsze jest przeoczony obszar, który może mieć wpływ na testy obciążenia: weryfikacja rzeczywistych dzienników systemu lub aplikacji podczas testu.

Można to łatwo monitorować, jeśli używa się specjalnie zbudowanego narzędzia APM (Application Performance Monitoring), takiego jak New Relic lub AppDynamics. Należy jednak pamiętać dużo czasu zajmie ręczne konfiguracja danego narzędzia.

Wyjątki mogą być spowodowane różnymi czynnikami, co oznacza, że należy dokładnie przeanalizować, dlaczego zostały spowodowane przez scenariusz testu obciążenia i jakie mają one wpływ na wydajność i stabilność systemu.

Wyjątki często wiążą się z olbrzymim obciążeniem wydajności związanym z procedurami ich obsługi i wszelkim powiązanym protokołowaniem z operacjami na dyskach lub w pamięci. Może to nie stanowić problemu przy pojedynczej transakcji, ale jeżeli pomnożymy ją przez ponad 1000 równoczesnych użytkowników i może to poważnie wpłynąć na szybkość reagowania systemu.