Definiowanie przypadków testowych i priorytetów

Zadbaj o dobrą organizację dzięki kolekcji Zapisuj i kategoryzuj treści zgodnie ze swoimi preferencjami.

Określ, co testować, zdefiniuj przypadki testowe i nadaj im priorytety.

Ramona Schwering

Z poprzedniego wpisu dowiesz się o strategiach testowania, liczbie testów potrzebnych do przetestowania aplikacji oraz o tym, jak znaleźć najlepsze rozwiązanie, aby uzyskać jak największą pewność co do wyników, mając na uwadze swoje zasoby. Daje nam to jednak tylko ogólne pojęcie, ile testować. Nadal musisz określić, co dokładnie chcesz przetestować. Te 3 kryteria mogą pomóc Ci zrozumieć, czego się spodziewać w testach oraz jaki typ testów i poziom szczegółowości może być najbardziej odpowiedni:

1. Zadbaj o ścieżkę sukcesu. Jest to najbardziej ogólna lub podstawowa ścieżka użytkownika w aplikacji, na której użytkownik bardzo szybko zauważy błąd.
2. Starannie wybierz poziom szczegółowości. Dowiedz się więcej, jeśli Twój przypadek użycia jest podatny na ataki lub jeśli błąd może spowodować poważne szkody.
3. Ustal priorytety testów na niższych poziomach, takich jak testy jednostkowe i testy integracji, a następnie, o ile to możliwe, testów kompleksowych na wyższych poziomach.

Z dalszej części tego artykułu dowiesz się, jak stosować te kryteria podczas definiowania przypadków testowych.

Co to jest przypadek testowy?

W rozwoju oprogramowania przypadek testowy to sekwencja działań lub okoliczności zaprojektowanych w celu potwierdzenia skuteczności programu lub aplikacji. Testowanie ma na celu zapewnienie, że oprogramowanie działa zgodnie z planem i że wszystkie jego funkcje działają prawidłowo. Testerzy oprogramowania lub programiści zwykle tworzą te przypadki testowe, aby zagwarantować, że oprogramowanie spełnia określone wymagania i specyfikacje.

Gdy test jest wykonywany, oprogramowanie przeprowadza serię kontroli, aby zapewnić pożądane wyniki. Podczas testowania:

• Weryfikacja. Proces dokładnego sprawdzania oprogramowania w celu zapewnienia jego prawidłowego działania. Kluczowe jest ustalenie, czy utworzony produkt spełnia wszystkie wymagania niefunkcjonalne i czy spełnia swoje zamierzone cele. Odpowiada ono na pytanie: „Czy prawidłowo tworzymy produkt?”.
• Weryfikacja. Proces zapewniający, że oprogramowanie jest zgodne z wymaganiami lub wymaganiami ogólnymi. Polega ono na sprawdzeniu, czy rzeczywisty produkt jest zgodny z oczekiwanym. Odpowiadamy na pytanie: „Czy tworzymy produkt odpowiedni do potrzeb użytkownika?”

Załóżmy, że program nie przynosi oczekiwanych rezultatów. W takim przypadku przypadek testowy będzie zawierać komunikat o nieudanym teście. Programista lub tester będzie musiał zbadać problem i znaleźć jego rozwiązanie. Pomyśl o sprawdzeniach i działaniach jako ścieżki, którymi podąża komputer, niezależnie od typu testowania. Grupy danych wejściowych lub warunków używanych do sprawdzania nazywane są „klasami równoważności”. Powinny one zachowywać się podobnie lub dawać podobne wyniki. Ścieżki wykonywane w ramach testu mogą się różnić, ale powinny odpowiadać czynnościom i oświadczeniu wykonanym w ramach testu.

Ścieżki testów: typowe rodzaje testów

W programowaniu przypadek testowy to scenariusz wykonania kodu, w którym oczekuje się określonego działania i sprawdza się, czy tak się dzieje. Zwykle istnieją 3 scenariusze, na podstawie których można tworzyć przypadki testowe.

Pierwszy z nich jest najbardziej znany i prawdopodobnie już go używasz. Jest to happy path, czyli „szczęśliwy scenariusz” lub „złota ścieżka”. Określa on najczęstsze zastosowanie funkcji, aplikacji lub zmiany – sposób, w jaki powinny one działać dla klienta.

Druga najważniejsza ścieżka testów, którą należy uwzględnić w przypadkach testowych, jest często pomijana, ponieważ jest niewygodna – jak sama nazwa wskazuje. Jest to „straszna ścieżka”, czyli inaczej test negatywny. Ta ścieżka dotyczy scenariuszy, które powodują nieprawidłowe działanie kodu lub przejście w stan błędu. Testowanie tych scenariuszy jest szczególnie ważne, jeśli masz przypadki użycia, które są bardzo podatne na ataki i stwarzają duże ryzyko dla zainteresowanych stron lub użytkowników.

Istnieją też inne ścieżki, o których warto wiedzieć i które warto rozważyć, ale są one zazwyczaj mniej popularne. W tabeli poniżej znajdziesz ich podsumowanie:

Istnieje kilka metod kategoryzowania tych ścieżek. Oto 2 najczęstsze podejścia:

• Podzielanie na partycje równoważne. Metoda testowania, która dzieli przypadki testowe na grupy lub partycje, a w efekcie pomaga tworzyć klasy równoważności. Zakładamy, że jeśli jeden przypadek testowy w particji wykrywa błąd, inne przypadki testowe w tej samej particji prawdopodobnie również wykażą podobne błędy. Wszystkie dane wejściowe w danej klasie równoważności powinny wykazywać identyczne zachowanie, więc możesz zmniejszyć liczbę przypadków testowych. Więcej informacji o partycjonowaniu równoważności
• Ogranicz analizę. Metoda testowania, zwana też analizą wartości granicznych, która sprawdza granice lub skrajne wartości danych wejściowych w celu znalezienia potencjalnych problemów lub błędów, które mogą wystąpić na granicach możliwości lub ograniczeń systemu.

Sprawdzona metoda: tworzenie przypadków testowych

Klasyczny przypadek testowy napisany przez testera zawiera konkretne dane, które pomogą Ci zrozumieć treść testu, który chcesz przeprowadzić, oraz oczywiście przeprowadzić sam test. Typowy tester dokumentuje swoje działania związane z testowaniem w tabeli. Na tym etapie możemy użyć 2 schematów, które pomogą nam uporządkować przypadki testowe, a później same testy:

• Uporządkuj, działaj, twierdzi. Schemat testowania „zaplanuj, wykonaj, zweryfikuj” (znany też jako „AAA” lub „Triple A”) to sposób na podzielenie testów na 3 odrębne etapy: planowanie testu, jego przeprowadzanie i w końcu wyciąganie wniosków.
• Zdarzenie, warunek, działanie. Ten wzorzec jest podobny do wzorca AAA, ale ma pewne korzenie w rozwoju opartego na zachowaniu.

W kolejnych artykułach omówimy te wzorce bardziej szczegółowo, gdy omówimy strukturę testu. Jeśli chcesz dowiedzieć się więcej o tych wzorach, przeczytaj te 2 artykuły: Arrange-Act-Assert: A pattern for writing good tests (Arrange-Act-Assert: wzór pisania dobrych testów) i Given-When-Then (Given-When-Then: wzór pisania dobrych testów).

Poniższa tabela podsumowuje klasyczny przykład, który uwzględnia wszystkie informacje z tego artykułu:

W przypadku testów automatycznych nie musisz dokumentować wszystkich przypadków testowych w sposób, w jaki robi to tester, choć z pewnością jest to przydatne. Jeśli się postarasz, wszystkie te informacje znajdziesz w testach. Przekształcmy teraz klasyczny przypadek testowy w test automatyczny.