Co to jest test dymu?

Przez: Tomasza Hamiltona Tomasza Hamiltona
Hours Zaktualizowano

⚡ Inteligentne podsumowanie

Testy dymowe (Smoke Testing) decydują, czy nowa kompilacja jest wystarczająco stabilna do testowania. Ta strona wyjaśnia, kiedy je uruchomić, kto je uruchamia, jak działa cykl i jak zautomatyzowane pakiety obsługują nowoczesne procesy dostarczania.

  • 🔍 Definicja: Testy dymowe polegają na przeprowadzeniu minimalnej liczby kontroli dla każdej nowej wersji, aby potwierdzić, że nic nie blokuje dalszych testów.
  • 🕒 Timing: Uruchom pakiet natychmiast po dotarciu kompilacji do środowiska kontroli jakości lub środowiska testowego, przed rozpoczęciem jakichkolwiek testów funkcjonalnych.
  • 👤 Własność: Inżynierowie ds. zapewnienia jakości lub kierownik ds. zapewnienia jakości wybierają najważniejsze funkcjonalności i decydują o zaakceptowaniu lub odrzuceniu kompilacji.
  • 🧭 Ścieżki krytyczne: Utrzymuj szeroki i szczegółowy zakres operacji logowania, wyszukiwania, wprowadzania danych, dokonywania płatności i wylogowywania w ramach jednego przejścia.
  • ⏱️. Budżet czasu wykonania: Utrzymuj przebieg na poziomie około dwudziestu do trzydziestu przypadków i przez dziesięć do piętnastu minut, aby bramka nigdy nie stała się wąskim gardłem.
  • ⚙️ Automatyka: Podłącz pakiet do procesu CI/CD, aby każde zatwierdzenie i każde wdrożenie było weryfikowane bez konieczności ręcznego wysiłku.
  • ???? Kontrola łuszczenia: Wycofaj przypadki, w których występują duże zależności i które są niespójne, ponieważ niezawodna brama niszczy zaufanie do werdyktu kompilacji.
Czytaj więcej

Co to jest test dymu?

Testowanie dymu jest procesem testowania oprogramowania, który określa, czy wdrożona kompilacja oprogramowania jest stabilna, czy nie. Testowanie dymne jest potwierdzeniem dla zespołu ds. zapewnienia jakości, że może on kontynuować dalsze testowanie oprogramowania. Składa się z minimalnego zestawu testów uruchamianych na każdej kompilacji w celu przetestowania funkcjonalności oprogramowania. Testowanie dymne jest również znane jako „testowanie weryfikacyjne kompilacji” lub „testowanie pewności”.

Mówiąc najprościej, testy dymowe oznaczają weryfikację działania ważnych funkcji i brak jakichkolwiek problemów w testowanej wersji. To krótki i szybki test regresyjny głównych funkcjonalności. Pomaga to ustalić, czy wersja jest wadliwa i czy dalsze testowanie nie będzie stratą czasu i zasobów.

PORÓWNAJ Test dymu kontra zdrowie psychiczne

Dlaczego wykonujemy testy dymowe?

Testy dymowe odgrywają ważną rolę w rozwoju oprogramowania, ponieważ zapewniają poprawność systemu na początkowych etapach. Dzięki temu możemy zaoszczędzić nakład pracy związany z testowaniem. Dopiero po zakończeniu testów dymowych rozpoczynamy testy funkcjonalne.

  • Wszystkie elementy wyróżniające się w projekcie zostaną zidentyfikowane podczas testów dymnych.
  • Dzięki testom dymowym większość usterek jest identyfikowana na wczesnym etapie rozwoju oprogramowania.
  • Dzięki testom dymu upraszczamy wykrywanie i korygowanie poważnych usterek.
  • Testując dym, zespół ds. kontroli jakości może znaleźć defekty w funkcjonalności aplikacji, które mogły ujawnić się w nowym kodzie.
  • Testowanie dymu pozwala wykryć wady o największym stopniu nasilenia.

1 przykład: Okno rejestrowania: Możliwość przejścia do następnego okna z prawidłową nazwą użytkownika i hasłem po kliknięciu przycisku Prześlij.

2 przykład: Użytkownik nie może wylogować się ze strony internetowej.

Kiedy przeprowadzamy testy dymowe?

Korzyści te materializują się tylko wtedy, gdy weryfikacja zostanie uruchomiona we właściwym momencie. Testy dymowe (Smoke Testing) przeprowadza się za każdym razem, gdy nowe funkcjonalności oprogramowania są opracowywane i integrowane z istniejącą kompilacją wdrożoną w środowisku QA/staging. Zapewniają one, że wszystkie krytyczne funkcjonalności działają poprawnie. Poniższy diagram przedstawia, w jaki sposób kompilacja trafia do środowiska QA przed rozpoczęciem testów dymowych.

W tej metodzie testowania zespół programistów wdraża kompilację w dziale zapewnienia jakości (QA). Testerzy pobierają i uruchamiają podzbiór przypadków testowych, aby sprawdzić krytyczne funkcjonalności kompilacji. Te serie przypadków testowych mają na celu wykrycie błędów występujących w kompilacji. Jeśli testy zakończą się sukcesem, zespół zapewnienia jakości kontynuuje pracę. Testy funkcjonalne.

Jakakolwiek awaria wskazuje na potrzebę przekazania systemu zespołowi programistów. Za każdym razem, gdy następuje zmiana w kompilacji, przeprowadzamy testy dymu, aby zapewnić stabilność.

Przykład: - Dodano nowy przycisk rejestracji w oknie logowania i wdrożono kompilację z nowym kodem. Przeprowadzamy testy dymowe nowej kompilacji.

Testy dymowe kwalifikują kompilację do dalszych formalnych testów i mają na celu wykazanie stabilności systemu i zgodności z wymaganiami. Głównym celem jest wczesne wykrycie poważnych problemów. Kompilacja zawiera wszystkie pliki danych, biblioteki, moduły wielokrotnego użytku oraz komponenty inżynieryjne wymagane do zaimplementowania jednej lub więcej funkcji produktu.

Co się stanie, jeśli nie przeprowadzimy testu dymowego

Jeśli nie przeprowadzimy testów dymowych na wczesnym etapie, wady mogą ujawnić się na późniejszych etapach, co może być kosztowne. Wada odkryte na późniejszych etapach mogą okazać się przeszkodą uniemożliwiającą udostępnienie produktów końcowych.

Kto przeprowadzi test dymowy?

Po udostępnieniu kompilacji w środowisku kontroli jakości, inżynierowie kontroli jakości/kierownik kontroli jakości przeprowadzają testy dymu. Za każdym razem, gdy pojawia się nowa kompilacja, zespół ds. kontroli jakości określa główną funkcjonalność aplikacji w celu przeprowadzenia testów dymu. Zespół ds. kontroli jakości sprawdza, czy w testowanej aplikacji nie występują elementy wyróżniające się.

Jak przeprowadzić test dymowy?

Testowanie dymu jest zwykle wykonywane ręcznie, chociaż istnieje możliwość wykonania tego samego poprzez automatyzację. Może się różnić w zależności od organizacji.

Ręczne testowanie dymu

Przeprowadzane są testy dymowe (smoke tests), aby upewnić się, że nawigacja po ścieżkach krytycznych przebiega zgodnie z oczekiwaniami i nie zakłóca funkcjonalności. Testowane są przypadki funkcjonalne o wysokim priorytecie, które są testowane w celu wykrycia krytycznych defektów w systemie. Jeśli test zakończy się pomyślnie, kontynuujemy testy funkcjonalne. Jeśli test zakończy się niepowodzeniem, kompilacja jest odrzucana i odsyłana do zespołu programistów w celu poprawy.

Dział zapewnienia jakości ponownie rozpoczyna testy dymowe z nową wersją kompilacji. Testy dymowe są przeprowadzane na nowych kompilacjach i będą integrowane ze starymi kompilacjami, aby utrzymać poprawność systemu. Przed rozpoczęciem testów dymowych zespół zapewnienia jakości powinien sprawdzić, czy kompilacje są poprawne.

Testowanie dymowe za pomocą automatyzacji

Testowanie automatyzacji jest używany do Testy regresjiMożemy jednak również użyć zestawu zautomatyzowanych przypadków testowych do uruchomienia testu dymowego. Dzięki testom automatycznym programiści mogą natychmiast sprawdzić kompilację, gdy tylko pojawi się nowa kompilacja gotowa do wdrożenia.

Zamiast powtarzać testy ręcznie za każdym razem, gdy wdrażana jest nowa kompilacja oprogramowania, wykonywane są zarejestrowane przypadki testów dymnych dla kompilacji. Sprawdzają one, czy główne funkcjonalności nadal działają prawidłowo. Jeśli test się nie powiedzie, można poprawić kompilację i natychmiast ją ponownie wdrożyć. Dzięki temu możemy zaoszczędzić czas i zapewnić środowisko QA wysokiej jakości kompilację.

Używając zautomatyzowanego narzędzia, inżynier testowy rejestruje wszystkie ręczne kroki wykonywane podczas kompilacji oprogramowania.

Nie przegap:

Cykl testów dymowych

Poniższy schemat blokowy przedstawia sposób przeprowadzania testów dymowych. Po wdrożeniu kompilacji w dziale zapewnienia jakości i pozytywnym przejściu testów dymowych przechodzimy do testów funkcjonalnych. Jeśli test dymowy zakończy się niepowodzeniem, kończymy testowanie do czasu rozwiązania problemu w kompilacji.

Najlepsze praktyki projektowania przypadków testów dymowych

Znajomość cyklu to jedno;ping Kolejnym czynnikiem, który sprawia, że ​​jest godny zaufania, jest pakiet. Pakiet dymowy zyskuje na popularności tylko wtedy, gdy jest kompaktowy, szybki i powtarzalny.

  • Najpierw zmapuj ścieżki krytyczne: Wymień przepływy pracy, które sprawiają, że produkt nadaje się do użytku komercyjnego, takie jak logowanie, wyszukiwanie, wprowadzanie danych, płatności i wylogowywanie. Jeśli któryś z nich ulegnie awarii, kompilacja nie będzie miała wartości dla testera.
  • Utrzymaj zestaw płytki, ale szeroki: Zajmij się każdym głównym modułem raz, zamiast zagłębiać się w jeden. Wartości graniczne, dane ujemne i sformułowania komunikatów o błędach należą do testów funkcjonalnych, a nie tutaj.
  • Ogranicz czas wykonania: Większość zespołów utrzymuje bieg przez dziesięć do piętnastu minut i ogranicza czas trwania do około dwudziestu do trzydziestu przypadki testoweBieg trwający godzinę przestaje być bramą i staje się wąskim gardłem.
  • Uruchom te same przypadki przy każdej kompilacji: Spójność pozwala przypisać błąd kodowi, a nie zmienionemu wyborowi testu.
  • Usuń przypadki niestabilne i z dużą liczbą zależności: Przypadek, który przechodzi i nie przechodzi bez żadnych zmian w kodzie, niszczy zaufanie do bramki. Zastępcze lub pozorowane niestabilne usługi stron trzecich, w których framework automatyzacji testów pozwala.
  • Zapisz jeden jednoznaczny werdykt: W każdym przypadku potrzebny jest pojedynczy oczekiwany wynik, aby można było zaakceptować lub odrzucić konstrukcję bez dyskusji.
  • Wersjonuj pakiet za pomocą kompilacji: Przechowuj zgłoszenia dotyczące dymu w tym samym repozytorium, w którym znajduje się kod aplikacji, aby brama zawsze odpowiadała testowanemu wydaniu.

RevPrzeglądaj pakiet w każdym wydaniu: wycofuj przypadki funkcji, które nie mają już znaczenia i dodaj nowe, krytyczne przepływy pracy.

Testy dymowe w rurociągach CI/CD

Pakiet zaprojektowany w ten sposób jest na tyle tani, że można go uruchamiać przy każdym zatwierdzeniu, co jest wymogiem nowoczesnego sposobu dostarczania. ciągła integracja serwer taki jak Jenkins Kompiluje kod, wdraża go w środowisku testowym, a następnie uruchamia pakiet Smoke Suite jako pierwszy zautomatyzowany etap. Zielony przebieg przenosi artefakt do etapu funkcjonalnego i regresji, natomiast czerwony przebieg powoduje błąd w potoku i powiadamia programistę zatwierdzającego zmiany w ciągu kilku minut.

Powszechne są dwa sposoby rozmieszczenia. Uruchomienie przed scaleniem chroni gałąź główną poprzez weryfikację każdego żądania ściągnięcia, a uruchomienie po wdrożeniu potwierdza, że ​​wdrożone środowisko jest dostępne i poprawnie skonfigurowane. Zespoły stosujące ciągłe wdrażanie często dodają trzecie, okrojone uruchomienie na produkcji natychmiast po wydaniu.

Ponieważ potok wykonuje pakiet wiele razy dziennie, przypadki muszą być nieinteraktywne, samoczyszczące i niezależne. Każdy przypadek, który czeka na decyzję człowieka lub pozostawia dane testowe, spowoduje zatrzymanie potoku.

Zalety testów dymowych

Oto kilka zalet wymienionych w przypadku testów dymu.

  • Łatwy w wykonaniu i szybko działający
  • Krytyczne błędy i usterki można łatwo wykryć i naprawić na wczesnym etapie.
  • Poprawia jakość systemu
  • Zmniejsza ryzyko
  • Postęp jest łatwiejszy do oceny.
  • Oszczędza wysiłek i czas związany z testowaniem
  • Minimalizuje ryzyko integracji

⚠ Uwaga: Przejście testu „smoke run” oznacza jedynie, że kompilacja nadaje się do testowania. Dotyczy on jedynie powierzchownie głównych funkcjonalności, więc drobne defekty, przypadki skrajne i rzadko używane funkcje pozostają ukryte do momentu uruchomienia testów funkcjonalnych i regresyjnych. Nigdy nie traktuj zielonego wyniku testu „smoke run” jako znaku, że kompilacja jest wolna od defektów.

