Jak projektować przypadki testowe: klasy, granice i warunki

Dziesięć poprawnych adresów i dziesięć haseł może dać dwadzieścia podobnych prób, które omijają najważniejszy błąd. Liczba przypadków nie mówi jeszcze, jakie reguły sprawdzono. W tej lekcji przełożysz wymagania formularza na mały zestaw danych: wybierzesz przedstawicieli klas, wartości przy limitach oraz kombinacje warunków. Każdy przypadek otrzyma uzasadnienie i wynik oczekiwany przed wykonaniem.

Potrzebujesz podstawowej znajomości formularza rejestracji. Pracujemy na lokalnym labie v1.0, z kontami tylko w pamięci serwera i syntetycznymi danymi. Nie przygotowujemy pełnego planu bezpieczeństwa ani testów wszystkich możliwych adresów pocztowych. Umiejętność po lekcji to wybór sprawdzeń, których sens potrafisz wyjaśnić.

1. Zacznij od podstawy testów

Podstawa testów to informacje, z których wyprowadzasz oczekiwania. W ćwiczeniu są nimi wymagania zapisane obok formularza i w instrukcji labu. Hasło ma mieć od 12 do 64 widocznych znaków ASCII bez spacji. Powtórzenie musi być identyczne. Regulamin jest obowiązkowy, marketing opcjonalny i początkowo wyłączony. E-mail ma projektowy, uproszczony format oraz nie może już istnieć.

Rozpisz wymagania osobno. „Poprawne dane tworzą konto” obejmuje więcej niż długość hasła: format e-maila, unikalność, powtórzenie, regulamin i tryb serwera. Jeśli połączysz wszystko w jedno zdanie, trudno będzie ustalić, dlaczego dana próba została odrzucona. Przy każdym wymaganiu zapisz sposób obserwacji: komunikat, brak żądania, HTTP, Payload albo stan kont.

Pytania również są częścią przygotowania. Czy hasło zawierające spację jest dozwolone? Czy e-mail obcina spacje z końców? Czy wielkość liter w powtórzeniu ma znaczenie? Tutaj odpowiedzi podano. W projekcie bez odpowiedzi nie twórz arbitralnej reguły. Zapisz niejasność i ustal ją, zanim wynik zostanie nazwany defektem.

2. Oddziel warunek, przypadek i wykonanie

Warunek testowy mówi, co trzeba sprawdzić, na przykład „dolna granica długości”. Przypadek określa dane, stan początkowy, kroki i oczekiwany rezultat. Wykonanie dodaje datę, środowisko, rzeczywisty wynik i ocenę. Ta kolejność zapobiega dopasowywaniu oczekiwania do tego, co zrobiła wadliwa aplikacja.

Przykład przypadku: po resecie, w zwykłym trybie, wpisz nowy adres, identyczne hasła po 11 znaków, zaznacz regulamin i wyłącz marketing. Oczekuj odrzucenia oraz braku konta. Jeśli demo przyjmie dane, przypadek nie staje się „pozytywny”. To wynik sprzeczny z wymaganiem, który trzeba opisać.

Do początkującego zestawu wystarczą pola: ID, wymaganie, warunki, dane, kroki, oczekiwany wynik i miejsce na wynik rzeczywisty. Nie potrzebujesz rozbudowanego szablonu dla każdej krótkiej próby. Nie pomijaj jednak stanu serwera: adres, który przed chwilą utworzyłeś, w następnym teście może już być duplikatem.

3. Podziel dane na klasy równoważności

Klasa równoważności grupuje wartości, dla których według reguły oczekujesz podobnego przetwarzania. Podział długości naszego hasła jest prosty: mniej niż 12, od 12 do 64 włącznie, więcej niż 64. Wybór reprezentanta z każdej klasy ogranicza liczbę prób, ale nie dowodzi poprawności wszystkich wartości. Technika opiera się na założeniu o podobnym zachowaniu w klasie, opisanym w ISTQB CTFL v4.0.1, sekcja 4.2.1.

To kilka wymiarów, a nie jedna płaska klasyfikacja. Hasło może jednocześnie być za krótkie i zawierać niedozwolony znak. Dla testu pojedynczej reguły wybierz poprawne pozostałe wymiary. Dwanaście liter z ą na końcu sprawdza zestaw znaków, a nie niewłaściwą długość.

Nie uznawaj wszystkich niepoprawnych e-maili za wystarczająco sprawdzone po jednym przykładzie. Brak @, brak części przed separatorem i brak końcówki domeny mogą uruchamiać różne kontrole. Podział służy projektowaniu, ale wymaganie i wiedza o funkcji pomagają ocenić, kiedy potrzebujesz dodatkowych podklas. Uproszczony format demo nie jest pełnym standardem poczty.

