Тестування міграції даних (ETL)
ETL (Extract, Transform, Load) - це процес, що поєднує три етапи: вилучення, перетворення та завантаження даних з одного джерела до іншого, тобто. процес переміщення даних з одного місця до іншого, з одного формату в інший або з одного додатка до іншого. Як правило, це результат впровадження нової системи чи місця зберігання даних. Бізнес-драйвером зазвичай є міграція або консолідація додатків, за яких застарілі системи замінюються або доповнюються новими додатками, які використовують той самий набір даних.
Міграція часто починається, коли компанії переходять від локальної інфраструктури та додатків до хмарних сховищ та додатків для оптимізації чи перетворення свого бізнесу.
ETL-тестування - це вид тестування, який виконується для гарантії того, що дані, перенесені з вихідної в цільову базу даних, є точними та відповідають чинним правилам перетворення.
Приклад:
Давайте розглянемо приклад злиття двох компаній - компанії A та компанії B. Після злиття їх операції будуть об'єднані, а їх клієнти, співробітники та інші дані зберігатимуться в єдиній централізованій базі даних. Припустимо, що компанія A використовує базу даних Oracle для зберігання всієї інформації, а компанія B використовує MySQL. Тепер для об'єднання своєї інформації обидві компанії можуть використовувати процес ETL для перенесення даних із окремих баз даних в одну узгоджену базу даних. У процесі ETL, оскільки дві бази даних різні, дані обох компаній будуть у різному форматі, використовуватимуться різні угоди про імена, використовуватимуться різні структури таблиць тощо. Через ці відмінності компаніям необхідно переконатися, що перед завантаженням даних до цільової бази даних вона була належним чином очищена і може сформувати потрібний формат. При тестуванні ETL тестувальники повинні переконатися, що:
дані обох баз даних були перетворені на формат цільової бази даних;
необхідні функції перетворення було виконано;
У процесі не було втрачено жодних даних, і дані точні.
Міграція складається з 7 етапів:
Premigration planning: Оцінити дані, що переміщуються на предмет стабільності;
Project initiation: Визначити та проінструктувати ключових осіб, які приймають рішення;
Landscape analysis: Створіть надійний процес управління правилами якості даних та поінформуйте бізнес про цілі проекту, включаючи відключення застарілих систем;
Solution design: Визначте, які дані необхідно перемістити, а також якість цих даних до та після переміщення.
Build & test: Закодуйте логіку міграції та протестуйте міграцію з копією робочого середовища.
Execute & validate: Продемонструйте, що міграція відповідає вимогам та що переміщені дані придатні для використання у бізнесі.
Decommission & monitor: Вимкніть та утилізуйте старі системи.
Це може бути величезним обсягом роботи, але не всі ці кроки необхідні для кожної міграції. Кожна ситуація є унікальною, і кожна компанія підходить до вирішення завдання по-своєму.
Як розробити стратегію перенесення даних?
Враховуючи цю складність, точне тестування має починатися задовго до фактичного перенесення даних, щоб забезпечити необхідний рівень обізнаності та ресурсів. Щоб гарантувати, що проект отримає необхідну йому увагу, зосередьтеся на провокаційному елементі міграції - на тому факті, що застаріла система буде відключена. Надійна стратегія тестування є обов'язковою!
Отже, етапи стратегії тестування тесту міграції, які будуть проводитись, можуть бути класифіковані як Pre-Migration Testing; Migration Testing; Post Migration Testing.
Тестування перед міграцією (Pre-Migration testing)
Ця фаза тестування ігнорується або не враховується у більш простих програмах. Але коли необхідно мігрувати складні програми, необхідно виконати дії перед міграцією. Ось дії, які робляться на цьому етапі:
Встановіть чіткий обсяг даних - які дані мають бути включені, які дані мають бути виключені, які дані потребують перетворення/конвертації тощо;
Виконання зіставлення даних (data mapping) між застарілим та новим додатком - для кожного типу даних у застарілому додатку порівняйте відповідний тип у новому додатку, а потім зіставте їх - зіставлення вищого рівня (Higher level mapping);
Вивчіть схему даних нового додатка - імена полів, типи, мінімальні та максимальні значення, довжину, обов'язкові поля, перевірки на рівні полів тощо;
Вивчіть інтерфейси в новому додатку та їх підключення. Дані, що проходять через інтерфейс, повинні бути надійно захищені та налаштовані;
Підготуйте тестові випадки, тестові сценарії та використовуйте їх для нових умов у нових програмах;
Виконайте набір тестових випадків із набором користувачів та збережіть результати, журнали. Те саме необхідно перевірити після того, як відбулася міграція, щоб переконатися, що застарілі дані та функціональність не пошкоджені;
Кількість даних та записів повинна бути чітко записана, її необхідно перевірити після міграції, щоб довести, що жодних даних не було втрачено.
Міграційне тестування (Migration testing)
В ідеалі міграція починається з резервного копіювання даних на стрічку, щоб будь-якої миті можна було відновити застарілу систему. Усі сценарії та кроки мають бути правильно задокументовані без будь-якої двозначності.
Запис фактичного часу, витраченого на міграцію з моменту початку міграції до успішного відновлення системи, є одним із тестових випадків, які необхідно виконати, і, отже, «Час, необхідний для міграції системи», має бути записаний у final test report, який буде надано як частина результатів міграційного тестування, і ця інформація буде корисною під час запуску в прод. Час простою, записане в тестовому середовищі, екстраполюється для розрахунку приблизного часу простою в працюючій системі. Саме у застарілій системі виконуватиметься міграція.
Під час цього тестування всі компоненти середовища зазвичай відключаються та видаляються з мережі для виконання дій з міграції. Отже, слід зазначити «Час простою», необхідне тесту міграції. В ідеалі воно буде таким самим, як і час міграції. Як правило, дії міграції, визначені в документі «Посібник з міграції» (Migration Guide), включають:
Фактична міграція програми;
Брандмауери, порти, хости, апаратні та програмні конфігурації - всі вони змінюються відповідно до нової системи, на яку переноситься стара версія;
Витоку даних, перевірки безпеки;
Перевіряється зв'язок між усіма компонентами програми;
Тестувальникам рекомендується перевірити вищевикладене у бекенді системи або шляхом проведення тестування білої скриньки. Після завершення міграції всі сервери будуть запущені і будуть виконані базові тести, пов'язані з перевіркою успішної міграції, що гарантує, що всі наскрізні системи правильно підключені і всі компоненти взаємодіють один з одним, БД запущений і працює, фронт успішно взаємодіє з беком. Ці тести повинні бути ідентифіковані заздалегідь та записані в документі «Специфікація тестів міграції» (Migration Test Specification document). Є можливість, що програмне забезпечення підтримує кілька різних платформ. У такому разі міграцію необхідно перевіряти на кожній із цих платформ окремо. Перевірка сценаріїв міграції буде частиною тестування міграції.
Іноді окремий сценарій міграції також перевіряється за допомогою тестування білої скриньки в автономному середовищі тестування. Отже, міграційне тестування буде комбінацією тестування білої та чорної скриньок. Після завершення цієї перевірки, пов'язаної з міграцією, та проходження відповідних тестів, команда може продовжити роботу з тестування після міграції.
Тестування після міграції (Post-Migration testing)
Після успішної міграції програми набуває чинності тестування після міграції. Тут наскрізне тестування системи виконується у тестовому середовищі. Тестувальники виконують певні тестові набори, тестові сценарії, варіанти використання зі застарілими даними та новим набором даних. На додаток до цього є певні елементи, які необхідно перевірити в перенесених середовищах:
Усі застарілі дані перенесені до нового додатку протягом запланованого часу простою. Щоб переконатися в цьому, порівняйте кількість записів між застарілим та новим додатком для кожної таблиці та подань у базі даних;
Усі зміни схеми (поля та таблиці додані чи видалені) відповідно до нової системи оновлено;
Дані, перенесені зі застарілого додатка до нового, повинні зберігати своє значення і формат, якщо це не вказано окремо. Щоб переконатися в цьому, порівняйте значення даних між застарілою та новою базою даних програми;
Перенесені дані у новому додатку. Охопіть максимальну кількість можливих причин. Для забезпечення 100% охоплення перевірки перенесення даних використовуйте інструмент автоматизованого тестування;
Безпека бази даних;
Цілісність даних для всіх можливих записів вибірки;
Раніше підтримувані функції у застарілій системі працюють належним чином у новій системі;
Потік даних у додатку, що охоплює більшість компонентів;
Інтерфейс між компонентами повинен бути ретельно протестований, оскільки дані не повинні змінюватися, губитися та спотворюватися під час проходження через компоненти. Для перевірки цього можна використати інтеграційні тестові випадки;
Надмірність застарілих даних. Жодні застарілі дані не повинні дублюватися під час міграції;
Випадки невідповідності даних, такі як зміна типу даних, зміна формату зберігання тощо;
Усі перевірки на рівні поля у застарілому додатку також повинні виконуватись у новому додатку;
Будь-яке додавання даних у новий додаток не повинно відбиватися на застарілому;
Оновлення даних застарілої програми через нову програму має підтримуватися. Після оновлення у новому додатку воно не повинно відбиватися на застарілому;
Видалення даних застарілої програми у новій програмі має підтримуватися. Після видалення в новому додатку воно також не повинно видаляти дані у застарілому;
Переконайтеся, що зміни, внесені до застарілої системи, підтримують нові функції, які надаються як частина нової системи;
Переконайтеся, що користувачі застарілої системи можуть продовжувати використовувати як старі, так і нові можливості, особливо ті, які пов'язані зі змінами. Виконання тестових випадків та результатів тестування, збережених під час тестування перед міграцією;
Створіть нових користувачів у системі та проведіть тести, щоб переконатися, що функціональність як старої, так і нової програми підтримує новостворених користувачів та працює нормально;
Проведіть тести функціональності на різних вибірках даних (різні вікові групи, користувачі різних регіонів тощо);
Також необхідно перевірити, чи включені «Прапори функцій» для нових функцій, а їх увімкнення/вимкнення дозволяє вмикати та вимикати функції;
Тестування продуктивності важливо для того, щоб переконатися, що перехід на нові системи/програмне забезпечення не погіршив продуктивність системи;
Також потрібне проведення навантажувальних та стрес-тестів для забезпечення стабільності системи;
Переконайтеся, що оновлення програмного забезпечення не відкрило жодних уразливостей у системі безпеки, і, отже, проведіть тестування безпеки, особливо в тій галузі, де до системи були внесені зміни під час міграції;
Зручність використання - це ще один аспект, який необхідно перевірити, в якому, якщо макет графічного інтерфейсу користувача/інтерфейсна система змінилася або змінилася якась функціональність, яка простота використання, яку кінцевий користувач відчуває порівняно із застарілою системою;
Оскільки скоуп тестування після міграції стає дуже великим, ідеально розділити важливі тести, які необхідно виконати в першу чергу, щоб переконатися, що міграція пройшла успішно, а потім виконати пізніше.
Також рекомендується автоматизувати наскрізні функціональні тестові випадки та інші можливі тестові випадки, щоб можна було скоротити час тестування та швидко отримати результати.
Джерела:
Дод. матеріал:
Last updated