Testowanie dymne kontra testowanie poprawności kontra testowanie regresji

Wszystkie trzy działają po zmianie kodu, dlatego często są mylone. Różnią się zakresem, szczegółowością i pytaniem, na które każdy z nich odpowiada.

Testowanie kodu w środowisku programistycznym w celu zapewnienia poprawności aplikacji przed przekazaniem jej do działu zapewnienia jakości (QA). Jest to proces weryfikujący, czy aplikacja w trakcie opracowywania spełnia podstawowe wymagania funkcjonalne.

Testowanie poprawności określa zakończenie fazy rozwojowej i podejmuje decyzję, czy przejść lub nie przekazać oprogramowanie do dalszej fazy testowania.

PODSTAWA TEST DYMU BADANIA ZDROWIA TESTOWANIE REGRESYJNE
Zakres Szeroka i płytka Wąskie i głębokie Szeroko i głęboko
Pytanie odpowiedziało Czy ta wersja jest wystarczająco stabilna, aby ją przetestować? Czy to konkretne rozwiązanie działa? Czy coś co działało kiedyś się zepsuło?
Sekwencja Po pierwsze, przy każdej kompilacji Po przejściu testów dymowych Po testach trzeźwości
Typowy czas trwania Od 10 do 15 minut Od 30 do 60 minut Hours do dni
Dopasowanie automatyki Bardzo wysoka Umiarkowany, często manualny Bardzo wysoka

W praktyce są one uruchamiane sekwencyjnie: testy dymne w celu zaakceptowania kompilacji, testy poprawności w celu zweryfikowania dostarczonych zmian i testy regresyjne, gdy harmonogram na to pozwala.

Przykładowe przypadki testowe dymu

Poniższa tabela przedstawia krótki zestaw dymowy, jeden wiersz na każdą ścieżkę krytyczną.

T.ID SCENARIUSZE TESTOWE OPIS KROK TESTU SPODZIEWANY WYNIK AKTUALNY REZULTAT STATUS
1 Prawidłowe dane logowania Przetestuj funkcjonalność logowania w aplikacji internetowej, aby upewnić się, że zarejestrowany użytkownik może zalogować się przy użyciu nazwy użytkownika i hasła 1. Uruchom aplikację
2. Przejdź na stronę logowania
3. Wprowadź prawidłową nazwę użytkownika
4. Wprowadź prawidłowe hasło
5.Kliknij przycisk logowania		 Logowanie powinno zakończyć się sukcesem zgodnie z oczekiwaniami Przechodzić
2 Dodanie funkcjonalności elementu Możliwość dodania przedmiotu do koszyka 1.Wybierz listę kategorii
2.Dodaj przedmiot do koszyka		 Artykuł powinien zostać dodany do koszyka Artykuł nie jest dodawany do koszyka Fail
3 Funkcja wylogowania Sprawdź funkcjonalność wylogowania 1. wybierz przycisk wylogowania Użytkownik powinien mieć możliwość wylogowania się. Użytkownik nie może się wylogować Fail

FAQ

Nazwa pochodzi z inżynierii sprzętowej, gdzie nowo zmontowane urządzenie przechodziło pierwszą kontrolę, jeśli nie wydzielało dymu po włączeniu. Oprogramowanie zapożyczyło tę ideę: jeśli kompilacja przejdzie szybką kontrolę po włączeniu, można rozpocząć głębsze testy.

Większość zespołów rozstrzyga od dwudziestu do trzydziestu przypadków, przy czym dziesięć to praktyczna granica, a pięćdziesiąt to górna granica. Prawdziwym ograniczeniem jest czas: jeśli pełny przebieg przekracza piętnaście minut, należy docinać przypadki, aż będą pasować.

Tak. Narzędzia AI potrafią odczytywać wymagania, historie użytkowników lub logi ruchu produkcyjnego i proponować ścieżki krytyczne o największym natężeniu ruchu w ramach analizy przypadków. Inżynier ds. zapewnienia jakości nadal musi zatwierdzić ten wybór, ponieważ model nie jest w stanie ocenić ryzyka komercyjnego.

To bardzo pomaga. Samonaprawiające się lokalizatory w nowoczesnych narzędzia do testów automatycznych ponowna identyfikacja przeniesionego lub przemianowanego elementu zamiast niepowodzenia, co eliminuje fałszywe alarmy sprawiające, że bramka dymowa jest niewiarygodna. Revsprawdź każdy wyleczony lokalizator zanim mu zaufasz.

Selenium oraz Cypress obejmuje przepływy przeglądarek, Postman oraz SoapUI obejmuje punkty końcowe interfejsu API i JUnit, TestNG, PyTest lub Jest uruchamiają pakiet. Robot Framework jest odpowiedni dla zespołów, które koncentrują się na słowach kluczowych.

Podsumuj ten post następująco: