Jak testować przesyłanie i pobieranie plików?

Użytkownik wybrał dokument, strona pokazuje jego nazwę i komunikat „Gotowe”. Czy plik trafił na serwer? Czy pobrany raport ma prawidłową treść? Te pytania dotyczą różnych etapów. W tej lekcji rozdzielisz wybór pliku, walidację w przeglądarce, wynik transferu i kontrolę pobrania. Na działającym przykładzie sprawdzisz granicę rozmiaru oraz niezgodną nazwę raportu.

Materiał jest dla początkujących testerów. Potrzebujesz przeglądarki i kilku syntetycznych plików. Laboratorium Pliki DEMO v1.0 nie wysyła nic na serwer: „Symuluj zapis” aktualizuje tylko tekst na stronie. Pobranie jest generowane w przeglądarce przez Blob. Dzięki temu można przećwiczyć dane i porównanie wyników bez używania prywatnych dokumentów. Nie jest to test zabezpieczeń uploadu backendu.

1. Ustal, który etap rzeczywiście testujesz

Wybór pliku oznacza wskazanie zasobu z dysku w systemowym oknie. Przeglądarka udostępnia stronie obiekt File opisujący wybrany plik. Walidacja lokalna sprawdza ustalone cechy, na przykład nazwę i rozmiar, przed dalszą akcją. Upload jest przesłaniem danych do odbiorcy. Wybranie pliku i wyświetlenie nazwy samo w sobie nie potwierdza uploadu.

Download, czyli pobranie, trzeba ocenić po otrzymanym pliku. Komunikat na stronie potwierdza co najwyżej uruchomienie akcji. Do wyniku potrzebujesz nazwy, obecności pliku i jego treści. W prawdziwym systemie dodatkowo możesz porównywać odpowiedź serwera z tym, co zapisano na dysku. W naszym demo serwer nie generuje raportu.

Podczas ustalania wymagań zapytaj o dozwolone formaty, minimalny i maksymalny rozmiar, liczbę plików oraz zachowanie po zmianie wyboru. Oddziel końcówkę nazwy od typu MIME i od faktycznej zawartości. Plik nazwany .png nie staje się obrazem dzięki samej nazwie. Przy pobraniu ustal także kodowanie tekstu i to, czy nazwa ma być stała, czy zawiera datę.

Wynik opisuj na poziomie, który obserwujesz. Lokalna akceptacja nie stanowi dowodu przyjęcia pliku przez backend.

2. Przeczytaj dokładną umowę demo

W instrukcji ćwiczenia znajdziesz wymagania i rozwiązania. Przyjmujemy jeden plik TXT, rozszerzenie .txt bez znaczenia wielkości liter, typ MIME text/plain i rozmiar od 1 do 1024 bajtów włącznie. Każdy nowy wybór unieważnia poprzednią akceptację. Pozytywna walidacja odblokowuje lokalny zapis. Reset usuwa wybór, zgodę i panel wyniku.

Niezależny przycisk pobiera raport o nazwie raport-demo.txt. Typ Blob to text/plain;charset=utf-8. Oczekiwana treść brzmi Raport DEMO: 3 przypadki, 1 błąd. i kończy się znakiem nowej linii. Wersja ćwiczenia zawiera dwa zamierzone defekty. Przycisk pobrania działa niezależnie od wybranego dokumentu, więc nie oczekuj w raporcie skopiowanej treści swojego pliku.

Jednostka ma znaczenie: 1024 B to dokładna liczba bajtów. Liczba widocznych znaków nie musi być taka sama. Polskie litery w UTF-8 mogą zajmować więcej niż jeden bajt, a edytor może dodać znak nowej linii lub znacznik kodowania. Własność size opisuje rozmiar w bajtach; jest to określone w dokumentacji Blob.size.

Nie zastępuj wymogu „od 1 do 1024 B włącznie” skrótem „mniej niż 1 KB”. Taki skrót usuwa informację o równości i może sugerować inną jednostkę. W tym ćwiczeniu wymaganie zostało dobrane do nauki granic, nie do potrzeb produkcyjnego systemu dokumentów.

3. Przygotuj pliki o znanym rozmiarze

Uruchom w katalogu projektu node tools/serwer-lekcji.cjs albo użyj istniejącego serwera. Otwórz:

http://127.0.0.1:8787/content/cwiczenia/pliki-demo/lab.html

Kliknij reset i zanotuj wersję przeglądarki. Przygotuj pliki 0, 1, 1023, 1024 oraz 1025 B. W instrukcji znajduje się gotowy kod PowerShell, który zapisuje w tmp/pliki-testowe odpowiednią liczbę liter ASCII bez dodatkowych znaków. Zweryfikuj kolumnę Length przed użyciem. Nazwa plik-1024.txt jest tylko opisem; sama nazwa nie potwierdza rozmiaru.

Jeżeli przygotowujesz plik w edytorze, porównaj jego rozmiar na stronie po wyborze. Nie dopisuj ręcznie spacji, żeby „wyglądał większy”. Dla testu granicy potrzebujesz dokładnej liczby bajtów. Puste dokumenty niektórych formatów mają nagłówki, więc pusty wizualnie plik PDF nie jest odpowiednikiem TXT o rozmiarze zero.

Przygotuj też syntetyczny zly.png z tekstem a. Ten plik nie jest prawdziwym obrazem. Służy sprawdzeniu niedozwolonego rozszerzenia oraz typu, bez wprowadzania złośliwej zawartości. Używaj wyłącznie testowych zasobów. W ćwiczeniu nie potrzebujemy rzeczywistych faktur, zdjęć ani dokumentów pracodawcy.

4. Wykonaj poprawną próbę i granice

Po resecie kliknij „Sprawdź plik” bez wyboru. Oczekuj prośby o plik i zablokowanego zapisu. Następnie wybierz plik-1.txt. Przeczytaj nazwę, liczbę bajtów oraz MIME wyświetlone na stronie. Kliknij walidację: lokalny zapis powinien zostać odblokowany. Kliknij „Symuluj zapis” i porównaj nazwę oraz rozmiar w panelu.

Powtórz procedurę dla wszystkich danych. Każdy plik wybieraj osobno, odczytuj jego cechy i dopiero potem sprawdzaj. Tabela rozdziela umowę od wyniku obecnej wadliwej wersji:

Na granicy 1024 B komunikat mówi, że rozmiar musi wynosić od 1 do 1024 B, ale właśnie taką wartość odrzuca. Zapisz pełny komunikat. Ten przypadek pokazuje, dlaczego zbadanie tylko „małego” i „dużego” pliku jest niewystarczające. Oba mogą zachowywać się poprawnie, podczas gdy równość jest błędna.

Inspekcja kodu demo potwierdza warunek f.size >= 1024. Powinno być f.size > 1024, ponieważ górna granica jest dozwolona. To ustalenie dotyczy tej implementacji. W raporcie dotyczącym innej aplikacji nie wpisuj przyczyny „zły operator”, jeśli widziałeś wyłącznie odrzucenie pliku.

5. Sprawdź typ i zmianę wybranego pliku

Pole ma atrybut accept ograniczający widoczne formaty w oknie wyboru. Jest to wskazówka dla przeglądarki, a nie pełna walidacja bezpieczeństwa. Użytkownik może mieć możliwość wybrania wszystkich plików. Taką rolę atrybutu określa HTML Standard: File Upload state.

Jeśli okno pozwala, wybierz zly.png przez opcję wszystkich plików. Zapisz MIME, które rozpoznała Twoja przeglądarka, i kliknij sprawdzenie. Oczekuj odrzucenia. Następnie wybierz poprawny plik o końcówce .TXT i dozwolonym rozmiarze. W demo wielkie litery rozszerzenia nie powinny powodować różnicy.

Typ File.type pochodzi z informacji dostępnych przeglądarce i może być pusty. Środowisko ma znaczenie: sam dobry tekst TXT nie daje gwarancji identycznego MIME na każdym systemie. Nasza ścisła reguła wymaga text/plain; jeżeli środowisko zgłasza pusty typ, zanotuj to jako osobny problem zgodności z regułą. Nie myl go z defektem rozmiaru.

Zatwierdź poprawny plik 1023 B, a potem wybierz inny, niedozwolony. Jeszcze przed ponowną walidacją zapis powinien zostać zablokowany. Inaczej mogłaby pozostać akceptacja dotycząca poprzedniego dokumentu. Sprawdź komunikat i nazwę aktualnego wyboru. W bieżącym demo unieważnienie działa prawidłowo.

Kliknij reset po symulacji zapisu. Pole ma zostać puste, zapis zablokowany, panel ma mówić „Brak zapisu”. Samo wyczyszczenie nazwy w jednym miejscu nie potwierdza całego resetu. Jeżeli po nowym wyborze poprzedni zapis nadal jest widoczny, rozróżnij historyczny wynik od aktualnej akceptacji: w tym ćwiczeniu nowy wybór unieważnia akceptację, a reset usuwa także wynik.

6. Pobierz raport i sprawdź plik

