1.4 Тестування програмних модулів

Модуль – найменша одиниця проектування. Для його тестування звичайно використовують методи «білого ящика». Тестуванню підлягають:

• інтерфейс модуля;

• внутрішні структури даних;

• незалежні шляхи;

• шляхи обробки помилок;

• граничні умови.

Інтерфейс модуля тестується для перевірки правильності уведення/виведення тестової інформації. Якщо немає впевненості в правильному уведенні/виведенні, нема рації проводити інші тести.

Дослідження внутрішніх структур даних гарантує цілісність даних, що зберігаються.

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

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

Звичайно при проектуванні модуля передбачають деякі помилкові умови. Для захисту від помилкових умов в модуль вводять шляхи обробки помилок. Тестування шляхів обробки помилок можна орієнтувати на виявлення таких ситуацій:

1. повідомлення про помилку незрозуміло;

2. текст повідомлення не відповідає виявленій помилці;

3. втручання системних засобів реєстрації аварії відбулося до обробки помилки в модулі;

4. обробка виняткової умови некоректна.

Дуже важливе запитання – коли закінчити тестування? На практиці використовують наступний критерій: якщо ймовірність безвідмовної роботи програмного виробу протягом 1000 год. становить щонайменше 0.995, то можна з 95%-ю упевненістю сказати, що проведено достатнє тестування.

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

Драйвер приймає початкові дані і очікувані результати тестових варіантів, запускає в роботу модуль, що підлягає тестуванню, одержує з модуля реальні результати і формує повідомлення про тестування. Драйвери можуть бути різних типів (рис. 2):

• драйвер типу А – тільки викликає підлеглий модуль;

• драйвер типу В – посилає елемент даних (параметр);

• драйвер типу С – відображає параметр із підлеглого модуля;

• драйвер типу D – є комбінацією драйверів В та С.

Рис. 1. Схема тестування модуля

Рис. 2. Типи драйверів

Звичайно використовуються драйвери типу C і D, оскільки вони дозволяють не тільки запускати модуль на виконання, але й одержувати з нього результати виконання тестових варіантів. Драйвери типу А і В можна застосовувати в тих випадках, коли випробуваний модуль має власні засоби виводу інформації про результати тестування.

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

Використовуються такі типи заглушок:

• заглушка типу А – імітує звернення до підлеглого модуля;

• заглушка типу В – здатна прийняти дані, з якими викликається підлеглий модуль;

• заглушка типу С – модулює роботу підлеглого модуля, відповідаючи на виклик передачею деяких фіксованих даних, які модуль, що тестується, використовує як результат виклику підлеглого модуля;

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

Рис. 3. Категорії заглушок