Регресивне тестування
Регресивне тестування (англ. regression testing, від лат. regressio — рух назад) — загальна назва для всіх видів тестування програмного забезпечення, спрямованих на виявлення помилок у вже протестованих ділянках вихідного коду. Такі помилки — коли після внесення змін до програми перестає працювати те, що мало б працювати, — називають регресивними помилками (англ. regression bugs).
Одна з головних цілей регресійного тестування - це визначити, чи впливає зміна в одній частині програмного забезпечення на його інші частини.
Вважається доброю практикою при виправленні помилки створити тест на неї й регулярно проганяти його при подальших змінах програми. Регресивне тестування може бути виконано як вручну так і за допомогою спеціалізованих програм, що дозволяють виконувати всі регресивні тести автоматично. У деяких проектах навіть використовують інструменти для автоматичного прогону регресивних тестів через заданий інтервал часу. Зазвичай це виконується після кожної вдалої компіляції (у невеликих проектах) чи кожну ніч або щотижня.
Регресивне тестування є невіддільною частиною екстремального програмування[джерело?]. У цій методології проектна документація замінюється на розширюване, повторюване й автоматизоване тестування всього програмного пакета на кожній стадії циклу розробки програмного забезпечення.
Регресивне тестування може бути використане не лише для перевірки коректності програми, часто його також застосовують для оцінки якості отриманого результату. Так, під час розробки компіляторів, у прогоні регресивних тестів звертають увагу на час компіляції кожного з тестових прикладів, розмір отриманого коду й швидкість його виконання.[1]
|
Фундаментальна проблема супроводу програм полягає в тому, що виправлення однієї помилки з великою ймовірністю (20-50%) спричиняє появу нової. Тому весь процес йде за принципом «два кроки вперед, один крок назад».
Чому не вдається усувати помилки акуратніше? По-перше, навіть коли дефект виявляє себе як відмова в якомусь одному місці, насправді він часто має розгалуження в усій системі, зазвичай, неочевидні. Будь-яка спроба виправити його мінімальними зусиллями призведе до виправлення локального, але якщо структура є не дуже чіткою або документація не дуже добра, віддалені наслідки цього виправлення залишаться непоміченими. По-друге, помилки зазвичай виправляє не автор програми, а, найчастіше, молодший програміст або стажист. Внаслідок внесення нових помилок супровід програми вимагає значно більше системного налагодження на кожен оператор, ніж у будь-якому іншому виді програмування. Теоретично, після кожного виправлення потрібно прогнати весь набір контрольних прикладів, за якими система перевірялася раніше, щоб переконатися, що вона якимось незрозумілим чином не ушкоджена. На практиці таке зворотне (регресивне) тестування справді має наближатися до цього теоретичного ідеалу й воно дуже дорого коштує. |
|
— Брукс Ф. , Міфічний людино-місяць або як створюються програмні системи. - Пер. з англ. — СПб.: Символ-Плюс, 2001. — 304 стр.: іл. (стор.113-114) | ||
- Автоматичне тестування
- Бета-тестування
- Інтеграційне тестування
- Модульне тестування
- Безперервна інтеграція
- Розробка через тестування
- Система відслідковування помилок
- Системне тестування
- Тестування програмного забезпечення
- Екстремальне програмування
- Юзабіліті-тестування
Що таке регресивне тестування?[недоступне посилання з липня 2019] (англ.)
- ↑ 8 Functional Testing Types Explained With Examples. Insights on Latest Technologies - Simform Blog (амер.). 27 лютого 2019. Процитовано 13 липня 2021.