Eksplorowanie testowania przesunięcia w prawo
Jak wyjaśniono wcześniej w kursie, testowanie zarządzania cyklem życia aplikacji jest niezbędne do maksymalizacji jakości kodu i zminimalizowania ryzyka operacyjnego związanego z wdrażaniem i aktualizowaniem oprogramowania. Jest to powód zastosowania podejścia shift-left , który wprowadza działania testowe tak szybko, jak to możliwe w fazie opracowywania. Istnieją jednak pewne aspekty testowania, które nie są skuteczne podczas przeprowadzania w ten sposób. Zamiast tego, aby w pełni spełniać swoją funkcję, muszą być wykonywane w środowisku produkcyjnym. To jest nazywane podejściem przesunięcie w prawo. Organizacja w naszym przykładowym scenariuszu musiałaby to wykorzystać, aby prawidłowo ocenić niezawodność swoich systemów w połączeniu z symulacją błędów. W tej jednostce przeanalizuj te i inne kryteria, które uzasadniają testowanie przesunięcia w prawo.
Jakie są przyczyny testowania shift-right?
Mimo że testowanie przesunięte na wcześniejsze etapy jest idealne do testowania jednostkowego i testowania dymnego, jest wykonywane w warunkach, które zwykle różnią się znacznie od tych, które mają zastosowanie do planowanych celów dostawy. Nawet dział kontroli jakości i środowiska testowe rzadko w pełni odzwierciedlają złożoność odpowiedników produkcyjnych. W rzeczywistości najlepszym sposobem pełnego zbadania zachowania obciążenia po wdrożeniu jest przetestowanie go w tym momencie.
Testowanie w środowisku produkcyjnym zapewnia następujące korzyści:
- Odzwierciedla rzeczywiste warunki pracy, w tym dodatkowe obciążenie związane z obsługą żądań użytkowników końcowych.
- Uwzględnia czynniki, które byłyby trudne do symulowania, takie jak łączność z systemami zewnętrznymi.
- Odzwierciedla zmiany zapotrzebowania na obciążenia w czasie.
Jakie są typowe scenariusze testowania typu shift-right?
Chociaż podejście do testowania shift-right może być uzasadnione w wielu scenariuszach, istnieje niewiele scenariuszy, w których jest odpowiednie. Te scenariusze obejmują:
Wdrożenia mikrousług: architektura mikrousług zwykle składa się z dużej liczby niezależnych składników. Liczna liczba kombinacji tych usług może uzasadniać zastosowanie testowania shift-right, aby skupić się na scenariuszach najbardziej odpowiednich w rzeczywistym środowisku produkcyjnym (zgodnie z ich rzeczywistym użyciem).
Ocenianie wpływu przepustowości sieci i warunków opóźnienia: warunki sieci wydają się być trudne do symulowania, więc jeśli wydajność obciążenia jest bardzo opóźniona lub zależna od przepustowości, testowanie przesunięcia w prawo może być najbardziej odpowiednią opcją.
Testowanie akceptacyjne użytkowników: rzeczywiste opinie użytkowników mogą być niezbędne do zweryfikowania wydajności i użyteczności obciążenia.
Procedury sprawdzania poprawności trybu failover w konfiguracjach nadmiarowych: iniekcja błędów i testowanie odzyskiwania po awarii mają na celu ocenę odporności obciążeń produkcyjnych. Wstrzyknięcie błędów polega na celowym wprowadzeniu awarii do poszczególnych składników procesu podczas jego wykonywania w celu zidentyfikowania wszelkich słabych stron i złagodzenia ich, zwiększając ogólną niezawodność.
Notatka
Inżynieria chaosu to kolejna koncepcja w obszarze testowania niezawodności metodyki DevOps. Podobnie jak w przypadku iniekcji błędów, obejmuje symulowanie błędów (w tym przypadku w celu utworzenia kontrolowanego chaosu w testowanym systemie). Jednak jego zakres jest zwykle szerszy, przeznaczony dla całego systemu, a nie tylko jego poszczególnych składników, a jego scenariusze testowania wydają się być bardziej kompleksowe. W rzeczywistości inżynieria chaosu jest zwykle ograniczona do środowisk kanary, które mają bardzo ograniczony wpływ lub brak wpływu na produkcję.
Notatka
Za pomocą usługi Azure Chaos Studio można zaimplementować eksperymenty inżynieryjne chaosu przeznaczone dla rozwiązań hostowanych na platformie Microsoft Azure. Omówimy przykład takich eksperymentów w laboratorium tego modułu.