Menu

Samouczek dotyczący testowania migracji danych: kompletny przewodnik

data migration testing tutorial

Omówienie testowania migracji danych:

Dość często słychać, że aplikacja jest przenoszona na inny serwer, zmienia się technologia, jest aktualizowana do kolejnej wersji lub przenoszona na inny serwer bazy danych itp.,

  • Co to właściwie oznacza?
  • Czego oczekuje się od zespołu testującego w takich sytuacjach?

Z punktu widzenia testowania oznacza to, że aplikacja musi zostać gruntownie przetestowana end-to-end wraz z pomyślną migracją z istniejącego systemu do nowego.

Poradniki z tej serii:

W tym przypadku należy przeprowadzić testy systemowe na wszystkich danych, które są używane w starej aplikacji, a także na nowych danych. Istniejąca funkcjonalność musi zostać zweryfikowana wraz z nową / zmodyfikowaną funkcjonalnością.

Testowanie migracji danych

Zamiast po prostu testowania migracji, można go również nazwać testem migracji danych, w którym wszystkie dane użytkownika zostaną przeniesione do nowego systemu.

Tak więc testy migracji obejmują testowanie ze starymi danymi, nowymi danymi lub kombinacją obu, starych funkcji (niezmienionych funkcji) i nowych funkcji.

Stara aplikacja jest zwykle określana jako „ dziedzictwo ' podanie. Wraz z nową / zaktualizowaną aplikacją obowiązkowe jest również testowanie starszych aplikacji, dopóki nowe / zaktualizowane aplikacje nie staną się stabilne i spójne. Obszerny test migracji nowej aplikacji ujawni nowe problemy, których nie znaleziono w starszej aplikacji.

Czego się nauczysz:

Co to jest testowanie migracji?

Testowanie migracji to proces weryfikacji migracji starszego systemu do nowego systemu z minimalnymi zakłóceniami / przestojami, z integralnością danych i brakiem utraty danych, przy jednoczesnym zapewnieniu, że wszystkie określone funkcjonalne i niefunkcjonalne aspekty aplikacji są spełnione po migracja.

Prosta reprezentacja systemu migracji:

Testowanie migracji

Dlaczego test migracji?

Jak wiemy, migracja aplikacji do nowego systemu może wynikać z różnych przyczyn, konsolidacji systemu, przestarzałej technologii, optymalizacji lub z innych powodów.

Dlatego chociaż system w użyciu musi zostać przeniesiony do nowego systemu, konieczne jest zapewnienie następujących punktów:

  1. Należy unikać / minimalizować wszelkiego rodzaju zakłócenia / niedogodności spowodowane dla użytkownika w związku z migracją. Np .: przestój, utrata danych
  2. Należy upewnić się, że użytkownik może nadal korzystać ze wszystkich funkcji oprogramowania, powodując minimalne szkody podczas migracji lub nie powodując ich wcale. Np .: zmiana funkcjonalności, usunięcie określonej funkcjonalności
  3. Ważne jest również, aby przewidzieć i wykluczyć wszystkie możliwe usterki / przeszkody, które mogą wystąpić podczas rzeczywistej migracji systemu na żywo.

Dlatego też, aby zapewnić płynną migrację działającego systemu poprzez wyeliminowanie tych defektów, konieczne jest przeprowadzenie testów migracji w laboratorium.

Testowanie to ma swoje znaczenie i odgrywa istotną rolę, gdy pojawiają się dane.

Z technicznego punktu widzenia wymagane jest również wykonanie w poniższych celach:

  • Zapewnienie zgodności nowej / zaktualizowanej aplikacji z całym możliwym sprzętem i oprogramowaniem obsługiwanym przez starszą aplikację. Również nowy zgodność należy przetestować również pod kątem nowego sprzętu, platformy programowej.
  • Aby wszystkie istniejące funkcjonalności działały jak w starszej aplikacji. Nie powinno być zmian w sposobie działania aplikacji w porównaniu ze starszą wersją.
  • Możliwość wystąpienia dużej liczby defektów w wyniku migracji jest bardzo duża. Wiele defektów jest zwykle związanych z danymi, dlatego te defekty muszą zostać zidentyfikowane i naprawione podczas testowania.
  • Aby upewnić się, że czas odpowiedzi systemu dla nowej / zaktualizowanej aplikacji jest taki sam lub krótszy niż czas odpowiedzi w starszej aplikacji.
  • Aby upewnić się, że połączenie między serwerami, sprzętem, oprogramowaniem itp. Jest nienaruszone i nie zrywa się podczas testowania. Przepływ danych między różnymi komponentami nie powinien w żadnym wypadku zostać przerwany.

Kiedy wymagane jest to badanie?

Testowanie należy przeprowadzić zarówno przed migracją, jak i po niej.

jak testować stronę internetową

Różne fazy testu migracji do wykonania w laboratorium testowym można sklasyfikować jak poniżej.

  1. Testy przed migracją
  2. Testowanie migracji
  3. Testy po migracji

Oprócz powyższego, plik wykonywane są również następujące testy jako część całej działalności migracyjnej.

  1. Weryfikacja zgodności wstecznej
  2. Testowanie wycofywania

Przed wykonaniem tego Testu, każdy Tester powinien dokładnie zrozumieć poniższe punkty:

  1. Zmiany zachodzące w ramach nowego systemu (serwer, front end, DB, schemat, przepływ danych, funkcjonalność itp.)
  2. Zrozumienie faktycznej strategii migracji określonej przez zespół. Jak przebiega migracja, krok po kroku zmiany zachodzące na zapleczu systemu oraz skrypty odpowiedzialne za te zmiany.

Dlatego konieczne jest dokładne zbadanie starego i nowego systemu, a następnie odpowiednie zaplanowanie i zaprojektowanie przypadków testowych i scenariuszy testowych, które zostaną objęte w ramach powyższych faz testowania i przygotowanie strategii testowania.

Strategia testowania migracji danych

Projektowanie strategii testów na potrzeby migracji obejmuje zestaw czynności do wykonania i kilka aspektów, które należy wziąć pod uwagę. Ma to na celu zminimalizowanie błędów i zagrożeń występujących w wyniku migracji oraz efektywne przeprowadzenie testów migracji.

Działania w tym teście:

# 1) Wyspecjalizowana formacja drużynowa :

Stwórz zespół testowy z członkami posiadającymi wymaganą wiedzę i doświadczenie oraz zapewnij szkolenie związane z migrowanym systemem.

#dwa) Analiza ryzyka biznesowego, analiza możliwych błędów :

Bieżąca działalność nie powinna być utrudniana po migracji, a zatem wykonywać „ Analiza ryzyka biznesowego ” spotkania z udziałem odpowiednich interesariuszy (Kierownik Testów, Analityk Biznesowy, Architekci, Właściciele Produktu, Właściciel Biznesowy itp.) oraz identyfikacja ryzyk i możliwych do wdrożenia środków zaradczych. Testowanie powinno obejmować scenariusze ujawnienia tych zagrożeń i sprawdzenia, czy wdrożono odpowiednie środki zaradcze.

Przeprowadzić ' Analiza możliwych błędów ” używając odpowiednich „Podejścia do zgadywania błędów” a następnie projektuj testy dotyczące tych błędów, aby odkryć je podczas testowania.

# 3) Analiza i identyfikacja zakresu migracji:

Przeanalizuj jasny zakres testu migracji, kiedy i co należy przetestować.

# 4) Znajdź odpowiednie narzędzie do migracji:

Definiując strategię tego testowania, automatycznego lub ręcznego, określ narzędzia, które będą używane. Na przykład: Zautomatyzowane narzędzie do porównywania danych źródłowych i docelowych.

