івень, внісши до нього деякі удосконалення або виправляючи помилки, або іноді навіть викинути проект і почати все спочатку, тому що розробник раптово побачив кращий підхід.
Якщо ж головна частина програми вже запрограмована і Відтестований, то виникає серйозний опір будь-яким поліпшень її структури. У кінцевому підсумку за рахунок таких поліпшень зазвичай можна заощадити більше, ніж ті кілька днів або тижнів, які розраховує виграти проектувальник, приступаючи до програмування занадто рано.
4.3 Технологія висхідного і низхідного тестування
При плановому підході програма перевіряється послідовно блок за блоком, причому якщо програма складається з центрального блоку, який проводить звернення до периферійних блокам, мало пов'язаних один з одним, то можливі такі два основних підходи до контролю такої програми, два основних напрямки тестування:
· від периферії до центру (висхідне тестування) або, навпаки,
· від центру до периферії (спадне тестування).
При першому, висхідному тестуванні, вживаному зазвичай для невеликих програм, спочатку тестують окремі периферійні блоки, а потім переходять до тестування центральній частині, яка, зрозуміло, взаємодіє тільки з налагодженими вже блоками.
При низхідному тестуванні, використовуваному для досить великих програм, паралельно з контролем периферійних блоків (або навіть до початку їх контролю) виробляється і контроль центрального блоку, виконуваного на комп'ютері спільно з імітаторами периферійних блоків, званих заглушками. У завдання імітаторів входить моделювання роботи відповідних блоків з метою підтримати функціонування центрального блоку. Зазвичай заглушки видають найпростіший результат, наприклад константу і повідомлення про факт своєї участі в роботі. Замість постійної величини на найбільш пізній стадії тестування може видаватися і випадкова величина в необхідному діапазоні.
Наприклад, для початкового контролю програми, що включає в якості одного зі своїх блоків обчислення певного інтеграла, заглушка такого блоку може повертати константу. У свою чергу, блок інтегрування сам має периферійний блок обчислення значень підінтегральної функції, в якості заглушки якого спочатку також може бути взята константа або найпростіша функціональна залежність.
На жаль, часто невірно розуміють функції, виконувані заглушками. Так, часом можна почути, що заглушка повинна виконувати лише запис повідомлення, що встановлює: Модуль підключився raquo ;. У більшості випадків ці твердження помилкові. Коли модуль A викликає модуль B, A припускає, що B виконує якусь роботу, тобто модуль A отримує результати роботи модуля B. Коли ж модуль B просто повертає управління або видає деяке повідомлення без передачі в A певних осмислених результатів, модуль A працює невірно НЕ внаслідок помилок у самому модулі, а через невідповідність йому модуля-заглушки. Більше того, результат може виявитися незадовільним, якщо відповідь модуля-заглушки не змінюється в залежності від умов тесту. Якщо заглушка завжди повертає один і той же фіксований результат замість конкретного значення, передбачуваного зухвалим модулем саме в цьому виклику, то викликає модуль спрацює як помилковий (наприклад, зациклиться) або видасть невірне вихідне значення. Отже,
Практично, обидва ці способи рідко використовуються в чистому вигляді, окремо один від одного. Зазвичай до часу, коли приступають до контролю центрального блоку, якісь найпростіші периферійні блоки вже налагоджені автономно, і немає необхідності моделювати їх роботу і розробляти заглушки.
Перевагою ранньої налагодження центрального блоку при низхідному тестуванні є те, що програміст швидко отримує можливість перевірити периферійні блоки в умовах, які в необхідній мірі наближені до реальних. Дійсно, центральний блок, забезпечений хоча б і найпростішими функціональними можливостями, можна розглядати як реальне середовище, в яку занурюються Отлаживаются блоки, додаються до центральної частини. Додавання Отлаживаются блоків зручно робити по одному для якнайшвидшого пошуку помилок, що виникають при стикуванні з центральним блоком. Підключення кожного нового блоку до центральної частини дозволяє поступово ускладнювати випробування, яким піддається тестуєма програма.
Суворої, коректної процедури підключення чергового послідовно модуля, що тестується не існує. Єдине правило, яким слід керуватися привиборі чергового модуля, полягає в тому, що їм має бути один з модулів, що викликаються модулем, попередньо пройшли тестування.
Запам'ятайте, що навіть якщо зміни вносяться тільки в одну підпрограму, то повторному тестуванню підлягає вся система. Цей процес називається тестуванням з поверненням....
