180 web application testing example test cases
Przykładowe testy aplikacji internetowych: Jest to pełna lista kontrolna testowania aplikacji internetowych i komputerowych.
To jest bardzo obszerna lista przykładowych przypadków testowych / scenariuszy testowania aplikacji internetowych. Naszym celem jest udostępnienie jednej z najbardziej wszechstronnych list kontrolnych testów, jakie kiedykolwiek napisano, a to jeszcze nie zostało zrobione.
W przyszłości będziemy aktualizować ten post, dodając więcej przypadków testowych i scenariuszy. Jeśli nie masz czasu, aby go teraz przeczytać, podziel się tym ze znajomymi i dodaj do zakładek na później.
Utwórz listę kontrolną testów jako integralną część procesu pisania przypadków testowych. Korzystając z tej listy kontrolnej, możesz łatwo utworzyć setki plików Przypadki testowe do testowania aplikacji internetowych lub desktopowych.
Są to wszystkie ogólne przypadki testowe i powinny mieć zastosowanie do prawie wszystkich rodzajów aplikacji. Skorzystaj z tych testów, pisząc przypadki testowe dla swojego projektu, a jestem pewien, że omówisz większość typy testów z wyjątkiem reguł biznesowych specyficznych dla aplikacji podanych w dokumentach SRS.
Chociaż jest to typowa lista kontrolna, zalecam przygotowanie standardowej listy kontrolnej testów dostosowanej do Twoich konkretnych potrzeb przy użyciu poniższych przypadków testowych oprócz testów specyficznych dla aplikacji.
Zalecane narzędzie:
Przed przystąpieniem do pisania przypadków testowych zalecamy pobranie tego narzędzia do zarządzania przypadkami testowymi. Ułatwi to proces planowania testów i pisania przypadków testowych, o których mowa w tym samouczku.
=> Pobierz narzędzie do zarządzania przypadkami testowymi TestRail
Znaczenie korzystania z listy kontrolnej do testowania
# 1) Utrzymanie standardowego repozytorium przypadków testowych wielokrotnego użytku dla Twojej aplikacji zapewni szybsze wychwytywanie większości typowych błędów.
#dwa) Lista kontrolna pomaga szybko napisać przypadki testowe dla nowych wersji aplikacji.
# 3) Ponowne wykorzystanie przypadków testowych pomaga zaoszczędzić pieniądze na zasobach potrzebnych do pisania powtarzalnych testów.
# 4) Ważne przypadki testowe będą zawsze uwzględniane, dzięki czemu prawie nie da się o nich zapomnieć.
# 5) Programiści mogą skorzystać z listy kontrolnej testów, aby upewnić się, że najczęstsze problemy zostały rozwiązane w samej fazie rozwoju.
Uwagi:
- Wykonaj te scenariusze z różnymi rolami użytkowników, np. administrator, gość itp.
- W przypadku aplikacji internetowych te scenariusze należy przetestować na wielu przeglądarkach jak IE, FF, Chrome i Safari z wersjami zatwierdzonymi przez klienta.
- Testuj z różnymi rozdzielczościami ekranu, takimi jak 1024 x 768, 1280 x 1024 itd.
- Aplikację należy przetestować na różnych wyświetlaczach, takich jak LCD, CRT, notebooki, tablety i telefony komórkowe.
- Testuj aplikację na różnych platformach, takich jak systemy operacyjne Windows, Mac, Linux itp.
Czego się nauczysz:
- Ponad 180 przykładowych przypadków testowych aplikacji internetowych
- Ponad 100 gotowych do wykonania przypadków testowych (listy kontrolne)
- Pełna lista kontrolna (przypadki testowe) dla większości elementów AUT
- Lista kontrolna nr 1: Lista kontrolna testowania urządzeń mobilnych
- Lista kontrolna nr 2: Lista kontrolna testowania formularzy / ekranów
- Lista kontrolna nr 3: Lista kontrolna testowania pola tekstowego
- Lista kontrolna nr 4: Lista kontrolna lub lista rozwijana Lista kontrolna testowania
- Lista kontrolna nr 5: Lista kontrolna pól wyboru w terenie
- Lista kontrolna nr 6: Lista kontrolna testowania przycisków radiowych
- Lista kontrolna nr 7: Scenariusze testów terenowych z datą
- Lista kontrolna nr 8: Zapisz scenariusze testowania przycisków
- Lista kontrolna nr 9: Anuluj scenariusze testu przycisku
- Lista kontrolna nr 10: Usuń punkty testowe przycisku
- Lista kontrolna nr 11: weryfikacja obszarów dotkniętych problemem po zapisaniu lub aktualizacji
- Lista kontrolna nr 12: Lista testowania sieci danych
- rekomendowane lektury
- Pełna lista kontrolna (przypadki testowe) dla większości elementów AUT
Ponad 180 przykładowych przypadków testowych aplikacji internetowych
Założenia: Załóżmy, że Twoja aplikacja obsługuje następujące funkcje
- Formularze z różnymi polami
- Okna podrzędne
- Aplikacja współdziała z bazą danych
- Różne kryteria filtrów wyszukiwania i wyświetlanie wyników
- Przesyłanie obrazu
- Funkcja wysyłania wiadomości e-mail
- Funkcja eksportu danych
Ogólne scenariusze testów
1. Wszystkie pola obowiązkowe należy zatwierdzić i oznaczyć symbolem gwiazdki (*).
2. Komunikaty o błędach walidacji powinny być wyświetlane poprawnie w prawidłowej pozycji.
3. Wszystkie komunikaty o błędach powinny być wyświetlane w tym samym stylu CSS ( Na przykład, używając koloru czerwonego)
4. Ogólne komunikaty potwierdzające powinny być wyświetlane w stylu CSS innym niż styl komunikatów o błędach ( Na przykład, używając koloru zielonego)
5. Tekst podpowiedzi powinien być zrozumiały.
6. W rozwijanych polach pierwszy wpis powinien być pusty lub zawierać tekst typu „Wybierz”.
7. „Funkcja usuwania” dowolnego rekordu na stronie powinna prosić o potwierdzenie.
8. Opcja Zaznacz / odznacz wszystkie rekordy powinna być dostępna, jeśli strona obsługuje funkcję dodawania / usuwania / aktualizowania rekordów
9. Wartości kwot powinny być wyświetlane z poprawnymi symbolami waluty.
10. Należy zapewnić domyślne sortowanie stron.
11. Funkcjonalność przycisku resetowania powinna ustawić wartości domyślne dla wszystkich pól.
12. Wszystkie wartości liczbowe powinny być poprawnie sformatowane.
13. Pola wejściowe należy sprawdzić pod kątem maksymalnej wartości pola. Wartości wejściowe większe niż określony maksymalny limit nie powinny być akceptowane ani przechowywane w bazie danych.
14. Sprawdź wszystkie pola wejściowe pod kątem znaków specjalnych.
15. Etykiety pól powinny być standardowe, np. pole akceptujące imię użytkownika powinno być odpowiednio oznaczone jako „Imię”.
16. Sprawdź funkcjonalność sortowania stron po operacjach dodawania / edycji / usuwania dowolnego rekordu.
17. Sprawdź funkcjonalność limitu czasu. Wartości limitów czasu powinny być konfigurowalne. Sprawdź zachowanie aplikacji po przekroczeniu limitu czasu operacji.
18. Sprawdź pliki cookie używane w aplikacji.
19. Sprawdź, czy pliki do pobrania wskazują prawidłowe ścieżki plików.
20. Wszystkie klucze zasobów powinny być konfigurowalne w plikach konfiguracyjnych lub w bazie danych zamiast na sztywnym kodowaniu.
21. Podczas nazewnictwa kluczy zasobów należy przestrzegać standardowych konwencji.
22. Sprawdź poprawność znaczników dla wszystkich stron internetowych (sprawdź poprawność HTML i CSS pod kątem błędów składniowych), aby upewnić się, że są zgodne ze standardami.
23. Awaria aplikacji lub niedostępne strony powinny zostać przekierowane na stronę błędu.
24. Sprawdź tekst na wszystkich stronach pod kątem błędów ortograficznych i gramatycznych.
25. Sprawdź numeryczne pola wejściowe z wartościami wprowadzania znaków. Powinien pojawić się odpowiedni komunikat walidacji.
26. Sprawdź liczby ujemne, jeśli jest to dozwolone w przypadku pól numerycznych.
27. Sprawdź liczbę pól z dziesiętnymi wartościami liczbowymi.
28. Sprawdź funkcjonalność przycisków dostępnych na wszystkich stronach.
29. Użytkownik nie powinien mieć możliwości dwukrotnego przesłania strony przez szybkie naciśnięcie przycisku przesyłania.
30. W obliczeniach należy uwzględnić błędy dzielenia przez zero.
31. Dane wejściowe z pustą pierwszą i ostatnią pozycją powinny być obsługiwane poprawnie.
pytania i odpowiedzi do wywiadu w bazie danych oracle
Scenariusze testów GUI i testów użyteczności
1. Wszystkie pola na stronie ( Na przykład, pole tekstowe, opcje radiowe, listy rozwijane) powinny być odpowiednio wyrównane.
2. Wartości liczbowe powinny być poprawnie uzasadnione, chyba że określono inaczej.
3. Między etykietami pól, kolumnami, wierszami, komunikatami o błędach itp. Należy zapewnić wystarczającą ilość miejsca.
4. Pasek przewijania powinien być włączony tylko wtedy, gdy jest to konieczne.
5. Rozmiar, styl i kolor czcionki dla nagłówka, tekstu opisu, etykiet, danych pola wewnętrznego i informacji o siatce powinny być standardowe, jak określono w SRS.
6. Pole tekstowe opisu powinno być wieloliniowe.
7. Wyłączone pola powinny być wyszarzone, a użytkownicy nie powinni mieć możliwości ustawienia fokusu na tych polach.
8. Po kliknięciu pola tekstu wejściowego wskaźnik myszy powinien zmienić się w kursor.
9. Użytkownik nie powinien mieć możliwości wpisywania rozwijanych list wyboru.
10. Informacje wypełniane przez użytkowników powinny pozostać nienaruszone, gdy pojawia się komunikat o błędzie podczas przesyłania strony. Użytkownik powinien mieć możliwość ponownego przesłania formularza poprzez poprawienie błędów.
11. Sprawdź, czy w komunikatach o błędach zastosowano właściwe etykiety pól.
12. Wartości pól rozwijanych powinny być wyświetlane w określonej kolejności sortowania.
13. Kolejność Tab i Shift + Tab powinny działać poprawnie.
14. Domyślne opcje radiowe powinny być wstępnie wybrane podczas ładowania strony.
15. Powinny być dostępne komunikaty pomocy dla poszczególnych pól i na poziomie strony.
16. Sprawdź, czy w przypadku błędów podświetlone są prawidłowe pola.
17. Sprawdź, czy opcje listy rozwijanej są czytelne i nie są obcięte z powodu ograniczeń rozmiaru pól.
18. Wszystkie przyciski na stronie powinny być dostępne za pomocą skrótów klawiaturowych, a użytkownik powinien mieć możliwość wykonywania wszystkich operacji za pomocą klawiatury.
19. Sprawdź wszystkie strony pod kątem uszkodzonych obrazów.
20. Sprawdź wszystkie strony pod kątem niedziałających łączy.
21. Wszystkie strony powinny mieć tytuł.
22. Komunikaty potwierdzające powinny zostać wyświetlone przed wykonaniem jakiejkolwiek operacji aktualizacji lub usunięcia.
23. Klepsydra powinna być wyświetlana, gdy aplikacja jest zajęta.
24. Tekst strony powinien być wyrównany do lewej.
25. Użytkownik powinien mieć możliwość wybrania tylko jednej opcji radia i dowolnej kombinacji pól wyboru.
Scenariusze testowe dla kryteriów filtrowania
1. Użytkownik powinien mieć możliwość filtrowania wyników przy użyciu wszystkich parametrów na stronie.
2. Funkcja zawężania wyszukiwania powinna załadować stronę wyszukiwania ze wszystkimi parametrami wyszukiwania wybranymi przez użytkownika.
3. Jeśli do wykonania operacji wyszukiwania wymagane jest co najmniej jedno kryterium filtrowania, upewnij się, że wyświetlany jest właściwy komunikat o błędzie, gdy użytkownik przesyła stronę bez wybierania kryteriów filtrowania.
4. Gdy wybór przynajmniej jednego kryterium filtru nie jest obowiązkowy, użytkownik powinien mieć możliwość przesłania strony, a do wyszukiwania wyników powinien przyzwyczaić się do domyślnych kryteriów wyszukiwania.
5. Odpowiednie komunikaty walidacji powinny być wyświetlane dla wszystkich nieprawidłowych wartości kryteriów filtru.
Scenariusze testowe dla siatki wyników
1. Symbol ładowania strony powinien być wyświetlany, gdy ładowanie strony wyników trwa dłużej niż domyślny.
2. Sprawdź, czy wszystkie parametry wyszukiwania są używane do pobierania danych wyświetlanych w tabeli wyników.
3. Całkowita liczba wyników powinna zostać wyświetlona w siatce wyników.
4. Kryteria wyszukiwania użyte do wyszukiwania powinny być wyświetlone w siatce wyników.
5. Wartości siatki wyników powinny być sortowane według domyślnej kolumny.
6. Posortowane kolumny powinny być wyświetlone z ikoną sortowania.
7. Siatki wyników powinny zawierać wszystkie określone kolumny z poprawnymi wartościami.
8. Funkcjonalność sortowania rosnąco i malejąco powinna działać dla kolumn obsługiwanych przez sortowanie danych.
9. Siatki wyników powinny być wyświetlane z odpowiednimi odstępami między kolumnami i wierszami.
10. Paginację należy włączyć, gdy wyników jest więcej niż domyślna liczba wyników na stronie.
11. Sprawdź funkcjonalność paginacji na następną, poprzednią, pierwszą i ostatnią stronę.
12. Zduplikowane rekordy nie powinny być wyświetlane w tabeli wyników.
13. Sprawdź, czy wszystkie kolumny są widoczne i, jeśli to konieczne, włączony jest poziomy pasek przewijania.
14. Sprawdź dane pod kątem kolumn dynamicznych (kolumn, których wartości są obliczane dynamicznie na podstawie wartości innych kolumn).
15. W przypadku siatek wyników przedstawiających raporty zaznacz wiersz „Sumy” i sprawdź sumę dla każdej kolumny.
16. W przypadku siatek wyników wyświetlających raporty zaznacz dane wiersza „Sumy”, gdy włączone jest paginacja, a użytkownik przechodzi do następnej strony.
17. Sprawdź, czy zastosowano odpowiednie symbole do wyświetlania wartości kolumn, np. Symbol% powinien być wyświetlany przy obliczaniu procentu.
18. Sprawdź dane siatki wyników, aby dowiedzieć się, czy zakres dat jest włączony.
Scenariusze testowe dla okna
1. Sprawdź, czy domyślny rozmiar okna jest prawidłowy.
2. Sprawdź, czy rozmiar okna podrzędnego jest prawidłowy.
3. Sprawdź, czy na stronie jest jakieś pole z domyślnym fokusem (ogólnie fokus powinien być ustawiony na pierwszym polu wejściowym ekranu).
4. Sprawdź, czy okna potomne są zamykane przy zamykaniu okna nadrzędnego / otwierającego.
5. Jeśli okno potomne jest otwarte, użytkownik nie powinien mieć możliwości używania ani aktualizowania żadnego pola w tle lub oknie nadrzędnym
6. Sprawdź minimalizowanie, maksymalizowanie i zamykanie funkcji okna.
7. Sprawdź, czy okno można zmienić.
8. Sprawdź funkcjonalność paska przewijania dla okien nadrzędnych i podrzędnych.
9. Sprawdź funkcjonalność przycisku anulowania dla okna potomnego.
Scenariusze testowania baz danych
1. Sprawdź, czy prawidłowe dane są zapisywane w bazie danych po pomyślnym przesłaniu strony.
2. Sprawdź wartości kolumn, które nie akceptują wartości null.
3. Sprawdź integralność danych. Dane powinny być przechowywane w jednej lub wielu tabelach w zależności od projektu.
4. Nazwy indeksów należy podawać zgodnie z normami np. IND__
5. Tabele powinny mieć kolumnę klucza podstawowego.
6. Kolumny tabeli powinny mieć dostępne informacje opisowe (z wyjątkiem kolumn audytowych, takich jak data utworzenia, utworzona przez itp.)
7. Do każdej bazy danych należy dodać dziennik operacji dodawania / aktualizacji.
8. Należy utworzyć wymagane indeksy tabel.
9. Sprawdź, czy dane zostały zatwierdzone w bazie danych dopiero po pomyślnym zakończeniu operacji.
10. Dane powinny zostać wycofane w przypadku nieudanych transakcji.
11. Nazwę bazy danych należy podać zgodnie z typem aplikacji tj. Test, UAT, sandbox, live (choć nie jest to standard, jest pomocny w utrzymaniu bazy danych)
12. Nazwy logiczne bazy danych należy podawać zgodnie z nazwą bazy danych (ponownie nie jest to standardowe, ale pomocne przy utrzymaniu bazy danych).
13. Procedur składowanych nie należy nazywać przedrostkiem „sp_”
14. Sprawdź, czy wartości w kolumnach inspekcji tabeli (takie jak data utworzenia, utworzenie, aktualizacja, aktualizacja, jest usunięte, usunięte dane, usunięte przez itp.) Są prawidłowo wypełnione.
15. Sprawdź, czy dane wejściowe nie są obcinane podczas zapisywania. Długość pola wyświetlana użytkownikowi na stronie iw schemacie bazy danych powinna być taka sama.
16. Sprawdź pola numeryczne z wartościami minimalnymi, maksymalnymi i zmiennoprzecinkowymi.
17. Sprawdź pola liczbowe z wartościami ujemnymi (zarówno dla akceptacji, jak i braku akceptacji).
18. Sprawdź, czy przycisk radiowy i opcje listy rozwijanej są poprawnie zapisane w bazie danych.
19. Sprawdź, czy pola bazy danych są zaprojektowane z poprawnym typem i długością danych.
20. Sprawdź, czy wszystkie ograniczenia tabeli, takie jak klucz podstawowy, klucz obcy itp., Są poprawnie zaimplementowane.
21. Przetestuj procedury składowane i wyzwalacze za pomocą przykładowych danych wejściowych.
22. Przed wprowadzeniem danych do bazy danych należy obciąć początkowe i końcowe spacje pola wejściowego.
23. Wartości puste nie powinny być dozwolone w kolumnie Klucz podstawowy.
Scenariusze testowania funkcji przesyłania obrazów
(Dotyczy również innych funkcji przesyłania plików)
1. Sprawdź przesłaną ścieżkę obrazu.
2. Sprawdź przesyłanie obrazu i zmień funkcjonalność.
3. Sprawdź funkcję przesyłania obrazów z plikami graficznymi o różnych rozszerzeniach ( Na przykład, JPEG, PNG, BMP itp.)
4. Sprawdź, czy w nazwie pliku jest dostępna spacja lub jakikolwiek inny dozwolony znak specjalny.
5. Sprawdź przesyłanie zduplikowanych nazwisk.
6. Sprawdź przesyłane obrazy o rozmiarze większym niż maksymalny dozwolony rozmiar. Powinien zostać wyświetlony odpowiedni komunikat o błędzie.
7. Sprawdź funkcję przesyłania obrazów z typami plików innymi niż obrazy ( Na przykład, txt, doc, pdf, exe itp.). Powinien zostać wyświetlony odpowiedni komunikat o błędzie.
8. Sprawdź, czy obrazy o określonej wysokości i szerokości (jeśli zdefiniowano) są akceptowane, w przeciwnym razie odrzucane.
9. W przypadku obrazów o dużym rozmiarze powinien pojawić się pasek postępu ładowania obrazu.
10. Sprawdź, czy funkcja przycisku anulowania działa pomiędzy procesem przesyłania.
11. Sprawdź, czy w oknie dialogowym wyboru plików są wyświetlane tylko obsługiwane pliki.
12. Sprawdź funkcję przesyłania wielu obrazów.
13. Sprawdź jakość obrazu po przesłaniu. Jakość obrazu nie powinna być zmieniana po przesłaniu.
14. Sprawdź, czy użytkownik może korzystać / przeglądać przesłane obrazy.
Scenariusze testowe do wysyłania wiadomości e-mail
(Przypadki testowe do tworzenia lub sprawdzania poprawności wiadomości e-mail nie są tutaj uwzględnione)
(Upewnij się, że używasz fikcyjnych adresów e-mail przed wykonaniem testów związanych z pocztą elektroniczną)
1. Szablon wiadomości e-mail powinien używać standardowego CSS dla wszystkich wiadomości e-mail.
2. Adresy e-mail należy zweryfikować przed wysłaniem wiadomości e-mail.
3. Znaki specjalne w szablonie treści wiadomości e-mail powinny być obsługiwane prawidłowo.
4. Znaki specyficzne dla języka ( Na przykład, Znaki języka rosyjskiego, chińskiego lub niemieckiego) powinny być odpowiednio obsługiwane w szablonie treści wiadomości e-mail.
5. Temat wiadomości e-mail nie powinien być pusty.
6. Pola zastępcze użyte w szablonie wiadomości e-mail należy zastąpić rzeczywistymi wartościami np. {Imię} {Nazwisko} powinno być zastąpione imieniem i nazwiskiem danej osoby we wszystkich adresatach.
7. Jeśli raporty z wartościami dynamicznymi są zawarte w treści wiadomości e-mail i dane raportu powinny być obliczone poprawnie.
8. Nazwa nadawcy wiadomości e-mail nie powinna być pusta.
9. E-maile powinny być sprawdzane w różnych klientach poczty e-mail, takich jak Outlook, Gmail, Hotmail, Yahoo! poczta itp.
10. Zaznacz, aby wysłać funkcję e-mail przy użyciu pól DO, DW i UDW.
11. Sprawdź wiadomości e-mail zawierające zwykły tekst.
12. Sprawdź wiadomości e-mail w formacie HTML.
13. Sprawdź nagłówek i stopkę wiadomości e-mail pod kątem logo firmy, polityki prywatności i innych linków.
14. Sprawdź e-maile z załącznikami.
15. Zaznacz, aby wysyłać funkcje e-mail do jednego, wielu odbiorców lub odbiorców z listy dystrybucyjnej.
16. Sprawdź, czy odpowiedź na adres email jest poprawna.
17. Zaznacz, aby wysyłać dużą liczbę wiadomości e-mail.
Scenariusze testowe funkcji eksportu programu Excel
1. Plik powinien zostać wyeksportowany z odpowiednim rozszerzeniem.
2. Nazwa pliku dla eksportowanego pliku Excel powinna być zgodna ze standardami, Na przykład, jeśli nazwa pliku używa sygnatury czasowej, powinna zostać poprawnie zastąpiona faktyczną sygnaturą czasową w momencie eksportowania pliku.
3. Sprawdź format daty, jeśli wyeksportowany plik Excel zawiera kolumny z datami.
4. Sprawdź formatowanie liczb dla wartości liczbowych lub walutowych. Formatowanie powinno być takie samo, jak pokazano na stronie.
5. Eksportowany plik powinien mieć kolumny z odpowiednimi nazwami kolumn.
6. Domyślne sortowanie stron powinno być również przeprowadzone w eksportowanym pliku.
7. Dane w pliku Excel powinny być odpowiednio sformatowane z tekstem nagłówka i stopki, datą, numerami stron itp. Wartościami dla wszystkich stron.
8. Sprawdź, czy dane wyświetlane na stronie i wyeksportowany plik Excel są takie same.
9. Sprawdź funkcję eksportu, gdy włączone jest paginacja.
10. Sprawdź, czy przycisk eksportu wyświetla odpowiednią ikonę zgodnie z typem eksportowanego pliku, Na przykład, Ikona pliku Excel dla plików xls
11. Sprawdź funkcję eksportu dla plików o bardzo dużych rozmiarach.
12. Sprawdź funkcję eksportu dla stron zawierających znaki specjalne. Sprawdź, czy te znaki specjalne są poprawnie eksportowane w pliku Excel.
Scenariusze testów wydajnościowych
1. Sprawdź, czy czas ładowania strony mieści się w dopuszczalnym zakresie.
2. Sprawdź ładowanie strony przy wolnych połączeniach.
3. Sprawdź czas reakcji na jakąkolwiek akcję w warunkach lekkiego, normalnego, umiarkowanego i dużego obciążenia.
4. Sprawdź wydajność procedur przechowywanych w bazie danych i wyzwalaczy.
5. Sprawdź czas wykonania zapytania do bazy danych.
6. Sprawdź testy obciążeniowe aplikacji.
7. Sprawdź aplikację pod kątem testów warunków skrajnych.
8. Sprawdź użycie procesora i pamięci w warunkach szczytowego obciążenia.
Scenariusze testów bezpieczeństwa
1. Sprawdź, czy nie ma ataków typu SQL injection.
2. Bezpieczne strony powinny używać protokołu HTTPS.
3. Awaria strony nie powinna ujawniać informacji o aplikacji ani serwerze. W tym celu powinna zostać wyświetlona strona błędu.
4. Unikaj znaków specjalnych w wejściu.
5. Komunikaty o błędach nie powinny ujawniać żadnych poufnych informacji.
6. Wszystkie poświadczenia powinny być przesyłane zaszyfrowanym kanałem.
7. Przetestuj ochronę haseł i egzekwowanie zasad haseł.
8. Sprawdź funkcję wylogowania z aplikacji.
9. Sprawdź ataki Brute Force.
10. Informacje o plikach cookie powinny być przechowywane wyłącznie w formacie zaszyfrowanym.
11. Sprawdź czas trwania sesji cookie i zakończenie sesji po przekroczeniu limitu czasu lub wylogowaniu.
11. Tokeny sesji powinny być przesyłane zabezpieczonym kanałem.
13. Hasło nie powinno być przechowywane w plikach cookies.
14. Test na ataki Denial of Service.
15. Sprawdź wyciek pamięci.
16. Przetestuj nieautoryzowany dostęp do aplikacji, manipulując wartościami zmiennych w pasku adresu przeglądarki.
17. Przetestuj obsługę rozszerzeń plików, aby pliki exe nie były przesyłane i uruchamiane na serwerze.
18. Wrażliwe pola, takie jak hasła i informacje o karcie kredytowej, nie powinny mieć włączonej funkcji autouzupełniania.
19. Funkcjonalność wysyłania plików powinna wykorzystywać ograniczenia dotyczące typów plików, a także oprogramowanie antywirusowe do skanowania przesyłanych plików.
20. Sprawdź, czy lista katalogów jest zabroniona.
21. Hasła i inne wrażliwe pola powinny być maskowane podczas wpisywania.
22. Sprawdź, czy funkcja „Zapomniałem hasła” jest zabezpieczona takimi funkcjami, jak tymczasowe wygaśnięcie hasła po określonych godzinach i pytanie zabezpieczające jest zadawane przed zmianą lub żądaniem nowego hasła.
23. Sprawdź funkcjonalność CAPTCHA.
24. Sprawdź, czy ważne zdarzenia są rejestrowane w plikach dziennika.
25. Sprawdź, czy uprawnienia dostępu są poprawnie zaimplementowane.
Testowanie penetracyjne przypadków testowych - Wymieniłem około 41 przypadków testowych do testów penetracyjnych ta strona .
Naprawdę chciałbym podziękować Devanshu lavaniya (Starszy inżynier ds. Kontroli jakości pracujący dla I-link Infosoft) za pomoc w przygotowaniu tej obszernej listy kontrolnej testów.
Próbowałem omówić prawie wszystkie standardowe scenariusze testowe dotyczące funkcji aplikacji internetowych i komputerowych. Mimo to wiem, że nie jest to pełna lista kontrolna. Testerzy w różnych projektach mają własne listy kontrolne testów oparte na ich doświadczeniu.
Zaktualizowano:
Ponad 100 gotowych do wykonania przypadków testowych (listy kontrolne)
Możesz użyć tej listy, aby przetestować najpopularniejsze składniki AUT
Jak za każdym razem skutecznie przetestować najpopularniejsze komponenty Twojego AUT?
Ten artykuł jest listą typowych walidacji dotyczących najczęściej spotykanych elementów AUT - zestawionych dla wygody testerów (szczególnie w środowisku zwinnym, w którym często pojawiają się krótkoterminowe wydania).
Każdy AUT (testowana aplikacja) jest wyjątkowy i ma bardzo konkretny cel biznesowy. Poszczególne aspekty (moduły) AUT obejmują różne operacje / działania, które są kluczowe dla sukcesu firmy, którą wspiera AUT.
Chociaż każdy AUT jest zaprojektowany inaczej, poszczególne komponenty / pola, które napotykamy na większości stron / ekranów / aplikacji, są takie same i mają mniej więcej podobne zachowanie.
Niektóre typowe składniki AUT:
- Zapisz, Aktualizuj, Usuń, Resetuj, Anuluj, OK - linki / przyciski - których funkcjonalnością jest etykieta obiektu.
- Pole tekstowe, listy rozwijane, pola wyboru, przyciski opcji, pola kontroli daty - które za każdym razem działają w ten sam sposób.
- Siatki danych, obszary dotknięte itp. W celu ułatwienia sporządzania raportów.
Sposób, w jaki te poszczególne elementy wpływają na ogólną funkcjonalność aplikacji, może być różny, ale kroki ich walidacji są zawsze takie same.
Kontynuujmy listę najczęściej używanych walidacji dla Aplikacja internetowa lub komputerowa strony / formularze.
Uwaga : Rzeczywisty wynik, oczekiwany wynik, dane testowe i inne parametry, które zazwyczaj są częścią przypadku testowego, są pomijane ze względu na prostotę - Stosuje się podejście oparte na ogólnej liście kontrolnej.
najlepszy downloader mp3 dla Androida bez reklam
Cel tej obszernej listy kontrolnej:
Podstawowym celem tych list kontrolnych (lub przypadków testowych) jest zapewnienie maksymalnego pokrycia testów na walidacji na poziomie pola bez poświęcania zbyt wiele czasu, jednocześnie nie obniżając jakości ich testowania.
W końcu zaufanie do produktu można osiągnąć tylko poprzez przetestowanie każdego elementu w możliwie najlepszym zakresie.
Pełna lista kontrolna (przypadki testowe) dla większości elementów AUT
Uwaga:Możesz korzystać z tych list kontrolnych w formacie Microsoft Excel (do pobrania na końcu artykułu). Możesz nawet śledzić wykonanie testu w tym samym pliku z wynikami pozytywnymi / negatywnymi i statusem.
Może to być wszechstronne źródło informacji dla zespołów ds. Kontroli jakości, umożliwiające testowanie i śledzenie najpopularniejszych elementów AUT.Możesz dodawać lub aktualizować przypadki testowe specyficzne dla Twojej aplikacjii uczyń z niej jeszcze bardziej obszerną listę.
Lista kontrolna nr 1: Lista kontrolna testowania urządzeń mobilnych
Nazwa modułu: |
Funkcjonalność modułu: |
Wpływ modułu na aplikację: |
Przepływ modułu: |
Menu i podmenu: |
Pisownia oraz kolejność i przydatność: |
Sterowanie dla każdego podmenu: |
Lista kontrolna nr 2: Lista kontrolna testowania formularzy / ekranów
Funkcjonalność formularza: |
Wpływ formy na aplikację: |
Przepływ formularzy: |
Projektowanie: |
Linie trasowania: |
Tytuł: |
Nazwy pól: |
Pisownia: |
Obowiązkowe znaki: |
Alerty do pól obowiązkowych: |
Guziki: |
Domyślna pozycja kursora: |
Sekwencja kart: |
Strona przed wprowadzeniem jakichkolwiek danych: |
Strona po wprowadzeniu danych: |
Lista kontrolna nr 3: Lista kontrolna testowania pola tekstowego
Pole tekstowe:
DODAJ (na ekranie dodawania) | EDYTUJ (na ekranie edycji) | |
Postacie | ||
Znaki specjalne | ||
Liczby | ||
Limit | ||
Alarm | ||
Pisownia i gramatyka w komunikacie Alert: |
BVA (rozmiar) dla pola tekstowego:
Min -> -> Pass
Min-1 -> -> Niepowodzenie
Min + 1 -> -> Pass
Max-1 -> -> Pass
Max + 1 -> -> Fail
Max -> -> Pass
ECP dla pola tekstowego:
Ważny | Nieważny |
- | - |
- | - |
Lista kontrolna nr 4: Lista kontrolna lub lista rozwijana Lista kontrolna testowania
Pole listy / menu rozwijane:
DODAJ (na ekranie dodawania) | EDYTUJ (na ekranie edycji) | |
nagłówek | ||
Poprawność istniejących danych | ||
Kolejność danych | ||
Zaznaczanie i odznaczanie | ||
Alarm: | ||
Pisownia i gramatyka alertu | ||
Kursor po alercie | ||
Refleksja zaznaczenia i odznaczenia w pozostałych polach |
Lista kontrolna nr 5: Lista kontrolna pól wyboru w terenie
CheckBox:
DODAJ (na ekranie dodawania) | EDYTUJ (na ekranie edycji) | |
Wybór domyślny | ||
Akcja po wyborze | ||
Akcja po usunięciu zaznaczenia | ||
Zaznaczanie i odznaczanie | ||
Alarm: | ||
Pisownia i gramatyka alertu | ||
Kursor po alercie | ||
Refleksja zaznaczenia i odznaczenia w pozostałych polach |
Lista kontrolna nr 6: Lista kontrolna testowania przycisków radiowych
Przycisk radiowy:
DODAJ (na ekranie dodawania) | EDYTUJ (na ekranie edycji) | |
Wybór domyślny | ||
Akcja po wyborze | ||
Akcja po usunięciu zaznaczenia | ||
Zaznaczanie i odznaczanie | ||
Alarm: | ||
Pisownia i gramatyka alertu | ||
Kursor po alercie | ||
Refleksja zaznaczenia i odznaczenia w pozostałych polach |
Lista kontrolna nr 7: Scenariusze testów terenowych z datą
Pole daty:
DODAJ (na ekranie dodawania) | EDYTUJ (na ekranie edycji) | |
Domyślny wyświetlacz daty | ||
Projekt kalendarza | ||
Nawigacja dla różnych miesięcy i lat w kontroli daty | ||
Ręczny wpis w polu tekstowym daty | ||
Format daty i zgodność z całym wnioskiem | ||
Alarm: | ||
Pisownia i gramatyka alertu | ||
Kursor po alercie | ||
Refleksja zaznaczenia i odznaczenia w pozostałych polach |
Lista kontrolna nr 8: Zapisz scenariusze testowania przycisków
Zapisz / aktualizuj:
DODAJ (na ekranie dodawania) | EDYTUJ (na ekranie edycji) | |
Bez podawania danych: | ||
Tylko z obowiązkowymi polami: | ||
Ze wszystkimi polami: | ||
Z maksymalnym limitem: | ||
Z minimalnym limitem | ||
Pisownia i gramatyka w komunikacie potwierdzającym: | ||
Kursor | ||
Powielanie unikalnych pól: | ||
Pisownia i gramatyka w duplikacie Komunikat ostrzegawczy: | ||
Kursor |
Lista kontrolna nr 9: Anuluj scenariusze testu przycisku
Anuluj:
Z danymi we wszystkich polach | ||
Tylko z obowiązkowymi polami: | ||
Ze wszystkimi polami: |
Lista kontrolna nr 10: Usuń punkty testowe przycisku
Kasować:
EDYTUJ (na ekranie edycji) | |
Usuń rekord, który nie jest używany nigdzie w aplikacji | |
Usuń rekord, który ma zależność | |
Dodaj ponownie nowy rekord z tymi samymi usuniętymi szczegółami |
Lista kontrolna nr 11: weryfikacja obszarów dotkniętych problemem po zapisaniu lub aktualizacji
Po zapisaniu / aktualizacji:
Wyświetl w widoku | |
Odbicie w dotkniętych formularzach w aplikacji |
Lista kontrolna nr 12: Lista testowania sieci danych
Siatka danych:
Tytuł siatki i pisownia | |
Formularz Przed podaniem jakichkolwiek danych | |
Wiadomość Przed podaniem jakichkolwiek danych | |
Pisownia | |
Wyrównanie | |
S Nie | |
Nazwy pól i kolejność | |
Poprawność istniejących danych | |
Kolejność istniejących danych | |
Dopasowanie istniejących danych | |
Nawigatory stron | |
Dane podczas nawigacji po różnych stronach |
Edytuj funkcjonalność łącza
Strona po edycji: | |
Tytuł i pisownia | |
Istniejące dane wybranego rekordu w każdym polu | |
guziki |
Chociaż ta lista może nie być wyczerpująca, jest rzeczywiście obszerna.
ŚCIĄGNIJ==> Możesz pobrać wszystkie te listy kontrolne w formacie MS Excel: Pobierz w formacie Excel
Punkty do zapamiętania:
- W zależności od potrzeb można dodać dodatkowe testy w ramach każdej kategorii / dla każdego pola lub usunąć istniejące pola. Innymi słowy, listy te można w pełni dostosować.
- Gdy zajdzie potrzeba dołączenia walidacji na poziomie pola do swoich zestawów testów, wystarczy wybrać odpowiednią listę i użyć jej na ekranie / stronie, którą chcesz przetestować.
- Utrzymuj listę kontrolną, aktualizując status pozytywny / negatywny, aby była to kompleksowa oferta obejmująca funkcje, ich walidację i zapisywanie wyników testów.
Zachęcamy do uzupełnienia tej listy kontrolnej, dodając więcej przypadków testowych / scenariuszy lub negatywnych przypadków testowych w sekcji komentarzy poniżej.
Byłbym również wdzięczny, gdybyś podzielił się tym ze znajomymi!
POPRZEDNIA samouczek | NEXT Tutorial
rekomendowane lektury
- Jak pisać przypadki testowe: najlepszy przewodnik z przykładami
- Testowanie plików cookie witryny i przypadki testowe do testowania plików cookie aplikacji internetowych
- Przykładowy szablon przypadku testowego z przykładami przypadków testowych (Pobierz)
- Najlepsze narzędzia do testowania oprogramowania 2021 (Narzędzia do automatyzacji testów QA)
- Podręcznik testowania zabezpieczeń aplikacji internetowych
- Testowanie aplikacji - podstawy testowania oprogramowania!
- Instalowanie aplikacji na urządzeniu i rozpoczęcie testowania z Eclipse
- TDD Vs BDD - Analiza różnic na przykładach