Testowanie przypadków użycia z przykładami

Przez: Tomasza Hamiltona Tomasza Hamiltona
Hours Zaktualizowano

⚡ Inteligentne podsumowanie

Testowanie przypadków użycia (Use Case Testing) weryfikuje transakcje typu end-to-end poprzez badanie interakcji między aktorem a systemem. Technika ta napędza przypadki testowe na poziomie systemowym i akceptacyjnym, wykrywa luki integracyjne i uzupełnia kontrole na poziomie jednostki o realistyczne przepływy pracy użytkowników.

  • 🎭 Interakcje modeli są wyraźne: Oznacz każdy przepływ aktorem (A) i systemem (S), aby testerzy mogli tracna każdym etapie transakcji.
  • 🛤️ Najpierw odkryj szczęśliwą ścieżkę: Zweryfikuj główny scenariusz sukcesu, a następnie dodaj rozszerzenia i ścieżki wyjątków, które odzwierciedlają rzeczywiste błędy użytkowników.
  • 🧩 Anchor z warunkami: Połącz każdy krok z wyraźnymi warunkami wstępnymi i końcowymi, aby wynik testu był jednoznaczny.
  • 🔗 Trace do akceptacji: Przyporządkuj przypadki użycia do kryteriów akceptacji, aby interesariusze biznesowi mogli zatwierdzić pokrycie w momencie wydania.
  • 🤖 Użyj pomocy sztucznej inteligencji: Przekształcaj proste historie użytkowników w projekty przypadków użycia, przyspieszając projektowanie testów i redukując liczbę pominiętych przepływów.
Czytaj więcej

Testowanie przypadków użycia: przykład

Co to jest testowanie przypadków użycia?

Testowanie przypadków użycia To technika testowania oprogramowania, która identyfikuje przypadki testowe obejmujące cały system, transakcja po transakcji, od początku do końca. Przypadki testowe opisują interakcje między użytkownikami a aplikacją. Testowanie przypadków użycia ujawnia luki, które mogłyby nie zostać wykryte podczas testowania poszczególnych komponentów oprogramowania w izolacji.

A przypadek użycia W testowaniu to krótki opis konkretnego sposobu wykorzystania oprogramowania przez aktora lub użytkownika. Przypadki użycia są pisane na podstawie działań użytkownika i odpowiadających im reakcji aplikacji i są szeroko wykorzystywane do wyprowadzania… przypadki testowe na poziomie systemowym i akceptacyjnym.

Kluczowe elementy przypadku użycia

Każdy przypadek użycia jest zbudowany z tego samego zestawu bloków konstrukcyjnych. Znajomość poszczególnych elementów z góry ułatwia zaprojektowanie pokrycia, które dokładnie odpowiada przypadkom testowym:

  • Aktor: Użytkownik lub system zewnętrzny inicjujący interakcję. Reprezentowany jako „A” w przepływach tekstowych.
  • System: Oprogramowanie testowane, które reaguje na działanie aktora. Reprezentowane jako „S”.
  • Warunki wstępne: stan, w jakim musi znajdować się system, aby można było rozpocząć przypadek użycia.
  • Główny scenariusz sukcesu: sekwencja szczęśliwych kroków aktora i systemu.
  • Rozszerzenia / alternatywne przepływy: gałęzie obsługujące wyjątki, błędy walidacji lub alternatywne wybory.
  • Warunki końcowe: stan, w jakim system pozostaje po zakończeniu przypadku użycia.

Jak przeprowadzić testowanie przypadków użycia: przykład

W przypadku użycia aktor jest reprezentowany przez „A”, a system przez „S”. Poniższy przykład opisuje funkcjonalność logowania w aplikacji internetowej.

Testowanie przypadków użycia: przykład

Główny scenariusz sukcesu Krok OPIS
A: Aktor S: System 1 A: Wprowadź nazwę agenta i hasło
2 S: Sprawdź hasło
3 S: Zezwól na dostęp do konta
Rozszerzenia 2a Hasło jest nieprawidłowe   S: Wyświetl komunikat i poproś o ponowną próbę (do 4 razy)
2b Hasło nieprawidłowe 4 razy   S: Zamknij aplikację

Powyższy schemat opisuje jedną szczęśliwą ścieżkę i dwa rozszerzenia. Czytając go krok po kroku:

  • Pierwszym krokiem całego procesu logowania jest podanie przez aktora adresu e-mail i hasła.
  • System weryfikuje hasło.
  • Jeśli hasło jest prawidłowe, dostęp zostanie przyznany.
  • Jeśli hasło jest nieprawidłowe, system wyświetla komunikat i monituje o maksymalnie cztery ponowne próby wprowadzenia hasła.
  • Jeśli po czterech próbach podanie hasła pozostanie nieprawidłowe, system zablokuje dalsze próby (w tym przykładzie blokując adres IP).

Na podstawie tego przypadku użycia przetestowałbyś scenariusz powodzenia plus jeden przypadek dla każdego rozszerzenia. To daje co najmniej trzy przypadki testowe: prawidłowe logowanie, odzyskiwalne nieprawidłowe hasło i blokadę po wielokrotnych błędach.

POWIĄZANE ARTYKUŁY

Zalety testowania przypadków użycia

Testowanie przypadków użycia naturalnie wpisuje się w wymagania i przypadki testowe. Główne zalety to:

  • Kompleksowe pokrycie: testuje transakcje w obrębie modułów, a nie izolowanych funkcji.
  • Walidacja skoncentrowana na użytkowniku: każdy scenariusz odzwierciedla sposób, w jaki rzeczywisty aktor korzysta z systemu.
  • Usuń traczdolność: przypadki użycia są bezpośrednio odwzorowywane na kryteria akceptacji dla interesariuszy.
  • Zapobieganie wadom: ujawnia luki integracyjne przed rozpoczęciem cykli regresji.
  • Artefakty wielokrotnego użytku: ten sam przypadek użycia jest wykorzystywany w przypadkach testowych, materiałach szkoleniowych i dokumentacji użytkownika.

Ograniczenia testowania przypadków użycia

Ta technika jest skuteczna, ale nie wyczerpująca. Należy pamiętać o następujących ograniczeniach:

  • Nie zastępuje testów jednostkowych: usterki komponentów niskiego poziomu nadal wymagają ukierunkowanych testów.
  • Zależy od dokładnych przypadków użycia: niejednoznaczne przepływy powodują niejednoznaczne testy.
  • Ograniczone w przypadku pokrycia niefunkcjonalnego: wydajność, bezpieczeństwo i dostępność wymagają własnych technik.
  • Koszty utrzymania: przypadki użycia muszą być aktualizowane w miarę zmian reguł biznesowych.

FAQ

Przypadek użycia opisuje interakcję aktora i systemu w celu osiągnięcia celu. Przypadek testowy weryfikuje, czy system faktycznie zachowuje się w określony sposób. Jeden przypadek użycia zazwyczaj napędza wiele przypadków testowych.

Testowanie przypadków użycia najlepiej przeprowadzać na poziomie systemowym i akceptacyjnym, po testach jednostkowych i integracyjnych, gdy celem jest sprawdzenie kompletnych przepływów pracy użytkowników, a nie poszczególnych funkcji.

Aktor „A” reprezentuje użytkownika lub system zewnętrzny, który inicjuje interakcję. System „S” reprezentuje oprogramowanie reagujące na te działania. Taka notacja sprawia, że ​​przepływy są zwarte i czytelne.

Rozszerzenia to alternatywne przepływy, które obsługują wyjątki lub odgałęzienia od głównego scenariusza sukcesu. Opisują one reakcję systemu, gdy aktor wprowadza nieprawidłowe dane, porzuca krok lub podąża inną ścieżką decyzyjną.

Co najmniej jeden przypadek testowy potrzebny jest dla głównego scenariusza sukcesu oraz jeden dla każdego rozszerzenia. Warianty graniczne, równoważne i ujemne mogą wymagać więcej danych, w zależności od profilu ryzyka aplikacji.

Nie. Testowanie przypadków użycia weryfikuje znane przepływy pracy, podczas gdy testowanie eksploracyjne ujawnia nieznane defekty poprzez nieskryptowaną interakcję. Te dwie techniki wzajemnie się uzupełniają i obejmują różne kategorie ryzyka.

Asystenci AI przekształcają proste historie użytkowników w ustrukturyzowane przypadki użycia z aktorami, scenariuszami sukcesu i rozszerzeniami. Sygnalizują również brakujące alternatywne przepływy, porównując wersję roboczą z typowymi wzorcami.

Tak. Narzędzia AI odczytują przypadek użycia i generują wersje robocze przypadków testowych dla głównego przepływu i każdego rozszerzenia, wraz z przykładowymi danymi. Tester nadal weryfikuje dane wyjściowe, aby potwierdzić, czy reguły biznesowe i priorytety ryzyka są prawidłowe.

Podsumuj ten post następująco: