РОЗДІЛ 1. АНАЛІЗ ПРОБЛЕМ ПРОЦЕСУ ТЕСТУВАННЯ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ
Програмні продукти демонструють стійку тенденцію до зростання і ускладнення. Це природно - продукти розвиваються, в них зявляються нові функції і можливості. Але при цьому зростає також складність самих продуктів, взаємозвязків їх компонентів і підсистем, інтеграція з іншими додатками. Все це створює значну ймовірність виникнення дефектів в програмному забезпечені.
Тому зараз тестування є неодмінною умовою успішного функціонування як для гігантів індустрії таких як Google, Microsoft, IBM чи Oracle, так і для розробників програмного забезпечення "під замовлення".
Тестування програмного забезпечення складається з різних випробувань, через які повинен пройти програмного продукту і включає різні види діяльності, повязані з контролем його якості.
Тестування не є самостійною активністю. Воно має своє визначене місце у моделі життєвого циклу розробки продукту і саме ця модель має найбільший вплив на те, як процес тестування буде організовано. Від моделі залежить що і коли повинно бути перевірено, обєм регресійного тестування, визначає які техніки тестування буде використано та багато іншого.
Індустрія програмного забезпечення розвивається стрімкими темпами і сьогодні моделей життєвого циклу і їх варіацій існує досить багато. Класичними вважаються - каскадна, V- модель і ітеративна. Найпопулярнішими ж сьогодні є гнучкі модель розробки.
Каскадна модель або «водоспад»
Найраніша модель розробки ПЗ, запропонована 1970 році Уінстоном Ройсом. Вона передбачає послідовне виконання всіх етапів проекту в чітко фіксованому порядку рис.1.1. Перехід на наступний етап означає повне завершення робіт на попередньому. Вимоги, визначені на стадії формування вимог, суворо документуються у вигляді технічного завдання і фіксуються на весь час розробки проекту. Кожна стадія завершується випуском повного комплекту документації, достатньої для того, щоб розробка могла бути продовжена іншою командою розробників.
Рис. 1.1 Каскадна модель або «водоспад»
Тестування у каскадній моделі розробки
Місце тестування у моделі «водоспад» є перед завершенням життєвого циклу проекту, тобто дефекти становляться виявленими близько до дати випуску продукту на ринок. Відомо, що вартість виправлення дефектів знайдених у кінці проекту набагато більша, ніж на ранніх етапах рис.1.2. Найкритичнішою є ситуація, коли дефект знайдений у специфікації, що вертає розробку на початкову фазу. Інколи такі проекти стає вигіднішим закрити, чим починати розробку з початку.
Рис. 1.2 Ціна виправлення дефекту на різних етапах розробки ПО
V- модель
Рис. 1.3 V- модель
V-модель була розроблена для вирішення деяких проблем, актуальних для традиційного «водоспаду»: виявлення дефектів на пізніх етапах життєвого циклу розробки продукту. Пізнє підключення тестування також призводить до збільшення затрат часу на нього. V-модель забезпечує механізм залучення тестування якомога раніше у життєвому циклі.
V-модель демонструє як перевірка (верифікація і валідація) може бути інтегрована у кожний етап життєвого циклу рис.1.3.
Активності з тестування не обмежуються лише безпосереднім виконанням тестів. Є цілий ряд заходів, які повинні бути виконані до кінця фази написання коду. Ці заходи повинні проводитися паралельно з кодуванням, і спеціалісти з тестування повинні співпрацювати на цих етапах із розробниками і бізнес-аналітиками. Почавши дизайн тестів рано, працівники галузі тестування виявляють дефекти у специфікаціях та інших вхідних для них документах, тим самим попереджуючи перенесеннях цих помилок у код.
У V-моделі перевірочні випробування відбувається починаючи з ранніх етапів, наприклад, огляд потреб користувачів, і закінчується у кінці життєвого циклу, наприклад, під час приймальних випробувань.
Ітеративна модель
Ітеративний підхід означає розробку малого ядра, на яке пізніше нарощується інша функціональність. Замість тривалої послідовної розробки від початку до завершення продукту існує цикл певного числа самостійних ітерацій рис.1.4. Результатом кожної ітерації є продукт, що містить частку функціональності кінцевого продукту.
Перевагами такого підходу є більш короткий час до виходу на ринок та можливість швидко внести зміни, якщо потреби замовника змінились.
Рис. 1.4 Ітеративна модель
Тестування у ітеративній моделі
Послідовність ітерації зумовлює - тестування нового функціоналу, регресійне тестування існуючого (перевірка, що внесені зміни не задали негативного впливу на інші області програми) та інтеграційне тестування між новою та існуючою частинами.
Регресійне тестування є важливим для кожної ітерації після першої. З цього випливає, що обєм тестування для кожної наступної фази буде збільшуватись.
Гнучка розробка
Гнучка розробка бере за основу ітеративний підхід, але зумовлює більш «легкий» та більш орієнтований на людські ресурси механізм. Гнучкі процеси використовують зворотній звязок замість планування як основний механізм контролю. Зворотній звязок гарантується частими тестами і раннім релізом продукту, що є в розробці. Найпопулярнішими варіаціями гнучких моделей є Екстремальне програмування(XP) і Scrum.
Тестування у гнучкій розробці
Гнучка розробка часто використовує підхід розробки через тести - це підхід, який зумовлює спочатку написання автоматичних модульних тестів, своєрідних прикладів, а потім написання коду безпосередньо.
Гнучка розробка завжди включає велику кількість ітерацій, кожна з яких потребує тестування. Тестування включає як повторний «прогін» автоматичних тестів, що були створені на стадії написанням коду (активність за яку відповідають зазвичай самі розробники), так і незалежне тестування командою тестування або сторонньою організацію або самим замовником.
Таким чином, активності по тестуванню є різноманітними і проходять на різних стадіях життєвого циклу розробки ПЗ. Моделі, що є широко вживаними сьогодні зумовлюють залучення тестування якомога раніше і передбачають на кожну активність команди розробки відповідну активність команди тестування.
- РОЗДІЛ 1. АНАЛІЗ ПРОБЛЕМ ПРОЦЕСУ ТЕСТУВАННЯ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ
- 1.1 Звязок між тестування і забезпеченням якості
- 1.2 Аналіз процесу тестування програмного забезпечення
- 1.3 Автоматизація процесу тестування програмного забезпечення
- 1.4 Аналіз переваг автоматичного тестування
- 1.5 Аналіз недоліків автоматичного тестування
- 1.6 Обґрунтування генерації тестів як більш ефективного підходу
- 1.7 Аналіз процесу ручного створення функціональних тестів
- Розділ 2 Функціональне тестування програмного забезпечення
- 1. Основні теоретичні відомості конструювання програмного забезпечення.
- 9.4.Моделі життєвого циклу програмного забезпечення іс
- Тестування програмного забезпечення
- §1 Автоматизація діловодних процесів
- Призначення тестування програмного забезпечення.
- 1. Процес тестування програмного забезпечення
- 1.5.1 Тестування програмного забезпечення та його компонент