Czym dokładnie jest test integracyjny?

Wspólnie z moimi przyjaciółmi staramy się dokładnie sklasyfikować, co jest testem integracyjnym.

Teraz, wracając do domu, właśnie zdałem sobie sprawę, że za każdym razem, gdy próbuję podać prawdziwy przykład testu integracyjnego w świecie rzeczywistym, okazuje się, że jest to test akceptacyjny, tj. coś, co przedsiębiorca powiedziałby na głos, określające, co powinien zapewniać system.

Sprawdziłem dokumentację Ruby on Rails pod kątem ich klasyfikacji tych typów testów, a teraz całkowicie mnie wyrzuciła.

Czy możesz podać mi krótki akademicki opis testu integracyjnego z przykładem ze świata rzeczywistego?

W tej chwili podoba mi się to stwierdzenie: „Nie ważne, jak to nazywasz, ale co robi” autorstwa Gojko Adzica w tym artykule .

Naprawdę musisz określić z osobami rozmawiającymi o testach, co zamierzasz przetestować.

Wiele osób ma różne poglądy, w zależności od ich roli.

Dla testerów ogólnie przyjętą metodologią testów w Holandii jest TMap . TMap dokonuje następującego rozróżnienia.

• test jednostkowy
• test integracji jednostki
• test systemu
• test integracji systemu
• test akceptacyjny (wszystkie rodzaje / poziomy)
• test akceptacji funkcjonalnej
• Test akceptacji użytkownika
• test akceptacyjny produkcji

Mają bardziej szczegółowy rodzaj testów, które można wykonać w ramach wyżej wymienionych testów. Spójrz na to słowo doc na przegląd.

Wikipedia ma również ładny przegląd .

Książka pragmatyczny programista mówi:

• test jednostkowy to test ćwiczący moduł
• testy integracji pokazują, że główne części systemu działają dobrze razem

Przeglądając te różne źródła i zamieszczając własne doświadczenia i opinie, zacznę od rozróżnienia według trzech kategorii

• kto ogólnie przeprowadza testy
• co jest testowane

• jaki jest cel testu

  • Test jednostkowy : testuj logikę w klasach przez programistów, aby pokazać poprawność poziomu kodu. Powinny być szybkie i nie mogą zależeć od innych części systemu, których nie zamierzasz testować
  • Test akceptacji funkcjonalnej : przetestuj scenariusz przypadku użycia na ograniczonym (specjalnie utworzonym) zestawie danych wykonanym przez dział testowy, aby pokazać, że każdy określony scenariusz działa zgodnie z określonym.
  • Test akceptacji użytkownika : przetestuj scenariusze przypadków użycia dotyczące produkcji, takie jak dane wykonane przez przedstawicieli użytkowników, aby formalnie zaakceptować aplikację
  • Test integracji : przetestuj ścieżki komunikacji między różnymi częściami modułu wykonane przez dział testowy lub programistów, aby wykazać, że wszystkie moduły działają poprawnie razem.

Moja powyższa lista to tylko początek i sugestia, ale naprawdę myślę: „To nie jest ważne, jak to nazywasz, ale to, co robi”

Mam nadzieję że to pomoże.

26-10-2016 Edycja: Niedawno wprowadzono bardzo miłe wprowadzenie do testów jednostkowych YouTube vs. testy integracyjne - rozważania MPJ - FunFunFunction # 55

test integracji okazuje się testem akceptacyjnym

Oczywiście.

Te dwie rzeczy są prawie takie same. Istnieją jednak nieco inne wymiary definicji testu.

Integracja == system jako całość.

Akceptacja == system jako całość.

Jedyną różnicą - i to jest subtelna - jest definicja przypadków testowych.

Integracja == przypadki testowe do testowania głębokości i stopnia integracji. Czy to działa dla wszystkich skrzynek krawędziowych i narożnych? Przypadki testowe są zazwyczaj techniczne, napisane przez projektantów i programistów.

