конспект лекцій (ТСПП). Конспект лекцій з дисципліни 07 технологія створення програмних продуктів напряму 050101 Компютерні науки
 Скачать 14.87 Mb.
|
12.5. Тестування модулів.Другим по важливості аспектом тестування після проектування тестів являється послідовність злиття усіх модулів в систему або програму. Ця сторона питання зазвичай не отримує достатньої уваги і часто розглядається надто пізно. Вибір цієї послідовності, проте, є одним з самих життєво важливих рішень, що приймаються на етапі тестування, оскільки він визначає форму, в якій записуються тести, типи необхідних інструментів тестування, послідовність програмування модулів, а також ретельність і економічність усього етапу тестування. З цієї причини таке рішення повинне прийматися на рівні проекту в цілому і на досить ранній його стадії. Тестування модулів (чи блоків) є процесом тестування окремих підпрограм або процедур програми. Тут мається на увазі, що, перш ніж починати тестування програми в цілому, слід протестувати окремі невеликі модулі, що утворюють цю програму. Такий підхід мотивується трьома причинами. По-перше, з'являється можливість управляти комбінаторикою тестування, оскільки спочатку увага концентрується на невеликих модулях програми. По-друге, полегшується завдання відладки програми, тобто виявлення місця помилки і виправлення тексту програми. По-третє, допускається паралелізм, що дозволяє одночасно тестувати декілька модулів. Мета тестування модулів - порівняння функцій, що реалізовуються модулем, із специфікаціями його функцій або інтерфейсу. Тестування модулів в основному орієнтоване на принцип "білого ящика". Це пояснюється передусім тим, що принцип "білого ящика" важче реалізувати при переході в наступному до тестування більших одиниць, наприклад програм в цілому. Крім того, наступні етапи тестування орієнтовані на виявлення помилок різного типу, т. е. помилок, не обов'язково пов'язаних з логікою програми, а що виникають, наприклад, із-за невідповідності програми вимогам користувача. Є великий вибір можливих підходів, які можуть бути використані для злиття модулів в більші одиниці. В більшості своїй вони можуть розглядатися як варіанти шести основних підходів, описаних нижче. Покрокове тестування Реалізація процесу тестування модулів спирається на два ключові положення: побудова ефективного набору тестів і вибір способу, за допомогою якого модулі комбінуються при побудові з них робочої програми. Друге положення є важливим, оскільки воно задає форму написання тестів модуля, типи засобів, використовуваних при тестуванні, порядок кодування і тестування модулів, вартість генерації тестів і вартість відладки. Розглянемо два підходи до комбінування модулів : покрокове і монолітне тестування. Виникає питання: "Що краще - виконати окремо тестування кожного модуля, а потім, комбінуючи їх, сформувати робочу програму або ж кожен модуль для тестування підключати до набору модулів", що раніше відтестували?. Перший підхід зазвичай називають монолітним методом, або методом "великого удару", при тестуванні і зборці програми; другий підхід відомий як покроковий метод тестування або зборки. Метод покрокового тестування припускає, що модулі тестуються не ізольовано один від одного, а підключаються по черзі для виконання тесту до набору вже модулів, що раніше відтестували. Покроковий процес триває до тих пір, поки до набору модулів, що відтестували, не буде підключений останній модуль. Детального розбору обох методів ми робити не будемо, приведемо лише деякі загальні висновки. Монолітне тестування вимагає великих витрат праці. При покроковому ж тестуванні "знизу-вгору" витрати праці скорочуються. Витрата машинного часу при монолітному тестуванні менша. Використання монолітного методу надає великі можливості для паралельної організації роботи на початковій фазі тестування (тестування усіх модулів одночасно). Це положення може мати важливе значення при виконанні великих проектів, в яких багато модулів і багато виконавців, оскільки чисельність персоналу, що бере участь в проекті, максимальна на початковій фазі. При покроковому тестуванні раніше виявляються помилки в інтерфейсах між модулями, оскільки раніше починається зборка програми. В протилежність цьому при монолітному тестуванні модулі "не бачать один одного" до останньої фази процесу тестування. Відладка програм при покроковому тестуванні легша. Якщо є помилки в міжмодульних інтерфейсах, а зазвичай так і буває, то при монолітному тестуванні вони можуть бути виявлені лише тоді, коли зібрана уся програма. У цей момент локалізувати помилку досить важко, оскільки вона може знаходитися в будь-якому місці програми. Навпаки, при покроковому тестуванні помилки такого типу в основному пов'язані з тим модулем, який підключається останнім. Результати покрокового тестування досконаліші. На закінчення відмітимо, що п. 1, 4, 5, 6 демонструють переваги покрокового тестування, а п. 2 і 3 - його недоліки. Оскільки для сучасного етапу розвитку обчислювальної техніки характерні тенденції до зменшення вартості апаратури і збільшення вартості праці, наслідки помилок в математичному забезпеченні дуже серйозні, а вартість усунення помилки тим менше, чим раніше вона виявлена; переваги, вказані в п. 1, 4, 5, 6, виступають на перший план. В той же час збиток, що наноситься недоліками (п. 2 і 3), невеликий. Усе це дозволяє нам зробити висновок, що покрокове тестування є переважним. Переконавшись в перевагах покрокового тестування перед монолітним, досліджуємо дві можливі стратегії тестування : низхідне і висхідне. Передусім внесемо ясність в термінологію. По-перше, терміни "низхідне тестування", "низхідна розробка", "низхідне проектування" часто використовуються як синоніми. Дійсно, терміни "низхідне тестування" і "низхідна розробка" є синонімами (в тому сенсі, що вони мають на увазі певну стратегію при тестуванні і створенні текстів модулів), але низхідне проектування - це абсолютно інший і незалежний процес. Програма, спроектована низхідним методом, може тестуватися і низхідним, і висхідним методами. По-друге, висхідна розробка, або тестування, часто ототожнюється з монолітним тестуванням. Це непорозуміння виникає через те, що початок висхідного тестування ідентичний монолітному при тестуванні нижніх або термінальних модулів. Але вище ми показали, що висхідне тестування насправді є покроковою стратегією. Висхідне тестування При висхідному підході програма збирається і тестується "від низу до верху". Тільки модулі самого нижнього рівня ("термінальні" модулі; модулі, що не викликають інших модулів) тестуються ізольовано, автономно. Після того, як тестування цих модулів завершене, виклик їх має бути так само надійний, як виклик вбудованої функції мови або оператор привласнення. Потім тестуються модулі, що безпосередньо викликають вже перевірені. Ці модулі більше високого рівня тестуються не автономно, а разом із вже перевіреними модулями нижчого рівня. Процес повторюється до тих пір, поки не буде досягнута вершина. Тут завершується і тестування модулів, і тестування сполучень програми. При висхідному тестуванні для кожного модуля потрібний драйвер: треба подавати тести відповідно до сполучення тестованого модуля. Одне з можливих рішень - написати для кожного модуля невелику провідну програму. Тестові дані представляються як "вбудовані" безпосередньо в цю програму змінні і структури даних, і вона багаторазово викликає тестований модуль, з кожним викликом передаючи йому нові тестові дані. Є і краще рішення: скористатися програмою тестування модулів - це інструмент тестування, що дозволяє описувати тести на спеціальній мові і избавляющий від необхідності писати драйвери. Тут відсутні проблеми, пов'язані з неможливістю або трудністю створення усіх тестових ситуацій, характерні для низхідного тестування. Драйвер як засіб тестування застосовується безпосередньо до того модуля, який тестується, де немає проміжних модулів, які слід брати до уваги. Аналізуючи інші проблеми, що виникають при низхідному тестуванні, можна помітити, що при висхідному тестуванні неможливо прийняти безрозсудне рішення про поєднання тестування з проектуванням програми, оскільки не можна почати тестування до тих пір, поки не спроектовані модулі нижнього рівня. Не існує також і труднощів з незавершеністю тестування одного модуля при переході до тестування іншого, тому що при висхідному тестуванні із застосуванням декількох версій заглушки немає складнощів з представленням тестових даних. Низхідне тестування Низхідне тестування (зване також низхідною розробкою) не є повною протилежністю висхідному, але в першому наближенні може розглядатися як таке. При низхідному підході програма збирається і тестується зверху "вниз". Ізольовано тестується тільки головний модуль. Після того, як тестування цього модуля завершене, з ним з'єднуються (наприклад, редактором зв'язків) один за іншим модулі, що безпосередньо викликаються їм, і тестується отримана комбінація. Процес повторюється до тих пір, поки не будуть зібрані і перевірені усі модулі. При цьому підході негайно виникають два питання: 1. "Що робити, коли тестований модуль викликає модуль нижчого рівня (якого в даний момент ще не існує)"? і "Як подаються тестові дані"? Відповідь на перше питання полягає в тому, що для імітації функцій бракуючих модулів програмуються модулі -"заглушки", які моделюють функції відсутніх модулів. Цікаве і друге питання: в якій формі готуються тестові дані і як вони передаються програмі? Якби головний модуль містив усі потрібні операції введення і виводу, відповідь була б проста: тести пишуться у вигляді звичайних для користувачів зовнішніх даних і передаються програмі через виділені їй пристрої введення. Так, проте, трапляється рідко. У добре спроектованій програмі фізичні операції введення-виводу виконуються на нижніх рівнях структури, оскільки фізичне уведення-виведення - абстракція досить низького рівня. Тому для того, щоб розв'язати проблему економічно ефективно, модулі додаються не в строго низхідній послідовності (усі модулі одного горизонтального рівня, потім модулі наступного рівня), а так, щоб забезпечити функціонування операцій фізичного введення-виводу якнайшвидше. Коли ця мета досягнута, низхідне тестування отримує значну перевагу: усі подальші тести готуються в тій же формі, яка розрахована на користувача. Низхідний метод має як достоїнства, так і недоліки в порівнянні з висхідним. Найзначніша гідність - те, що цей метод поєднує тестування модуля, тестування сполучень і часткове тестування зовнішніх функцій. З цим же пов'язана інша його гідність: коли модулі ввода-вы- вода вже підключені, тести можна готувати в зручному виді. Низхідний підхід вигідний також у тому випадку, коли є сумніви відносно здійсненності програми в цілому або коли в проекті програми можуть опинитися серйозні дефекти. Перевагою низхідного підходу дуже часто вважають відсутність необхідності в драйверах; замість драйверів вам просто слід написати "заглушки". Низхідний метод тестування має, на жаль, деякі недоліки. Основним з них є те, що модуль рідко тестується досконально відразу після його підключення. Річ у тому, що грунтовне тестування деяких модулів може зажадати украй витончених заглушок. Програміст часто вирішує не витрачати масу часу на їх програмування, а замість цього пише прості заглушки і перевіряє лише частину умов в модулі. Він, звичайно, збирається повернутися і закінчити тестування даного модуля пізніше, коли прибере заглушки. Такий план тестування - визначено не краще рішення, оскільки про відкладені умови часто забувають. Другий тонкий недолік низхідного підходу полягає в тому, що він може породити віру в можливість почати програмування і тестування верхнього рівня програми до того, як уся програма буде повністю спроектована. Ця ідея на перший погляд здається економічною, але зазвичай справа йде зовсім навпаки. Більшість досвідчених проектувальників визнають, що проектування програми - процес ітеративний. Рідко перший проект виявляється досконалим. Нормальний стиль проектування структури програми припускає після закінчення проектування нижніх рівнів повернутися назад і підправити верхній рівень, внісши в нього деякі удосконалення або виправляючи помилки, або іноді навіть викинути проект і почати усе спочатку, тому що розробник несподівано побачив кращий підхід. Якщо ж головна частина програми вже запрограмована і відтестувала, то виникає серйозний опір будь-яким поліпшенням її структури. Зрештою за рахунок таких поліпшень зазвичай можна заощадити більше, ніж ті декілька днів або тижнів, які розраховує виграти проектувальник, приступаючи до програмування дуже рано. Метод "великого стрибка" Ймовірно, найпоширеніший підхід до інтеграції модулів - метод "великого стрибка". Відповідно до цього методу кожен модуль тестується автономно. Після закінчення тестування модулів вони інтегруються в систему усе відразу. Метод "великого стрибка" в порівнянні з іншими підходами має багато недоліків і мало достоїнств. Заглушки і драйвери потрібні для кожного модуля. Модулі не інтегруються до самого останнього моменту, а це означає, що протягом довгого часу серйозні помилки в сполученнях можуть залишитися невиявленими. Якщо програма мала (як, наприклад, програма завантажувача) і добре спроектована, метод "великого стрибка" може виявитися прийнятним. Проте для великих програм метод "великого стрибка" зазвичай згубний. Метод сандвіча Тестування методом сандвіча є компроміс між висхідним і низхідним підходами. Тут робиться спроба скористатися достоїнствами обох методів, уникнувши їх недоліків. При використанні цього методу одночасно починають висхідне і низхідне тестування, збираючи програму як знизу, так і згори і зустрічаючись врешті-решт десь в середині. Точка зустрічі залежить від конкретної тестованої програми і має бути заздалегідь визначена при вивченні її структури. Наприклад, якщо розробник може представити свою систему у вигляді рівня прикладних модулів, потім рівня модулів обробки запитів, потім рівня примітивних функцій, то він може вирішити застосовувати низхідний метод на рівні прикладних модулів (програмуючи заглушки замість модулів обробки запитів), а на інших рівнях застосувати висхідний метод. Метод сандвіча зберігає таку гідність низхідного і висхідного підходів, як початок інтеграції системи на самому ранньому етапі. Оскільки вершина програми вступає в лад рано, ми, як в низхідному методі, вже на ранньому етапі отримуємо працюючий каркас програми. Оскільки нижні рівні програми створюються висхідним методом, знімаються проблеми низхідного методу, які були пов'язані з неможливістю тестувати деякі умови в глибині програми. |