Мени

Водич за тестирање миграције података: Комплетан водич

data migration testing tutorial

Испробајте Наш Инструмент За Елиминисање Проблема

Преглед тестирања миграције података:

Често се чује да се апликација премешта на други сервер, мења технологија, ажурира на следећу верзију или премешта на други сервер базе података итд.,

  • Шта ово заправо значи?
  • Шта се очекује од тима за тестирање у овим ситуацијама?

Са становишта тестирања, све то значи да апликација мора бити темељно тестирана од краја до краја, заједно са успешном миграцијом са постојећег на нови систем.

Водичи у овој серији:

Тестирање система у овом случају мора бити извршено са свим подацима који се користе у старој апликацији, као и новим подацима. Постојећу функционалност треба верификовати заједно са новом / измењеном функционалношћу.

Тестирање миграције података

Уместо само тестирања миграције, оно се може назвати и тестирањем миграције података, где ће целокупни подаци корисника бити премештени у нови систем.

Дакле, тестирање миграције укључује тестирање са старим подацима, новим подацима или комбинацијом обе, старе функције (непромењене карактеристике) и нове карактеристике.

Стара апликација се обично назива „ наслеђе ' апликација. Заједно са новом / надограђеном апликацијом, такође је обавезно држати тестирање старе верзије док нове / надограђене не постану стабилне и доследне. Опсежни тест миграције нове апликације откриће нове проблеме који нису пронађени у застарелој апликацији.

Шта ћете научити:

Шта је тестирање миграције?

Тестирање миграције је поступак верификације миграције старог система на нови систем са минималним прекидима / прекидима рада, са интегритетом података и без губитка података, истовремено осигуравајући да су сви наведени функционални и нефункционални аспекти апликације испуњени након миграција.

Једноставно представљање система миграције:

Испитивање миграције

Зашто тест миграције?

Као што знамо, миграција апликације на нови систем може бити из различитих разлога, консолидације система, застареле технологије, оптимизације или било којих других разлога.

Стога, иако систем у употреби треба пребацити на нови систем, неопходно је осигурати следеће тачке:

  1. Свака врста сметњи / непријатности која је узрокована кориснику услед миграције треба избегавати / минимизирати. Нпр: застоји, губитак података
  2. Потребно је осигурати да ли корисник може наставити да користи све функције софтвера наносећи минималну или никакву штету током миграције. Нпр: промена функционалности, уклањање одређене функције
  3. Такође је важно предвидети и искључити све могуће грешке / сметње које би се могле појавити током стварне миграције живог система.

Стога је, како би се осигурала несметана миграција живог система уклањањем тих недостатака, од пресудног значаја да се изврши тестирање миграције у лабораторији.

Ово тестирање има свој значај и игра виталну улогу када подаци дођу у слику.

Технички, такође се захтева да се изврши у следеће сврхе:

  • Да би се осигурала компатибилност нове / надограђене апликације са свим могућим хардвером и софтвером који стара верзија подржава. Такође, ново компатибилност треба тестирати на нови хардвер, софтверску платформу такође.
  • Да би се осигурало да све постојеће функционалности функционишу као у застарелој апликацији. Не би требало да дође до промене начина рада апликације у односу на стару.
  • Могућност великог броја дефеката услед миграције је врло велика. Многи недостаци ће се обично односити на податке и стога их треба открити и отклонити током тестирања.
  • Да би се осигурало да ли је време одзива система нове / надограђене апликације једнако или мање од оног потребно за застарелу апликацију.
  • Да би се осигурало да ли су везе између сервера, хардвера, софтвера итд. Нетакнуте и не прекидају се током тестирања. Проток података између различитих компоненти не сме се прекидати ни под којим условима.

Када је потребно ово тестирање?

Тестирање се мора извршити и пре и после миграције.

Различите фазе теста миграције који ће се изводити у испитној лабораторији могу се класификовати као доле.

  1. Испитивање пре миграције
  2. Испитивање миграције
  3. Тестирање након миграције

Поред наведеног, следећи тестови се такође изводе као део целокупне миграционе активности.

  1. Провера компатибилности уназад
  2. Тестирање враћања

Пре извођења овог тестирања, неопходно је да било који испитивач јасно разуме следеће тачке:

  1. Промене које се дешавају као део новог система (сервер, фронт енд, ДБ, шема, проток података, функционалност итд.,)
  2. Да бисте разумели стварну стратегију миграције коју је тим поставио. Како се миграција догађа, корак по корак промене се дешавају у позадини система и скриптама одговорним за ове промене.

Због тога је неопходно темељито проучити стари и нови систем, а затим сходно томе планирати и дизајнирати случајеве испитивања и сценарије испитивања који ће бити обухваћени као део горњих фаза тестирања и припремити стратегију испитивања.

Стратегија испитивања миграције података

Дизајнирање тест стратегије за миграцију укључује низ активности које треба обавити и неколико аспеката које треба размотрити. Ово је ради минимизирања грешака и ризика који настају као резултат миграције и ефикасног обављања миграционог тестирања.

Активности у овом тестирању:

# 1) Формирање специјализованог тима :

Формирајте испитни тим са члановима који имају потребно знање и искуство и обезбедите обуку у вези са системом који се мигрира.

#два) Анализа пословног ризика, анализа могућих грешака :

Текуће пословање не би требало да буде ометено након миграције, па стога обављати „ Анализа пословног ризика састанци који укључују праве заинтересоване стране (менаџер теста, пословни аналитичар, архитекте, власници производа, власник предузећа итд.) и идентификују ризике и применљиве мере ублажавања. Тестирање би требало да обухвати сценарије за откривање тих ризика и проверу да ли су спроведене одговарајуће мере ублажавања.

Спровести ' Анализа могућих грешака ’ користећи одговарајуће „Приступ погађању грешака“ а затим дизајнирајте тестове око ових грешака како бисте их открили током тестирања.

уџбеник повезане листе ц ++

# 3) Анализа и идентификација обима миграције:

Анализирајте јасан опсег теста миграције као када и шта треба тестирати.

# 4) Идентификујте одговарајући алат за миграцију:

Док дефинишете стратегију овог тестирања, аутоматизованог или ручног, идентификујте алате који ће се користити. На пример: Аутоматски алат за упоређивање података о извору и одредишту.

# 5) Утврдите одговарајуће тест окружење за миграцију:

Утврдите одвојена окружења за окружења пре и после миграције да бисте извршили било какву верификацију која је потребна у оквиру тестирања. Разумети и документовати техничке аспекте Легаци и Нев систем оф Мигратион, како би се осигурало да је тест окружење постављено у складу с тим.

# 6) Документ о спецификацији теста миграције и преглед:

Припремите документ са спецификацијама за миграциони тест који јасно описује приступ тестирању, подручја испитивања, методе испитивања (аутоматизовано, ручно), методологију испитивања (црна кутија, техника испитивања беле кутије ), Број циклуса тестирања, распоред тестирања, приступ стварању података и коришћење података уживо (осетљиве информације треба маскирати), спецификација окружења за тестирање, квалификација тестера итд., И покрените сесију прегледа са заинтересованим странама.

# 7) Покретање производње мигрираног система :

Анализирајте и документујте списак обавеза за миграцију производње и објавите га унапред

Различите фазе миграције

У наставку су дате различите фазе миграције.

Фаза 1:Испитивање пре миграције

Пре миграције података, скуп активности тестирања се изводи као део фазе теста пре миграције. Ово се занемарује или се не узима у обзир у једноставнијим апликацијама. Али када треба пребацити сложене апликације, активности пред миграцијом су неопходне.