Akceptacja == przypadków testowych do wykonania 80% zestawu funkcji zorientowanych na użytkownika końcowego. Nie wszystkie skrzynie krawędzi i narożników. Przypadki testowe są zwykle nietechniczne i napisane przez użytkowników końcowych.

Osobiście lubię myśleć o teście integracji jako o teście funkcji, gdy każdy element systemu jest prawdziwy , bez fałszywych obiektów.

Prawdziwe repozytorium, prawdziwa baza danych, prawdziwy interfejs użytkownika. Testowane są określone funkcje, gdy system jest w pełni zmontowany i wygląda tak, jak powinien być po wdrożeniu.

W moim (przyznaję) małym doświadczeniu zrozumiałem, że słowo integracja może naprawdę powodować nieporozumienia: naprawdę trudno jest znaleźć coś całkowicie izolowanego w systemie, niektóre elementy na pewno będą wymagać pewnej integracji.

W ten sposób przyzwyczaiłem się do następujących rozróżnień:

• Używam testu jednostkowego, aby zidentyfikować, udokumentować i podkreślić wszystkie zachowania, które klasa, którą testuję, jest odpowiedzialna za osiągnięcie.
• Robię testy integracyjne, ilekroć mam komponent (może więcej niż jeden) w moim systemie, który prowadzi rozmowę z innym „ zewnętrznym ” systemem. (kontynuuje poniżej ...)
• I wdrożyć kontrolę odbioru do zdefiniowania, dokumentowania i stres pewien przepływ pracy, który jest oczekiwany przez system.

W definicji testu integracji przez zewnętrzny miałem na myśli system, który jest poza moim zakresem programistycznym : z jakiegokolwiek powodu nie mogę natychmiast zmienić sposobu ich działania. Może to być biblioteka, składnik systemu, którego nie można zmienić (tzn. Jest współdzielony z innymi projektami w firmie), dbms itp. Do tych testów muszę skonfigurować coś bardzo podobnego do rzeczywistego środowiska systemu będzie działał w: system zewnętrzny musi zostać zainicjowany i ustawiony na określony stan; realistyczne dane muszą być zarejestrowane w bazie danych; itp.

Zamiast tego, kiedy przeprowadzam testy akceptacyjne, podrabiam rzeczy: pracuję nad czymś innym, pracuję nad specyfikacjami systemu, a nie nad jego zdolnością do współpracy z podmiotami zewnętrznymi.

To naprawdę jest węższy pogląd w porównaniu z tym, co opisał KeesDijk wcześniej, ale przypuszczam, że projekty, nad którymi pracowałem do tej pory, były wystarczająco małe, aby pozwolić mi na ten poziom uproszczenia.

Test integracyjny sprawdza, czy elementy złożonego systemu (np. Oprogramowanie, samolot, elektrownia) działają razem zgodnie z przeznaczeniem.

Wyobraźmy sobie, że mówimy o samolocie (z oprogramowaniem jest bardziej abstrakcyjne i trudne do zrobienia). Testy integracyjne obejmują sprawdzenie:

• poprawna interakcja między niektórymi komponentami. Przykład: po naciśnięciu przycisku Start silnik uruchamia się, a śmigło osiąga oczekiwaną prędkość obrotową (dron nadal pozostaje na ziemi)
• poprawna interakcja z komponentami zewnętrznymi. Przykład: sprawdź, czy wbudowane radio może komunikować się z radiem stacjonarnym (dron nadal znajduje się na ziemi)
• poprawna interakcja między wszystkimi zaangażowanymi komponentami, aby system jako całość działał zgodnie z oczekiwaniami. Przykład: załoga pilotów testowych i inżynierów uruchamia samolot i lata nim (wszyscy noszą spadochrony ...).

Test integracji rozwiązuje problem techniczny , a mianowicie to, że system działa pomimo podziału na komponenty. W oprogramowaniu komponentami mogą być przypadki użycia, moduły, funkcje, interfejsy, biblioteki itp.

Test akceptacyjny sprawdza, czy produkt jest odpowiedni do określonego celu. Zasadniczo są one wykonywane przez klienta. Przyjmując analogię samolotu, obejmują sprawdzenie, czy:

• przewidywane scenariusze biznesowe prowadzą do oczekiwanego rezultatu w niemal realnej sytuacji. Przykład: przećwicz próbę wejścia na pokład z pasażerami testowymi, aby sprawdzić, czy personel może monitorować wejście na pokład zgodnie z oczekiwaniami za pomocą procedur operacyjnych. Niektóre scenariusze mogą być tak proste, że wyglądałyby jak test jednostkowy, ale są wykonywane przez użytkownika (np. Wypróbuj wtyczki elektryczne ze sprzętem firm).
• system działa w niemal realnej sytuacji biznesowej. Przykład: wykonaj pusty lot testowy między dwoma prawdziwymi miejscami docelowymi, z nowo wyszkolonymi pilotami z linii lotniczej, aby sprawdzić, czy zużycie paliwa jest zgodne z obietnicą.

Test akceptacyjny dotyczy bardziej kwestii odpowiedzialności . W relacji klient / dostawca może to być odpowiedzialność umowna (zgodność ze wszystkimi wymogami). Ale w każdym przypadku obowiązkiem organizacji używającej jest zapewnienie, aby ich obowiązki mogły być wykonywane z systemem i ostrożnie zapobiegać wszelkim nieprzewidzianym problemom (np. Ta korporacja kolejowa, która podczas testów akceptacyjnych odkryła, że ​​musiała skrócić niektóre quais, ponieważ nowe wagony były o 5 cm za duże - bez żartów!).

Wnioski: Testy integracji i akceptacji pokrywają się. Obaj zamierzają pokazać, że system jako całość działa. Jednak „całość” może być większa dla klienta (ponieważ sam system może być częścią większego systemu organizacyjnego) i bardziej techniczna dla integratora systemu:

Testy integracyjne to nic innego jak sprawdzenie połączenia i poprawności przepływu danych między dwoma lub więcej modułami.

Na przykład: gdy tworzymy pocztę (jeden moduł) i wysyłamy ją do ważnego identyfikatora użytkownika (drugi moduł), testowanie integracji polega na sprawdzeniu, czy wysłana poczta znajduje się w wysłanych elementach.

Jedna praktyczna definicja testu integracji to: Każdy test, który wymaga interakcji z czymś poza procesem.

Na przykład:

• System plików
• Sieć
• Baza danych
• Zewnętrzny interfejs API

Istnieje pewien rodzaj umowy między twoim procesem a światem zewnętrznym, a minimalna weryfikacja tej umowy powinna być celem testu integracyjnego. tzn. nie powinno to nic więcej niż weryfikować umowy. Jeśli tak, to zbliżasz się do przestrzeni systemowej / end-to-end.

Testy jednostkowe są w stanie przetestować całą logikę w granicach procesu i mogą to zrobić z łatwością właśnie z powodu braku zależności od powolnego / kruchego / złożonego „świata zewnętrznego”.

Chociaż istnieją testy integracyjne, definicja ta nie obejmuje (stąd dlaczego nazwałem ją praktyczną definicją), myślę, że są one znacznie mniej popularne / przydatne.

NB Ściśle mówiąc, tak, ta definicja obejmie również testy systemowe / kompleksowe. W mojej filozofii są one formą „ekstremalnego” testu integracji, dlatego ich nazwy podkreślają inny aspekt. W drugim kierunku test jednostkowy można uznać za test całkowania zerowych składników, tzn. Wszystkie testy można uznać za leżące gdzieś na spektrum całkowania, integrujące między składnikami 0-n :-)