Co to są testy jednostkowe, testy integracyjne, testy dymu i testy regresji?

731

Co to są testy jednostkowe, testy integracyjne, testy dymu i testy regresji? Jakie są między nimi różnice i jakich narzędzi mogę użyć dla każdego z nich?

Na przykład używam JUnit i NUnit do testowania jednostkowego i testowania integracji . Czy są jakieś narzędzia do ostatnich dwóch testów dymu lub regresji ?

caltuntas
źródło
2
Powiązane: stackoverflow.com/questions/437897/…
Bill the Lizard
1
Inni już dobrze odpowiedzieli, ale chciałbym dodać, że osobiście uważam, że test dymu i test regresji są zbędne. Robią to samo: przetestuj, aby upewnić się, że zmiany w systemie niczego nie zepsuły.
Randolpho
15
Myślę, że różnią się one znacznie od testów regresji. Myślę, że są to celowo „lekkie” szybkie testy, które są uruchamiane na początku, aby zaoszczędzić czas, ponieważ jeśli któryś z nich zawiedzie, wiesz, że nie warto zawracać sobie głowy dodatkowymi testami. np. Czy klient może połączyć się z bazą danych, czy jest zainstalowany .net, czy jest zainstalowana poprawna wersja ... Być może masz również wdrożenie wstępne (aktualizujemy z wersji 1 do wersji 1.1, więc sprawdź, czy wersja 1 jest zainstalowana) i post- wdrażanie testów dymu.
AndyM
Testy dymu są zgodne z opisem AndyM. Ale są też rodzajem testu regresji.
kevin mcdonnell,
2
Powiązane: stackoverflow.com/questions/4904096/…
rogerdpack

Odpowiedzi:

1044
  • Test jednostkowy : Określ i przetestuj jeden punkt kontraktu na jedną metodę klasy. Powinno to mieć bardzo wąski i dobrze określony zakres. Złożone zależności i interakcje ze światem zewnętrznym są zagubione lub wyszydzone .

  • Test integracji : przetestuj poprawne współdziałanie wielu podsystemów. Jest tam całe spektrum, od testowania integracji między dwiema klasami, po testowanie integracji ze środowiskiem produkcyjnym.

  • Test dymu (inaczej sprawdzanie czystości ) : Prosty test integracji, w którym sprawdzamy, czy po uruchomieniu testowanego systemu powraca on normalnie i nie wysadza się w powietrze.

    • Testowanie dymu jest zarówno analogią do elektroniki, gdzie pierwszy test ma miejsce podczas włączania obwodu (jeśli pali, to źle!) ...
    • ... i najwyraźniej z hydrauliką , gdzie system rur jest dosłownie wypełniony dymem, a następnie sprawdzany wizualnie. Jeśli coś pali, system jest nieszczelny.
  • Test regresji : test napisany po naprawieniu błędu. Zapewnia to, że ten konkretny błąd nie wystąpi ponownie. Pełna nazwa to „test nieregresyjny”. Może to być również test wykonany przed zmianą aplikacji, aby upewnić się, że aplikacja zapewnia ten sam wynik.

Do tego dodam:

  • Test akceptacyjny : Sprawdź, czy funkcja lub przypadek użycia jest poprawnie zaimplementowany. Jest podobny do testu integracji, ale z naciskiem na przypadek użycia, a nie na zaangażowane komponenty.

  • Test systemu : Testuje system jako czarną skrzynkę. Zależności od innych systemów są często wyśmiewane lub usuwane podczas testu (w przeciwnym razie byłby to bardziej test integracyjny).

  • Kontrola przed lotem : testy powtarzane w środowisku produkcyjnym w celu złagodzenia syndromu „build on my machine”. Często realizuje się to poprzez przeprowadzenie testu akceptacji lub próby dymu w środowisku produkcyjnym.

ddaa
źródło
250
Testy dymu wyprzedzają elektronikę o sto lat i pochodzą z kanalizacji, kiedy system rur został wypełniony rzeczywistym dymem, a następnie sprawdzony wizualnie. Jeśli paliło, było nieszczelne.
SnakE
2
Testy regresji są również stosowane do zmian funkcji, a nie tylko do naprawiania błędów. Poniższa odpowiedź Nikity jest bardziej wyczerpującą definicją.
BobRodes,
25
@AndyM Tło „testu dymu” jest niedokładne. IIRC pochodzi z kanalizacji, gdzie dym jest pompowany w systemie rur po jego zbudowaniu (i zanim zostanie podłączony do sieci wodociągowej). Jeśli pojawi się dym, rury nie są odpowiednio uszczelnione. Jest to mniej szkodliwe niż faktyczne przepuszczanie wody i sprawdzanie, czy występują jakiekolwiek kałuże (możliwe uszkodzenie ścian / murów w trakcie procesu). To przybliżone przybliżenie, że system nie zawiedzie katastrofalnie. Proces tworzenia może być następujący: „Kompilacja” przeszła? => „Test dymu” przeszedł? => „Test akceptacyjny” przeszedł => do zespołu kontroli jakości w celu przeprowadzenia szczegółowych testów.
Cristian Diaconescu
4
Uważam, że popełniłeś błąd, stwierdzając, że „test regresji” naprawdę jest skrótem dla „testu nieregresji”? Jestem sceptyczny, po części dlatego, że jest to po prostu nieintuicyjne i mylące (choć istnieje wiele terminów), ale także Wikipedia ma dwa osobne artykuły na temat testów regresji i braku regresji. Artykuł na temat testowania regresji mówi nawet: Kontrast z testowaniem nieregresyjnym ... który ma na celu sprawdzenie, czy po wprowadzeniu lub aktualizacji danej aplikacji zmiana ma zamierzony skutek.
Brian C
2
@ddaa Testy sanity i testy dymu nie są takie same. Testy poczytalności są przeprowadzane po tym, jak kompilacja zakończy test dymu i zostanie zaakceptowana przez zespół kontroli jakości do dalszych testów, testy poczytalności sprawdzają główną funkcjonalność z dokładniejszymi szczegółami.
Bharat
105
  • Test jednostkowy : automatyczny test sprawdzający wewnętrzne funkcjonowanie klasy. Powinien to być samodzielny test niezwiązany z innymi zasobami.
  • Test integracji : automatyczny test przeprowadzany w środowisku, podobny do testów jednostkowych, ale z zasobami zewnętrznymi (db, dostęp do dysku)
  • Test regresji : po wdrożeniu nowych funkcji lub poprawek błędów ponownie testujesz scenariusze, które działały w przeszłości. W tym miejscu omówiono możliwość, w której nowe funkcje niszczą istniejące.
  • Testowanie dymu : pierwsze testy, na których testerzy mogą stwierdzić, czy będą kontynuować testowanie.
Gerrie Schenck
źródło
2
Definicja testu regresji nie jest dokładnie taka, jaka jest. @ddaa definiuje to poprawnie.
Robert Koritnik,
Definicja testu integracji jest zdecydowanie rozmyta. Na przykład w odpowiedzi tutaj stackoverflow.com/a/4904533/32453 jest bardziej zdefiniowany jako testowanie wielu interakcji twojego kodu, niekoniecznie wymagający prawdziwej bazy danych (zasoby zewnętrzne) ... chociaż niektórzy ludzie definiują to tak, jak opisałeś ... ahh terminologia. (Wolę nieco poprzednią definicję, FWIW, testowanie wielu interakcji.)
rogerdpack
Proszę zobaczyć moje pytanie: stackoverflow.com/questions/61711739/…
milad salimi
To odpowiada tytułowi, ale nie dotyczy narzędzi do dwóch ostatnich rodzajów testów, testów dymu lub regresji .
Peter Mortensen
90

Każdy będzie miał nieco inne definicje i często są szare obszary. Jednak:

  • Test jednostkowy: czy to trochę (jak najbardziej izolowane) działa?
  • Test integracji: czy te dwa (lub więcej) składniki działają razem?
  • Test dymu: czy cały ten system (tak blisko bycia systemem produkcyjnym, jak to możliwe) dobrze się łączy? (tzn. czy mamy wystarczającą pewność, że nie stworzy czarnej dziury?)
  • Test regresji: czy przypadkowo wprowadziliśmy jakieś błędy, które wcześniej naprawiliśmy?
Jon Skeet
źródło
Jak oceniacie testy integracyjne w odniesieniu do testów jednostkowych? Jeśli myprj jest to główny katalog projektu i mypkgznajduje się pod myprj, mam testy jednostkowe pod myprj/tests/test_module1.py, a mój pakiet pod myprj/mypkg. Działa to świetnie w przypadku testów jednostkowych, ale zastanawiam się, czy istnieje jakakolwiek konwencja. Powinienem śledzić, gdzie powinny się znajdować testy integracyjne?
alpha_989
1
@ alpha_989: Nie wiem, jaka byłaby konwencja dla Pythona. W .NET mam obecnie kod produkcyjny, testy jednostkowe i testy integracyjne w trzech oddzielnych projektach, wzajemnie od siebie nawzajem - ale jest też wiele alternatyw.
Jon Skeet
Ok dzięki. Mogłem znaleźć standardową rekomendację inną niż spojrzenie na inny projekt Pythona. ale pójdę za tobą ..
alpha_989
Proszę zobaczyć moje pytanie: stackoverflow.com/questions/61711739/…
milad salimi
@miladsalimi: Nie dodawaj niepowiązanych komentarzy tylko w celu zwrócenia uwagi na inne pytanie. Widzę, że zrobiłeś to na czterech innych postach - proszę nie.
Jon Skeet
51

Nowa kategoria testów, o której właśnie się dowiedziałem, to test kanaryjski . Test kanarkowy to zautomatyzowany, nieniszczący test, który jest przeprowadzany regularnie w środowisku na żywo , tak że jeśli kiedykolwiek zawiedzie, wydarzy się coś naprawdę złego.

Przykładami mogą być:

  • Czy dane, które powinny być dostępne tylko w fazie rozwoju / testów, pojawiły się na żywo ?
  • Czy proces w tle nie został uruchomiony?
  • Czy użytkownik może się zalogować?
AndyM
źródło
2
Czy strona może być pingowana w ogóle - odpowiednio, istnieje usługa o nazwie Binary Canary.
Dan Dascalescu
15
Nazwa pochodzi od wydobycia węgla: zabierz ze sobą kanarka „na dół”. Kiedy go zgasi, wydostań się szybko. Kanarki są bardzo wrażliwe na małe stężenia szkodliwych gazów i umrą, zanim poziomy stężeń staną się toksyczne dla ludzi. Jeśli test Canary nie powiedzie się, napraw go szybko, ponieważ upłynie tylko trochę czasu, zanim LIVE zakończy się niepowodzeniem.
Robino
1
Sposób, w jaki używamy testów Canary w mojej pracy, polega na przeniesieniu kilku klientów do nowej wersji, a nie wszystkich jednocześnie. Jeśli kilku pierwszych klientów przeżyje, możemy dodać resztę. Te pierwsze to kanarki.
00prometheus
2
@ 00prometheus, to testy beta.
GregNash
1
@HarveyLin, chociaż test Canary jest koniecznie testem, który zapobiega katastrofie, oczywiście nie jest on używany tylko w ten sposób. Ale zasada jest „test ten pracuje, bo to jest krytyczna”. Oczywiście, każdy test ma prawie ten sam cel, ale koncepcja jest bardzo konkretna. W twoim przypadku nie liczyłbym wszystkich testów jako testów kanaryjskich.
Charles Roberto Canato,
11

Odpowiedź z jednej z najlepszych stron internetowych dotyczących technik testowania oprogramowania:

Rodzaje testowania oprogramowania - pełna lista kliknij tutaj

Wpisz opis zdjęcia tutaj

To dość długi opis i nie zamierzam go tutaj wklejać, ale może być pomocny dla kogoś, kto chce poznać wszystkie techniki testowania.

Kaleem Ullah
źródło
10

Test jednostkowy: sprawdzenie, czy dany komponent (tj. Klasa) utworzył lub zmodyfikował funkcje zgodnie z projektem. Ten test może być ręczny lub automatyczny, ale nie wykracza poza granice komponentu.

Test integracji: sprawdzenie, czy interakcja poszczególnych komponentów działa zgodnie z planem. Testy integracyjne można wykonać na poziomie jednostki lub systemu. Testy te mogą być ręczne lub automatyczne.

Test regresji: sprawdzenie, czy nowe defekty nie są wprowadzane do istniejącego kodu. Testy te mogą być ręczne lub automatyczne.

W zależności od SDLC ( wodospad , RUP , zwinny itp.) Poszczególne testy mogą być wykonywane „fazami” lub mogą być wykonywane mniej więcej w tym samym czasie. Na przykład testowanie jednostkowe może być ograniczone do programistów, którzy następnie przekazują kod testerom do testów integracji i regresji. Jednak w innym podejściu programiści mogą przeprowadzać testy jednostkowe oraz testy integracji i regresji na pewnym poziomie (stosując podejście TDD wraz z ciągłą integracją oraz automatycznymi testami jednostkowymi i regresyjnymi).

Zestaw narzędzi będzie zależeć w dużej mierze od bazy kodu, ale istnieje wiele narzędzi open source do testowania jednostkowego (JUnit). Testy HP (Mercury) QTP lub Silkland firmy Borland są narzędziami do automatycznej integracji i testów regresji.

rdrex
źródło
To jedna z niewielu odpowiedzi, która zawiera coś o narzędziach.
Peter Mortensen
8

Test jednostkowy : testowanie pojedynczego modułu lub niezależnego komponentu w aplikacji jest znane jako testowanie jednostkowe. Testy jednostkowe zostaną przeprowadzone przez programistę.

Test integracji : połączenie wszystkich modułów i przetestowanie aplikacji w celu zweryfikowania komunikacji i przepływu danych między modułami działa poprawnie lub nie. Testy te przeprowadzają także programiści.

Test dymu Podczas testu dymu sprawdzają aplikację w płytki i szeroki sposób. W testach dymu sprawdzają główną funkcjonalność aplikacji. Jeśli w aplikacji występuje jakikolwiek problem z blokowaniem, zgłaszają się do zespołu programistów, a zespół programistów naprawi go i usunie usterkę, a następnie zwróci zespołowi testującemu. Teraz zespół testujący sprawdzi wszystkie moduły, aby sprawdzić, czy zmiany dokonane w jednym module wpłyną na drugi moduł, czy nie. W testach dymu przypadki testowe są skryptowane.

