Menu

Výukový program pro testování migrace dat: Kompletní průvodce

data migration testing tutorial

Vyzkoušejte Náš Nástroj Pro Odstranění Problémů

Přehled testování migrace dat:

Často je slyšet, že aplikace je přesunuta na jiný server, technologie je změněna, je aktualizována na další verzi nebo přesunuta na jiný databázový server atd.,

  • Co to vlastně znamená?
  • Co se v těchto situacích očekává od testovacího týmu?

Z hlediska testování to vše znamená, že aplikace musí být důkladně testována end-to-end spolu s úspěšnou migrací ze stávajícího systému do nového systému.

Výukové programy v této sérii:

Testování systému je v tomto případě nutné provést se všemi daty, která se používají ve staré aplikaci i v nových datech. Stávající funkce je třeba ověřit spolu s novými / upravenými funkcemi.

Testování migrace dat

Místo pouhého testování migrace jej lze také nazvat jako Test migrace dat, kde budou přenesena všechna data uživatele do nového systému.

Testování migrace tedy zahrnuje testování se starými daty, novými daty nebo kombinací obou, starých funkcí (nezměněné funkce) a nových funkcí.

Stará aplikace se obvykle nazývá „ dědictví ' aplikace. Spolu s novou / upgradovanou aplikací je také povinné udržovat testování starší aplikace, dokud se nové / upgradované aplikace nestanou stabilní a konzistentní. Rozsáhlý test migrace u nové aplikace odhalí nové problémy, které nebyly nalezeny ve starší aplikaci.

Co se naučíte:

Co je testování migrace?

Migration Testing je proces ověřování migrace staršího systému na nový systém s minimálním narušením / prostojem, s integritou dat a bez ztráty dat, přičemž je zajištěno, že všechny specifikované funkční a nefunkční aspekty aplikace budou splněny po migrace.

Jednoduché znázornění migračního systému:

Testování migrace

Proč migrační test?

Jak víme, migrace aplikace na nový systém by mohla být z různých důvodů, konsolidace systému, zastaralé technologie, optimalizace nebo z jiných důvodů.

I když je tedy nutné systém migrovat do nového systému, je nezbytné zajistit následující body:

  1. Je třeba se vyhnout / minimalizovat jakýkoli druh narušení / nepříjemností způsobených uživateli v důsledku migrace. Např .: prostoje, ztráta dat
  2. Je třeba zajistit, aby uživatel mohl i nadále využívat všechny funkce softwaru tím, že během migrace způsobí minimální nebo žádné poškození. Např .: změna funkčnosti, odebrání určité funkce
  3. Je také důležité předvídat a vyloučit všechny možné závady / překážky, které mohou nastat během skutečné migrace živého systému.

Proto, abychom zajistili hladkou migraci živého systému odstraněním těchto vad, je nezbytné provést testování migrace v laboratoři.

Toto testování má svůj vlastní význam a hraje zásadní roli, když se data dostanou do obrazu.

Technicky je také nutné provést jej pro níže uvedené účely:

  • Zajistit kompatibilitu nové / upgradované aplikace s veškerým možným hardwarem a softwarem, které starší aplikace podporuje. Také nové kompatibilita by měl být také testován na nový hardware, softwarovou platformu.
  • Chcete-li zajistit, aby všechny stávající funkce fungovaly jako ve starší aplikaci. Ve srovnání se starší verzí by nemělo dojít ke změně způsobu fungování aplikace.
  • Možnost velkého počtu vad v důsledku migrace je velmi vysoká. Mnoho defektů bude obvykle souviset s daty, a proto je nutné je během testování identifikovat a opravit.
  • Zajistit, zda je doba odezvy systému nové / upgradované aplikace stejná nebo kratší než doba potřebná pro starší aplikaci.
  • Zajistit, aby spojení mezi servery, hardwarem, softwarem atd. Bylo neporušené a během testování se nepřerušilo. Tok dat mezi různými komponentami by se neměl za žádných podmínek přerušit.

Kdy je toto testování vyžadováno?

Testování musí být provedeno před i po migraci.

Různé fáze testu migrace které lze provést v testovací laboratoři, lze klasifikovat níže.

  1. Testování před migrací
  2. Testování migrace
  3. Testování po migraci

Kromě výše uvedeného, jsou prováděny také následující testy jako součást celé migrační aktivity.

  1. Zpětné ověření kompatibility
  2. Testování vrácení zpět

Před provedením tohoto testování je nezbytné, aby každý tester jasně porozuměl níže uvedeným bodům:

  1. Změny probíhající jako součást nového systému (server, front-end, databáze, schéma, tok dat, funkčnost atd.)
  2. Pochopit skutečnou strategii migrace stanovenou týmem. Jak probíhá migrace, postupné změny probíhající v backendu systému a skriptů odpovědných za tyto změny.

Proto je nezbytné provést důkladnou studii starého a nového systému a poté odpovídajícím způsobem naplánovat a navrhnout testovací případy a testovací scénáře, které mají být zahrnuty jako součást výše uvedených fází testování, a připravit strategii testování.

Strategie testování migrace dat

Návrh strategie testování pro migraci zahrnuje sadu činností, které je třeba provést, a několik aspektů, které je třeba vzít v úvahu. To má minimalizovat chyby a rizika, která se vyskytnou v důsledku migrace, a efektivně provádět testování migrace.

Činnosti v tomto testování:

# 1) Specializovaná formace týmu :

Vytvořte testovací tým se členy, kteří mají požadované znalosti a zkušenosti, a poskytněte školení týkající se systému, který je migrován.

#dva) Analýza obchodního rizika, analýza možných chyb :

Současné podnikání by po migraci nemělo být omezováno, a tedy provádět „ Analýza obchodních rizik “ schůzky zahrnující správné zúčastněné strany (vedoucí testů, obchodní analytik, architekti, vlastníci produktů, vlastníci firem atd.) a identifikují rizika a realizovatelná zmírnění. Testování by mělo zahrnovat scénáře k odhalení těchto rizik a ověření, zda byla implementována náležitá zmírnění.

Chování Analýza možných chyb “ pomocí vhodných „Přístupy k odhadování chyb“ a poté navrhnout testy kolem těchto chyb, abyste je během testování odhalili.

nejlepší bezplatný software ke stahování videí z YouTube

# 3) Analýza a identifikace rozsahu migrace:

Analyzujte jasný rozsah testu migrace podle toho, kdy a co je třeba testovat.

# 4) Určete vhodný nástroj pro migraci:

Při definování strategie tohoto testování, automatizovaného nebo manuálního, identifikujte nástroje, které budou použity. Např: Automatizovaný nástroj pro porovnání zdrojových a cílových dat.

# 5) Určete vhodné testovací prostředí pro migraci:

Určete samostatná prostředí pro prostředí před a po migraci, abyste mohli provést jakékoli ověření, které je vyžadováno jako součást testování. Pochopte a zdokumentujte technické aspekty staršího a nového systému migrace, abyste zajistili, že testovací prostředí je nastaveno podle toho.

# 6) Specifikační dokument migrace a recenze:

Připravte dokument Specifikace migračního testu, který jasně popisuje přístup k testování, oblasti testování, testovací metody (automatizované, manuální), metodiku testování (černá skříňka, technika testování bílé krabice ), Počet cyklů testování, plán testování, přístup k vytváření dat a používání živých dat (je třeba maskovat citlivé informace), specifikace testovacího prostředí, kvalifikace testerů atd., A se zúčastněnými stranami proběhne kontrolní relace.

# 7) Zahájení výroby migrovaného systému :

Analyzujte a dokumentujte seznam úkolů pro migraci výroby a publikujte jej v dostatečném předstihu

Různé fáze migrace

Níže jsou uvedeny různé fáze migrace.

Fáze 1:Testování před migrací

Před migrací dat se sada testovacích aktivit provádí jako součást fáze před migrací. To je v jednodušších aplikacích ignorováno nebo se o něm neuvažuje. Ale když se mají migrovat složité aplikace, jsou aktivity před migrací nutností.

Níže je uveden seznam akcí, které jsou v této fázi prováděny:

  • Stanovte jasný rozsah dat - jaká data je třeba zahrnout, jaká data je třeba vyloučit, která data je třeba transformovat / převést atd.
  • Proveďte mapování dat mezi starší a novou aplikací - pro každý typ dat ve starší aplikaci porovnejte její relevantní typ v nové aplikaci a poté je mapujte - mapování na vyšší úrovni.
  • Pokud má nová aplikace pole, které je v ní povinné, ale není tomu tak ve starší verzi, a pak zajistěte, aby ve starší verzi nebylo toto pole jako null. - Mapování na nižší úrovni.
  • Prostudujte si schéma dat nové aplikace - názvy polí, typy, minimální a maximální hodnoty, délku, povinná pole, ověření na úrovni pole atd., Jasně
  • Je třeba poznamenat několik tabulek ve starém systému a pokud jsou nějaké tabulky zrušeny a je třeba ověřit přidanou po migraci.
  • Počet záznamů v každé tabulce, zobrazení by měla být uvedena ve starší aplikaci.
  • Prostudujte si rozhraní v nové aplikaci a jejich připojení. Tok dat v rozhraní by měl být vysoce zabezpečený a neměl by být narušen.
  • Připravte testovací případy, testovací scénáře a případy použití pro nové podmínky v nových aplikacích.
  • Provádějte sadu testovacích případů, scénářů se sadou uživatelů a uchovávejte výsledky, protokoly uložené. Totéž je třeba ověřit po migraci, aby bylo zajištěno, že starší data a funkce budou neporušené.
  • Počet dat a záznamů je třeba jasně zaznamenat, je třeba je po migraci ověřit, aby nedošlo ke ztrátě dat.

Fáze 2:Testování migrace

'' Průvodce migrací “, což je k provedení migrační aktivity je třeba přísně dodržovat pokyny připravené migračním týmem. V ideálním případě aktivita migrace začíná daty zálohovanými na pásku, aby bylo možné kdykoli obnovit starší systém.

Ověření části dokumentace „ Průvodce migrací je také součástí testování migrace dat . Ověřte, zda je dokument jasný a snadno sledovatelný. Všechny skripty a kroky musí být správně zdokumentovány bez jakékoli nejednoznačnosti. Jakýkoli druh chyb v dokumentaci, chybějící shody v pořadí provedení kroků je také třeba považovat za důležité, aby mohly být hlášeny a opraveny.

Skripty pro migraci, průvodce a další informace týkající se skutečné migrace je třeba vyzvednout z úložiště správy verzí pro provedení.

Poznamenat si skutečný čas potřebný k migraci od okamžiku zahájení migrace do úspěšné obnovy systému, je jedním z testovacích případů, které se mají provést, a proto „Čas potřebný k migraci systému“ je třeba zaznamenat do závěrečné zprávy o testu, která bude doručena jako součást výsledků testů migrace, a tyto informace budou užitečné při zahájení výroby. Odstávka zaznamenaná v testovacím prostředí je extrapolována pro výpočet přibližné doby odstávky v živém systému.

Je na starém systému, kde bude migrační aktivita prováděna.

Během tohoto testování budou všechny součásti prostředí obvykle přeneseny a odstraněny ze sítě za účelem provádění migračních aktivit. Proto je nutné si povšimnout „Odstávka“ vyžadováno pro test migrace. V ideálním případě to bude stejné jako v době migrace.

Aktivita migrace definovaná v dokumentu „Průvodce migrací“ obecně zahrnuje:

  • Skutečná migrace aplikace
  • Firewally, port, hostitelé, hardware, softwarové konfigurace jsou upraveny podle nového systému, na který se migruje starší verze
  • Úniky dat, provádějí se bezpečnostní kontroly
  • Je zkontrolováno připojení mezi všemi komponentami aplikace

Doporučuje se, aby testeři ověřili výše uvedené v zadní části systému nebo provedením testování bílé skříňky.

Po dokončení aktivity migrace uvedené v příručce se zobrazí všechny servery a provedou se základní testy související s ověřením úspěšné migrace, což zajistí, že jsou všechny systémy typu end-to-end správně připojeny a všechny komponenty ke každému z nich mluví. ostatní, DB je v provozu, front-end úspěšně komunikuje se zadním koncem. Tyto testy je třeba identifikovat dříve a zaznamenat je v dokumentu Specifikace testu migrace.

Tento software podporuje několik různých platforem. V takovém případě je třeba migraci ověřit na každé z těchto platforem samostatně.

Součástí testu migrace bude ověření migračních skriptů. Skript individuální migrace se někdy ověřuje také pomocí „testování bílé skříňky“ v samostatném testovacím prostředí.

Z tohoto důvodu bude testování migrace kombinací jak „bílé skříňky, tak i černé skříňky“.

Po dokončení tohoto ověření souvisejícího s migrací a absolvování příslušných testů může tým pokračovat v aktivitě testování po migraci.

Fáze č. 3:Testování po migraci

Jakmile je aplikace úspěšně migrována, objeví se po ní testování po migraci.

Zde se v testovacím prostředí provádí komplexní testování systému. Testeři provádějí identifikované testovací případy, testovací scénáře, případy použití se staršími daty i novou sadu dat.

Kromě těchto existují v migrovaných prostředích ověřené konkrétní položky, které jsou uvedeny níže:

Všechny jsou zdokumentovány jako testovací případ a jsou zahrnuty v dokumentu „Specifikace testu“.

  1. Zkontrolujte, zda jsou všechna data ve starší verzi přenesena do nové aplikace v době plánovaného výpadku. Chcete-li to zajistit, porovnejte počet záznamů mezi starší a novou aplikací pro každou tabulku a zobrazení v databázi. Také nahlaste čas potřebný k pohybu, řekněme 10 000 záznamů.
  2. Zkontrolujte, zda jsou aktualizovány všechny změny schématu (pole a tabulky přidané nebo odebrané) podle nového systému.
  3. Data migrovaná ze starší verze do nové aplikace by si měla zachovat svoji hodnotu a formát, pokud k tomu není specifikováno. Abyste to zajistili, porovnejte hodnoty dat mezi starší a novou databází aplikace.
  4. Otestujte migrovaná data proti nové aplikaci. Zde uvádíme maximální počet možných případů. Chcete-li zajistit 100% pokrytí s ohledem na ověření migrace dat, použijte automatizovaný testovací nástroj.
  5. Zkontrolujte zabezpečení databáze.
  6. Zkontrolujte integritu dat pro všechny možné záznamy vzorků.
  7. Zkontrolujte a zajistěte, aby dřívější podporované funkce ve starém systému fungovaly podle očekávání v novém systému.
  8. Zkontrolujte tok dat v aplikaci, která pokrývá většinu komponent.
  9. Rozhraní mezi komponentami by mělo být důkladně otestováno, protože data by neměla být upravována, ztracena a poškozena, když procházejí komponenty. K ověření lze použít testovací případy integrace.
  10. Zkontrolujte redundanci starších dat. Během migrace by se neměla duplikovat žádná starší data
  11. Zkontrolujte případy nesouladu dat, jako je změna datového typu, změna formátu ukládání atd.,
  12. Všechny kontroly na úrovni pole ve starší aplikaci by měly být zahrnuty také v nové aplikaci
  13. Jakékoli přidání dat v nové aplikaci by se nemělo odrážet zpět na starší verzi
  14. Měla by být podporována aktualizace dat starší aplikace prostřednictvím nové aplikace. Po aktualizaci v nové aplikaci by se neměla odrážet zpět na starší verzi.
  15. Mělo by být podporováno mazání dat starší aplikace v nové aplikaci. Jakmile je v nové aplikaci odstraněn, neměla by také mazat starší data.
  16. Ověřte, zda změny provedené ve starém systému podporují novou funkčnost dodávanou jako součást nového systému.
  17. Ověřte, že uživatelé ze staršího systému mohou i nadále používat starou i novou funkčnost, zejména ty, u nichž se jedná o změny. Proveďte testovací případy a výsledky testů uložené během testování před migrací.
  18. Vytvářejte nové uživatele v systému a provádějte testy, abyste zajistili, že funkčnost ze starší i nové aplikace podporuje nově vytvořené uživatele a funguje dobře.
  19. Provádějte testy související s funkčností pomocí různých vzorků dat (různé věkové skupiny, uživatelé z různých oblastí atd.)
  20. Rovněž je nutné ověřit, zda jsou u nových funkcí povoleny „příznaky funkcí“ a zapnutí / vypnutí umožňuje jejich zapnutí a vypnutí.
  21. Testování výkonu je důležité k zajištění toho, aby migrace na nový systém / software nezhoršila výkon systému.
  22. Rovněž je nutné provést zátěžové a zátěžové testy, aby byla zajištěna stabilita systému.
  23. Ověřte, zda aktualizace softwaru neotevřela žádné chyby zabezpečení, a proto proveďte testování zabezpečení, zejména v oblasti, kde byly během migrace provedeny změny v systému.
  24. Použitelnost je dalším aspektem, který je třeba ověřit, přičemž pokud se změnilo rozložení grafického uživatelského rozhraní / front-end systém nebo se změnila jakákoli funkce, jaké je snadné použití, které koncový uživatel pociťuje ve srovnání se starším systémem.

Vzhledem k tomu, že rozsah testování po migraci se stává velmi velkým, je ideální oddělit důležité testy, které je třeba nejprve provést, aby se ověřilo, zda je migrace úspěšná, a poté zbývající provést později.

Je také vhodné automatizovat koncové funkční testovací případy a další možné testovací případy, aby bylo možné zkrátit dobu testování a výsledky byly rychle k dispozici.

Několik tipů pro testery pro psaní testovacích případů pro provedení po migraci:

  • Když je aplikace migrována, neznamená to, že testovací případy musí být napsány pro celou novou aplikaci. Testovací případy, které jsou již navrženy pro starší verzi, by pro novou aplikaci měly stále platit. Pokud je to možné, použijte pokud možno staré testovací případy a převeďte starší testovací případy na případy nové aplikace.
  • Pokud v nové aplikaci dojde ke změně funkce, pak je třeba upravit testovací případy související s funkcí.
  • Pokud je v nové aplikaci přidána nějaká nová funkce, měly by být pro tuto konkrétní funkci navrženy nové testovací případy.
  • Pokud v nové aplikaci dojde k poklesu funkcí, testovací případy související starší aplikace by neměly být brány v úvahu pro provedení po migraci a měly by být označeny jako neplatné a udržovány odděleně.
  • Navrhované testovací případy by měly být vždy spolehlivé a konzistentní z hlediska použití. Ověření kritických dat by mělo být zahrnuto do testovacích případů, aby nedošlo k jejich úniku při provádění.
  • Pokud je design nové aplikace odlišný od designu starší verze (UI), měly by být testovací případy související s uživatelským rozhraním upraveny tak, aby se nový design přizpůsobil. Rozhodnutí buď aktualizovat, nebo zapsat nové, v tomto případě může provést tester na základě objemu provedených změn.

Zpětné testování kompatibility

Migrace systému rovněž vyžaduje, aby testeři ověřili „Zpětnou kompatibilitu“, přičemž nový zavedený systém je kompatibilní se starým systémem (minimálně 2 předchozí verze) a zajišťuje, že s těmito verzemi dokonale funguje.

Zpětná kompatibilita má zajistit:

  1. Zda nový systém podporuje funkce podporované v dřívějších 2 verzích spolu s novou.
  2. Systém lze úspěšně migrovat z dřívějších 2 verzí bez jakýchkoli potíží.

Proto je nezbytné zajistit zpětnou kompatibilitu systému konkrétním provedením testů souvisejících s podporou zpětné kompatibility. Testy týkající se zpětné kompatibility je třeba navrhnout a zahrnout do dokumentu Specifikace testu pro provedení.

Testování vrácení zpět

V případě jakýchkoli problémů při provádění migrace nebo pokud dojde k selhání migrace kdykoli během migrace, mělo by být možné, aby se systém vrátil zpět ke staršímu systému a rychle obnovil svou funkci bez dopadu na uživatele a funkce podporované dříve.

Abychom to mohli ověřit, je třeba navrhnout scénáře testu selhání migrace jako součást negativního testování a je třeba otestovat mechanismus vrácení zpět. Ve výsledcích testu je také třeba zaznamenat a zaznamenat celkovou dobu potřebnou k obnovení zpět do původního systému.

Po vrácení zpět hlavní funkce a regresní testování (automatizované) by mělo být spuštěno, aby se zajistilo, že migrace nic neovlivnila a vrácení zpět je úspěšné při obnovení původního systému na místě.

Souhrnná zpráva o testu migrace

Souhrnná zpráva o testu by měly být vytvořeny po dokončení testování a měly by zahrnovat zprávu o souhrnu různých testů / scénářů provedených jako součást různých fází migrace se stavem výsledku (vyhovět / nevyhovět) a protokoly testů.

Čas zaznamenaný pro následující činnosti by měl být jasně uveden:

  1. Celková doba migrace
  2. Odstávky aplikací
  3. Čas strávený migrací 10 000 záznamů.
  4. Čas strávený odvoláním.

Kromě výše uvedených informací lze uvést také veškerá pozorování / doporučení.

Výzvy v testování migrace dat

Výzvy, kterým toto testování čelí, spočívají hlavně v datech. Níže je několik v seznamu:

# 1) Kvalita dat:

Můžeme zjistit, že data použitá ve starší aplikaci mají špatnou kvalitu v nové / upgradované aplikaci. V takových případech je třeba zlepšit kvalitu dat, aby byly splněny obchodní standardy.

Faktory jako předpoklady, převody dat po migraci, data zadaná v samotné starší aplikaci jsou neplatná, špatná analýza dat atd. Vede ke špatné kvalitě dat. Výsledkem jsou vysoké provozní náklady, zvýšená rizika integrace dat a odchylka od účelu podnikání.

# 2) Neshoda dat:

Data migrovaná ze starší verze do nové / upgradované aplikace se v nové mohou shledat jako neshodující se. To může být způsobeno změnou datového typu, formátu úložiště dat, může být předefinován účel, pro který jsou data používána.

To vedlo k obrovskému úsilí upravit nezbytné změny, aby se buď neodpovídající data opravila, nebo je přijala a doladila k tomuto účelu.

# 3) Ztráta dat:

Při migraci ze starší verze do nové / upgradované aplikace může dojít ke ztrátě dat. Může to být u povinných nebo nepovinných polí. Pokud jsou ztracená data pro nepovinná pole, pak bude jejich záznam stále platný a lze je znovu aktualizovat.

Pokud se ale údaje povinného pole ztratí, pak se samotný záznam stane neplatným a nebude možné jej stáhnout. To bude mít za následek obrovskou ztrátu dat a mělo by být nutné je načíst buď ze záložní databáze, nebo z protokolů auditu, pokud jsou správně zachyceny.

# 4) Objem dat:

která společnost je v současné době lídrem v cloudových webhostingových službách?

Obrovská data, která k migraci v rámci prostoje migrační aktivity vyžadují hodně času. Např: Stírací losy v telekomunikačním průmyslu, uživatelé na inteligentní síťové platformě atd., Zde je časem výzva, starší data jsou vymazána, budou vytvořena obrovská nová data, která je třeba znovu migrovat. Automatizace je řešením obrovské migrace dat.

# 5) Simulace prostředí v reálném čase (se skutečnými daty):

Simulace prostředí v reálném čase ve zkušební laboratoři je další skutečnou výzvou, kdy se testeři dostávají do různých druhů problémů se skutečnými daty a reálným systémem, kterým během testování nečelí.

Při provádění testování migrace dat je tedy vzorkování dat, replikace skutečného prostředí, identifikace objemu dat zapojených do migrace velmi důležité.

# 6) Simulace objemu dat:

Týmy musí studovat data v živém systému velmi pečlivě a měly by přijít s typickou analýzou a vzorkováním dat.

Např: uživatelé s věkovou skupinou do 10 let, 10–30 let atd., Pokud je to možné, je třeba získávat data ze živého přenosu, pokud ne, je třeba data vytvářet v testovacím prostředí. K vytvoření velkého objemu dat je třeba použít automatizované nástroje. Pokud nelze svazek simulovat, lze použít extrapolaci, kdekoli je to možné.

Tipy k vyrovnání rizik migrace dat

Níže je uvedeno několik tipů, které je třeba provést, aby se vyhladila rizika migrace dat:

  • Standardizujte data použitá ve starém systému, takže při migraci budou standardní data k dispozici v novém systému
  • Vylepšete kvalitu dat tak, aby při migraci existovala kvalitativní data k otestování, která poskytne pocit testování jako koncový uživatel
  • Před migrací vyčistěte data, aby při migraci nebyla v novém systému přítomna duplicitní data, a také to udrží celý systém čistý
  • Znovu zkontrolujte omezení, uložené procedury, složité dotazy, které přinášejí přesné výsledky, takže při migraci budou v novém systému také vrácena správná data
  • Identifikujte správný automatizační nástroj pro provádění kontrol dat / záznamů v novém systému ve srovnání se staršími.

Závěr

S ohledem na složitost provádění testování migrace dat, přičemž je třeba mít na paměti, že malá chyba v jakémkoli aspektu ověření během testování povede k riziku selhání migrace ve výrobě, je proto velmi důležité provést pečlivou a důkladnou studii & analýza systému před a po migraci. Naplánujte a navrhněte efektivní strategii migrace pomocí robustních nástrojů spolu se zkušenými a vyškolenými testery.

Jak víme, že migrace má obrovský dopad na kvalitu aplikace, musí celý tým vynaložit značné úsilí k ověření celého systému ve všech aspektech, jako je funkčnost, výkon, zabezpečení, použitelnost, dostupnost, spolehlivost, kompatibilita atd., což zase zajistí úspěšné „testování migrace“.

„Různé typy migrací“ které se ve skutečnosti obvykle stávají poměrně často a způsoby, jak zvládnout jejich testování, budou stručně vysvětleny v našem další tutoriál v této sérii .

O autorech: Tuto příručku napsal autor STH Nandini. Má více než 7 let zkušeností s testováním softwaru. Také děkuji autorce STH Gayathri S. za přezkoumání a poskytnutí jejích valubale návrhů na vylepšení této série. Gayathri má více než 18 let zkušeností v oblasti vývoje a testování softwaru.

Sdělte nám své komentáře / návrhy týkající se tohoto tutoriálu.

Doporučené čtení

^