4. Zbadaj granice po obu stronach

Błędy często ujawniają się blisko przejścia między dozwolonym i niedozwolonym zakresem. Dla liczb całkowitych opisujących długość możesz wybrać zestaw dwuwartościowy 11, 12, 64, 65: sąsiadujące wartości po obu stronach dwóch przejść. Dla granic samej klasy poprawnej, 12 i 64, ich sąsiedztwo daje sześć wartości: 11, 12, 13, 63, 64, 65.

Wartości wewnętrzne 13 i 63 uzupełniają sprawdzenie limitów. Wszystkie pozostałe warunki utrzymuj poprawne.

Pierwszy zestaw zawiera cztery różne wartości, drugi sześć. Nie nazywaj jednak drugiego pełnym trzywartościowym pokryciem wszystkich trzech klas według ISTQB. Klasy niepoprawne mają także granice 11 i 65; ich sąsiedztwo dodaje 10 i 66. Pełny zestaw wokół tych przejść to 10, 11, 12, 13, 63, 64, 65, 66, czyli osiem unikalnych wartości. Infografika celowo pokazuje węższy plan wokół granic klasy poprawnej. Zawsze nazwij, które granice objęto. Przy małych zakresach sąsiedztwa mogą się nakładać; wtedy licz unikalne dane.

W konsoli możesz przygotować dane przez 'a'.repeat(11) i analogiczne wyrażenia dla kolejnych długości. Sprawdź .length, zanim skopiujesz tekst. Generator nie wykonuje testu formularza. W tej lekcji automatycznie sprawdzono długości wygenerowanych ciągów; potwierdzono także dostępny wcześniej scenariusz fałszywego sukcesu 503. Wyniki wszystkich prób granicznych czytelnik musi zapisać po własnym wykonaniu.

Granice dotyczą również czasu, ceny czy liczby plików, jeśli wymaganie określa uporządkowany zakres. Nie szukaj automatycznie „wartości tuż obok” dla koloru albo typu konta. Tam sensowniejszy może być podział klas lub tabela warunków. Technikę dopasuj do reguły, nie do nazwy pola.

5. Nie pomyl znaków z jednostkami kodowania

Dlaczego w demo używamy liter ASCII? Dzięki temu jedna litera a zajmuje jedną jednostkę licznikową JavaScript, a oczekiwanie jest jednoznaczne. Dla dowolnego tekstu String.length mierzy jednostki kodowe UTF-16, a nie zawsze liczbę znaków widzianych przez człowieka. Opisuje to MDN: String.length.

Emoji może dać długość większą niż jeden, a wizualny znak może składać się z kilku elementów Unicode. Jeśli projekt dopuszcza taki tekst, wymaganie musi ustalić sposób liczenia. W tej lekcji nie rozszerzamy polityki hasła samodzielnie. Test ą ma dać odrzucenie z powodu zestawu znaków, a nie służyć sprawdzeniu pełnej obsługi Unicode.

Podobnie nie przenoś limitów 12–64 do innego produktu jako gotowej polityki bezpieczeństwa. Są regułą dydaktycznej aplikacji. Metoda pozostaje użyteczna przy innych wartościach, lecz liczby i interpretacja muszą pochodzić z właściwej specyfikacji.

6. Wykorzystaj tabelę warunków dla kombinacji

Długość to tylko jeden rodzaj problemu. Gdy decyzja zależy od kilku warunków, zapisz ich kombinacje. Uprość najpierw sytuację: zwykły tryb serwera, poprawny i nowy e-mail, dozwolone hasło. Rozpatruj tylko zgodność powtórzenia oraz akceptację regulaminu.

Dwa warunki binarne dają 2 × 2 = 4 kombinacje. To lokalna tabela dla ograniczonego zakresu, nie pełna tabela rejestracji. Dodanie niezależnego warunku binarnego podwaja liczbę kombinacji. Nie musisz wykonywać wszystkich możliwych kombinacji całego formularza, ale musisz wiedzieć, co pomijasz i dlaczego.

R4 sprawdza współwystępowanie dwóch problemów. Jeśli formularz pokaże tylko informację o regulaminie, nie dowodzi to sprawdzenia zgodności haseł. R2 jest potrzebna do izolowania tej reguły. Jeśli wymaganie nie ustala kolejności błędów, nie zgłaszaj defektu tylko dlatego, że spodziewałeś się najpierw innego komunikatu.

7. Zbuduj przypadek, który daje rozstrzygający wynik

