Techniczne pojęcia w testowaniu aplikacji webowych: słownik testera z testami w DevTools

Techniczne pojęcia w testowaniu aplikacji webowych to słownictwo, którym opisuje się, jak przeglądarka rozmawia z serwerem, gdzie trzyma dane i jak buduje stronę: HTTP, cookies, cache, CORS, nagłówki bezpieczeństwa i kilkanaście innych. Ten słownik do każdego hasła dopisuje to, czego zwykle brakuje w definicjach: co konkretnie sprawdzacie i gdzie to zobaczycie w DevTools.

Szukacie przewodnika po samym procesie, czyli jakie testy zaplanować, w jakiej kolejności i jakimi narzędziami? Ten temat opisuje osobny artykuł testowanie aplikacji webowych: co sprawdzić, jakie testy i jakimi narzędziami. Tutaj skupiamy się na pojęciach, bez których trudno zrozumieć zgłoszenie błędu od programisty albo raport z testów bezpieczeństwa.

Po co testerowi techniczne pojęcia?

Bo większość błędów w aplikacjach webowych nie siedzi w tym, co widać na ekranie. Formularz wygląda dobrze, a ciasteczko sesji wycieka do skryptów reklamowych. Strona ładuje się szybko u Was, a u klienta pokazuje wersję sprzed tygodnia, bo zadziałał cache. Kto zna pojęcia, ten wie, gdzie zajrzeć.

Dane pokazują, że to nie są teoretyczne problemy. Według raportu HTTP Archive Web Almanac 2024 nagłówek Content-Security-Policy wysyła tylko 19% hostów, a flagę HttpOnly ma 42% ciasteczek pierwszej strony na komputerach. Każda z tych luk to gotowy przypadek testowy.

Każde hasło poniżej ma ten sam układ: krótka definicja i akapit „Co testujecie” z konkretnym przykładem. W naszych projektach testów aplikacji webowych właśnie ta lista służy jako punkt startu dla nowych osób w zespole.

Jak przeglądarka rozmawia z serwerem?

Przez protokół HTTP: przeglądarka wysyła żądanie, serwer odsyła odpowiedź z kodem statusu, nagłówkami i treścią. Zanim to nastąpi, DNS zamienia nazwę domeny na adres IP.

HTTP i HTTPS

HTTP to protokół wymiany żądań i odpowiedzi, opisany w dokumencie RFC 9110 (IETF, 2022). HTTPS to ten sam protokół w szyfrowanym połączeniu TLS. Dziś każda strona z logowaniem albo formularzem powinna działać wyłącznie po HTTPS.

Co testujecie: wpiszcie adres z http:// i sprawdźcie, czy serwer przekierowuje na https:// kodem 301. Sprawdźcie też, czy strona po HTTPS nie ładuje obrazków albo skryptów po HTTP, bo przeglądarka zgłosi wtedy ostrzeżenie mixed content w konsoli.

DNS

DNS to system, który tłumaczy nazwę domeny, na przykład qualityisland.pl, na adres IP serwera. Zmiana rekordu DNS nie działa od razu, bo odpowiedzi są przechowywane przez czas TTL.

Co testujecie: po migracji albo zmianie środowiska sprawdźcie poleceniem nslookup albo dig, na jaki adres wskazuje domena. Połowa zgłoszeń „na produkcji nie działa, u mnie działa” po wdrożeniu kończy się na tym, że tester widział jeszcze stary serwer.

Metody HTTP

Metoda mówi serwerowi, co chcecie zrobić z zasobem: GET pobiera, POST tworzy, PUT zastępuje, PATCH zmienia fragment, DELETE usuwa. RFC 9110 (IETF, 2022) nazywa GET, HEAD, OPTIONS i TRACE metodami bezpiecznymi, czyli takimi, które nie powinny zmieniać danych. Szczegóły z przykładami znajdziecie w artykule o metodach HTTP w testach API.

Co testujecie: wyślijcie dwa razy to samo żądanie DELETE albo PUT. Drugie nie może zepsuć danych, bo te metody są idempotentne. Sprawdźcie też, czy GET niczego nie zapisuje, na przykład czy link „usuń” nie działa przez zwykłe kliknięcie w adres.

Kody statusu

Trzycyfrowy kod w odpowiedzi mówi, jak zakończyło się żądanie. Pierwsza cyfra określa klasę odpowiedzi.

