Jak pisać przypadki testowe: najlepszy przewodnik z przykładami

how write test cases

W tym dogłębnym praktycznym samouczku dotyczącym pisania przypadków testowych omówiłem szczegóły tego, czym jest przypadek testowy, jego standardową definicję i techniki projektowania przypadków testowych.

Co to jest przypadek testowy?

Przypadek testowy zawiera komponenty, które opisują dane wejściowe, działanie i oczekiwaną odpowiedź w celu ustalenia, czy funkcja aplikacji działa poprawnie.

Przypadek testowy to zestaw instrukcji „JAK” sprawdzić określony cel / cel testowy, który po wykonaniu tych czynności powie nam, czy oczekiwane zachowanie systemu jest spełnione, czy nie.

Lista samouczków objętych tą serią pisania przypadków testowych:

Jak napisać:

Samouczek nr 1: Co to jest przypadek testowy i jak pisać przypadki testowe (ten samouczek)
Samouczek nr 2: Przykładowy szablon przypadku testowego z przykładami (pobierz) (musisz przeczytać)
Samouczek nr 3: Pisanie przypadków testowych z dokumentu SRS
Samouczek nr 4: Jak pisać przypadki testowe dla danego scenariusza
Samouczek nr 5: Jak przygotować się do pisania przypadków testowych
Samouczek nr 6: Jak pisać negatywne przypadki testowe

Przykłady:

Samouczek nr 7: Ponad 180 przykładowych przypadków testowych dla aplikacji internetowych i komputerowych
Samouczek nr 8: Ponad 100 gotowych do wykonania scenariuszy testowych (lista kontrolna)

Techniki pisania:

Samouczek nr 9: Wykres przyczyn i skutków - dynamiczna technika pisania przypadków testowych
Samouczek nr 10: Technika testowania przejść między stanami
Samouczek nr 11: Technika testowania tablicy ortogonalnej
Samouczek nr 12: Technika zgadywania błędów
Samouczek nr 13: Tabela walidacji terenowej (FVT) Technika projektowania testów

Scenariusze testowe:

Samouczek nr 14: Przypadki testowe a scenariusze testowe
Samouczek nr 15: Różnica między planem testów, strategią testów i przypadkiem testowym

Automatyzacja:

Samouczek nr 16: Jak wybrać odpowiednie przypadki testowe do testowania automatycznego
Samouczek nr 17: Jak przetłumaczyć ręczne przypadki testowe na skrypty automatyzacji

Narzędzia do zarządzania testami:

Samouczek nr 18: Najlepsze narzędzia do zarządzania testami
Samouczek nr 19: TestLink do zarządzania przypadkami testowymi
Samouczek nr 20: Tworzenie przypadków testowych i zarządzanie nimi za pomocą HP Quality Center
Samouczek nr 21: Wykonywanie przypadków testowych przy użyciu ALM / QC

Przypadki specyficzne dla domeny:

Samouczek nr 22: Przypadki testowe dla aplikacji ERP
Samouczek nr 23: Przypadki testowe aplikacji JAVA
Samouczek nr 24: Analiza wartości brzegowych i podział równoważności

Kontynuujmy pierwszy samouczek z tej serii.

Zalecane narzędzia:

Przed przystąpieniem do pisania przypadków testowych zalecamy pobranie tego narzędzia do zarządzania przypadkami testowymi. Ułatwi to proces pisania przypadków testowych, o którym mowa w tym samouczku:

# 1) TestRail

=> Pobierz narzędzie do zarządzania przypadkami testowymi TestRail

# 2) TestMonitor

Zarządzanie testami online na najwyższym poziomie. Rewolucyjne łatwe.

TestMonitor to kompleksowe narzędzie do zarządzania testami dla każdej organizacji. Proste, intuicyjne podejście do testowania. Niezależnie od tego, czy wdrażasz oprogramowanie dla przedsiębiorstw, potrzebujesz kontroli jakości, tworzysz wysokiej jakości aplikację, czy po prostu potrzebujesz pomocy w projekcie testowym, TestMonitor zapewni Ci wsparcie.

=> Odwiedź witrynę TestMonitor

Czego się nauczysz:

algorytm sortowania bąbelkowego C ++

• Co to jest przypadek testowy i jak pisać przypadki testowe?
  • Dlaczego piszemy testy?
  • Jak pisać przypadki testowe?
  • Podstawowy format instrukcji przypadku testowego
• Wskazówki dotyczące pisania testów
  • • # 1) Utrzymuj to proste, ale nie za proste; uczynić to złożonym, ale niezbyt złożonym:
    • # 2) Po udokumentowaniu przypadków testowych przejrzyj raz jako Tester:
    • # 3) Wiąż i ułatwiaj testerom:
    • # 4) Bądź współtwórcą:
    • # 5) Nigdy nie zapomnij o użytkowniku końcowym:
• Jak osiągnąć doskonałość w dokumentacji przypadków testowych
  • Przydatne porady i wskazówki
    • # 1) Czy Twój dokument testowy jest w dobrym stanie?
    • # 2) Nie zapomnij opisywać przypadków negatywnych
    • # 3) Wykonaj kroki testu atomowego
    • # 4) Ustal priorytety testów
    • # 5) Sekwencja ma znaczenie
    • # 6) Dodaj znacznik czasu i nazwę testera do komentarzy
    • # 7) Uwzględnij szczegóły przeglądarki
    • # 8) Zachowaj dwa osobne arkusze - „Błędy” i „Podsumowanie” w dokumencie
• Jak NIE pisać testów
  • 3 Najczęstsze problemy w przypadkach testowych
    • # 1) Kroki złożone
    • # 2) Zachowanie aplikacji jest zgodne z oczekiwaniami
    • # 3) Wiele warunków w jednym przypadku
• Jak poprawić efektywność przypadków testowych
  • Zbieranie dokumentów do pisania testów
  • Prawdziwy przykład
  • Dokument przypadku testowego
  • Zbieranie danych testowych
• Znaczenie standaryzacji przypadków testowych
  • Powody ponownego wykorzystania przypadków testowych
  • Co to jest test standardowy w testach internetowych?
  • Wniosek
  • rekomendowane lektury

Co to jest przypadek testowy i jak pisać przypadki testowe?

Pisanie skutecznych przypadków to umiejętność. Możesz się tego nauczyć z doświadczenia i wiedzy o testowanej aplikacji.

Aby uzyskać podstawowe instrukcje dotyczące pisania testów, obejrzyj poniższy film:

Powyższe zasoby powinny dać nam podstawy procesu pisania testów.

Poziomy procesu pisania testów:

• Poziom 1: Na tym poziomie napiszesz podstawowe przypadki z dostępnej specyfikacji i dokumentacja użytkownika.
• Poziom 2: To jest etap praktyczny w których przypadki pisania zależą od faktycznego przepływu funkcjonalnego i systemowego aplikacji.
• Poziom 3: Na tym etapie pogrupujesz niektóre sprawy i napisz procedurę testową . Procedura testowa to nic innego jak grupa małych przypadków, może maksymalnie 10.
• Poziom 4: Automatyzacja projektu. Zminimalizuje to interakcję człowieka z systemem, dzięki czemu kontrola jakości może skupić się na aktualnie aktualizowanych funkcjach do testowania, zamiast zajmować się testowaniem regresji.

Dlaczego piszemy testy?

Podstawowym celem pisania przypadków jest aby zweryfikować zakres testów aplikacji.

Jeśli pracujesz w dowolnej organizacji CMMi, standardy testów są dokładniej przestrzegane. Pisanie przypadków wprowadza pewną standaryzację i minimalizuje ad-hoc podejście do testowania.

Jak pisać przypadki testowe?

Pola:

• Identyfikator przypadku testowego
• Jednostka do przetestowania: Co należy zweryfikować?
• Założenia
• Dane testowe: Zmienne i ich wartości
• Kroki do wykonania
• Spodziewany wynik
• Aktualny rezultat
• Pass / Fail
• Komentarze

Podstawowy format instrukcji przypadku testowego

Zweryfikować
Za pomocą (nazwa narzędzia, nazwa tagu, okno dialogowe itp.)
Z (warunki)
Do (co jest zwracane, pokazywane, pokazywane)

Zweryfikować: Używane jako pierwsze słowo w instrukcji testowej.
Za pomocą: Aby zidentyfikować, co jest testowane. W zależności od sytuacji możesz użyć tutaj „wprowadzanie” lub „wybieranie” zamiast używania.

W przypadku każdej aplikacji musisz uwzględnić wszystkie rodzaje testów, takie jak:

• Sprawy funkcjonalne
• Przypadki negatywne
• Przypadki graniczne

Podczas pisania tych wszystkich plików Najlepsi współtwórcy powinni być proste i łatwe do zrozumienia .

************************************************

Wskazówki dotyczące pisania testów

Jedną z najczęstszych i głównych czynności testera oprogramowania (osoby z SQA / SQC) jest pisanie scenariuszy i przypadków testowych.

Istnieje kilka ważnych i krytycznych czynników związanych z tą główną działalnością. Przyjrzyjmy się najpierw tym czynnikom z lotu ptaka.

Ważne czynniki związane z procesem pisania:

a) Najlepsi współtwórcy są podatni na regularne poprawki i aktualizacje:

Żyjemy w ciągle zmieniającym się świecie i to samo dotyczy również oprogramowania. Zmiany wymagań oprogramowania mają bezpośredni wpływ na przypadki. Za każdym razem, gdy zmieniają się wymagania, TC wymaga aktualizacji.

Jednak nie tylko zmiana wymagań może spowodować rewizję i aktualizację TC. Podczas wykonywania TC pojawia się wiele pomysłów i można zidentyfikować wiele warunków podrzędnych jednego TC. Wszystko to powoduje aktualizację TC, a czasem nawet prowadzi do dodania nowych TC.

Co więcej, podczas testów regresji kilka poprawek i / lub zmian wymaga zmiany lub nowych TC.

b) TC są podatni na rozpowszechnianie wśród testerów, którzy wykonają następujące czynności:

Oczywiście nie ma takiej sytuacji, w której jeden tester wykonuje wszystkie TC. Zwykle jest kilku testerów, którzy testują różne moduły jednej aplikacji. Zatem TC są podzieleni między testerów według posiadanych przez nich obszarów testowanej aplikacji.

Niektóre TC związane z integracją aplikacji mogą być wykonywane przez wielu testerów, podczas gdy inne TC mogą być wykonywane tylko przez jednego testera.

c) TC są podatne na tworzenie klastrów i grupowanie:

To normalne i powszechne, że TC należący do jednego scenariusza testowego zwykle żądają ich wykonania w określonej kolejności lub w formie grupy. Mogą istnieć wymagania wstępne TC, które wymagają wykonania innych TC przed uruchomieniem się.

Podobnie, zgodnie z logiką biznesową AUT, jeden TC może mieć udział w kilku warunkach testowych, a jeden warunek testowy może składać się z wielu TC.

d) TC mają tendencję do współzależności:

Jest to również interesujące i ważne zachowanie TC wskazujące, że mogą być od siebie współzależni. Od średnich do dużych aplikacji o złożonej logice biznesowej ta tendencja jest bardziej widoczna.

Najbardziej przejrzystym obszarem każdej aplikacji, w którym można z pewnością zaobserwować to zachowanie, jest współdziałanie między różnymi modułami tych samych lub nawet różnych aplikacji. Mówiąc prosto, wszędzie tam, gdzie różne moduły, pojedyncza aplikacja lub wiele aplikacji są od siebie zależne, to samo zachowanie jest również odzwierciedlane w TC.

e) Najlepsi współtwórcy są podatni na rozpowszechnianie wśród programistów (szczególnie w środowisku programistycznym opartym na testach):

Ważnym faktem dotyczącym TC jest to, że mają one być używane nie tylko przez testerów. W normalnym przypadku, gdy błąd jest naprawiany przez programistów, pośrednio używają oni TC do naprawienia problemu. Podobnie, jeśli postępuje się za rozwojem opartym na testach, deweloperzy używają bezpośrednio TC w celu zbudowania ich logiki i uwzględnienia wszystkich scenariuszy w ich kodzie, do których odnoszą się TC.

Wskazówki dotyczące pisania skutecznych testów:

Mając na uwadze powyższe 5 czynników, oto kilka wskazówek, jak pisać skutecznych Najlepszych Współtwórców.

