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

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 ?

• 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.

• 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.

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?

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ć?

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

Rodzaje testowania oprogramowania - pełna lista kliknij 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.

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.

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

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”.

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.

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.

• 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

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).

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

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.

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.

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ę.

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.

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 .

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.