difference between test plan
Dowiedz się, jaka jest różnica między planem testów, strategią testów, przypadkiem testowym, skryptem testowym, scenariuszem testowym i warunkami testowymi z przykładami:
Testowanie oprogramowania obejmuje kilka podstawowych, a także ważnych pojęć, o których powinien wiedzieć każdy tester oprogramowania.
W tym artykule wyjaśniono różne pojęcia związane z testowaniem oprogramowania wraz z ich porównaniem.
Plan testów a strategia testów, przypadek testowy a skrypt testowy, scenariusz testowy a warunek testowy i procedura testowa a zestaw testów są szczegółowo wyjaśnione, aby ułatwić zrozumienie.
=> Kliknij tutaj, aby uzyskać pełną serię samouczków dotyczących planu testów
Powyższe pytanie zadane przez Sasi C. jest najczęściej zadawanym pytaniem w naszym Klasa testowania oprogramowania i zawsze mówię naszym uczestnikom, że wraz z doświadczeniem prawie nie zauważamy tych słów i że stają się one częścią naszego słownictwa.
Ale często otacza je zamieszanie iw tym artykule próbuję zdefiniować kilka powszechnie używanych terminów.
Różne koncepcje testowania oprogramowania
Poniżej wymieniono różne koncepcje testowania oprogramowania wraz z ich porównaniem.
Zaczynajmy!!
Obsługuje pytania i odpowiedzi na rozmowę kwalifikacyjną z technikiem
Czego się nauczysz:
- Różnica między planem testów a strategią testów
- Plan testów
- Dokument planu testów
- Strategia testów
- Dokument strategii testów
- 1) Przegląd projektu
- # 2) Zakres wymagań
- # 3) Plan testów wysokiego poziomu
- # 4) Podejście testowe
- # 5) Pokrycie testowe
- # 6) Środowisko testowe
- # 7) Elementy dostarczane i metryki kontroli jakości
- # 8) Zarządzanie defektami
- # 9) Zarządzanie komunikacją
- # 10) Założenia, ryzyko i zależności
- # 11) Dodatek
- Plan testów a strategia testów
- Różnica między przypadkiem testowym a skryptem testowym
- Różnica między scenariuszem testowym a warunkami testowymi
- Różnica między procedurą testową a zestawem testów
- Wniosek
Różnica między planem testów a strategią testów
Strategia testów i Plan testów to dwa ważne dokumenty w cyklu życia testów w każdym projekcie. Tutaj staramy się zapewnić dogłębną wiedzę na temat strategii testów i dokumentów planu testów.
Plan testów
Plan testów można zdefiniować jako dokument określający zakres, cel i podejście do testowania aplikacji. Plan testów to termin i produkt dostarczany.
Plan testów to dokument, który zawiera listę wszystkich czynności w projekcie zapewniania jakości, harmonogram ich, określa zakres projektu, role i obowiązki, ryzyko, kryteria wejścia i wyjścia, cel testu i wszystko, co przyjdzie Ci do głowy.
Plan testów to, jak lubię nazywać „super dokument”, który zawiera wszystko, co trzeba wiedzieć i potrzebować. Proszę sprawdź ten link aby uzyskać więcej informacji i próbkę.
Plan testów zostanie zaprojektowany w oparciu o wymagania. Przydzielając pracę inżynierom testowym, z jakichś powodów jeden z testerów zostaje zastąpiony innym. Tutaj plan testów jest aktualizowany.
Strategia testów określa podejście do testowania i wszystko, co go otacza. Różni się od planu testów w tym sensie, że strategia testów jest tylko podzbiorem planu testów. Jest to podstawowy dokument testowy, który jest w pewnym stopniu ogólny i statyczny. Istnieje również spór o to, na jakich poziomach stosowana jest strategia lub plan testów - ale naprawdę nie widzę żadnej wyraźnej różnicy.
Przykład: Plan testów zawiera informacje o tym, kto będzie testował w jakim czasie. Na przykład, Moduł 1 zostanie przetestowany przez „X tester”. Jeśli tester Y z jakiegoś powodu zastępuje X, plan testów musi zostać zaktualizowany.
Dokument planu testów
Plan testów to dokument, który zawiera pełne informacje na temat zadań testowania związanych z projektem oprogramowania. Zawiera szczegółowe informacje, takie jak zakres testowania, typy testów, cele, metodologia testów, wysiłek testowy, ryzyko i zdarzenia awaryjne, kryteria wydania, elementy dostarczane do testów itp. Śledzi możliwe testy, które zostaną uruchomione w systemie po zakodowaniu.
Plan testów ma się oczywiście zmienić. Początkowo projekt planu testów zostanie opracowany w oparciu o przejrzystość projektu w tym czasie. Ten wstępny plan będzie modyfikowany w miarę postępu projektu. Kierownik zespołu testowego lub Kierownik Testów może przygotować dokument planu testów. Opisuje Specyfikacje i na ich podstawie może ulec zmianie.
Co testować, kiedy testować, kto będzie testował i jak testować zostanie określone w planie testów. Plan testów uporządkuje listę problemów, zależności i podstawowych ryzyk.
Rodzaje planu testów
Plany testów mogą być różnego typu w zależności od etapu testowania. Początkowo będzie istniał główny plan testów dla całego wykonania projektu. Można tworzyć osobne plany testów dla określonych typów testów, takich jak testowanie systemu, testowanie integracji systemu, testowanie akceptacyjne użytkownika itp.
Innym podejściem jest posiadanie oddzielnych planów testów dla testów funkcjonalnych i niefunkcjonalnych. W przypadku tego podejścia testowanie będzie miało oddzielny plan testów.
Zawartość dokumentu planu testów ( Struktura planu testów IEEE-829 )
Trudno jest nakreślić jasny format planu testów. Format planu testów może się różnić w zależności od projektu. IEEE zdefiniowało standard dla planów testów, które są opisane jako struktura planu testów IEEE-829.
Poniżej znajdują się zalecenia IEEE dotyczące zawartości standardowego planu testów:
- Identyfikator planu testów
- Wprowadzenie
- Elementy testowe
- Problemy z ryzykiem oprogramowania
- Funkcje do przetestowania
- Funkcje, których nie należy testować
- Podejście
- Kryteria zaliczenia / niepowodzenia przedmiotu (lub) Kryteria przyjęcia
- Kryteria zawieszenia i wymagania dotyczące wznowienia
- Materiały testowe
- Zadania testowe
- Wymagania środowiskowe
- Potrzeby kadrowe i szkoleniowe
- Obowiązki
- Harmonogram
- Aprobaty
Sugerowany odczyt => Samouczek dotyczący planu testów - doskonały przewodnik
Strategia testów
Strategia testów to zbiór wytycznych, które wyjaśniają projekt testów i określają, w jaki sposób należy przeprowadzić testowanie.
Przykład: Strategia testów zawiera takie szczegóły, jak „Poszczególne moduły mają być testowane przez członków zespołu testowego”. W tym przypadku nie ma znaczenia, kto ją testuje - jest więc ogólna, a zmiana członka zespołu nie musi być aktualizowana, utrzymując ją statyczną.
wsparcie techniczne wywiad pytania i odpowiedzi pdf
Dokument strategii testów
Celem strategii testowania jest zdefiniowanie podejścia do testowania, typów testów, środowisk testowych i narzędzi, które mają być używane do testowania, a także ogólnych szczegółowych informacji o tym, jak strategia testów zostanie dopasowana do innych procesów. Dokument strategii testów ma być żywym dokumentem i zostanie zaktualizowany **, gdy uzyskamy większą jasność co do wymagań, parametrów SLA, środowiska testowego i podejścia do zarządzania kompilacją itp.
Strategia testów jest przeznaczona dla całego zespołu projektowego, który składa się ze sponsorów projektów, małych i średnich przedsiębiorstw biznesowych, rozwoju aplikacji / integracji, partnerów integracji systemów, zespołów konwersji danych, zespołów zajmujących się tworzeniem / wydaniem, takich jak kierownicy techniczni, kierownicy architektury oraz zespoły wdrożeniowe i infrastruktury.
** Niektórzy twierdzą, że raz zdefiniowana strategia testów nigdy nie powinna być aktualizowana. W większości projektów testowych jest zwykle aktualizowany w miarę postępu projektu.
Poniżej znajdują się ważne sekcje, które powinien zawierać dokument strategii testów:
1) Przegląd projektu
Ta sekcja może rozpocząć się od przedstawienia przeglądu organizacji, po którym następuje krótki opis projektu. Może zawierać poniższe szczegóły
- Jaka była potrzeba projektu?
- Jakie cele osiągnie projekt?
Tabela akronimów: Lepiej jest dołączyć tabelę ze akronimami, które czytelnik dokumentów może wymyślić, odwołując się do dokumentu.
# 2) Zakres wymagań
Zakres wymagań może obejmować zakres aplikacji i zakres funkcjonalny
Zakres zastosowania definiuje testowany system i wpływ na system wynikający z nowej lub zmienionej funkcjonalności. Można również zdefiniować powiązane systemy.
| System | Wpływ (nowa lub zmieniona funkcja) | Powiązany system |
|---|---|---|
| Opisuje, jak testować, kiedy testować, kto będzie testował, a co testować. | Opisuje, jakiego rodzaju techniki należy przestrzegać i który moduł przetestować. | |
| System A | Nowe ulepszenia i poprawki błędów | • System B • System C |
Zakres funkcjonalny określa wpływ na różne moduły w systemie. Tutaj zostanie wyjaśniony każdy powiązany system pod względem funkcjonalności.
| System | Moduł | Funkcjonalność | Powiązany system |
|---|---|---|---|
| System C | Moduł 1 | Funkcjonalność 1 | System B |
| Funkcjonalność 2 | System C |
# 3) Plan testów wysokiego poziomu
Plan testów to osobny dokument. W strategii testów można uwzględnić plan testów wysokiego poziomu. Plan testów wysokiego poziomu może obejmować cele testów i zakres testów. Zakres testów powinien określać zarówno działania w zakresie, jak i poza zakresem.
# 4) Podejście testowe
W tej sekcji opisano podejście do testowania, które będzie stosowane podczas cyklu życia testów.
Zgodnie z powyższym diagramem, testowanie zostanie przeprowadzone w dwóch fazach, tj. Strategia i planowanie testów oraz Wykonanie testów. Faza strategii i planowania testów będzie jednorazowa dla całego programu, podczas gdy fazy wykonywania testów będą powtarzane dla każdego cyklu całego programu. Powyższy diagram przedstawia różne etapy i rezultaty (wyniki) na każdym etapie podejścia wykonawczego.
Podejście testowe powinno obejmować poniższe podsekcje
a) Harmonogram testów: Wyjaśnij proponowany harmonogram projektu w tej podsekcji
b) Podejście do testów funkcjonalnych: Korzystanie z tej podsekcji zapewnia przegląd każdej fazy oraz odpowiednie kryteria wejścia i wyjścia. Różne fazy testowania to testy jednostkowe, testy systemowe, testy integracji systemu, testy akceptacji użytkowników i testy kompleksowe.
c) Testowanie kluczowych wskaźników wydajności:
- Priorytetyzacja przypadków testowych: Zdefiniuj podejście do priorytetyzacji przypadków testowych, aby w przypadku ograniczeń czasowych zespół testowy mógł wykonać scenariusze o wysokim priorytecie. Powinno istnieć porozumienie między interesariuszami projektu dotyczące ewentualnego ryzyka związanego z niewykonaniem wszystkich zaplanowanych scenariuszy.
- Priorytetyzacja defektów: Strategia ustalania priorytetów defektów to kolejny temat do omówienia. Zdefiniuj poziom priorytetu i podaj opis każdemu poziomowi, np. Krytyczny, wysoki, średni itp. Również
- Czas realizacji wady: Czas naprawy defektu definiuje się jako czas między pierwszym ujawnieniem wady a usunięciem wady i ponownym testem. Szybka realizacja zapewnia szybkie testowanie i przestrzeganie harmonogramu projektu. Dla każdego poziomu priorytetu defektów określ czas realizacji.
| Priorytetowy poziom | Czas realizacji wady |
|---|---|
| 1 - krytyczny | Czas odpowiedzi: 2 godziny lub mniej Poprawka gotowa do migracji: 1 dzień roboczy lub mniej |
# 5) Pokrycie testowe
W tej sekcji opisano procesy, które będzie wykonywał zespół ds. Zapewnienia jakości w celu optymalizacji pokrycia wymagań biznesowych / funkcjonalnych w scenariuszach testowych i przypadkach testowych. Macierz śledzenia wymagań: (RTM) może służyć do śledzenia wszystkich wymagań za pomocą odpowiednich scenariuszy testowych i przypadków testowych.
# 6) Środowisko testowe
Zdefiniuj różne dostępne środowiska kontroli jakości. Wspomnij, jakie testy będą wykonywane w jakim środowisku i przez kogo. Utwórz plan tworzenia kopii zapasowych środowiska, aby zająć się sytuacjami awaryjnymi. Dostęp do każdego środowiska powinien być regulowany i jasno określany.
W tej sekcji można również wspomnieć o narzędziach testujących, które będą używane.
| Czynność | Narzędzie | Uwagi |
|---|---|---|
| Zarządzanie testami | HP ALM | Podaj powód używania tego narzędzia |
| Zarządzanie defektami | JIRA | Podaj powód używania tego narzędzia |
# 7) Elementy dostarczane i metryki kontroli jakości
Wypisz wszystkie elementy zapewniające kontrolę jakości
| S. Nie. | Dostarczalne |
|---|---|
| 1 | Dokument strategii testów |
| dwa | Macierz śledzenia wymagań |
| 3 | Skrypty testowe ST |
| 4 | Raport podsumowujący test |
| 5 | Lista scenariuszy kwalifikujących się do automatyzacji |
Wypisz wszystkie wskaźniki kontroli jakości
| # | Nazwa metryki | Definicja danych | Wzór metryczny | Metryczna jednostka miary | Raporty, w których metryki mają być użyte |
|---|---|---|---|---|---|
| 1 | Wskaźniki pokrycia wymagań (RCM) | Pokrycie wymagań przez kontrolę jakości | Stosunek liczby przetestowanych wymagań do liczby zidentyfikowanych wymagań | % | Cotygodniowy raport o stanie kontroli jakości, Podsumowanie testu |
| dwa | Pokrycie testowe | Pokrycie wykonanego przypadku testowego | Stosunek liczby wykonanych przypadków testowych do liczby zaplanowanych przypadków testowych | % | Raport dziennej realizacji, Cotygodniowy raport o stanie kontroli jakości, Podsumowanie testu |
# 8) Zarządzanie defektami
Jasno zdefiniuj strategię zarządzania defektami, tworząc przepływ pracy, metodologię śledzenia defektów i proces segregacji defektów. Wspomnij o odpowiedzialności za defekty dla ról każdego testera. Okresowa analiza defektów i analiza przyczyn źródłowych poprawią ogólną jakość testowania
# 9) Zarządzanie komunikacją
Ustal wytyczne dotyczące raportów o stanie, spotkań dotyczących stanu i komunikacji na miejscu i na morzu.
# 10) Założenia, ryzyko i zależności
Opisz założenia, na których opiera się projekt. Mogą to być czasy, zasoby i możliwości systemu. Opisz wszelkie zależności, takie jak inne projekty, dostępność tymczasowych zasobów, inne terminy, które mogą mieć wpływ na projekt
# 11) Dodatek
W tej sekcji uwzględnij takie kwestie, jak role i obowiązki, strefa czasu pracy i referencje
Dalsza lektura=> Przewodnik po piśmie dobrej strategii testowej .
Plan testów a strategia testów
| PLAN BADAŃ | STRATEGIA TESTOWA |
|---|---|
| Wywodzi się ze specyfikacji wymagań oprogramowania (SRS). | Pochodzi z dokumentu wymagań biznesowych (BRS). |
| Jest przygotowywany przez lidera testów lub menedżera. | Jest opracowywany przez kierownika projektu lub analityka biznesowego. |
| Identyfikator planu testów, funkcje do przetestowania, techniki testowania, zadania testowe, kryteria zaliczenia lub niepowodzenia funkcji, rezultaty testów, obowiązki i harmonogram itp. To elementy planu testów. | Cele i zakres, formaty dokumentacji, procesy testowe, struktura raportowania zespołu, strategia komunikacji z klientem itp. To elementy składowe strategii testów. |
| Jeśli pojawi się nowa funkcja lub nastąpi zmiana w wymaganiu, dokument planu testów zostanie zaktualizowany. | Strategia testów zachowuje standardy podczas przygotowywania dokumentu. Jest również nazywany dokumentem statycznym. |
| Plan testów możemy przygotować indywidualnie. | W mniejszych projektach strategia testów jest często częścią planu testów. |
| Plan testów możemy przygotować na poziomie projektu. | Strategię testów możemy wykorzystać w wielu projektach. |
| Możemy opisać specyfikacje za pomocą planu testów. | Strategia testów opisuje ogólne podejścia. |
| Plan testów zmieni się w trakcie trwania projektu. | Strategia testów zazwyczaj nie zmienia się po zatwierdzeniu. |
| Plan testów jest zapisywany po podpisaniu wymagań. | Strategia testów jest tworzona przed planem testów. |
| Plany testów mogą być różnych typów. Będzie istniał główny plan testów i oddzielny plan testów dla różnych typów testów, takich jak plan testów systemu, plan testów wydajnościowych itp. | Dla projektu będzie tylko jeden dokument dotyczący strategii testów. |
| Plan testów powinien być jasny i zwięzły. | Strategia testowania zawiera ogólne wskazówki dotyczące projektu. |
Różnica między tymi dwoma dokumentami jest subtelna. Strategia testów to statyczny dokument wysokiego poziomu dotyczący projektu. Z drugiej strony plan testów będzie określał, co testować, kiedy i jak testować.
Różnica między przypadkiem testowym a skryptem testowym
Moim zdaniem tych dwóch terminów można używać zamiennie. Tak, mówię, że nie ma różnicy. Przypadek testowy to sekwencja kroków, które pomagają nam wykonać określony test aplikacji. Skrypt testowy to również to samo.
Istnieje jedna szkoła myślenia, że przypadek testowy jest terminem używanym w środowisku testowania ręcznego, a skrypt testowy jest używany w środowisku automatyzacji. Po części jest to prawda, ze względu na poziom komfortu testerów w poszczególnych dziedzinach, a także na to, jak narzędzia odnoszą się do testów (niektóre wywołują skrypty testowe, a niektóre - przypadki testowe).
W efekcie zarówno skrypt testowy, jak i przypadek testowy to kroki, które należy wykonać w aplikacji w celu sprawdzenia jej funkcjonalności, czy to ręcznie, czy za pomocą automatyzacji.
Dalsza lektura=> Jak pisać skuteczne przypadki testowe? i Przykładowy szablon przypadku testowego .
| PRZYPADEK TESTOWY | SKRYPT TESTOWY |
|---|---|
| Jest to podstawowa forma testowania aplikacji po kolei. | Po opracowaniu skrypt będzie go uruchamiał wielokrotnie, aż do zmiany wymagań. |
| Jest to procedura krok po kroku używana do testowania aplikacji | Jest to zestaw instrukcji do automatycznego testowania aplikacji. |
| Termin przypadek testowy jest używany w ręcznym środowisku testowym. | Termin skrypt testowy jest używany w środowisku testowania automatyzacji. |
| Odbywa się to ręcznie. | Odbywa się to poprzez format skryptów. |
| Jest rozwijany w formie szablonów. | Jest rozwijany w formie skryptów. |
| Szablon przypadku testowego zawiera identyfikator kombinezonu testowego, dane testowe, procedurę testową, rzeczywiste wyniki, oczekiwane wyniki itp. | W Test Scripcie możemy używać różnych poleceń do tworzenia skryptu. |
| Służy do testowania aplikacji. | Służy również do testowania aplikacji. |
| Przykład: Musimy zweryfikować przycisk logowania w aplikacji, Kroki obejmują: a) Uruchom aplikację. b) Sprawdź, czy przycisk logowania jest wyświetlany, czy nie. | Przykład: Chcemy kliknąć przycisk obrazu w aplikacji. Skrypt zawiera: a) Kliknij przycisk Obraz. |
Różnica między scenariuszem testowym a warunkami testowymi
Scenariusz testowy: Jest to sposób na zdefiniowanie wszystkich możliwych sposobów testowania aplikacji. Jest to jedno oświadczenie obejmujące wszystkie możliwe sposoby testowania aplikacji.
Stan testu: Warunek Testu to specyfikacja, której tester musi przestrzegać, aby przetestować Aplikację.
Jest to jednowierszowy wskaźnik, który testerzy tworzą jako początkowy, przejściowy krok w fazie projektowania testów. Jest to przeważnie jednowierszowa definicja „Co” będziemy testować w odniesieniu do określonej funkcji. Zwykle scenariusze testowe są danymi wejściowymi do tworzenia przypadków testowych.
W projektach zwinnych scenariusze testowe są jedynymi danymi wyjściowymi projektu testów i nie są pisane żadne przypadki testowe. Scenariusz testowy może skutkować wieloma testami.
Przykłady scenariuszy testowych:
- Sprawdź, czy administrator może dodać nowy kraj
- Sprawdź, czy istniejący kraj może zostać usunięty przez administratora
- Sprawdź, czy można zaktualizować istniejący kraj
Z drugiej strony warunki testu są bardziej szczegółowe. Można to z grubsza zdefiniować jako cel / cel pewnego testu.
Przykładowe warunki testowe: W powyższym przykładzie, gdybyśmy mieli przetestować scenariusz 1, możemy przetestować następujące warunki:
- Wpisz nazwę kraju jako „Indie” (poprawna) i sprawdź, czy dodano kraj
- Wpisz puste miejsce i sprawdź, czy kraj zostanie dodany.
- W każdym przypadku szczegółowe dane są opisane, a cel testu jest znacznie bardziej precyzyjny.
Dalsza lektura=> Ponad 180 przykładowych scenariuszy testowych do testowania aplikacji internetowych i komputerowych.
| SCENARIUSZ TESTOWY | WARUNEK BADANIA |
|---|---|
| Oto jednowierszowe stwierdzenia wyjaśniające, co zamierzamy przetestować. | Warunek testu opisuje główny cel testowania aplikacji. |
| Jest to proces testowania aplikacji na wszystkie możliwe sposoby. | Warunki testowe to statyczne reguły, których należy przestrzegać podczas testowania aplikacji. |
| Scenariusze testowe są danymi wejściowymi do tworzenia przypadków testowych. | Daje główny cel, aby przetestować aplikację. |
| Scenariusz testowy obejmuje wszystkie możliwe przypadki testowania aplikacji. | Warunki testu są bardzo specyficzne. |
| Zmniejsza złożoność. | To sprawia, że system jest wolny od błędów. |
| Scenariusz testowy może obejmować pojedynczy przypadek testowy lub grupę przypadków testowych. | Taki jest cel przypadków testowych. |
| Pisząc scenariusze, łatwo będzie zrozumieć funkcjonalność aplikacji. | Warunki testu są bardzo specyficzne. |
| Przykładowe scenariusze testowe: # 1) Sprawdź, czy administrator może dodać nowy kraj. # 2) Sprawdź, czy istniejący kraj może zostać usunięty przez administratora. # 3) Sprawdź, czy można zaktualizować istniejący kraj. | Przykładowe warunki testu: # 1) Wpisz nazwę kraju jako „Indie” i sprawdź, czy dodano kraj. # 2) Pozostaw puste pola i sprawdź, czy kraj został dodany. |
Różnica między procedurą testową a zestawem testów
Procedura testowa jest połączeniem przypadków testowych opartych na pewnym logicznym uzasadnieniu, takim jak wykonanie całościowej sytuacji lub coś w tym rodzaju. Kolejność, w jakiej mają być uruchamiane przypadki testowe, jest ustalona.
Procedura testowa: To nic innego jak cykl życia testu. Cykl życia testowania składa się z 10 kroków.
Oni są:
- Szacowanie wysiłku
- Rozpoczęcie projektu
- Badanie systemu
- Plan testów
- Zaprojektuj przypadek testowy
- Automatyzacja testów
- Wykonaj przypadki testowe
- Zgłoś usterki
- Testowanie regresji
- Analiza i raport podsumowujący
Na przykład , gdybym miał przetestować wysyłanie wiadomości e-mail z Gmail.com, kolejność przypadków testowych, które połączyłbym w procedurę testową, byłaby następująca:
- Test sprawdzający login
- Test tworzenia wiadomości e-mail
- Test polegający na dołączeniu jednego / więcej załączników
- Sformatowanie wiadomości e-mail w wymagany sposób przy użyciu różnych opcji
- Dodawanie kontaktów lub adresów e-mail do pól Do, UDW, DW
- Wysyłanie wiadomości e-mail i upewnianie się, że jest ona wyświetlana w sekcji „Wysłane”
Wszystkie powyższe przypadki testowe są zgrupowane w celu osiągnięcia określonego celu na ich końcu. Ponadto procedury testowe obejmują kilka przypadków testowych połączonych w dowolnym momencie.
Z drugiej strony zestaw testów to lista wszystkich przypadków testowych, które muszą zostać wykonane jako część cyklu testowego lub fazy regresji, itp. Nie ma logicznego grupowania na podstawie funkcjonalności. Kolejność wykonywania przypadków testowych składowych może być ważna lub nie.
Pakiet testowy: Pakiet testów to kontener zawierający zestaw testów, które pomagają testerom w wykonywaniu i raportowaniu stanu wykonania testów. Może przyjąć dowolny z trzech stanów, tj. Aktywny, w toku i ukończony.
Przykład zestawu testów : Jeśli aktualna wersja aplikacji to 2.0. Poprzednia wersja 1.0 mogła mieć 1000 przypadków testowych do całkowitego przetestowania. W wersji 2 istnieje 500 przypadków testowych, aby po prostu przetestować nową funkcjonalność dodaną w nowej wersji.
Tak więc obecny zestaw testów obejmowałby 1000 + 500 przypadków testowych, które obejmują zarówno regresję, jak i nową funkcjonalność. Zestaw też jest kombinacją, ale nie dążymy do osiągnięcia celu.
Zestawy testów mogą zawierać 100, a nawet tysiące przypadków testowych.
| PROCEDURA TESTOWA | ZESTAW TESTOWY |
|---|---|
| Tworzenie procedur testowych opiera się na przeprowadzaniu testów od końca do końca. | Zestawy testów są tworzone w oparciu o cykl lub zakres. |
| Jest to połączenie przypadków testowych do testowania aplikacji. | Jest to grupa przypadków testowych do testowania aplikacji. |
| Jest to logiczne zgrupowanie oparte na funkcjonalności. | Nie ma logicznego grupowania na podstawie funkcjonalności. |
| Procedury testowe są produktami dostarczanymi w procesie tworzenia oprogramowania. | Jest wykonywany jako część cyklu testowego lub regresji. |
| Kolejność wykonania jest ustalona. | Kolejność wykonania może nie mieć znaczenia. |
| Procedura testowa obejmuje przypadki testowe od końca do końca. | Zestaw testów zawiera wszystkie nowe funkcje i przypadki testowe regresji. |
| Procedury testowe są kodowane w nowym języku o nazwie TPL (język procedur testowych). | Zestaw testów zawiera ręczne przypadki testowe lub skrypty automatyzacji. |
Wniosek
Koncepcje testowania oprogramowania odgrywają ważną rolę w cyklu życia testowania oprogramowania.
Dokładne zrozumienie omówionych powyżej koncepcji wraz z ich porównaniem jest bardzo ważne dla każdego Testera Oprogramowania, aby skutecznie przeprowadzić proces testowania.
Zazwyczaj takie artykuły są doskonałym punktem wyjścia do głębszych dyskusji. Dlatego prosimy o podzielenie się swoimi przemyśleniami, umowami, nieporozumieniami i wszystkim innym w komentarzach poniżej. Czekamy na Twoją opinię.
Czekamy również na Twoje pytania dotyczące testowania oprogramowania w ogóle lub cokolwiek związanego z Twoją karierą testera. Bardziej szczegółowo zajmiemy się nimi w nadchodzących postach z tej samej serii.
Miłego czytania !!
jak program komputerowy dla początkujących
=> Odwiedź tutaj, aby zapoznać się z pełną serią samouczków dotyczących planu testów
POPRZEDNIA samouczek | NEXT Tutorial
rekomendowane lektury
- Samouczek dotyczący planu testów: przewodnik dotyczący pisania dokumentu planu testów oprogramowania od podstaw
- Jak napisać dokument dotyczący strategii testów (z przykładowym szablonem strategii testów)
- Jak przygotować się do pisania przypadków testowych (Porady dotyczące produktywności)
- Co to jest scenariusz testowy: szablon scenariusza testowego z przykładami
- Różnica między planem testów wydajnościowych a strategią testów wydajnościowych
- Jak pisać przypadki testowe: najlepszy przewodnik z przykładami
- Przykładowy szablon planu testów oprogramowania z formatem i zawartością
- Scenariusz testowy kontra Przypadek testowy: Jaka jest różnica między nimi?