Zaczynajmy!!!

# 1) Utrzymuj to proste, ale nie za proste; uczynić to złożonym, ale niezbyt złożonym:

To stwierdzenie wydaje się paradoksem. Ale obiecuję, że tak nie jest. Utrzymuj wszystkie etapy NW atomowo i precyzyjnie. Wymień kroki z poprawną sekwencją i poprawnym mapowaniem do oczekiwanych wyników. Przypadek testowy powinien być oczywisty i łatwy do zrozumienia. Właśnie o to mi chodzi, żeby to uprościć.

Teraz, uczynienie go złożonym, oznacza zintegrowanie go z planem testów i innymi TC. W razie potrzeby zapoznaj się z innymi TC, odpowiednimi artefaktami, GUI itp. Ale rób to w zrównoważony sposób. Nie zmuszaj testera do poruszania się w tę iz powrotem w stosie dokumentów w celu ukończenia pojedynczego scenariusza testowego.

Z drugiej strony, nie pozwól nawet testerowi dokumentować tych TC w bardzo zwięzły sposób. Pisząc NW, zawsze pamiętaj, że Ty lub ktoś inny będziecie musieli je poprawić i zaktualizować.

# 2) Po udokumentowaniu przypadków testowych przejrzyj raz jako Tester:

Nigdy nie myśl, że praca jest wykonywana po napisaniu ostatniego TC scenariusza testowego. Przejdź na początek i raz przejrzyj wszystkich Najlepszych Współtwórców, ale nie z myślą o autorach najlepszych współtwórców lub planistach testów. Przejrzyj wszystkich NW z myślą o testerze. Myśl racjonalnie i spróbuj wysuszyć swoich najlepszych współtwórców.

Oceń, czy wszystkie kroki i zobacz, czy wspomniałeś o nich wyraźnie w zrozumiały sposób i czy oczekiwane wyniki są zgodne z tymi krokami.

Upewnij się, że dane testowe określony w TC jest wykonalny nie tylko dla rzeczywistych testerów, ale jest również zgodny ze środowiskiem czasu rzeczywistego. Upewnij się, że nie ma konfliktu zależności między TC i sprawdź, czy wszystkie odniesienia do innych TC / artefaktów / GUI są dokładne. W przeciwnym razie Testerzy mogą mieć poważne kłopoty.

# 3) Wiąż i ułatwiaj testerom:

Nie zostawiaj danych testowych na testerach. Daj im szereg danych wejściowych, zwłaszcza gdy mają być wykonane obliczenia lub zachowanie aplikacji zależy od danych wejściowych. Możesz pozwolić im decydować o wartościach testowych pozycji danych, ale nigdy nie dawaj im swobody wyboru samych testowych pozycji danych.

Ponieważ, celowo lub nieumyślnie, mogą ponownie i ponownie używać tych samych danych testowych, a niektóre ważne dane testowe mogą zostać zignorowane podczas wykonywania TC.

Zapewnij testerom swobodę, organizując TC według kategorii testowania i powiązanych obszarów aplikacji. Jasno poucz i wspominaj, którzy TC są współzależni i / lub grupowi. Podobnie, wyraźnie wskaż, którzy TC są niezależni i odizolowani, aby tester mógł odpowiednio zarządzać swoją całością działań.

W tym miejscu możesz być zainteresowany poczytaniem o analizie wartości brzegowych, która jest strategią projektowania przypadków testowych, która jest używana w testach czarnoskrzynkowych. Kliknij tutaj aby dowiedzieć się więcej na ten temat.

# 4) Bądź współtwórcą:

Nigdy nie akceptuj FS ani dokumentu projektowego w takiej postaci, w jakiej jest. Twoim zadaniem nie jest tylko przejście przez FS i zidentyfikowanie scenariuszy testowych. Będąc specjalistą ds. Kontroli jakości, nie wahaj się i nie wahaj się wspierać biznesu i dawaj sugestie, jeśli uważasz, że można coś ulepszyć w aplikacji.

Zasugeruj także programistom, zwłaszcza w środowisku programistycznym opartym na TC. Zaproponuj listy rozwijane, elementy sterujące kalendarza, listę wyboru, przyciski opcji grup, bardziej znaczące wiadomości, przestrogi, monity, ulepszenia związane z użytecznością itp.

Będąc QA, nie tylko testuj, ale zrób różnicę!

# 5) Nigdy nie zapomnij o użytkowniku końcowym:

Najważniejszym interesariuszem jest „Użytkownik końcowy”, który ostatecznie będzie korzystał z aplikacji. Dlatego nigdy nie zapominaj o nim na żadnym etapie pisania NW. W rzeczywistości użytkownik końcowy nie powinien być ignorowany na żadnym etapie całego SDLC. Jednak dotychczasowy nacisk kładę tylko na mój temat.

Dlatego podczas identyfikacji scenariuszy testowych nigdy nie pomijaj przypadków, które będą najczęściej używane przez użytkownika, ani przypadków krytycznych dla biznesu, nawet jeśli są rzadziej używane. Pozostań na miejscu użytkownika końcowego, a następnie przejrzyj wszystkich Najlepszych Współtwórców i oceń praktyczną wartość wykonania wszystkich udokumentowanych Najlepszych Współtwórców.

************************************************

Jak osiągnąć doskonałość w dokumentacji przypadków testowych

Będąc testerem oprogramowania, z pewnością zgodzisz się ze mną, że wymyślenie idealnego dokumentu testowego jest naprawdę trudnym zadaniem.

Zawsze zostawiamy trochę miejsca na ulepszenia w naszym Dokumentacja przypadku testowego . Czasami nie jesteśmy w stanie zapewnić 100% pokrycia testów przez najlepszych współtwórców, a czasami szablon testu nie jest odpowiedni lub brakuje nam dobrej czytelności i przejrzystości naszych testów.

Jako tester, ilekroć zostaniesz poproszony o napisanie dokumentacji testowej, nie zaczynaj od razu w sposób doraźny. Bardzo ważne jest, aby dobrze zrozumieć cel pisania przypadków testowych przed przystąpieniem do tworzenia dokumentacji.

Testy powinny być zawsze jasne i przejrzyste. Powinny być napisane w sposób ułatwiający testerowi przeprowadzenie pełnego testu poprzez wykonanie kroków określonych w każdym z testów.

Ponadto dokument przypadku testowego powinien zawierać tyle przypadków, ile jest wymaganych do zapewnienia kompletności pokrycie testu . Na przykład powinieneś spróbować objąć testowanie dla wszystkich możliwych scenariuszy, które mogą wystąpić w twojej aplikacji.

Mając na uwadze powyższe punkty, pozwólcie, że poprowadzę was teraz przez wycieczkę po tym, jak osiągnąć doskonałość w dokumentacji testów.

Przydatne porady i wskazówki

W tym miejscu mam zamiar podać kilka przydatnych wskazówek, które mogą dać ci przewagę w dokumentacji testowej od innych.

# 1) Czy Twój dokument testowy jest w dobrym stanie?

Najlepszym i najprostszym sposobem uporządkowania dokumentu testowego jest podzielenie go na wiele pojedynczych przydatnych sekcji. Podziel całe testowanie na wiele scenariuszy testowych. Następnie podziel każdy scenariusz na wiele testów. Na koniec podziel każdy przypadek na wiele etapów testowych.

Jeśli korzystasz z programu Excel, udokumentuj każdy przypadek testowy na osobnym arkuszu skoroszytu, w którym każdy przypadek testowy opisuje jeden pełny przebieg testu.

# 2) Nie zapomnij opisywać przypadków negatywnych

Jako tester oprogramowania musisz myśleć nieszablonowo i narysować wszystkie możliwości, jakie napotyka Twoja aplikacja. Jako testerzy musimy sprawdzić, czy wszelkie nieautentyczne próby wejścia do oprogramowania lub nieprawidłowe dane przepływające przez aplikację powinny zostać zatrzymane i zgłoszone.

Zatem przypadek negatywny jest równie ważny, jak przypadek pozytywny. Upewnij się, że dla każdego posiadanego scenariusza dwa przypadki testowe - jeden pozytywny i jeden negatywny . Dodatni powinien obejmować przepływ zamierzony lub normalny, a ujemny przepływ niezamierzony lub wyjątkowy.

# 3) Wykonaj kroki testu atomowego

Każdy krok testu powinien być atomowy. Nie powinno być żadnych dalszych podetapów. Im prostszy i bardziej przejrzysty jest etap testu, tym łatwiej będzie go kontynuować.

# 4) Ustal priorytety testów

Często mamy rygorystyczne ramy czasowe na zakończenie testów aplikacji. W takim przypadku możemy przegapić testowanie niektórych ważnych funkcji i aspektów oprogramowania. Aby tego uniknąć, podczas dokumentowania każdego testu należy oznaczyć priorytet.

Możesz użyć dowolnego kodowania, aby określić priorytet testu. Generalnie lepiej jest użyć dowolnego z 3 poziomów, wysoki, średni i niski lub 1, 50 i 100. Tak więc, jeśli masz ścisły harmonogram, powinieneś najpierw wykonać wszystkie testy o wysokim priorytecie, a następnie przejść do testów o średnim i niskim priorytecie.

Na przykład - w przypadku sklepu internetowego weryfikacja odmowy dostępu za nieprawidłową próbę zalogowania się do aplikacji może być sprawą o wysokim priorytecie, weryfikacja wyświetlania odpowiednich produktów na ekranie użytkownika może być sprawą o średnim priorytecie i weryfikacja koloru tekstu wyświetlanego na przyciski ekranowe mogą być testami o niskim priorytecie.

# 5) Sekwencja ma znaczenie

Sprawdź, czy kolejność czynności w teście jest absolutnie poprawna. Niewłaściwa kolejność czynności może prowadzić do nieporozumień. Najlepiej, gdy kroki powinny również definiować całą sekwencję od wejścia do aplikacji do wyjścia z aplikacji dla konkretnego testowanego scenariusza.

# 6) Dodaj znacznik czasu i nazwę testera do komentarzy

Może się zdarzyć, że testujesz aplikację, ktoś wprowadza modyfikacje równolegle do tej samej aplikacji lub ktoś może zaktualizować aplikację po zakończeniu testów. Prowadzi to do sytuacji, w której wyniki testów mogą się zmieniać w czasie.

Dlatego zawsze lepiej jest dodać sygnaturę czasową z nazwiskiem testera w komentarzach testowych, aby wynik testu (pozytywny lub negatywny) można było przypisać do stanu aplikacji w danym momencie. Alternatywnie możesz mieć „ Data wykonania ”Kolumna dodana osobno do przypadku testowego, która wyraźnie określa sygnaturę czasową testu.

# 7) Uwzględnij szczegóły przeglądarki

Jak wiesz, jeśli jest to aplikacja internetowa, wyniki testu mogą się różnić w zależności od przeglądarki, w której jest wykonywany. Aby ułatwić innym testerom, programistom lub każdemu, kto przegląda dokument testowy, należy dodać do sprawy nazwę i wersję przeglądarki, aby można było łatwo replikować defekt.

# 8) Zachowaj dwa osobne arkusze - „Błędy” i „Podsumowanie” w dokumencie

Jeśli dokumentujesz w programie Excel, pierwsze dwa arkusze skoroszytu powinny zawierać podsumowanie i błędy. Arkusz podsumowania powinien zawierać podsumowanie scenariusza testowego, a arkusz błędów powinien zawierać listę wszystkich problemów napotkanych podczas testowania. Znaczenie dodania tych dwóch arkuszy polega na tym, że da czytelnikowi / użytkownikowi dokumentu jasne zrozumienie procesu testowania.

Tak więc, gdy czas jest ograniczony, te dwa arkusze mogą okazać się bardzo przydatne w przedstawieniu przeglądu testów.

Dokument testowy powinien zapewniać jak najlepsze pokrycie testu, doskonałą czytelność i powinien mieć jeden standardowy format.

Możemy osiągnąć doskonałość w dokumentacji testów, pamiętając po prostu o kilku podstawowych wskazówkach, takich jak organizacja dokumentu przypadków testowych, ustalanie priorytetów TC, posiadanie wszystkiego we właściwej kolejności, w tym wszystkie obowiązkowe szczegóły dotyczące wykonania TC oraz zapewnienie jasnych i przejrzystych kroków testowych, itp., jak omówiono powyżej.

************************************************

Jak NIE pisać testów

Większość czasu spędzamy na pisaniu, przeglądaniu, wykonywaniu lub utrzymywaniu tychże. Szkoda, że ​​testy są również najbardziej podatne na błędy. Różnice w rozumieniu, organizacyjne praktyki testowania, brak czasu itp. To tylko niektóre z powodów, dla których często widzimy testy, które pozostawiają wiele do życzenia.

Na naszej stronie jest wiele artykułów na ten temat, ale tutaj się zobaczy Jak NIE pisać przypadków testowych - kilka wskazówek, które będą pomocne w tworzeniu charakterystycznych, jakościowych i skutecznych testów.

Czytajmy dalej i pamiętaj, że te wskazówki są przeznaczone zarówno dla nowych, jak i doświadczonych testerów.

3 Najczęstsze problemy w przypadkach testowych

1. Stopnie kompozytowe
2. Zachowanie aplikacji jest traktowane zgodnie z oczekiwaniami
3. Wiele warunków w jednym przypadku

Te trzy elementy muszą znaleźć się na mojej liście 3 najczęściej występujących problemów w procesie pisania testów.

Co ciekawe, dzieje się tak zarówno w przypadku nowych, jak i doświadczonych testerów, a my po prostu stosujemy te same wadliwe procesy, nie zdając sobie sprawy, że kilka prostych środków może łatwo naprawić sytuację.

Przejdźmy do tego i omówmy szczegółowo każdy z nich:

# 1) Kroki złożone

Po pierwsze, czym jest złożony krok?

Na przykład, podajesz wskazówki od punktu A do punktu B: jeśli powiesz, że „Idź do miejsca XYZ, a następnie do ABC”, nie będzie to miało większego sensu, ponieważ tutaj myślimy: „Jak mam dostać się do XYZ w pierwszej kolejności ”- zamiast tego zacząć od„ Skręć w lewo stąd i jedź 1 milę, a następnie skręć w prawo w Rd. nr 11, aby dotrzeć do XYZ ”może przynieść lepsze wyniki.

Dokładnie te same zasady dotyczą testów i ich kroków.

Na przykład Piszę test dla Amazon.com - złóż zamówienie na dowolny produkt.

Poniżej znajdują się moje kroki testowe (uwaga: piszę tylko kroki, a nie wszystkie inne części testu, takie jak oczekiwany wynik itp.)

do . Uruchom Amazon.com
b . Wyszukaj produkt, wprowadzając słowo kluczowe / nazwę produktu w polu „Szukaj” u góry ekranu.
do . Z wyświetlonych wyników wyszukiwania wybierz pierwszy.
re . Kliknij Dodaj do koszyka na stronie szczegółów produktu.
jest . Kasa i zapłać.
fa . Sprawdź stronę potwierdzenia zamówienia.

Teraz, czy możesz określić, który z nich jest złożony? Prawy- Krok (e)

Pamiętaj, że testy zawsze dotyczą „Jak” testować, dlatego ważne jest, aby w swoim teście napisać dokładne kroki „Jak płacić i płacić”.

Dlatego powyższy przypadek jest bardziej skuteczny, gdy zostanie napisany poniżej:

do . Uruchom Amazon.com
b . Wyszukaj produkt, wprowadzając słowo kluczowe / nazwę produktu w polu „Szukaj” u góry ekranu.
do . Z wyświetlonych wyników wyszukiwania wybierz pierwszy.
re . Kliknij Dodaj do koszyka na stronie szczegółów produktu.
jest . Kliknij Do kasy na stronie koszyka.
fa . Wprowadź informacje CC, informacje o wysyłce i rozliczeniu.
sol . Kliknij Do kasy.
godz . Sprawdź stronę potwierdzenia zamówienia.

Dlatego etap złożony to taki, który można podzielić na kilka oddzielnych etapów. Następnym razem, gdy będziemy pisać testy, zwróćmy wszyscy uwagę na tę część i jestem pewien, że zgodzicie się ze mną, że robimy to częściej, niż nam się wydaje.

# 2) Zachowanie aplikacji jest zgodne z oczekiwaniami

W dzisiejszych czasach coraz więcej projektów ma do czynienia z tą sytuacją.

Brak dokumentacji, ekstremalne programowanie, szybkie cykle rozwojowe to kilka powodów, które zmuszają nas do polegania na aplikacji (lub starszej wersji) do pisania testów lub oparcia samych testów. Jak zawsze, jest to sprawdzona zła praktyka - nie zawsze naprawdę.

Jest to nieszkodliwe, o ile masz otwarty umysł i spodziewasz się, że - „AUT może być wadliwy”. Tylko wtedy, gdy nie myślisz, że tak jest, wszystko działa źle. Jak zawsze, pozwolimy przemówić przykładom.

Jeśli poniżej jest strona, na której piszesz / projektujesz kroki testu:

Przypadek 1:

Jeśli kroki mojego przypadku testowego są następujące:

1. Uruchom witrynę zakupów.
2. Kliknij opcję Wysyłka i zwrot - Oczekiwany wynik: Strona wysyłki i zwrotów jest wyświetlana z napisem „Wpisz tutaj swoje informacje” i przyciskiem „Kontynuuj”.

Zatem jest to niepoprawne.

Przypadek 2:

1. Uruchom witrynę zakupów.
2. Kliknij opcję Wysyłka i zwrot.
3. W polu tekstowym „Wprowadź numer zamówienia” znajdującym się na tym ekranie wprowadź numer zamówienia.
4. Kliknij Kontynuuj - Oczekiwany wynik: Wyświetlane są szczegóły zamówienia związane z wysyłką i zwrotami.

Przypadek 2 jest lepszym przypadkiem testowym, ponieważ nawet jeśli aplikacja referencyjna zachowuje się niepoprawnie, traktujemy ją tylko jako wskazówkę, wykonujemy dalsze badania i zapisujemy oczekiwane zachowanie zgodnie z przewidywaną poprawną funkcjonalnością.

Konkluzja: Aplikacja jako odniesienie to szybki skrót, ale wiąże się ona z własnymi zagrożeniami. Dopóki jesteśmy ostrożni i krytyczni, daje to niesamowite rezultaty.

# 3) Wiele warunków w jednym przypadku

Jeszcze raz uczmy się od Przykład .

Spójrz na poniższe kroki testowe: Poniżej przedstawiono kroki testowe w ramach jednego testu funkcji logowania.

za. Wpisz prawidłowe dane i kliknij Prześlij.
b. Pozostaw pole Nazwa użytkownika puste. Kliknij Prześlij.
do. Pozostaw pole hasła puste i kliknij Prześlij.
re. Wybierz już zalogowaną nazwę użytkownika / hasło i kliknij Prześlij.

To, co musiało być 4 różnymi przypadkami, łączy się w jeden. Możesz pomyśleć - co w tym złego? Oszczędza dużo dokumentacji, a co mogę zrobić w 4, robię to w 1-, czyż nie jest super? Cóż, niezupełnie. Powody?

Czytaj:

• A co jeśli jeden z warunków nie powiedzie się - musimy oznaczyć cały test jako „nieudany”. Jeśli oznaczymy cały przypadek jako „nieudany”, oznacza to, że nie działają wszystkie 4 warunki, co nie jest prawdą.
• Testy muszą mieć płynność. Od warunku wstępnego do kroku 1 i przez wszystkie etapy. Jeśli podążę za tym przypadkiem, w kroku (a), jeśli się powiedzie, zostanę zalogowany na stronie, na której opcja „logowanie” nie jest już dostępna. Kiedy więc przejdę do kroku (b) - gdzie tester będzie wprowadzał nazwę użytkownika? Widzisz, przepływ jest przerwany.

W związku z tym, pisać testy modułowe . Wydaje się, że to dużo pracy, ale wystarczy oddzielić rzeczy i użyć naszych najlepszych przyjaciół Ctrl + C i Ctrl + V do pracy dla nas. :)

************************************************

Jak poprawić efektywność przypadków testowych

Testerzy oprogramowania powinni pisać swoje testy od wcześniejszego etapu cyklu życia oprogramowania, najlepiej w fazie wymagań oprogramowania.

Kierownik testów lub kierownik ds. Zapewnienia jakości powinien zebrać i przygotować maksymalną możliwą liczbę dokumentów zgodnie z poniższą listą.

Zbieranie dokumentów do pisania testów

1) Dokument wymagań użytkownika

Jest to dokument zawierający listę procesów biznesowych, profili użytkowników, środowiska użytkownika, interakcji z innymi systemami, wymiany istniejących systemów, wymagań funkcjonalnych, wymagań niefunkcjonalnych, wymagań licencyjnych i instalacyjnych, wymagań wydajnościowych, wymagań bezpieczeństwa, użyteczności i wymagań współbieżnych itp. .,

2) Dokument przypadku użycia biznesowego

Ten dokument zawiera szczegółowe informacje na temat przypadek użycia scenariusz wymagań funkcjonalnych z perspektywy biznesowej. Ten dokument obejmuje aktorów biznesowych (lub system), cele, warunki wstępne, warunki końcowe, przepływ podstawowy, przepływ alternatywny, opcje, wyjątki dla każdego przepływu biznesowego systemu zgodnie z wymaganiami.

# 3) Dokument wymagań funkcjonalnych

W tym dokumencie szczegółowo opisano wymagania funkcjonalne każdej funkcji systemu w ramach wymagań.

Zwykle dokument wymagań funkcjonalnych służy jako wspólne repozytorium zarówno dla zespołu deweloperskiego i testującego, jak i dla interesariuszy projektu, w tym dla klientów zaangażowanych (czasami zamrożonych) wymagań, które należy traktować jako najważniejszy dokument dla każdego rozwoju oprogramowania.

# 4) Plan projektu oprogramowania (opcjonalnie)

Dokument opisujący szczegóły projektu, cele, priorytety, kamienie milowe, działania, strukturę organizacyjną, strategię, monitorowanie postępów, analizę ryzyka, założenia, zależności, ograniczenia, wymagania szkoleniowe, obowiązki klienta, harmonogram projektu itp.,

5) QA / Plan testów

Dokument ten szczegółowo opisuje system zarządzania jakością, standardy dokumentacji, mechanizm kontroli zmian, krytyczne moduły i funkcjonalności, system zarządzania konfiguracją, plany testowania, śledzenie defektów, kryteria akceptacji itp.

Plik plan testów dokument służy do identyfikacji funkcji do testowania, funkcji, które nie mają być testowane, przydziałów zespołów testujących i ich interfejsu, wymagań dotyczących zasobów, harmonogramu testów, pisania testów, pokrycia testów, wyników testów, wymagań wstępnych do wykonania testów, raportowania błędów i śledzenia mechanizm, metryki testów itp.,

Prawdziwy przykład

Zobaczmy, jak efektywnie pisać przypadki testowe dla znanego i prostego ekranu „Logowanie”, jak na poniższym rysunku. Plik podejście do testowania będzie prawie taki sam nawet na złożonych ekranach z większą ilością informacji i krytycznymi funkcjami.

# 1) Pierwszym podejściem do każdego procesu testowego będzie uzyskanie prototypu ekranu (lub ramek drucianych) jak powyżej, jeśli są dostępne. Może to nie być dostępne w przypadku niektórych funkcji i zależy od krytyczności projektowania prototypu na wcześniejszych etapach rozwoju.

Ale jeśli plik SRS Dokument (Specyfikacja wymagań oprogramowania) jest dostępny dla projektu, większość prototypów ekranu jest opracowywana przez zespół projektowy. Ten rodzaj ekranu upraszcza pracę testera i zwiększa wydajność testów.

#dwa) Następnie specyfikacje wymagań funkcjonalnych . To zależy od procesu organizacyjnego, będzie dostępne w pakiecie wielu dokumentów.

Zatem wybierz najlepszy dokument do pisania przypadków, może to być dokument wymagań użytkownika lub specyfikacja wymagań funkcjonalnych (lub nawet dokument SRS, jeśli może to być zrozumiałe dla zespołu testującego), który zapewni pełny przepływ funkcjonalny wybranego funkcja do przetestowania.

# 3) Gdy prototyp ekranu i specyfikacje funkcjonalne są gotowe, tester powinien rozpocząć pisanie przypadków, stosując następujące podejście i kryteria.

• Testy interfejsu użytkownika :Kontrolki / pola, które są widoczne dla użytkownika. Dla testowanej funkcji dostępna jest kontrola statyczna i dynamiczna. Na przykład, na ekranie logowania powyżej teksty „Nazwa użytkownika i hasło” to pola statyczne, które nie wymagają interakcji użytkownika, a jedynie wyświetla tekst.

• Sprawy funkcjonalne :Z drugiej strony przycisk Zaloguj się i hiperłącza (zapomniałeś hasła? I rejestracja) to dynamiczne pola, które wymagają interakcji użytkownika poprzez kliknięcie elementów sterujących, co później wykona pewne działanie.

• Przypadki baz danych :Gdy użytkownik wprowadzi nazwę użytkownika i hasło, można napisać testy, aby sprawdzić powiązaną bazę danych, czy nazwa użytkownika i hasło są sprawdzane w odpowiedniej bazie danych i tabeli, a także użytkownik ma uprawnienia do logowania się do testowanej aplikacji.
  

• Testy procesów :Jest to związane z procesem (a nie akcjami związanymi z widocznymi kontrolkami dostępnymi na ekranie) związanym z funkcją i funkcjonalnością. Na przykład, kliknięcie łącza Nie pamiętam hasła na powyższym przykładowym ekranie może wysłać wiadomość e-mail do użytkownika. Może więc e-mail musi zostać przetestowany pod kątem prawidłowego procesu i potwierdzenia.

4) Na koniec zachowaj „ Mantra BAOE ', znaczy i) Przepływ podstawowy ii) Przepływ alternatywny iii) Opcje oraz iv) Wyjątki dla pełnego pokrycia funkcjonalnego przepływu i funkcji do przetestowania. Każda koncepcja powinna być zastosowana do testów pozytywnych i negatywnych.

Na przykład, zobaczmy proste podejście BAOE dla przykładowego ekranu logowania powyżej.

• Przepływ podstawowy: Wprowadź ścieżkę URL Loginu w dowolnej przeglądarce, wprowadź wymagane informacje i zaloguj się do aplikacji.
• Przepływ alternatywny: Zainstaluj aplikację na urządzeniu mobilnym, wprowadź wymagane informacje i zaloguj się do aplikacji.
• Opcje: Jakie są dostępne opcje, aby przejść do tego samego ekranu logowania? Na przykład, po zalogowaniu się do aplikacji kliknięcie „Wyloguj” może spowodować wyświetlenie tego samego ekranu lub w przypadku wygaśnięcia sesji lub wygaśnięcia sesji użytkownik może przejść do ekranu logowania.
• Wyjątki: Jakie są wyjątki, jeśli moje testy są negatywne? Na przykład, jeśli na ekranie logowania zostaną wprowadzone nieprawidłowe dane uwierzytelniające, czy użytkownik otrzyma komunikat o błędzie, czy nie zostanie skojarzona żadna czynność.

Mając wszystkie te informacje pod ręką, zacznijmy pisać TC dla ekranu logowania, w formacie z pełnym pokryciem i identyfikowalnością oraz ze szczegółowymi informacjami. Logiczna kolejność i numeracja identyfikująca „ Identyfikator przypadku testowego ” będzie bardzo przydatny do szybkiej identyfikacji historii wykonania przypadków testowych.

Przeczytaj także=> Ponad 180 próbek gotowych do użycia przypadków testowych dla aplikacji internetowych i komputerowych.

Dokument przypadku testowego

Uwaga : Kolumny testowe nie są ograniczone do poniższego przykładowego dokumentu testowego, który można przechowywać w arkuszu Excela, aby mieć tyle kolumn, ile potrzeba do pełnej macierzy identyfikowalności, a mianowicie. Priorytet, cel testowania, rodzaj testowania, lokalizacja zrzutu ekranu błędu itp.,

Przeczytaj także=> Przykładowy szablon przypadku testowego z przykładami.

Aby ułatwić prostotę i czytelność tego dokumentu, napiszmy szczegółowo poniżej kroki umożliwiające odtworzenie, oczekiwane i rzeczywiste zachowanie testów na ekranie logowania.

Uwaga : Dodaj kolumnę Rzeczywiste zachowanie na końcu tego szablonu.

Zbieranie danych testowych

Podczas pisania przypadku testowego najważniejszym zadaniem każdego testera jest zebranie danych testowych. To działanie jest pomijane i pomijane przez wielu testerów z założeniem, że przypadki testowe mogą być wykonywane z przykładowymi danymi lub danymi fikcyjnymi i mogą być przesyłane, gdy dane są naprawdę potrzebne. Jest to krytyczne błędne przekonanie, że pobieranie danych próbnych lub danych wejściowych z pamięci umysłu w czasie wykonywania przypadków testowych.

Jeśli dane nie są gromadzone i aktualizowane w dokumencie testowym w czasie pisania testów, tester poświęciłby anormalnie więcej czasu na zebranie danych w czasie wykonywania testu. Dane testowe powinny być zbierane zarówno dla przypadków pozytywnych, jak i negatywnych z całej perspektywy funkcjonalnego przepływu cechy. Dokument biznesowego przypadku użycia jest bardzo przydatny w tej sytuacji.

Znajdź przykładowy dokument danych testowych dla testów opisanych powyżej, który z kolei będzie pomocny w tym, jak skutecznie możemy zebrać dane, które ułatwią nam pracę w momencie wykonywania testu.

************************************************

Znaczenie standaryzacji przypadków testowych

W tym zabieganym świecie nikt nie może robić powtarzalnych rzeczy dzień w dzień z takim samym zainteresowaniem i energią. Zwłaszcza nie pasjonuje mnie ciągłe wykonywanie tego samego zadania w pracy. Lubię zarządzać sprawami i oszczędzać czas. Każdy w IT powinien tak być.

Wszystkie firmy informatyczne realizują różnego rodzaju projekty. Projekty te mogą być oparte na produktach lub usługach. Większość z tych projektów dotyczy witryn internetowych i testowanie witryn internetowych . Dobra wiadomość jest taka, że ​​wszystkie strony internetowe mają wiele podobieństw. A jeśli witryny są przeznaczone dla tej samej domeny, mają również kilka wspólnych cech.

