Меню

Підручник з тестування міграції даних: Повне керівництво

data migration testing tutorial

Спробуйте Наш Інструмент Для Усунення Проблем

Огляд тестування міграції даних:

Досить часто можна почути, що додаток переміщується на інший сервер, змінюється технологія, оновляється до наступної версії або переміщується на інший сервер баз даних тощо,

  • Що це насправді означає?
  • Що очікується від групи тестувань у цих ситуаціях?

З точки зору тестування, це все означає, що додаток повинен бути ретельно протестований наскрізно, разом із успішною міграцією з існуючої системи на нову.

Підручники з цієї серії:

У цьому випадку тестування системи повинно проводитися з усіма даними, які використовуються в старому додатку, а також з новими даними. Існуючу функціональність потрібно перевірити разом із новою / зміненою функціональністю.

Перевірка міграції даних

Замість просто тестування міграції його також можна назвати тестуванням міграції даних, де всі дані користувача будуть перенесені в нову систему.

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

Стара заявка зазвичай називається ' спадщина ’Заявка. Поряд з новою / оновленою програмою, також обов'язково продовжувати тестувати застарілу програму, поки нові / оновлені не стануть стабільними та послідовними. Широкий тест міграції нового додатка виявить нові проблеми, яких не було знайдено у застарілій програмі.

Що ви дізнаєтесь:

Що таке тестування на міграцію?

Тестування міграції - це процес перевірки міграції застарілої системи на нову систему з мінімальними перебоями / простоєм, з цілісністю даних і без втрати даних, забезпечуючи при цьому, що всі зазначені функціональні та нефункціональні аспекти програми виконуються після міграція.

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

Тестування міграції

Чому міграційний тест?

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

Отже, хоча Систему, що використовується, потрібно перенести на нову систему, важливо забезпечити наступні пункти:

  1. Потрібно уникати / мінімізувати будь-які порушення / незручності, спричинені користувачеві внаслідок міграції. Наприклад: простої, втрата даних
  2. Потрібно переконатися, чи зможе користувач продовжувати використовувати всі функції програмного забезпечення, завдаючи мінімальної шкоди або взагалі не завдаючи їй шкоди. Наприклад: зміна функціональних можливостей, вилучення певної функціональності
  3. Також важливо передбачити та виключити всі можливі збої / перешкоди, які можуть виникнути під час фактичної міграції системи, що працює.

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

Це тестування має своє значення, і воно відіграє життєво важливу роль, коли дані надходять у картину.

Технічно це також потрібно виконати для наступних цілей:

  • Щоб забезпечити сумісність нового / оновленого додатка з усім можливим обладнанням та програмним забезпеченням, яке підтримує застаріла програма. Також, новий сумісність слід протестувати на наявність нового обладнання, програмної платформи.
  • Щоб забезпечити всі існуючі функціональні можливості, як у застарілій програмі. Не повинно бути змін у способі роботи програми в порівнянні із застарілою.
  • Можливість великої кількості дефектів внаслідок міграції дуже велика. Багато дефектів, як правило, пов'язані з даними, а отже, ці дефекти повинні бути виявлені та виправлені під час тестування.
  • Щоб переконатись, що час відповіді системи нового / оновленого додатка однаковий чи менший, ніж той, що потрібний для застарілої програми.
  • Щоб переконатися, що зв’язок між серверами, апаратним забезпеченням, програмним забезпеченням тощо не порушено та не порушується під час тестування. Потік даних між різними компонентами не повинен порушуватися за будь-яких умов.

Коли потрібно це тестування?

Тестування повинно проводитися як до, так і після міграції.

Різні фази міграційного тесту , що проводитимуться у випробувальній лабораторії, можна класифікувати як нижче.

  1. Передміграційне тестування
  2. Тестування міграції
  3. Тестування після міграції

На додаток до вищезазначеного також виконуються наступні тести як частина всієї міграційної діяльності.

  1. Перевірка зворотної сумісності
  2. Тестування відкоту

Перш ніж проводити це Тестування, важливо, щоб будь-який Тестер чітко розумів наведені нижче пункти:

  1. Зміни, що відбуваються як частина нової системи (сервер, інтерфейс, БД, схема, потік даних, функціональність тощо,)
  2. Для розуміння фактичної стратегії міграції, викладеної командою. Як відбувається міграція, покрокові зміни, що відбуваються у серверній системі та сценаріях, відповідальних за ці зміни.

Отже, важливо провести ретельне вивчення старої та нової системи, а потім, відповідно, спланувати та розробити тестові кейси та сценарії тестів, які будуть охоплені як частина вищезазначених фаз тестування, та підготувати стратегію тестування.

Стратегія тестування міграції даних

Розробка тестової стратегії міграції включає набір заходів, які слід виконати, та декілька аспектів, які слід врахувати. Це має на меті мінімізувати помилки та ризики, що виникають в результаті міграції, та ефективно провести тестування міграції.

Діяльність у цьому тестуванні:

# 1) Формування спеціалізованої команди :

Сформуйте команду тестування з членами, які мають необхідні знання та досвід, та проведіть навчання, пов’язане із системою, що переноситься.

# два) Аналіз бізнес-ризиків, аналіз можливих помилок :

Поточний бізнес не повинен заважати після міграції, а отже здійснювати ' Аналіз бізнес-ризиків зустрічі із залученням відповідних зацікавлених сторін (керівник випробувань, бізнес-аналітик, архітектори, власники продуктів, власник бізнесу тощо) та виявлення ризиків та можливих пом'якшень. Тестування повинно включати сценарії для виявлення цих ризиків та перевірки того, чи були застосовані належні пом'якшення.

Поведінка Аналіз можливих помилок використовуючи відповідні „Підходи до вгадування помилок“ а потім розробити тести навколо цих помилок, щоб виявити їх під час тестування.

Запитання та відповіді на питання співбесіди адміністратора Salesforce pdf

# 3) Аналіз та ідентифікація обсягу міграції:

Проаналізуйте чіткий обсяг тесту міграції, як коли і що потрібно перевірити.

# 4) Визначте відповідний інструмент для міграції:

Визначаючи стратегію цього тестування, автоматичну чи ручну, визначте інструменти, які збираєтесь використовувати. Наприклад: Автоматизований інструмент для порівняння вихідних та цільових даних.

# 5) Визначте відповідне тестове середовище для міграції:

Визначте окремі середовища для середовищ до і після міграції, щоб здійснити будь-яку перевірку, яка необхідна в рамках тестування. Зрозумійте та задокументуйте технічні аспекти застарілої та нової системи міграції, щоб забезпечити, щоб тестове середовище було налаштоване відповідно до цього.

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

Підготуйте документ із специфікацією тесту на міграцію, де чітко описується підхід до тестування, напрямки тестування, методи тестування (автоматизовані, ручні), методологія тестування (чорний ящик, техніка тестування білого ящика ), Кількість циклів тестування, графік тестування, підхід до створення даних та використання даних у режимі реального часу (конфіденційну інформацію потрібно маскувати), специфікацію тестового середовища, кваліфікацію тестувальників тощо, та провести оглядову сесію із зацікавленими сторонами.

# 7) Запуск виробництва перенесеної системи :

Проаналізуйте та задокументуйте список справ для міграції виробництва та опублікуйте його заздалегідь

Різні фази міграції

Нижче наведено різні етапи міграції.

Фаза No1:Передміграційне тестування

Перш ніж переносити дані, виконуються набори тестових заходів як частина фази передміграційного тестування. Це ігнорується або не враховується в більш простих додатках. Але коли потрібно мігрувати складні програми, необхідна попередня міграція.

Нижче наведено перелік дій, які було здійснено на цьому етапі:

  • Встановіть чіткий обсяг даних - які дані потрібно включити, які дані виключити, які дані потребують перетворення / перетворення тощо.
  • Виконайте зіставлення даних між застарілою версією та новою програмою - для кожного типу даних у застарілій програмі порівняйте відповідний тип у новій програмі, а потім зіставіть їх - Картування вищого рівня.
  • Якщо у новій програмі є обов’язкове поле, але це не стосується застарілих даних, то переконайтеся, що у спадщини немає цього поля як нульове. - Картування нижчого рівня.
  • Чітко вивчіть схему даних нової програми - назви полів, типи, мінімальні та максимальні значення, довжина, обов’язкові поля, перевірка рівня полів тощо.
  • Ряд таблиць у застарілій системі слід записати, а якщо будь-які таблиці скидаються та додаються після перенесення, потрібно перевірити.
  • Кілька записів у кожній таблиці, подання повинні бути зазначені у застарілій програмі.
  • Вивчіть інтерфейси в новій програмі та їх зв’язки. Дані, що надходять в інтерфейс, повинні бути надійно захищені і не порушуватися.
  • Підготуйте тестові кейси, сценарії тестування та приклади використання для нових умов у нових додатках.
  • Виконайте набір тестових кейсів, сценаріїв із набором користувачів і зберігайте результати, журнали. Те саме потрібно перевірити після перенесення, щоб переконатися, що застарілі дані та функціональність залишаються незмінними.
  • Кількість даних та записів слід чітко записати, після перевірки його потрібно перевірити на відсутність втрати даних.

