Co to jest testowanie regresji? Definicja, narzędzia, metoda i przykład

what is regression testing

Co to jest testowanie regresji?

Testowanie regresyjne to rodzaj testów wykonywanych w celu sprawdzenia, czy zmiana kodu w oprogramowaniu nie wpływa na istniejącą funkcjonalność produktu. Ma to na celu upewnienie się, że produkt działa dobrze z nowymi funkcjami, poprawkami błędów lub wszelkimi zmianami w istniejącej funkcji. Wcześniej wykonane przypadki testowe są ponownie wykonywane w celu sprawdzenia wpływu zmiany.

=> Kliknij tutaj, aby uzyskać pełną serię samouczków dotyczących planu testów

Testy regresyjne to rodzaj testowania oprogramowania, w którym przypadki testowe są ponownie wykonywane w celu sprawdzenia, czy poprzednia funkcjonalność aplikacji działa poprawnie, a nowe zmiany nie wprowadziły żadnych nowych błędów.

Ten test można przeprowadzić na nowej kompilacji, gdy nastąpi znacząca zmiana w oryginalnej funkcjonalności, nawet w przypadku jednej poprawki błędu.

Regresja oznacza ponowne przetestowanie niezmienionych części aplikacji.

Czego się nauczysz:

• Samouczki omówione w tej serii
• Przegląd testu regresji
• Kiedy wykonać ten test?
• Czy testy regresji można przeprowadzić ręcznie?
• Narzędzia do automatycznego testowania regresji
• Dlaczego test regresji?
• Rodzaje testów regresji
  • # 1) Regresja jednostek
  • # 2) Częściowa regresja
  • # 3) Pełna regresja
• Ile regresji jest wymagana?
• Co robimy podczas sprawdzania regresji?
• Techniki testowania regresji
  • # 1) Przetestuj ponownie wszystko
  • # 2) Wybór testu regresji
  • # 3) Priorytetyzacja przypadków testowych
  • # 4) Hybryda
• Jak wybrać zestaw testów regresji?
• Jak przeprowadzić testy regresji?
• Regresja w Agile
  • 1) Regresja na poziomie sprintu
  • # 2) Regresja od końca do końca
• Zalety
• Niedogodności
• Regresja aplikacji GUI
• Różnica między regresją a ponownym testowaniem
• Szablon planu testów regresji (TOC)
  • # 1) Historia dokumentu
  • # 2) Odniesienia
  • # 3) Plan testów regresji
  • # 4) Zatwierdzenie / akceptacja
• Wniosek
• rekomendowane lektury

Samouczki omówione w tej serii

Samouczek nr 1: Co to jest testowanie regresji (Ten samouczek)
Samouczek nr 2: Narzędzia do testów regresji
Samouczek nr 3: Przetestuj ponownie testy regresji
Samouczek nr 4: Zautomatyzowane testy regresyjne w Agile

Przegląd testu regresji

Test regresji jest jak metoda weryfikacji. Przypadki testowe są generalnie zautomatyzowane, ponieważ przypadki testowe muszą być wykonywane wielokrotnie, a wielokrotne ręczne uruchamianie tych samych przypadków testowych jest również czasochłonne i żmudne.

Na przykład, Rozważmy produkt X, w którym jedną z funkcji jest wywołanie potwierdzenia, akceptacji i wysłania wiadomości e-mail po kliknięciu przycisków Potwierdź, Akceptuj i Wyślij.

W wiadomości e-mail z potwierdzeniem pojawia się jakiś problem i aby to naprawić, wprowadzono pewne zmiany w kodzie. W takim przypadku należy przetestować nie tylko wiadomości e-mail z potwierdzeniem, ale także e-maile dotyczące akceptacji i wysłania, aby upewnić się, że zmiana w kodzie nie wpłynęła na nie.

Testowanie regresyjne nie jest zależne od żadnego języka programowania, takiego jak Java, C ++, C # itp. Jest to metoda testowania, która jest używana do testowania produktu pod kątem modyfikacji lub aktualizacji. Sprawdza, czy jakakolwiek modyfikacja produktu nie wpływa na istniejące moduły produktu.

Weryfikacja, czy błędy zostały naprawione, a nowo dodane funkcje nie spowodowały żadnego problemu w poprzedniej działającej wersji oprogramowania.

Testerzy przeprowadzają testy funkcjonalne, gdy nowa kompilacja jest dostępna do weryfikacji. Celem tego testu jest weryfikacja zmian wprowadzonych w istniejącej funkcjonalności, a także nowo dodanej funkcjonalności.

Po wykonaniu tego testu tester powinien zweryfikować, czy istniejąca funkcjonalność działa zgodnie z oczekiwaniami, a nowe zmiany nie wprowadziły żadnej usterki w funkcjonalności działającej przed tą zmianą.

Test regresji powinien być częścią cyklu wydania i musi być uwzględniony przy szacowaniu testu.

Kiedy wykonać ten test?

Testowanie regresyjne jest zwykle wykonywane po weryfikacji zmian lub nowej funkcjonalności. Ale nie zawsze tak jest. W przypadku wydania, którego ukończenie trwa miesiące, testy regresji muszą zostać włączone do codziennego cyklu testów. W przypadku wydań cotygodniowych testy regresji można przeprowadzić po zakończeniu testów funkcjonalnych zmian.

Sprawdzanie regresji jest odmianą ponownego testu (który polega po prostu na powtórzeniu testu). Podczas ponownego testowania powodem może być wszystko. Powiedzmy, że testowałeś konkretną funkcję i to był koniec dnia - nie mogłeś zakończyć testów i musiałeś zatrzymać proces bez decydowania, czy test przeszedł / nie powiódł się.

Następnego dnia po powrocie wykonujesz test jeszcze raz - oznacza to, że powtarzasz test, który wykonałeś wcześniej. Prostą czynnością powtórzenia testu jest powtórny test.

Podstawą testu regresji jest swego rodzaju retest. Tylko na specjalną okazję coś się zmieniło w aplikacji / kodzie. Może to być kod, projekt lub cokolwiek innego, co dyktuje ogólną strukturę systemu.

Retest przeprowadzany w tej sytuacji w celu upewnienia się, że wspomniana zmiana nie wpłynęła na nic, co już działało wcześniej, nazywa się Testem Regresyjnym. Najczęstsze powody, dla których może to zostać przeprowadzone, to fakt, że zostały utworzone nowe wersje kodu (zwiększenie zakresu / wymagań) lub naprawiono błędy.

Czy testy regresji można przeprowadzić ręcznie?

Właśnie uczyłem jeden z tych dni na mojej klasie i przyszło mi do głowy pytanie - „Czy można wykonać regresję ręcznie?”

Odpowiedziałem na pytanie i ruszyliśmy dalej w klasie. Wszystko wydawało się w porządku, ale jakoś to pytanie dręczyło mnie trochę później.

W wielu partiach to pytanie pojawia się wiele razy na różne sposoby. Niektórzy z nich są:

• Czy do wykonania testu potrzebujemy narzędzia?
• Jak przeprowadzane są testy regresji?
• Nawet po całej rundzie testów - nowicjuszom trudno jest określić, czym dokładnie jest test regresji?

I oczywiście oryginalne pytanie:

• Czy to badanie można przeprowadzić ręcznie?

Najpierw, Wykonanie testów jest prostą czynnością polegającą na użyciu przypadków testowych i wykonaniu tych kroków na AUT, dostarczeniu danych testowych i porównaniu wyniku uzyskanego w AUT z oczekiwanym wynikiem wymienionym w przypadkach testowych.

W zależności od wyniku porównania, ustawiamy stan testu pozytywnego / negatywnego. Wykonanie testów jest tak proste, że do tego procesu nie są potrzebne żadne specjalne narzędzia.

Narzędzia do automatycznego testowania regresji

Zautomatyzowany test regresji to obszar testowy, w którym możemy zautomatyzować większość prac testowych. Uruchamiamy wszystkie wcześniej wykonane przypadki testowe na nowej kompilacji.

Oznacza to, że mamy dostępny zestaw przypadków testowych, a ręczne uruchamianie tych przypadków testowych jest czasochłonne. Znamy oczekiwane wyniki, więc automatyzacja tych przypadków testowych oszczędza czas i jest wydajną metodą testów regresji. Zakres automatyzacji zależy od liczby przypadków testowych, które będą nadal obowiązywać w godzinach nadliczbowych.

Jeśli przypadki testowe zmieniają się od czasu do czasu, zakres aplikacji rośnie, a automatyzacja procedury regresji będzie stratą czasu.

Większość narzędzi do testów regresji to narzędzia do nagrywania i odtwarzania. Będziesz rejestrować przypadki testowe, przechodząc przez AUT (testowaną aplikację) i sprawdzając, czy oczekiwane wyniki nadchodzą, czy nie.

Przybory

• Selen
• Catalog Studio
• AdventNet QEngine
• Tester regresji
• vTest
• woda
• actiWate
• Rational Functional Tester
• SilkTest
• TimeShiftX

Większość z nich to narzędzia do testów funkcjonalnych i regresji.

Zalecana lektura => Sprawdź tutaj listę najlepszych narzędzi regresji

Dodawanie i aktualizowanie przypadków testowych regresji w zestawie testów automatyzacji jest uciążliwym zadaniem. Wybierając narzędzie automatyzacji do testów regresyjnych, należy sprawdzić, czy narzędzie umożliwia łatwe dodawanie lub aktualizowanie przypadków testowych.

oprogramowanie do łamania haseł dla systemu Windows 7

W większości przypadków musimy często aktualizować automatyczne przypadki testowe regresji ze względu na częste zmiany w systemie.

OBEJRZYJ WIDEO

Bardziej szczegółowe wyjaśnienie definicji wraz z przykładem można znaleźć poniżejFilm z testu regresji:

Dlaczego test regresji?

Regresja jest inicjowana, gdy programista naprawi jakikolwiek błąd lub doda nowy kod dla nowej funkcjonalności do systemu.

W nowo dodanej i istniejącej funkcjonalności może istnieć wiele zależności.

Jest to miara jakości polegająca na sprawdzeniu, czy nowy kod jest zgodny ze starym kodem, tak aby nie wpływać na kod niezmodyfikowany. W większości przypadków zespół testowy ma za zadanie sprawdzić ostatnie zmiany w systemie.

W takiej sytuacji testowanie tylko obszaru aplikacji, którego dotyczy problem, jest konieczne, aby zakończyć proces testowania na czas, obejmując wszystkie główne aspekty systemu.

Ten test jest bardzo ważny, gdy do aplikacji dodawane są ciągłe zmiany / ulepszenia. Nowa funkcjonalność nie powinna negatywnie wpływać na istniejący testowany kod.

Regresja jest wymagana, aby znaleźć błędy, które wystąpiły z powodu zmiany w kodzie. Jeśli te testy nie zostaną wykonane, produkt może napotkać krytyczne problemy w aktywnym środowisku, co rzeczywiście może doprowadzić klienta do kłopotów.

Podczas testowania dowolnej witryny internetowej tester zgłasza problem polegający na tym, że Cena Produktu nie jest wyświetlana poprawnie, tj. Pokazuje cenę niższą niż rzeczywista cena Produktu i należy ją wkrótce naprawić.

Gdy programista naprawi problem, należy go ponownie przetestować. Wymagane są również testy regresyjne, ponieważ weryfikacja ceny na zgłoszonej stronie zostałaby poprawiona, ale mogłaby pokazywać nieprawidłową cenę na stronie podsumowania, na której wyświetlana jest suma z innymi opłatami lub poczta wysłana do klienta nadal ma nieprawidłową cenę.

Teraz w takim przypadku klient będzie musiał ponieść stratę, jeśli te testy nie zostaną przeprowadzone, ponieważ witryna oblicza całkowity koszt z nieprawidłową ceną, a ta sama cena jest wysyłana do klienta pocztą elektroniczną. Gdy klient zaakceptuje produkt, zostanie sprzedany online po niższej cenie, będzie to dla klienta strata.

Tak więc to testowanie odgrywa dużą rolę i jest również bardzo wymagane i ważne.

Rodzaje testów regresji

Poniżej podano różne typy regresji:

• Regresja jednostkowa
• Częściowa regresja
• Pełna regresja

# 1) Regresja jednostek

Regresja jednostek jest wykonywana podczas Testów jednostkowych faza i kod są testowane oddzielnie, tj. wszelkie zależności od testowanej jednostki są blokowane, aby jednostka mogła być testowana indywidualnie bez żadnych rozbieżności.

# 2) Częściowa regresja

Regresja częściowa ma na celu sprawdzenie, czy kod działa poprawnie, nawet jeśli zmiany zostały wprowadzone w kodzie, a jednostka jest zintegrowana z niezmienionym lub już istniejącym kodem.

# 3) Pełna regresja

Pełna regresja jest wykonywana, gdy zmiana w kodzie jest wykonywana na wielu modułach, a także, jeśli wpływ zmiany w jakimkolwiek innym module jest niepewny. Produkt jako całość jest poddawany regresji, aby sprawdzić wszelkie zmiany spowodowane zmienionym kodem.

Ile regresji jest wymagana?

Zależy to od zakresu nowo dodanych funkcji.

Jeśli zakres poprawki lub funkcji jest zbyt duży, obszar aplikacji, na który ma to wpływ, jest również dość duży i testy należy przeprowadzić dokładnie, uwzględniając wszystkie przypadki testowe aplikacji. Można to jednak skutecznie zadecydować, gdy tester otrzyma informacje od programisty dotyczące zakresu, natury i ilości zmian.

Ponieważ są to testy powtarzalne, przypadki testowe można zautomatyzować, dzięki czemu zestaw samych przypadków testowych można łatwo wykonać w nowej kompilacji.

Przypadki testowe regresji należy wybierać bardzo ostrożnie, aby zapewnić maksymalną funkcjonalność w minimalnym zestawie przypadków testowych. Te zestawy przypadków testowych wymagają ciągłych ulepszeń dla nowo dodanych funkcji.

Staje się to bardzo trudne, gdy zakres aplikacji jest bardzo duży i występują ciągłe przyrosty lub poprawki do systemu. W takich przypadkach należy przeprowadzić testy selektywne, aby zaoszczędzić czas i koszt testowania. Te selektywne przypadki testowe są wybierane na podstawie ulepszeń wprowadzonych w systemie i części, na które może mieć największy wpływ.

Co robimy podczas sprawdzania regresji?

• Ponownie uruchom wcześniej przeprowadzone testy
• Porównaj bieżące wyniki z wynikami wcześniej wykonanych testów

Jest to ciągły proces wykonywany na różnych etapach w całym cyklu testowania oprogramowania.

Najlepszą praktyką jest przeprowadzenie testu regresji po Testy poczytalności lub dymu i na koniec testów funkcjonalnych dla krótkiego wydania.

Aby przeprowadzić skuteczne testy, regresja Plan testów powinien zostać utworzony. Plan ten powinien określać strategię testowania regresji i kryteria wyjścia. Testowanie wydajności jest również częścią tego testu, aby upewnić się, że na wydajność systemu nie wpłyną zmiany wprowadzone w komponentach systemu.

Najlepsze praktyki : Codziennie wieczorem uruchamiaj zautomatyzowane przypadki testowe, aby wszelkie skutki uboczne regresji można było naprawić w kompilacji następnego dnia. W ten sposób zmniejsza ryzyko wydania, pokrywając prawie wszystkie defekty regresji na wczesnym etapie, zamiast znajdować i naprawiać je na końcu cyklu wydawania.

Techniki testowania regresji

Poniżej podano różne techniki.

• Przetestuj ponownie wszystko
• Wybór testu regresji
• Priorytetyzacja przypadków testowych
• Hybrydowy

# 1) Przetestuj ponownie wszystko

Jak sama nazwa wskazuje, całe przypadki testowe w zestawie testów są ponownie wykonywane, aby upewnić się, że nie ma błędów, które wystąpiły z powodu zmiany w kodzie. Jest to kosztowna metoda, ponieważ wymaga więcej czasu i zasobów w porównaniu z innymi technikami.

# 2) Wybór testu regresji

W tej metodzie przypadki testowe są wybierane z zestawu testów do ponownego wykonania. Nie cały pakiet jest ponownie wykonywany. Wybór przypadków testowych odbywa się na podstawie zmiany kodu w module.

Przypadki testowe są podzielone na dwie kategorie, jedna to Przypadki testowe wielokrotnego użytku, a druga to Przestarzałe przypadki testowe. Przypadki testowe wielokrotnego użytku mogą być używane w przyszłych cyklach regresji, podczas gdy przestarzałe nie są używane w nadchodzących cyklach regresji.

# 3) Priorytetyzacja przypadków testowych

Przypadki testowe o wysokim priorytecie są wykonywane jako pierwsze niż przypadki o średnim i niskim priorytecie. Priorytet przypadku testowego zależy od jego krytyczności i wpływu na produkt, a także od funkcjonalności produktu, który jest częściej używany.

# 4) Hybryda

Technika hybrydowa to połączenie wyboru testu regresji i priorytetyzacji przypadków testowych. Zamiast wybierać cały zestaw testów, wybierz tylko te przypadki testowe, które są ponownie wykonywane w zależności od ich priorytetu.

Jak wybrać zestaw testów regresji?

Większość błędów wykrytych w środowisku produkcyjnym wynika z wprowadzonych zmian lub błędów naprawionych na jedenastej godzinie, czyli zmiany wprowadzone na późniejszym etapie. Poprawka błędu na ostatnim etapie może spowodować inne problemy / błędy w Produkcie. Dlatego sprawdzanie regresji jest bardzo ważne przed wydaniem produktu.

Poniżej znajduje się lista przypadków testowych, które można wykorzystać podczas wykonywania tego testu:

• Funkcjonalności, które są często używane.
• Przypadki testowe obejmujące moduł, w którym wprowadzono zmiany.
• Złożone przypadki testowe.
• Przypadki testowe integracji, które obejmują wszystkie główne komponenty.
• Przypadki testowe dotyczące podstawowej funkcjonalności lub cechy Produktu.
• Należy uwzględnić przypadki testowe o priorytecie 1 i priorytecie 2.
• Przypadki testowe, które często kończą się niepowodzeniem lub ostatnie defekty testów, zostały znalezione w tym samym.

Jak przeprowadzić testy regresji?

Teraz, gdy ustaliliśmy, co oznacza regresja, widać, że testuje ona również - po prostu powtarzając w określonej sytuacji z określonego powodu. Dlatego możemy bezpiecznie wywnioskować, że ta sama metoda ma zastosowanie do testowania w pierwszej kolejności można zastosować również do tego.

Dlatego też, jeśli testowanie można wykonać ręcznie, to może być również testowanie regresyjne. Użycie narzędzia nie jest konieczne. Jednak z biegiem czasu aplikacje są coraz bardziej funkcjonalne, co stale zwiększa zakres regresji. Aby jak najlepiej wykorzystać ten czas, ten test jest najczęściej zautomatyzowany .

Poniżej podano różne etapy wykonywania tego testu

• Przygotuj zestaw testów do regresji, uwzględniając punkty wymienione w „Jak wybrać zestaw testów regresji”?
• Zautomatyzuj wszystkie przypadki testowe zestawu testów.
• Zaktualizuj zestaw regresji, gdy jest to wymagane, na przykład w przypadku znalezienia nowego defektu, który nie jest objęty przypadkiem testowym, a przypadek testowy dla tego samego powinien zostać zaktualizowany w zestawie testów, aby testy nie zostały pominięte w tym samym przypadku następnym razem . Zestaw testów regresyjnych powinien być właściwie zarządzany poprzez ciągłe aktualizowanie przypadków testowych.
• Wykonuj przypadki testowe regresji za każdym razem, gdy nastąpi jakakolwiek zmiana w kodzie, błąd zostanie naprawiony, zostanie dodana nowa funkcjonalność, dokonane zostanie ulepszenie istniejącej funkcjonalności itp.
• Utwórz raport z wykonania testu, który zawiera stan pomyślny / niepowodzenie wykonanych przypadków testowych.