Nagłówki HTTP

Nagłówki to pary nazwa i wartość dołączone do żądania i odpowiedzi. Niosą informacje o typie treści, języku, cache, ciasteczkach i zabezpieczeniach. Najszybciej zobaczycie je w terminalu poleceniem curl -I, które pobiera same nagłówki.

curl -I https://github.com, fragment odpowiedzi z 11.10.2026

strict-transport-security: max-age=31536000; includeSubdomains; preload
x-frame-options: deny
x-content-type-options: nosniff
referrer-policy: origin-when-cross-origin, strict-origin-when-cross-origin
content-security-policy: default-src 'none'; base-uri 'self'; ...
set-cookie: logged_in=no; expires=Mon, 11 Oct 2027 08:37:25 GMT; domain=.github.com; path=/; HttpOnly; secure; SameSite=Lax

Co testujecie: porównajcie nagłówki odpowiedzi na środowisku testowym i produkcyjnym. Brak nagłówka na jednym z nich to częsty efekt innej konfiguracji serwera, a nie błędu w kodzie aplikacji.

Gdzie aplikacja trzyma dane w przeglądarce?

W czterech miejscach: w ciasteczkach, w Web Storage, w pamięci podręcznej i w sesji po stronie serwera, do której przeglądarka trzyma tylko identyfikator. Wszystkie zobaczycie w Chrome w panelu Application.

Cookies, czyli ciasteczka

Cookie to mała porcja danych, którą serwer każe zapisać przeglądarce nagłówkiem Set-Cookie, a przeglądarka odsyła ją przy kolejnych żądaniach. Mechanizm opisuje RFC 6265 (IETF, 2011). Ciasteczka służą do utrzymania sesji, zapamiętania języka czy zgody na pliki cookie.

Ważna poprawka do popularnych definicji: w ciasteczkach nie przechowuje się danych logowania, czyli loginu i hasła. To zła praktyka. Ciasteczko sesji powinno zawierać tylko losowy identyfikator, który nic nie mówi bez bazy danych serwera.

Co testujecie: otwórzcie DevTools, panel Application, sekcja Cookies, i sprawdźcie kolumny Secure, HttpOnly i SameSite przy ciasteczku sesji. Potem w konsoli wpiszcie poniższe polecenie. Jeśli identyfikator sesji pojawi się w wyniku, skrypt wstrzyknięty przez atak XSS też go odczyta.

Konsola DevTools

document.cookie
// oczekiwane: brak ciasteczka sesji, np. tylko "lang=pl; cookie_consent=1"

Według web.dev ciasteczko bez atrybutu SameSite przeglądarki z rodziny Chrome traktują jak SameSite=Lax. Nie zakładajcie jednak, że każda przeglądarka zrobi to samo, i sprawdzajcie jawne ustawienie.

Sesja

Sesja to stan zalogowania po stronie serwera, powiązany z przeglądarką identyfikatorem w ciasteczku albo tokenem. Wylogowanie powinno unieważnić sesję na serwerze, a nie tylko usunąć ciasteczko w przeglądarce.

Co testujecie: skopiujcie wartość ciasteczka sesji, wylogujcie się, a potem wklejcie ją z powrotem w panelu Application i odświeżcie stronę. Jeśli jesteście znowu zalogowani, sesja nie została unieważniona. Sprawdźcie też, czy identyfikator sesji zmienia się po zalogowaniu.

localStorage i sessionStorage

Web Storage to magazyn par klucz i wartość w przeglądarce. localStorage przetrwa zamknięcie przeglądarki, sessionStorage znika po zamknięciu karty. W odróżnieniu od ciasteczek dane nie są wysyłane do serwera, ale JavaScript ma do nich pełny dostęp.

Co testujecie: przejrzyjcie panel Application, sekcja Local Storage. Token dostępu, numer PESEL albo dane karty w tym miejscu to zgłoszenie do zespołu bezpieczeństwa, bo każdy skrypt na stronie może je odczytać.

Cache

Cache to kopia zasobu zapisana bliżej użytkownika: w przeglądarce, w serwerze pośredniczącym albo w CDN. O tym, jak długo kopia jest ważna, decydują nagłówki Cache-Control, ETag i Last-Modified. Gdy kopia jest aktualna, serwer odpowiada kodem 304 Not Modified bez treści.

