Co to jest testowanie regeneracji? z Przykładem

⚡ Inteligentne podsumowanie

Testowanie odzyskiwania danych ma na celu sprawdzenie, czy oprogramowanie może wznowić normalne działanie po awarii, zerwaniu połączenia sieciowego lub awarii sprzętu, poprzez przywrócenie systemu do znanego, prawidłowego stanu i ponowne przetworzenie transakcji do momentu awarii.

  • 🔁 Co to udowadnia: OperaDziałania te są kontynuowane po katastrofie, a nie tylko dlatego, że istnieje plik kopii zapasowej.
  • 🧩 Gdzie się znajduje: Technika niefunkcjonalna, stosowana przez przeszkolonych testerów na zabezpieczonych danych zapasowych.
  • ⏱️. Sterowniki czasu odzyskiwania: Punkty ponownego uruchomienia, ilość danych oraz umiejętności i narzędzia zespołu ds. odzyskiwania danych.
  • 🔄 Kształt procesu: Normalna praca, katastrofa, zakłócenie, odbudowa, a następnie powrót do normy.
  • 💾 Wybór strategii: Pojedyncze lub wielokrotne kopie zapasowe, jedna lub kilka lokalizacji, w trybie online lub offline, automatyczne lub ręczne.
  • ✅ Po przywróceniu: Policz pliki w stosunku do oryginalnego folderu, otwórz kilka typów i porównaj katalogi za pomocą narzędzi systemowych.

Czym jest testowanie odzyskiwania w testowaniu oprogramowania na przykładzie

Czym jest testowanie odzyskiwania?

Testowanie odzyskiwania To technika testowania oprogramowania, która weryfikuje zdolność oprogramowania do odzyskiwania danych po awariach, takich jak awarie oprogramowania lub sprzętu oraz awarie sieci. Celem testowania odzyskiwania danych jest ustalenie, czy oprogramowanie może kontynuować działanie po awarii lub utracie integralności. Testowanie odzyskiwania danych polega na przywróceniu oprogramowania do stanu, w którym integralność była znana, oraz ponownym przetworzeniu transakcji do momentu awarii.

W inżynierii oprogramowania testowanie odzyskiwalności jest rodzajem testy niefunkcjonalne — obejmuje aspekty niezwiązane z konkretną funkcją lub działaniem użytkownika, takie jak skalowalność czy bezpieczeństwo. Jest on wykonywany przez profesjonalnych testerów, a odpowiednie dane zapasowe są wcześniej przechowywane w bezpiecznych lokalizacjach.

Przykład testowania odzyskiwania

Dwa scenariusze ilustrują tę technikę w najprostszej postaci. W każdym z nich celowo wymuszono awarię, a następnie obserwowano wznowienie działania aplikacji.

  • Przerwa w sieci: Gdy aplikacja odbiera dane z sieci, odłącz kabel połączeniowy. Po pewnym czasie podłącz go ponownie i sprawdź, czy aplikacja może nadal odbierać dane od momentu zerwania połączenia.
  • Przywracanie sesji: Uruchom ponownie system, gdy przeglądarka ma otwartą określoną liczbę sesji, i sprawdź, czy przeglądarka odzyska je wszystkie.

Poniższa ilustracja przedstawia tę samą ideę w formie wizualnej.

Koncepcja testów odzyskiwania pokazująca awarię systemu, a następnie przywrócenie go do normalnego działania

Czas potrzebny na regenerację zależy od:

  • Liczba punktów ponownego uruchomienia
  • Ilość danych przechowywanych przez aplikację
  • Szkolenia i umiejętności osób prowadzących działania naprawcze oraz dostępne narzędzia do odzyskiwania

W przypadku wystąpienia kilku awarii testy odzyskiwania danych należy przeprowadzać w sposób ustrukturyzowany, a nie wszystkie naraz — najpierw dla jednego segmentu, a potem dla kolejnego.

Cykl życia procesu odzyskiwania

Przed zaprojektowaniem przypadków testowych warto ustalić, gdzie interweniuje test odzyskiwania. Cykl życia procesu odzyskiwania składa się z pięciu etapów:

  1. Normalna operacja
  2. Wystąpienie katastrofy
  3. Zakłócenie i awaria operacji
  4. Usuwanie awarii poprzez proces odzyskiwania
  5. Rekonstrukcja wszystkich procesów i informacji, przywrócenie całego systemu do normalnego działania

Poniższy schemat blokowy przedstawia kolejność tych pięciu etapów.

