W ramach naszej witryny stosujemy pliki cookies w celu świadczenia Państwu usług na najwyższym poziomie. Więcej szczegółów w naszej Polityce Prywatności.

Nazywam się Charles, w czym mogę pomóc?

Styczeń 10, 2018 Anna Marchlewicz

Chciałabym opowiedzieć o tym, jak Charles pomógł mi podczas pracy w projekcie. Kim on jest? Charles jest narzędziem debugującym proxy. Bez jego pomocy nie byłoby możliwe przetestowanie nowych funkcjonalności wprowadzonych w aplikacjach mobilnych, które rozwijał mój zespół.

W przypadku standardowych modułów tychże aplikacji zespół backendowy dostarczał tzw. „rozszerzenia” dla zespołu testowego, co pozwalało na symulowanie najczęściej występujących błędów, zwracanych przez backendowe API. Jego użycie było bardzo proste i wystarczyło jedynie wysłać parametry w formie JSON-a dla wybranego zapytania i użytkowania. Muszę tu przyznać, że był to przykład świetnej współpracy między zespołem testowym a deweloperskim i sprawiał, że nasza praca była łatwiejsza.

Dla nowej funkcjonalności został stworzony nowy moduł po stronie backendu, który niestety nie mógł korzystać z wcześniejszych „rozszerzeń”. Z tego powodu powstało pytanie, jak można symulować błędy zwracane przez serwer bez pomocy programistów?

Narzędzie proxy

Od początku było wiadomo, że będziemy potrzebować narzędzia debugującego proxy. Pierwszym i najbardziej oczywistym wyborem był Fiddler. Posiadał on niezbędne dla naszych potrzeb opcje, więc zdecydowaliśmy się go użyć. Jednak szybko okazało się, że jest on przydatny jedynie na komputerze z systemem Windows, a nie z OS X / Mac OS. Problemem było nawet jego uruchomienie, nie mówiąc już o jakichkolwiek testach. W związku z tym potrzebna była alternatywa. Znaleźliśmy i wzięliśmy pod uwagę dwie opcje: Burp Suite i Charles Proxy. Oba programy dobrze sprawdzały się na Mac OS, ale ten drugi – Charles – miał zdecydowanie bardziej intuicyjny interfejs. Nawet dla takiego nowicjusza jak ja było jasne jak go używać.

Interfejs aplikacji Charlie

Ustawianie proxy na urządzeniach mobilnych

Ustawienie HTTP proxy na urządzeniach mobilnych (iPhone’y, telefony z Androidem) nie było trudne. W ustawieniach Wi-Fi wystarczyło wybrać „Ustawienie serwera proxy”, gdzie wpisałam mój adres IP i domyślny port (8888, który bez problemu można zmienić). Teraz wszystkie zapytania z moich urządzeń mobilnych były nagrywane w Charles.

Ustawienie proxy na urządzaniach mobilnych

Breakpoints

Mogłam również przerwać zapytanie w trakcie jego wykonywania za pomocą funkcji „Breakpoints”. Charles udostępniał dwie opcje: modyfikowanie zapytania oraz modyfikowanie odpowiedzi. W większości przypadków wystarczające było zmodyfikowanie otrzymanej odpowiedzi, zmieniając „200 OK” na „500 Internal Server Error” lub „498 Invalid Token”.

Edycja odpowiedzi zapytania

Wykorzystując opcję Breakpoints, byłam w stanie sprawdzić, czy testowana aplikacja działa poprawnie w przypadku otrzymania kodu błędu w odpowiedzi. Sprawiło to, że mogłam testować również negatywne przypadki testowe.

SSL proxying

Ponieważ był to początek implementacji nowej funkcjonalności, całość działała dobrze po HTTP. Wraz z postępem prac, serwis zaczął być dostępny po HTTPS. Nie było to jednak problemem, gdyż Charles pozwala również na SSL proxying.

SSL proxying

Niestety to okazało się nie być takie proste. Aplikacje mobilne (zarówno iOS, jak i Android) miały wbudowany SSL pinning i nie było możliwe kontynuowanie pracy bez pomocy deweloperów. Aby móc dalej pracować, zgłosiłam zadania do obu zespołów, aby w wersji debug aplikacji wyłączyć SSL pinning. Zespół iOS-owy zgodził się na dodanie specjalnej opcji do wersji debugowych, która umożliwiała wyłączenie SSL pinningu. Z kolei programiści z zespołu Android stwierdzili, że dodawanie takiej opcji nie jest bezpieczne, ponieważ zbyt głęboko ingeruje w strukturę i odmówili implementacji. W tej sytuacji trzeba było znaleźć inne rozwiązanie. Z pomocą Charlesa możliwe było dodanie wygenerowanego certyfikatu do aplikacji w wersji debugowej.

Zapisanie certyfikatu z aplikacji Charles

W ten sposób ponownie było możliwe sprawdzanie komunikacji na obu platformach.

Ponownie o Breakpoints

Na następnym etapie implementacji nowej opcji, zostało dodane nowe zapytanie dotyczące dostępu, które miało ograniczyć liczbę użytkowników, mogących z nowej funkcji skorzystać. W środowisku testowym limit wynosił 100 użytkowników, co w efekcie powodowało, że wszystkie konta testowe miały ten dostęp. Programista backendu zasugerował, że jest możliwe zablokowanie dostępu dla kont testowych, poprzez użycie następującej procedury: usunięcie swojego użytkownika, następnie poproszenie programisty o zmianę limitu na 0 (czyli żaden nowy użytkownik nie dostanie dostępu) i przetestowanie tego scenariusza. Po wszystkich testach należało ponownie poprosić programistę o przywrócenie wcześniejszego limitu. Brzmi jak żart, prawda? Niestety to faktycznie zaproponował zespół backendowy. Również w tym przypadku Charles okazał się bardzo pomocny. Mogłam pominąć tę skomplikowaną procedurę dzięki możliwości edycji treści odpowiedzi w przypadku zapytania o dostęp.

Rewrite

Nowa funkcjonalność działała świetnie do czasu, gdy serwer testowy został przeniesiony na inną instancję. Nieoczekiwanie podczas próby zalogowania się do aplikacji, był zwracany pewien konkretny kod błędu. W tym przypadku aplikacja powinna 3 razy sprawdzić dostęp do usługi, ale aplikacja iOS-owa robiła to nieustannie. Po stronie backendowej problem został rozwiązany bardzo szybko, ale konieczne było przetestowanie poprawek również po stronie aplikacji mobilnej. Wyzwaniem było zasymulowanie takiej sytuacji. Użycie Breakpoints byłoby uciążliwe: ustawienie breakpointu, zatrzymanie na odpowiedź, zmodyfikowanie odpowiedzi, wysłanie zmodyfikowanej odpowiedzi, zatrzymanie na odpowiedź, zmodyfikowanie odpowiedzi, wysłanie zmodyfikowanej odpowiedzi i tak dalej. Nie brałam tego nawet pod uwagę. Szczęśliwie Charles ma kolejną, świetną opcję: Rewrite. Umożliwiała ona ustawienie kodu odpowiedzi dla wybranego zapytania bez ręcznego modyfikowania jej za każdym razem.

Nadpisywanie odpowiedzi

Co więcej, raz przygotowaną listę breakpointów można było wyeksportować i przekazać innym osobom w zespole testowym.

Throttling

Charles posiada także funkcję modyfikacji jakości połączenia sieciowego, zwaną Throttling. Pozwala ona także na wybranie hosta, dla którego będzie to ograniczenie działać. Z tego właśnie powodu był to dla mnie lepszy wybór niż Network Link Conditioner na moim komputerze. Oczywiście mogłam użyć opcji developerskiej na iPhonie, ale nie ma ona odpowiednika na urządzeniach z system Android.

Ustawienie ograniczeń połączenia

Z perspektywy czasu jestem przekonana, że ukończenie tej części projektu nie byłoby możliwe bez aplikacji Charles.

Podsumowanie

Charles udostępnia znacznie więcej ciekawych funkcji, oprócz tych opisanych powyżej. Jedną z nich, Map Local, odkryłam znacznie później i wykorzystywałam do zmiany treści odpowiedzi, zamiast ustawiać breakpointy i ręcznie modyfikować treść.

Dzięki wykorzystaniu Charlesa, testowanie aplikacji mobilnych stało się łatwiejsze, a aplikacja pozwala na testowanie przypadków błędów.

Charles Proxy: https://www.charlesproxy.com/buy/

newsletter paper plane icon
newsletter paper plane icon

Thank you!

We will get back to you soon.

Najnowsze wpisy