Testy regresyjne wykonujące wielokrotnie te same przypadki testowe w celu upewnienia się, że niezmieniony moduł nie spowoduje żadnej wady. Testy regresji podlegają testom funkcjonalnym

malini
źródło
To odpowiada tytułowi, ale nie dotyczy narzędzi do dwóch ostatnich rodzajów testów, testów dymu lub regresji. Powtarza także poprzednie odpowiedzi - można je uczynić unikalnymi, odpowiadając na pytanie dotyczące narzędzi.
Peter Mortensen
7

TESTOWANIE REJESTRACJI

„Test regresji ponownie uruchamia poprzednie testy zmienionego oprogramowania, aby upewnić się, że zmiany wprowadzone w bieżącym oprogramowaniu nie wpływają na funkcjonalność istniejącego oprogramowania”.

Nikita G.
źródło
18
Skąd cytujesz?
Daryl
4
Według tej strony cytat ten pochodzi z artykułu z Wikipedii „Testowanie oprogramowania”, choć wydaje się, że fragment został w pewnym momencie zmieniony od 2010 roku.
Zach Lysobey,
W każdym razie WP nie jest prawidłowym źródłem. Źródła, do których istnieją odniesienia, mogą być prawidłowe. W WP nie ma żadnych ważnych źródeł, o których mowa, ani w artykułach, ani na stronach dyskusji, które potwierdzałyby twierdzenie, że „nie” robi jakąkolwiek różnicę. Porównałem fragmenty tekstu na listach wyników z wyszukiwań w Książkach Google zarówno dla, jak "regression test"i "non-regression test". To jest to samo.
Rainald62
To odpowiada (części) tytułowi, ale nie dotyczy narzędzia do dwóch ostatnich rodzajów testów, testów dymu lub regresji. Powtarza także poprzednie odpowiedzi - można je uczynić unikalnymi, odpowiadając na pytanie dotyczące narzędzi.
Peter Mortensen
7

Chciałem tylko dodać i podać nieco więcej informacji na temat tego, dlaczego mamy te poziomy testów, co tak naprawdę oznaczają w przykładach

Mike Cohn w swojej książce „Successful with Agile” zaproponował „Testing Pyramid” jako sposób na podejście do automatycznych testów w projektach. Istnieją różne interpretacje tego modelu. Model wyjaśnia, jakie rodzaje testów automatycznych należy utworzyć, jak szybko mogą przekazywać informacje zwrotne na temat testowanej aplikacji i kto je pisze. Istnieją 3 poziomy automatycznych testów potrzebnych do każdego projektu i są one następujące.

Testy jednostkowe najmniejszy komponent aplikacji. Może to być dosłownie jedna funkcja w kodzie, która oblicza wartość na podstawie niektórych danych wejściowych. Ta funkcja jest częścią kilku innych funkcji bazy kodu sprzętowego / programowego tworzącego aplikację.

Na przykład - weźmy kalkulator internetowy. Najmniejsze komponenty tej aplikacji, które muszą zostać przetestowane jednostkowo, mogą być funkcją wykonującą dodawanie, inną, która wykonuje odejmowanie i tak dalej. Wszystkie te małe funkcje razem tworzą aplikację kalkulatora.