Co testujecie: po wdrożeniu sprawdźcie, czy użytkownik dostaje nową wersję plików JS i CSS. W DevTools zaznaczcie w panelu Network opcję Disable cache i porównajcie wynik z normalnym odświeżeniem. Strona z danymi osobowymi nie powinna być zapisywana w cache serwera pośredniczącego, czyli powinna mieć Cache-Control: private albo no-store.

Z czego zbudowany jest frontend?

Z trzech warstw: HTML opisuje strukturę i treść, CSS wygląd, a JavaScript zachowanie. Przeglądarka składa z nich drzewo DOM, które widzicie w panelu Elements.

HTML i DOM

HTML to język znaczników opisujący, co jest na stronie: nagłówek, akapit, formularz, przycisk. DOM to drzewo obiektów, które przeglądarka buduje z HTML i które JavaScript może zmieniać w trakcie działania strony.

Co testujecie: sprawdźcie, czy przyciski są elementami button, a pola mają etykiety label. To podstawa testów dostępności według WCAG 2.2 i jednocześnie podstawa stabilnych selektorów w automatyzacji.

CSS i selektory CSS

CSS opisuje wygląd: kolory, czcionki, odstępy i układ. Selektor CSS wskazuje, których elementów dotyczy reguła, na przykład #login po identyfikatorze albo button[type="submit"] po atrybucie. Te same selektory służą do wyszukiwania elementów w Selenium, Playwright i Cypress.

Co testujecie: w panelu Elements naciśnijcie Ctrl+F (Cmd+F na Macu) i wpiszcie selektor. DevTools pokaże, ile elementów pasuje. Selektor do testu automatycznego powinien wskazywać dokładnie jeden element. Więcej o strategiach znajdziecie w tekście o selektorach w Selenium.

JavaScript

JavaScript to język, który wykonuje się w przeglądarce i reaguje na działania użytkownika: kliknięcia, wpisywanie, przewijanie. Odpowiada też za walidację formularzy po stronie klienta i za pobieranie danych w tle.

Co testujecie: wyłączcie walidację w przeglądarce (w DevTools usuńcie atrybut required albo wyślijcie żądanie bezpośrednio z Postmana). Serwer musi odrzucić złe dane sam, bo walidacji w JavaScript nie da się zaufać.

AJAX i fetch

AJAX to technika pobierania danych z serwera bez przeładowania całej strony. Dziś zwykle realizuje się ją funkcją fetch, a dane przychodzą w formacie JSON, nie XML, mimo nazwy techniki.

Co testujecie: w panelu Network włączcie filtr Fetch/XHR i wykonajcie akcję na stronie. Zobaczycie każde żądanie do API, jego kod statusu i odpowiedź. Spinner, który kręci się w nieskończoność, prawie zawsze ma tam swoje wyjaśnienie w postaci błędu 4xx albo 5xx.

Responsywność

Responsywność to zdolność strony do dopasowania układu do szerokości ekranu. Opiera się na regułach CSS media queries i znaczniku meta viewport.

Co testujecie: w DevTools włączcie tryb urządzenia (Ctrl+Shift+M) i przejdźcie przez szerokości 320, 768 i 1280 pikseli. Szukajcie poziomego paska przewijania, nachodzących na siebie elementów i przycisków mniejszych niż 24 na 24 piksele, bo tyle wymaga kryterium 2.5.8 WCAG 2.2 (W3C, 2023).

Jakie mechanizmy bezpieczeństwa sprawdza tester?

Przede wszystkim nagłówki bezpieczeństwa i politykę CORS. Oba mechanizmy działają w przeglądarce, więc tester bez dostępu do kodu serwera może je sprawdzić w kilka minut.

Nagłówki bezpieczeństwa (security headers)

To nagłówki odpowiedzi HTTP, które każą przeglądarce włączyć dodatkowe zabezpieczenia. W wielu polskich materiałach krąży nazwa „zapytania bezpieczeństwa”, ale to błędne tłumaczenie: chodzi o nagłówki, nie zapytania. Projekt OWASP Secure Headers utrzymuje listę zalecanych nagłówków i ich wartości.