Фаза No2:Тестування міграції

' Керівництво з міграції ’, яке є підготовлених командою з питань міграції, необхідно суворо дотримуватися для здійснення міграційної діяльності. В ідеалі активність міграції починається із резервного копіювання даних на стрічці, щоб у будь-який час можна було відновити застарілу систему.

Перевірка документальної частини « Керівництво з міграції ’також є частиною тестування міграції даних . Переконайтеся, що документ чіткий і простий у виконанні. Усі сценарії та кроки повинні бути задокументовані правильно, без жодних двозначностей. Будь-які помилки документації, пропущені збіги в порядку виконання кроків також слід вважати важливими, щоб їх можна було повідомити та виправити.

Сценарії міграції, керівництво та іншу інформацію, що стосується фактичної міграції, потрібно взяти із сховища контролю версій для виконання.

Відзначити фактичний час, необхідний для міграції з моменту початку міграції до успішного відновлення системи, є одним із тестових випадків, який слід виконати, а отже, 'Час, необхідний для міграції системи' Потрібно записати в остаточний звіт про випробування, який буде представлений як частина результатів випробувань на міграцію, і ця інформація буде корисною під час запуску виробництва. Простій, зафіксований у тестовому середовищі, екстраполюється для обчислення приблизного простою в живій системі.

Саме на застарілій системі буде здійснюватися міграційна діяльність.

Під час цього тестування всі компоненти навколишнього середовища, як правило, збиваються і вилучаються з мережі для здійснення міграційних заходів. Отже, слід зазначити «Час простою» необхідний для тесту на міграцію. В ідеалі вона буде такою ж, як і за часів міграції.

Як правило, міграційна діяльність, визначена в документі „Керівництво з міграції”, включає:

  • Фактична міграція програми
  • Брандмауери, порти, хости, апаратне забезпечення, конфігурації програмного забезпечення змінені відповідно до нової системи, на яку переноситься застаріла версія
  • Витоки даних, перевірки безпеки виконуються
  • Перевірено зв’язок між усіма компонентами програми

Тестерам бажано перевірити вищезазначене у серверній системі або шляхом тестування білих ящиків.

Після завершення дії міграції, зазначеної в посібнику, запускаються всі сервери та виконуються базові тести, пов’язані з перевіркою успішної міграції, що гарантує, що всі кінцеві системи належним чином підключені і всі компоненти розмовляють з кожним інше, БД працює і працює, фронт-енд успішно спілкується з тильним. Ці тести потрібно ідентифікувати раніше та записати у документі Специфікації тесту міграції.

Існує можливість того, що програмне забезпечення підтримує кілька різних платформ. У такому випадку перенесення потрібно перевірити на кожній із цих платформ окремо.

Перевірка сценаріїв міграції буде частиною тесту міграції. Іноді окремий сценарій міграції також перевіряється за допомогою 'тестування білого ящика' в автономному середовищі тестування.

Отже, тестування на міграцію буде поєднанням як «тестування білого ящика», так і тестування «чорного ящика».

Як тільки ця перевірка, пов’язана з міграцією, буде виконана і відповідні тести пройдені, команда може продовжувати діяльність із тестування після перенесення.

Фаза No3:Тестування після міграції

Після успішної міграції програми з’являється тестування після перенесення.

Тут наскрізне тестування системи виконується в середовищі тестування. Тестери виконують ідентифіковані тестові випадки, сценарії тестів, випадки використання зі застарілими даними, а також новий набір даних.

найкраща ігрова компанія для роботи

На додаток до цього, є певні елементи, які слід перевірити в перенесених середовищах, перелічені нижче:

Усі вони задокументовані як тестовий випадок та включені до документа „Тестові специфікації”.

  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. Юзабіліті - це ще один аспект, який слід перевірити, коли, якщо розмітка графічного інтерфейсу / інтерфейсна система змінилася або будь-яка функціональність змінилася, яка простота використання відчувається кінцевим користувачем порівняно із застарілою системою.

Оскільки сфера тестування після міграції стає дуже величезною, ідеально розділити важливі тести, які потрібно виконати спочатку, щоб підтвердити успішність міграції, а потім провести інші, що пізніше.

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

Кілька порад тестувальникам щодо написання тестових кейсів для виконання після міграції:

  • Коли програма перенесена, це не означає, що тестові кейси повинні бути написані для цілої нової програми. Тестові кейси, вже розроблені для застарілої версії, все ще мають бути добрими для нової програми. Отже, наскільки це можливо, використовуйте старі тестові кейси та перетворюйте застарілі тестові кейси на нові програми, де це потрібно.
  • Якщо в новій програмі є якісь зміни функції, тоді слід змінити тестові кейси, пов’язані з цією функцією.
  • Якщо в новій програмі додано якусь нову функцію, тоді для цієї конкретної функції слід розробити нові тестові кейси.
  • Якщо в новій програмі спостерігається будь-яке падіння функцій, тестові випадки відповідних застарілих додатків не слід розглядати для виконання після перенесення, а також слід позначати як недійсні та зберігати окремо.
  • Розроблені тестові кейси завжди повинні бути надійними та послідовними з точки зору використання. Перевірка критичних даних повинна охоплюватися тестовими випадками, щоб вони не були пропущені під час виконання.
  • Коли дизайн нової програми відрізняється від проекту застарілої версії (UI), тоді тестові кейси, пов’язані з користувацьким інтерфейсом, повинні бути змінені, щоб адаптувати новий дизайн. Рішення або оновити, або написати нові, у цьому випадку, може прийняти тестувальник, виходячи з обсягу змін.

Тестування зворотної сумісності

Міграція системи також вимагає від тестувальників перевірки „Зворотної сумісності”, в якій нова система, що вводиться, сумісна зі старою системою (принаймні 2 попередні версії) і гарантує, що вона ідеально функціонує з цими версіями.

Зворотна сумісність полягає у забезпеченні:

  1. Чи підтримує нова система функціональність, що підтримується в попередніх 2-х версіях, разом із новою.
  2. Систему можна успішно перенести з попередніх 2-х версій без жодних клопотів.

Отже, важливо забезпечити зворотну сумісність системи, спеціально проводячи тести, пов'язані з підтримкою зворотної сумісності. Тести, пов'язані зі зворотною сумісністю, повинні бути розроблені та включені в документ Тестових специфікацій для виконання.

Тестування відкоту

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

Отже, для того, щоб це перевірити, сценарії тестування на відмову міграції повинні бути розроблені як частина негативного тестування та механізм відкоту. Загальний час, необхідний для відновлення до застарілої системи, також повинен бути зафіксований та повідомлений у результатах тестування.

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

Підсумковий звіт про міграційний тест

Звіт про випробування повинен бути виготовлений після завершення тестування і повинен охоплювати звіт про короткий зміст різних тестів / сценаріїв, що проводяться в рамках різних фаз міграції, із статусом результату (проходження / невдача) та журналами тестування.

Слід чітко повідомляти про час, зафіксований для наступних заходів:

  1. Загальний час міграції
  2. Час простою додатків
  3. Час, витрачений на перенесення 10000 записів.
  4. Час, витрачений на відкат.

На додаток до вищезазначеної інформації, також можна повідомляти про будь-які спостереження / рекомендації.

Проблеми при тестуванні міграції даних

Проблеми, з якими стикається це тестування, полягають головним чином у даних. Нижче наведено кілька у списку:

# 1) Якість даних:

Ми можемо виявити, що дані, які використовуються у застарілій програмі, є низькою якістю в новій / оновленій програмі. У таких випадках якість даних має бути покращена, щоб відповідати діловим стандартам.

Такі фактори, як припущення, перетворення даних після міграції, дані, введені у самій застарілій програмі, є недійсними, поганий аналіз даних тощо призводить до низької якості даних. Це призводить до високих експлуатаційних витрат, збільшення ризиків інтеграції даних та відхилення від мети бізнесу.

# 2) Невідповідність даних:

Дані, перенесені із застарілої версії в нову / оновлену програму, можуть виявити невідповідність у новій. Це може бути пов'язано зі зміною типу даних, формату зберігання даних, мета, для якої використовуються дані, може бути перевизначена.

Це призводить до величезних зусиль, щоб змінити необхідні зміни, щоб або виправити невідповідні дані, або прийняти їх і налаштувати з цією метою.

# 3) Втрата даних:

Дані можуть бути втрачені під час переходу із застарілої версії на нову / оновлену програму. Це може бути з обов’язковими або необов’язковими полями. Якщо втрачені дані стосуються необов’язкових полів, то запис для них все одно буде дійсним і може бути оновлений знову.

Але якщо дані обов’язкового поля втрачені, то сам запис стає недійсним і його не можна відкликати. Це призведе до величезної втрати даних, і їх доведеться отримувати або з резервної бази даних, або з журналів аудиту, якщо вони правильно записані.

# 4) Обсяг даних:

Величезні дані, що вимагають багато часу для міграції у вікні простою під час міграційної діяльності. Наприклад: Скретч-карти в галузі телекомунікацій, користувачі на інтелектуальній мережевій платформі тощо, тут проблема полягає в тому, що застарілі дані очищаються, будуть створені величезні нові дані, які потрібно перенести знову. Автоматизація - це рішення для величезної міграції даних.

# 5) Моделювання середовища в реальному часі (з фактичними даними):

Моделювання середовища в реальному часі в лабораторії тестування є ще однією реальною проблемою, коли тестувальники стикаються з різними проблемами з реальними даними та реальною системою, з якою не стикаються під час тестування.

Отже, вибірка даних, тиражування реального середовища, ідентифікація обсягу даних, що беруть участь у міграції, є досить важливою під час проведення тестування міграції даних.

# 6) Моделювання обсягу даних:

Командам потрібно дуже ретельно вивчати дані в реальній системі, і вони повинні придумати типовий аналіз та вибірку даних.

Наприклад: користувачі з віковою групою менше 10 років, 10-30 років тощо. Наскільки це можливо, необхідно отримувати дані з прямого ефіру, якщо не створювати дані в середовищі тестування. Для створення великого обсягу даних потрібно використовувати автоматизовані інструменти. Екстраполяція, де це застосовно, може бути використана, якщо обсяг неможливо змоделювати.

Поради щодо пом’якшення ризиків міграції даних

Нижче наведено кілька порад, які слід виконати, щоб згладити ризики міграції даних:

  • Стандартизуйте дані, що використовуються у застарілій системі, так що при міграції стандартні дані будуть доступні в новій системі
  • Підвищення якості даних, щоб при міграції були якісні дані для тестування, що дають відчуття тестування як кінцевого користувача
  • Очистіть дані перед перенесенням, щоб при перенесенні дублікати даних не були присутніми в новій системі, а також це підтримувало всю систему в чистоті
  • Перевірте обмеження, збережені процедури, складні запити, що дають точні результати, щоб при перенесенні правильні дані також поверталися в новій системі
  • Визначте правильний інструмент автоматизації для перевірки даних / перевірки записів у новій системі порівняно із застарілою версією.

Висновок

Отже, враховуючи складність проведення тестування міграції даних, маючи на увазі, що невелика помилка в будь-якому аспекті перевірки під час тестування призведе до ризику збою міграції на виробництві, дуже важливо провести ретельне і ретельне дослідження & аналіз системи до та після міграції. Плануйте та розробляйте ефективну стратегію міграції за допомогою надійних інструментів разом із кваліфікованими та навченими тестувальниками.

Оскільки ми знаємо, що міграція має величезний вплив на якість програми, вся команда повинна докласти чимало зусиль, щоб перевірити всю систему у всіх аспектах, таких як функціональність, продуктивність, безпека, зручність використання, доступність, надійність, сумісність тощо, що, в свою чергу, забезпечить успішне 'тестування міграції'.

'Різні типи міграцій' що зазвичай трапляється досить часто в реальності, і способи проведення їх тестування будуть коротко пояснені в нашій наступний підручник з цієї серії .

Про авторів: Цей посібник написаний автором STH Нандіні. Вона має 7+ років досвіду у тестуванні програмного забезпечення. Крім того, подяка автору STH Гаятрі С. за огляд та надання цінних пропозицій щодо вдосконалення цієї серії. Гаятрі має понад 18 років досвіду в розробці програмного забезпечення та тестуванні.

Повідомте нам свої коментарі / пропозиції щодо цього підручника.

Рекомендована література

^