how classify positive
jak znaleźć domyślną maskę podsieci
Możesz zrobić coś w łatwy lub trudny sposób - ważne jest, abyś to zrobił. Jest kilka prostych rzeczy na co dzień, ale bez pewności siebie coś w nich nie pasuje do naszych umysłów, a zakres sukcesu jest strzałem w dziesiątkę.
Weźmy dziś jeden prosty przykład i znajdźmy skróty, które nie tylko wyjaśnią koncepcje, ale także zapewnią, że zawsze będzie to właściwe.
Pozytywna lub negatywna klasyfikacja scenariuszy / przypadków testowych
Proces projektowania testów jest 3-krotny:
- Zidentyfikuj wymagania
- Napisz scenariusze testów (jeden wiersz wskazujący, co testować)
- Zaprojektuj szczegółowe instrukcje testowania (przypadki testowe)
Pisząc scenariusze testowe, klasyfikujemy je na warunki pozytywne i negatywne. (Kiedy się nad tym zastanowić, czy naprawdę ważne jest dokonanie takiej klasyfikacji? Jeśli tak, czemu to służy? W każdym razie musimy je wszystkie przetestować, prawda?) To mnie też bije w większości. Ale myślę, że jest to próba ustalenia odpowiedniego zasięgu i pomaga ustalić, że testujemy zarówno szczęśliwą, jak i alternatywną ścieżkę, którą system ma obsługiwać. Prosimy o komentarz poniżej, jeśli znasz inne powody, dla których tak się dzieje.
Przyjrzyjmy się teraz kilku wymaganiom, napisz scenariusze testów i przeprowadź klasyfikację.
# 1) Zaloguj się :Użytkownik, który wprowadzi prawidłowe dane uwierzytelniające, dostaje się do systemu. Jeśli poświadczenia są niepoprawne, odmowa dostępu i wyświetlony komunikat o błędzie.
# 2) Wyświetl produkty: Załóżmy, że istnieje katalog online wszystkich produktów dostępnych w systemie i wyświetla je wszystkie na liście po kliknięciu linku „Wyświetl produkty”.
# 3) Wyloguj się: Kliknięcie tego linku powoduje wylogowanie użytkownika.
Mam zamiar napisać kilka scenariuszy testowych dla tych wymagań.
Tabela A:Właściwy sposób
| Identyfikator scenariusza testowego | Opis scenariusza testowego | Pozytywny Negatywny |
|---|---|---|
| TS_login_01 | Sprawdź, czy użytkownik loguje się pomyślnie, jeśli wprowadzone poświadczenia są poprawne | Pozytywny |
| TS_login_02 | Sprawdź, czy użytkownik nie ma dostępu, gdy wprowadzone poświadczenia są nieprawidłowe | Negatywny |
| TS_ViewProduct_01 | Sprawdź, czy wszystkie elementy są wymienione po kliknięciu łącza Wyświetl produkty | Pozytywny |
| TS_logout_01 | Sprawdź, czy już zalogowany użytkownik zostanie wylogowany z systemu po kliknięciu wylogowania | Pozytywny |
Jednak czasami widzę scenariusz testu napisany w ten sposób.
Tabela B: Wpisy zaznaczoneNettoto nieprawidłowe scenariusze testowe.
| Identyfikator scenariusza testowego | Opis scenariusza testowego | Pozytywny Negatywny |
|---|---|---|
| TS_login_01 | Sprawdź, czy użytkownik loguje się pomyślnie, jeśli wprowadzone poświadczenia są poprawne | Pozytywny |
| TS_login_02 | Sprawdź, czy użytkownik nie ma dostępu, gdy wprowadzone poświadczenia są nieprawidłowe | Negatywny |
| TS_ViewProduct_01 | Sprawdź, czy wszystkie elementy są wymienione po kliknięciu łącza Wyświetl produkty | Pozytywny |
| TS_ViewProduct_02 | Sprawdź, czy wszystkie elementy nie są wymienione po kliknięciu łącza Wyświetl produkty | Negatywny |
| TS_logout_01 | Sprawdź, czy już zalogowany użytkownik zostanie wylogowany z systemu po kliknięciu wylogowania | Pozytywny |
| TS_logout_02 | Sprawdź, czy użytkownik nie wylogowuje się po kliknięciu łącza wylogowania | Negatywny |
W przypadku pomyślnego logowania istnieje równy i przeciwny przypadek, w którym nie powiedzie się. Nie wszystkie wymagania mają takie być i dla nich naprawdę nie ma przymusu pisania negatywnego scenariusza.
Konkluzja: Nie każdy wymóg powinien mieć negatywne przypadki.
W tym momencie, jeśli myślisz „Skąd będę wiedzieć” lub „Nadal nie jestem pewien”, oto prosta ściągawka, która pomoże.
Jeśli istnieje jedno uogólnienie dotyczące aplikacji, to to, że są one dynamiczne. Dane wejściowe (dane, kliknięcia itp.), Które dostarczymy, spowodują, że aplikacja będzie działać w określony sposób i wygeneruje określony wynik.
Prosta korelacja między zmiennymi wejściowymi i wyjściowymi ułatwi to zrozumienie.
Spróbujmy się zalogować:
| Wejście | Wynik | Pozytywny Negatywny |
|---|---|---|
| Poprawne (poprawne dane logowania) | Prawidłowo (zalogowany użytkownik) | Pozytywny |
| Niepoprawne (nieprawidłowe dane logowania) | Prawidłowo (komunikat o błędzie) | Negatywny |
| Poprawne (poprawne dane logowania) | Niepoprawnie - logowanie nie powiodło się | Błąd / wada |
| Niepoprawne (nieprawidłowe dane logowania) | Niepoprawnie (system je loguje) - „O, zgroza!” :) | Błąd / wada |
Jak więc widzisz z powyższej tabeli, możemy powiedzieć, że kategoryzujemy przepływ pierwotny jako dodatni, a przepływ alternatywny (również prawidłowe zachowanie aplikacji) jest oznaczany jako ujemny.
Ostatnie dwa przypadki zaznaczone na czerwono to w rzeczywistości błędy. Testowanie polega na sprawdzaniu poprawności wymagań, a gdy nie działają one zgodnie z zamierzeniami, znajdujemy błędy. Ponieważ nie przeprowadzamy weryfikacji pod kątem wad, ostatnie dwa przypadki są nieważne.
Podążając za tym samym tokiem myślenia i stosując go do wylogowywania się i przeglądania produktów, oto, co otrzymasz.
| Wejście | Wynik | Pozytywny Negatywny |
|---|---|---|
| Wyloguj (kliknij) | Poprawnie - wylogowuje | Pozytywny |
| Wyloguj (kliknij) | Niepoprawnie - pozostaje zalogowany | Błąd / wada |
| Zobacz produkty (kliknij) | Prawidłowo - wyświetla produkty | Pozytywny |
| Zobacz produkty (kliknij) | Niepoprawne (brak listy lub nieprawidłowe wyświetlanie listy) | Błąd / wada |
Jak widać, w przypadku tych wymagań nie ma możliwości podania nieprawidłowych danych wejściowych. Dlatego nie trzeba pisać negatywnych scenariuszy / przypadków testowych.
Końcowe przemyślenia:
System może być poddawany dodatnim lub ujemnym wejściom. Tak czy inaczej, system powinien generować prawidłowe dane wyjściowe. Przypadki, w których zwykle występuje prawidłowy wkład, są pozytywne. Te, które dotyczą prawidłowego, ale ujemnego wkładu, są ujemne.
Kilka wskazówek:
# 1) Kiedy plik od końca do końca przypadków testowych są napisane pod kątem UAT lub nawet testów systemowych, zawsze trafiają do nich pozytywne przypadki testowe.
#dwa) Czasami klasyfikacja jest subiektywna.Na przykład, jeśli usuwam coś w witrynie i otrzymam wiadomość z potwierdzeniem z pytaniem „Czy na pewno chcesz usunąć ten wpis?” z opcjami OK i Anuluj - według mnie kliknięcie Anuluj jest przypadkiem pozytywnym. Ale niektórzy uważają, że jest to negatywne, ponieważ głównym celem opcji „Usuń” jest usunięcie, a nie anulowanie operacji. Tak więc ocena testera również odgrywa rolę w klasyfikacji.
# 3) Dla każdego pozytywnego przypadku nie zawsze istnieje równy i przeciwny przypadek negatywny.
Powyższa metoda zawsze gwarantuje prawidłową klasyfikację. Spróbuj sam i powiedz mi, jeśli nie. :) „Skrót jest często złym skrótem.” - Ale może tak nie być w tym przypadku!
Aby uzyskać bardziej formalne wyjaśnienie testu negatywnego, zaznacz => Co to jest testowanie negatywne i jak pisać negatywne przypadki testowe?
O autorze: Ten artykuł został napisany przez członka zespołu STH, Swati S. Dołącz do jej kursu szkoleniowego QA na żywo tutaj: Najlepsze szkolenie z testowania oprogramowania, jakie kiedykolwiek otrzymasz! '
Daj nam znać, jeśli podobał Ci się ten artykuł i chcesz, aby w kolejnych artykułach można było łatwo wyjaśnić takie podstawowe pojęcia.
Wasze komentarze, pytania, opinie i czytelnictwo są wysoko cenione i cenione w STH. Miłego testowania!
rekomendowane lektury
- Testowanie pozytywne: wyjaśnienie znaczenia i zalet prawdziwych scenariuszy testowych
- Jak pisać przypadki testowe dla strony logowania (przykładowe scenariusze)
- Co to jest testowanie negatywne i jak pisać negatywne przypadki testowe?
- Jak pisać przypadki testowe dla bankomatu (przykładowe scenariusze)
- Efektywne skrypty Selenium i scenariusze rozwiązywania problemów - samouczek Selenium nr 27
- Typy testów migracji: ze scenariuszami testów dla każdego typu
- Samouczek QTP nr 24 - Używanie obiektów wirtualnych i scenariuszy odzyskiwania w testach QTP
- Testowanie aplikacji opieki zdrowotnej - wskazówki i ważne scenariusze testowania (część 2)