Raport HTTP Archive Web Almanac 2024 pokazuje, że nagłówek X-Content-Type-Options pojawia się w 48% odpowiedzi, a Strict-Transport-Security w 34%. Z naszego doświadczenia brakujący nagłówek to jedno z najczęstszych znalezisk w raportach z testów bezpieczeństwa aplikacji webowych, bo naprawa zajmuje programiście kilka minut, a ryzyko zostaje latami.

CORS

Cross-Origin Resource Sharing to mechanizm, w którym serwer nagłówkiem Access-Control-Allow-Origin mówi przeglądarce, które inne domeny mogą odczytać jego odpowiedzi. Domyślnie przeglądarka na to nie pozwala. Przed żądaniem, które może zmienić dane, wysyła zapytanie wstępne metodą OPTIONS, tak zwany preflight.

Druga poprawka do popularnych definicji: CORS nie chroni serwera przed atakiem. To przeglądarka pilnuje reguł, a curl czy Postman wcale ich nie stosują. CORS rozluźnia zasadę tego samego pochodzenia, a nie ją zaostrza.

Co testujecie: wyślijcie żądanie z nagłówkiem Origin: https://obca-domena.example i sprawdźcie odpowiedź. Serwer, który odsyła dowolny Origin z powrotem w Access-Control-Allow-Origin razem z Access-Control-Allow-Credentials: true, pozwala obcej stronie czytać dane zalogowanego użytkownika. To błąd krytyczny.

Tryb incognito

Tryb incognito to okno przeglądarki, które po zamknięciu usuwa historię, ciasteczka i dane formularzy z tej sesji. W trakcie sesji ciasteczka działają normalnie. Nie daje anonimowości: strona, pracodawca i dostawca internetu widzą Waszą aktywność tak samo.

Co testujecie: używajcie incognito do testu pierwszej wizyty: baner zgody na ciasteczka, ekran logowania, onboarding. Gdy potrzebujecie dwóch użytkowników naraz, na przykład administratora i klienta, otwórzcie zwykłe okno i okno incognito obok siebie.

Czym są WebSockety i PWA?

WebSocket to stałe, dwukierunkowe połączenie między przeglądarką a serwerem, a PWA to aplikacja webowa, którą można zainstalować i używać częściowo bez sieci. Oba pojęcia zmieniają sposób testowania, bo nie wszystko widać jako zwykłe żądanie HTTP.

WebSocket

Połączenie WebSocket zaczyna się jak zwykłe żądanie HTTP, które serwer przełącza kodem 101 Switching Protocols. Od tej chwili obie strony mogą wysyłać wiadomości w dowolnym momencie. Protokół opisuje RFC 6455 (IETF, 2011). Używają go czaty, powiadomienia na żywo i notowania giełdowe.

Co testujecie: w panelu Network włączcie filtr WS, kliknijcie połączenie i otwórzcie zakładkę Messages. Zobaczycie każdą wiadomość w obie strony. Sprawdźcie, co dzieje się po zerwaniu sieci (w Network ustawcie Offline): czy aplikacja wznawia połączenie i czy nie gubi wiadomości.

PWA, czyli Progressive Web App

PWA to aplikacja webowa z plikiem manifestu i skryptem service worker. Manifest pozwala ją zainstalować na telefonie albo komputerze. Service worker przechwytuje żądania i może serwować zasoby z własnej pamięci, także bez sieci.

Co testujecie: w panelu Application sprawdźcie sekcje Manifest i Service workers. Przełączcie sieć na Offline i przejdźcie przez główne ekrany. Najczęstszy błąd po wdrożeniu: service worker serwuje starą wersję aplikacji, dopóki użytkownik nie zamknie wszystkich kart.

DevTools i rozszerzenia: narzędzia testera

DevTools to wbudowany w przeglądarkę zestaw narzędzi do podglądu i zmiany strony w czasie działania. Otwieracie go klawiszem F12. Dla testera to najważniejsze narzędzie pracy z aplikacją webową, ważniejsze niż jakikolwiek płatny program.

Rozszerzenia przeglądarki

Rozszerzenia, nazywane potocznie pluginami, dodają przeglądarce funkcje: blokowanie reklam, tłumaczenie, menedżer haseł. Dla testera są jednocześnie narzędziem i źródłem fałszywych błędów.