Испод је листа акција предузетих током ове фазе:

  • Поставите јасан опсег података - који подаци морају бити укључени, који подаци морају бити изузети, који подаци требају трансформацију / конверзију итд.
  • Извршите мапирање података између старе и нове апликације - за сваку врсту података у застарелој апликацији упоредите њен релевантан тип у новој апликацији, а затим их мапирајте - Мапирање на вишем нивоу.
  • Ако нова апликација има поље које је обавезно у себи, али то није случај у старом формату, а затим осигурајте да легаци нема то поље као нулл. - Мапирање нижег нивоа.
  • Јасно проучите шему података нове апликације - називи поља, типови, минималне и максималне вредности, дужина, обавезна поља, провере нивоа поља итд., Јасно
  • Треба забележити одређени број табела у старом систему, а ако неке табеле изостану и додају се након миграције, то треба верификовати.
  • Одређени број записа у свакој табели, прегледи треба забележити у застарелој апликацији.
  • Проучите интерфејсе у новој апликацији и њихове везе. Подаци који пролазе кроз интерфејс требају бити високо заштићени и не смеју се кварити.
  • Припремите тест случајеве, сценарије тестирања и случајеве употребе за нове услове у новим апликацијама.
  • Извршите скуп тест случајева, сценарија са скупом корисника и задржите резултате, евиденције. Исто треба верификовати након миграције како би се осигурало да су стари подаци и функционалност нетакнути.
  • Бројање података и записа треба јасно забележити, треба га верификовати након миграције како не би дошло до губитка података.

Фаза 2:Испитивање миграције

' Водич за миграцију ’који је које је припремио тим за миграције, мора се строго поштовати да би се извршиле миграционе активности. У идеалном случају, активност миграције започиње резервним копирањем података на траци, тако да се у сваком тренутку може обновити стари систем.

Верификација документационог дела „ Водич за миграцију ’такође је део тестирања миграције података . Проверите да ли је документ јасан и да ли га је лако пратити. Све скрипте и кораци морају бити исправно документовани без икаквих нејасноћа. Било какве грешке у документацији, промашаји по редоследу извршавања корака такође се морају сматрати важним како би се могли пријавити и поправити.

Скрипте за миграцију, водич и друге информације повезане са стварном миграцијом потребно је преузети из спремишта за контролу верзија за извршење.

Записивање стварног времена потребно за миграцију од тачке почетка миграције до успешне обнове система, један је од тест случајева који треба извршити, а тиме и „Време потребно за миграцију система“ потребно је забележити у завршном извештају о испитивању који ће бити достављен као део резултата теста миграције и ове информације ће бити корисне током покретања производње. Застој забележен у тестном окружењу екстраполира се за израчунавање приближног застоја у живом систему.

На наследном систему ће се обављати активност миграције.

Током овог тестирања, све компоненте животне средине обично ће бити срушене и уклоњене са мреже да би се извршиле активности миграције. Отуда је неопходно напоменути ‘Застој’ потребно за тест миграције. У идеалном случају, то ће бити исто као у време миграције.

Генерално, миграциона активност дефинисана у документу „Водич за миграцију“ укључује:

  • Стварна миграција апликације
  • Конфигурације заштитног зида, порта, хостова, хардвера и софтвера су измењени у складу са новим системом на који се преноси наследство
  • Изводи се цурење података, безбедносне провере
  • Проверава се повезаност свих компонената апликације

Пожељно је да тестери верификују горе наведено у позадини система или тако што ће извршити тестирање у белој кутији.

Када се заврши активност миграције наведена у водичу, сви сервери се покрећу и извршавају се основни тестови у вези са верификацијом успешне миграције, што осигурава да су сви крајњи и крајњи системи одговарајуће повезани и да све компоненте разговарају са сваким друго, ДБ је покренут и покренут, предњи крај успешно комуницира са задњим крајем. Ови тестови морају бити идентификовани раније и забележени у документу Спецификација теста миграције.

Постоје могућности да софтвер подржава више различитих платформи. У том случају, миграцију треба верификовати на свакој од ових платформи посебно.

Верификација скрипти за миграцију биће део теста миграције. Понекад се појединачна скрипта за миграцију такође верификује помоћу „тестирања беле кутије“ у самосталном окружењу за тестирање.

Стога ће тестирање миграције бити комбинација и „тестирања беле кутије и црне кутије“.

Када се заврши ова верификација у вези са миграцијом и прођу одговарајући тестови, тим може да настави са активностима тестирања након миграције.

Фаза # 3:Испитивање након миграције

Када се апликација успешно мигрира, на сцену ступа тестирање након миграције.

Овде се врши тестирање система од краја до краја у окружењу за тестирање. Тестери извршавају идентификоване тест случајеве, сценарије тестирања, случајеве употребе са застарелим подацима, као и нови скуп података.

