ZAWODNIK

Testowanie, debugowanie i dokumentacja aplikacji

INF.03 · teoria
autor: redakcja · 02.11.2026
Błędy składni, wykonania i logiki, przypadki testowe, debugger przeglądarki oraz ponowne sprawdzenie poprawki. Komentarze, dokumentacja techniczna i instrukcja użytkownika. Lekcja 10.4 kursu INF.03.
Te­sto­wa­nie to po­rów­ny­wa­nie rze­czy­wi­ste­go za­cho­wa­nia pro­gra­mu z wcze­śniej okre­ślo­nym wy­ni­kiem. Na eg­za­mi­nie trzeba zna­leźć błąd w kodzie, prze­śle­dzić stan zmien­nych, po­pra­wić dzia­ła­nie i przy­go­to­wać do­ku­men­ta­cję. W prak­tycz­nym pro­jek­cie test nie kończy się na otwar­ciu strony: obej­mu­je też for­mu­larz, ob­li­cze­nia, dane błędne i spraw­dze­nie skut­ków po­praw­ki.

Ro­dza­je błędów i czy­ta­nie ko­mu­ni­ka­tów

Błąd skład­ni ozna­cza zapis nie­zgod­ny z re­gu­ła­mi języka, na przy­kład brak na­wia­su lub dwu­krop­ka. Błąd wy­ko­na­nia po­ja­wia się pod­czas pracy, gdy pro­gram pró­bu­je wy­ko­nać nie­do­zwo­lo­ną ope­ra­cję, na przy­kład po­dzie­lić przez zero. Błąd lo­gicz­ny daje nie­wła­ści­wy wynik mimo po­praw­nej skład­ni i moż­li­wo­ści uru­cho­mie­nia. Zły próg rabatu może nie wy­wo­łać żad­ne­go ko­mu­ni­ka­tu błędu.
Ko­mu­ni­kat czyta się razem z nazwą pliku, nu­me­rem wier­sza i kon­tek­stem. Miej­sce wy­kry­cia pro­ble­mu nie zawsze jest miej­scem jego po­wsta­nia. Brak za­my­ka­ją­ce­go na­wia­su może zostać za­uwa­żo­ny do­pie­ro przy na­stęp­nej in­struk­cji. Nie za­czy­naj od ka­so­wa­nia wska­za­ne­go wier­sza. Sprawdź rów­nież in­struk­cję po­prze­dza­ją­cą i to, jak pro­gram trafił do danego miej­sca.
W Py­tho­nie dzie­le­nie liczby przez zero zgła­sza ZeroDivisionError, czyli błąd dzie­le­nia przez zero. Brak de­fi­ni­cji użytej nazwy może zgło­sić NameError. Taki ko­mu­ni­kat zawęża po­szu­ki­wa­nia, lecz nie po­dej­mu­je de­cy­zji, jaki wynik apli­ka­cja po­win­na zwró­cić dla braku danych. Wy­ma­ga­nie okre­śla autor za­da­nia, a do­ku­men­ta­cja języka wy­ja­śnia me­cha­nizm błędu. Roz­róż­nie­nia opi­su­je do­ku­men­ta­cja Py­tho­na.

Przy­pa­dek te­sto­wy i war­to­ści gra­nicz­ne

Przy­pa­dek te­sto­wy opi­su­je dane, czyn­no­ści i ocze­ki­wa­ny wynik. Dla funk­cji przy­zna­ją­cej rabat trzeba usta­lić próg. Za­łóż­my, że od trzech sztuk obo­wią­zu­je cena 20 zł, a po­ni­żej trzech cena 25 zł. Test dwóch sztuk po­wi­nien dać 50 zł, trzech 60 zł, a czte­rech 80 zł. Te­sto­wa­nie wy­łącz­nie pięciu sztuk nie spraw­dza, czy rabat za­czy­na się w pra­wi­dło­wym miej­scu.
War­to­ści gra­nicz­ne leżą na gra­ni­cy wa­run­ku i tuż obok niej. Dla mi­ni­mum rów­ne­go jeden spraw­dza się zero, jeden i dwa. Dla listy spraw­dza się brak ele­men­tów, jeden ele­ment i wiele ele­men­tów. Przy for­mu­la­rzu spraw­dza się także pusty tekst, nie­pra­wi­dło­wy zapis i wie­lo­krot­ne uru­cho­mie­nie ope­ra­cji. Ocze­ki­wa­ne za­cho­wa­nie dla danych błęd­nych musi być usta­lo­ne przed oceną wyniku.
Test jed­nost­ko­wy spraw­dza wy­dzie­lo­ny frag­ment, na przy­kład funk­cję li­czą­cą kwotę. Test in­te­gra­cyj­ny bada współ­pra­cę części, na przy­kład skryp­tu i bazy. Test całego pro­ce­su prze­cho­dzi przez dzia­ła­nia użyt­kow­ni­ka, od otwar­cia for­mu­la­rza do po­twier­dze­nia. Te po­zio­my wy­kry­wa­ją różne pro­ble­my. Po­praw­na funk­cja nie gwa­ran­tu­je, że przy­cisk prze­ka­zu­je do niej od­po­wied­nie dane.
Przy­kła­do­wy zapis testu po­wi­nien po­zwo­lić innej osobie go po­wtó­rzyć. „For­mu­larz nie działa” jest za mało do­kład­ne. „Po wpi­sa­niu 3 w pole liczby sztuk i klik­nię­ciu Oblicz wi­docz­na kwota to 75 zł, ocze­ki­wa­no 60 zł” wska­zu­je dane, dzia­ła­nie i róż­ni­cę. Do ra­por­tu dopisz wersję apli­ka­cji lub nazwę spraw­dza­ne­go pliku, aby wia­do­mo było, czego do­ty­czył wynik.

Od objawu do przy­czy­ny

De­bu­go­wa­nie to usta­la­nie przy­czy­ny błędu na pod­sta­wie ob­ser­wa­cji pro­gra­mu. Naj­pierw od­twórz pro­blem na moż­li­wie małym przy­kła­dzie. Potem po­rów­naj dane wej­ścio­we, stan po­śred­ni i wynik. Zmie­niaj jedną uza­sad­nio­ną rzecz naraz, aby wie­dzieć, co spo­wo­do­wa­ło róż­ni­cę. Przy­pad­ko­we po­praw­ki w kilku pli­kach utrud­nia­ją po­twier­dze­nie przy­czy­ny.
Po­niż­szy pro­gram ma po­praw­ną skład­nię, ale nie zgadza się z pro­giem rabatu przy­ję­tym w po­przed­niej sekcji:
1
2
3
4
5
6
7
8
function obliczKwote(ilosc) {
let cena = 25;
if (ilosc > 3) {
cena = 20;
}
return cena * ilosc;
}
console.log(obliczKwote(3));
Wynik to 75. Wa­ru­nek wymaga więcej niż trzech sztuk, więc dla trzech cena zo­sta­je równa 25. Przy­czy­na leży w ope­ra­to­rze po­rów­na­nia. Za­stą­pie­nie go ope­ra­to­rem „więk­sze lub równe” na­pra­wia tę gra­ni­cę:
1
2
3
if (ilosc >= 3) {
cena = 20;
}
To frag­ment za­stę­pu­ją­cy wa­ru­nek we­wnątrz po­przed­niej funk­cji, a nie osobny kom­plet­ny pro­gram. Po zmia­nie wy­wo­ła­nie dla trzech sztuk zwraca 60. Nie należy zmie­niać ceny ba­zo­wej na 20, bo wtedy dwa za­mó­wio­ne pro­duk­ty także do­sta­ły­by rabat. Po­praw­ka ma przy­wró­cić regułę, a nie tylko do­pa­so­wać jeden wynik.

De­bug­ger w prze­glą­dar­ce

De­bug­ger prze­glą­dar­ki po­zwa­la za­trzy­mać wy­ko­na­nie JavaScript i obej­rzeć stan. Otwórz stronę z pełną funk­cją z po­przed­nie­go przy­kła­du w pliku JS, uru­chom na­rzę­dzia de­we­lo­per­skie i przejdź do panelu So­ur­ces (źródła). Otwórz plik i ustaw punkt prze­rwa­nia, czyli miej­sce za­trzy­ma­nia, na wier­szu z wa­run­kiem. Od­śwież stronę, aby wy­ko­nać skrypt po­now­nie.
Po za­trzy­ma­niu sprawdź war­to­ści ilosc i cena w panelu za­kre­su zmien­nych albo przez do­da­nie ich do ob­ser­wo­wa­nych wy­ra­żeń. Po­win­ny wy­no­sić 3 i 25. Przejdź jeden krok dalej i sprawdź, czy wy­ko­na­nie weszło do wnę­trza wa­run­ku. W błęd­nej wersji nie wej­dzie. Ta ob­ser­wa­cja po­twier­dza, że pro­blem jest zwią­za­ny z de­cy­zją, a nie z dzia­ła­niem mno­że­nia.
Step over (krok bez wcho­dze­nia) wy­ko­nu­je bie­żą­cą in­struk­cję, trak­tu­jąc wy­wo­ła­nie funk­cji jako całość. Step into (krok do wnę­trza) po­zwa­la wejść do wy­wo­ły­wa­nej funk­cji, a Step out (wyj­ście z funk­cji) wraca do miej­sca jej wy­wo­ła­nia. Resume (wznów) kon­ty­nu­uje do na­stęp­ne­go za­trzy­ma­nia. Nazwy i ikony mogą za­le­żeć od prze­glą­dar­ki; zna­cze­nie ope­ra­cji po­zo­sta­je po­dob­ne. Pro­ce­du­rę opi­su­je do­ku­men­ta­cja Chrome DevTools.
Stos wy­wo­łań po­ka­zu­je, które funk­cje do­pro­wa­dzi­ły do ak­tu­al­ne­go miej­sca. Jest przy­dat­ny, gdy ten sam kod uru­cha­mia kilka przy­ci­sków. De­bug­ger strony nie za­trzy­ma au­to­ma­tycz­nie kodu PHP wy­ko­ny­wa­ne­go na ser­we­rze. Dla PHP używa się na­rzę­dzi i logów po stro­nie ser­we­ra. Kon­so­la JavaScript może zo­ba­czyć od­po­wiedź PHP, lecz nie od­czy­tu­je bez­po­śred­nio jego zmien­nych.

