Menu

Testowanie dymu a testowanie poczytalności: różnica w przykładach

smoke testing vs sanity testing

Wypróbuj Nasz Instrument Do Eliminowania Problemów

Zapoznaj się szczegółowo z różnicami między testowaniem dymu a testami poczytalności, korzystając z przykładów:

W tym samouczku dowiemy się, czym są testy normalności i testy dymu w testowaniu oprogramowania. Na prostych przykładach poznamy również kluczowe różnice między testami Sanity i Smoke.

W większości przypadków jesteśmy zdezorientowani między znaczeniem testów poczytalności i testów dymu. Po pierwsze, te dwa testy są „ różne ”I są wykonywane na różnych etapach cyklu testowego.

Testowanie dymu i test psychiczny

Czego się nauczysz:

Testowanie poczytalności

Testowanie poczytalności jest wykonywane, gdy jako QA nie mamy wystarczająco dużo czasu, aby przeprowadzić wszystkie przypadki testowe Testy funkcjonalności , Testowanie interfejsu użytkownika, systemu operacyjnego lub przeglądarki.

Dlatego zdefiniowałbym:

„Testowanie Sanity jako wykonanie testów, które ma na celu dotknięcie każdej implementacji i jej wpływu, ale nie do końca lub dogłębnie, może obejmować testy funkcjonalne, UI, wersji itp., W zależności od implementacji i jej wpływu”.

Czy nie wszyscy wpadamy w sytuację, w której musimy się wylogować za dzień lub dwa, ale wersja do testów nadal nie jest dostępna?

unix commands pytania i odpowiedzi do wywiadu pdf

Ach tak, założę się, że ty również musiałeś stawić czoła tej sytuacji przynajmniej raz w swoim doświadczeniu z testowaniem oprogramowania. Cóż, często się z tym mierzyłem, ponieważ moje projekty były w większości zwinne i czasami proszono nas o dostarczenie ich tego samego dnia. Ups, jak mogę przetestować i wydać kompilację w ciągu kilku godzin?

Czasami zwariowałem, ponieważ nawet jeśli była to niewielka funkcjonalność, konsekwencje mogły być ogromne. A jako wisienkę na torcie klienci czasami po prostu odmawiają poświęcenia dodatkowego czasu. Jak mogłem w kilka godzin zakończyć całe testy, zweryfikować każdą funkcjonalność, Błędy i zwolnić?

testy poczytalności

Odpowiedź na wszystkie takie problemy była bardzo prosta, czyli nic innego, jak tylko użycie Strategia testowania poczytalności.

Kiedy wykonujemy te testy dla modułu, funkcjonalności lub kompletnego systemu, plik Przypadki testowe do wykonania są tak dobrane, aby dotykały wszystkich ważnych elementów tego samego, tj. szerokich, ale płytkich testów.

Czasami testowanie jest nawet wykonywane losowo, bez przypadków testowych. Ale pamiętaj, Test poczytalności powinien być wykonywany tylko wtedy, gdy masz mało czasu, nigdy nie używaj go do regularnych wydań. Teoretycznie to testowanie jest podzbiorem Testowanie regresji .

Moje doświadczenie

Doświadczenie w testowaniu poczytalności

W ramach mojej ponad 8-letniej kariery w testowaniu oprogramowania przez 3 lata pracowałem Metodyka zwinna y i to był czas, kiedy najczęściej używałem testu poczytalności.

Wszystkie duże wydania były planowane i wykonywane w sposób systematyczny, ale czasami małe wydania były proszone o jak najszybsze dostarczenie. Nie mieliśmy dużo czasu, aby udokumentować przypadki testowe, wykonać, sporządzić dokumentację błędów, przeprowadzić regresję i prześledzić cały proces.

Stąd następujące kluczowe wskazówki, którymi kierowałem się w takich sytuacjach:

# 1) Usiądź z menedżerem i zespołem programistów, gdy omawiają implementację, ponieważ muszą pracować szybko i dlatego nie możemy oczekiwać, że wyjaśnią nam osobno.

Pomogłoby to również w zorientowaniu się, co zamierzają zaimplementować, na który obszar będzie to wpływać itp. Jest to bardzo ważna rzecz, ponieważ czasami po prostu nie zdajemy sobie sprawy z konsekwencji i czy istnieją jakiekolwiek istniejące funkcje będzie utrudniony (w najgorszym).