Przygotuj pusty folder testowy, aby nie pomylić nowego pliku ze starszym. Kliknij „Pobierz raport DEMO”. Sprawdź panel pobrań przeglądarki lub folder docelowy. W obecnej wersji sugerowana nazwa to raport-demo.csv, choć wymaganie mówi raport-demo.txt. To drugi celowy defekt: F02.

Otwórz otrzymany plik jako zwykły tekst. Powinien zawierać dokładnie zdanie o trzech przypadkach i jednym błędzie, wraz z polskim „ł” oraz końcowym znakiem nowej linii. Treść v1.0 jest poprawna. Nie uznawaj całego pobrania za „niedziałające”, skoro działa zapis i zawartość, a różnica dotyczy nazwy. Precyzyjne zgłoszenie pozwala przygotować adekwatną poprawkę.

Nazwa sugerowana przez stronę nie musi być identyczna z końcową nazwą w folderze. Przy kolizji przeglądarka może dodać numer. Dlatego dla testu stałego rozszerzenia ważny jest czysty folder albo odczyt sugestii przed zapisaniem. Mechanizm download i zależność od przeglądarki opisuje dokumentacja elementu a.

W demo raport tworzy Blob, czyli obiekt danych. Kod nadaje mu typ tekstowy, tworzy lokalny adres obiektu i uruchamia link do pobrania. Ten adres nie jest endpointem serwera. Nie szukaj odpowiedzi HTTP z raportem, której ćwiczenie nie implementuje. Budowę Blob opisuje dokumentacja tego API.

7. Jak rozszerzyć plan na prawdziwy upload?

W systemie z backendem zbadaj żądanie wysłania pliku i odpowiedź, następnie potwierdź obecność zasobu w dozwolony sposób. Komunikat frontendowy i odpowiedź API to odrębne dowody. Zaplanuj odrzucenie przez serwer, przerwanie połączenia, ponowienie oraz zachowanie częściowo wykonanej operacji. Przetestowanie tych sytuacji wymaga środowiska, które faktycznie przesyła dane.

Walidacja klienta nie stanowi zabezpieczenia serwera. OWASP wskazuje, że deklarowanemu typowi nie należy ufać jako samodzielnej kontroli; weryfikacja uploadu obejmuje między innymi format, limity, uprawnienia i sposób przechowywania. Zobacz OWASP File Upload Cheat Sheet. Nasze porównanie końcówki i MIME jest jedynie ćwiczeniem lokalnych reguł.

W prawdziwym pobieraniu sprawdź dostęp do zasobu z właściwym kontem i brak dostępu z kontem bez uprawnień. Ustal zachowanie nieistniejącego lub wygasłego pliku. Te scenariusze wymagają autoryzowanego środowiska i syntetycznych danych zespołu. Pliki DEMO nie mają kont, praw dostępu ani storage, więc żadnego z tych wyników nie można z nich wyprowadzić.

8. Zadanie, rozwiązanie i retest

Przygotuj dwa zgłoszenia: odrzucenie TXT 1024 B i rozszerzenie pobranego raportu. Dla pierwszego dołącz syntetyczny plik, jego rozmiar, MIME oraz kroki od resetu. Oczekiwane: lokalna akceptacja i odblokowany zapis. Rzeczywiste: komunikat odrzucenia i zablokowany przycisk. Dla drugiego podaj wymaganą nazwę TXT, sugerowaną CSV oraz osobną informację o poprawnej treści.

Po naprawie F01 powtórz pięć rozmiarów z tabeli i niedozwolony typ. Nie wystarczy, że 1024 B zacznie przechodzić: 1025 B nadal ma być odrzucany. Po naprawie F02 pobierz raport do pustego folderu i porównaj nazwę, zawartość oraz polskie znaki. W obu scenariuszach zachowaj test resetu i zmianę wyboru, ponieważ poprawki nie powinny zostawić starej akceptacji.

Weryfikację wykonano 2 października 2026: Node v24.16.0, Playwright, Chromium 151.0.7922.34, polecenie node tools/test-sklep-pliki.cjs. Potwierdzono granice, typ, wielkie TXT, unieważnianie stanu i rzeczywiste pobranie z odczytem zawartości. Dowody znajdują się w tmp/qa-sklep-pliki/. Automatyzacja nie bada każdego systemowego okna wyboru, a demo nie testuje zabezpieczeń uploadu backendu.

Uporządkuj próby z checklistą plików i jej PDF. Analizę rzeczywistej wymiany HTTP możesz następnie przećwiczyć w lekcji Network, pamiętając, że wykorzystuje ona inne laboratorium.