Menu

Ciągłe testowanie w DevOps

continuous testing devops

Wypróbuj Nasz Instrument Do Eliminowania Problemów

Co to jest ciągłe testowanie i ciągłe testowanie w DevOps?

Mam nadzieję, że ostatni samouczek wam się podobał Ciągłe wdrażanie w DevOps .

Wiemy, jak ważne jest testowanie w każdym dostawie oprogramowania, a DevOps jest krótkim cyklem dostaw, niemożliwe jest każdorazowe ręczne uruchomienie wszystkich zaprojektowanych przypadków testowych, gdy pojedyncza linia kodu jest aktualizowana w narzędziu do kontroli wersji i to jest ciągła testowanie i zautomatyzowany potok ciągłego testowania pojawiają się w DevOps.

Ciągłe testowanie w DevOps

Sugerowana lektura => Samouczek szkoleniowy DevOps od podstaw

Korzyści z CT:

    • Jakość i szybkość to ogromne zalety CT.
    • Szybsza i szybsza informacja zwrotna o kodzie.
    • Zwiększa zaufanie zespołu i zachęca ich do ciągłego doskonalenia.

WIDEO Część 3 Blok 4: Testowanie ciągłe- 14 minut 39 sekund

Transkrypcja:

W tym bloku dowiemy się o Ciągłe testowanie i ciągłe testowanie potoku szczegółowo.

Ciągłe testowanie to kolejny ważny proces ciągłego dostarczania wraz z ciągłą integracją, który w potoku obejmuje: różne fazy testowania gdzie testy automatyczne są uruchamiane wraz z automatycznymi bramkami jakości pomiędzy nimi.

Zatem ciągłe testowanie polega na wykonywaniu automatycznych testów, w sposób ciągły i powtarzalny, w oparciu o kod i różne środowiska wdrożeniowe.

Głównie testy jednostkowe, statyczna analiza kodu, analiza kodu bezpieczeństwa, testy integracyjne, testy obciążenia i wydajności są częścią ciągłego testowania, który jest wykonywany w zautomatyzowanym potoku ciągłego testowania.

Ponieważ ciągła integracja i ciągłe wdrażanie nazywane są CI, CD, ciągłe testowanie jest częściej nazywane CT.

Jeśli zobaczysz ten diagram, który jest potokiem ciągłego dostarczania, ten potok zawiera dwa potoki, jeden to potok kompilacji, który jest potokiem CI lub potokiem ciągłej integracji, który składa się z automatycznego wyzwalacza kompilacji, kompilowania, kompilowania i wdrażania.

Drugi to potok testowy, który jest potokiem ciągłego testowania

Zobaczmy teraz więcej na temat ciągłego testowania.

Wiemy, jak ważne jest testowanie, testowanie każdej linii kodu…… testowanie za każdym razem… i testowanie na różnych etapach i jest prawie niemożliwe ręczne uruchomienie wszystkich zaprojektowanych testów za każdym razem, gdy wiersz kodu jest aktualizowany do kontroli wersji.

W tym miejscu pojawiają się ciągłe testy.

Tak więc jeśli kod, który dostanie się do zautomatyzowanego, ciągłego zintegrowanego potoku, nie zostanie dokładnie przetestowany i zapewni wymaganą jakość, nie ma sensu udostępniać oprogramowania klientom. Chodzi mi o to, że nie można zapewnić jakości, jeśli kod nie zostanie dokładnie przetestowany.

Tak więc ciągłe testowanie, zgodnie z wcześniejszą definicją, polega na wykonywaniu różnych typów testów, w sposób ciągły na bazie kodu i w różnych środowiskach, w których jest wdrażany, zgodnie z predefiniowanymi i zaprojektowanymi w potoku ciągłego dostarczania.

Jak widać na rysunku, testy jednostkowe odbywają się na samym serwerze CI, który testuje każdą jednostkę systemu oddzielnie.

Testy integracyjne są przeprowadzane w środowisku integracyjnym, które zasadniczo weryfikuje zintegrowane ze sobą komponenty. Testy systemowe w środowisku testowym systemu, w którym system BIG ze wszystkimi zintegrowanymi komponentami i interfejsami jest testowany poprzez scenariusze na poziomie systemu w środowisku testowym systemu i tak dalej.

A dogłębność testowania często rośnie, gdy symulacja środowiska zbliża się do produkcji.

Testowanie ciągłe staje się coraz trudniejsze i dłuższe wraz z postępem w kierunku środowiska produkcyjnego, ponieważ musimy powoli dodawać wiele testów i bardziej skomplikowanych testów w miarę dojrzewania kodu i postępu złożoności środowiska.

pytania do wywiadu dla analityka biznesowego

To nie jest tak, że te same przypadki testowe byłyby uruchamiane przez cały czas, przypadki testowe muszą być aktualizowane za każdym razem w różnych fazach, a automatyczne skrypty są aktualizowane, ponieważ kod staje się bardziej dojrzały, przechodzi na wyższy poziom środowiska, w którym również konfiguracje i infrastruktura postęp, aż trafi do produkcji.

Tak więc nawet czas potrzebny do uruchomienia testów wydłuża się wraz z postępem testów w kierunku punktu wydania, tak jak testowanie jednostkowe może zająć znacznie mniej czasu, podczas gdy niektóre testy integracyjne lub niektóre testy systemowe lub testy obciążenia mogą zająć kilka długich godzin lub może zająć kilka dni do biegu.

Tutaj ciągłe testowanie polegałoby głównie na automatycznym uruchamianiu przypadków testowych z wyzwalaczem. Ale jak zdefiniowaliśmy wcześniej, ciągła dostawa obejmuje również pewne testy ręczne i bramki, w których niektóre testy są przeprowadzane ręcznie, przed wprowadzeniem do produkcji.

Te bramki pośredniej jakości na każdym etapie testowania i zwiększają zaufanie do kodu.

.net pytanie i odpowiedzi do wywiadu

Tak więc ciągłe testowanie jako takie obejmuje testowanie jednostkowe wraz ze wstępnymi automatycznymi weryfikacjami bezpieczeństwa. Następnie przechodzi do poziomu testowania integracji, w którym uruchamiane są automatyczne testy integracyjne, a następnie do poziomu systemu, na którym scenariusze na poziomie systemu są zautomatyzowane i uruchamiane.

Tutaj przeprowadzane są nawet pewne scenariusze testów wydajności.

Następnie przechodzi do `` Testów akceptacyjnych '', które zasadniczo obejmują zautomatyzowane przypadki testowe akceptacji witryny, a na końcu do `` Testowania akceptacji użytkownika '', które może być ręcznym wykonaniem i obejmuje udział użytkownika końcowego w przeprowadzaniu testów, a to będzie rodzaj ostatecznego podpisania produktu lub funkcji, w którym ręczna bramka jest wywoływana i ostatecznie wdrażana w miejscu produkcji.

Zasadniczo, wraz z postępem ciągłego testowania, złożoność testów i środowiska testowego rośnie i przenosi się do środowiska, które jest bliższe produkcji, jak symulacja.

Nie muszę specjalnie wspominać, że wszystkie te etapy testów obejmują testy weryfikacji kompilacji, testy poczytalności, testy dymu i testy regresyjne, a także, jak powiedziałem, zależy to od tego, co zaprojektujemy w procesie ciągłego testowania i dostarczania.

Jest to typowy proces ciągłego testowania, który może zostać zaprojektowany przez zespół w oparciu o typ produktu oraz różne poziomy testowania i typy testów, których wymaga produkt.

Testowanie ciągłe wymaga zintegrowania struktury automatyzacji z narzędziem kontroli wersji i CI oraz różnymi zautomatyzowanymi narzędziami do przeprowadzania testów funkcjonalnych i niefunkcjonalnych na różnych etapach testowania, takich jak:

  • Sonar do statycznej analizy kodu,
  • Wzmocnij dla bezpiecznej analizy kodu,
  • Selen do testów funkcjonalnych,
  • Load Runner do testowania obciążenia itp.,

Microsoft TFS, Jenkins, chef, puppet to tylko kilka narzędzi dostępnych na rynku do projektowania potoku CI-CD.

Rzecz w tym, że narzędzia te mogą nie obsługiwać pełnej automatyzacji od końca do końca, w zależności od używanego narzędzia do kontroli wersji, więc niewiele organizacji może preferować opracowywanie własnych ram automatyzacji, które umożliwiają automatyzację procesu dostarczania z kodu od końca do końca. zobowiązać się do dostarczenia kodu.

Tak więc ciągłe testowanie jako bardzo istotna część testowania zapewnia jakość produktu lub wydania i należy bardzo uważać przy wyborze narzędzia, frameworka itp., Które przede wszystkim decydują o jakości i szybkości dostawy.

Zatem skonfigurowanie odpowiedniego potoku ciągłego testowania zajmuje nieco więcej czasu w potoku ciągłego dostarczania. Nie tylko w części dotyczącej narzędzi i frameworka, ale także w części przypadków testowych. Ciągłe testowanie obejmuje również definiowanie potoku wdrażania w.

Ponieważ CT wymaga zautomatyzowanego wdrażania kompilacji w różnych środowiskach na różnych etapach, co wymaga automatyzacji wdrażania i konfigurowania środowisk za pomocą automatycznych skryptów.

Te zautomatyzowane skrypty, które obejmują konfigurację infrastruktury i środowiska jako kod, są sprawdzane w narzędziu do kontroli wersji, a potok dostarczania przejmuje go z narzędzia do kontroli wersji w celu przeprowadzenia wdrożenia. Nazywa się to potokiem wdrażania.

Przejdźmy teraz do zalet CT,

Osiągnięcie jakości i szybkości to największa zaleta ciągłego testowania.

W przeciwieństwie do wcześniejszych czasów, gdy testowanie odbywało się tylko na końcu, testowanie w całości jest koncepcją ciągłego testowania, a zatem ciągłe testowanie w potoku dostaw, pozwala zespołowi wprowadzić bramki jakości w dowolnym miejscu i dowolną liczbę bramek jakości, w kolejności aby osiągnąć wymagany poziom jakości.

Tak więc, jeśli w ogóle kod nie powiedzie się do testowania w jakimkolwiek konkretnym punkcie lub bramie potoku, zespół może cofnąć się i automatycznie zakończyć wdrożenie do tego momentu.

Daje to wyraźną wskazówkę zarówno zespołowi deweloperskiemu, jak i zespołowi operacyjnemu, że czegoś tam brakuje i zespół może pracować, aby to naprawić. Jest to więc zaleta i elastyczność ciągłego procesu testowania.

Tak więc wprowadzenie bramek jakości w różnych fazach testowania lepiej reguluje jakość kodu w potoku.

Im większa liczba bramek, przez które przechodzi kod, tym większe będzie zaufanie zespołu do kodu, że może on trafić do produkcji na wyższym poziomie jakości.

Tak więc ciągłe testowanie zwiększa pewność zespołu i zachęca go do ciągłego doskonalenia.

Ogólnie rzecz biorąc, jeśli zespół tak naprawdę nie zaniedbuje żadnych niepowodzeń testów w żadnej fazie testów lub bramek jakości w przygotowaniu, zdecydowanie ciągłe testowanie będzie bonusem w osiąganiu celów wysokiej jakości.

Podsumowując ciągłe testowanie, od testów jednostkowych, które są przeprowadzane na etapie wstępnym, poprzez testy akceptacyjne, testy wydajnościowe, a nawet niektóre testy ręczne, które mają zostać przeprowadzone, są BARDZO BARDZO krytyczne dla zdefiniowania ciągłego testowania w potoku DevOps.

To kończy naszą dyskusję na tematy części 3 dotyczące ciągłej integracji, ciągłego dostarczania i ciągłego testowania.

W naszym nadchodzącym samouczku omówimy więcej Zarządzanie konfiguracją, zarządzanie wersjami i monitorowanie wydajności aplikacji.

POPRZEDNIA samouczek | NEXT Tutorial

rekomendowane lektury

^