14 postów z tagiem "Testing"

Rozdział 6 „Generative AI Design Patterns" opisuje cztery wzorce niezawodności: LLM-as-Judge, Reflection, Dependency Injection i Prompt Optimization. Wszystkie opierają się na ewaluatorze, więc to on decyduje, co system uzna za dobry wynik. Sprawdziłem dwa z tych wzorców na Qwen3.8-27B na stacji z RTX 5090. Jedna runda samokrytyki tym samym modelem podniosła wynik na 60 zadaniach kalendarzowych z 42 do 45. Krytyk przepuścił jednak połowę błędów, a jedną poprawną odpowiedź zepsuł. Automatyczny test, który mówił tylko „źle", podniósł wynik do 54, a poprawnych odpowiedzi z założenia nie ruszał. W Prompt Optimization obaj sędziowie wybrali prompt lepszy od bazowego, co zgadza się z autorami. Sędzia z ogólną rubryką ocenił jednak wyżej od bazowego także prompt, który ani razu nie podał numeru zgłoszenia.

Uruchomiłem NVIDIA garak, otwartoźródłowy skaner podatności modeli językowych, przeciwko Qwen3.8-27B INT4 z poprzednich wpisów. Garak dostał polecenie tłumaczenia ataków na polski. Probe promptinject zgłosił 0 udanych wstrzyknięć na 96 prób. Kiedy przejrzałem odpowiedzi ręcznie, wyszło 16 przypadków, w których model wypisał dokładnie to, co kazała mu wstrzyknięta instrukcja. Przyczyna leży w garak, nie w modelu: fraza, którą atak każe powtórzyć, jest w prompcie tłumaczona na polski, a wzorzec, którego szuka detektor, zostaje po angielsku. Zgłosiłem to jako błąd. Poprawka zaproponowana przez innego kontrybutora przechodzi swoje testy, ale na prawdziwym tłumaczeniu wykrywa 4 z tych 16 przypadków.

Magento 2 (obecnie Adobe Commerce) to potężna, modularna platforma e-commerce. Ze względu na swoją architekturę – zaawansowany backend oparty na strukturze EAV oraz dynamiczny frontend wykorzystujący biblioteki takie jak Knockout.js i jQuery – platforma ta stawia przed inżynierami jakości (QA) specyficzne i bardzo wymagające wyzwania.

Standardowe podejścia do testowania automatycznego często zawodzą w zderzeniu z Magento 2. Poniżej przedstawiamy szczegółową analizę największych wyzwań testowych specyficznych dla tej platformy oraz sprawdzone wzorce radzenia sobie z nimi.

Witamy w wielkim finale naszej serii! Przez ostatnie tygodnie budowaliśmy Piramidę Testów, walczyliśmy z asynchronicznością, przejmowaliśmy kontrolę nad bazą danych i API, pilnowaliśmy dostępności i bawiliśmy się w hakerów.

Jednak wszystkie te niesamowite testy, bez względu na to jak czysty jest ich kod, nie mają znaczenia, dopóki działają wyłącznie na komputerze dewelopera. Prawdziwa jakość rodzi się w Continuous Integration (CI/CD).

W tej części przyjrzymy się infrastrukturze i sposobom wpinania automatyzacji tak, by stanowiła twardą bramkę jakościową (Quality Gate).

Po zbudowaniu Piramidy Testów, opanowaniu mockowania i wdrożeniu testów wizualnych, mogłoby się wydawać, że nasza praca jest skończona. Niestety, testowanie tzw. "szczęśliwych ścieżek" (Happy Paths) to zaledwie wierzchołek góry lodowej.

W czwartej części naszego cyklu poruszymy obszary najczęściej ignorowane w procesie deweloperskim, aż do momentu krytycznego błędu na produkcji. Skupimy się na Dostępności (A11y), Bezpieczeństwie (Security) oraz nieliniowym, hakerskim podejściu do własnej aplikacji, czyli Testowaniu Adwersaryjnym.

Po ustabilizowaniu fundamentów strategii testowej i zapanowaniu nad środowiskiem (sieć oraz dane), czas spojrzeć na warstwę, z którą nasz użytkownik styka się bezpośrednio – interfejs.

W trzeciej części cyklu skupimy się na połączonych konceptach Testowania Wielopłaszczyznowego (Cross-X) oraz Testowania Wizualnego. Dlaczego warto o nich mówić razem? Ponieważ oba skupiają się na zagwarantowaniu, że niezależnie od urządzenia, silnika czy najmniejszej zmiany w CSS, nasza aplikacja wygląda i zachowuje się wzorowo.

W poprzedniej części cyklu o automatyzacji testów omówiliśmy fundamenty: Piramidę Testów i traktowanie testów jako pełnoprawnego kodu produkcyjnego (Page Object Model, TypeScript). Jednak nawet najlepiej napisany kod testowy będzie bezużyteczny, jeśli będzie działał na niestabilnym środowisku z nieprzewidywalnymi danymi.

Dlatego w tym bardzo "mięsistym" technicznie wpisie skupimy się na wyzwaniu, które spędza sen z powiek wielu testerom: Izolacja Danych i Zarządzanie Ruchem Sieciowym.

Zanim zaczniemy pisać o konkretnych narzędziach, konfigurować pipeline'y CI/CD i uruchamiać testy w środowiskach wirtualnych, musimy odpowiednio ustawić nasz "mindset". Budowanie stabilnego frameworka testowego zaczyna się od obranej strategii (Piramidy Testów), a kończy na uświadomieniu sobie kluczowej zasady: kod testów to kod produkcyjny.

W dzisiejszym świecie tworzenia oprogramowania (szczególnie aplikacji Fullstack), testowanie to nie tylko "dodatek", ale absolutny fundament utrzymania zdrowego cyklu życia projektu. W projekcie reads od początku postawiliśmy na wysoką jakość i zautomatyzowane procesy. Chciałbym podzielić się z Wami, dlaczego wybraliśmy Playwrighta do testów End-to-End (E2E), jak to narzędzie sprawdza się w praktyce oraz w jaki sposób wpięliśmy je w naszą "piramidę testów" na CI/CD.

Jako inżynier bezpieczeństwa, który zaczynał od analizy pakietów w Wiresharku i ręcznego „fuzzowania” formularzy, z pewnym sentymentem wspominam rok 2005. Wtedy bezpieczeństwo aplikacji webowych opierało się na naiwnym zaufaniu do protokołów GET i POST. Parametry w URL-u były dosłownie zaproszeniem do przejęcia bazy danych (SQLi), a brak walidacji po stronie serwera był normą, nie wyjątkiem. Królowała era monolitycznych systemów, w których jedna luka w kodzie oznaczała natychmiastowe RCE (Remote Code Execution). Zamiast podejścia Secure by Design, żyliśmy w świecie „perymetrycznej obrony”, wierząc, że firewall ochroni nas przed wszystkim.