Покрокове тестування

Тестування модулів.

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

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

Мета тестування модулів - порівняння функцій, що реалізовуються модулем, із специфікаціями його функцій або інтерфейсу.

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

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

Реалізація процесу тестування модулів спирається на два ключові положення: побудова ефективного набору тестів і вибір способу, за допомогою якого модулі комбінуються при побудові з них робочої програми. Друге положення є важливим, оскільки воно задає форму написання тестів модуля, типи засобів, використовуваних при тестуванні, порядок кодування і тестування модулів, вартість генерації тестів і вартість відладки. Розглянемо два підходи до комбінування модулів: покрокове і монолітне тестування.

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

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

Детального розбору обох методів ми робити не будемо, приведемо лише деякі загальні висновки.

Монолітне тестування вимагає великих витрат праці. При покроковому ж тестуванні "знизу-вгору" витрати праці скорочуються.

Витрата машинного часу при монолітному тестуванні менша.

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

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

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

Результати покрокового тестування досконаліші.

На закінчення відмітимо, що п. 1, 4, 5, 6 демонструють переваги покрокового тестування, а п. 2 і 3 - його недоліки. Оскільки для сучасного етапу розвитку обчислювальної техніки характерні тенденції до зменшення вартості апаратури і збільшення вартості праці, наслідки помилок в математичному забезпеченні дуже серйозні, а вартість усунення помилки тим менше, чим раніше вона виявлена; переваги, вказані в п. 1, 4, 5, 6, виступають на перший план. В той же час збиток, що наноситься недоліками (п. 2 і 3), невеликий. Усе це дозволяє нам зробити висновок, що покрокове тестування є переважним.

Переконавшись в перевагах покрокового тестування перед монолітним, досліджуємо дві можливі стратегії тестування: низхідне і висхідне. Передусім внесемо ясність в термінологію.

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

По-друге, висхідна розробка, або тестування, часто ототожнюється з монолітним тестуванням. Це непорозуміння виникає через те, що початок висхідного тестування ідентичний монолітному при тестуванні нижніх або термінальних модулів. Але вище ми показали, що висхідне тестування насправді є покроковою стратегією.

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