Przypadek PT-11 może wyglądać tak:

Cel: odrzucenie hasła tuż poniżej minimum.
Warunki: reset; zwykły tryb; sieć online; nowy adres.
Dane: granica11@example.com; oba hasła abcdefghijk;
       regulamin tak; marketing nie.
Kroki: wypełnij podanymi danymi, wyślij, odczytaj UI i stan.
Oczekiwanie: rejestracja odrzucona; adres nie dodany do stanu.
Wynik rzeczywisty: [uzupełnij po próbie].

Odrzucenie nie musi automatycznie oznaczać HTTP 422. Poprawny frontend może zablokować wysłanie przed żądaniem. Jeśli przypadek ma sprawdzać backend, nazwij warstwę i wywołaj API według instrukcji labu. „Brak konta” nie odpowiada wtedy na całe pytanie: potrzebujesz statusu oraz odpowiedzi walidacji.

Po każdej niezależnej próbie resetuj stan i ustawienia. Alternatywą w produkcie bywa kontrolowany zestaw unikalnych danych, ale nie pozwala on zapomnieć o innych zależnościach. Dla próby duplikatu przeciwnie: najpierw utwórz konto, a potem zachowaj stan. Reset pomiędzy tymi dwoma krokami zniszczyłby warunek testowy.

8. Policz pokrycie i oddziel je od zaliczenia

Najpierw zdefiniuj mianownik. Jeżeli celem są trzy klasy długości, wykonanie po jednym reprezentancie daje pokrycie 3/3 w tym wymiarze. Nie daje 100% wszystkich testów formularza. Jeśli wybrałeś sześć wartości granicznych i wykonałeś cztery, wykonanie wynosi 4/6, czyli około 66,7% zaplanowanych wartości.

Zaliczenie jest czymś innym. Jeśli w czterech wykonanych próbach jedna ujawni błąd, masz trzy wyniki zgodne z wymaganiem i jeden niezgodny. Dwa pozostałe są niewykonane. Nie licz ich jako poprawnych ani jako defektów. Zapisuj status „zablokowany”, jeśli brak środowiska uniemożliwił próbę, wraz z przyczyną.

Przypadek może sprawdzać kilka wcześniej nazwanych elementów pokrycia, ale nie dodawaj ich po fakcie, aby zwiększyć procent. Dane poprawne długościowo nie muszą sprawdzać całej klasy obsługi Unicode, zgód i awarii. Raport pokrycia jest użyteczny dopiero wraz z zakresem oraz brakującymi sprawdzeniami.

9. Zadanie i rozwiązanie

Przygotuj sześć przypadków granicznych dla hasła, cztery reguły z tabeli warunków oraz jeden scenariusz duplikatu. Przy każdym wskaż oczekiwanie i stan początkowy. Wykonaj najpierw 11 i 12 znaków, następnie R2. Resztę oznacz jako niewykonaną, dopóki nie przeprowadzisz prób. Do organizacji wykorzystaj checklistę rejestracji.

Rozwiązanie planu długości to 11, 12, 13, 63, 64, 65. Pierwszą i ostatnią wartość należy odrzucić, cztery środkowe przyjąć przy poprawnej reszcie. R2 powinna zostać odrzucona z powodu różnego powtórzenia. Wadliwy lab może przyjąć 11 znaków i niezgodne hasła: takie zachowanie należy opisać jako defekt, nie zmienić tabelę oczekiwań.

Dla duplikatu użyj początkowo zajętego zajety@example.com albo utwórz nowy adres i wyślij go ponownie bez resetu. Oczekuj 409 oraz braku kolejnego konta. W drugim wariancie przypadek ma dwa etapy i zależność między nimi. Ujęcie tego w warunkach pozwala uniknąć fałszywego wyniku z przypadkowo nowym adresem.

Po poprawce minimum powtórz 11, 12 i 13 znaków. Po poprawce powtórzenia sprawdź różne i identyczne wartości. To ograniczona regresja sąsiednich reguł, która może wychwycić odwrócenie warunku albo przesunięcie granicy. Nie zastępuje pełnego zestawu produktu.

Źródła sprawdzono 2 października 2026 r.; sylabus ISTQB v4.0.1 wykorzystano do krótkich definicji, a zestawy i obliczenia są autorskim planem dla demo. Zweryfikowano długości generatora danych w Node i odczytano kod labu; nie przedstawiamy wszystkich przypadków z tabel jako wykonanych. Materiał przygotowany z pomocą AI, autor serwisu Marcin Kozłowski. Dalej: testy eksploracyjne i ryzyko.