# 5) Zidentyfikuj odpowiednie środowisko testowe do migracji:

Zidentyfikuj oddzielne środowiska dla środowisk przed i po migracji, aby przeprowadzić weryfikację wymaganą jako część testowania. Zrozum i udokumentuj techniczne aspekty starszego i nowego systemu migracji, aby upewnić się, że środowisko testowe zostało skonfigurowane zgodnie z tym.

# 6) Dokument specyfikacji testu migracji i przegląd:

Przygotuj dokument Specyfikacji testu migracji, który jasno opisuje podejście testowe, obszary testowania, metody testowania (automatyczne, ręczne), metodologię testowania (czarna skrzynka, technika testowania białoskrzynkowego ), Liczbę cykli testowania, harmonogram testów, podejście do tworzenia danych i wykorzystywania danych na żywo (informacje wrażliwe należy zamaskować), specyfikację środowiska testowego, kwalifikacje testerów itp. Oraz przeprowadzić sesję przeglądową z interesariuszami.

# 7) Uruchomienie produkcyjne zmigrowanego systemu :

Przeanalizuj i udokumentuj listę rzeczy do zrobienia dla migracji produkcyjnej i opublikuj ją z dużym wyprzedzeniem

Różne fazy migracji

Poniżej podano różne fazy migracji.

Faza 1:Testy przed migracją

Przed migracją danych wykonywany jest zestaw czynności testowych w ramach fazy testowej przed migracją. Jest to ignorowane lub nie brane pod uwagę w prostszych aplikacjach. Jednak w przypadku migracji złożonych aplikacji konieczne są działania poprzedzające migrację.

Poniżej znajduje się lista działań, które są podejmowane w tej fazie:

  • Określ jasny zakres danych - jakie dane mają zostać uwzględnione, jakie dane mają zostać wykluczone, które wymagają transformacji / konwersji itp.
  • Wykonaj mapowanie danych między starszą i nową aplikacją - dla każdego typu danych w starszej aplikacji porównaj odpowiedni typ w nowej aplikacji, a następnie zmapuj je - Mapowanie wyższego poziomu.
  • Jeśli nowa aplikacja zawiera pole, które jest obowiązkowe, ale nie ma to miejsca w starszej wersji, a następnie upewnij się, że w dotychczasowej aplikacji to pole nie jest puste. - Mapowanie niższego poziomu.
  • Przestudiuj schemat danych nowej aplikacji - nazwy pól, typy, wartości minimalne i maksymalne, długość, pola obowiązkowe, walidacje na poziomie pól itp.
  • Należy zanotować kilka tabel w starszym systemie, a jeśli jakiekolwiek tabele zostały usunięte i dodane po migracji, należy zweryfikować.
  • Wiele rekordów w każdej tabeli, widoki należy odnotować w starszej aplikacji.
  • Zapoznaj się z interfejsami w nowej aplikacji i ich połączeniami. Dane przepływające przez interfejs powinny być dobrze zabezpieczone i nienaruszone.
  • Przygotuj przypadki testowe, scenariusze testowe i przypadki użycia dla nowych warunków w nowych aplikacjach.
  • Wykonaj zestaw przypadków testowych, scenariuszy ze zbiorem użytkowników i przechowuj wyniki, zapisywane dzienniki. To samo należy zweryfikować po migracji, aby upewnić się, że starsze dane i funkcje są nienaruszone.
  • Liczbę danych i zapisów należy wyraźnie zanotować, po migracji należy zweryfikować pod kątem braku utraty danych.

Faza 2:Testowanie migracji

' Przewodnik po migracji ”, którym jest przygotowany przez zespół ds. migracji musi być ściśle przestrzegany w celu przeprowadzenia działań migracyjnych. W idealnym przypadku migracja rozpoczyna się od utworzenia kopii zapasowej danych na taśmie, tak aby za każdym razem można było przywrócić starszy system.

Weryfikacja części dokumentacji „ Przewodnik po migracji ”jest również częścią testu migracji danych . Sprawdź, czy dokument jest jasny i łatwy do zrozumienia. Wszystkie skrypty i kroki muszą być poprawnie udokumentowane, bez jakichkolwiek niejasności. Wszelkiego rodzaju błędy w dokumentacji, brak dopasowania w kolejności wykonywania kroków również należy uznać za ważne, aby można je było zgłosić i naprawić.

Skrypty migracyjne, przewodnik i inne informacje związane z rzeczywistą migracją należy pobrać z repozytorium kontroli wersji w celu wykonania.

Zanotowanie faktycznego czasu potrzebnego na migrację od momentu rozpoczęcia migracji do pomyślnego przywrócenia systemu jest jednym z przypadków testowych do wykonania, a zatem „Czas potrzebny na migrację systemu” musi zostać odnotowane w końcowym raporcie z testów, który zostanie dostarczony jako część wyników testu migracji, a informacje te będą przydatne podczas uruchamiania produkcji. Przestój zarejestrowany w środowisku testowym jest ekstrapolowany w celu obliczenia przybliżonego czasu przestoju w działającym systemie.

Znajduje się w starym systemie, w którym będzie przeprowadzana migracja.

Podczas tych testów wszystkie komponenty środowiska są zwykle wyłączane i usuwane z sieci w celu przeprowadzenia działań związanych z migracją. Dlatego należy zwrócić uwagę na „Przestój” wymagany do testu migracji. Idealnie będzie to samo, co w czasie migracji.

Ogólnie rzecz biorąc, działania migracyjne zdefiniowane w dokumencie „Przewodnik po migracji” obejmują:

  • Rzeczywista migracja aplikacji
  • Zapory sieciowe, port, hosty, sprzęt, konfiguracje oprogramowania są modyfikowane zgodnie z nowym systemem, na który migrowana jest starsza wersja
  • Wycieki danych, przeprowadzane są kontrole bezpieczeństwa
  • Sprawdzana jest łączność między wszystkimi komponentami aplikacji

Zaleca się, aby testerzy zweryfikowali powyższe na zapleczu systemu lub przeprowadzając testy typu white box.

Po zakończeniu czynności migracji określonej w przewodniku, wszystkie serwery zostaną uruchomione i zostaną wykonane podstawowe testy związane z weryfikacją pomyślnej migracji, co zapewnia, że ​​wszystkie systemy end-to-end są odpowiednio połączone i wszystkie komponenty rozmawiają z każdym inne, DB działa i działa, front-end pomyślnie komunikuje się z zapleczem. Testy te należy wcześniej zidentyfikować i zapisać w dokumencie Migration Test Specification.

Istnieją możliwości, że oprogramowanie obsługuje wiele różnych platform. W takim przypadku migrację należy zweryfikować na każdej z tych platform osobno.

Weryfikacja skryptów migracji będzie częścią testu migracji. Czasami indywidualny skrypt migracji jest również weryfikowany za pomocą „testów białoskrzynkowych” w samodzielnym środowisku testowym.

W związku z tym testowanie migracji będzie połączeniem „testów białoskrzynkowych” i „czarnoskrzynkowych”.

Po zakończeniu weryfikacji związanej z migracją i pomyślnym przejściu odpowiednich testów, zespół może kontynuować czynności związane z testowaniem po migracji.

Faza 3:Testy po migracji

Po pomyślnym przeprowadzeniu migracji aplikacji pojawiają się testy po migracji.

Tutaj kompleksowe testowanie systemu odbywa się w środowisku testowym. Testerzy wykonują zidentyfikowane przypadki testowe, scenariusze testowe, przypadki użycia ze starszymi danymi, a także nowy zestaw danych.

Oprócz tego istnieją określone elementy do zweryfikowania w migrowanych środowiskach, które są wymienione poniżej:

Wszystkie z nich są udokumentowane jako przypadek testowy i zawarte w dokumencie „Specyfikacja testu”.

  1. Sprawdź, czy wszystkie dane ze starszej wersji są migrowane do nowej aplikacji w zaplanowanym czasie przestoju. Aby to zapewnić, porównaj liczbę rekordów między starszą i nową aplikacją dla każdej tabeli i widoków w bazie danych. Podaj również czas potrzebny na przeniesienie, powiedzmy 10000 rekordów.
  2. Sprawdź, czy wszystkie zmiany schematu (dodane lub usunięte pola i tabele) zgodnie z nowym systemem są zaktualizowane.
  3. Dane migrowane ze starszej do nowej aplikacji powinny zachować swoją wartość i format, chyba że określono inaczej. Aby to zapewnić, porównaj wartości danych między starszą i nową bazą danych aplikacji.
  4. Przetestuj zmigrowane dane w nowej aplikacji. Tutaj omówiono maksymalną liczbę możliwych przypadków. Aby zapewnić 100% pokrycie w zakresie weryfikacji migracji danych, użyj narzędzia do automatycznego testowania.
  5. Sprawdź bezpieczeństwo bazy danych.
  6. Sprawdź integralność danych dla wszystkich możliwych przykładowych rekordów.
  7. Sprawdź i upewnij się, że wcześniej obsługiwane funkcje w starszym systemie działają zgodnie z oczekiwaniami w nowym systemie.
  8. Sprawdź przepływ danych w aplikacji, która obejmuje większość komponentów.
  9. Interfejs między komponentami powinien zostać dokładnie przetestowany, ponieważ dane nie powinny być modyfikowane, tracone ani uszkodzone podczas przechodzenia przez komponenty. Aby to zweryfikować, można użyć przypadków testowych integracji.
  10. Sprawdź nadmiarowość starszych danych. Żadne starsze dane nie powinny być powielane podczas migracji
  11. Sprawdź przypadki niezgodności danych, takie jak zmiana typu danych, zmiana formatu przechowywania itp.,
  12. Wszystkie kontrole na poziomie pola w starszej aplikacji powinny być również uwzględnione w nowej aplikacji
  13. Jakiekolwiek dodanie danych w nowej aplikacji nie powinno odzwierciedlać starszej wersji
  14. Aktualizowanie danych starszej aplikacji za pośrednictwem nowej aplikacji powinno być obsługiwane. Po zaktualizowaniu w nowej aplikacji nie powinna odzwierciedlać starszej wersji.
  15. Usuwanie danych starszej aplikacji w nowej aplikacji powinno być obsługiwane. Po usunięciu w nowej aplikacji nie powinno również usuwać danych w starszych wersjach.
  16. Sprawdź, czy zmiany wprowadzone w starszym systemie obsługują nową funkcjonalność dostarczaną jako część nowego systemu.
  17. Sprawdź, czy użytkownicy starszego systemu mogą nadal korzystać zarówno ze starej, jak i nowej funkcjonalności, zwłaszcza tych, w których wprowadzane są zmiany. Wykonaj przypadki testowe i wyniki testów zapisane podczas testów przed migracją.
  18. Stwórz nowych użytkowników w systemie i przeprowadź testy, aby upewnić się, że funkcjonalność ze starszej i nowej aplikacji obsługuje nowo utworzonych użytkowników i działa poprawnie.
  19. Przeprowadzaj testy funkcjonalne na różnych próbkach danych (różne grupy wiekowe, użytkownicy z różnych regionów itp.)
  20. Konieczne jest również sprawdzenie, czy „Flagi funkcji” są włączone dla nowych funkcji, a włączenie / wyłączenie umożliwia włączanie i wyłączanie funkcji.
  21. Testowanie wydajności jest ważne, aby upewnić się, że migracja do nowego systemu / oprogramowania nie pogorszyła wydajności systemu.
  22. Wymagane jest również przeprowadzenie testów obciążeniowych i testów wytrzymałościowych, aby zapewnić stabilność systemu.
  23. Sprawdź, czy aktualizacja oprogramowania nie otworzyła żadnych luk w zabezpieczeniach i dlatego przeprowadź testy bezpieczeństwa, szczególnie w obszarze, w którym wprowadzono zmiany w systemie podczas migracji.
  24. Użyteczność to kolejny aspekt, który należy zweryfikować, przy czym jeśli układ GUI / system front-endu zmienił się lub jakakolwiek funkcjonalność uległa zmianie, jaka jest łatwość użytkowania, którą odczuwa użytkownik końcowy w porównaniu do starszego systemu.

Ponieważ zakres testów po migracji staje się bardzo szeroki, idealnym rozwiązaniem jest wyodrębnienie ważnych testów, które należy wykonać najpierw, aby potwierdzić, że migracja się powiodła, a następnie przeprowadzić pozostałe później.

Wskazane jest również zautomatyzowanie od końca do końca funkcjonalnych przypadków testowych i innych możliwych przypadków testowych, aby można było skrócić czas testowania, a wyniki były szybko dostępne.

Kilka wskazówek dla testerów dotyczących pisania przypadków testowych do wykonania po migracji:

  • Kiedy aplikacja jest migrowana, nie oznacza to, że przypadki testowe muszą być napisane dla całej nowej aplikacji. Przypadki testowe już zaprojektowane dla starszej wersji powinny nadal działać dobrze dla nowej aplikacji. Dlatego w miarę możliwości należy używać starych przypadków testowych i konwertować starsze przypadki testowe na przypadki nowej aplikacji, jeśli jest to wymagane.
  • Jeśli nastąpi zmiana funkcji w nowej aplikacji, należy zmodyfikować przypadki testowe związane z tą funkcją.
  • Jeśli do nowej aplikacji dodano nową funkcję, należy zaprojektować nowe przypadki testowe dla tej konkretnej funkcji.
  • Gdy w nowej aplikacji wystąpi jakikolwiek spadek funkcji, powiązane przypadki testowe starszej aplikacji nie powinny być brane pod uwagę przy wykonywaniu po migracji i powinny być oznaczone jako nieważne i oddzielone.
  • Zaprojektowane przypadki testowe powinny zawsze być niezawodne i spójne pod względem użytkowania. Weryfikacja danych krytycznych powinna być uwzględniona w przypadkach testowych, aby nie została pominięta podczas wykonywania.
  • Jeśli projekt nowej aplikacji różni się od projektu starszej wersji (UI), należy zmodyfikować przypadki testowe związane z interfejsem użytkownika, aby dostosować nowy projekt. Decyzja o aktualizacji lub zapisaniu nowych, w tym przypadku, może zostać podjęta przez testera na podstawie wielkości zmiany.

Testowanie zgodności wstecznej

Migracja systemu wymaga również od testerów sprawdzenia „wstecznej kompatybilności”, w której wprowadzony nowy system jest kompatybilny ze starym systemem (co najmniej 2 poprzednie wersje) i zapewnia, że ​​działa on doskonale z tymi wersjami.

Zgodność z poprzednimi wersjami ma zapewnić:

  1. Czy nowy system obsługuje funkcje obsługiwane we wcześniejszych 2 wersjach wraz z nową.
  2. System można pomyślnie migrować z wcześniejszych 2 wersji bez żadnych kłopotów.

Dlatego konieczne jest zapewnienie kompatybilności wstecznej systemu poprzez wykonanie testów związanych z obsługą kompatybilności wstecznej. Testy związane z kompatybilnością wsteczną muszą zostać zaprojektowane i uwzględnione w dokumencie specyfikacji testów w celu wykonania.

Testowanie wycofywania

W przypadku jakichkolwiek problemów podczas przeprowadzania migracji lub w przypadku niepowodzenia migracji w dowolnym momencie migracji, wówczas system powinien mieć możliwość przywrócenia do starszego systemu i szybkiego wznowienia jego funkcji bez wpływu na użytkowników i funkcjonalność obsługiwana wcześniej.

Aby to zweryfikować, scenariusze testów błędów migracji muszą być zaprojektowane jako część testów negatywnych, a mechanizm wycofywania musi zostać przetestowany. Całkowity czas potrzebny na powrót do starszego systemu również musi zostać zarejestrowany i podany w wynikach testów.

Po przywróceniu, główna funkcjonalność i testy regresji (automatyczne) należy uruchomić, aby upewnić się, że migracja na nic nie wpłynęła, a wycofanie zakończyło się sukcesem w przywróceniu dotychczasowego systemu.

Raport podsumowujący testy migracji

Podsumowanie testu powinien zostać utworzony po zakończeniu testów i powinien obejmować raport podsumowania różnych testów / scenariuszy przeprowadzonych w ramach różnych faz migracji wraz ze statusem wyników (zaliczony / niezaliczony) oraz dziennikami testów.

Należy wyraźnie podać czas zarejestrowany dla następujących czynności:

  1. Całkowity czas migracji
  2. Przestój aplikacji
  3. Czas poświęcony na migrację 10000 rekordów.
  4. Czas spędzony na wycofaniu.

Oprócz powyższych informacji można również zgłosić wszelkie uwagi / zalecenia.

Wyzwania w testowaniu migracji danych

Wyzwania stojące przed tymi testami dotyczą głównie danych. Poniżej znajduje się kilka z listy:

1) Jakość danych:

Może się okazać, że dane używane w starszej aplikacji są niskiej jakości w nowej / zaktualizowanej aplikacji. W takich przypadkach jakość danych musi zostać poprawiona, aby spełnić standardy biznesowe.

Czynniki takie jak założenia, konwersje danych po migracji, dane wprowadzone w samej starszej aplikacji są nieprawidłowe, słaba analiza danych itp. Prowadzi do niskiej jakości danych. Skutkuje to wysokimi kosztami operacyjnymi, zwiększonym ryzykiem integracji danych i odchyleniem od celu biznesowego.

# 2) Niezgodność danych:

Dane migrowane ze starszej do nowej / zaktualizowanej aplikacji mogą być niezgodne w nowej. Może to wynikać ze zmiany rodzaju danych, formatu przechowywania danych, przedefiniowania celu, w jakim dane są wykorzystywane.

Skutkuje to ogromnym wysiłkiem, aby zmodyfikować niezbędne zmiany, aby skorygować niezgodne dane lub zaakceptować je i dostosować do tego celu.

# 3) Utrata danych:

Dane mogą zostać utracone podczas migracji ze starszej do nowej / zaktualizowanej aplikacji. Mogą to być pola obowiązkowe lub nieobowiązkowe. Jeśli utracone dane dotyczą pól nieobowiązkowych, rekord dla nich będzie nadal ważny i będzie można go ponownie zaktualizować.

Ale jeśli dane z obowiązkowego pola zostaną utracone, sam rekord staje się nieważny i nie można go wycofać. Spowoduje to ogromną utratę danych i powinno być odzyskane albo z kopii zapasowej bazy danych, albo z dzienników audytu, jeśli zostały poprawnie przechwycone.

# 4) Ilość danych:

Ogromne dane, które wymagają dużo czasu na migrację w oknie przestoju migracji. Na przykład: Zdrapki w branży telekomunikacyjnej, użytkownicy korzystający z inteligentnej platformy sieciowej itp., Tutaj wyzwanie pojawia się z czasem, starsze dane zostaną wyczyszczone, zostaną utworzone ogromne nowe dane, które należy ponownie zmigrować. Automatyzacja to rozwiązanie do ogromnej migracji danych.

jakie jest najlepsze narzędzie do usuwania złośliwego oprogramowania