Na przykład:

Pozwólcie, że wyjaśnię to na przykładzie. Proszę przeanalizować poniższą sytuację:

Poniżej przedstawiono obserwacje, jakie możemy poczynić z powyższej sytuacji:

• Wraz ze wzrostem wydań rośnie funkcjonalność.
• Czas rozwoju niekoniecznie rośnie wraz z wydaniami, ale czas testowania tak
• Żadna firma / jej zarząd nie będzie gotowa poświęcić więcej czasu na testowanie, a mniej na rozwój
• Nie możemy nawet skrócić czasu potrzebnego na testowanie, zwiększając liczebność zespołu testowego, ponieważ więcej osób oznacza więcej pieniędzy, a nowi ludzie również oznaczają dużo szkoleń, a może także kompromis w zakresie jakości, ponieważ nowi ludzie mogą nie odpowiadać wymaganej wiedzy poziomy natychmiast.
• Inną możliwością jest oczywiście ograniczenie regresji. Ale może to być ryzykowne dla oprogramowania.

Z tych wszystkich powodów testowanie regresyjne jest dobrym kandydatem do testów automatycznych, ale nie musi być wykonywane tylko w ten sposób.

Podstawowe kroki przeprowadzania testów regresji

Za każdym razem, gdy oprogramowanie ulega zmianie i pojawia się nowa wersja / wydanie, następujące kroki, które możesz wykonać, aby przeprowadzić tego typu testy:

• Dowiedz się, jakie zmiany wprowadzono w oprogramowaniu
• Przeanalizuj i określ, które moduły / części oprogramowania mogą mieć wpływ - zespoły programistyczne i BA mogą odegrać kluczową rolę w dostarczaniu tych informacji
• Przyjrzyj się swoim przypadkom testowym i określ, czy będziesz musiał wykonać pełną, częściową czy jednostkową regresję. Zidentyfikuj te, które będą pasować do Twojej sytuacji
• Zaplanuj czas i przetestuj!

Regresja w Agile

Zwinny jest podejściem adaptacyjnym opartym na metodzie iteracyjnej i przyrostowej. Produkt tworzony jest w krótkich iteracjach zwanych sprintem, które trwają od 2 do 4 tygodni. W agile istnieje wiele iteracji, dlatego testowanie to odgrywa znaczącą rolę, ponieważ nowa funkcjonalność lub zmiana kodu jest wykonywana w iteracjach.

Zestaw testów regresyjnych powinien być przygotowywany od fazy początkowej i aktualizowany przy każdym sprincie.

W Agile kontrola regresji jest objęta dwiema kategoriami:

• Regresja na poziomie sprintu
• Regresja od końca do końca

1) Regresja na poziomie sprintu

Regresja na poziomie sprintu jest wykonywana głównie dla nowych funkcji lub ulepszeń, które są wykonywane w najnowszym sprincie. Przypadki testowe z zestawu testów są wybierane zgodnie z nowo dodaną funkcjonalnością lub wykonanym ulepszeniem.

# 2) Regresja od końca do końca

Regresja od końca do końca obejmuje wszystkie przypadki testowe, które mają zostać ponownie wykonane, aby przetestować cały produkt od końca do końca, obejmując wszystkie podstawowe funkcje Produktu.

Ponieważ Agile ma krótkie sprinty i trwa, bardzo potrzebne jest zautomatyzowanie zestawu testów, przypadki testowe są wykonywane ponownie i to również musi zostać ukończone w krótkim czasie. Automatyzacja przypadków testowych skraca czas wykonywania i poślizg defektów.

Zalety

Poniżej podano różne zalety testu regresji