Поред ових, постоје одређене ставке које треба верификовати у мигрираном окружењу, а које су наведене у наставку:

Све ово је документовано као тест случај и укључено у документ „Спецификација теста“.

  1. Проверите да ли су сви подаци из старе верзије премештени у нову апликацију у планираном застоју. Да бисте то осигурали, упоредите број записа између старе и нове апликације за сваку табелу и погледе у бази података. Такође, пријавите време потребно за премештање рецимо 10000 записа.
  2. Проверите да ли су ажуриране све промене шеме (додата или уклоњена поља и табеле) према новом систему.
  3. Подаци мигрирани из старе верзије у нову апликацију требало би да задрже вредност и формат, осим ако то није одређено. Да бисте то осигурали, упоредите вредности података између старе и нове базе података апликације.
  4. Тестирајте мигриране податке у односу на нову апликацију. Овде је обухваћен максималан број могућих случајева. Да бисте осигурали 100% покривеност у вези са верификацијом миграције података, користите алатку за аутоматско тестирање.
  5. Проверите сигурност базе података.
  6. Проверите интегритет података за све могуће записе узорака.
  7. Проверите и осигурајте да раније подржане функције у старом систему раде како се очекивало у новом систему.
  8. Проверите проток података у апликацији која покрива већину компонената.
  9. Интерфејс између компонената треба детаљно тестирати, јер се подаци не смеју мењати, губити и оштећивати када пролазе кроз компоненте. Случајеви интеграционих тестова могу се користити за потврду овога.
  10. Проверите да ли су застарели подаци сувишни. Ниједан застарели податак не би требало да се дуплира током миграције
  11. Проверите да ли постоје случајеви неусклађености података као што су промењени тип података, промењен формат складиштења итд.,
  12. Све провере нивоа поља у застарелој апликацији такође треба да буду обухваћене новом апликацијом
  13. Било који додатак података у новој апликацији не би требало да се одражава на наслеђе
  14. Треба подржати ажурирање података застареле апликације путем нове апликације. Једном ажуриран у новој апликацији, не би требало да се одражава на наслеђе.
  15. Треба да буде подржано брисање података застареле апликације у новој апликацији. Једном обрисана у новој апликацији, она такође не би требало да брише податке из старе верзије.
  16. Уверите се да промене извршене у старом систему подржавају нову функционалност испоручену као део новог система.
  17. Проверите да ли корисници из старог система могу да наставе да користе и стару и нову функционалност, посебно оне у које су укључене промене. Извршите тест случајеве и резултате испитивања ускладиштене током тестирања пред миграцијом.
  18. Створите нове кориснике у систему и извршите тестове како бисте били сигурни да функционалност наслеђене верзије, као и нова апликација, подржава новостворене кориснике и ради добро.
  19. Спровести тестове повезане са функционалношћу са различитим узорцима података (различите старосне групе, корисници из другог региона итд.,)
  20. Такође је потребно проверити да ли су за нове функције омогућене „Ознаке карактеристика“, а њихово укључивање / искључивање омогућава укључивање и искључивање функција.
  21. Тестирање перформанси је важно како би се осигурало да прелазак на нови систем / софтвер није погоршао перформансе система.
  22. Такође је потребно извршити тестове оптерећења и оптерећења како би се осигурала стабилност система.
  23. Уверите се да надоградња софтвера није отворила ниједну безбедносну рањивост и зато извршите безбедносно тестирање, посебно у области у којој су у систему извршене промене током миграције.
  24. Употребљивост је још један аспект који треба проверити, при чему је једноставност коришћења који крајњи корисник осећа у поређењу са застарелим системом ако се промени ГУИ распоред / фронт-енд систем или се променила било која функционалност.

Будући да обим тестирања након миграције постаје веома велик, идеално је раздвојити важне тестове које је потребно прво обавити да би се утврдило да ли је миграција успешна, а затим спровести преостале.

Такође је препоручљиво аутоматизовати функционалне тестове са краја на крај и друге могуће случајеве испитивања, тако да се време тестирања може смањити и резултати ће бити брзо доступни.

Неколико савета за тестере за писање тест случајева за извршење након миграције:

б дрво и б + дрво
  • Када се апликација мигрира, то не значи да се тест примери морају написати за целу нову апликацију. Тест случајеви који су већ дизајнирани за старе верзије и даље би требало да буду добри за нову апликацију. Дакле, што је више могуће користите старе случајеве тестова и конвертујте старе примере примера у случајеве нове апликације где год је то потребно.
  • Ако се у новој апликацији промени нека карактеристика, тада треба изменити тест случајеве повезане са том функцијом.
  • Ако је у нову апликацију додата било која нова функција, тада би за ту посебност требало да буду дизајнирани нови тест случајеви.
  • Када дође до пада карактеристика у новој апликацији, тестови сродних застарелих апликација не би требало да се узимају у обзир за извршавање након миграције и требало би да буду означени као неважећи и одвојени.
  • Дизајнирани тестови увек треба да буду поуздани и доследни у погледу употребе. Верификација критичних података треба да буде обухваћена тестним случајевима како се не би пропустили током извршавања.
  • Када се дизајн нове апликације разликује од застарелог (УИ), тада би тестови у вези са корисничким интерфејсом требали бити модификовани како би се прилагодио нови дизајн. Одлуку да ажурира или напише нове, у овом случају, тестер може да донесе на основу обима промене.

Испитивање уназад компатибилности

Миграција система такође захтева од тестера да верификују „уназад компатибилност“, при чему је нови систем компатибилан са старим системом (најмање 2 претходне верзије) и осигурава да савршено функционише са тим верзијама.

Повратна компатибилност је осигурати:

  1. Да ли нови систем подржава функцију подржану у раније 2 верзије заједно са новом.
  2. Систем се може успешно пребацити из претходне 2 верзије без икаквих мука.

Стога је неопходно осигурати повратну компатибилност система посебно извођењем тестова повезаних са подршком за повратну компатибилност. Тестови везани за компатибилност са уназад треба да буду дизајнирани и укључени у документ о спецификацији теста за извршење.

Тестирање враћања

У случају било каквих проблема током извођења миграције или ако дође до неуспеха миграције у било ком тренутку током миграције, требало би да буде могуће да се систем врати на застарели систем и брзо настави са радом без утицаја на кориснике и функционалност подржана раније.

Дакле, да би се ово верификовало, сценарији теста неуспеха миграције треба да буду дизајнирани као део негативног тестирања и да се тестирају механизми враћања. Укупно време потребно за повратак на застарели систем такође треба забележити и пријавити у резултатима теста.

Након повратка, главна функционалност и регресијско испитивање (аутоматизовано) треба покренути како би се осигурало да миграција није утицала ни на шта и да је повраћај успешан у враћању старог система.

Резиме извештаја о тестирању миграције

Резиме теста треба да се изради након завршетка тестирања и треба да покрива извештај о резимеу различитих тестова / сценарија изведених у оквиру различитих фаза миграције са статусом резултата (пролазак / неуспех) и записницима теста.

Треба јасно навести време забележено за следеће активности:

  1. Укупно време за миграцију
  2. Прекид рада апликација
  3. Време проведено за миграцију 10000 записа.
  4. Време проведено за враћање.

Поред горе наведених информација, могу се извести и сва запажања / препоруке.

Изазови у тестирању миграције података

Изазови са којима се суочава ово тестирање углавном су подаци. Испод је неколико на листи:

# 1) Квалитет података:

Можда ћемо открити да су подаци коришћени у застарелој апликацији лошег квалитета у новој / надограђеној апликацији. У таквим случајевима се мора побољшати квалитет података како би се задовољили пословни стандарди.

Фактори попут претпоставки, претворбе података након миграција, података унетих у саму застарелу апликацију су неваљани, лоша анализа података итд. Доводи до лошег квалитета података. То резултира високим оперативним трошковима, повећаним ризицима интеграције података и одступањем од сврхе пословања.

# 2) Неподударање података:

Подаци који су мигрирани из старе верзије у нову / надограђену апликацију могу се наћи у новој у неусклађености. То је можда због промене типа података, формата складиштења података, сврха у коју се подаци користе може бити редефинисана.