Co testujecie: każdy błąd, którego nie da się odtworzyć u programisty, sprawdźcie w oknie incognito albo w czystym profilu przeglądarki. Bloker reklam potrafi usunąć z DOM przycisk z klasą zawierającą słowo „banner”, a wtedy zgłoszenie dotyczy Waszej przeglądarki, nie aplikacji. Jak opisać takie środowisko w zgłoszeniu, pokazujemy w przewodniku jak poprawnie zgłosić błąd.

Jak mierzyć szybkość strony: Core Web Vitals

Core Web Vitals to trzy wskaźniki Google, które opisują, jak użytkownik odczuwa szybkość strony: ładowanie, reakcję na działanie i stabilność układu. Od 12 marca 2024 roku, według bloga web.dev, wskaźnik INP zastąpił w tym zestawie wcześniejszy FID.

Według web.dev progi trzeba spełnić dla 75. percentyla odsłon, osobno na telefonach i komputerach. Wynik z Waszego szybkiego laptopa w biurze to więc najlepszy przypadek, a nie typowy. Strona, która ładuje się w sekundę na światłowodzie w biurze, potrafi być bardzo cierpliwą lekcją pokory na telefonie w pociągu. Progi i sposób pomiaru opisujemy dokładniej w artykule jak szybko powinna ładować się strona, a gdy problem dotyczy obciążenia serwera, potrzebne są testy wydajnościowe.

Ściąga: pojęcie, panel DevTools, test

Całą listę w jednej tabeli. Wydrukujcie ją albo przypnijcie w zespole jako checklistę przed wydaniem wersji.

Kolejne 40 pomysłów na to, gdzie szukać błędów, znajdziecie w Web Testing Heuristic Checklist. Z doświadczenia naszego zespołu wynika, że największy zwrot daje połączenie obu list: słownik mówi, co sprawdzić, a heurystyki podpowiadają, jak to zepsuć.

Jeśli chcecie przećwiczyć te pojęcia z trenerem, zacznijcie od kursu tester manualny, kurs kompleksowy albo szkolenia testowanie interfejsów webowych. Warstwę API i metody HTTP rozwija wprowadzenie do testowania API, a nagłówki, ciasteczka i sesje w ujęciu bezpieczeństwa szkolenie testy bezpieczeństwa dla początkujących. Przez szkolenia Quality Island przeszło już ponad 2 500 specjalistów. Artykuły o jakości oprogramowania pisane z perspektywy decydentów publikuje też nasz portal Strefa QA, a o tym, jak testują inne zespoły, usłyszycie na Testing Ground Conference.

Powiązane na blogu Quality Island

• Testowanie aplikacji webowych: co sprawdzić, jakie testy i jakimi narzędziami
• Web Testing Heuristic Checklist: 40 heurystyk testowania aplikacji webowych
• Metody HTTP: GET, POST, PUT, PATCH i DELETE w testach API
• Testowanie bezpieczeństwa: rola testowania manualnego i automatycznego
• Postman: co to jest i jak zacząć testować API

Pełna lista źródeł

• IETF, RFC 9110: HTTP Semantics, 2022. Metody, kody statusu, metody bezpieczne i idempotentne.
• IETF, RFC 6265: HTTP State Management Mechanism, 2011. Ciasteczka, atrybuty Secure i HttpOnly.
• IETF, RFC 6455: The WebSocket Protocol, 2011.
• IETF, RFC 6797: HTTP Strict Transport Security, 2012.
• HTTP Archive, Web Almanac 2024, rozdział Security, 2024. Odsetki nagłówków bezpieczeństwa i atrybutów ciasteczek.
• OWASP, OWASP Secure Headers Project, stan na 11.10.2026.
• MDN Web Docs, Set-Cookie, stan na 11.10.2026.
• MDN Web Docs, Cross-Origin Resource Sharing (CORS), stan na 11.10.2026.
• MDN Web Docs, HTTP caching, stan na 11.10.2026.
• MDN Web Docs, Progressive web apps, stan na 11.10.2026.
• web.dev, SameSite cookies explained, stan na 11.10.2026.
• web.dev, Web Vitals, stan na 11.10.2026.
• web.dev, Interaction to Next Paint becomes a Core Web Vital, 2024.
• Google, Pomoc Chrome: przeglądanie w trybie incognito, stan na 11.10.2026.
• Google, Chrome DevTools documentation, stan na 11.10.2026.
• W3C, Web Content Accessibility Guidelines (WCAG) 2.2, 2023. Kryterium 2.5.8 Target Size (Minimum).