• Poprawia jakość Produktu.
• Gwarantuje, że wszelkie poprawki lub ulepszenia, które zostaną wprowadzone, nie wpłyną na istniejącą funkcjonalność Produktu.
• Do tego testowania można użyć narzędzi automatyzacji.
• Zapewnia, że ​​problemy, które zostały już naprawione, nie wystąpią ponownie.

Niedogodności

Chociaż jest kilka zalet, są też pewne wady. Oni są:

• Należy to zrobić również dla niewielkiej zmiany w kodzie, ponieważ nawet niewielka zmiana w kodzie może spowodować problemy w istniejącej funkcjonalności.
• Jeśli automatyzacja nie jest używana w Projekcie do tego testowania, wielokrotne wykonywanie przypadków testowych będzie czasochłonnym i żmudnym zadaniem.

Regresja aplikacji GUI

Trudno jest wykonać test regresji GUI (graficzny interfejs użytkownika), gdy strukturę GUI jest modyfikowany. Przypadki testowe napisane na starym interfejsie GUI albo stają się przestarzałe, albo wymagają modyfikacji.

Ponowne użycie przypadków testowych regresji oznacza, że ​​przypadki testowe GUI są modyfikowane zgodnie z nowym GUI. Ale to zadanie staje się uciążliwe, jeśli masz duży zestaw przypadków testowych GUI.

Różnica między regresją a ponownym testowaniem

Ponowne testowanie jest wykonywane dla przypadków testowych, które kończą się niepowodzeniem podczas wykonywania, a zgłoszony błąd został naprawiony, podczas gdy sprawdzanie regresji nie ogranicza się do poprawki błędu, ponieważ obejmuje również inne przypadki testowe, aby upewnić się, że naprawa błędu nie została wpłynęło na jakąkolwiek inną funkcjonalność Produktu.

Szablon planu testów regresji (TOC)

1. Historia dokumentu

2. Referencje

3. Plan testów regresji

3.1. Wprowadzenie

3.2. Cel, powód

3.3. Strategia testów

3.4. Funkcja do przetestowania

3.5. Wymagania dotyczące zasobów

3.5.1. Wymagania sprzętowe

3.5.2. Wymagania dotyczące oprogramowania

3.6. Harmonogram testów

3.7. Żądanie zmiany

3.8. Kryteria wejścia / wyjścia

3.8.1. Kryteria wejścia do tego badania

3.8.2. Kryteria zakończenia tego testu

3.9. Założenie / ograniczenia

3.10. Przypadki testowe

3.11. Ryzyko / założenia

3.12. Przybory

4. Zatwierdzenie / Odbiór

Przyjrzyjmy się szczegółowo każdemu z nich.

# 1) Historia dokumentu

Historia dokumentu składa się z zapisu pierwszej wersji roboczej oraz wszystkich zaktualizowanych w podanym poniżej formacie.

# 2) Odniesienia

Kolumna Referencje umożliwia śledzenie wszystkich dokumentów referencyjnych używanych lub wymaganych dla Projektu podczas tworzenia planu testów.

# 3) Plan testów regresji

3.1. Wprowadzenie

W tym dokumencie opisano zmianę / aktualizację / ulepszenie produktu, który ma być testowany, oraz podejście zastosowane do tego testowania. Wszystkie zmiany kodu, ulepszenia, aktualizacje, dodane funkcje są nakreślone do przetestowania. Przypadki testowe używane do testów jednostkowych i testów integracyjnych mogą służyć do tworzenia zestawu testów dla regresji.

3.2. Cel, powód

Celem planu testów regresyjnych jest opisanie, co dokładnie i jak testowanie będzie wykonywane w celu uzyskania wyników. Sprawdzanie regresji ma na celu zapewnienie, że żadna inna funkcjonalność produktu nie zostanie ograniczona z powodu zmiany kodu.

3.3. Strategia testów

Strategia testów opisuje podejście, które zostanie zastosowane do wykonania tego testowania, w tym technikę, która zostanie zastosowana, jakie będą kryteria ukończenia, kto będzie wykonywał jaką czynność, kto napisze skrypty testowe, jakie narzędzie regresji będzie używane kroki mające na celu pokrycie zagrożeń, takich jak kryzys zasobów, opóźnienia w produkcji itp.

