Меню

Урок за тестване на миграцията на данни: Пълно ръководство

data migration testing tutorial

Опитайте Нашия Инструмент За Премахване На Проблемите

Преглед на тестването на миграция на данни:

Доста често се чува, че дадено приложение се премества на различен сървър, технологията се променя, актуализира се до следващата версия или се премества на различен сървър на база данни и т.н.,

  • Какво всъщност означава това?
  • Какво се очаква от екипа за тестване в тези ситуации?

От гледна точка на тестването, всичко означава, че приложението трябва да бъде тествано щателно от край до край заедно с миграцията от съществуващата система към новата система успешно.

Уроци от тази поредица:

В този случай трябва да се извърши системно тестване с всички данни, които се използват в старо приложение и новите данни. Съществуващата функционалност трябва да бъде проверена заедно с новата / модифицираната функционалност.

Тестване на миграцията на данни

Вместо просто тестване на миграцията, то може да се нарече и тестване на миграцията на данни, при което всички данни на потребителя ще бъдат мигрирани към нова система.

И така, тестовете за миграция включват тестване със стари данни, нови данни или комбинация от двете, стари функции (непроменени функции) и нови функции.

Старото приложение обикновено се нарича „ наследство ' приложение. Заедно с новото / надстроеното приложение също е задължително да продължавате да тествате наследено приложение, докато новите / надстроените станат стабилни и последователни. Обширен тест за миграция на ново приложение ще разкрие новите проблеми, които не са намерени в старото приложение.

Какво ще научите:

Какво е тестване на миграцията?

Тестът за миграция е процес на проверка на миграцията на наследената система към новата система с минимално прекъсване / престой, с целостта на данните и без загуба на данни, като същевременно гарантира, че всички посочени функционални и нефункционални аспекти на приложението са изпълнени след миграция.

Просто представяне на миграционната система:

Тестване на миграцията

Защо тест за миграция?

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

Следователно, докато използваната система трябва да бъде мигрирана към нова система, от съществено значение е да се осигурят следните точки:

  1. Всякакъв вид смущения / неудобства, причинени на потребителя поради миграция, трябва да се избягват / свеждат до минимум. Например: престой, загуба на данни
  2. Трябва да се уверите дали потребителят може да продължи да използва всички функции на софтуера, като причинява минимални или никакви щети по време на миграцията. Например: промяна във функционалността, премахване на определена функционалност
  3. Също така е важно да се предвидят и изключат всички възможни проблеми / пречки, които биха могли да възникнат по време на действителната миграция на активната система.

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

Това тестване има собствено значение и играе жизненоважна роля, когато данните влязат в картината.

Технически се изисква също да бъде изпълнено за следните цели:

  • За да се осигури съвместимост на новото / надстроеното приложение с целия възможен хардуер и софтуер, които наследственото приложение поддържа. Също така, ново съвместимост трябва да се тества за нов хардуер, софтуерна платформа също.
  • За да се гарантира, че всички съществуващи функционалности работят както в старото приложение. Не трябва да има промяна в начина, по който работи приложението в сравнение със старото.
  • Възможността за голям брой дефекти поради миграция е много голяма. Много от дефектите обикновено са свързани с данни и следователно тези дефекти трябва да бъдат идентифицирани и отстранени по време на тестването.
  • За да се уверите дали времето за реакция на системата на новото / надстроеното приложение е същото или по-малко от това, което е необходимо на старото приложение.
  • За да се гарантира дали връзката между сървъри, хардуер, софтуер и т.н., е непокътната и не се прекъсва по време на тестване. Потокът от данни между различните компоненти не трябва да се нарушава при никакви условия.

Кога се изисква това тестване?

Тестването трябва да се извърши както преди, така и след миграция.

Различните фази на теста за миграция , които ще се извършват в тестовата лаборатория, могат да бъдат класифицирани по-долу.

  1. Тестване преди миграцията
  2. Тестване на миграцията
  3. Тестване след миграция

В допълнение към горното, изпълняват се и следните тестове като част от цялата миграционна дейност.

  1. Проверка на обратната съвместимост
  2. Тестване на откат