Schemat blokowy cyklu życia procesu odzyskiwania obejmujący normalną działalność, katastrofę, przerwę, odzyskiwanie i rekonstrukcję

Omówmy szczegółowo te pięć kroków:

  1. Normalna praca. System składający się ze sprzętu, oprogramowania i oprogramowania sprzętowego, zintegrowany w celu osiągnięcia wspólnego celu, wykonuje zaprojektowane zadanie bez zakłóceń w ustalonym czasie.
  2. Wystąpienie katastrofy. Do zakłóceń może dojść z powodu nieprawidłowego działania oprogramowania, np. awarii wywołanej przez wejście danych, awarii spowodowanej awarią sprzętu lub uszkodzenia powstałego na skutek pożaru, kradzieży lub strajku.
  3. Zakłócenia i awarie. To najbardziej bolesna faza, prowadząca do strat biznesowych, zerwanych relacji, utraconych możliwości, straconych godzin pracy i, nieuchronnie, strat finansowych i utraty wartości firmy. Plan odzyskiwania po awarii minimalizuje ten etap.
  4. Usuwanie skutków katastrofy. Jeśli plan zapasowy i procesy ograniczania ryzyka są już wdrożone, odzyskiwanie danych zajmuje znacznie mniej czasu i wysiłku. Wyznaczony zespół, którego rola każdej osoby jest z góry określona, ​​ustala zakres odpowiedzialności i zapobiega długim okresom zakłóceń.
  5. Rekonstrukcja. Może to wymagać wielu sesji operacji w celu odbudowania wszystkich folderów wraz z plikami konfiguracyjnymi. Do prawidłowego odzyskiwania wymagana jest odpowiednia dokumentacja i zdefiniowany proces rekonstrukcji.

Strategia renowacji

Zespół ds. odzyskiwania danych powinien mieć własną strategię odzyskiwania ważnego kodu i danych, aby przywrócić normalne funkcjonowanie. Strategia ta jest unikalna dla każdej organizacji i zależy od krytyczności obsługiwanych systemów, a w przypadku systemów krytycznych sprowadza się do zestawu wyborów:

  1. Pojedyncza kopia zapasowa lub więcej niż jedna
  2. Wiele kopii zapasowych w jednym miejscu lub w różnych miejscach
  3. Kopia zapasowa online lub offline
  4. Kopie zapasowe są tworzone automatycznie zgodnie z polityką lub uruchamiane ręcznie
  5. Niezależny zespół restauracyjny lub zespół programistów wykonujący pracę

Każdy wybór wiąże się z kosztami, a wiele kopii zapasowych może pochłaniać więcej zasobów fizycznych lub wymagać niezależnego zespołu. Zależność również ma znaczenie: firmy są narażone na ryzyko poprzez kod i dane przechowywane u jednego dostawcy, a także na dużą skalę. AWS Awarie wielokrotnie powodowały, że znane usługi konsumenckie były niedostępne w tym samym momencie. W takich przypadkach kluczowe jest niezależne przywracanie usług.

Jak przeprowadzić test odzyskiwania

Strategia ustalona, ​​teraz pozostaje pytanie, jak skonfigurować sam test. Podczas przeprowadzania testów odzyskiwania należy wziąć pod uwagę następujące kwestie.

  • Stwórz środowisko testowe możliwie najbardziej zbliżone do rzeczywistych warunków wdrożenia: interfejs, protokół, oprogramowanie sprzętowe, sprzęt i oprogramowanie powinny być zgodne ze środowiskiem produkcyjnym.
  • Mimo że dokładne testowanie może być czasochłonne i kosztowne, nadal należy wykonać identyczną konfigurację i dokładną kontrolę.
  • Jeżeli to możliwe, przetestuj na sprzęcie, na który ostatecznie zostanie przywrócona kopia zapasowa — zwłaszcza jeśli przywracasz dane na innym komputerze niż ten, na którym utworzono kopię zapasową.
  • Niektóre systemy tworzenia kopii zapasowych wymagają, aby dysk twardy miał dokładnie taki sam rozmiar jak dysk, z którego została pobrana kopia zapasowa.
  • Zarządzaj przestarzałością: technologia napędów rozwija się szybko, a stary dysk może nie być kompatybilny z nowym. Przywracanie do Maszyna wirtualna pomaga, ponieważ oprogramowanie do wirtualizacji może imitować istniejący sprzęt, w tym rozmiary dysków.
  • Systemy tworzenia kopii zapasowych online nie są wyjątkiem od tej reguły. Większość dostawców chroni użytkowników przed problemami z nośnikami poprzez odporne na błędy systemy pamięci masowej, dzięki czemu awarie ujawniają się późno.
  • Mimo że systemy tworzenia kopii zapasowych online są niezwykle niezawodne, strona przywracania danych musi zostać przetestowana, aby upewnić się, że nie występują żadne problemy z odzyskiwaniem, bezpieczeństwem lub szyfrowaniem.