3.4. Funkcje do przetestowania

W tym miejscu wymieniono cechę / komponenty testowanego produktu. W przypadku regresji wszystkie przypadki testowe są ponownie wykonywane lub te, które mają wpływ na istniejącą funkcjonalność, są wybierane w zależności od wykonanej poprawki / aktualizacji lub ulepszenia.

3.5. Wymagania dotyczące zasobów

3.5.1. Wymagania sprzętowe:

Określono tutaj wymagania sprzętowe, takie jak komputery, laptop, modemy, książka Mac, smartfon itp.

3.5.2. Wymagania dotyczące oprogramowania:

Określono wymagania dotyczące oprogramowania, na przykład system operacyjny i przeglądarki, które będą wymagane.

3.6. Harmonogram testów

Harmonogram testów określa szacowany czas na wykonanie czynności testowych.

Na przykład Ile zasobów będzie wykonywać czynności testowe, a także w jakim czasie?

3.7. Żądanie zmiany

Podano szczegóły CR, dla których zostanie wykonana regresja.

3.8. Kryteria wejścia / wyjścia

3.8.1. Kryteria wejścia do tego testu:

Zdefiniowano kryteria wejściowe dla produktu, aby rozpocząć sprawdzanie regresji.

Na przykład:

• Należy zakończyć kodowanie zmian / ulepszenie / dodanie nowej funkcji.
• Plan testów regresji powinien zostać zatwierdzony.

3.8.2. Kryteria zakończenia dla tego testu:

Tutaj definiowane są kryteria wyjścia dla regresji.

Na przykład:

• Należy zakończyć testy regresji.
• Wszelkie nowe krytyczne błędy znalezione podczas tego testowania powinny zostać zamknięte.
• Raport z testu powinien być gotowy.

3.9. Przypadki testowe

Tutaj zdefiniowano przypadki testowe regresji.

3.10. Ryzyko / założenia

Wszelkie ryzyka i założenia są identyfikowane i przygotowywany jest dla nich plan awaryjny.

3.11. Przybory

Określono narzędzia, które mają być użyte w Projekcie. Jak na przykład:

• Narzędzie do automatyzacji
• Narzędzie do zgłaszania błędów

# 4) Zatwierdzenie / akceptacja

Nazwy i oznaczenia osób są wymienione tutaj:

Wniosek

Testowanie regresyjne jest jednym z ważnych aspektów, ponieważ pomaga w dostarczeniu produktu wysokiej jakości, upewniając się, że wszelkie zmiany w kodzie, niezależnie od tego, czy jest mały, czy duży, nie wpływają na istniejącą lub starą funkcjonalność.

Dostępnych jest wiele narzędzi automatyzacji do automatyzacji przypadków testowych regresji, jednak narzędzie należy wybrać zgodnie z wymaganiami projektu. Narzędzie powinno mieć możliwość aktualizowania zestawu testów, ponieważ zestaw testów regresji wymaga częstej aktualizacji.

Tym samym kończymy ten temat i mamy nadzieję, że od teraz będzie on znacznie bardziej zrozumiały.

Daj nam znać swoje pytania i komentarze dotyczące regresji. Jak poradziłeś sobie z zadaniami testowania regresji?

=> Odwiedź tutaj, aby zapoznać się z pełną serią samouczków dotyczących planu testów

rekomendowane lektury

• Najlepsze narzędzia do testowania oprogramowania 2021 (Narzędzia do automatyzacji testów QA)
• 10 najpopularniejszych narzędzi do testowania regresji w 2021 r
• Co to jest testowanie niezawodności: definicja, metoda i narzędzia
• 11 najlepszych narzędzi automatyzacji do testowania aplikacji na Androida (narzędzia do testowania aplikacji na Androida)
• Zautomatyzowane testy regresji: wyzwania, proces i kroki
• Testing Primer Pobierz eBook
• Różnica między ponownym testowaniem a testowaniem regresji na przykładzie
• Top 10+ najlepszych narzędzi testowych SAP (narzędzia automatyzacji SAP)