Покрокове тестування. Висхідне тестування. Низхідне тестування

Метод сандвіча

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

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

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

Покрокове тестування

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

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

другий підхід відомий як покроковий метод тестування або зборки.

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

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

• Монолітне тестування вимагає великих витрат праці. При покроковому ж тестуванні "знизу-вгору" витрати праці скорочуються.

• Витрата машинного часу при монолітному тестуванні менша.

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

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

• Відладка програм при покроковому тестуванні легша. Якщо є помилки в міжмодульних інтерфейсах, а зазвичай так і буває, то при монолітному тестуванні вони можуть бути виявлені лише тоді, коли зібрана уся програма. У цей момент локалізувати помилку досить важко, оскільки вона може знаходитися в будь-якому місці програми. Навпаки, при покроковому тестуванні помилки такого типу в основному пов'язані з тим модулем, який підключається останнім.

• Результати покрокового тестування досконаліші.

На закінчення відмітимо, що п. 1, 4, 5, 6 демонструють переваги покрокового тестування, а п. 2 і 3 - його недоліки. Оскільки для сучасного етапу розвитку обчислювальної техніки характерні тенденції до зменшення вартості апаратури і збільшенню вартості праці, наслідки помилок в математичному забезпеченні дуже серйозні, а вартість усунення помилки тим менше, чим раніше вона виявлена; переваги, вказані в п. 1, 4, 5, 6, виступають на перший план. В той же час збиток, що наноситься недоліками (п. 2 і 3), невеликий. Усе це дозволяє нам зробити висновок, що покрокове тестування є переважним.

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

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

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

Висхідне тестування

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

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

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

Низхідне тестування

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

При цьому підході негайно виникають два питання: 1. "Що робити, коли тестований модуль викликає модуль нижчого рівня (якого в даний момент ще не існує)"? і "Як подаються тестові дані"?

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

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

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

Перевагою низхідного підходу дуже часто вважають відсутність необхідності в драйверах; замість драйверів вам просто слід написати "заглушки".

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

12.7.Метод "великого стрибка". Метод сандвіча. Модифікований метод сандвіча.

Метод "великого стрибка"

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

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

Якщо програма мала (як, наприклад, програма завантажувача) і добре спроектована, метод "великого стрибка" може виявитися прийнятним. Проте для великих програм метод "великого стрибка" зазвичай згубний.

Метод сандвіча

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

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

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

Модифікований метод сандвіча

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

Дата добавления: 2014-01-04