Основні поняття і принципи тестування ПЗ

Тестування — процес виконання програми з метою виявлення помилок. Кроки процесу задаються тестами.

Кожен тест визначає:

q свій набір початкових даних і умов для запуску програми;

q набір очікуваних результатів роботи програми.

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

Хорошим вважають тестовий варіант з високою вірогідністю виявлення ще не розкритої помилки. Успішним називають тест, який виявляє досі не розкриту помилку.

Метою проектування тестових варіантів є систематичне виявлення різних класів помилок при мінімальних витратах часу і вартості.

Важлива відповідь на питання: що може тестування?

Тестування забезпечує:

q виявлення помилок;

q демонстрацію відповідності функцій програми її призначенню;

q демонстрацію реалізації вимог до характеристик програми;

q відображення надійності як індикатора якості програми.

А чого не може тестування? Тестування не може показати відсутності дефектів (воно може показувати тільки присутність дефектів). Важливо пам'ятати це (швидше сумне) твердження при проведенні тестування.

Розглянемо інформаційні потоки процесу тестування. Вони показані на мал. 20.5.

Мал. 20.5 Інформаційні потоки процесу тестування

На вході процесу тестування три потоки:

q текст програми;

q початкові дані для запуску програми;

q очікувані результати.

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

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

q якість і надійність ПЗ задовільні;

q тести не здатні виявляти серйозні помилки.

Нарешті, якщо тести не виявляють помилок, з'являється сумнів в тому, що тестові варіанти досить продумані і що в ПЗ немає прихованих помилок. Такі помилки будуть, зрештою, виявлятися користувачами і коригуватися розробником на етапі супроводу (коли вартість виправлення зростає в 60-100 разів в порівнянні з етапом розробки).

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

Існують 2 принципи тестування програми:

q функціональне тестування (тестування «чорного ящика»);

q структурне тестування (тестування «білого ящика»).

Тестування «чорного ящика»

Відомі: функції програми.

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

Як показано на мал. 20.6, основне місце додатка тестів «чорного ящика» — інтерфейс ПЗ.

Мал. 20.6. Тестування «чорного ящика»

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

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

q як приймаються початкові дані;

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

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

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

Тестування «білого ящика»

Відома: внутрішня структура програми.

Досліджуються: внутрішні елементи програми і зв'язку між ними (мал. 20.7).

Мал. 20.7. Тестування «білого ящика»

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

Класичний процес тестування забезпечує перевірку результатів, отриманих на кожному етапі розробки. Як правило, він розпочинається з тестування в малому, коли перевіряються програмні модулі, триває при перевірці об'єднання модулів в систему і завершується тестуванням у великому, при якому перевіряються відповідність програмного продукту вимогам замовника і його взаємодія з іншими компонентами комп'ютерної системи.

Не нашли, что искали? Воспользуйтесь поиском: