Fiddler – pierwsze skrzypce testowania

16 czerwca 2018 | Narzędzia

Praca z oprogramowaniem jest nierozłącznie związana z koniecznością poznawania wielu narzędzi – część z nich stanowi po prostu niezbędne minimum, bez którego nic nie zrobimy. Inne po prostu ułatwiają nam życie. Niektóre są genialne w swojej prostocie, a inne są technologicznymi nosorożcami, dla których nie ma rzeczy niemożliwych. Fiddler należy raczej do tej drugiej grupy, dając ogromne możliwości testerom.

Ci z Was, którzy mają już większe doświadczenie w IT o Fiddlerze na pewno przynajmniej słyszeli, a mogę się założyć, że wiele osób wykorzystywało co najmniej jedną z wielu jego możliwości. Do mnie Fiddler wraca jak bumerang, na początku kariery potrzebny był mi w zasadzie tylko do sprawdzania, czy działa funkcjonalność przełączania na zapasowy stream video w przypadku awarii głównego. Potem, dla poszerzania wiedzy, troszeczkę bawiłam się testowaniem API. A teraz wykorzystuję jego możliwości m.in do testów wydajności. No bo… czego ten nasz Skrzypek nie potrafi?

Po co to komu? Komu to potrzebne?

Fiddler jest powszechnie znany jako “web proxy debugger” – i już samo to określenie może nas nakierować, z czym mamy do czynienia: znajdując się pomiędzy klientem a serwerem, przechwytuje ruch HTTP/HTTPS i wyświetla go użytkownikowi. A także pozwala na jego modyfikowanie. I w tym miejscu może urodzić się pytanie – po co to robić?

Znakomita większość aplikacji do komunikacji wykorzystuje protokół Hypertext Transfer Protocol, powszechnie znany jak HTTP: witryny internetowe, usługi RESTful czy nawet interfejsy API SOAP l. I na co dzień, gdy budujemy i weryfikujemy te aplikacje, ani programiści, ani my, testerzy, nie martwimy się za bardzo tym, co dzieje się na poziomie sieci. Ale jednak od czasu do czasu możemy natrafić się problem, który będzie wymał od nas wyjścia poza schemat i obniżenia do poziomu sieci, aby dowiedzieć się, co się dzieje. W przypadku aplikacji webowych możemy po prostu otworzyć konsolę i wielu przypadkach to wystarczy i załatwi sprawę. Ale już w przypadku klientów desktopowych komunikujących się z serwerem czy API sprawa już nie jest taka prosta i oczywista. A i w webowkach funkcje oferowane przez przeglądarkę mogą być zbyt ubogie na nasze potrzeby.

Wsparcie testów manualnych

Testując aplikację desktopową zdarzyło mi się trafić na jakieś nietypowe działanie, niekoniecznie zakończone oczywistym błędem z walącym po oczach komunikatem z wielkim czerwonym “iksem” i napisaem “Error”. Czasami aplikacja po prostu się zawiesza czy nie wykonuje jakiegoś polecenia. Wtedy odpalam FIddlera – przeglądając sesję za sesją mogę trafić na coś, co może znacznie ułatwić inwestygację problemu, a czasem wręcz wprost wskazać, co należy poprawić: czasem jest to gdzieś ukryty kod odpowiedzi 500, innym razem puste, lecące gdzieś w eter zapytanie.

Fiddler mi się przydał też w czasach, gdy musiałam testować aplikację przy ograniczonej prędkości łącza czy też sprawdzić poprawność przełączania na zapasowe pasmo. Fakt, że w tej pierwszej sytuacji lepiej sprawdza się Charles (o nim też napiszę kilka słów, bo… jest tego wart :P), ale może niektórzy – podobnie do mnie – preferują mniejszą liczbę zainstalowanych narzędzi.

Co jest fajne, to że nie musimy się ograniczać do systemu czy przeglądarki. Przy odrobinie gimnastyki możemy wykorzystać monitorowanie ruchu sieciowy także do testów aplikacji mobilnych.

Testy wydajności

Wydajność zwykle jest mocno sprzężona z ruchem sieciowym i tym, jak komunikacja jest mocno obciążona. Już samo to nasuwa wniosek, że wykorzystując dane uzyskane za pomocą FIddlera możemy uzyskać sporo informacji na temat wydajności naszego systemu. Może wydać się to banalne, ale już sam czas rozpoczęcia i trwania każdej sesji które uzyskujemy dzięki narzędziu, może być podstawą do wysnucia ciekawych wniosków. Analizując poszczególne sesje łatwo też dojdziemy do “wąskich gardeł” czy “ślepych zaułków” oznaczonych po prostu… czerwoną ikonką X.

Testy API

Wspomniałam wcześniej, że w ilości narzędzi jestem raczej minimalistką. I choć sama do trudniejszych zadań korzystam z Postmana, to do tych prostszych FIddler w zupełności wystarczy. Wbudowany w Fiddlera “Composer” daje nam w zasadzie całkiem podobne możliwości do tych, które znajdziemy w Postmanie. No, może nie tak atrakcyjne graficznie i pozbawione możliwości “wyklikania”, ale za to pozwalające na jednoczesne obserwowanie ruchu sieciowego.

To tylko kilka z wielu możliwości Fiddlera. Mogłabym też wspomnieć o dodatkach, jakie po wpięciu do tego narzędzia umożliwią nam wykonywanie testów bezpieczeństwa, albo wyniosą testowanie wydajności na inny poziom. Ale o tym może innym razem 🙂 A Wy? Korzystacie z Fiddlera? A może z innego narzędzia monitorowania ruchu?

Najnowsze wpisy

CzytanQA: Duch w sieci

Gdyby ktoś zapytał mnie o największego trolla w historii IT, to bez mrugnięcia okiem odpowiedziałabym: Kevin Mitnick. A jego autobiografia, napisana wespół z Williamem L. Simonem jest tego najlepszych dowodem.

#4 Antywzorce w testowaniu oprogramowania: Testowanie niewłaściwej funkcjonalności

Każdy, kto ma odrobinę doświadczenia w testowaniu oprogramowania wie, jak trudne jest uzyskanie stuprocentowego pokrycia kodu testami.

CzytanQA: Social skills for information security professionals

Kiedy tylko Dawid Bałut na swoim profilu poinformował, że jego pierwsza anglojęzyczna książka jest już dostępna, od razu wiedziałam, co następne pojawi się w serii CzytanQA.

Pin It on Pinterest

Podoba Ci się wpis?

Podziel się ze znajomymi!