сутні проблеми, пов'язані з неможливістю або трудністю створення всіх тестових ситуацій, характерні для спадного тестування. Драйвер як засіб тестування застосовується безпосередньо до того модулю, який тестується, де немає проміжних модулів, які слід брати до уваги. Аналізуючи інші проблеми, що виникають при низхідному тестуванні, можна помітити, що при висхідному тестуванні неможливо прийняти нерозумне рішення про суміщення тестування з проектуванням програми, оскільки не можна почати тестування до тих пір, поки не спроектовані модулі нижнього рівня. Не існує також і труднощів з незавершеністю тестування одного модуля при переході до тестування іншого, тому що при 'висхідному тестуванні з застосуванням декількох версій заглушки немає складнощів з поданням тестових даних.
Восходящее тестування - це прекрасний спосіб локалізації помилок. Якщо помилку виявлено при тестуванні єдиного модуля, то очевидно, що вона міститься саме в ньому - для пошуку її джерела не потрібно аналізувати код всієї системи. А якщо помилка проявляється при спільній роботі двох попередньо протестованих модулів, значить, справа в їх інтерфейсі. Ще однією перевагою висхідного тестування є те, що виконує його програміст концентрується на дуже вузькій області (єдиному модулі, передачі даних між парою модулів і т.п.). Завдяки цьому тестування проводиться більш ретельно і з більшою ймовірністю виявляє помилки.
Головним недоліком висхідного тестування є необхідне написання спеціального коду-оболонки, що викликає тестований модуль. Якщо він, у свою чергу, викликає інший модуль, для нього потрібно написати «заглушку». Заглушка - це імітація викликається функції, що повертає ті ж дані, але нічого більше не робить.
Зрозуміло, що написання оболонок і заглушок уповільнює роботу, а для кінцевого продукту вони абсолютно марні. Але написання одного разу, ні елементи можуть використовуватися повторно при кожній зміні про-флмми. Хороший набір оболонок і заглушок - це дуже ефективний інструмент тестування.
На противагу висхідному тестуванню, стратегія цілісного тестування припускає, що до повної інтеграції системи її окремі модулі не проходять особливо ретельного тестування.
Перевагою такої стратегії є те, що немає необхідності в написанні додаткового коду. Тому багато керівників вибирають цей спосіб з міркувань економії часу - вони вважають, що краще розробити одне великий набір тестів і з його допомогою за один раз перевірити всю систему. Але таке уявлення зовсім помилково, і ось чому.
Дуже важко виявити джерело помилки. Це головна проблема. Оскільки жоден з модулів не перевірений як слід, в більшості з них є помилки. Виходить, що питання не стільки в тому, в якому модулі сталася виявлена ??помилка, скільки в тому, яка з помилок у всіх залучених до процесу модулях привела до отриманого результату. І коли накладаються помилки декількох модулів, ситуацію може бути набагато важче локалізувати і повторити.
Крім того, помилка в одному з модулів може блокувати тестування іншого. Як протестувати функцію, якщо викликає її модуль не працює? Якщо не написати для цієї функції програму-оболонку, доведеться чекати налагодження модуля, а це може затягнутися надовго.
Важко організувати виправлення помилок. Якщо програму пишуть кілька програмістів (а саме так і буває у великих системах), і при цьому невідомо, в якому модулі помилка, хто ж буде її шукати і виправляти? Один програміст буде вказувати на іншого, той, з'ясувавши, що його код ні при чому, знову звернеться до першого, а в результаті буде сильно страждати швидкість розробки.
Процес тестування погано автоматизований. Те, що на перший погляд здається перевагою цілісного тестування - відсутність необхідності писати оболонки і заглушки, - насправді обертається його недоліком. У процесі розробки програма щодня змінюється, і її доводиться тестувати знову і знову. А оболонки і заглушки допомагають автоматизувати цей одноманітний працю.
4.2 Спадний тестування
Існує і ще один принцип організації тестування, при якому програма так само, як і при висхідному способі, тестується не цілком, а по частинах. Тільки напрямок руху змінюється - спочатку тестується самий верхній рівень ієрархії модулів, а від нього тестувальник поступово спускається вниз. Така технологія називається низхідній (top-down). Обидві технології - і спадну і висхідну - називають також інкрементального.
При низхідному тестуванні відпадає необхідність у написанні оболонок, але заглушки залишаються. У міру тестування заглушки по черзі замінюються на реальні модулі.
Думки фахівців про те, яка з двох інкрементальних стратегій тестування більш ефективна, сильно розходяться. На практ...
