Aplikacja webowa na pracę magisterską z informatyki ma sens wtedy, gdy pomaga rozstrzygnąć konkretne pytanie badawcze i nie jest celem samym w sobie. Na studiach drugiego stopnia komisja ocenia przede wszystkim to, czego dowiedziałeś się dzięki aplikacji: jak sposób renderowania wpływa na wydajność, czy interfejs jest dostępny dla osób korzystających z czytnika ekranu, jak skuteczne są wybrane zabezpieczenia albo który wariant ekranu lepiej sprawdza się u użytkowników. Z tego wpisu dowiesz się, jakie są główne osie badawcze dla projektu webowego, zobaczysz tematy z przypisaną metodą, zasady wiarygodnego pomiaru, plan testu A/B, układ rozdziałów oraz błędy, przez które magisterki z tego obszaru tracą punkty.
Praca magisterska z informatyki, w której aplikacja jest stanowiskiem badawczym
W pracy inżynierskiej wynikiem jest działający system wraz z dokumentacją. W magisterce system przypomina raczej aparaturę w laboratorium: pozwala wywołać zjawisko i je zmierzyć. Z tej zmiany perspektywy wynikają trzy praktyczne konsekwencje. Budujesz tylko te funkcje, które są potrzebne do eksperymentu. Projektujesz aplikację tak, by dało się zmieniać jeden czynnik naraz – na przykład strategię renderowania – przy niezmienionej reszcie kodu. A rozdział opisujący implementację jest wyraźnie krótszy od rozdziałów z wynikami i dyskusją.
Projekty webowe należą do stałych pozycji w wykazach prac. Dane z repozytoriów prac dyplomowych pokazują, że w okresie 2024–2026 obroniono ok. 180 prac, w których aplikację tworzono z użyciem bibliotek React, Vue albo Angular. Prac o bezpieczeństwie aplikacji webowych i testach penetracyjnych było w tym okresie ok. 150, wobec ok. 70 w poprzednich trzech latach. Sam „system rezerwacji w React” niczym się więc nie wyróżni – wyróżnia go dopiero dobrze postawiony problem. Przegląd typowych zakresów znajdziesz w opisie tematyki prac na kierunku informatyka.
Pięć osi badawczych dla aplikacji webowej
Architektura renderowania
Renderowanie po stronie klienta (SPA), po stronie serwera (SSR), generowanie statyczne (SSG) oraz podejścia mieszane – częściowa hydratacja czy architektura wysp – różnią się ilością JavaScriptu wysyłanego do przeglądarki i momentem, w którym użytkownik widzi treść. Pytanie badawcze może dotyczyć kompromisu między świeżością danych a czasem wyświetlenia strony albo kosztu obsługi serwera przy rosnącej liczbie odwiedzin.
Wydajność mierzona metrykami Core Web Vitals
LCP (czas wyrenderowania największego elementu widocznego na ekranie), INP (opóźnienie reakcji na interakcję) i CLS (nieoczekiwane przesunięcia układu) dają wspólny język do porównań. Ciekawsze od samego wyniku w Lighthouse jest wyjaśnienie, co go psuje: skrypty firm trzecich, ciężkie czcionki, obrazy bez zadeklarowanych wymiarów, długie zadania blokujące główny wątek przeglądarki.
Dostępność według WCAG
Wytyczne WCAG 2.2 oraz wzorce projektowe WAI-ARIA określają, jak komponenty mają działać z klawiaturą i technologiami asystującymi. Badanie może porównywać skuteczność narzędzi automatycznych z oceną ekspercką albo sprawdzać, jak gotowe komponenty z popularnych bibliotek zachowują się w różnych czytnikach ekranu.
Bezpieczeństwo
Zamiast przeglądu wszystkich zagrożeń wybierz jeden mechanizm obronny i zmierz jego skuteczność oraz koszt wdrożenia: politykę Content Security Policy, ograniczanie liczby żądań, atrybuty ciasteczek sesyjnych, kontrolę integralności zasobów ładowanych z zewnętrznych serwerów (Subresource Integrity).
Eksperymenty z użytkownikami
Aplikacja dostępna w sieci daje dostęp do prawdziwego ruchu, więc możesz losowo przydzielać odwiedzających do wariantów i porównywać odsetek ukończonych zadań, czas lub liczbę błędów. To jedyna z pięciu osi, w której wynikiem jest zachowanie ludzi, a nie parametry techniczne, dlatego wymaga przemyślanego planu statystycznego i zgód uczestników.
Przykładowe tematy z metodą badawczą
Propozycje w tabeli traktuj jako materiał na pierwszą konsultację z promotorem. Każda ma wskazany czynnik, którym sterujesz, i sposób pomiaru. Zakres zawęzisz, wybierając konkretny rodzaj serwisu, grupę urządzeń albo jeden scenariusz użycia.
| Temat pracy | Rodzaj badania | Co mierzysz |
|---|---|---|
| Generowanie statyczne z przyrostową regeneracją a renderowanie na żądanie w serwisie z ofertą kursów – świeżość treści kontra czas wyświetlenia | eksperyment porównawczy na dwóch wdrożeniach tej samej treści | LCP, czas do pierwszego bajtu, opóźnienie publikacji zmian |
| Architektura wysp a pełna hydratacja aplikacji jednostronicowej na smartfonach z niższej półki cenowej | pomiar laboratoryjny z ograniczeniem mocy procesora i przepustowości sieci | rozmiar paczek JavaScript, INP, łączny czas blokowania |
| Odroczone ładowanie skryptów zewnętrznych (analityka, okno czatu, osadzona mapa) a responsywność serwisu z rezerwacją wizyt | eksperyment z kilkoma wariantami konfiguracji | INP, CLS, kompletność zbieranych danych analitycznych |
| Rozbieżności między wynikami testów laboratoryjnych a pomiarami od rzeczywistych użytkowników w serwisie informacyjnym | analiza danych z Lighthouse i z biblioteki web-vitals zbieranych przez kilka tygodni | różnice 75. percentyla LCP i INP, źródła rozbieżności |
| Okna dialogowe, menu rozwijane i karuzele z popularnych bibliotek komponentów w odbiorze czytników NVDA i VoiceOver | audyt ekspercki według wzorców WAI-ARIA | liczba naruszeń, odsetek wykrytych przez narzędzia automatyczne |
| Komunikaty o błędach w formularzach odczytywane przez czytniki ekranu – regiony aria-live a przenoszenie fokusu na pole z błędem | test zadaniowy z użytkownikami technologii asystujących | skuteczność poprawienia błędu, czas, ocena zrozumiałości |
| Polityka Content Security Policy z jednorazowymi tokenami w aplikacji jednostronicowej – skuteczność wobec wstrzykiwania skryptów i koszt wdrożenia | eksperyment na przygotowanym zestawie scenariuszy ataku | odsetek zablokowanych ładunków, liczba niezbędnych zmian w kodzie |
| Limity żądań i wyzwania obliczeniowe jako ochrona formularza logowania przed masowym sprawdzaniem wykradzionych haseł | symulacja ataku w izolowanym środowisku testowym | skuteczność blokady, dodatkowe opóźnienie dla zwykłego użytkownika |
| Formularz zamówienia jednoetapowy a wieloetapowy w sklepie internetowym – test A/B na rzeczywistym ruchu | eksperyment online z losowym przydziałem | odsetek ukończonych zamówień, czas wypełniania |
| Ekrany szkieletowe a klasyczny wskaźnik ładowania – postrzegany czas oczekiwania na wyniki wyszukiwania | eksperyment z uczestnikami i krótki kwestionariusz | subiektywna ocena czasu, przerwane wyszukiwania |
| WebAssembly a JavaScript w przetwarzaniu dużych plików tabelarycznych bezpośrednio w przeglądarce | benchmark z wieloma powtórzeniami | czas przetwarzania, zużycie pamięci, rozmiar modułu |
Jak mierzyć wydajność, żeby wyniki obroniły się przed recenzentem
Najwięcej uwag w recenzjach takich prac dotyczy nie tematu, lecz warsztatu pomiarowego. Poniższe zasady porządkują tę część pracy i warto opisać je wprost w rozdziale metodycznym.
- Odróżniaj dane laboratoryjne od terenowych. Lighthouse czy WebPageTest działają w kontrolowanych warunkach, a dane od użytkowników (RUM) pokazują rozkład wyników na prawdziwych urządzeniach. Oba źródła odpowiadają na inne pytania.
- Ustal warunki stanowiska: model procesora, przeglądarkę z numerem wersji, profil ograniczenia sieci, wersje bibliotek i tryb budowania produkcyjnego.
- Rób serie, nie pojedyncze uruchomienia. Odrzuć przebiegi rozgrzewające, a dla każdego wariantu podaj medianę i miarę rozproszenia.
- Posługuj się percentylami. Wyniki wydajności mają rozkłady prawostronnie skośne; Google ocenia Core Web Vitals na poziomie 75. percentyla, więc ta sama konwencja ułatwi porównania z literaturą.
- Test statystyczny dobierz do danych. Przy rozkładach dalekich od normalnego lepiej sprawdzi się test Manna-Whitneya lub przedziały ufności z metody bootstrap niż test t.
- Skrypty pomiarowe i surowe wyniki trzymaj w publicznym lub udostępnionym promotorowi repozytorium; odnośnik dodaj w załączniku.
Dobrym nawykiem jest prowadzenie dziennika pomiarów: data, wersja kodu (identyfikator commita), konfiguracja, wynik. Gdy po kilku tygodniach coś się nie zgadza, dziennik pozwala odtworzyć przyczynę zamiast powtarzać całą serię.
Test A/B w pracy magisterskiej – plan krok po kroku
- Hipoteza i jedna główna miara sukcesu, zapisane przed uruchomieniem eksperymentu, np. „formularz wieloetapowy zwiększa odsetek ukończonych zamówień”.
- Wielkość próby wyznaczona analizą mocy: minimalny efekt, który ma znaczenie praktyczne, moc testu (zwykle 0,8) i poziom istotności (zwykle 0,05).
- Losowy i stały przydział – ta sama osoba przy kolejnych wizytach trafia do tego samego wariantu, np. dzięki identyfikatorowi zapisanemu w ciasteczku.
- Czas trwania ustalony z góry. Kończenie testu w chwili, gdy wynik „wygląda dobrze”, zawyża ryzyko fałszywego odkrycia.
- Kontrola jakości danych: zgodność proporcji przydziału z założoną, odfiltrowanie ruchu botów, sprawdzenie, czy oba warianty działały bez awarii.
- Analiza: test różnicy proporcji lub regresja logistyczna, przedział ufności dla różnicy i omówienie wielkości efektu, nie tylko wartości p.
- Etyka i ochrona danych: zgoda na pliki cookie analityczne, minimalizacja zbieranych informacji, uzgodnienie zasad z właścicielem serwisu i – w razie wątpliwości – opinia komisji etycznej wydziału.
Ruch do eksperymentu możesz pozyskać z własnego serwisu, ze strony koła naukowego, organizacji studenckiej albo od partnera biznesowego, który zgodzi się na test. Jeśli ruch jest zbyt mały na test online, przenieś eksperyment do warunków kontrolowanych i zaproś uczestników do wykonania zadań. Przy planowaniu analizy przydaje się wsparcie opisane na stronie analiza statystyczna i badania.
Układ rozdziałów pracy
- Otwarcie pracy: skąd wziął się problem, dlaczego ma znaczenie praktyczne, jakie stawiasz pytania i czego się spodziewasz.
- Stan badań: przegląd publikacji o badanym zjawisku – na przykład o wpływie hydratacji na responsywność – zamiast podręcznikowego opisu protokołu HTTP.
- Metoda: zmienne, warianty, stanowisko pomiarowe, uczestnicy lub zbiory danych, procedura i plan analizy.
- Aplikacja badawcza: architektura i te decyzje implementacyjne, które wpływają na mierzone wielkości.
- Prezentacja rezultatów: rozkłady pomiarów na wykresach, zestawienia liczbowe i testy istotności, na razie bez interpretacji.
- Dyskusja: co oznaczają wyniki, jak mają się do wcześniejszych publikacji, co mogło je zniekształcić.
- Zakończenie z bezpośrednią odpowiedzią na każde pytanie badawcze oraz propozycjami dalszych prac.
O tym, jak całość wpisuje się w wymogi studiów drugiego stopnia, przeczytasz na stronie praca magisterska krok po kroku. Szczegółowe wymagania formalne – objętość, szablon, sposób dołączenia kodu – sprawdź w regulaminie dyplomowania swojego wydziału.
Literatura i zaplecze w Toruniu
Do przeglądu badań najlepiej nadają się ACM Digital Library, IEEE Xplore oraz materiały konferencyjne poświęcone inżynierii oprogramowania oraz projektowania interakcji. Specyfikacje W3C i WHATWG, dokumentacja MDN oraz coroczny raport Web Almanac opracowywany przez HTTP Archive są źródłami pomocniczymi – dobre do opisu technologii, słabsze jako dowód w dyskusji. Studenci Wydziału Matematyki i Informatyki UMK mogą korzystać z baz udostępnianych przez Bibliotekę Uniwersytecką w Toruniu; listę dostępnych zasobów i zasady logowania spoza sieci uczelni sprawdzisz na jej stronie. Jeśli studiujesz informatykę na Politechnice Bydgoskiej, zajrzyj do katalogu biblioteki uczelnianej i do wykazu tematów prowadzonych przez promotorów wydziału – temat zgodny z ich specjalnością badawczą łatwiej uzyskuje akceptację.
Na czym magisterki webowe tracą punkty
- Porównanie wariantów różniących się kilkoma rzeczami naraz – inną biblioteką, innym hostingiem i innym zestawem funkcji – przez co nie wiadomo, co wywołało różnicę.
- Pomiary w trybie deweloperskim, z włączonymi rozszerzeniami przeglądarki albo na laptopie podłączonym do zasilania raz, a raz nie.
- Rozdział teoretyczny będący streszczeniem dokumentacji frameworka, bez odniesień do badań naukowych.
- Wnioski o „wszystkich aplikacjach webowych” wyciągnięte z jednego serwisu testowego.
- Test A/B zatrzymany po kilku dniach, bo różnica wyglądała obiecująco.
- Testy bezpieczeństwa przeprowadzone na cudzym serwisie bez pisemnej zgody właściciela.
Część tych problemów wychodzi dopiero przy czytaniu całości, dlatego przed oddaniem pracy warto zlecić niezależne czytanie tekstu – zakres takiej pomocy opisuje strona redakcja i korekta pracy.
FAQ – aplikacja webowa w magisterce
Czy praca z aplikacją webową musi zawierać badanie z udziałem ludzi?
Nie. Eksperyment wydajnościowy, analiza bezpieczeństwa czy audyt dostępności są pełnoprawnymi badaniami. Uczestnicy są potrzebni wtedy, gdy pytanie dotyczy zachowania lub odczuć użytkowników – na przykład postrzeganego czasu oczekiwania.
Ile pomiarów wystarczy, żeby porównanie było wiarygodne?
Nie ma jednej liczby. Wykonaj serię próbną, oceń rozrzut wyników i na tej podstawie dobierz liczbę powtórzeń tak, by przedziały ufności dla porównywanych wariantów były wystarczająco wąskie. Uzasadnienie tej decyzji opisz w rozdziale metodycznym.
Czy mogę badać serwis, którego nie jestem autorem?
Pomiar wydajności publicznie dostępnych stron zwykle nie budzi zastrzeżeń, jeżeli nie obciążasz serwera nadmiernym ruchem. Testy bezpieczeństwa wymagają natomiast wyraźnej zgody właściciela; bez niej pracuj na własnej kopii lub na celowo podatnych aplikacjach szkoleniowych.
Czy wybór frameworka wpływa na ocenę?
Sam w sobie nie. Liczy się uzasadnienie: dlaczego dana technologia pozwala odpowiedzieć na pytanie badawcze i jak jej specyfika wpływa na interpretację wyników.
Jeśli zastanawiasz się, czy Twój pomysł lepiej sprawdzi się na urządzeniach przenośnych, porównaj go z zagadnieniami z wpisu o badaniach z użyciem aplikacji na smartfony – tam osie badawcze dotyczą energii, pracy bez sieci i ergonomii małego ekranu.