Co to jest testowanie chaosu?

Testowanie chaosu to technika używana do testowania odporności systemów oprogramowania przez wprowadzenie nieoczekiwanych awarii lub zakłóceń. Testowanie chaosu jest również nazywane inżynierią chaosu. Celem testowania chaosu jest zidentyfikowanie słabych stron i zwiększenie odporności aplikacji.

Testowanie chaosu opiera się na założeniu, że systemy kończą się niepowodzeniem w nieoczekiwany sposób. Tradycyjne metody testowania często zawodzą w odkrywaniu tych nieoczekiwanych trybów awarii. Podczas testowania chaosu można symulować rzeczywiste scenariusze, takie jak awarie serwera, opóźnienie sieci lub wyczerpanie zasobów. Symulowanie tych zachowań pomaga ujawnić ukryte problemy i słabości, które mogą nie być widoczne w normalnych warunkach testowania.

Oto kilka kluczowych kwestii, które należy wziąć pod uwagę podczas testowania chaosu:

• Bądź proaktywny. Zamiast czekać na awarie, testowanie chaosu aktywnie wprowadza błędy, aby zobaczyć, jak system reaguje. Testowanie chaosu umożliwia identyfikowanie i rozwiązywanie problemów, zanim staną się poważnymi problemami.
• Uzyskiwanie szczegółowych informacji. Celem testowania chaosu jest nauczenie się z błędów. Wprowadzając je, możesz uzyskać cenny wgląd w to, jak system zachowuje się pod obciążeniem i wykorzystać te informacje, aby go ulepszyć.
• Promowanie wysiłku zespołu. Testowanie chaosu jest najbardziej skuteczne, gdy wykonujesz je wspólnie. Chcesz uzyskać opinię od deweloperów, testerów, operacji i innych interesariuszy. Współpracując ze sobą, można zidentyfikować najważniejsze obszary do testowania i zapewnienia, że wszyscy są informowani.
• Zacznij od małych kroków i rozbudowuj się. Po pierwszym rozpoczęciu od testowania chaosu warto zacząć od małych i stopniowo zwiększać złożoność testów. Zaczynając od małych kroków, pomaga budować pewność siebie i lepsze zrozumienie, jak system zachowuje się w różnych warunkach.

Podsumowując, testowanie chaosu to zaawansowana technika, która może pomóc zwiększyć odporność aplikacji. Proaktywnie wprowadzając błędy i ucząc się od nich, możesz zidentyfikować i rozwiązać problemy, zanim staną się poważnymi problemami.

Testy chaos engineering dla interfejsów API wywoływanych przez aplikację

Testowanie chaosu często koncentruje się na infrastrukturze: serwerach, sieciach i kontenerach. Jeśli aplikacja zależy od interfejsów API, niektóre błędy, które użytkownicy zauważają, pochodzą z tych interfejsów API: błąd 500 od dostawcy płatności, błąd 429 od GitHub lub OpenAI albo odpowiedź, która trwa 8 sekund zamiast 80 milisekund. Możesz zastosować te same pomysły dotyczące testowania chaosu do tych zależności na poziomie poszczególnych odpowiedzi interfejsu API:

• Błędy. Losowo zwracaj 5xx błędy i sprawdź, czy aplikacja ponawia to, co można bezpiecznie ponowić, i wyświetla przydatny komunikat dla reszty.
• Ograniczanie przepustowości Zwróć 429 z nagłówkiem Retry-After i sprawdź, czy aplikacja czeka przed ponownym wywołaniem.
• Opóźnienie. Opóźnij odpowiedzi i sprawdź limity czasu, wskaźniki ładowania oraz co się stanie, gdy odpowiedzi przychodzą w niewłaściwej kolejności.

Approach	Co znajdziesz	Co tracisz
Oczekiwanie na środowisko produkcyjne	Rzeczywiste awarie	Wszystko, dopóki użytkownik tego nie kliknie
Wyśmiewa interfejs API w testach lub pozwól agentowi kodowania napisać pozorny kod	Czy gałęzie błędów są uruchamiane?	Rzeczywiste formaty błędów interfejsu API, zasady ponawiania prób Twojego SDK i sposób działania uruchomionej aplikacji. Aplikacja wymaga również przełącznika tylko do testowania, aby uzyskać pozorny dostęp.
Zakłóć działanie rzeczywistej infrastruktury (na przykład zabij usługę lub zablokuj ruch sieciowy)	Jak system radzi sobie z awariami	Błędy na poziomie interfejsu API, takie jak określony kod błędu lub nagłówek Retry-After
Przechwytywanie rzeczywistego ruchu aplikacji i wstrzykiwanie błędów interfejsu API	Błędy, ograniczanie przepustowości i opóźnienia dla rzeczywistych adresów URL w wybranym tempie	Błędy infrastruktury. Użyj do tego narzędzi do chaosu infrastruktury.

Wypróbuj ją w aplikacji

Dev Proxy powoduje błędy wywołań interfejsu API w aplikacji, podczas gdy aplikacja nadal wywołuje rzeczywiste adresy URL. Działa z dowolnym typem aplikacji, na dowolnym stosie technologii, bez zmieniania kodu. Na przykład, aby spowodować niepowodzenie połowy żądań do interfejsu API z losowymi błędami, postępuj zgodnie z instrukcjami Testuj moją aplikację z losowymi błędami, a aby je spowolnić, zobacz Symulowanie powolnych odpowiedzi interfejsu API. Aby uruchomić te same testy w potoku ciągłej integracji, zobacz Używanie Dev Proxy w CI/CD.

Następny krok

Przetestuj moją aplikację z losowymi błędami