Definiowanie przypadków testowych i priorytetów

Ustal, co testować, zdefiniuj przypadki testowe i nadaj priorytet.

Ramona Schwering

W poprzednim poście omówiliśmy strategie testowania, liczbę testów niezbędnych do przetestowania aplikacji oraz sposoby znalezienia tego, który najlepiej sprawdzi się w celu uzyskania miarodajnych wyników przy jednoczesnym uwzględnieniu posiadanych zasobów. Daje nam to jednak tylko wyobrażenie o tym, ile testowania można przetestować. Musisz jeszcze dokładnie określić, co chcesz przetestować. Poniższe 3 kryteria mogą pomóc w zrozumieniu, czego można się spodziewać w teście, oraz określeniu, jaki typ i poziom szczegółowości testu będą dla niego najlepsze:

1. Zadbaj o swoją szczęśliwą drogę. Jest to najbardziej ogólna lub ogólna historia aplikacji, w której użytkownik bardzo szybko zauważy błąd.
2. Dobrze zastanów się nad poziomem szczegółowości. Dowiedz się więcej, jeśli Twój przypadek użycia jest podatny na ataki lub gdzie błąd może spowodować duże szkody.
3. W miarę możliwości stosuj w miarę możliwości testy niższego poziomu, takie jak testy jednostkowe i integracyjne, nad testami kompleksowymi.

W dalszej części tego artykułu opisujemy te kryteria i ich zastosowanie przy definiowaniu przypadków testowych.

Co to jest przypadek testowy?

W przypadku tworzenia oprogramowania przypadek testowy to sekwencja działań lub okoliczności, które mają na celu potwierdzenie skuteczności programu lub aplikacji. Celem testowania jest sprawdzenie, czy oprogramowanie działa zgodnie z planem oraz czy wszystkie jego funkcje i funkcje działają prawidłowo. Testerzy oprogramowania i deweloperzy zwykle tworzą takie przypadki testowe, aby zagwarantować, że oprogramowanie spełnia określone wymagania i specyfikacje.

Po uruchomieniu przypadku testowego oprogramowanie wykonuje serię testów, aby upewnić się, że przynosi oczekiwane wyniki. W tym czasie test wykonuje te zadania:

• Weryfikacja. Proces szczegółowego sprawdzania oprogramowania w celu zapewnienia, że działa bez błędów. Ważne jest, aby ustalić, czy utworzony produkt spełnia wszystkie niezbędne wymagania dotyczące niedziałających funkcji i czy spełnia swoje zamierzone przeznaczenie. Odpowiedź brzmi: „Czy dobrze budujemy tę usługę?”.
• Weryfikacja. Proces sprawdzania, czy oprogramowanie spełnia niezbędne standardy lub ogólne wymagania. Polega ona na sprawdzeniu, czy rzeczywisty produkt jest zgodny z oczekiwanym. Zasadniczo odpowiadamy na pytanie: „Czy tworzymy usługę odpowiednią do wymagań użytkownika?”.

Załóżmy, że program nie przynosi oczekiwanych wyników. W takim przypadku zgłoszeniem testowym jest komunikat o niepomyślnym wyniku testu, a programista lub tester musi zbadać problem i znaleźć rozwiązanie. Testy i działania są jak ścieżki, którymi podąża komputer, niezależnie od typu testu. Grupy danych wejściowych lub warunków używanych do sprawdzania są nazywane „klasami równoważności”. Powinny one uzyskać podobne działanie lub uzyskać podobne wyniki z testowanego systemu. Konkretne ścieżki wykonywane w teście mogą się różnić, ale powinny być zgodne z działaniami i asercjami wykonywanymi w teście.

Ścieżki testowe: typowe przypadki testowe

W przypadku programowania przypadek testowy to scenariusz wykonania kodu, w którym oczekiwane i testowane są określone zachowanie. Zwykle dostępne są 3 scenariusze tworzenia przypadków testowych.

Pierwszy jest najbardziej znany i prawdopodobnie już z niego korzystasz. Jest to ścieżka szczęśliwego dnia, znana również jako „scenariusz szczęśliwego dnia” lub „złota ścieżka”. Określa najczęstszy przypadek użycia funkcji, aplikacji lub zmiany, czyli sposób, w jaki powinna ona działać dla klienta.

Druga najważniejsza ścieżka testowa, którą należy wypróbować w przypadkach testowych, jest często pomijana, ponieważ jest niekomfortowa – co sugeruje jej nazwa. Jest to „straszna ścieżka” lub negatywny test. Ta ścieżka jest ukierunkowana na scenariusze, w których kod działa nieprawidłowo lub wyświetla się błąd. Testowanie tych scenariuszy jest szczególnie ważne, jeśli masz bardzo podatne na ataki przypadki użycia, które stwarzają wysokie ryzyko dla zainteresowanych osób lub użytkowników.

Istnieją też inne ścieżki, które warto znać i stosować, ale zwykle są one rzadziej używane. Ich podsumowanie znajdziesz w tej tabeli:

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

• Partycjonowanie równoważności. Metoda testowania, która kategoryzuje przypadki testowe na grupy lub partycje, dzięki czemu pomaga tworzyć klasy równoważności. Opiera się na założeniu, że jeśli jeden przypadek testowy na partycji wykryje defekt, inne przypadki testowe w tej samej partycji prawdopodobnie ujawnią podobne defekty. Wszystkie dane wejściowe w ramach określonej klasy 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
• Analiza limitów. Metoda testowania, zwana też analizą wartości granic, polega na badaniu granic lub wartości skrajnych wartości wejściowych pod kątem potencjalnych problemów lub błędów, które mogą się pojawić w granicach możliwości lub ograniczeń systemu.

Sprawdzona metoda: pisanie przypadków testowych

Klasyczny przypadek testowy napisany przez testera będzie zawierać konkretne dane, które pomogą Ci zrozumieć treść testu, który chcesz przeprowadzić, i oczywiście go przeprowadzić. Typowy tester dokumentuje swoje testy w tabeli. Na tym etapie możemy wykorzystać 2 wzorce ułatwiające opracowanie struktury przypadków testowych, a później także samych testów:

• Rozmieszczaj, działaj, zgłaszaj wzorce. Wzorzec testowania „organizuj, działaj, zgłaszaj” (nazywany również „AAA” lub „trójka A”) polega na połączeniu testów w 3 różne etapy: przeorganizowanie testu, następnie przeprowadzenie testu i wreszcie wyciąganie wniosków.
• Wzór na podstawie, kiedy, potem. Ten wzorzec jest podobny do wzorca AAA, ale ma pewne korzenie w programowaniu opartym na zachowaniach.

Kolejne artykuły zawierają więcej szczegółów na temat tych wzorców, gdy tylko omówimy strukturę testu. Jeśli chcesz dowiedzieć się więcej o tych wzorcach na tym etapie, zapoznaj się z tymi 2 artykułami: Arrange-Act-Assert: A pattern for using for what’s dobrych testów oraz Given-When-Następnie.

Zgodnie ze wszystkimi wnioskiami z tego artykułu podsumowujemy klasyczny przykład w tej tabeli:

W przypadku testów automatycznych nie musisz dokumentować wszystkich tych przypadków testowych w taki sposób, w jaki musi to robić tester, choć jest to bez wątpienia pomocne. Wszystkie te informacje znajdziesz w teście, jeśli będziesz uważnie się z nimi zapoznać. Przekształćmy ten klasyczny przypadek testowy w test automatyczny.