Тестування на відновлення
Тестування відновлення - це техніка тестування програмного забезпечення, яка перевіряє здатність програмного забезпечення відновлювати такі збої, як збої програмного / апаратного забезпечення, збої в роботі мережі тощо. Метою Тестування відновлення є визначення того, чи можна продовжувати операції з програмним забезпеченням після катастрофи або втрати цілісності. Тестування відновлення передбачає повернення програмного забезпечення назад до точки, коли була відома цілісність, та повторну обробку транзакцій до точки відмови.
Приклад тестування на відновлення
Коли програма отримує дані з мережі, від'єднайте з'єднувальний кабель.
- Через деякий час знову підключіть кабель і проаналізуйте здатність програми продовжувати отримувати дані від точки, в якій було порушено мережеве з’єднання.
- Перезапустіть систему, поки у браузері відкрито певну кількість сеансів, і перевірте, чи може браузер відновити їх усі чи ні
У програмній інженерії тестування на відновлюваність є різновидом нефункціонального тестування. (Нефункціональне тестування стосується аспектів програмного забезпечення, які можуть не бути пов’язані з певною функцією або дією користувача, наприклад, масштабованістю чи безпекою.)
Час, необхідний для відновлення, залежить від:
- Кількість точок перезапуску
- Обсяг заявок
- Навчання та навички людей, які проводять відновлювальні заходи, та інструменти, доступні для відновлення.
Коли є низка відмов, замість того, щоб подбати про всі відмови, тестування на відновлення слід проводити структуровано, що означає тестування на відновлення для одного сегмента, а потім іншого.
Це роблять професійні тестери. Перед тестуванням відновлення належні резервні дані зберігаються в безпечних місцях. Це робиться для того, щоб забезпечити можливість продовження операції навіть після катастрофи.
Життєвий цикл процесу відновлення
Життєвий цикл процесу відновлення можна класифікувати на наступні п’ять етапів:
- Нормальна робота
- Виникнення лиха
- Порушення та збій операції
- Ліквідація наслідків стихійних лих у процесі відновлення
- Реконструкція всіх процесів та інформації для приведення всієї системи до нормальної роботи
Давайте обговоримо ці 5 кроків детально-
-
Система, що складається з апаратного, програмного та мікропрограмного забезпечення, інтегрована для досягнення спільної мети, працює для досягнення чітко визначеної та заявленої мети. Система покликана виконувати звичайну операцію для виконання задуманої роботи без будь-яких збоїв протягом встановленого періоду часу.
-
Порушення може статися через несправність програмного забезпечення через різні причини, такі як несправність, ініційована введенням, збій програмного забезпечення через несправність обладнання, пошкодження внаслідок пожежі, крадіжки та страйку.
-
Фаза зриву - це найболючіша фаза, яка призводить до збитків у бізнесі, розриву відносин, втрат можливостей, людських годин і незмінно фінансових втрат та втрат гудвілу. Кожне розумне агентство повинно мати план відновлення після катастрофи, щоб фаза зриву була мінімальною.
-
Якщо план резервного копіювання та процеси зменшення ризику знаходяться в потрібному місці перед тим, як зіткнутися з катастрофою та аварією, тоді відновлення може бути здійснено без великих втрат часу, зусиль та енергії. Потрібно визначити призначену особу разом зі своєю командою з призначеною роллю кожної з цих осіб, щоб визначити відповідальність та допомогти організації врятуватись від тривалого періоду зриву.
-
Реконструкція може включати декілька сеансів операцій з відновлення всіх папок разом із конфігураційними файлами. Для правильного відновлення має бути належне документування та процес реконструкції.
Стратегія відновлення
Команда відновлення повинна мати свою унікальну стратегію отримання важливого коду та даних, щоб нормалізувати роботу агенції.
Стратегія може бути унікальною для кожної організації на основі критичності систем, якими вони обробляють.
Можливу стратегію для критичних систем можна візуалізувати наступним чином:
- Мати одну резервну копію або кілька
- Мати кілька резервних копій в одному місці або в різних місцях
- Щоб мати резервну копію в режимі онлайн або резервну копію в режимі офлайн
- Чи можна робити резервне копіювання автоматично на основі політики або вручну?
- Для роботи може бути використана незалежна команда з реставрації або сама команда розробників
З кожною з цих стратегій пов'язаний коефіцієнт витрат, і багато ресурсів, необхідних для кількох резервних копій, можуть споживати більше фізичних ресурсів або, можливо, знадобиться незалежна команда.
Багато компаній можуть постраждати через залежність даних та коду від відповідного агентства розробників. Наприклад, якщо Amazon AWS припинить роботу Інтернету. Незалежне відновлення має вирішальне значення в таких випадках.
Як зробити тестування на відновлення
Під час проведення тесту на відновлення слід враховувати наступні речі.
- Ми повинні створити випробувальний стенд якомога ближче до реальних умов розгортання. Зміни у взаємодії, протоколі, прошивці, апаратному забезпеченні та програмному забезпеченні повинні бути якомога ближчими до фактичного стану, якщо не такими самими.
- Завдяки вичерпному тестуванню може знадобитися багато часу, і слід провести дорогу справу, ідентичну конфігурацію та повну перевірку.
- Якщо це можливо, слід провести тестування на апаратному забезпеченні, яке ми нарешті збираємось відновити. Це особливо вірно, якщо ми відновлюємо роботу на машині, яка відрізняється від тієї, яка створила резервну копію.
- Деякі системи резервного копіювання очікують, що жорсткий диск буде точно такого ж розміру, як той, з якого була взята резервна копія.
- Застарілістю слід керувати, оскільки технологія приводу розвивається швидкими темпами, і старий привід може бути несумісним з новим. Одним із способів вирішення проблеми є відновлення на віртуальній машині. Постачальники програмного забезпечення для віртуалізації, такі як VMware Inc., можуть налаштовувати віртуальні машини на імітацію існуючого обладнання, включаючи розміри дисків та інші конфігурації.
- Інтернет-системи резервного копіювання не є винятком для тестування. Більшість постачальників послуг резервного копіювання в Інтернеті захищають нас від безпосереднього впливу проблем із засобами масової інформації завдяки використанню відмовостійких систем зберігання даних.
- Хоча онлайнові системи резервного копіювання надзвичайно надійні, ми повинні протестувати сторону відновлення системи, щоб переконатися, що немає проблем із функціональністю пошуку, захистом або шифруванням.
Процедура тестування після відновлення
Більшість великих корпорацій мають незалежних аудиторів, які періодично виконують вправи для перевірки відновлення.
Витрати на підтримку та випробування комплексного плану відновлення після стихійних лих можуть бути значними, і це може бути непомірним для дрібних підприємств.
Менші ризики можуть покладатися на резервні копії даних та плани зберігання за межами майданчика, щоб зберегти їх у разі катастрофи.
Після відновлення папок і файлів можна виконати такі перевірки, щоб гарантувати належне відновлення файлів:
- Перейменуйте пошкоджену папку документів
- Підрахуйте файли у відновлених папках і зрівняйте їх із наявною папкою.
- Відкрийте кілька файлів і переконайтеся, що вони доступні. Обов’язково відкрийте їх за допомогою програми, яка зазвичай їх використовує. І переконайтеся, що ви можете переглядати дані, оновлювати дані або що завгодно, як ви зазвичай робите.
- Найкраще відкривати декілька файлів різних типів, картинки, mp3-файли, документи, деякі великі, а інші маленькі.
- Більшість операційних систем мають утиліти, якими можна порівнювати файли та каталоги.
Короткий зміст:
У цьому посібнику ми вивчили різні аспекти тестування відновлення, які допомагають зрозуміти, чи відповідає система чи програма своїм вимогам після відмови.
Ця стаття представлена Шветою Приядаршіні