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

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

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

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

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

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

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

"Як подаються тестові дані"?

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

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

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

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

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

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

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

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

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

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

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