Преди да извършите това тестване, е важно всеки тестер да разбере ясно следните точки:

  1. Промените, случващи се като част от новата система (сървър, преден край, DB, схема, поток от данни, функционалност и т.н.,)
  2. За да разберете действителната стратегия за миграция, изложена от екипа. Как се извършва миграцията, стъпка по стъпка промени, които се случват в бекенда на системата и скриптовете, отговорни за тези промени.

Следователно е от съществено значение да се направи задълбочено проучване на старата и новата система и след това съответно да се планират и проектират тестовите случаи и тестовите сценарии, които да бъдат обхванати като част от горните фази на тестване и да се подготви стратегията за тестване.

Стратегия за тестване на миграцията на данни

Проектирането на тестовата стратегия за миграция включва набор от дейности, които трябва да бъдат извършени, и няколко аспекта, които трябва да бъдат взети предвид. Това е с цел минимизиране на грешките и рисковете, които възникват в резултат на миграция, и за ефективно извършване на теста за миграция.

Дейности в това тестване:

# 1) Формиране на специализиран екип :

Сформирайте екипа за тестване с членовете, притежаващи необходимите знания и опит и осигурете обучение, свързано със системата, която се мигрира.

# две) Анализ на бизнес риска, анализ на възможни грешки :

Настоящият бизнес не трябва да бъде възпрепятстван след миграция и следователно да се извършва „ Анализ на бизнес риска срещи с участието на подходящите заинтересовани страни (мениджър на тестове, бизнес анализатор, архитекти, собственици на продукти, собственик на бизнес и др.) и идентифициране на рисковете и изпълнимите мерки. Тестването трябва да включва сценарии за разкриване на тези рискове и проверка дали са приложени подходящи смекчаващи мерки.

Поведение, ръководене ' Анализ на възможни грешки ’ използвайки подходящо „Подходи за отгатване на грешки“ и след това проектирайте тестове около тези грешки, за да ги откриете по време на тестване.

как да отворите .torrent

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

Анализирайте ясния обхват на теста за миграция като кога и какво трябва да бъде тествано.

# 4) Определете подходящия инструмент за миграция:

Докато определяте стратегията на това тестване, автоматизирано или ръчно, идентифицирайте инструментите, които ще бъдат използвани. E.g: Автоматизиран инструмент за сравняване на данни за източника и местоназначението.

# 5) Определете подходящата тестова среда за миграция:

Идентифицирайте отделни среди за среди преди и след миграция, за да извършите всяка проверка, която се изисква като част от тестването. Разберете и документирайте техническите аспекти на Legacy and New system of Migration, за да сте сигурни, че тестовата среда е настроена според това.

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

Подгответе документ за спецификация на теста за миграция, който ясно описва тестовия подход, областите на тестване, методите за тестване (автоматизирани, ръчни), методологията за тестване (черна кутия, техника за тестване на бяла кутия ), Брой цикли на тестване, график на тестване, подход за създаване на данни и използване на данни на живо (чувствителната информация трябва да бъде маскирана), спецификация на тестовата среда, квалификация на тестери и т.н., и проведете сесия за преглед със заинтересованите страни.

# 7) Стартиране на производството на мигриралата система :

Анализирайте и документирайте списъка със задачи за миграция на продукцията и го публикувайте доста предварително

Различни фази на миграция

По-долу са дадени различните фази на миграцията.

Фаза # 1:Тестване преди миграция

Преди мигриране на данните се извършват набор от тестови дейности като част от фазата на теста преди миграцията. Това се пренебрегва или не се разглежда в по-прости приложения. Но когато трябва да се мигрират сложни приложения, дейностите преди миграцията са задължителни.

По-долу е даден списък на действията, предприети по време на тази фаза:

  • Задайте ясен обхват на данните - какви данни трябва да бъдат включени, какви данни трябва да бъдат изключени, кои данни се нуждаят от трансформация / преобразуване и т.н.
  • Извършете картографиране на данни между наследено и ново приложение - за всеки тип данни в наследеното приложение сравнете съответния му тип в новото приложение и след това ги картографирайте - Картографиране на по-високо ниво.
  • Ако новото приложение има полето, което е задължително в него, но това не е така в наследството, и след това се уверете, че наследството няма това поле като null. - Картографиране от по-ниско ниво.
  • Проучете ясно схемата за данни на новото приложение - имена на полета, типове, минимални и максимални стойности, дължина, задължителни полета, проверки на ниво поле и т.н., ясно
  • Редица таблици в наследената система трябва да бъдат записани и ако някоя таблица бъде отпаднала и добавена след миграция, трябва да бъде проверена.
  • Редица записи във всяка таблица, изгледи трябва да бъдат отбелязани в наследеното приложение.
  • Проучете интерфейсите в новото приложение и техните връзки. Данните, които текат в интерфейса, трябва да бъдат силно защитени и да не се нарушават.
  • Подгответе тестови случаи, тестови сценарии и случаи на употреба за нови условия в новите приложения.
  • Изпълнете набор от тестови случаи, сценарии с набор от потребители и съхранявайте резултатите, регистрационните файлове. Същото трябва да бъде проверено след миграцията, за да се гарантира, че старите данни и функционалност са непокътнати.
  • Броят на данните и записите трябва да бъде отбелязан ясно, той трябва да бъде проверен след миграцията за липса на загуба на данни.

Фаза # 2:Тестване на миграцията

' Ръководство за миграция ’, което е подготвен от миграционния екип трябва стриктно да се спазва, за да се извърши миграционната дейност. В идеалния случай миграционната дейност започва с архивиране на данните на лентата, така че по всяко време старата система да може да бъде възстановена.

Проверка на документацията част на „ Ръководство за миграция “също е част от теста за миграция на данни . Проверете дали документът е ясен и лесен за следване. Всички скриптове и стъпки трябва да бъдат документирани правилно, без никакви неясноти. Всякакъв вид грешки в документацията, пропуснати съвпадения в реда на изпълнение на стъпките също трябва да се считат за важни, за да могат да бъдат докладвани и коригирани.

Скриптовете за миграция, ръководството и друга информация, свързана с действителната миграция, трябва да бъдат взети от хранилището за контрол на версиите за изпълнение.

Да се ​​отбележи действителното време, необходимо за миграция от момента на започване на миграцията до успешното възстановяване на системата, е един от тестовите случаи, които трябва да бъдат изпълнени и следователно „Време, необходимо за мигриране на системата“ трябва да бъде записано в окончателния протокол от изпитването, който ще бъде предоставен като част от резултатите от теста за миграция и тази информация ще бъде полезна по време на стартирането на производството. Времето на престой, записано в тестовата среда, се екстраполира, за да се изчисли приблизителният престой в системата под напрежение.

В старата система ще се извършва миграционната дейност.

По време на това тестване, всички компоненти на околната среда обикновено ще бъдат свалени и отстранени от мрежата, за да се извършат миграционните дейности. Следователно е необходимо да се отбележи „Престой“ необходими за тест за миграция. В идеалния случай той ще бъде същият като този от времето на миграцията.

Обикновено миграционната дейност, определена в документа „Ръководство за миграция“, включва:

  • Действителна миграция на приложението
  • Конфигурациите на защитни стени, порт, хостове, хардуер, софтуер са модифицирани според новата система, върху която се мигрира наследството
  • Изтичат данни, проверяват се сигурността
  • Проверява се връзката между всички компоненти на приложението

Препоръчително е тестерите да проверят горепосоченото в бекенда на системата или като проведат тестване на бяла кутия.

След приключване на дейността по миграция, посочена в ръководството, се извеждат всички сървъри и ще се извършват основни тестове, свързани с проверка на успешната миграция, което гарантира, че всички системи от край до край са свързани по подходящ начин и всички компоненти говорят с всеки друго, DB работи и работи, предният край комуникира успешно със задния край. Тези тестове трябва да бъдат идентифицирани по-рано и записани в документа за спецификация на теста за миграция.

Има възможности софтуерът да поддържа множество различни платформи. В такъв случай миграцията трябва да бъде проверена на всяка от тези платформи поотделно.

Проверката на скриптове за миграция ще бъде част от теста за миграция. Понякога индивидуалният скрипт за миграция също се проверява с помощта на „White box testing“ в самостоятелна среда за тестване.

Следователно тестовете за миграция ще бъдат комбинация от „тестване на бяла кутия и черна кутия“.

След като тази проверка, свързана с миграцията, бъде извършена и съответните тестове бъдат преминати, екипът може да продължи с дейността по тестване след миграция.

Фаза # 3:Тестване след миграция

След като приложението бъде мигрирано успешно, в картината се появява тестване след миграция.

Тук се извършва тестване на система от край до край в средата за тестване. Тестерите изпълняват идентифицирани тестови случаи, тестови сценарии, случаи на употреба със стари данни, както и нов набор от данни.

В допълнение към тях има конкретни елементи, които трябва да бъдат проверени в мигрираните среди, които са изброени по-долу:

Всички те са документирани като тест и са включени в документа „Спецификация на теста“.

  1. Проверете дали всички данни в наследството са мигрирани към новото приложение в рамките на планирания престой. За да се уверите в това, сравнете броя на записите между наследеното и новото приложение за всяка таблица и изгледи в базата данни. Също така отчетете времето, необходимо за преместване, да речем 10000 записа.
  2. Проверете дали всички промени в схемата (полета и таблици са добавени или премахнати) според новата система са актуализирани.
  3. Данните, мигрирани от наследеното към ново приложение, трябва да запазят своята стойност и формат, освен ако не е посочено за това. За да се уверите в това, сравнете стойностите на данните между старата и базата данни на новото приложение.
  4. Тествайте мигриралите данни спрямо новото приложение. Тук се обхваща максимален брой възможни случаи. За да осигурите 100% покритие по отношение на проверката на миграцията на данни, използвайте инструмента за автоматизирано тестване.
  5. Проверете за сигурност на базата данни.
  6. Проверете за целостта на данните за всички възможни примерни записи.
  7. Проверете и се уверете, че по-ранната поддържана функционалност в старата система работи, както се очаква в новата система.
  8. Проверете потока от данни в приложението, което обхваща повечето компоненти.
  9. Интерфейсът между компонентите трябва да бъде широко тестван, тъй като данните не трябва да се модифицират, губят и повреждат, когато преминават през компоненти. Тестовите случаи за интеграция могат да се използват за проверка на това.
  10. Проверете за излишък на стари данни. По време на миграцията не трябва да се дублират стари данни
  11. Проверете за случаи на несъответствие на данни, като например тип на данните, формат на съхранение е променен и т.н.,
  12. Всички проверки на ниво поле в наследеното приложение също трябва да бъдат обхванати в новото приложение
  13. Всяко добавяне на данни в новото приложение не трябва да отразява обратно на наследството
  14. Трябва да се поддържа актуализиране на данните на наследено приложение чрез новото приложение. След като бъде актуализирано в новото приложение, то не трябва да отразява обратно на наследството.
  15. Изтриването на данните на старото приложение в новото приложение трябва да се поддържа. Веднъж изтрито в новото приложение, то не бива да изтрива и данни в наследство.
  16. Уверете се, че промените, направени в старата система, поддържат новата функционалност, доставена като част от новата система.
  17. Уверете се, че потребителите от наследената система могат да продължат да използват както старата функционалност, така и новата функционалност, особено тези, в които се включват промените. Изпълнете тестовите случаи и резултатите от теста, съхранявани по време на теста преди миграцията.
  18. Създавайте нови потребители в системата и провеждайте тестове, за да се уверите, че функционалността от наследството, както и новото приложение, поддържа новосъздадените потребители и работи добре.
  19. Извършвайте тестове, свързани с функционалността, с разнообразни извадки от данни (различна възрастова група, потребители от различен регион и т.н.,)
  20. Необходимо е също така да се провери дали „Feature Flags“ са активирани за новите функции и включването / изключването му позволява на функциите да се включват и изключват.
  21. Тестването на производителността е важно, за да се гарантира, че миграцията към нова система / софтуер не е влошила производителността на системата.
  22. Също така се изисква да се извършат тестове за натоварване и стрес, за да се осигури стабилност на системата.
  23. Уверете се, че надстройката на софтуера не е отворила никакви уязвимости в сигурността и по този начин извършете тестове за сигурност, особено в областта, където са направени промени в системата по време на миграцията.
  24. Използваемостта е друг аспект, който трябва да бъде проверен, при което, ако оформлението на GUI / системата от предния край се промени или някаква функционалност се промени, каква е лекотата на използване, която крайният потребител изпитва в сравнение със старата система.

Тъй като обхватът на тестовете след миграция става много огромен, идеално е да се отделят важните тестове, които трябва да се направят първо, за да се установи, че миграцията е успешна, а след това да се извършат останалите по-късно.