Pytanie, które zawsze mnie zaskakuje, brzmi: „Jeśli większość aplikacji jest podobna, na przykład: takie jak sklepy detaliczne, które były testowane tysiące razy wcześniej:„ Dlaczego musimy pisać od podstaw przypadki testowe dla kolejnej witryny detalicznej? ” Czy nie zaoszczędzi to mnóstwo czasu, usuwając istniejące skrypty testowe, które były używane do testowania poprzedniej witryny detalicznej?

Oczywiście, może być kilka drobnych poprawek, które moglibyśmy wprowadzić, ale ogólnie jest to łatwiejsze, wydajniejsze, oszczędza czas i pieniądze, a tym samym zawsze pomaga utrzymać wysoki poziom zainteresowania testerów. Kto lubi wielokrotnie pisać, przeglądać i utrzymywać te same przypadki testowe, prawda? Ponowne wykorzystanie istniejących testów może rozwiązać ten problem w dużym stopniu, a Twoi klienci również uznają to za inteligentne i logiczne.

Więc logicznie, zacząłem wyciągać istniejące skrypty z podobnych projektów internetowych, wprowadziłem zmiany i szybko je przejrzałem. Zastosowałem również kodowanie kolorami, aby pokazać wprowadzone zmiany, aby recenzent mógł skupić się tylko na części, która została zmieniona.

Powody ponownego wykorzystania przypadków testowych

# 1) Większość funkcjonalnych obszarów witryny to prawie - logowanie, rejestracja, dodawanie do koszyka, lista życzeń, kasy, opcje wysyłki, opcje płatności, zawartość strony produktu, ostatnio oglądane, odpowiednie produkty, funkcje kodów promocyjnych itp.

#dwa) Większość projektów to tylko ulepszenia lub zmiany w istniejącej funkcjonalności.

# 3) Systemy zarządzania treścią, które definiują miejsca na ładowanie obrazów w sposób statyczny i dynamiczny, są również wspólne dla wszystkich witryn internetowych.

# 4) Strony detaliczne mają CSR (Obsługa klienta) również.

# 5) System backendowy i aplikacja magazynowa wykorzystująca JDA są również używane przez wszystkie serwisy WWW.

# 6) Pojęcie plików cookie, limitu czasu i bezpieczeństwa jest również powszechne.

# 7) Projekty internetowe są często podatne na zmiany wymagań.

# 8) Plik rodzaje testów potrzebne są powszechne, jak przeglądarka testy zgodności , test wydajności , testy bezpieczeństwa

Widzisz, jest wiele wspólnych i podobnych.

Mając na uwadze, że wielokrotne użycie jest drogą do zrobienia, czasami same modyfikacje mogą zająć więcej lub mniej czasu lub nie. Czasami może się wydawać, że lepiej zacząć od zera, niż tyle modyfikować.

Można to łatwo rozwiązać, tworząc zestaw standardowych przypadków testowych dla każdej z typowych funkcji.

Co to jest test standardowy w testach internetowych?

• Twórz kompletne przypadki testowe - kroki, dane, zmienne itp. Zapewni to, że niepodobne dane / zmienne można po prostu zastąpić, gdy wymagany jest podobny przypadek testowy.
• Kryteria wejścia i wyjścia powinny być odpowiednio zdefiniowane.
• Modyfikowalne kroki lub oświadczenie w krokach należy wyróżnić innym kolorem, aby można je było szybko znaleźć i wymienić.
• Język używany do tworzenia standardowych przypadków testowych powinien być ogólny.
• Wszystkie funkcje każdej witryny powinny zostać uwzględnione w przypadkach testowych.
• Nazwa przypadków testowych powinna być nazwą funkcji lub funkcji, którą obejmuje przypadek testowy. Ułatwi to znacznie odnalezienie przypadku testowego z zestawu.
• Jeśli istnieje jakaś podstawowa lub standardowa próbka, plik GUI lub zrzut ekranu funkcji, należy go dołączyć wraz z odpowiednimi krokami.

Korzystając z powyższych wskazówek można stworzyć zestaw standardowych skryptów i używać ich z niewielkimi lub wymaganymi modyfikacjami dla różnych stron internetowych.

Te standardowe przypadki testowe również można zautomatyzować, ale ponownie skupienie się na możliwości ponownego wykorzystania jest zawsze plusem. Także jeśli automatyzacja opiera się na GUI, ponowne użycie skryptów w wielu adresach URL lub witrynach jest czymś, co osobiście nigdy nie było skuteczne.

Korzystanie ze standardowego zestawu ręcznych przypadków testowych dla różnych witryn internetowych z niewielkimi modyfikacjami jest najlepszym sposobem przeprowadzenia testów witryny. Wszystko, czego potrzebujemy, to tworzenie i utrzymywanie przypadków testowych z odpowiednimi standardami i zastosowaniem.

Wniosek

Poprawa efektywności przypadków testowych nie jest po prostu zdefiniowanym terminem, ale jest ćwiczeniem, które można osiągnąć poprzez dojrzały proces i regularną praktykę.

Zespół testowy nie powinien być zmęczony angażowaniem się w doskonalenie takich zadań, ponieważ jest to najlepsze narzędzie do większych osiągnięć w świecie jakości, co zostało udowodnione w wielu organizacjach testujących na całym świecie w projektach o znaczeniu krytycznym i złożonych aplikacjach.

Mam nadzieję, że zdobyłbyś ogromną wiedzę na temat koncepcji przypadków testowych. Obejrzyj naszą serię samouczków, aby dowiedzieć się więcej o przypadkach testowych i wyrażaj swoje przemyślenia w sekcji komentarzy poniżej!

jak oglądać plik mkv

Następny samouczek

rekomendowane lektury

• Testy funkcjonalne a testy niefunkcjonalne
• Przewodnik po testowaniu przenośności z praktycznymi przykładami
• Rodzaje testowania oprogramowania: różne typy testów ze szczegółami
• Najlepsze narzędzia do testowania oprogramowania 2021 (Narzędzia do automatyzacji testów QA)
• Testy alfa i testy beta (kompletny przewodnik)
• Co to jest testowanie systemu - najlepszy przewodnik dla początkujących
• ISTQB Testing Certification Przykładowe pytania z odpowiedziami
• Jak napisać tygodniowy raport o stanie testów oprogramowania