То резултира огромним напорима да се измене потребне промене како би се исправили неусклађени подаци или прихватили и прилагодили у ту сврху.

# 3) Губитак података:

Подаци се могу изгубити приликом преласка из старе верзије у нову / надограђену апликацију. Ово може бити са обавезним пољима или необавезним пољима. Ако су изгубљени подаци за необавезна поља, тада ће запис за њих и даље бити важећи и може се поново ажурирати.

Али ако се подаци обавезног поља изгубе, запис сам по себи постаје неважећи и не може се повући. То ће резултирати великим губитком података и треба их преузети из резервне базе података или евиденције ревизије ако су правилно снимљени.

# 4) Обим података:

Огромни подаци којима је потребно много времена за миграцију у оквиру периода застоја активности миграције. На пример: Греб картице у индустрији телекомуникација, корисници на интелигентној мрежној платформи итд., Овде је изазов временом, обрисани су стари подаци, створиће се огромни нови подаци које треба поново мигрирати. Аутоматизација је решење за огромну миграцију података.

# 5) Симулација окружења у стварном времену (са стварним подацима):

Симулација окружења у реалном времену у лабораторији за тестирање је још један прави изазов, где тестери улазе у различите проблеме са стварним подацима и стварним системом, са којим се суочава током тестирања.

Дакле, узорковање података, репликација стварног окружења, идентификација обима података који су укључени у миграцију је прилично важно током извођења тестирања миграције података.

# 6) Симулација обима података:

Тимови морају врло пажљиво проучавати податке у живом систему и требали би доћи до типичне анализе и узорковања података.

На пример: корисници старосне групе испод 10 година, 10-30 година итд., што је више могуће, потребно је прибавити податке уживо, ако не и стварање података у окружењу за тестирање. За стварање велике количине података потребно је користити аутоматизоване алате. Екстраполација, где год је то могуће, може се користити ако јачина звука не може бити симулирана.

Савети за ублажавање ризика преноса података

Испод је дато неколико савета које треба предузети како би се ублажили ризици миграције података:

  • Стандардизујте податке који се користе у старом систему, тако да ће приликом миграције стандардни подаци бити доступни у новом систему
  • Побољшајте квалитет података, тако да приликом миграције постоје квалитативни подаци за тестирање који дају осећај тестирања као крајњег корисника
  • Очистите податке пре миграције, тако да приликом миграције дуплицирани подаци неће бити присутни у новом систему, а такође ово одржава читав систем чистим
  • Поново проверите ограничења, ускладиштене процедуре, сложене упите који дају тачне резултате, тако да се приликом миграције тачни подаци враћају и у нови систем
  • Утврдите исправан алат за аутоматизацију за вршење провера података / евиденција у новом систему у поређењу са наследством.

Закључак

Стога, узимајући у обзир сложеност спровођења тестирања миграције података, имајући на уму да ће мали пропуст у било ком аспекту верификације током тестирања довести до ризика од неуспеха миграције у производњи, веома је важно спровести пажљиво и темељно проучавање & анализа система пре и после миграције. Планирајте и осмислите ефикасну стратегију миграције помоћу робусних алата заједно са вештим и обученим тестерима.

Као што знамо да миграција има огроман утицај на квалитет апликације, читав тим мора уложити доста труда да верификује читав систем у свим аспектима попут функционалности, перформанси, сигурности, употребљивости, доступности, поузданости, компатибилности итд., што ће заузврат обезбедити успешно „тестирање миграције“.

„Различите врсте миграција“ то се обично догађа прилично често у стварности, а начини руковања њиховим тестирањем биће укратко објашњени у нашем тексту следећи водич из ове серије .

О ауторима: Овај водич написао је аутор СТХ Нандини. Има 7+ година искуства у тестирању софтвера. Такође, хвала ауторици СТХ Гаиатхри С. на прегледу и давању њених вредних предлога за побољшање ове серије. Гаиатхри има више од 18 година искуства у развоју софтвера и услугама тестирања.

Обавестите нас о својим коментарима / сугестијама у вези са овим упутством.

Препоручено читање

^