конспект лекцій (ТСПП). Конспект лекцій з дисципліни 07 технологія створення програмних продуктів напряму 050101 Компютерні науки
 Скачать 14.87 Mb.
|
12.6.Покрокове тестування. Висхідне тестування. Низхідне тестування.Покрокове тестування Реалізація процесу тестування модулів спирається на два ключові положення: побудова ефективного набору тестів і вибір способу, за допомогою якого модулі комбінуються при побудові з них робочої програми. Друге положення є важливим, оскільки воно задає форму написання тестів модуля, типи засобів, використовуваних при тестуванні, порядок кодування і тестування модулів, вартість генерації тестів і вартість відладки. Розглянемо два підходи до комбінування модулів : покрокове і монолітне тестування. Виникає питання: "Що краще - виконати окремо тестування кожного модуля, а потім, комбінуючи їх, сформувати робочу програму або ж кожен модуль для тестування підключати до набору модулів", що раніше відтестували?. Перший підхід зазвичай називають монолітним методом, або методом "великого удару", при тестуванні і зборці програми; другий підхід відомий як покроковий метод тестування або зборки. Метод покрокового тестування припускає, що модулі тестуються не ізольовано один від одного, а підключаються по черзі для виконання тесту до набору вже модулів, що раніше відтестували. Покроковий процес триває до тих пір, поки до набору модулів, що відтестували, не буде підключений останній модуль. Детального розбору обох методів ми робити не будемо, приведемо лише деякі загальні висновки.
На закінчення відмітимо, що п. 1, 4, 5, 6 демонструють переваги покрокового тестування, а п. 2 і 3 - його недоліки. Оскільки для сучасного етапу розвитку обчислювальної техніки характерні тенденції до зменшення вартості апаратури і збільшенню вартості праці, наслідки помилок в математичному забезпеченні дуже серйозні, а вартість усунення помилки тим менше, чим раніше вона виявлена; переваги, вказані в п. 1, 4, 5, 6, виступають на перший план. В той же час збиток, що наноситься недоліками (п. 2 і 3), невеликий. Усе це дозволяє нам зробити висновок, що покрокове тестування є переважним. Переконавшись в перевагах покрокового тестування перед монолітним, досліджуємо дві можливі стратегії тестування : низхідне і висхідне. Передусім внесемо ясність в термінологію. По-перше, терміни "низхідне тестування", "низхідна розробка", "низхідне проектування" часто використовуються як синоніми. Дійсно, терміни "низхідне тестування" і "низхідна розробка" є синонімами (в тому сенсі, що вони мають на увазі певну стратегію при тестуванні і створенні текстів модулів), але низхідне проектування - це абсолютно інший і незалежний процес. Програма, спроектована низхідним методом, може тестуватися і низхідним, і висхідним методами. По-друге, висхідна розробка, або тестування, часто ототожнюється з монолітним тестуванням. Це непорозуміння виникає через те, що початок висхідного тестування ідентичний монолітному при тестуванні нижніх або термінальних модулів. Але вище ми показали, що висхідне тестування насправді є покроковою стратегією. Висхідне тестування При висхідному підході програма збирається і тестується "від низу до верху". Тільки модулі самого нижнього рівня ("термінальні" модулі; модулі, що не викликають інших модулів) тестуються ізольовано, автономно. Після того, як тестування цих модулів завершене, виклик їх має бути так само надійний, як виклик вбудованої функції мови або оператор привласнення. Потім тестуються модулі, що безпосередньо викликають вже перевірені. Ці модулі більше високого рівня тестуються не автономно, а разом із вже перевіреними модулями нижчого рівня. Процес повторюється до тих пір, поки не буде досягнута вершина. Тут завершується і тестування модулів, і тестування сполучень програми. При висхідному тестуванні для кожного модуля потрібний драйвер: треба подавати тести відповідно до сполучення тестованого модуля. Одне з можливих рішень - написати для кожного модуля невелику провідну програму. Тестові дані представляються як "вбудовані" безпосередньо в цю програму змінні і структури даних, і вона багаторазово викликає тестований модуль, з кожним викликом передаючи йому нові тестові дані. Є і краще рішення: скористатися програмою тестування модулів - це інструмент тестування, що дозволяє описувати тести на спеціальній мові і избавляющий від необхідності писати драйвери. Тут відсутні проблеми, пов'язані з неможливістю або трудністю створення усіх тестових ситуацій, характерні для низхідного тестування. Драйвер як засіб тестування застосовується безпосередньо до того модуля, який тестується, де немає проміжних модулів, які слід брати до уваги. Аналізуючи інші проблеми, що виникають при низхідному тестуванні, можна помітити, що при висхідному тестуванні неможливо прийняти безрозсудне рішення про поєднання тестування з проектуванням програми, оскільки не можна почати тестування до тих пір, поки не спроектовані модулі нижнього рівня. Не існує також і труднощів з незавершеністю тестування одного модуля при переході до тестування іншого, тому що при висхідному тестуванні із застосуванням декількох версій заглушки немає складнощів з представленням тестових даних. Низхідне тестування Низхідне тестування (зване також низхідною розробкою) не є повною протилежністю висхідному, але в першому наближенні може розглядатися як таке. При низхідному підході програма збирається і тестується зверху "вниз". Ізольовано тестується тільки головний модуль. Після того, як тестування цього модуля завершене, з ним з'єднуються (наприклад, редактором зв'язків) один за іншим модулі, що безпосередньо викликаються їм, і тестується отримана комбінація. Процес повторюється до тих пір, поки не будуть зібрані і перевірені усі модулі. При цьому підході негайно виникають два питання: 1. "Що робити, коли тестований модуль викликає модуль нижчого рівня (якого в даний момент ще не існує)"? і "Як подаються тестові дані"? Відповідь на перше питання полягає в тому, що для імітації функцій бракуючих модулів програмуються модулі -"заглушки", які моделюють функції відсутніх модулів. Цікаве і друге питання: в якій формі готуються тестові дані і як вони передаються програмі? Якби головний модуль містив усі потрібні операції введення і виводу, відповідь була б проста: тести пишуться у вигляді звичайних для користувачів зовнішніх даних і передаються програмі через виділені їй пристрої введення. Так, проте, трапляється рідко. У добре спроектованій програмі фізичні операції введення-виводу виконуються на нижніх рівнях структури, оскільки фізичне уведення-виведення - абстракція досить низького рівня. Тому для того, щоб розв'язати проблему економічно ефективно, модулі додаються не в строго низхідній послідовності (усі модулі одного горизонтального рівня, потім модулі наступного рівня), а так, щоб забезпечити функціонування операцій фізичного введення-виводу якнайшвидше. Коли ця мета досягнута, низхідне тестування отримує значну перевагу: усі подальші тести готуються в тій же формі, яка розрахована на користувача. Низхідний метод має як достоїнства, так і недоліки в порівнянні з висхідним. Найзначніша гідність - те, що цей метод поєднує тестування модуля, тестування сполучень і часткове тестування зовнішніх функцій. З цим же пов'язана інша його гідність: коли модулі ввода-вы- вода вже підключені, тести можна готувати в зручному виді. Низхідний підхід вигідний також у тому випадку, коли є сумніви відносно здійсненності програми в цілому або коли в проекті програми можуть опинитися серйозні дефекти. Перевагою низхідного підходу дуже часто вважають відсутність необхідності в драйверах; замість драйверів вам просто слід написати "заглушки". Низхідний метод тестування має, на жаль, деякі недоліки. Основним з них є те, що модуль рідко тестується досконально відразу після його підключення. Річ у тому, що грунтовне тестування деяких модулів може зажадати украй витончених заглушок. Програміст часто вирішує не витрачати масу часу на їх програмування, а замість цього пише прості заглушки і перевіряє лише частину умов в модулі. Він, звичайно, збирається повернутися і закінчити тестування даного модуля пізніше, коли прибере заглушки. Такий план тестування - визначено не краще рішення, оскільки про відкладені умови часто забувають. |