Test Jednostkowy? Test Integracyjny? Test Regresji? Test Akceptacyjny?

Test jednostkowy: gdy się nie powiedzie, powie Ci, który fragment kodu należy naprawić.

Test integracji: gdy się nie powiedzie, informuje Cię, że elementy Twojej aplikacji nie współpracują ze sobą zgodnie z oczekiwaniami.

Test akceptacji: gdy nie powiedzie się, informuje, że aplikacja nie robi tego, czego oczekuje klient.

Test regresji: gdy się nie powiedzie, informuje, że aplikacja nie zachowuje się już tak, jak kiedyś.

Oto proste wyjaśnienie dla każdego z wymienionych testów i kiedy są one stosowane:

Test Jednostkowy Test jednostkowy jest przeprowadzany na samodzielnym urządzeniu (zwykle klasie lub metodzie) i powinien być przeprowadzany za każdym razem, gdy jednostka została wdrożona lub aktualizacja jednostki została zakończona.

Oznacza to, że jest uruchamiany za każdym razem, gdy napisałeś klasę / metodę, naprawiłeś błąd, zmieniłeś funkcjonalność...

Test Integracyjny Test integracyjny ma na celu sprawdzenie, jak dobrze kilka jednostek oddziałuje ze sobą. Tego rodzaju badanie powinno być przeprowadzane w przypadku, gdy między jednostkami została ustanowiona nowa forma komunikacji lub zmienił się charakter ich interakcji.

Oznacza to, że jest uruchamiany za każdym razem, gdy niedawno napisana jednostka jest zintegrowana z resztą systemu lub gdy jednostka, która wchodzi w interakcje z innymi systemami, została zaktualizowana (i pomyślnie przeszła testy jednostkowe).

Badanie Regresji Wykonuje się testy regresyjne za każdym razem, gdy coś zostało zmienione w systemie, w celu sprawdzenia, czy nie wprowadzono żadnych nowych błędów.

Oznacza to, że jest uruchamiany po wszystkich łatkach, aktualizacjach, poprawkach błędów. Badanie regresji może być postrzegane jako szczególny przypadek połączonego testu jednostkowego i testu integracyjnego.

Test Akceptacyjny Testy akceptacyjne są przeprowadzane zawsze, gdy istotne jest sprawdzenie, czy podsystem (ewentualnie cały system) spełnia wszystkie jego specyfikacje.

Oznacza to, że jest głównie uruchamiany przed Ukończenie nowego zadania lub ogłoszenie ukończenia większego zadania. Zobacz to jako ostateczną kontrolę, aby sprawdzić, czy naprawdę ukończyłeś swoje cele, zanim pójdziesz do klienta / szefa i ogłosisz zwycięstwo.

Tak przynajmniej się nauczyłem, choć jestem pewien, że są inne przeciwstawne poglądy. Tak czy inaczej, mam nadzieję, że to pomoże.

Spróbuję:

1. test jednostkowy: programista napisałby taki, aby przetestować indywidualny komponent lub klasę.
2. Test integracji: bardziej rozbudowany test, który obejmowałby kilka komponentów lub pakietów, które muszą współpracować
3. Test Regresyjny: dokonanie pojedynczej zmiany w aplikacji wymusza ponowne uruchomienie wszystkich testów i sprawdzenie wszystkich funkcjonalności.
4. Test akceptacji: użytkownicy końcowi lub QA robią to przed podpisaniem się, aby zaakceptować dostawę aplikacji. Informatyka mówi " aplikacja spełniła moje wymagania."

Test jednostkowy: Czy moja pojedyncza metoda działa poprawnie? (NO dependencies, or dependencies)

Test integracji: Czy moje dwa oddzielnie opracowane Moduły działają poprawnie, gdy razem?

Test regresji: czy złamałem coś zmieniając/pisząc nowy kod? (Uruchamianie testów jednostkowych / integracyjnych z każdym commitem jest technicznie (zautomatyzowanym) testem regresji). Częściej stosowane w kontekście QA-manual lub zautomatyzowane.

Test akceptacyjny : test wykonywany przez klienta, że "akceptuje" dostarczony SW

Can ' t comment (reputation to low :-| ) so...

@ Andrejs zwraca uwagę na różnice między środowiskami związanymi z każdym rodzajem testów.

Testy jednostkowe są uruchamiane zazwyczaj na maszynie programistów (i ewentualnie podczas budowania CI) z wyszydzanymi zależnościami od innych zasobów/systemów.

Testy integracyjne z definicji muszą mieć (w pewnym stopniu) dostępność zależności; inne zasoby i systemy są nazywane tak, że środowisko jest bardziej reprezentacyjne. Dane do testów mogą być wyśmiewane lub mały zasłonięty podzbiór rzeczywistych danych produkcyjnych.

UAT / Acceptance testing musi reprezentować rzeczywiste doświadczenia dla QA i zespołów biznesowych akceptujących oprogramowanie. Wymaga więc pełnej integracji i realistycznych wolumenów danych oraz pełnych maskowanych/zaciemnionych zestawów danych, aby zapewnić realistyczną wydajność i wrażenia użytkownika końcowego.

Inne "ilities" również mogą potrzebować środowiska, aby być jak najbliżej rzeczywistości do symulacji doświadczenie w produkcji np. testowanie wydajności, bezpieczeństwo,...