Po­praw­ka i test re­gre­sji

Test re­gre­sji to spraw­dze­nie, czy póź­niej­sza zmiana nie przy­wró­ci­ła wcze­śniej usu­nię­te­go pro­ble­mu. Po na­pra­wie progu zapisz test trzech sztuk jako przy­pa­dek kon­tro­l­ny. Na­stęp­nie sprawdź także dwie i cztery sztuki, po­nie­waż po­praw­ka wa­run­ku wpływa na po­dział całego za­kre­su. Jeżeli pro­gram ma ob­słu­gi­wać brak towaru lub nie­po­praw­ną liczbę, te wy­ma­ga­nia po­trze­bu­ją osob­nych przy­pad­ków.
Wa­li­da­cja skład­ni spraw­dza zgod­ność zapisu z re­gu­ła­mi języka. Po­le­ce­nie PHP z opcją -l może spraw­dzić skład­nię pliku bez nor­mal­ne­go wy­ko­na­nia pro­gra­mu, ale nie po­twier­dzi wyniku ob­li­czeń i po­praw­no­ści po­łą­cze­nia z bazą. Po­dob­nie wa­li­da­tor HTML nie ocenia pełnej logiki apli­ka­cji. Zakres na­rzę­dzia trzeba ze­sta­wić z ro­dza­jem pro­ble­mu.
Raport po po­praw­ce po­wi­nien po­ka­zać: jaki błąd od­two­rzo­no, jaka była przy­czy­na, co zmie­nio­no i jakie przy­pad­ki spraw­dzo­no po­now­nie. Nie trzeba prze­pi­sy­wać całego kodu. Zapis ocze­ki­wa­ne­go i rze­czy­wi­ste­go wyniku daje moc­niej­szy dowód niż ogólne stwier­dze­nie o po­praw­nym dzia­ła­niu.

Ko­men­ta­rze i do­ku­men­ta­cja

Ko­men­tarz wy­ja­śnia kod osobie, która będzie go czytać. Naj­bar­dziej pomaga przy za­ło­że­niach i po­wo­dach nie­ty­po­wej de­cy­zji. Opis „zwiększ licz­nik o jeden” przy oczy­wi­stym zwięk­sze­niu zwykle nic nie wnosi. Opis „próg obej­mu­je także do­kład­nie trzy sztuki” do­ku­men­tu­je regułę, którą łatwo omył­ko­wo zmie­nić. Nie­ak­tu­al­ny ko­men­tarz trzeba po­pra­wić razem z kodem.
W JavaScript ko­men­tarz jed­no­li­nio­wy za­czy­na się od // i trwa do końca wier­sza. Ko­men­tarz blo­ko­wy za­pi­su­jesz między /* i */; może obej­mo­wać kilka wier­szy. In­ter­pre­ter pomija ko­men­ta­rze, ale po­zo­sta­ją one w źródle dla czy­ta­ją­cej je osoby. Przy po­pra­wio­nym wa­run­ku zapisz powód wyboru gra­ni­cy:
1
2
3
4
// Rabat obejmuje także dokładnie trzy sztuki, zgodnie z cennikiem.
if (ilosc >= 3) {
cena = 20;
}
To ko­men­tarz o regule biz­ne­so­wej. Po zmia­nie cen­ni­ka sprawdź za­rów­no wa­ru­nek, jak i jego opis, aby nie prze­ka­zy­wa­ły sprzecz­nych in­for­ma­cji.
Do­ku­men­ta­cja tech­nicz­na opi­su­je prze­zna­cze­nie pro­gra­mu, struk­tu­rę plików, wy­ma­ga­ne wersje i sposób uru­cho­mie­nia. Po­win­na wska­zać kon­fi­gu­ra­cję bazy, przy­go­to­wa­nie danych i sposób spraw­dze­nia dzia­ła­nia. Hasło do rze­czy­wi­ste­go konta nie po­win­no być pu­blicz­nym ele­men­tem in­struk­cji. Warto roz­dzie­lić przy­kła­do­wą kon­fi­gu­ra­cję od se­kre­tów uży­wa­nych na danym sta­no­wi­sku.
In­struk­cja użyt­kow­ni­ka opi­su­je czyn­no­ści z punktu wi­dze­nia osoby ko­rzy­sta­ją­cej z apli­ka­cji. Dla kal­ku­la­to­ra wy­ja­śnia otwar­cie strony, do­zwo­lo­ne war­to­ści, przy­cisk ob­li­cze­nia i odczyt wyniku. Po­win­na także po­wie­dzieć, co zrobić po ko­mu­ni­ka­cie o błę­dzie. Nazwy zmien­nych, za­py­ta­nia SQL i lo­ka­li­za­cja punktu prze­rwa­nia zwykle nie po­ma­ga­ją temu od­bior­cy. Ten sam pro­gram po­trze­bu­je więc róż­nych do­ku­men­tów dla róż­nych zadań.

Na eg­za­mi­nie

Przy szu­ka­niu błędu naj­pierw oblicz ocze­ki­wa­ny wynik i prze­śledź kon­kret­ne war­to­ści. Od­róż­nij brak śred­ni­ka od złego progu i od błędu po­łą­cze­nia. Jeśli wy­ma­ga­ny jest de­bug­ger, pokaż punkt za­trzy­ma­nia i stan zmien­nych, a nie wy­łącz­nie otwar­tą kon­so­lę. Do­ku­men­ta­cja po­win­na do­ty­czyć od­da­nej wersji pro­gra­mu.
Pu­łap­ka: po­praw­ka, która daje dobry wynik tylko dla jed­ne­go spraw­dzo­ne­go wej­ścia, może psuć po­zo­sta­łe przy­pad­ki. Po zmia­nie sprawdź obie strony gra­ni­cy wa­run­ku.
W pracy prak­tycz­nej za­cho­waj wy­ma­ga­ne zrzuty i pliki, usuń przy­pad­ko­we ko­mu­ni­ka­ty dia­gno­stycz­ne z koń­co­we­go widoku oraz po­now­nie przejdź główny sce­na­riusz. Użyt­kow­nik po­wi­nien otrzy­mać zro­zu­mia­ły re­zul­tat, a osoba spraw­dza­ją­ca moż­li­wość od­two­rze­nia wyniku.

Ściąga

Po­ję­cie
Co spraw­dza lub opi­su­je
błąd skład­ni
nie­po­praw­ny zapis języka
błąd wy­ko­na­nia
nie­do­zwo­lo­na ope­ra­cja pod­czas pracy
błąd lo­gicz­ny
wynik sprzecz­ny z wy­ma­ga­niem
przy­pa­dek te­sto­wy
wej­ście, czyn­no­ści, ocze­ki­wa­ny wynik
bre­ak­po­int
punkt za­trzy­ma­nia de­bug­ge­ra
test re­gre­sji
brak po­wro­tu wcze­śniej­sze­go błędu
do­ku­men­ta­cja tech­nicz­na
budowa, wy­ma­ga­nia, uru­cho­mie­nie
in­struk­cja użyt­kow­ni­ka
ob­słu­ga i re­ak­cja na ko­mu­ni­ka­ty
Pobierz ściągę PDF

[ W TYM DZIALE ]

poprzednia: Warsztat: edytor, IDE, XAMPP, localhost, narzędzia deweloperskie przeglądarkispis działu: Programowanie: pojecia, algorytmy, warsztat

[ INF.03: INNE ARTYKUŁY ]

Hub INF.03Zakres materiałuDokumenty CKEFormularze HTML na egzaminie INF.03Grafika i multimedia na egzaminie INF.03JavaScript na egzaminie INF.03Zapytania SQL na egzaminie INF.03Bazy danych i SQL na egzaminie INF.03pokaż więcej (85)
ZAWODNIK
egzamin zawodowy INF.02 · INF.03 · INF.04
Serwer Discord›
Egzaminy zawodowe IT/Matury/Studia
@yastor
Polityka prywatnościRegulaminKontakt
© 2026 Zawodnik · by Yastor
Arkusze i zasady oceniania pochodzą z CKE. Serwis nie jest powiązany z Centralną Komisją Egzaminacyjną.