Тестування підтримки (Maintenance testing)
Супровід (maintenance): Модифікація програмного продукту після його постачання з метою виправлення дефектів, поліпшення продуктивності або інших характеристик або для адаптації продукту до оточення, що змінилося. (IEEE 1219)
Супроводжуваність (maintainability): Легкість зміни програмного продукту для виправлення дефектів, для відповідності новим вимогам, з метою полегшення наступного супроводу або для адаптації до оточення, що змінилося. (ІSO 9126)
Тестування супровідності (maintainability testing): Тип тестування, що проводиться для оцінки ступеня ефективності та продуктивності можливих змін елемента тестування. (ГОСТ 56920)
Maintenance є останньою стадією SDLC. На думку багатьох експертів, у міру того, як зміни після релізу вносяться в існуючу програму, кожна зміна може розглядатися як початок нового циклу SDLC, але точніше буде сказати, що проект в цей час знаходиться в життєвому циклі обслуговування програмного забезпечення (SMLC - Software Maintenance Life Cycle). Багато проектів проводять більшу частину свого часу саме в SMLC після релізу, а не в SDLC перед ним.
Maintenance testing(тестування підтримки/обслуговування/експлуатації/супроводу) - це модифікація програмного продукту після його випуску з метою виправлення дефектів, поліпшення продуктивності або інших характеристик або для адаптації продукту до оточення, що змінилося. (IEEE 1219). Після того, як програмне забезпечення або програма задеплоєна, вона починає експлуатуватися роками і навіть десятиліттями. У цей час система та її операційне середовище часто виправляються, змінюються чи розширюються. Користувач може потребувати деяких доданих або нових функцій у поточному програмному забезпеченні, які вимагають внесення змін до поточного програмного забезпечення, і ці зміни повинні бути протестовані. Кінцевим користувачам може знадобитися міграція програмного забезпечення на іншу останню апаратну платформу або зміну середовища, наприклад версії ОС, варіанти бази даних і т. д., що вимагає тестування всієї програми на нових платформах і в новому середовищі. Після того, як продукт релізується, він іноді вимагає деякого обслуговування з метою профілактики збоїв.
Основні активності (principal activities):
Динамічне обслуговування (Dynamic maintenance)
Коригування (Corrective maintenance)
Адаптивне обслуговування (Adaptive maintenance)
Завдання виконання Maintenance testing стає ефективнішим, коли програмне забезпечення має хорошу характеристику обслуживаемости (maintainability).
Reliability, maintainability в ISO 9126 визначається як "легкість, з якою програмний продукт може бути змінений для виправлення дефектів, модифікований для відповідності новим вимогам, модифікований для полегшення майбутнього обслуговування або адаптований до середовища".
Maintainability складається з:
Аналізованість: це стосується зусиль, необхідних (зазвичай розробниками) для діагностики дефектів або виявлення частин програмної системи, що потребують змін;
Змінність: це стосується зусиль, необхідних для фактичного виправлення дефектів або внесення вдосконалень;
Стабільність: ймовірність виникнення непередбачених побічних ефектів внаслідок внесення змін до програмного забезпечення. Це те, що ми маємо на увазі, коли іноді говоримо, що програмне забезпечення тендітне (brittle);
Тестування: описує зусилля, необхідні тестування зміненого програмного забезпечення. Це один із основних атрибутів якості програмного забезпечення, який безпосередньо впливає на нашу роботу;
Причини поганої Maintainability:
Основні ризики (Maintainability Risks)
Наслідки
Зусилля, необхідні для виправлення дефектів та внесення змін, можуть бути більшими, ніж планувалося
Якщо розмір групи підтримки (maintenance team), яка виконує ці завдання, буде фіксованою (звичайна ситуація), це також призведе до збільшення часових витрат
Час, що витрачається завдання обслуговування, перевищує фіксовані вікна обслуговування (maintenance windows)
Це може негативно позначитися на виробництві (наприклад, співробітники, які прибувають на роботу, виявляють, що сервер додатків недоступний через прослизання вікна планового нічного обслуговування)
Підтримка (Maintainers) можуть бути змушені скорочувати терміни, щоб не виходити за межі погоджених періодів обслуговування. Їм може знадобитися зробити припущення щодо реалізації необхідних змін (можливо через погану документацію)
Якщо застосовуються Угоди про рівень обслуговування, можуть накладатися штрафи
Довгострокове накопичення поганої підтримуваності внаслідок кумулятивного ефекту поганої практики розробки програмного забезпечення
Рівень надійності поступово знижується
Збільшується кількість функціональних дефектів, що вносяться до змін (регресії)
На виправлення дефектів потрібно більше часу
На персонал підтримки чиниться дедалі більший тиск, що може навіть призвести до подальшого погіршення ситуації.
Види Maintenance testing :
Підтвердження тестування (Confirmation Maintenance Testing): тестування зміненої функціональності. Ви повинні ретельно протестувати всі модифікації (невеликі або великі), внесені в програмне забезпечення, і переконатися, що немає проблем із функціональністю та простоїв. Тестове середовище має бути копією реального середовища разом із тестовими даними;
Регресійне тестування (Regression Maintenance Testing): тестування існуючої функціональності щодо регресії. Це робиться після фази підтвердження тестування. Ви повинні протестувати всю систему, щоб переконатися, що змінена функціональність (роботи з обслуговування) не повинна впливати на функціональність наявного програмного забезпечення;
Для підтримуючого релізу (maintenance release) може знадобитися підтримуюче тестування на кількох рівнях тестування з використанням різних типів тестів залежно від його обсягу. Обсяг технічного обслуговування залежить від :
Ступінь ризику зміни, наприклад, ступінь, в якому змінена область програмного забезпечення спілкується з іншими компонентами або системами;
розмір існуючої системи;
розмір зміни;
Тригери для Maintenance . Існує кілька причин, з яких проводиться обслуговування програмного забезпечення, а значить, і тестування обслуговування як для запланованих, так і для незапланованих змін. Ми можемо класифікувати тригери для обслуговування наступним чином:
Модифікації, такі як заплановані покращення (наприклад, на основі випуску), коригувальні та термінові зміни, зміни операційного середовища (наприклад, планові оновлення операційної системи або бази даних), оновлення програмного забезпечення COTS та виправлення для дефектів та вразливостей;
Міграція, наприклад, з однієї платформи на іншу, яка може вимагати операційних тестів нового середовища, а також зміненого програмного забезпечення, або тестів перетворення даних, коли дані з іншої програми будуть перенесені до системи, що підтримується;
Виведення з експлуатації, наприклад, коли термін підтримки програми добігає кінця. Коли програма або система виводяться з експлуатації, це може зажадати тестування міграції або архівування даних, якщо потрібні тривалі періоди зберігання даних;
Також може знадобитися тестування процедур відновлення/вилучення після архівування протягом тривалого періоду зберігання;
Регресійне тестування може знадобитися, щоб переконатися, що всі функціональні можливості, які залишаються в експлуатації, як і раніше, працюють;
Наприклад, для систем Інтернету речей (IoT) тестування обслуговування може бути ініційоване введенням у загальну систему нових або модифікованих речей, таких як апаратні пристрої та програмні послуги. При тестуванні обслуговування таких систем особлива увага приділяється інтеграційному тестуванню на різних рівнях (наприклад, рівень мережі, рівень додатків) та аспектам безпеки, зокрема тим, що належать до персональних даних.
Impact Analysis для Maintenance. Аналіз впливу оцінює зміни, які були внесені до підтримуючої версії, щоб визначити передбачувані наслідки, а також очікувані та можливі побічні ефекти (side effects) зміни, а також визначити області у системі, на які ця зміна вплине. Аналіз впливу також допоможе визначити вплив зміни на існуючі тести. Побічні ефекти та порушені області у системі необхідно протестувати щодо регресії, можливо, після оновлення будь-яких існуючих тестів, порушених зміною. Аналіз впливу може бути проведений до внесення зміни, щоб допомогти вирішити, чи слід вносити зміну, виходячи з можливих наслідків інших областях системи.
Джерела:
Дод. матеріал:
Last updated