Тестування надійності — це тип тестування програмного забезпечення, який перевіряє, чи може програмне забезпечення виконувати безвідмовну роботу в певному середовищі протягом визначеного періоду часу.
Він спрямований на виявлення потенційних збоїв або проблем продукту чи системи та визначення імовірності їх виникнення.
В широкому сенсі до цього типу тестування відносять: тестування продуктивності, тестування безпеки, регресійне тестування, тестування відновлення і функціональне тестування, але це дискусійно.
У більш вузькому розумінні до цього типу тестування відносять: навантажувальне тестування, стрес тестування, регресійне тестування і тестування функцій.
Згадаємо складові надійності згідно з ISO 25010.
Надійність (Reliability) включає зрілість, готовність, відмовостійкісь, відновлюваність.
Зрілість (Maturity) — ступінь відповідності системи, продукта або компонента при нормальній роботі вимогам надійності.
Готовність (Availability) — ступінь працездатності і доступності системи, продукта або компонента.
Відмовостійкість (Fault tolerance) — здатність системи, продукта або компонента працювати як призначено, не дивлячись на наявність дефектів програмного забезпечення або апаратних засобів.
Відновлюваність (Revoverability) — здатність продукта або системи відновити дані та необхідний стан системи у випадку переривання або збою.
Основні параметри, які беруть участь у перевірці надійності: імовірність безвідмовної роботи, тривалість безвідмовної роботи, середовище, в якому воно виконується.
Щоб виконати тестування надійності, потрібно: встановити цілі щодо надійності, розробити робочий профіль, спланувати та виконати тести, використовувати результати тестів для прийняття рішень.
Три категорії тестування, які часто використовуються: моделювання, вимірювання, поліпшення.
Моделювання
Значні результати можна отримати, застосовуючи відповідні моделі. Щоб спростити проблеми, можна робити припущення та абстракції, і жодна модель не підійде для всіх ситуацій. Техніку моделювання програмного забезпечення можна розділити на дві підкатегорії: прогнозне моделювання та оціночне моделювання. Прогнозне моделювання використовує історичні дані. Зазвичай воно здійснюється до етапів розробки або тестування. Оціночне моделювання використовує поточні дані розробки програмного забезпечення. Зазвичай використовується пізніше в життєвому циклі розробки програмного забезпечення.
Вимірювання
Для оцінки надійності програмного забезпечення враховується ціла низка факторів. Існує безліч показників, в яких легко заплутатися і рощгубитися. Можна виділити три групи показників для вимірювання надійності: показники продукту, метрики управління проєктом чи процесом, метрики помилок і несправностей.
Якість продукту безпосередньо залежить від організації проєкту та процесу. Показники процесу можна використовувати для оцінки, моніторингу та підвищення надійності та якості програмного забезпечення.
Показники несправностей і збоїв збираються і систематизуються. Ці показники надають можливість розрахувати кількісно низку важливих коефіцієнтів, зокрема і відсоток збоїв, відсоток виправлених/невиправлених дефектів тощо.
До показників продукту відносять:
- Розмір програмного забезпечення : рядок коду (LOC) – це інтуїтивно зрозумілий початковий підхід до вимірювання розміру програмного забезпечення. У цьому показнику враховується лише вихідний код, а коментарі та інші невиконувані оператори не враховуватимуться.
- Метрика функціональна точка (Function Point Metric) є методом вимірювання функціональності розробки програмного забезпечення. Вона враховуватиме кількість входів, виходів, головних файлів тощо. Вона вимірює функціональні можливості, надані користувачеві, і не залежить від мови програмування.
- Показники тестового покриття: це спосіб оцінки несправності та надійності шляхом виконання тестів програмного продукту і розрахунку відповідних показників покриття.
Надійність програмного забезпечення вимірюється середнім часом між відмовами (MTBF – mean time between failures) .
MTBF = MTTF + MTTR
Середнє значення до збою (MTTF – mean time to failures): це різниця в часі між двома послідовними збоями.
Середній час ремонту (MTTR – mean time to repair): це час, необхідний для усунення несправності.
Поліпшення
Поліпшення повністю залежить від проблем, що виникли в програмі чи системі, або ж від характеристик програмного забезпечення. Залежно від складності програмного модуля буде відрізнятися і спосіб поліпшення. Два основних обмеження, час і бюджет, обмежать зусилля, спрямовані на підвищення надійності програмного забезпечення.
Тестування відновлення
Тестування відновлення — це техніка тестування програмного забезпечення, яка перевіряє здатність програмного забезпечення відновлюватися після збоїв, таких як збої програмного/апаратного забезпечення, збої мережі тощо. Мета тестування відновлення — визначити, чи можна продовжувати роботу програмного забезпечення після збою чи втрати цілісності. Тестування відновлення передбачає повернення програмного забезпечення до точки, коли була наявна цілісність (стан, що передував збою), і повторну обробку транзакцій до точки збою.
Час відновлення залежить від: кількості точок перезапуску, обсягу додатків, навчання та навичок людей, які проводять заходи з відновлення і інструментів доступних для відновлення.
Життєвий цикл процесу відновлення можна розділити на такі п’ять етапів:
- Нормальна робота. Система, що складається з апаратного, програмного та мікропрограмного забезпечення, інтегрованого для досягнення мети, є функціональною та працює відповідно до очікувань.
- Виникнення критичної ситуації. Критична ситуація може виникнути з різних причин, як-от несправність, ініційована введенням, збій програмного забезпечення через збій обладнання, пошкодження через техногенну аварію, спробу скоїти злочин (пограбування) тощо.
- Переривання та збій операції. Найболючіша фаза, яка призводить до втрат. Повинен бути план аварійного відновлення, щоб ця фаза збою була мінімальною.
- Усунення наслідків критичної ситуації через процес відновлення. Якщо план резервного копіювання та процеси керування ризиками розроблені і впроваджені, перш ніж зіткнутися з критичною ситуацією та збоями, відновлення можна виконати без особливих втрат часу, зусиль і енергії. Повинна бути відповідальна особа чи команда з розподілом ролей, щоб визначити відповідальність і допомогти організації уникнути тривалого періоду збою.
- Відновлення всіх процесів і інформації для переведення всієї системи в нормальний режим роботи. Може включати кілька сеансів операцій для відновлення всіх папок разом із файлами конфігурації. Для правильного відновлення має бути відповідна документація та чітко структурований процес.
Стратегія відновлення
Команда відновлення повинна мати свою унікальну стратегію для отримання важливого коду та даних, щоб повернути роботу системи до нормального стану.
Стратегія може бути унікальною для кожної організації залежно від критичності систем, з якими вони працюють.
Можливу стратегію для критичних систем можна візуалізувати відповідями на такі питання:
- Чи мати одну резервну копію або більше однієї?
- Чи мати кілька резервних копій в одному місці або в різних місцях?
- Чи резервне копіювання онлайн або резервне копіювання офлайн?
- Чи може резервне копіювання виконуватися автоматично на основі політики чи вручну?
- Чи мати незалежну групу відновлення або внутрішню групу спеціалістів, можна використовувати для відновлення?
В цьому відео поговоримо про тестування надійності:
00:20 Тестування надійності
10:20 Моделювання як категорія тестування
11:18 Вимірювання та поліпшення
15:15 Тестування відновлення