Ponieważ odzyskiwanie jest ćwiczeniem kompleksowym, te przebiegi są zwykle planowane równolegle testowanie systemu a nie na poziomie jednostki.

Procedura testowania po renowacji

Przywrócenie danych to dopiero połowa sukcesu; przywrócona kopia musi zostać udowodniona jako użyteczna. Większość dużych korporacji zleca niezależnym audytorom okresowe przeprowadzanie ćwiczeń odzyskiwania danych. Kompleksowy plan odzyskiwania po awarii jest kosztowny w utrzymaniu i testowaniu, dlatego mniejsze organizacje często polegają na kopiach zapasowych i zewnętrznej pamięci masowej.

Po przywróceniu folderów i plików poniższe kontrole potwierdzą, czy zostały one prawidłowo odzyskane:

  • Zmień nazwę uszkodzonego folderu dokumentu, aby nie można było pomylić z nim przywróconej kopii.
  • Policz pliki w przywróconych folderach i porównaj tę liczbę z liczbą plików w oryginalnym folderze.
  • Otwórz kilka plików za pomocą aplikacji, która normalnie z nich korzysta, i sprawdź, czy dane można przeglądać i aktualizować jak zwykle.
  • Otwórz kilka plików różnego typu — zdjęcia, MP3i dokumenty, niektóre duże, niektóre małe.
  • Użyj narzędzi do porównywania plików i katalogów, które są najczęściej używane system operacyjny zapewniać.

FAQ

Testowanie failover sprawdza, czy ruch przełącza się płynnie na węzeł rezerwowy. Testowanie odzyskiwania idzie dalej i sprawdza, czy oryginalna usługa, jej dane i transakcje w trakcie transmisji zostały przywrócone do prawidłowego stanu.

RTO to czas potrzebny na przywrócenie usługi; RPO to dopuszczalna utrata danych. Test odzyskiwania mierzy zarówno czas przywracania dla RTO, jak i porównuje odzyskane dane z ostatnim znanym dobrym stanem dla RPO.

Powtarzają się trzy warianty: odzyskiwanie po awarii w przypadku awarii w całej lokalizacji, odzyskiwanie bazy danych w przypadku uszkodzonych magazynów danych oraz odzyskiwanie środowiska w przypadku uszkodzonej konfiguracji lub zależności. Każdy z nich korzysta z tego samego cyklu życia z innym wyzwalaczem awarii.

Modele uczenia maszynowego klasyfikują usługi według historii incydentów i głębokości zależności, dzięki czemu najbardziej ryzykowne ścieżki przywracania są uruchamiane jako pierwsze. Wykrywanie anomalii w dziennikach przywracania oznacza również uruchomienia, które zakończyły się, ale wygenerowały niekompletne dane.

Drugi pilot GitHub Szybko tworzy skrypty wspomagające wstrzykiwanie błędów, skrypty przywracania i asercje po przywróceniu. Tester nadal decyduje, który błąd wymusić i jak wygląda poprawny stan odzyskany, ponieważ oba są zgodne z regułami biznesowymi.

Coroczne ćwiczenia są powszechne, z kwartalnymi ćwiczeniami dla systemów krytycznych. Każda zmiana w narzędziu do tworzenia kopii zapasowych, platformie pamięci masowej lub architekturze powinna spowodować ponowne uruchomienie, ponieważ nieprzetestowana zmiana po cichu unieważnia poprzedni wynik.

Wymusza prawdziwe awarie, więc się nakłada Niszczące testy, ale celem jest odbudowa, a nie naprawa uszkodzeń. Przeprowadź test na odizolowanym poligonie testowym, a nie na rzeczywistych danych produkcyjnych.

Rejestruj wstrzykniętą awarię, czas rozpoczęcia i zakończenia, zmierzone RTO i RPO, kroki wymagające ręcznej interwencji oraz każdą rozbieżność wykrytą w przywróconych danych. Dodaj działania naprawcze i datę ponownego testu.

Podsumuj ten post następująco: