Jako testerzy oprogramowania i inżynierowie automatyzacji często myślimy o ścieżce pozytywnej: ścieżce, którą użytkownik najprawdopodobniej wybierze podczas korzystania z naszej aplikacji. Pisząc nasze zautomatyzowane testy interfejsu użytkownika, chcemy mieć pewność, że automatyzujemy te ścieżki pozytywne, a podczas pisania automatyzacji API chcemy zweryfikować, że każdy punkt końcowy zwraca „200 OK” lub podobną pomyślną odpowiedź.
Jednak ważne jest, aby uwzględniać testy negatywne zarówno w testach manualnych, jak i zautomatyzowanych. Oto kilka powodów.
Nasze zautomatyzowane testy mogą przechodzić z niewłaściwych powodów
Kiedy po raz pierwszy zacząłem pisać zautomatyzowane testy interfejsu użytkownika w JavaScript, nie rozumiałem pojęcia obietnicy. Zakładałem po prostu, że gdy wysyłam żądanie znalezienia elementu, nie zwróci ono tego elementu, dopóki nie zostanie on faktycznie znaleziony. Byłem bardzo podekscytowany, gdy moje testy zaczęły kończyć się zielonym wynikiem „Zaliczono”, aż współpracownik zasugerował, żebym spróbował doprowadzić do niepowodzenia testu, sprawdzając inną wartość. Test ponownie zakończył się pomyślnie, ponieważ w rzeczywistości sprawdzał istniejącą obietnicę, która zawsze zwracała „Prawda”. Nauczyło mnie to cennej lekcji: nigdy nie zakładaj, że twoje zautomatyzowane testy działają poprawnie tylko dlatego, że przechodzą pomyślnie. Pamiętaj, aby uruchamiać scenariusze, w których testy powinny zakończyć się niepowodzeniem, i upewniać się, że tak się dzieje. Dzięki temu możesz mieć pewność, że naprawdę testujesz to, co wydaje ci się, że testujesz.
Have an account? Log In
Testy negatywne mogą ujawnić niewłaściwie obsługiwane błędy, które mogą wpłynąć na użytkownika
W testowaniu API każdy błąd związany z klientem powinien skutkować odpowiedzią z poziomu 400, a nie serwerowym błędem z poziomu 500. Jeśli przeprowadzasz testy negatywne i odkrywasz, że zamiast odpowiedzi 403 pojawia się teraz odpowiedź 500, może to oznaczać, że kod nie obsługuje już prawidłowo tego przypadku użycia. Odpowiedź 500 z serwera może uniemożliwić użytkownikowi uzyskanie odpowiednich informacji potrzebnych do naprawienia błędu, a w najgorszym przypadku może doprowadzić do awarii aplikacji.
Testy negatywne mogą wykryć luki w zabezpieczeniach
Równie ważne jak upewnienie się, że użytkownik może zalogować się do aplikacji, jest sprawdzenie, czy użytkownik nie może zalogować się do aplikacji, gdy nie powinien mieć takiej możliwości. Jeśli przeprowadzasz test logowania wyłącznie z prawidłową nazwą użytkownika i hasłem, pomijasz ten kluczowy obszar! Spotkałem się z sytuacją, w której użytkownik mógł zalogować się, wpisując cokolwiek jako hasło, z sytuacją, w której użytkownik mógł zalogować się z pustym hasłem, oraz z sytuacją, w której użytkownik mógł zalogować się przy użyciu nieprawidłowej nazwy użytkownika i hasła.
Równie ważne jest zweryfikowanie, że określeni użytkownicy nie mają dostępu do części aplikacji. Starannie przetestowana i działająca strona administratora nie będzie miała większego znaczenia, jeśli okaże się, że może uzyskać do niej dostęp dowolny przypadkowy użytkownik.
Testy negatywne pomagają utrzymać bazę danych w czystości
Jak wspomniałem w rozdziale 12, posiadanie dobrych, prawidłowych danych w bazie danych pomoże utrzymać aplikację w dobrym stanie. Dane, które nie spełniają oczekiwań, mogą powodować awarie stron internetowych lub uniemożliwiać ich załadowanie, a także prowadzić do nieprawidłowego wyświetlania informacji. Im więcej testów negatywnych możesz przeprowadzić dla danych wejściowych, tym większą masz pewność, że będziesz mieć wyłącznie dobre dane.
W przypadku każdego pola wejściowego, za którego testowanie odpowiadam, chcę dokładnie wiedzieć, które znaki są dozwolone. Następnie mogę przeprowadzić całą serię testów negatywnych, aby upewnić się, że wpisy zawierające niedozwolone znaki są odrzucane.
More Articles
Czasami użytkownicy wybierają ścieżkę negatywną
Tak łatwo, szczególnie w przypadku nowej funkcji wdrażanej w pośpiechu, aby zdążyć przed terminem, zapomnieć o przetestowaniu ścieżek użytkownika, na których użytkownik klika przycisk Anuluj lub Usuń. Użytkownicy robią to jednak cały czas — wystarczy pomyśleć o sytuacjach, gdy rozważasz zakup online, a następnie zmieniasz zdanie i usuwasz produkt z koszyka. Wyobraź sobie swoją frustrację, gdyby nie można było usunąć czegoś z koszyka albo gdyby przycisk Anuluj nie czyścił formularza, aby umożliwić rozpoczęcie od nowa. Doświadczenie użytkownika w tym obszarze jest równie ważne jak ścieżka pozytywna.
Testowanie oprogramowania polega na szukaniu nieoczekiwanych zachowań, aby znaleźć je, zanim zrobi to użytkownik. Połączenie testowania negatywnego z testowaniem ścieżki pozytywnej pozwala nam upewnić się, że nasi użytkownicy nie doświadczą żadnych nieprzyjemnych niespodzianek.
Jeśli chcesz jeszcze bardziej zoptymalizować procesy testowania, rozważ integrację najwyższej klasy narzędzia do zarządzania bazą danych, które poradzi sobie ze złożonymi potrzebami związanymi z danymi.
Kompletna książka dla testerów oprogramowania
Kiedy w 2009 roku odkryłem swoją pasję do testowania oprogramowania, chciałem dowiedzieć się o nim wszystkiego, ale znalazłem bardzo niewiele książek, które mogłyby mnie tego nauczyć. Ostatecznie uczyłem się metodą prób i błędów, czytając wpisy na blogach i rozmawiając ze współpracownikami. Obecnie istnieją znakomite książki poświęcone konkretnym obszarom testowania oprogramowania, takim jak testowanie eksploracyjne, testowanie zwinne i automatyzacja testów, ale nie znam żadnej książki, która miałaby być kompletnym źródłem wiedzy o testowaniu.
Napisałem Kompletnego testera oprogramowania, ponieważ chciałem zapewnić zarówno początkującym, jak i doświadczonym testerom pomysły oraz narzędzia, których potrzebują, aby działać jak najskuteczniej. Aby otrzymywać szybkie wskazówki dotyczące kontroli jakości i więcej rekomendacji książkowych, zasubskrybuj biuletyn The QA Lead.
Powiązana lektura: CZYM JEST ZEPHYR SCALE?
Powiązana lista narzędzi:
- OPROGRAMOWANIE DO TESTÓW WYDAJNOŚCIOWYCH DLA ZESPOŁÓW QA
- NARZĘDZIA DO AUTOMATYZACJI TESTÓW ETL DLA ZESPOŁÓW QA
Warto również sprawdzić: