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

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

Тестування якості ПЗ. Метою тестування є пошук порушень вимог якості, сформульованих в специфікації якості ПЗ. Це найбільш важкий і найменш вивчений вид тестування. Ясно лише, що далеко не кожен примітив якості ПЗ може бути випробуваний тестуванням (про оцінку якості ПЗ див. наступну лекцію). Завершеність ПЗ перевіряється вже при тестуванні зовнішніх функцій. На даному етапі тестування цього примітиву якості може бути продовжене якщо потрібно отримати яку-небудь імовірнісну оцінку ступеня надійності ПЗ. Проте, методика такого тестування ще вимагає своєї розробки. Точність, стійкість, захищеність, тимчасова ефективність, в якійсь мірі - ефективність по пам'яті, ефективність по пристроях, розширюваність і, частково, незалежність від пристроїв можуть тестуватися. Кожен з цих видів тестування має свою специфіку і заслуговує окремого розгляду. Ми тут обмежимося лише їх перерахуванням. Легкість застосування ПЗ (критерій якості, що включає декілька примітивів якості, див. лекцію 4) оцінюється при тестуванні документації по застосуванню ПЗ.

Тестування документації по застосуванню ПЗ. Метою тестування є пошук неузгодженості документації по застосуванню і сукупністю програм ПЗ, а також незручностей застосування ПЗ. Цей етап безпосередньо передує підключенню користувача до завершення розробки ПЗ (тестуванню вимог до ПЗ і атестацій ПЗ), тому вельми важливо розробникам спочатку самим скористатися ПЗ так, як це робитиме користувач [10.1]. Всі тести на цьому етапі готуються виключно на підставі тільки документації по застосуванню ПЗ. Перш за все, повинні тестуватися можливості ПЗ як це робилося при тестуванні зовнішніх функцій, але тільки на підставі документації по застосуванню. Повинні бути протестовані всі неясні місця в документацію, а також всі приклади, використані в документації. Далі тестуються найбільш важкі випадки застосування ПЗ з метою виявити порушення вимог відносності легкості застосування ПЗ.

Тестування визначення вимог до ПЗ. Метою тестування є з'ясування, якою мірою ПЗ не відповідає пред'явленому визначенню вимог до нього. Особливість цього виду тестування полягає в тому, що його здійснює організація-покупець або організація-користувач ПЗ [10.1] як один з шляхів подолання бар'єру між розробником і користувачем (див. лекцію 3). Звичайне це тестування проводиться за допомогою контрольних завдань - типових задах, для яких відомий результат рішення. У тих випадках, коли ПЗ, що розробляється, винне придти на зміну іншому варіанту ПЗ, який вирішує хоч би частину завдань ПЗ, що розробляється, тестування проводиться шляхом вирішення загальних завдань за допомогою як старого, так і нового ПЗ з подальшим зіставленням отриманих результатів. Іноді як форма такого тестування використовують дослідну експлуатацію ПЗ - обмежене застосування нового ПЗ з аналізом використання результатів в практичній діяльності. По-существу, цей вид тестування багато в чому перекликається з випробуванням ПЗ при його атестації (див. лекцію 14), але виконується до атестації, а іноді і замість атестації.

3. Організація процесу тестування ПЗ

Процес тестування об'єднує різні способи тестування в сплановану послідовність кроків, які приводять до успішної побудови програмної системи (ПС) [3] [13] [64] [69]. Методика тестування ПС може бути представлена у вигляді спіралі, що розгортається (мал. 8.1).

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

86

Лекція 8. Тестування і відлагодження програмного засобу помилок етапу проектування ПС. На третьому обороті спіралі проводиться тестування

правильності, перевіряюче коректність етапу аналізу вимог до ПС. На завершальному витку спіралі проводиться системне тестування, що виявляє дефекти етапу системного аналізу ПС.

Охарактеризуємо кожен крок процесу тестування.

1. Тестування елементів. Мета — індивідуальна перевірка кожного модуля. Використовуються способи тестування «білого ящика».

Мал. 8.1. Спіраль процесу тестування ПС

2.Тестування інтеграції. Мета — тестування збірки модулів в програмну систему. В основному застосовують способи тестування «чорного ящика».

3.Тестування правильності. Мета — перевірити реалізацію в програмній системі всіх

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

4. Системне тестування. Мета — перевірка правильності об'єднання і взаємодії всіх елементів комп'ютерної системи, реалізації всіх системних функцій.

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

На практиці зазвичай застосовують статистичний критерій: «Можна з 95%-ю впевненістю сказати, що проведено достатнє тестування, якщо вірогідність безвідмовної роботи ПП протягом 1000 годин складає щонайменше 0,995».

Науковий підхід при відповіді на це питання полягає в застосуванні математичної моделі відмов. Наприклад, для логарифмічної моделі Пуассона формула розрахунку поточної інтенсивності відмов має вигляд:

λ0 — початкова інтенсивність відмов (на початку тестування); р — експоненціальне зменшення

інтенсивності відмов за рахунок помилок, що виявляються і усуваються; t — тривалість тестування. За допомогою рівняння (8.1) можна передбачити зниження помилок в ході тестування, а також

час, потрібний для досягнення допустимо низької інтенсивності відмов.

3.1. Тестування елементів

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

інтерфейс модуля; внутрішні структури даних;

незалежні шляхи передачі даних; шляхи обробки помилок; граничні умови.

87

Лекція 8. Тестування і відлагодження програмного засобу Інтерфейс модуля тестується для перевірки правильності введення-виводу тестової інформації.

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

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

Найбільш загальними помилками обчислень є:

неправильний або такий, що не зрозумів пріоритет арифметичних операцій; змішана форма операцій; некоректна ініціалізація;

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

Джерелами помилок порівняння і неправильних потоків управління є: порівняння різних типів даних; некоректні логічні операції і пріоритетність;

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

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

Тестування шляхів обробки помилок можна орієнтувати на наступні ситуації:

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

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

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

4)обробка виняткової ситуації є некоректна;

5)опис помилки не дозволяє визначити її причину.

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

1)при обробці n-го елементу n-елементного масиву;

2)при виконанні m-ї ітерації циклу з т проходами;

3)при появі мінімального (максимального) значення.

Тестові варіанти, орієнтовані на дані ситуації, мають високу вірогідність виявлення помилок.

Тестування елементів зазвичай розглядається як доповнення до етапу кодування. Воно починається після розробки тексту модуля. Оскільки модуль не є автономною системою, то для реалізації тестування потрібні додаткові засоби, представлені на мал. 8.2.

Мал. 8.2. Програмне середовище для тестування модуля

88

Лекція 8. Тестування і відлагодження програмного засобу

Додатковими засобами є драйвер тестування і заглушки. Драйвер — програма, що управляє, яка приймає початкові дані (InData) і очікувані результати (ExpRes) тестових варіантів, запускає в роботу тестований модуль, отримує з модуля реальні результати (OutData) і формує донесення про тестування. Алгоритм роботи тестового драйвера приведений на мал. 8.3.

Мал. 8.3. Алгоритм роботи драйвера тестування

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

Створення драйвера і заглушок має на увазі додаткові витрати, оскільки вони не поставляються з кінцевим програмним продуктом.

Якщо ці засоби прості, то додаткові витрати невеликі. На жаль, багато модулів не можуть бути адекватно протестовані за допомогою простих додаткових засобів. У цих випадках повне тестування може бути відкладене до кроку тестування інтеграції (де драйвери або заглушки також використовуються).

89