Тестування "чорної скриньки"

Відомі: функції програми. Досліджується: робота кожної функції на всій області визначення.

Основне місце програми тестів «чорної скриньки» — інтерфейс ПЗ.

Ці тести демонструють:

Як виконуються функції програми.

Як приймаються вихідні дані.

Як виробляються результати.

Як зберігається цілісність зовнішньої інформації.

При тестуванні «чорної скриньки» розглядаються системні характеристики програм, ігнорується їхня внутрішня логічна структура. Вичерпне тестування, як правило, неможливе. Наприклад, якщо в програмі 10 вхідних величин і кожна приймає по 10 значень, то кількість тестових варіантів становитиме 10^10 . Тестування «чорної скриньки» не реагує на багато особливостей програмних помилок.

Тестування «чорної скриньки» (функціональне тестування) дозволяє отримати комбінації вхідних даних, які забезпечують повну перевірку всіх функціональних вимог до програми. Програмний виріб тут розглядається як «чорна скринька», чию поведінку можна визначити тільки дослідженням його входів та відповідних виходів. При такому підході бажано мати:

Набір, утворений такими вхідними даними, які призводять до аномалій у поведінці програми (назвемо його IT);

Набір, утворений такими вхідними даними, які демонструють дефекти програми (назвемо його OT).

Будь-який спосіб тестування «чорної скриньки» повинен:

Виявити такі вхідні дані, які з високою ймовірністю належать набору IT;

Сформулювати такі очікувані результати, які з високою імовірністю є елементами набору OT.

Принцип «чорної скриньки» не альтернативний принципу «білої скриньки». Скоріше це доповнює підхід, який виявляє інший клас помилок.

Тестування «чорної скриньки» забезпечує пошук наступних категорій помилок:

Некоректних чи відсутніх функцій;

Помилок інтерфейсу;

Помилок у зовнішніх структурах даних або в доступі до зовнішньої бази даних;

Помилок характеристик (необхідна ємність пам'яті і т.д.);

Помилок ініціалізації та завершення.

Подібні категорії помилок способами «білої скриньки» не виявляються.

За часом проведення тестів

Альфа-тестування — імітація реальної роботи з системою штатними розробниками або реальна робота з системою потенційними користувачами/замовником. Найчастіше альфа-тестування проводиться на ранній стадії розробки продукту, але у деяких випадках може застосовуватися для закінченого продукту як внутрішнього приймального тестування. Іноді альфа-тестування виконується під відлагоджувачем або з використанням середовища, яке допомагає швидко виявляти знайдені помилки. Виявлені помилки можуть бути передані тестувальникам для додаткового дослідження у середовищі, подібному тому, в якому буде використовуватися програма.

Бета-тестування — у деяких випадках виконується поширення версії з обмеженнями (за функціональністю або часом роботи) для певної групи осіб, з тим щоб переконатися, що продукт містить достатньо мало помилок. Іноді бета-тестування виконується для того, щоб отримати зворотній зв'язок про продукт від його майбутніх користувачів.

SDLC – Software development life cycle

Каскадна модель

Першою моделлю, що отримала широку популярність і дійсно структурний процес розробки, є каскадна або водоспадна. Вона була створена після минулої в 1968 р конференції NATO з питань науки і техніки, де розглядалися подібні питання, і розділяє процес створення програмного продукту на послідовні етапи (слід зазначити, що вона вже застосовувалася тоді різними розробниками, однак ні кількість, ні зміст етапів не уніфіковані).

Модифікована каскадна модель передбачала можливість повернення до попередніх етапів Через нетривалий час після своєї появи на світ каскадная модель була доопрацьована Уінстом Ройсом з урахуванням взаємозалежності етапів і необхідність повернення на попередні щаблі, що може бути викликано, наприклад, неповнотою вимог або помилками в формуванні завдання. У такому «обратимом» вигляді каскадная модель проіснувала довгий час і з'явилася основою для багатьох проектів Однак практичне використання даної моделі виявило безліч її недоліків, головний з яких полягав у тому, що вона більше підходить для традиційних видів інженерної діяльності, ніж для розробки ПЗ. Зокрема, однією з найбільших проблем виявилася її «схильність» до можливих невідповідностям отриманого в результаті продукту і вимог, які до нього пред'являлися. Основна причина цього полягає в тому, що повністю сформований продукт з'являється лише на пізніх етапах розробки, але так як роботу на різних етапах зазвичай виконували різні фахівці і проект передавався від однієї групи до іншої, то за принципом зіпсованого телефону чинився так, що на виході виходило не зовсім те, що передбачалося спочатку.

V-подібна модель

Рис. V-подібна модель дозволяє набагато краще контролювати результат на предмет його відповідності очікуванням, оскільки сфокусована на тестуванні

Була запропонована саме для того, щоб усунути недоліки каскадної моделі, а назва - V-образна, або шарнирная - з'явилося через її специфічного графічного представлення V-подібна модель дала можливість значно підвищити якість ПО за рахунок своєї орієнтації на тестування, а також багато в чому дозволила проблему відповідності створеного продукту висунутим вимогам завдяки процедурам верифікації та атестації на ранніх стадіях розробки (пунктирні лінії на малюнку вказують на залежність етапів планування / постановки задачі та тестування / приймання). Проте в цілому V-подібна модель є всього лише модифікацією каскадної і володіє багатьма її недоліками. Зокрема, і та і інша слабо пристосовані до можливих змін вимог замовника. Якщо процес розробки займає тривалий час (іноді до декількох років), то отриманий в результаті продукт може виявитися фактично непотрібним замовнику, оскільки його потреби істотно змінилися. У тій же мірі актуальне і питання впливу науково-технічного прогресу: вимоги до ПЗ висуваються з урахуванням поточного стану наукових і практичних досягнень в області апаратно-програмного забезпечення, однак IТ-сфера розвивається дуже швидко, і тривалий процес розробки здатний привести до створення продукту, який базується на застарілих технологіях і виявляється неконкурентоспроможним ще до своєї появи. Важливе також питання планування показників очікуваної функціональності, оскільки в цих моделях він є не більш ніж припущенням: зокрема, визначити, яку швидкість обробки даних забезпечить створюваний продукт або скільки він буде займати пам'яті, на етапі постановки задачі практично неможливо. Якщо подібні вимоги чітко зафіксовані в умовах договору між замовником і виконавцем, то цілком імовірно, що отримане рішення не буде їм задовольняти, хоча відомо це стане тільки на завершальних етапах розробки, коли основні ресурси вже витрачені.

Ітеративна модель

ПЗ на відміну, наприклад, від мікросхеми можна вводити в експлуатацію по частинам, а значить, розробляти і поставляти його замовнику також можна поступово. Саме на цьому заснована ітеративна або інкрементна модель, що передбачає дроблення продукту на відносно незалежні складові, які розробляються і вводяться в експлуатацію окремо. Така модель вигідна як для замовника, так і для творця системи, оскільки дозволяє просуватися вперед, дотримуючись інтересів обох сторін. Однак у неї є свої недоліки. Ділення на функціональні блоки в цілому уповільнює процес, так як виникає необхідність забезпечення їх взаємодії. Для багатьох рішень цей метод непридатний, оскільки з них не можна вичленувати окремі складові, які можуть бути поставлені і функціонувати незалежно. Істотно зростає навантаження і на керівний персонал у зв'язку з ускладненням завдань з координування робіт над окремими складовими системи, збільшується вартість внесення змін до готові компоненти, які вже встановлені і працюють у замовника.

Спіральна модель

Рис. Спіральна модель Боема об'єднує каскадний підхід і ітераційний процес проектування на основі створення прототипів

Запропонована Баррі Боем в 1988 р, вона стала суттєвим проривом у розумінні природи розробки ПО, хоча, за великим рахунком, є об'єднанням двох моделей: каскадної і на основі створення прототипів Спіральна модель Боема сфокусована на проектуванні. Власне розробка ПО відбувається лише на останньому витку спіралі за звичайною каскадної моделі, однак цьому передує кілька ітерацій проектування на основі створення прототипів - при цьому кожна ітерація включає стадію виявлення й аналізу ризиків і найбільш складних завдань. Оскільки спіральна модель в основному охоплює саме проектування, то в первісному вигляді вона не отримала широкого розповсюдження в якості методу управління всім життєвим циклом створення ПЗ. Однак головна її ідея, що полягає в тому, що процес роботи над проектом може складатися з циклів, що проходять одні й ті ж етапи, послужила вихідним пунктом для подальших досліджень і стала основою більшості сучасних моделей процесу розробки ПЗ. У підсумку замовник буде змушений або миритися з обмеженнями створеного на основі розглянутих моделей рішення, або додатково інвестувати кошти, щоб отримати дійсно те, що необхідно.