#dwa) Ponieważ masz mało czasu, zanim zespół programistów będzie pracował nad wdrożeniem, możesz z grubsza zanotować przypadki testowe w narzędziach takich jak Evernote itp. Ale upewnij się, że napiszesz je gdzieś, aby móc je później dodać do narzędzie przypadków testowych.

# 3) Przygotuj swoje stanowisko testowe zgodnie z implementacją i jeśli uważasz, że istnieją jakieś sygnały ostrzegawcze, takie jak tworzenie określonych danych, jeśli platforma testowa zajmie trochę czasu (i jest to ważny test dla wydania), natychmiast podnieś te flagi i poinformuj swojego kierownika lub PO o blokadzie na wyłączność.

Tylko dlatego, że klient chce jak najszybciej, nie oznacza to, że kontrola jakości zostanie wydana, nawet jeśli jest w połowie przetestowana.

# 4) Uzgodnij ze swoim zespołem i menedżerem, że ze względu na brak czasu będziesz informować o błędach tylko zespół programistów, a formalny proces dodawania, oznaczanie błędów na różnych etapach w narzędziu do śledzenia błędów zostanie wykonane później, aby zaoszczędzić czas .

# 5) Kiedy zespół programistów przeprowadza testy na końcu, spróbuj sparować z nimi (zwane parowaniem dev-QA) i zrób podstawową rundę dotyczącą samej konfiguracji, pomoże to uniknąć tworzenia się tam i z powrotem, jeśli podstawowa implementacja zawiedzie .

# 6) Teraz, gdy masz już kompilację, najpierw przetestuj reguły biznesowe i wszystkie przypadki użycia. Możesz zachować testy, takie jak walidacja pola, nawigacja itp. Na później.

# 7) Niezależnie od znalezionych błędów, zanotuj je wszystkie i spróbuj zgłosić je razem do programistów, zamiast zgłaszać je indywidualnie, ponieważ będzie im łatwo pracować nad grupą.

# 8) Jeśli masz wymagania dotyczące ogólnego Test wydajności lub testy obciążeniowe lub obciążeniowe, a następnie upewnij się, że masz do tego odpowiednią strukturę automatyzacji. Ponieważ ręczne przetestowanie ich za pomocą testu poczytalności jest prawie niemożliwe.

# 9) To jest najważniejsza część, a nawet ostatni krok strategii testów poczytalności - „Kiedy sporządzasz wersję e-mail lub dokument, wspomnij o wszystkich wykonanych przypadkach testowych, znalezionych błędach ze znacznikiem stanu i jeśli coś zostało niesprawdzone wspomnieć o tym z uzasadnieniem ' Spróbuj napisać krótką historię o swoich testach, która przekaże wszystkim, co zostało przetestowane, zweryfikowane, a co nie.

Podążałem za tym religijnie, kiedy korzystałem z tego testu.

Pozwólcie, że podzielę się własnym doświadczeniem:

# 1) Pracowaliśmy nad stroną internetową, która wyświetlała wyskakujące reklamy na podstawie słów kluczowych. Reklamodawcy zwykli składać oferty na określone słowa kluczowe, które miały do ​​tego przeznaczony ekran. Kiedyś domyślna wartość stawki wynosiła 0,25 USD, którą licytujący mógł nawet zmienić.

Było jeszcze jedno miejsce, w którym ta domyślna stawka pojawiała się i można ją było zmienić na inną wartość. Klient przyszedł z prośbą o zmianę wartości domyślnej z 0,25 USD na 0,5 USD, ale wspomniał tylko o oczywistym ekranie.

Podczas burzy mózgów zapomnieliśmy (?) O tym drugim ekranie, ponieważ nie był on zbytnio używany do tego celu. Ale podczas testowania, kiedy przeprowadziłem podstawowy przypadek, w którym stawka wynosiła 0,5 USD i sprawdzałem od końca do końca, stwierdziłem, że cronjob dla tego samego zawodzi, ponieważ w jednym miejscu znajdował 0,25 USD.

Zgłosiłem to mojemu zespołowi, a my wprowadziliśmy zmianę i pomyślnie dostarczyliśmy ją tego samego dnia.

#dwa) W ramach tego samego projektu (wspomnianego powyżej) zostaliśmy poproszeni o dodanie małego pola tekstowego na uwagi / komentarze do składania ofert. To była bardzo prosta realizacja i zobowiązaliśmy się dostarczyć ją tego samego dnia.

W związku z tym, jak wspomniano powyżej, przetestowałem wszystkie reguły biznesowe i przypadki ich użycia, a kiedy przeprowadziłem testy walidacyjne, stwierdziłem, że kiedy wprowadziłem kombinację znaków specjalnych, takich jak, strona uległa awarii.

Przemyśleliśmy to i stwierdziliśmy, że faktyczni oferenci w żadnym wypadku nie będą używać takich kombinacji. Dlatego wydaliśmy go z dobrze zredagowaną notatką dotyczącą problemu. Klient zaakceptował to jako błąd, ale zgodził się z nami zaimplementować go później, ponieważ był to poważny błąd, ale nie poprzedni.

# 3) Ostatnio pracowałem nad projektem aplikacji mobilnej i musieliśmy zaktualizować czas dostawy wyświetlany w aplikacji zgodnie ze strefą czasową. Miał zostać przetestowany nie tylko w aplikacji, ale także w serwisie internetowym.

Podczas gdy zespół programistów pracował nad wdrożeniem, stworzyłem skrypty automatyzacji do testowania usług internetowych oraz skrypty DB do zmiany strefy czasowej przedmiotu dostawy. Oszczędzało to moje wysiłki i mogliśmy osiągnąć lepsze wyniki w krótkim czasie.

Testowanie poczytalności a testowanie regresyjne

Poniżej podano kilka różnic między nimi:


S. Nie.		Testowanie regresji


Testowanie poczytalności
7To testowanie jest czasami zaplanowane na tygodnie lub nawet miesiące.

Przeważnie trwa to maksymalnie 2-3 dni.

1Testy regresyjne są wykonywane w celu sprawdzenia, czy cały system i poprawki błędów działają poprawnie.Testy poprawności są wykonywane losowo, aby sprawdzić, czy każda funkcja działa zgodnie z oczekiwaniami.
dwaW tych testach każda najmniejsza część jest cofnięta.
To nie jest zaplanowany test i jest wykonywany tylko w przypadku załamania czasowego.
3
To dobrze rozbudowane i zaplanowane testy.

To nie jest zaplanowany test i jest wykonywany tylko w przypadku załamania czasowego.

4Na potrzeby tego testowania tworzony jest odpowiednio zaprojektowany zestaw przypadków testowych.

Tworzenie przypadków testowych może nie zawsze być możliwe; zazwyczaj tworzony jest zgrubny zestaw przypadków testowych.

5Obejmuje to dogłębną weryfikację funkcjonalności, interfejsu użytkownika, wydajności, testowanie przeglądarki / systemu operacyjnego itp., Tj. Każdy aspekt systemu jest regresowany.

Obejmuje to głównie weryfikację reguł biznesowych, funkcjonalności.

6To szeroki i dogłębny test.

To jest szeroki i płytki test.

Strategia testowania aplikacji mobilnych

Testowanie poczytalności aplikacji mobilnych

Pewnie się zastanawiasz, dlaczego wspominam tutaj konkretnie o aplikacjach mobilnych?

Powodem jest to, że system operacyjny i wersja przeglądarki dla aplikacji internetowych lub komputerowych nie różnią się zbytnio, a zwłaszcza rozmiary ekranu są standardowe. Jednak w przypadku aplikacji mobilnych rozmiar ekranu, sieć komórkowa, wersje systemu operacyjnego itp. Wpływają na stabilność, wygląd i krótko mówiąc, na sukces aplikacji mobilnej.

Dlatego sformułowanie strategii staje się krytyczne podczas wykonywania tych testów w aplikacji mobilnej, ponieważ jedna awaria może spowodować duże kłopoty. Testowanie należy również przeprowadzić mądrze i ostrożnie.

Oto kilka wskazówek, które pomogą Ci pomyślnie przeprowadzić te testy w „aplikacji mobilnej”:

# 1) Przede wszystkim przeanalizuj ze swoim zespołem wpływ wersji systemu operacyjnego na wdrożenie.

Spróbuj znaleźć odpowiedzi na pytania, takie jak, czy zachowanie będzie różne w różnych wersjach? Czy wdrożenie będzie działać na najniższej obsługiwanej wersji, czy nie? Czy wystąpią problemy z wydajnością przy wdrażaniu wersji? Czy jest jakaś szczególna funkcja systemu operacyjnego, która może mieć wpływ na zachowanie implementacji? itp.

#dwa) W powyższej notatce przeanalizuj również modele telefonów, tj. Czy są jakieś cechy telefonu, które będą miały wpływ na wdrożenie? Czy realizacja zachowań zmienia się z GPS? Czy zachowanie implementacji zmienia się wraz z aparatem telefonu? itd. Jeśli okaże się, że nie ma to żadnego wpływu, unikaj testów na różnych modelach telefonów.

# 3) O ile nie ma żadnych zmian w interfejsie użytkownika dla implementacji, zalecałbym, aby testowanie interfejsu użytkownika miało jak najmniejszy priorytet, możesz poinformować zespół (jeśli chcesz), że interfejs użytkownika nie będzie testowany.

# 4) Aby zaoszczędzić czas, unikaj testowania w dobrych sieciach, ponieważ jest oczywiste, że implementacja będzie działać zgodnie z oczekiwaniami w silnej sieci. Poleciłbym zacząć od testów w sieci 4G lub 3G.

# 5) Te testy należy przeprowadzić w krótszym czasie, ale upewnij się, że wykonałeś co najmniej jeden test w terenie, chyba że jest to zwykła zmiana interfejsu użytkownika.

# 6) Jeśli musisz przetestować macierz różnych systemów operacyjnych i ich wersji, sugerowałbym, abyś zrobił to w sprytny sposób. Na przykład wybierz do testowania najniższą, średnią i najnowszą parę wersji systemu operacyjnego. Możesz wspomnieć w dokumencie wydania, że ​​nie każda kombinacja jest testowana.

# 7) Na podobnej linii, w celu sprawdzenia poprawności implementacji interfejsu użytkownika, użyj małych, średnich i dużych rozmiarów ekranu, aby zaoszczędzić czas. Możesz także skorzystać z symulatora i emulatora.

Środki ostrożności

Testowanie poczytalności jest wykonywane, gdy masz mało czasu, dlatego nie możesz przeprowadzić każdego przypadku testowego, a co najważniejsze, nie masz wystarczająco dużo czasu na zaplanowanie testów. Aby uniknąć gier z obwinianiem, lepiej jest podjąć środki ostrożności.

W takich przypadkach brak pisemnej komunikacji, dokumentacji testowej i pomyłki są dość powszechne.

Aby upewnić się, że nie padniesz tego ofiarą, upewnij się, że:

  • Nigdy nie akceptuj kompilacji do testowania, dopóki nie otrzymasz pisemnego wymagania udostępnionego przez klienta. Zdarza się, że klienci komunikują zmiany lub nowe wdrożenia ustnie lub na czacie lub prostą linijką 1 w e-mailu i oczekują, że potraktujemy to jako wymaganie. Zmusz swojego klienta, aby przedstawił kilka podstawowych punktów funkcjonalności i kryteriów akceptacji.
  • Zawsze rób zgrubne notatki o swoich przypadkach testowych i błędach, jeśli nie masz wystarczająco dużo czasu, aby je starannie napisać. Nigdy nie zostawiaj tych nieudokumentowanych. Jeśli jest trochę czasu, podziel się nim ze swoim prowadzącym lub zespołem, aby jeśli czegoś brakuje, mogli to łatwo wskazać.
  • Jeśli Tobie i Twojemu zespołowi brakuje czasu, upewnij się, że błędy są oznaczone w odpowiednim stanie w wiadomości e-mail? Możesz wysłać do zespołu pełną listę błędów i poprosić deweloperów o ich odpowiednie oznaczenie. Zawsze trzymaj piłkę na boisku przeciwnika.
  • Jeśli masz Framework automatyzacji gotowy, użyj tego i unikaj robienia Testowanie ręczne w ten sposób w krótszym czasie możesz pokryć więcej.
  • Unikaj scenariusza „wypuszczenie za 1 godzinę”, chyba że masz 100% pewności, że będziesz w stanie dostarczyć.
  • Na koniec, jak wspomniano powyżej, przygotuj szczegółową wiadomość e-mail z informacją o tym, co jest testowane, co zostało pominięte, powody, zagrożenia, które błędy zostały rozwiązane, co oznacza „opóźnienie” itp.

W ramach kontroli jakości powinieneś ocenić, która część implementacji jest najważniejsza, którą należy przetestować, a które części można pominąć lub przetestować.

Nawet w krótkim czasie zaplanuj strategię dotyczącą tego, jak chcesz osiągnąć, a będziesz w stanie osiągnąć to, co najlepsze w danym przedziale czasowym.

Testowanie dymu

Smoke Testing nie jest wyczerpującym testowaniem, ale jest to grupa testów wykonywanych w celu sprawdzenia, czy podstawowe funkcje tej konkretnej wersji działają prawidłowo, czy nie. Jest to i zawsze powinien być pierwszym testem wykonywanym na „nowej” kompilacji.

Gdy zespół programistów wydaje kompilację do kontroli jakości w celu przetestowania, oczywiście nie jest możliwe przetestowanie całej kompilacji i natychmiastowe sprawdzenie, czy którakolwiek z implementacji zawiera błędy lub czy któraś z działających funkcji jest uszkodzona.

W związku z tym, w jaki sposób kontrola jakości upewni się, że podstawowe funkcje działają prawidłowo?

Odpowiedzią na to będzie wykonanie Testowanie dymu .

Testowanie dymu

Gdy testy zostaną oznaczone jako testy Smoke (w zestawie testów), dopiero wtedy kompilacja zostanie zaakceptowana przez dział kontroli jakości w celu przeprowadzenia dogłębnych testów i / lub regresji. Jeśli którykolwiek z testów dymnych zakończy się niepowodzeniem, kompilacja zostanie odrzucona, a zespół programistów musi naprawić problem i udostępnić nową kompilację do testów.

Teoretycznie test Smoke jest definiowany jako testowanie na poziomie powierzchni w celu poświadczenia, że ​​wersja dostarczona przez zespół programistów zespołowi ds. Kontroli jakości jest gotowa do dalszych testów. Te testy są również wykonywane przez zespół programistów przed udostępnieniem kompilacji zespołowi ds. Kontroli jakości.

Testowanie to jest zwykle używane w testowaniu integracji, testowaniu systemu i testowaniu poziomu akceptacji. Nigdy nie traktuj tego jako substytutu rzeczywistego zakończenia pełnego testu . Zawiera zarówno pozytywne, jak i negatywne testy w zależności od implementacji kompilacji.

Przykłady testowania dymu

To testowanie jest zwykle używane do integracji, akceptacji i Testowanie systemu .

W mojej karierze jako QA zawsze akceptowałem kompilację dopiero po wykonaniu testu dymu. Więc zrozummy, czym jest test dymu z perspektywy wszystkich tych trzech testów, z kilkoma przykładami.

# 1) Testy akceptacyjne

Za każdym razem, gdy kompilacja jest przekazywana do kontroli jakości, test dymny w postaci pliku Testy akceptacyjne powinno być zrobione.

W tym teście pierwszym i najważniejszym testem dymnym jest sprawdzenie podstawowej oczekiwanej funkcjonalności implementacji. W ten sposób powinieneś zweryfikować wszystkie implementacje dla tej konkretnej kompilacji.

Weźmy następujące przykłady jako implementacje wykonane w kompilacji, aby zrozumieć testy dymne dla tych:

  • Zaimplementowano funkcję logowania, aby umożliwić zarejestrowanym sterownikom pomyślne logowanie.
  • Zaimplementowano funkcjonalność pulpitu nawigacyjnego, aby pokazać trasy, które kierowca ma dziś wykonać.
  • Zaimplementowano funkcjonalność pokazującą odpowiedni komunikat w przypadku braku tras na dany dzień.

W powyższej kompilacji, na poziomie akceptacji, test dymny będzie oznaczał sprawdzenie, czy podstawowe trzy implementacje działają poprawnie. Jeśli którykolwiek z tych trzech elementów jest uszkodzony, kontrola jakości powinna odrzucić kompilację.

# 2) Testowanie integracji

Testowanie to jest zwykle wykonywane, gdy poszczególne moduły są wdrażane i testowane. w Testy integracyjne poziom, to testowanie jest wykonywane, aby upewnić się, że wszystkie podstawowe funkcje integracji i kompleksowe funkcje działają prawidłowo, zgodnie z oczekiwaniami.

Może to być integracja dwóch modułów lub wszystkich modułów razem, stąd złożoność testu dymnego będzie się różnić w zależności od poziomu integracji.

Rozważmy następujące przykłady implementacji integracji dla tego testowania:

jak korzystać z pliku jar
  • Wdrożono integrację modułów tras i przystanków.
  • Wdrożono integrację aktualizacji statusu przyjazdu i odzwierciedlają to samo na ekranie przystanków.
  • Zaimplementowano integrację modułów pełnej funkcjonalności od odbioru do dostawy.

W tej kompilacji test dymny nie tylko zweryfikuje te trzy podstawowe implementacje, ale w przypadku trzeciej implementacji w kilku przypadkach zostanie również zweryfikowana pełna integracja. Bardzo pomaga poznanie problemów, które pojawiają się podczas integracji i tych, które pozostały niezauważone przez zespół programistów.

# 3) Testowanie systemu

Jak sama nazwa wskazuje, na poziomie systemu testowanie dymu obejmuje testy najważniejszych i najczęściej używanych przepływów pracy systemu. Odbywa się to dopiero po przygotowaniu i przetestowaniu całego systemu, a te testy na poziomie systemu można również nazwać testami dymu przed testami regresyjnymi.

Przed rozpoczęciem regresji całego systemu, podstawowe cechy od końca do końca są testowane w ramach testu dymu. Zestaw testów dymnych dla całego systemu składa się z kompleksowych przypadków testowych, z których użytkownicy końcowi będą korzystać bardzo często.

Odbywa się to zwykle za pomocą narzędzi do automatyzacji.

Znaczenie w metodologii SCRUM

Obecnie projekty nie są zgodne z metodologią Waterfall w realizacji projektów, w większości wszystkie projekty są zgodne z Agile i SCRUM tylko. W porównaniu z tradycyjną metodą kaskadową, Smoke Testing cieszy się dużym uznaniem w SCRUM i Agile.

W SCRUMie pracowałem 4 lata . A ponieważ wiemy, że w SCRUMie sprinty trwają krócej, dlatego niezwykle ważne jest wykonanie tych testów, aby nieudane kompilacje mogły zostać natychmiast zgłoszone zespołowi programistów i również naprawione.

Oto kilka na wynos na temat znaczenia tego testu w SCRUM:

  • Poza dwutygodniowym sprintem połowa czasu jest przydzielana do kontroli jakości, ale czasami kompilacje do kontroli jakości są opóźnione.
  • W sprintach najlepiej jest, aby zespół zgłaszał problemy na wczesnym etapie.
  • Każda historia ma zestaw kryteriów akceptacji, dlatego testowanie pierwszych 2-3 kryteriów akceptacji jest równe testowaniu dymu tej funkcji. Klienci odrzucają dostawę, jeśli jedno kryterium zawodzi.
  • Wyobraź sobie, co się stanie, jeśli zespół programistów dostarczy Ci kompilację w ciągu 2 dni, a na wersję demonstracyjną pozostaną tylko 3 dni, a natrafisz na awarię podstawowej funkcjonalności.
  • Średnio sprint ma historie w zakresie od 5 do 10, dlatego podczas tworzenia kompilacji ważne jest, aby upewnić się, że każda historia została zaimplementowana zgodnie z oczekiwaniami przed zaakceptowaniem wersji do testów.
  • Kiedy cały system ma zostać przetestowany i poddany regresji, wykonywany jest sprint. Dwa tygodnie może trochę mniej na przetestowanie całego systemu, stąd bardzo ważne jest zweryfikowanie najbardziej podstawowych funkcjonalności przed rozpoczęciem regresji.

Test dymu kontra testy akceptacji konstrukcji

Testowanie dymu jest bezpośrednio związane z testami akceptacji budowy (BAT).

W BAT wykonujemy te same testy - aby sprawdzić, czy kompilacja nie zawiodła i czy system działa dobrze, czy nie. Czasami zdarza się, że podczas tworzenia kompilacji pojawiają się pewne problemy, a po dostarczeniu kompilacja nie działa w przypadku kontroli jakości.

Powiedziałbym, że BAT jest częścią testu dymnego, ponieważ jeśli system zawiedzie, jak możesz jako QA zaakceptować kompilację do testów? Nie tylko funkcje, ale sam system musi działać, zanim QA przejdzie do szczegółowego testowania.

Cykl testu dymu

Poniższy schemat blokowy wyjaśnia cykl testowania dymu.

Po wdrożeniu kompilacji do kontroli jakości podstawowy cykl polega na tym, że jeśli test dymu przejdzie pomyślnie, kompilacja zostanie zaakceptowana przez zespół ds. Kontroli jakości do dalszych testów, ale jeśli się nie powiedzie, kompilacja jest odrzucana do czasu naprawienia zgłoszonych problemów.

Cykl testowy

Cykl testu dymu

Kto powinien przeprowadzić test dymu?

Ikona Who

Nie cały zespół jest zaangażowany w tego typu testy, aby uniknąć marnowania czasu podczas wszystkich kontroli jakości.

Testowanie dymu jest idealnie przeprowadzane przez kierownika ds. Kontroli jakości, który na podstawie wyniku decyduje, czy przekazać kompilację zespołowi do dalszych testów, czy też ją odrzucić. W przypadku braku potencjalnego klienta, zespół kontroli jakości również może przeprowadzić te testy.

Czasami, gdy projekt jest realizowany na dużą skalę, grupa kontroli jakości może również przeprowadzić te testy, aby sprawdzić, czy nie ma żadnych przerywaczy. Jednak w przypadku SCRUM tak nie jest, ponieważ SCRUM jest płaską strukturą bez potencjalnych klientów ani menedżerów, a każdy tester ma własną odpowiedzialność za swoje historie.

Dlatego poszczególne osoby odpowiedzialne za kontrolę jakości przeprowadzają te testy dla artykułów, które są ich właścicielami.

Dlaczego powinniśmy zautomatyzować testy dymu?

To testowanie jest pierwszym testem wykonywanym na kompilacji wydanej przez zespół programistów. Na podstawie wyników tych testów wykonywane są dalsze testy (lub kompilacja jest odrzucana).

Najlepszym sposobem przeprowadzenia tego testu jest użycie narzędzia do automatyzacji i zaplanowanie uruchomienia pakietu dymu po utworzeniu nowej kompilacji. Możesz się zastanawiać, dlaczego powinienem „Zautomatyzować zestaw do testowania dymu”?

Spójrzmy na następujący przypadek:

Powiedzmy, że dzieli Cię tydzień od wydania, a spośród wszystkich 500 przypadków testowych Twój zestaw testów dymu obejmuje 80-90. Jeśli zaczniesz ręcznie wykonywać wszystkie te 80-90 przypadków testowych, wyobraź sobie, ile czasu zajmiesz? Myślę, że 4-5 dni (minimum).

Ale jeśli korzystasz z automatyzacji i tworzysz skrypty do uruchamiania wszystkich tych 80-90 przypadków testowych, najlepiej byłoby, gdyby zostały one uruchomione w ciągu 2-3 godzin, a wyniki będziesz miał natychmiast przy sobie. Czy nie zaoszczędziło to Twojego cennego czasu i nie dało rezultatów związanych z wbudowaniem w znacznie krótszym czasie?

Pięć lat temu testowałem aplikację do prognozowania finansów, która pobierała dane dotyczące Twojego wynagrodzenia, oszczędności itp. I prognozowała Twoje podatki, oszczędności i zyski w zależności od przepisów finansowych. Oprócz tego dostosowaliśmy do krajów zależnych od kraju i jego przepisów podatkowych, które uległy zmianie (w kodzie).

Na potrzeby tego projektu miałem 800 przypadków testowych, a 250 to przypadki testowe z dymem. Używając Selenium, mogliśmy łatwo zautomatyzować i uzyskać wyniki tych 250 przypadków testowych w 3-4 godziny. To nie tylko zaoszczędziło nam czasu, ale pokazało nam jak najszybciej o występach.

Dlatego jeśli nie można zautomatyzować, skorzystaj z pomocy automatyzacji w tym testowaniu.

Zalety i wady

Przyjrzyjmy się najpierw zaletom, ponieważ ma wiele do zaoferowania w porównaniu z kilkoma wadami.

Zalety:

  • Łatwe do wykonania.
  • Zmniejsza ryzyko.
  • Defekty są identyfikowane na bardzo wczesnym etapie.
  • Oszczędza wysiłek, czas i pieniądze.
  • Działa szybko, jeśli jest zautomatyzowany.
  • Najmniej zagrożeń i problemów związanych z integracją.
  • Poprawia ogólną jakość systemu.

Niedogodności:

  • Testowanie to nie jest równe ani nie zastępuje pełnego testowania funkcjonalnego.
  • Nawet po przejściu testu dymu możesz znaleźć błędy showstopper.
  • Ten typ testowania jest najlepszy, jeśli można zautomatyzować, w przeciwnym razie dużo czasu spędza się na ręcznym wykonywaniu przypadków testowych, szczególnie w projektach na dużą skalę, które mają około 700-800 przypadków testowych.

Zdecydowanie należy przeprowadzić testy dymu na każdej kompilacji, ponieważ na bardzo wczesnym etapie wskazuje ono na poważne awarie i występowanie przeszkód. Dotyczy to nie tylko nowych funkcjonalności, ale także integracji modułów, rozwiązywania problemów i improwizacji. Jest to bardzo prosty proces do wykonania i uzyskania prawidłowego wyniku.

Testowanie to można traktować jako punkt wejścia do pełnego testowania funkcjonalnego funkcjonalności lub systemu (jako całości). Ale przed tym, zespół ds. zapewnienia jakości powinien bardzo jasno określić, jakie testy należy wykonać jako testy dymu . Testy te mogą zminimalizować wysiłek, zaoszczędzić czas i poprawić jakość systemu. Zajmuje bardzo ważne miejsce w sprintach, ponieważ czas w sprintach jest krótszy.

Testowanie to można wykonać zarówno ręcznie, jak i za pomocą narzędzi automatyzacji. Ale najlepszym i preferowanym sposobem jest użycie narzędzi automatyzacji, aby zaoszczędzić czas.

Różnica między testem dymu a testem zdrowia psychicznego

W większości przypadków jesteśmy zdezorientowani między znaczeniem testów poczytalności i testów dymu. Po pierwsze, te dwa testy są „ różne ”I wykonywane na różnych etapach cyklu testowego.

S. Nie.Testowanie dymu

Testowanie poczytalności

1 Testowanie dymu oznacza sprawdzenie (podstawowe), czy implementacje wykonane w kompilacji działają poprawnie.Testowanie poprawności oznacza sprawdzenie, czy nowo dodane funkcje, błędy itp. Działają poprawnie.
dwa To pierwsze testy na początkowej kompilacji.Gotowe, gdy kompilacja jest względnie stabilna.
3 Wykonano na każdej kompilacji.Wykonano na stabilnych kompilacjach po regresji.

Poniżej znajduje się schematyczne przedstawienie ich różnic:

SmokeTesting

TESTY DYMU

  • To testowanie pochodzi z sprzęt komputerowy testowanie praktyki włączania nowego sprzętu po raz pierwszy i uznawania go za sukces, jeśli nie zapali się i nie dymi. W branży oprogramowania testowanie to płytkie i szerokie podejście, w ramach którego testowane są wszystkie obszary aplikacji bez wchodzenia zbyt głęboko.
  • Test dymny jest oparty na skrypcie, przy użyciu pisemnego zestawu testów lub testu automatycznego
  • Test Smoke ma na celu dotknięcie każdej części aplikacji w pobieżny sposób. Jest płytkie i szerokie.
  • Testy te są przeprowadzane w celu upewnienia się, czy działają najważniejsze funkcje programu, ale bez zawracania sobie głowy drobniejszymi szczegółami. (Na przykład weryfikacja kompilacji).
  • To testowanie to normalna kontrola stanu kompilacji aplikacji przed przystąpieniem do jej dogłębnego przetestowania.

TESTY POCZĄTKOWE

  • Test poczytalności to wąski test regresji, który koncentruje się na jednym lub kilku obszarach funkcjonalności. Testy poczytalności są zwykle wąskie i głębokie.
  • Ten test jest zwykle nieskryptowany.
  • Ten test służy do określenia, czy niewielka część aplikacji nadal działa po niewielkiej zmianie.
  • To testowanie jest pobieżne, jest wykonywane za każdym razem, gdy pobieżne testy są wystarczające, aby udowodnić, że aplikacja działa zgodnie ze specyfikacjami. Ten poziom testowania jest podzbiorem testów regresji.
  • Ma to na celu sprawdzenie, czy wymagania są spełnione, czy nie, sprawdzając najpierw wszystkie funkcje.

Mam nadzieję, że rozumiesz różnice między tymi dwoma ogromnymi i ważnymi typami testowania oprogramowania. Podziel się swoimi przemyśleniami w sekcji komentarzy poniżej !!

rekomendowane lektury

^