Historycznie programista pisze te testy, ponieważ są one zwykle pisane w tym samym języku programowania, co aplikacja. W tym celu wykorzystywane są środowiska do testowania jednostkowego, takie jak JUnit i NUnit (dla java), MSTest (dla C # i .NET) oraz Jasmine / Mocha (dla JavaScript).

Największą zaletą testów jednostkowych jest to, że działają one bardzo szybko pod interfejsem użytkownika i możemy uzyskać szybką informację zwrotną na temat aplikacji. Powinno to stanowić ponad 50% zautomatyzowanych testów.

Testy API / integracji różne komponenty systemu oprogramowania. Komponenty mogą obejmować testowanie baz danych, API (interfejs programowania aplikacji), narzędzia i usługi innych firm wraz z aplikacją.

Na przykład - w powyższym przykładzie kalkulatora aplikacja internetowa może używać bazy danych do przechowywania wartości, używać interfejsów API do przeprowadzania niektórych weryfikacji po stronie serwera i może używać narzędzia / usługi innej firmy do publikowania wyników w chmurze, aby udostępniać je w różnych platformy.

Historycznie deweloper lub techniczna QA pisała te testy przy użyciu różnych narzędzi, takich jak Postman, SoapUI, JMeter i innych narzędzi, takich jak Testim.

Działają one znacznie szybciej niż testy interfejsu użytkownika, ponieważ nadal działają pod maską, ale mogą pochłonąć nieco więcej czasu niż testy jednostkowe, ponieważ musi on sprawdzić komunikację między różnymi niezależnymi komponentami systemu i zapewnić ich bezproblemową integrację. Powinno to stanowić ponad 30% testów automatycznych.

Testy interfejsu użytkownika - Na koniec mamy testy, które sprawdzają poprawność interfejsu użytkownika aplikacji. Testy te są zwykle zapisywane w celu przetestowania przepływów końcowych przez aplikację.

Na przykład - W aplikacji kalkulatora przepływ może przebiegać od końca do końca, otwieranie przeglądarki-> Wprowadzanie adresu URL aplikacji kalkulatora -> Logowanie za pomocą nazwy użytkownika / hasła -> Otwieranie aplikacji kalkulatora -> Wykonywanie niektórych operacji na kalkulatorze -> weryfikacja tych wyników z interfejsu użytkownika -> Wylogowanie z aplikacji. Może to być jeden do końca przepływ, który byłby dobrym kandydatem do automatyzacji interfejsu użytkownika.

Historycznie techniczni testerzy jakości lub testerzy ręczni piszą testy interfejsu użytkownika. Używają platform open source, takich jak Selenium lub platformy testujące interfejs użytkownika, takie jak Testim, do tworzenia, wykonywania i utrzymywania testów. Testy te dają więcej wizualnych informacji zwrotnych, ponieważ można zobaczyć, jak przebiegają testy, różnicę między oczekiwanymi a rzeczywistymi wynikami za pomocą zrzutów ekranu, dzienników, raportów z testów.

Największym ograniczeniem testów interfejsu użytkownika jest to, że są one stosunkowo wolne w porównaniu do testów na poziomie jednostki i interfejsu API. Powinien zatem stanowić jedynie 10–20% ogólnych zautomatyzowanych testów.

Kolejne dwa typy testów mogą się różnić w zależności od projektu, ale pomysł jest następujący:

Testy dymu

Może to być kombinacja powyższych 3 poziomów testowania. Chodzi o to, aby uruchamiać go podczas każdego sprawdzania kodu i upewnić się, że krytyczne funkcje systemu nadal działają zgodnie z oczekiwaniami; po scaleniu zmian w nowym kodzie. Zwykle muszą pracować z 5–10 minutami, aby uzyskać szybszą informację zwrotną na temat awarii

Testy regresji

Zazwyczaj są one uruchamiane co najmniej raz dziennie i obejmują różne funkcje systemu. Zapewniają, że aplikacja nadal działa zgodnie z oczekiwaniami. Są one bardziej szczegółowe niż testy dymu i obejmują więcej scenariuszy aplikacji, w tym te niekrytyczne.

Raj Subrameyer
źródło
Odpowiedź można poprawić, odpowiadając na pytanie dotyczące narzędzi do testowania dymu lub regresji .
Peter Mortensen
5

Testy jednostkowe są ukierunkowane na najmniejszą możliwą część wdrożenia. W Javie oznacza to, że testujesz pojedynczą klasę. Jeśli klasa zależy od innych klas, są one sfałszowane.

Gdy test wywołuje więcej niż jedną klasę, jest to test integracyjny .

Uruchomienie pełnych pakietów testowych może zająć dużo czasu, więc po zmianie wiele zespołów przeprowadza szybkie testy, aby wykryć poważne uszkodzenia. Na przykład uszkodziłeś identyfikatory URI do niezbędnych zasobów. To są testy dymu .

Testy regresji są uruchamiane na każdej kompilacji i pozwalają skutecznie refaktoryzować przechwytując to, co psujesz. Każdy rodzaj testu może być testem regresji, ale uważam, że testy jednostkowe są najbardziej pomocne w znalezieniu źródła błędu.

Dave
źródło
To odpowiada tytułowi, ale nie dotyczy narzędzi do dwóch ostatnich rodzajów testów, testów dymu lub regresji. Powtarza także poprzednie odpowiedzi - można je uczynić unikalnymi, odpowiadając na pytanie dotyczące narzędzi.
Peter Mortensen
4
  • Testy integracyjne: Testy integracyjne to zintegrowany kolejny element
  • Testowanie dymu: Testowanie dymu jest również znane jako testowanie wersji kompilacji. Testowanie dymu jest początkowym procesem testowania przeprowadzanym w celu sprawdzenia, czy testowane oprogramowanie jest gotowe / stabilne do dalszych testów.
  • Testy regresji: Testy regresji są testami powtarzanymi . Czy nowe oprogramowanie jest realizowane w innym module, czy nie.
  • Testowanie jednostkowe: jest to badanie białej skrzynki. Zaangażowani są tylko programiści
Madhivanan
źródło
To odpowiada tytułowi, ale nie dotyczy narzędzi do dwóch ostatnich rodzajów testów, testów dymu lub regresji. Powtarza także poprzednie odpowiedzi - można je uczynić unikalnymi, odpowiadając na pytanie dotyczące narzędzi.
Peter Mortensen
3

Test jednostkowy: sprawdzenie, czy dany komponent (tj. Klasa) utworzył lub zmodyfikował funkcje zgodnie z projektem. Ten test może być ręczny lub automatyczny, ale nie wykracza poza granice komponentu.

Test integracji: sprawdzenie, czy interakcja poszczególnych komponentów działa zgodnie z planem. Testy integracyjne można wykonać na poziomie jednostki lub systemu. Testy te mogą być ręczne lub automatyczne.

Test regresji: sprawdzenie, czy nowe defekty nie są wprowadzane do istniejącego kodu. Testy te mogą być ręczne lub automatyczne.

W zależności od SDLC (wodospad, rup, zwinność itp.) Poszczególne testy mogą być wykonywane „fazami” lub mogą być wykonywane mniej więcej w tym samym czasie. Na przykład testowanie jednostkowe może być ograniczone do programistów, którzy następnie przekazują kod testerom do testów integracji i regresji. Jednak w innym podejściu programiści mogą przeprowadzać testy jednostkowe oraz testy integracji i regresji na pewnym poziomie (stosując podejście TDD wraz z ciągłą integracją oraz automatycznymi testami jednostkowymi i regresyjnymi).

nhfghfgsq
źródło
Jest to hurtowo plagiat innej odpowiedzi na to samo pytanie przepełnienia stosu (odpowiedź wysłana ponad cztery lata wcześniej).
Peter Mortensen
3

Testy jednostkowe Testy jednostkowe są na bardzo niskim poziomie, blisko źródła twojej aplikacji. Polegają one na testowaniu poszczególnych metod i funkcji klas, komponentów lub modułów używanych przez oprogramowanie. Testy jednostkowe są generalnie dość tanie w automatyzacji i mogą być przeprowadzane bardzo szybko przez serwer ciągłej integracji.

Testy integracyjne Testy integracyjne sprawdzają, czy różne moduły lub usługi używane przez aplikację działają dobrze. Na przykład może to być testowanie interakcji z bazą danych lub upewnianie się, że mikrousługi działają razem zgodnie z oczekiwaniami. Tego typu testy są droższe, ponieważ wymagają wielu części aplikacji do uruchomienia.

Testy funkcjonalne Testy funkcjonalne koncentrują się na biznesowych wymaganiach aplikacji. Sprawdzają jedynie wynik działania i nie sprawdzają stanów pośrednich systemu podczas wykonywania tego działania.

Czasami występuje pomyłka między testami integracji i testami funkcjonalnymi, ponieważ oba wymagają interakcji wielu komponentów. Różnica polega na tym, że test integracji może po prostu zweryfikować, czy można wykonać zapytanie do bazy danych, podczas gdy test funkcjonalny spodziewałby się uzyskać określoną wartość z bazy danych zgodnie z wymaganiami produktu.

Testy kompleksowe Testy kompleksowe replikują zachowanie użytkownika w oprogramowaniu w kompletnym środowisku aplikacji. Sprawdza, czy różne przepływy użytkowników działają zgodnie z oczekiwaniami i mogą być tak proste, jak załadowanie strony internetowej lub zalogowanie się lub znacznie bardziej złożone scenariusze weryfikujące powiadomienia e-mail, płatności online itp.

Kompleksowe testy są bardzo przydatne, ale są drogie w wykonaniu i mogą być trudne do utrzymania, gdy są zautomatyzowane. Zaleca się przeprowadzenie kilku kluczowych testów end-to-end i poleganie w większym stopniu na testach niższego poziomu (testy jednostkowe i integracyjne), aby móc szybko zidentyfikować przełomowe zmiany.

Testy akceptacyjne Testy akceptacyjne to testy formalne wykonywane w celu sprawdzenia, czy system spełnia wymagania biznesowe. Wymagają one uruchomienia całej aplikacji i skupienia się na replikowaniu zachowań użytkowników. Mogą jednak pójść dalej i zmierzyć wydajność systemu i odrzucić zmiany, jeśli określone cele nie zostaną osiągnięte.

Test wydajności wydajnościowe Testy wydajnościowe sprawdzają zachowanie systemu, gdy jest on pod znacznym obciążeniem. Testy te są niefunkcjonalne i mogą przybierać różne formy, aby zrozumieć niezawodność, stabilność i dostępność platformy. Na przykład może obserwować czasy odpowiedzi podczas wykonywania dużej liczby żądań lub sprawdzać, jak zachowuje się system z dużą ilością danych.

Testy wydajności są z natury dość kosztowne we wdrożeniu i uruchomieniu, ale mogą pomóc ci zrozumieć, czy nowe zmiany spowodują degradację twojego systemu.

Testy dymu Testy dymu to podstawowe testy sprawdzające podstawową funkcjonalność aplikacji. Mają być szybkie do wykonania, a ich celem jest zapewnienie, że główne funkcje systemu działają zgodnie z oczekiwaniami.

Testy dymu mogą być przydatne zaraz po wykonaniu nowej kompilacji, aby zdecydować, czy można uruchomić droższe testy, lub bezpośrednio po wdrożeniu, aby upewnić się, że aplikacja działa poprawnie w nowo wdrożonym środowisku.

Źródło: https://www.atlassian.com/continuous-delivery/software-testing/types-of-software-testing

令狐 葱
źródło
Definicja testowania dymu tutaj jest dość słaba. Każdy test niskiego poziomu może być „testem podstawowym sprawdzającym podstawową funkcjonalność aplikacji”. Najlepszym kandydatem do tej definicji są testy jednostkowe. Test jednostkowy testuje jednostkę aplikacji (jak sama nazwa wskazuje), a jednostka jest rzeczywiście podstawową funkcjonalnością (w zależności od definicji funkcjonalności). Najlepszą definicją wydaje się ta podana przez @ddaa
yerlilbilgin
2

Testy jednostkowe: zawsze wykonuje je programista po ich opracowaniu, aby dowiedzieć się o problemie ze strony testowej, zanim przygotują jakiekolwiek wymagania do kontroli jakości.

Testy integracyjne: Oznacza to, że tester musi zweryfikować weryfikację modułu do podmodułu, gdy niektóre dane / funkcje są kierowane do jednego modułu do innego modułu. Lub w systemie, jeśli korzystasz z narzędzia innej firmy, które wykorzystuje dane systemowe do integracji.

Testowanie dymu: tester przeprowadzony w celu weryfikacji systemu na potrzeby testów wysokiego poziomu i próby znalezienia błędu zatrzymania show przed wprowadzeniem zmian lub kodu.

Testowanie regresji: Tester przeprowadził regresję w celu weryfikacji istniejącej funkcjonalności ze względu na zmiany wprowadzone w systemie w celu rozszerzenia lub zmian w systemie.

Krunal
źródło
Czy nie musimy tworzyć testu przed faktycznym opracowaniem?
Vin Shahrdar
@VShShahrdar, Czy mówisz o testowaniu jednostkowym?
Krunal
tak. Zwykle tworzę testy jednostkowe przed napisaniem kodu produkcyjnego. Tak powinieneś to zrobić, prawda?
Vin Shahrdar,
1
Tak .. Ale testy jednostkowe przeprowadzane są także przed kontrolą jakości, przed którą stoi programista. Przed wdrożeniem kodu na serwerze QA dev zawsze przeprowadza testy jednostkowe
Krunal
2

Testów jednostkowych

Testy jednostkowe są zwykle wykonywane przez programistów, podczas gdy testerzy są częściowo ewoluowani w tego typu testach, w których testowanie odbywa się jednostkowo. W Javie JUnit przypadki testowe mogą również umożliwiać sprawdzenie, czy napisany kod jest doskonale zaprojektowany, czy nie.

Testy integracyjne:

Ten rodzaj testowania jest możliwy po testach jednostkowych, gdy wszystkie / niektóre komponenty są zintegrowane. Tego rodzaju testy upewnią się, że zintegrowane komponenty wpływają na wzajemne możliwości pracy lub funkcjonalności?

Testowanie dymu

Ten rodzaj testowania jest wykonywany na końcu, gdy system zostanie pomyślnie zintegrowany i będzie gotowy do pracy na serwerze produkcyjnym.

Ten rodzaj testowania sprawi, że każda ważna funkcja od początku do końca będzie działać poprawnie, a system będzie gotowy do wdrożenia na serwerze produkcyjnym.

Testy regresji

Ten rodzaj testowania jest ważny, aby sprawdzić, czy niezamierzone / niechciane defekty nie występują w systemie, gdy programista naprawił niektóre problemy. Testy te zapewniają również, że wszystkie błędy zostały pomyślnie rozwiązane i dlatego nie występują inne problemy.

mohit sarsar
źródło
To odpowiada tytułowi, ale nie dotyczy narzędzi do dwóch ostatnich rodzajów testów, testów dymu lub regresji. Powtarza także poprzednie odpowiedzi - można je uczynić unikalnymi, odpowiadając na pytanie dotyczące narzędzi.
Peter Mortensen
2

Testy dymu i poczytalności są wykonywane po kompilacji oprogramowania w celu ustalenia, czy rozpocząć testowanie. Poczytalność może, ale nie musi, zostać wykonana po badaniu dymu. Mogą być wykonywane osobno lub w tym samym czasie - zdrowie psychiczne jest natychmiast po dymie.

Ponieważ testy poczytalności są bardziej dogłębne i zajmują więcej czasu, w większości przypadków warto zautomatyzować.

Wykonanie testu dymu zwykle trwa nie dłużej niż 5-30 minut. Jest bardziej ogólna: sprawdza niewielką liczbę podstawowych funkcji całego systemu, aby sprawdzić, czy stabilność oprogramowania jest wystarczająca do dalszych testów i czy nie ma żadnych problemów, blokując przebieg planowanych przypadków testowych.

Testy rozsądku są bardziej szczegółowe niż dym i mogą trwać od 15 minut do całego dnia, w zależności od skali nowej wersji. Jest to bardziej wyspecjalizowany typ testów akceptacyjnych, przeprowadzanych po progresji lub ponownym testowaniu. Sprawdza podstawowe funkcje niektórych nowych funkcji i / lub poprawki błędów wraz z niektórymi ściśle z nimi powiązanymi funkcjami, aby zweryfikować, czy działają one zgodnie z wymaganą logiką operacyjną, zanim testy regresyjne będą mogły zostać wykonane na większą skalę.

Radostta
źródło
Rozwija to nieco, ale nie chodzi o narzędzia do dwóch ostatnich rodzajów testów, do testów dymu lub testów regresji . Można go uczynić wyjątkowym, odpowiadając na pytanie dotyczące narzędzi.
Peter Mortensen
1

Istnieje już kilka dobrych odpowiedzi, ale chciałbym je dopracować:

Testowanie jednostkowe jest tutaj jedyną formą testowania białych skrzynek. Pozostałe to testy czarnej skrzynki. Testowanie w białej skrzynce oznacza, że ​​znasz dane wejściowe; znasz wewnętrzne działanie mechanizmu i możesz go sprawdzić i znasz wynik. Dzięki testom czarnej skrzynki wiesz tylko, co to jest wejście i jakie powinno być wyjście.

Tak więc testowanie jednostkowe jest tutaj jedynym testem w białej skrzynce.

  • Testy jednostkowe testują określone fragmenty kodu. Zazwyczaj metody.
  • Testy integracyjne sprawdzają, czy nowe oprogramowanie może integrować się ze wszystkim innym.
  • Testy regresji. Testy są wykonywane, aby upewnić się, że niczego nie zepsułeś. Wszystko, co kiedyś działało, powinno nadal działać.
  • Testowanie dymu odbywa się jako szybki test, aby upewnić się, że wszystko wygląda dobrze, zanim zaangażujesz się w bardziej energiczne testy.
uriDium
źródło
5
Testowanie jednostkowe niekoniecznie jest białą skrzynką. Niektóre z najlepszych testów jednostkowych, jakie widziałem, są w zasadzie przykładami zaczerpniętymi z wymagań, określającymi oczekiwane wyniki niezależnie od jakichkolwiek koncepcji implementacyjnych.
joel.neely
1
do tego dochodzą testy jednostkowe w testach regresji, dlatego testy regresji nie są testami białej ani czarnej skrzynki. Posunąłbym się nawet do stwierdzenia, że ​​nawet testy integracji i dymu mogą być testami białej lub czarnej skrzynki.
Lieven Keersmaekers
1
Musiałbym się z tym nie zgodzić. Testowanie implementacji wzorca projektowego jest formą testowania integracji i jest testem białej skrzynki.
Hazok
To odpowiada tytułowi, ale nie dotyczy narzędzi do dwóch ostatnich rodzajów testów, testów dymu lub regresji . Powtarza także poprzednie odpowiedzi - można je uczynić unikalnymi, odpowiadając na pytanie dotyczące narzędzi.
Peter Mortensen
1

Testy dymu zostały już tutaj wyjaśnione i są proste. Testy regresji podlegają testom integracji.

Zautomatyzowane testy można podzielić na tylko dwa.

Testy jednostkowe i integracyjne (to wszystko, co się liczy)

Nazwałbym to wyrażeniem „długi test” (LT) dla wszystkich testów, takich jak testy integracyjne, testy funkcjonalne, testy regresji, testy interfejsu użytkownika itp. A testy jednostkowe jako „test krótki”.

Przykładem LT może być automatyczne ładowanie strony internetowej, logowanie do konta i kupowanie książki. Jeśli test się powiedzie, istnieje większe prawdopodobieństwo, że zostanie uruchomiony na stronie w ten sam sposób (stąd odniesienie do „lepszego snu”). Long = odległość między stroną internetową (początek) a bazą danych (koniec).

I to jest świetny artykuł omawiający zalety testowania integracyjnego (długi test) nad testowaniem jednostkowym .

Niebieskie chmury
źródło
1

Test regresji - jest rodzajem testowania oprogramowania, w którym próbujemy obejść lub sprawdzić poprawkę błędu . Funkcjonalność wokół poprawki błędu nie powinna zostać zmieniona lub zmieniona z powodu dostarczonej poprawki. Problemy znalezione w takim procesie nazywane są problemami regresji .

Testowanie dymu: jest rodzajem testów wykonywanych w celu podjęcia decyzji, czy zaakceptować kompilację / oprogramowanie do dalszych testów jakości.

Sanyal
źródło