# 5) Symulacja środowiska czasu rzeczywistego (z aktualnymi danymi):

Symulacja środowiska czasu rzeczywistego w laboratorium testowym to kolejne prawdziwe wyzwanie, w którym testerzy wchodzą w różnego rodzaju problemy z rzeczywistymi danymi i rzeczywistym systemem, z którymi nie mają do czynienia podczas testów.

Zatem próbkowanie danych, replikacja rzeczywistego środowiska, identyfikacja ilości danych zaangażowanych w migrację jest dość ważne podczas przeprowadzania Testów migracji danych.

# 6) Symulacja ilości danych:

Zespoły muszą bardzo dokładnie przestudiować dane w systemie na żywo i powinny wymyślić typową analizę i próbkowanie danych.

Na przykład: użytkownicy w wieku poniżej 10 lat, 10-30 lat itp., W miarę możliwości dane z transmisji na żywo należy pozyskiwać, jeśli nie, tworzenie danych musi odbywać się w środowisku testowym. Do tworzenia dużej ilości danych należy używać zautomatyzowanych narzędzi. Tam, gdzie ma to zastosowanie, można zastosować ekstrapolację, jeśli nie można zasymulować objętości.

Wskazówki, jak złagodzić ryzyko migracji danych

Poniżej podano kilka wskazówek, które należy wykonać, aby złagodzić ryzyko migracji danych:

  • Standaryzuj dane używane w starszym systemie, tak aby po migracji standardowe dane były dostępne w nowym systemie
  • Popraw jakość danych, aby podczas migracji istniały dane jakościowe do przetestowania, dając wrażenie testowania jako użytkownik końcowy
  • Wyczyść dane przed migracją, aby po migracji zduplikowane dane nie były obecne w nowym systemie, a także utrzyma cały system w czystości
  • Ponownie sprawdź ograniczenia, procedury składowane, złożone zapytania, które dają dokładne wyniki, tak aby po migracji poprawne dane zostały zwrócone również w nowym systemie
  • Zidentyfikuj prawidłowe narzędzie do automatyzacji do przeprowadzania kontroli danych / sprawdzania rekordów w nowym systemie w porównaniu ze starszym.

Wniosek

Dlatego biorąc pod uwagę złożoność związaną z przeprowadzaniem Testów migracji danych, mając na uwadze, że mały błąd w jakimkolwiek aspekcie weryfikacji podczas testowania doprowadzi do ryzyka niepowodzenia migracji na produkcji, bardzo ważne jest przeprowadzenie dokładnych i dokładnych badań. & analiza systemu przed i po migracji. Zaplanuj i zaprojektuj skuteczną strategię migracji przy użyciu solidnych narzędzi oraz wykwalifikowanych i przeszkolonych testerów.

Ponieważ wiemy, że migracja ma ogromny wpływ na jakość aplikacji, cały zespół musi włożyć sporo wysiłku, aby zweryfikować cały system we wszystkich aspektach, takich jak funkcjonalność, wydajność, bezpieczeństwo, użyteczność, dostępność, niezawodność, kompatybilność itp., co z kolei zapewni pomyślne „testy migracji”.

„Różne rodzaje migracji” co zwykle zdarza się dość często w rzeczywistości, a sposoby radzenia sobie z ich testowaniem zostaną pokrótce wyjaśnione w naszym następny tutorial z tej serii .

O Autorach: Ten przewodnik został napisany przez autorkę STH Nandini. Ma ponad 7 lat doświadczenia w testowaniu oprogramowania. Dziękuję również autorce STH Gayathri S. za przejrzenie i przekazanie jej sugestii dotyczących ulepszenia tej serii. Gayathri ma ponad 18-letnie doświadczenie w tworzeniu oprogramowania i usługach testowania.

Przekaż nam swoje uwagi / sugestie dotyczące tego samouczka.

rekomendowane lektury

^