Розділ 2 Функціональне тестування програмного забезпечення

Лекція 1 (2 години)

Тема: Особливості тестування „чорного ящика ”. Способи тестування: розбиття по еквівалентності, аналіз граничних значень

Основні поняття тестування „чорного ящика”.

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

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

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

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

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

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

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

Спосіб розбиття по еквівалентності

Розбиття по еквівалентності - найпопулярніший спосіб тестування «чорного ящика» .

У цьому способі вхідна область дані програми ділиться на класи еквівалентності. Для кожного класу еквівалентності розробляється один тестовий варіант.

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

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

Наприклад, якщо специфікація задає в якості припустимих вхідних величин 5-розрядні цілі числа в діапазоні 15 000...70 000, то клас еквівалентності припустимих ВД (вихідних даних) включає величини від 15 000 до 70 000, а два класи еквівалентності неприпустимих ВД становлять:

- числа менші, ніж 15 000;

- числа більші, ніж 70 000.

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

Умова уведення може задавати:

1) певне значення;

2) діапазон значень;

3) множину конкретних величин;

4) бульову умову.

Сформулюємо правила формування класів еквівалентності.

1. Якщо умова введення задає діапазон n...m, то визначаються один припустимий і два неприпустимих класи еквівалентності:

- V_Class={n.. .т} — припустимий клас еквівалентності;

- Inv_С1аss1={x|для будь-якого х: х < п} — перший неприпустимий клас еквівалентності;

- Inv_С1аss2={y|для кожного в: в > т} — другий неприпустимий клас еквівалентності.

2. Якщо умова введення задає конкретне значення а, то визначається один припустимий і два неприпустимих класи еквівалентності:

- V_Class={a};

- Inv_Class1 ={х|для будь-якого х: х < а};

- Inv_С1аss2={y|для кожного в: в > а}.

3. Якщо умова введення задає множину значень {а, b, с}, то визначаються один припустимий і один неприпустимий клас еквівалентності:

- V_Class={a, b, с};

- Inv_С1аss={x|для будь-якого х: (х а)&(х b)&(х с) }.

4. Якщо умова введення задає бульове значення, наприклад true, то визначаються один припустимий і один неприпустимий клас еквівалентності:

- V_Class={true};

- Inv_Class={false}.

Після побудови класів еквівалентності розробляються тестові варіанти. Тестовий варіант вибирається так, щоб перевірити відразу найбільшу кількість властивостей класу еквівалентності.

Спосіб аналізу граничних значень

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

Основні відмінності аналізу граничних значень від розбиття по еквівалентності:

1) тестові варіанти створюються для перевірки тільки ребер класів еквівалентності;

2) при створенні тестових варіантів враховують не тільки умови введення, але й область виводу.

Сформулюємо правила аналізу граничних значень.

1. Якщо умова введення задає діапазон п... т, то тестові варіанти повинні бути побудовані:

- для значень n и m;

- для значень трохи лівіше від n і трохи правіше m на числовій осі.

Наприклад, якщо задано вхідний діапазон -1,0...+1,0, то створюються тести для значень - 1,0, +1,0, - 1,001, +1,001.

2. Якщо умова введення задає дискретну множину значень, то створюються тестові варіанти:

- для перевірки мінімального й максимального значень;

- для значень, що трохи менші мінімуму й трохи більші максимуму.

Так, якщо вхідний файл може містити від 1 до 255 записів, то створюються тести для 0, 1, 255, 256 записів.

3. Правила 1 і 2 застосовуються до умов області виводу.

Розглянемо приклад, коли в програмі потрібно виводити таблицю значень. Кількість рядків і стовпців у таблиці міняється. Задається тестовий варіант для мінімального висновку (по об'єму таблиці), а також тестовий варіант для максимального висновку (по об'єму таблиці).

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

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

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

Лекція 2 (2 години)

Тема: Методика тестування програмних систем

Процес тестування поєднує різні способи тестування в сплановану послідовність кроків, які приводять до успішної побудови програмної системи (ПС) . Методика тестування ПС може бути представлена у вигляді спіралі, що розвертається (мал. 2.2.1).

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

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

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

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

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

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

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

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

Методики тестування відповідно до цілей тестування

Тестування проводиться відповідно до певних цілей (можуть бути задані явно або неявно) і різним рівнем точності. Визначення мети точним чином, що виражається кількісно, дозволяє забезпечити контроль результатів тестування.

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

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

Установочне тестування. З назви видно, що дані тести проводяться з метою перевірки процедури інсталяції системи в цільовому оточенні.

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

Функціональні тести/тести відповідності. Ці тести можуть називатися по різному, однак, їхня суть проста - перевірка відповідності системи поставленим до неї вимогам, описаним на рівні специфікації поведінкових характеристик.

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

Регресійне тестування. Визначення успішності регресійних тестів говорить: “повторне вибіркове тестування системи або компонентів для перевірки зроблених модифікацій не повинне приводити до непередбачених ефектів”. На практиці це означає, що якщо система успішно проходила тести до внесення модифікацій, вона повинна їх проходить і після внесення таких. Основна проблема регресійного тестування полягає в пошуку компромісу між тими ресурсами, які є, й необхідністю проведення таких тестів у міру внесення кожної зміни. Деякою мірою, завдання полягає в тім, щоб визначити критерії “масштабів” змін, з досягненням яких необхідно проводити регресійні тести.

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

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

Порівняльне тестування. Одиничний набір тестів, що дозволяють зрівняти дві версії системи.

Відновлювальні тести. Мета - перевірка можливостей рестарту системи у випадку непередбаченої катастрофи, що впливає на функціонування операційного середовища, у якій виконується система.

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

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

Лекція 3 (2 години)

Тема: Тестування інтеграцій. Тестування правильності

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

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

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

Тести проводяться для виявлення помилок інтерфейсу. Перелічимо деякі категорії помилок інтерфейсу:

- втрата даних при проходженні через інтерфейс;

- відсутність у модулі необхідного посилання;

- несприятливий вплив одного модуля на іншій;

- підфункції при об'єднанні не утворять необхідну головну функцію;

- окремі (припустимі) неточності при інтеграції виходять за припустимий рівень;

проблеми при роботі із глобальними структурами даних.

Існує два варіанти тестування, що підтримують процес інтеграції: низхідне тестування й висхідне тестування. Розглянемо кожний з них.

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

Опишемо можливі кроки процесу низхідної інтеграції.

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

2. Одна із заглушок заміняється реальним модулем. Модуль вибирається пошуком в ширину або в глибину.

3. Після підключення кожного модуля (і установки на ньому заглушок) проводиться набір тестів, що перевіряють отриману структуру.

4. Якщо в модулі-драйвері вже немає заглушок, виконується зміна модуля-драйвера (пошуком в ширину або в глибину).

5. Виконується повернення на крок 2 (доти, поки не буде побудована ціла структура).

Достоїнство спадної інтеграції: помилки в головній, керуючій частині системи виявляються в першу чергу.

Недолік: труднощі в ситуаціях, коли для повного тестування на верхніх рівнях потрібні результати обробки з нижніх рівнів ієрархії.

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

1. Модулі нижнього рівня поєднуються в кластери (групи, блоки), що виконують певну програмну підфункцію.

2. Для координації вводів-виводів тестового варіанта пишеться драйвер, що керує тестуванням кластерів.

3. Тестується кластер.

4. Драйвери видаляються, а кластери поєднуються в структуру рухом нагору.

При проведенні тестування інтеграції дуже важливо виявити критичні модулі. Ознаки критичного модуля:

1) реалізує кілька вимог до програмної системи;

2) має високий рівень керування (перебуває досить високо в програмній структурі);

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

4) має певні вимоги до продуктивності обробки.

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

Лекція 4 (2 години)

Тема: Системне тестування. Тестування працездатності

Системне тестування. Системне тестування має на увазі вихід за рамки області дії програмного проекту й проводиться не тільки розробником програми. Класична проблема системного тестування - вказівка причини. Вона виникає, коли розробник одного системного елемента обвинувачує розробника іншого елемента в причині виникнення дефекту. Для захисту від подібного обвинувачення розробник програмного елемента повинен:

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

- провести тести, що моделюють невдалі дані або інші потенційні помилки інтерфейсу ПС;

- записати результати тестів, щоб використати їх як доказ невиновності у випадку «вказівки причини»;

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

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

Типи системних тестів.

Тестування відновлення. Багато комп'ютерних систем повинні відновлюватися після відмов і відновляти обробку в межах заданого часу. У деяких випадках система повинна бути відмовостійкою, тобто відмови обробки не повинні бути причиною припинення роботи системи. В інших випадках системна відмова повинен бути усунута в межах заданого кванту часу, інакше замовникові наноситься серйозний економічний збиток.

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

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

Тестування безпеки перевіряє фактичну реакцію захисних механізмів, вбудованих у систему, на проникнення.

У ході тестування безпеки випробувач відіграє роль зломщика. Йому дозволено все:

- спроби довідатися пароль за допомогою зовнішніх засобів;

- атака системи за допомогою спеціальних утиліт, що аналізують захисти;

- придушення, приголомшення системи (у надії, що вона відмовиться обслуговувати інших клієнтів);

- цілеспрямоване введення помилок у надії проникнути в систему в ході відновлення;

- перегляд несекретних даних у надії знайти ключ для входу в систему.

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

Лекція 5 (2 години)

Тема: Відлагодження програмних систем

Налагодження - це локалізація й усунення помилок. Налагодження є наслідком успішного тестування. Це значить, що якщо тестовий варіант виявляє помилку, то процес налагодження знищує її.

Отже, процесу налагодження передує виконання тестового варіанта. Його результати оцінюються, реєструється невідповідність між очікуваним і реальним результатами. Невідповідність є симптомом схованої причини. Процес налагодження намагається зіставити симптом із причиною, внаслідок чого приводить до виправлення помилки. Можливі два результати процесу налагодження:

1) причина знайдена, виправлена, знищена;

2) причина не знайдена.

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

Можливі різні способи прояву помилок:

1) програма завершується нормально, але видає невірні результати;

2) програма зависає;

3) програма завершується по перериванню;

4) програма завершується, видає очікувані результати, але збережені дані зіпсовані (це самий неприємний варіант).

Характер прояву помилок також може мінятися. Симптом помилки може бути:

- постійним;

- мерехтливим;

- граничним (проявляється при перевищенні деякого порога в обробці - 200 літаків на екрані відслідковуються, а 201-го - немає);

- відкладеним (проявляється тільки після виправлення помилок, що його маскують).

У ході налагодження ми зустрічаємо помилки в широкому діапазоні: від дрібних неприємностей до катастроф. Наслідком збільшення помилок є посилення тиску на відладника. Часто через цей тиск розробник усуває одну помилку й вносить дві нові помилки.

Англійський термін debugging (налагодження) дослівно переводиться як «лов бліх», що відбиває специфіку процесу — гонитву за об'єктами налагодження, «блохами». Розглянемо, як може бути організований цей процес «лову бліх».

Розрізняють дві групи методів налагодження:

- аналітичні;

- експериментальні.

Аналітичні методи базуються на аналізі вихідних даних для тестових прогонів. Експериментальні методи базуються на використанні допоміжних засобів налагодження (налагоджувальний друк, трасування), що дозволяють уточнити характер поведінки програми при тих або інших вихідних даних.

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

У найпростішому випадку місце прояву симптому й помилковий фрагмент збігаються. Але найчастіше вони далеко відстоять друг від друга.

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

У різних методах простежування організується по-різному. В аналітичних методах – на основі логічних висновків про поводження програми. Ціль – крок за кроком зменшувати область програми, підозрювану в наявності помилки. Тут визначається кореляція між значеннями вихідних даних і особливостями поводження.