Rozdział z wynikami w pracy inżynierskiej z informatyki nie jest rozdziałem statystycznym — nie testujesz hipotez na próbie respondentów, tylko oceniasz własny system: czy działa zgodnie z wymaganiami, jak zachowuje się pod obciążeniem i gdzie kończą się jego możliwości. To zupełnie inny rozdział niż ogólny, przekrojowy „od danych do rozdziału z wynikami” pisany pod badania ankietowe czy eksperymentalne. Poniżej struktura dopasowana do pracy inżynierskiej z informatyki, z gotowym przykładem na aplikacji webowej. Omawiamy cztery bloki tego rozdziału, sposób prezentacji wyników testów funkcjonalnych i wydajnościowych, macierz zgodności z wymaganiami oraz to, jak zmienia się zawartość rozdziału w zależności od typu projektu — aplikacji webowej, mobilnej, systemu z uczeniem maszynowym czy rozwiązania wbudowanego.
Czym różni się ten rozdział od rozdziału wyników w pracy badawczej
W pracy badawczej (np. ankietowej czy eksperymentalnej) rozdział wyników odpowiada na pytania badawcze poprzez analizę danych zebranych od respondentów lub uczestników badania. W pracy inżynierskiej z informatyki „wynikiem” jest zaimplementowany system, a rozdział wyników pokazuje, jak ten system zachowuje się w praktyce: czy przechodzi testy funkcjonalne, jak radzi sobie pod obciążeniem i na ile spełnia wymagania sformułowane w rozdziale analizy. Nie ma tu próby losowej ani testów statystycznych — jest środowisko testowe, scenariusze testowe i zmierzone parametry działania systemu.
Cztery bloki rozdziału z wynikami w pracy inżynierskiej
- Środowisko i metodyka testowania — konfiguracja sprzętowa i programowa, na której przeprowadzono testy, oraz przyjęta metodyka (testy jednostkowe, integracyjne, akceptacyjne).
- Wyniki testów funkcjonalnych — tabela przypadków testowych z oczekiwanym i rzeczywistym rezultatem (pass/fail) dla kluczowych funkcji systemu.
- Wyniki testów wydajnościowych — zmierzone parametry: czas odpowiedzi, przepustowość, zużycie zasobów pod określonym obciążeniem.
- Ocena zgodności z wymaganiami — zestawienie wymagań funkcjonalnych i niefunkcjonalnych z rozdziału analizy z tym, które zostały spełnione, a które częściowo lub wcale.
Jak prezentować wyniki testów funkcjonalnych
Najczytelniejszą formą jest tabela przypadków testowych: numer przypadku, krótki opis testowanej funkcji, kroki wykonania, oczekiwany rezultat, rzeczywisty rezultat, status (zaliczony/niezaliczony). Przy 15–30 przypadkach testowych typowych dla pracy inżynierskiej warto pogrupować je tematycznie (np. „testy modułu logowania”, „testy modułu płatności”) zamiast wypisywać wszystkie w jednej długiej tabeli bez podziału. Każdy niezaliczony przypadek testowy powinien mieć krótki komentarz wyjaśniający przyczynę i status naprawy — recenzent traktuje nieomówiony błąd jako poważniejszy problem niż sam fakt jego wystąpienia.
Wyniki testów wydajnościowych — jak zmierzyć i przedstawić
Typowe parametry mierzone w pracy inżynierskiej z informatyki to: czas odpowiedzi serwera pod różnym obciążeniem (np. dla 10, 50, 100 równoczesnych użytkowników), przepustowość (liczba żądań obsłużonych w jednostce czasu) oraz zużycie pamięci i procesora podczas testów obciążeniowych. Narzędzia typowe do tego typu testów to Apache JMeter, k6 lub wbudowane narzędzia profilowania środowiska programistycznego. Wyniki najlepiej prezentować w formie wykresu (czas odpowiedzi w funkcji liczby użytkowników) uzupełnionego tabelą z dokładnymi wartościami liczbowymi — sam wykres bez tabeli utrudnia odczytanie precyzyjnych danych, a sama tabela bez wykresu nie pokazuje trendu.
Ocena zgodności z wymaganiami — macierz traceability
Najbardziej przekonującą formą oceny zgodności jest macierz łącząca każde wymaganie z rozdziału analizy (funkcjonalne i niefunkcjonalne) z konkretnym przypadkiem testowym, który je weryfikuje, i statusem spełnienia. Taka macierz od razu pokazuje promotorowi i recenzentowi, że żadne wymaganie nie zostało pominięte przy testowaniu, oraz uczciwie wskazuje wymagania spełnione tylko częściowo — np. funkcja działająca poprawnie, ale nieoptymalizowana pod kątem wydajności, powinna być opisana jako spełniona częściowo, a nie w pełni, nawet jeśli technicznie „działa”.
Dyskusja — jak połączyć wyniki z celem pracy
Sekcja dyskusji w pracy inżynierskiej nie powtarza wyników, tylko interpretuje je względem celu postawionego we wstępie: czy zaimplementowany system rozwiązuje problem, który miał rozwiązać, w jakim stopniu, i jakie kompromisy projektowe (np. między prostotą a skalowalnością) wpłynęły na uzyskane rezultaty. Dobra dyskusja odnosi się też do rozwiązań alternatywnych rozważanych w rozdziale analizy — dlaczego przyjęte podejście technologiczne okazało się (lub nie) trafnym wyborem w świetle uzyskanych wyników testów.
Ograniczenia implementacji — jak je opisać uczciwie
Ograniczenia w pracy inżynierskiej dotyczą zwykle zakresu funkcjonalnego (co świadomie pominięto ze względu na czas), skali testów (np. testy wydajnościowe przeprowadzone na środowisku deweloperskim, nie produkcyjnym) oraz założeń upraszczających przyjętych przy projektowaniu. Uczciwie opisane ograniczenie („testy wydajnościowe nie obejmują scenariusza awarii bazy danych, ponieważ wykraczał poza zakres pracy”) jest oceniane lepiej niż milczenie na ten temat lub twierdzenie, że system jest „gotowy produkcyjnie” bez żadnych zastrzeżeń.
Jak ten rozdział zmienia się przy innym typie projektu
Struktura czterech bloków pozostaje ta sama niezależnie od typu systemu, ale ich zawartość różni się istotnie. W aplikacji mobilnej testy wydajnościowe koncentrują się na zużyciu baterii, czasie uruchomienia i płynności animacji (klatki na sekundę), a nie na liczbie równoczesnych użytkowników serwera. W projekcie z uczeniem maszynowym rozdział z wynikami zamiast tabeli pass/fail zawiera metryki modelu (dokładność, precyzja, czułość, F1-score) na zbiorze testowym, a „testy funkcjonalne” sprowadzają się do walidacji poprawności działania pipeline’u danych. W systemie wbudowanym (embedded) testy wydajnościowe obejmują zużycie pamięci RAM i czas reakcji na sygnał sprzętowy, często mierzone na rzeczywistym urządzeniu, nie w symulatorze. Zasada jest wspólna: dobierz metryki właściwe dla typu systemu, zamiast kopiować gotowy zestaw z innej pracy.
Jak przygotować się do pytań komisji o ten rozdział
Komisja na obronie pracy inżynierskiej z informatyki najczęściej pyta o trzy rzeczy związane z rozdziałem wyników: dlaczego wybrano akurat te narzędzia do testowania, a nie inne dostępne na rynku; co dokładnie oznacza niezaliczony przypadek testowy i czy został naprawiony przed oddaniem pracy; oraz czy autor potrafi wytłumaczyć przyczynę zaobserwowanego spadku wydajności pod obciążeniem, a nie tylko podać liczbę. Przygotowanie krótkiej, technicznej odpowiedzi na każde z tych pytań, jeszcze przed obroną, jest znacznie skuteczniejsze niż uczenie się całego rozdziału na pamięć.
Przykład: aplikacja webowa do zarządzania zadaniami zespołu
Środowisko testowe: serwer z 4 rdzeniami CPU i 8 GB RAM, baza PostgreSQL, testy przeprowadzone lokalnie i w kontenerze Docker. Wyniki testów funkcjonalnych: 24 z 26 przypadków testowych zaliczonych, 2 niezaliczone (błąd walidacji formularza przy znakach specjalnych — naprawiony; brak obsługi strefy czasowej w powiadomieniach — pozostawiony jako ograniczenie). Wyniki wydajnościowe: czas odpowiedzi poniżej 200 ms dla 50 równoczesnych użytkowników, wzrost do około 800 ms przy 200 użytkownikach — wskazujący na granicę skalowalności obecnej architektury bez dodatkowego cachowania. Zgodność z wymaganiami: 18 z 20 wymagań funkcjonalnych spełnionych w pełni, 2 częściowo (eksport danych działa, ale bez formatu PDF, tylko CSV). Dyskusja: cel pracy — stworzenie działającego prototypu narzędzia do zarządzania zadaniami — został osiągnięty, a ograniczenie skalowalności przy większym obciążeniu jest zgodne z założeniem pracy jako prototypu, nie systemu produkcyjnego.
Testy automatyczne a testy manualne — co wpisać do rozdziału
Jeśli w projekcie napisano testy automatyczne (np. w JUnit, pytest czy Jest), warto podać w rozdziale wyników nie tylko wynik ich przebiegu, ale też pokrycie kodu testami (code coverage) — nawet przybliżone, np. „testy jednostkowe pokrywają około 70% logiki biznesowej modułu płatności”. Testy manualne, przeprowadzone ręcznie przez autora według scenariusza, są równie wartościowym dowodem poprawności działania systemu, ale warto jasno zaznaczyć, które przypadki testowe zostały zautomatyzowane, a które sprawdzono ręcznie — to rozróżnienie samo w sobie mówi recenzentowi, na ile system jest przygotowany do dalszego rozwoju po obronie, kiedy testy automatyczne chronią przed regresją, a testy manualne trzeba powtarzać za każdym razem od nowa.
Jak długo powinien trwać etap testowania w harmonogramie pracy
Realistyczny etap testowania (przygotowanie środowiska, napisanie przypadków testowych, wykonanie testów funkcjonalnych i wydajnościowych, naprawa znalezionych błędów) zajmuje zwykle 3–4 tygodnie w typowym harmonogramie semestralnym pracy inżynierskiej — krócej niż etap implementacji, ale dłużej, niż zakłada wielu studentów planujących projekt na starcie. Realny czas warto zweryfikować już na etapie planowania harmonogramu, pytając promotora lub starszych roczników, ile czasu faktycznie zajęło im testowanie podobnego systemu, zamiast opierać się wyłącznie na własnym optymistycznym założeniu. Zostawienie testowania na ostatni tydzień przed oddaniem pracy jest jednym z najczęstszych powodów, dla których rozdział z wynikami wygląda na dopisany na siłę, z jednym akapitem zamiast pełnej tabeli przypadków testowych. Zaplanowanie testowania jako osobnego etapu w harmonogramie, z własnym terminem, a nie „resztek czasu” po implementacji, jest jednym z najprostszych sposobów na uniknięcie tego problemu.
Checklist rozdziału z wynikami do pracy inżynierskiej
- Środowisko testowe (sprzęt, oprogramowanie, konfiguracja) jest opisane na tyle precyzyjnie, żeby dało się je odtworzyć.
- Wyniki testów funkcjonalnych są w tabeli z jasnym statusem pass/fail przy każdym przypadku.
- Każdy niezaliczony przypadek testowy ma komentarz o przyczynie i statusie naprawy.
- Wyniki wydajnościowe pokazują konkretne liczby, nie tylko ogólne stwierdzenie „system działa szybko”.
- Macierz zgodności łączy każde wymaganie z przypadkiem testowym, który je weryfikuje.
- Dyskusja odnosi wyniki do celu pracy, nie tylko je powtarza.
- Ograniczenia implementacji są nazwane wprost, nie pominięte.
Najczęstsze błędy w tym rozdziale
- Opis wyników jako „system działa poprawnie” bez tabeli przypadków testowych i konkretnych liczb.
- Pominięcie niezaliczonych testów lub przemilczenie błędów zamiast ich uczciwego omówienia.
- Brak macierzy łączącej wymagania z testami — recenzent nie widzi, czy każde wymaganie zostało zweryfikowane.
- Dyskusja będąca powtórzeniem wyników zamiast ich interpretacją względem celu pracy.
- Twierdzenie o gotowości produkcyjnej systemu bez opisania ograniczeń testów.
FAQ — rozdział z wynikami w pracy inżynierskiej z informatyki
Czy muszę przeprowadzać testy wydajnościowe, jeśli mój system jest małą aplikacją?
Nawet uproszczone testy (np. czas odpowiedzi dla kilku poziomów obciążenia) są wartościowe — pokazują, że autor rozumie różnicę między „działa” a „działa wydajnie”, niezależnie od skali projektu.
Ile przypadków testowych wystarczy do pracy inżynierskiej?
Nie ma sztywnej liczby — liczba przypadków powinna pokrywać wszystkie kluczowe funkcje systemu z rozdziału wymagań, co w typowej pracy licencjackiej/inżynierskiej daje zwykle 15–30 przypadków.
Czy mogę pokazać tylko zaliczone testy, pomijając te, które nie przeszły?
Nie — pominięcie niezaliczonych testów jest łatwe do wykrycia przy porównaniu z kodem źródłowym lub demonstracją na żywo, i jest oceniane znacznie gorzej niż uczciwe pokazanie błędu wraz ze statusem naprawy.
Jakich narzędzi użyć do testów wydajnościowych, jeśli nie znam się na tym dobrze?
Apache JMeter i k6 mają duże społeczności i tutoriale wprowadzające — obie pozwalają wygenerować podstawowy raport obciążeniowy bez zaawansowanej wiedzy o testowaniu wydajności.
Czy rozdział z wynikami musi zawierać zrzuty ekranu interfejsu?
Nie jest to obowiązkowe, ale kilka zrzutów ekranu kluczowych funkcji dobrze uzupełnia tabele testów, szczególnie przy demonstrowaniu, że dana funkcja rzeczywiście działa zgodnie z opisem.
Co jeśli mój system nie spełnił wszystkich zaplanowanych wymagań?
Opisz to wprost w macierzy zgodności i w dyskusji — niespełnione wymaganie z uczciwym wyjaśnieniem przyczyny (np. brak czasu, zmiana zakresu) jest normalną częścią pracy inżynierskiej, nie powodem do ukrywania.
Czy testy automatyczne są wymagane w pracy inżynierskiej z informatyki?
Nie zawsze formalnie wymagane, ale mile widziane — pokazują umiejętność, która jest standardem w zawodowym programowaniu, a nie tylko dodatkiem do pracy dyplomowej.
Co jeśli nie zdążę przetestować wszystkich funkcji systemu przed oddaniem pracy?
Lepiej opisać dokładnie przetestowane funkcje z pełnymi wynikami niż powierzchownie „przetestować” wszystko bez rzetelnej dokumentacji — jakość testów liczy się bardziej niż ich liczba.
Ogólną strukturę pracy inżynierskiej z informatyki, rozdział po rozdziale, opisaliśmy w jak napisać pracę inżynierską z informatyki. Ogólną, przekrojową wersję rozdziału z wynikami dla prac opartych na danych i hipotezach (nie na systemie) znajdziesz w masz wyniki, nie masz rozdziału. 30 przykładów tytułów prac dyplomowych z informatyki, z formułą budowy tytułu, znajdziesz w przykładach tytułów prac dyplomowych z informatyki. Wstęp napisany dla pracy inżynierskiej z informatyki, akapit po akapicie, opisaliśmy w wstępie do pracy dyplomowej — przykładzie gotowego tekstu.