Препоръчително е също така да се автоматизират функционалните тестови случаи от край до край и други възможни тестове, така че времето за тестване да може да бъде намалено и резултатите да са достъпни бързо.

Няколко съвета за тестери за писане на тестови случаи за изпълнение след миграция:

  • Когато приложението се мигрира, това не означава, че тестовите случаи трябва да бъдат написани за цялото ново приложение. Тестовите случаи, вече проектирани за наследството, все още трябва да са добри за новото приложение. Така че, доколкото е възможно, използвайте старите тестови случаи и конвертирайте наследените тестови случаи в случаи на ново приложение, където е необходимо.
  • Ако има някаква промяна на функцията в новото приложение, тогава тестовите случаи, свързани с функцията, трябва да бъдат променени.
  • Ако в новото приложение е добавена нова функция, тогава трябва да бъдат проектирани нови тестови случаи за тази конкретна функция.
  • Когато има спад в характеристиките в новото приложение, тестовите случаи на свързаните с наследство приложения не трябва да се разглеждат за изпълнение след миграция и те трябва да бъдат маркирани като невалидни и да се пазят отделно.
  • Проектираните тестови случаи винаги трябва да бъдат надеждни и последователни по отношение на използването. Проверката на критичните данни трябва да бъде обхваната в тестови случаи, за да не бъде пропусната по време на изпълнението.
  • Когато дизайнът на новото приложение е различен от този на наследеното (UI), тогава тестовите случаи, свързани с потребителския интерфейс, трябва да бъдат модифицирани, за да се адаптира новият дизайн. Решението за актуализиране или писане на нови, в този случай, може да бъде взето от тестера въз основа на обема на настъпилата промяна.

Тестване на обратна съвместимост

Миграцията на системата изисква също така тестерите да проверят „Обратна съвместимост“, при което въведената нова система е съвместима със старата система (поне 2 предишни версии) и гарантира, че тя функционира перфектно с тези версии.

Обратната съвместимост е да се гарантира:

  1. Дали новата система поддържа функционалността, поддържана в по-ранните 2 версии заедно с новата.
  2. Системата може да бъде мигрирана успешно от предишните 2 версии без никакви неприятности.

Следователно е от съществено значение да се осигури обратна съвместимост на системата, като се извършат специално тестовете, свързани с поддържането на обратна съвместимост. Тестовете, свързани със обратна съвместимост, трябва да бъдат проектирани и включени в документа за спецификация на теста за изпълнение.

Тестване на откат

В случай на някакви проблеми по време на извършването на миграцията или ако има неуспех на миграцията по всяко време по време на миграцията, тогава трябва да е възможно системата да се върне към старата система и да възобнови функцията си бързо, без да се влияе на потребителите и функционалността, поддържана по-рано.

Така че, за да се провери това, трябва да бъдат проектирани сценарии за тестване на отказ на миграция като част от отрицателното тестване и механизмът за връщане трябва да бъде тестван. Общото време, необходимо за възстановяване на старата система, също трябва да бъде записано и отчетено в резултатите от теста.

След откат, основната функционалност и регресионно тестване (автоматизирано) трябва да се изпълни, за да се гарантира, че миграцията не е повлияла на нищо и връщането е успешно при връщането на старата система на място.

Обобщен доклад за теста за миграция

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

как да добавя елементи в масив java

Трябва ясно да се отчита времето, отчетено за следните дейности:

  1. Общо време за миграция
  2. Престой на приложенията
  3. Време, прекарано за мигриране на 10000 записа.
  4. Време, прекарано за откат.

В допълнение към горната информация могат да се отчитат и всякакви наблюдения / препоръки.

Предизвикателства при тестване на миграцията на данни

Предизвикателствата пред това тестване са предимно с данни. По-долу са малко в списъка:

# 1) Качество на данните:

Може да открием, че данните, използвани в наследеното приложение, са с лошо качество в новото / надстроеното приложение. В такива случаи качеството на данните трябва да се подобри, за да отговаря на бизнес стандартите.

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

# 2) Несъответствие на данните:

Данните, мигрирани от наследството към новото / надстроеното приложение, могат да бъдат открити за несъответстващи в новото. Това може да се дължи на промяната в типа данни, формата на съхранението на данните, целта, за която се използват данните, може да бъде предефинирана.

Това води до огромни усилия за модифициране на необходимите промени, за да коригира несъответстващите данни или да ги приеме и настрои за тази цел.

# 3) Загуба на данни:

Данните могат да бъдат загубени при мигриране от наследеното към новото / надстроеното приложение. Това може да е със задължителни или незадължителни полета. Ако изгубените данни са за незадължителни полета, тогава записът за него ще остане валиден и може да бъде актуализиран отново.

Но ако данните на задължителното поле бъдат загубени, тогава самият запис става невалиден и не може да бъде изтеглен. Това ще доведе до огромна загуба на данни и трябва да се извлече или от архивната база данни или от журналите за одит, ако е заснета правилно.

# 4) Обем на данните:

Огромни данни, които изискват много време за мигриране в рамките на периода на престой на миграционната активност. E.g: Скреч карти в индустрията на телекомуникациите, потребители на интелигентна мрежова платформа и т.н., тук предизвикателството е с времето, старите данни се изчистят, ще бъдат създадени огромни нови данни, които трябва да бъдат мигрирани отново. Автоматизацията е решението за огромна миграция на данни.

# 5) Симулация на среда в реално време (с действителните данни):

Симулацията на среда в реално време в лабораторията за тестване е друго истинско предизвикателство, при което тестерите попадат в различни видове проблеми с реалните данни и реалната система, с която не се сблъскват по време на тестването.

Така че вземането на проби от данни, репликацията на реалната среда, идентифицирането на обема на данните, участващи в миграцията, е доста важно, докато се извършва тестване на миграцията на данни.

# 6) Симулация на обема на данните:

Екипите трябва да изучават данните в системата на живо много внимателно и трябва да измислят типичния анализ и вземане на проби от данните.

E.g: потребители с възрастова група под 10 години, 10-30 години и т.н., Доколкото е възможно, трябва да се получат данни от живо, ако не е необходимо създаването на данни в тестовата среда. Трябва да се използват автоматизирани инструменти за създаване на голям обем данни. Може да се използва екстраполация, където е приложимо, ако обемът не може да се симулира.

Съвети за изглаждане на рисковете от миграцията на данни

По-долу са дадени няколко съвета за изглаждане на рисковете от миграция на данни:

  • Стандартизирайте данните, използвани в наследената система, така че при мигриране стандартните данни да са достъпни в новата система
  • Подобрете качеството на данните, така че при мигриране да има качествени данни за тестване, даващи усещането за тестване като краен потребител
  • Почистете данните преди мигриране, така че при мигриране дублирани данни няма да присъстват в новата система, а това също поддържа цялата система чиста
  • Проверете отново ограниченията, съхранените процедури, сложни заявки, които дават точни резултати, така че при мигриране да се връщат коректни данни и в новата система
  • Идентифицирайте правилния инструмент за автоматизация за извършване на проверки на данни / проверки на записи в новата система в сравнение с наследството.

Заключение

Следователно, като се има предвид сложността, свързана с извършването на тестване на миграцията на данни, като се има предвид, че малка грешка във всеки аспект на проверката по време на тестването ще доведе до риск от неуспех на миграцията в производството, е много важно да се извърши внимателно и задълбочено проучване & анализ на системата преди и след миграция. Планирайте и проектирайте ефективната миграционна стратегия със здравите инструменти заедно с квалифицирани и обучени тестери.

Тъй като знаем, че миграцията оказва огромно влияние върху качеството на приложението, целият екип трябва да положи много усилия, за да провери цялата система във всички аспекти като функционалност, производителност, сигурност, използваемост, наличност, надеждност, съвместимост и т.н., което от своя страна ще осигури успешно „тестване на миграцията“.

‘Различни видове миграции’ които обикновено се случват доста често в действителност и начините за справяне с тяхното тестване ще бъдат обяснени накратко в нашата следващ урок от тази поредица .

За авторите: Това ръководство е написано от STH Автор Нандини. Тя има 7+ години опит в тестването на софтуер. Също така, благодарение на авторката на STH Gayathri S. за прегледа и предоставянето на нейните ценни предложения за подобряване на тази поредица. Gayathri има 18+ години опит в разработването и тестването на софтуер.

Кажете ни вашите коментари / предложения относно този урок.

Препоръчително четене

^