2. Інтеграція модулів.

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

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

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

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

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

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

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

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

Цікаве і друге питання: у якій формі готуються тестові дані і як вони передаються програмі? Якби головний модуль містив всі потрібні операції введення і виводу, відповідь була б проста:

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

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

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

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

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

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