Nowi testerzy często słyszą te dwa terminy używane tak, jakby oznaczały to samo. Oni nie. Różnica między przypadkiem testowym a scenariuszem testowym polega głównie na poziomie szczegółowości, a jego zrozumienie pomaga zdecydować, ile napisać przed rozpoczęciem testowania.

W tym przewodniku opisano każdy z nich, a następnie omówiono funkcję resetowania pojedynczego hasła, począwszy od wymagań, przez scenariusze, aż po pełne przypadki testowe. Funkcja i jej zasady są wymyślonym przykładem. Terminologia również różni się nieco w zależności od zespołu i narzędzia, więc uzgodnij, co te słowa oznaczają w Twoim zespole.

Krótka odpowiedź

Scenariusz testowy opisuje sytuację, którą należy sprawdzić, na przykład „sprawdź, czy użytkownik może zresetować zapomniane hasło”. Zwykle jest to jedna linia i szczegóły pozostawia testerowi.

Przypadek testowy dokładnie opisuje, jak sprawdzić jeden warunek w tej sytuacji: warunki wstępne, kroki, dane testowe i oczekiwany wynik. Dwóch testerów podążających za nim powinno dojść do tego samego werdyktu.

Pomyśl o zaplanowaniu podróży. Scenariusz to „podróż z Pune do Delhi”. Przypadek testowy to pełny plan podróży, z numerem lotu, godziną odlotu i czynnościami do wykonania na każdym etapie.

Przypadek testowy i scenariusz testowy obok siebie

Co to jest scenariusz testowy?

Scenariusz testowy to krótki opis czynności, którą może wykonać użytkownik, lub sytuacji, z którą musi sobie poradzić system. Koncentruje się na tym, co ważne z zewnątrz i zwykle wynika bezpośrednio z wymagań lub historii użytkownika.

Scenariusze są cenne, ponieważ są szybkie. Możesz wymienić trzydzieści w czasie potrzebnym na napisanie trzech szczegółowych przypadków, co czyni je doskonałym sposobem na sprawdzenie zasięgu z właścicielem produktu: „czy pomyśleliśmy o wszystkim?” Czytelnik nietechniczny może bez problemu śledzić listę scenariuszy.

Co to jest przypadek testowy?

Przypadek testowy to zestaw określonych warunków i kroków służących do ustalenia, czy dana rzecz działa. Typowy przypadek testowy zawiera:

• Unikalny identyfikator i wyraźny tytuł
• Warunki wstępne, czyli to, co musi być spełnione przed rozpoczęciem
• Numerowane kroki
• Konkretne dane testowe
• oczekiwany wynik
• rzeczywisty wynik i stan wypełniane podczas uruchamiania

Przypadki testowe wyróżniają się, gdy liczy się spójność. Nowy członek zespołu może je uruchomić, wyniki można porównać w różnych wersjach, a Ty masz zapis tego, co zostało zweryfikowane. Zagłębiamy się w nasz przewodnik na temat jak pisać przypadki testowe.

Jedna funkcja, od początku do końca

Krok 1: Wymaganie

Użytkownicy, którzy zapomną hasła, mogą poprosić o link resetujący za pośrednictwem poczty elektronicznej. Link działa jednorazowo i wygasa po 30 minutach. Nowe hasło musi mieć co najmniej 8 znaków.

Krok 2: Scenariusze testowe

Spójrz na TS-02. Wymóg nigdy nie określa, co powinno się stać z nieznanym adresem e-mail, a napisanie scenariusza ujawniło tę lukę. Czy strona powinna ujawniać, że adres nie jest zarejestrowany? Ze względów bezpieczeństwa zwykle nie powinno, ponieważ umożliwia to atakującym odkrycie prawidłowych kont. Wczesne znalezienie tych pytań jest jedną z największych korzyści pisania scenariuszy.

Krok 3: Przypadki testowe

Teraz rozszerzamy tylko TS-05 o przypadki testowe. Jeden scenariusz staje się kilkoma:

Wartości te nie były przypadkowe. TC-051 i TC-052 znajdują się po obu stronach granicy, wykorzystując analizę wartości brzegowych, a pozostałe pochodzą z podziału równoważności.

Szablon przypadku testowego

Oto pełna wersja TC-052. Skopiuj ten układ, jeśli Twój zespół nie ma jeszcze standardu:

ID:            TC-052
Title:         Reset rejects a password of 7 characters
Scenario:      TS-05 New password rules are enforced
Priority:      High
Preconditions: Account asha@example.com exists
               A valid, unused reset link has been requested
Test data:     New password: abcd123

Steps:
  1. Open the reset link from the email
  2. Enter abcd123 in New password
  3. Enter abcd123 in Confirm password
  4. Click Reset password

Expected:      Error "Password must be at least 8 characters"
               Password is unchanged, and the link stays valid
Actual:        (filled in during the run)
Status:        (Pass / Fail / Blocked)

Zauważ, że oczekiwany wynik sprawdza więcej niż komunikat o błędzie. Potwierdza również, że stare hasło nadal działa i że link jest nadal użyteczny. Słabe przypadki testowe często zatrzymują się na tym, co widać na ekranie.

Tam, gdzie mieszczą się w szerszym obrazie

Tradycyjnie scenariusze i przypadki są pisane na etapie projektowania testów w cyklu życia testowania oprogramowania.

Kiedy używać każdego z nich

Scenariusze są często wystarczające, gdy:

• Zespół jest mały, doświadczony i dobrze zna produkt.
• Czasu jest mało lub wymagania często się zmieniają.
• Cechą jest niskie ryzyko.
• Chcesz szybko przejrzeć zasięg z zainteresowanymi stronami.
• Kierujesz testami eksploracyjnymi.

Szczegółowe przypadki testowe są warte wysiłku, gdy:

• Awaria byłaby kosztowna, podobnie jak w przypadku płatności, bezpieczeństwa czy danych zdrowotnych.
• Organy regulacyjne lub audytorzy potrzebują dowodów na to, co zostało przetestowane.
• Testy muszą przeprowadzić nowi lub zewnętrzni testerzy.
• Wyniki należy powtórzyć dokładnie, tak jak w zestawie regresji.
• Kroki staną się testami automatycznymi.

Większość dojrzałych zespołów używa obu. Sporządzają listę scenariuszy wszystkiego i piszą pełne przypadki tylko dla najwyższego ryzyka. Nie ma potrzeby dokumentowania każdego kroku na stronie ustawień niskiego ryzyka w taki sam sposób, jak przelew bankowy.

Scenariusze, przypadki i automatyzacja

Dobrze napisany przypadek testowy można niemal bezpośrednio powiązać z testem automatycznym. Warunki wstępne stają się konfiguracją, kroki stają się działaniami, a oczekiwany wynik staje się asercją. Ramy programistyczne oparte na zachowaniu używają nawet słowa „scenariusz” w odniesieniu do specyfikacji plików wykonywalnych:

Scenario: Reset rejects a short password
  Given I have opened a valid reset link
  When I submit the new password "abcd123"
  Then I see "Password must be at least 8 characters"
  And my password is unchanged

Co mylące, to, co BDD nazywa scenariuszem, jest znacznie bliższe przypadkowi testowemu, ponieważ zawiera określone dane i wyniki. To dobre przypomnienie, aby uzgodnić warunki. Aby zautomatyzować te kontrole, zapoznaj się z naszym samouczkiem Playwright lub samouczkiem pytest.

Co czyni je dobrymi

Typowe błędy

• Zapisuję tylko szczęśliwe ścieżki. Większość błędów występuje w warunkach błędu, więc uwzględnij to, co powinno zakończyć się niepowodzeniem.
• Korzystanie z niejasnych oczekiwanych wyników. „To powinno działać poprawnie” pozwala każdemu testerowi zdecydować o czymkolwiek.
• Dokładne dokumentowanie wszystkiego. Tysiące przypadków, których nikt nie prowadzi, są gorsze niż przydatny mały zestaw.
• Pomijanie scenariuszy. Przechodzenie od razu do spraw może spowodować, że całe obszary zostaną zapomniane.
• Pozwalanie na przedawnienie spraw. Kiedy produkt się zmienia, stare sprawy wprowadzają ludzi w błąd. Regularnie je przeglądaj.
• Wiązanie kroków z delikatnymi szczegółami. „Kliknij niebieski przycisk u góry” łamie wszelkie przeprojektowania.

Podsumowanie

Scenariusze zapewniają szeroki zakres, a przypadki testowe zapewniają głębię. Zacznij od scenariuszy następnej funkcji i przejrzyj je z programistą i właścicielem produktu. Następnie rozwiń tylko te ryzykowne w pełne przypadki. Luki znajdziesz wcześniej, a czas pisania spędzisz tam, gdzie się to liczy.

Najczęstsze pytania

Ucz się dalej