Testowanie trzeźwości a testowanie dymne: kluczowe różnice, przykłady i kiedy stosować każde z nich

Testowanie dymne a testowanie trzeźwości: tabela porównawcza

WYGLĄD	Testowanie dymu	Testowanie poczytalności
Główny cel	Sprawdź stabilność kompilacji	Zweryfikuj funkcjonalność zmian
Zakres	Szeroki (całe zastosowanie)	Wąskie (konkretne moduły)
Głębokość	Płytkie testowanie	Głębokie testy (ukierunkowane)
Wykonane przez	Programiści lub testerzy	Tylko dla testerów
Stan kompilacji	Kompilacje początkowe/niestabilne	Relatywnie stabilne kompilacje
Dokumenty	Skryptowane i udokumentowane	Zwykle bez scenariusza
Podzbiór testowy	Testy akceptacyjne	Testy regresji
Automatyzacja	Wysoce polecany	Może być ręczny lub automatyczny

Co to jest kompilacja oprogramowania?

Jeśli tworzysz prosty program komputerowy, który składa się tylko z jednego pliku kodu źródłowego, wystarczy skompilować i połączyć ten plik, aby utworzyć plik wykonywalny. Ten proces jest prosty. Zazwyczaj tak nie jest. Typowy projekt programistyczny składa się z setek, a nawet tysięcy plików kodu źródłowego. Tworzenie programu wykonywalnego z tych plików jest skomplikowanym i czasochłonnym zadaniem. Aby utworzyć program wykonywalny, musisz użyć oprogramowania do kompilacji, a proces ten nazywa się „kompilacją oprogramowania”.

Co to jest test dymu?

Testowanie dymowe (ang. smoke testing) to technika testowania oprogramowania wykonywana po skompilowaniu oprogramowania w celu weryfikacji, czy krytyczne funkcjonalności oprogramowania działają prawidłowo. Jest ono przeprowadzane przed wykonaniem szczegółowych testów funkcjonalnych lub regresyjnych. Głównym celem testów dymowych jest odrzucenie aplikacji z defektami, aby zespół ds. zapewnienia jakości nie tracił czasu na testowanie wadliwej aplikacji.

W testach dymowych wybrane przypadki testowe obejmują najważniejsze funkcjonalności lub komponenty systemu. Celem nie jest dokładne testowanie, ale upewnienie się, że kluczowe funkcjonalności aplikacji działają poprawnie. Na przykład, typowy test dymowy weryfikuje, czy aplikacja uruchamia się poprawnie, czy interfejs graficzny reaguje na polecenia itp.

Co to jest test poczytalności?

Testowanie poprawności (sanity testing) to rodzaj testowania oprogramowania przeprowadzanego po otrzymaniu kompilacji oprogramowania z drobnymi zmianami w kodzie lub funkcjonalności, w celu upewnienia się, że błędy zostały naprawione i nie powodują dalszych problemów. Celem jest ustalenie, czy proponowana funkcjonalność działa mniej więcej zgodnie z oczekiwaniami. Jeśli test poprawności zakończy się niepowodzeniem, kompilacja jest odrzucana, aby uniknąć marnowania czasu i zasobów na głębsze testowanie.

Celem nie jest „weryfikacja” pełnej funkcjonalności, ale stwierdzenie, czy twórca oprogramowania zastosował pewną racjonalność (zdrowy rozsądek). Na przykład, jeśli Twój kalkulator naukowy zwraca wynik 2 + 2 = 5! Wtedy nie ma sensu testować zaawansowanych funkcji, takich jak sin 30 + cos 50.

Historia i pochodzenie terminów

Termin „testowanie dymne” (ang. smoke testing) wywodzi się z branży sprzętowej i elektronicznej. Kiedy inżynierowie po raz pierwszy uruchamiali nową płytkę drukowaną, obserwowali, czy zaczyna dymić – co było bezpośrednim wskaźnikiem podstawowej wady. Jeśli dym nie pojawił się, można było przystąpić do podstawowych testów. Koncepcja ta została przyjęta przez testerów oprogramowania w latach 1980. XX wieku do opisu wstępnej weryfikacji kompilacji.

Z drugiej strony, „testowanie poprawności” odnosi się do sprawdzania „poprawności” lub racjonalności konkretnych zmian. Termin ten kładzie nacisk na weryfikację, czy oprogramowanie zachowuje się w sensowny, logiczny sposób po modyfikacjach – w istocie pytając: „Czy to ma sens?”.

Testowanie dymne kontra testowanie poprawności kontra testowanie regresji

Zrozumienie, w jaki sposób te trzy typy testów współdziałają ze sobą, jest kluczowe dla skutecznej strategii zapewnienia jakości:

• Testowanie dymu następuje po pierwsze — weryfikuje, czy kompilacja jest wystarczająco stabilna, aby można ją było testować.
• Testowanie poczytalności następuje (jeśli ma to zastosowanie) — potwierdza, że ​​określone zmiany lub poprawki działają prawidłowo.
• Testy regresji jest najbardziej kompleksowy — daje pewność, że wprowadzone zmiany nie naruszą żadnej istniejącej funkcjonalności.

Można to porównać do lejka: testy dymowe to szeroki otwór, który szybko odfiltrowuje niestabilne kompilacje, testy poprawności zawężają zakres do określonych zmian, a testy regresyjne zapewniają dokładne pokrycie całego systemu.

Scenariusz ze świata rzeczywistego: aplikacja e-commerce

Rozważmy witrynę e-commerce, która otrzymała nową wersję z poprawionym błędem koszyka zakupowego:

Test dymny: Dział kontroli jakości najpierw weryfikuje, czy strona się ładuje, użytkownicy mogą się logować, produkty wyświetlają się poprawnie, wyszukiwarka działa i rozpoczyna się proces finalizacji zamówienia. Trwa to około 15-30 minut.

Test zdrowia psychicznego: Po przejściu testów dymowych, testerzy skupiają się na funkcjonalności koszyka zakupowego – dodawaniu produktów, aktualizowaniu ilości, usuwaniu produktów i weryfikacji obliczeń. Ten ukierunkowany test trwa około 30–60 minut.

Jeśli oba testy zakończą się sukcesem, zespół przystępuje do pełnych testów regresyjnych, które mogą potrwać kilka godzin lub dni, w zależności od złożoności aplikacji.

Kiedy stosować test dymny, a kiedy test trzeźwości

Użyj testu dymowego, gdy:

• Nowa wersja oprogramowania jest wdrażana w środowisku testowym
• Musisz szybko zweryfikować kluczowe funkcjonalności, takie jak logowanie, nawigacja i przepływ danych
• Określanie, czy kompilacja jest wystarczająco stabilna do dalszych szczegółowych testów
• Integracja z procesami CI/CD w celu automatycznej weryfikacji kompilacji

Stosuj testy trzeźwości, gdy:

• Wprowadzane są drobne zmiany kodu, poprawki błędów lub udoskonalenia funkcji
• Sprawdzanie, czy określone zmiany działają zgodnie z przeznaczeniem
• Kompilacja jest już stosunkowo stabilna, co potwierdzają wcześniejsze testy dymne

Zalety i ograniczenia

Zalety

• Szybka identyfikacja problemów krytycznych: Obie metody pozwalają szybko zidentyfikować problemy, które mogłyby wstrzymać testy.
• Efektywność zasobów: Zespoły nie marnują czasu na szczegółowe testowanie wersji, które są zasadniczo błędne.
• Wczesne wykrywanie usterek: Wczesne wykrywanie usterek obniża ogólne koszty naprawy.
• Szybsze cykle wydań: Efektywne zarządzanie pozwala na szybszą iterację i wdrażanie.

Ograniczenia

• Ograniczony zasięg: Żaden z typów testów nie zapewnia kompleksowego pokrycia całego zastosowania.
• Można pominąć ukryte błędy: Problemy z integracją lub przypadki skrajne mogą pozostać niewykryte.
• Nie zastępuje pełnego testowania: Służą one jako szybkie filtry, ale nie zastępują testów regresyjnych.

Najlepsze praktyki wdrażania

Do testów dymnych:

• Zautomatyzuj testy dymowe i zintegruj je z procesem CI/CD dla każdej kompilacji.
• Ogranicz zestaw testów dymowych wyłącznie do najważniejszych funkcjonalności — nie pozwól, aby stał się zbyt duży.
• Aktualizuj testy dymowe za każdym razem, gdy dodawane lub modyfikowane są istotne funkcje.

W celu sprawdzenia poprawności działania:

• Zawsze sprawdzaj dokumentację zmian przed tworzeniem scenariuszy testów poprawności.
• Skoncentruj wysiłki testowe na zmienionych obszarach i bezpośrednio przyległych funkcjonalnościach.
• Stosuj techniki testowania eksploracyjnego w celu wykrycia nieoczekiwanych problemów.

Typowe błędy, których należy unikać

• Mylenie dwóch typów testów: Testy dymowe są szerokie i płytkie; testy walidacyjne są wąskie i głębokie.
• Pominięcie testów dymowych w celu zaoszczędzenia czasu: Często prowadzi to do marnowania wysiłku włożonego w tworzenie niestabilnych wersji.
• Zbytnie uszczegóławianie testów dymowych: To zaprzecza celowi szybkiej weryfikacji.
• Postępowanie po wystąpieniu błędów: Jeśli którykolwiek z testów zakończy się niepowodzeniem, przerwij test i rozwiąż problem przed kontynuacją.

Zalecane narzędzia do testowania dymu i zdrowia psychicznego

• Selenium Sterownik sieciowy: Standard branżowy w zakresie automatyzacji testów aplikacji internetowych
• TestNG/JUnit: Ramki testowe do organizowania i wykonywania testów automatycznych
• Akcje Jenkins/GitHub: Narzędzia CI/CD do automatycznego budowania i wykonywania testów
• Cypress: Nowoczesne, przyjazne dla programistów kompleksowe środowisko testowe
• Postman/REST Assured: Narzędzia do testowania API do testów dymowych zaplecza

FAQ