6_Основи тестування програмногозабезпечення
Лекція6: Модульне та інтеграційне тестування
Розглядаються особливості модульного тестування, обговорюються підходи до тестування на основі потоку управління, потоку даних, обговорюються динамічні та статичні методи при структурному підході. Розглядається приклад модульного тестування. Розглядається взаємозв'язок складання модулів та методів інтеграційного тестування. Обговорюються підходи монолітного, інкрементального, низхідного та висхідного тестування. Розглядаються особливості інтеграційного тестування у процедурному програмуванні.
Модульне тестування - це тестування програми лише на рівні окремо взятих модулів, функцій чи класів. Мета модульного тестування полягає у виявленні локалізованих у модулі помилок у реалізації алгоритмів, а також у визначенні ступеня готовності системи до переходу на наступний рівень розробки та тестування. Модульне тестування проводиться за принципом "білої скриньки", тобто ґрунтується на знанні внутрішньої структури програми, і часто включає ті чи інші методи аналізу покриття коду.
Модульне тестування зазвичай передбачає створення навколо кожного модуля певного середовища, що включає заглушки для всіх інтерфейсів модуля, що тестується. Деякі з них можуть використовуватися для подачі вхідних значень, інші для аналізу результатів, присутність третіх може бути продиктована вимогами компілятором і збирачем.
На рівні модульного тестування найпростіше виявити дефекти, пов'язані з алгоритмічними помилками та помилками кодування алгоритмів, типу роботи з умовами та лічильниками циклів, а також з використанням локальних змінних та ресурсів. Помилки, пов'язані з неправильним трактуванням даних, некоректною реалізацією інтерфейсів,сумісністю, продуктивністю тощо. зазвичай пропускаються лише на рівні модульного тестування і виявляються більш пізніх стадіях тестування.
Саме ефективність виявлення тих чи інших типів дефектів має визначати стратегію модульного тестування, тобто розміщення акцентів щодо набору вхідних значень. В організації, що займається розробкою програмного забезпечення, як правило, є історична база даних (Repository) розробок, що зберігає конкретні відомості про розробку попередніх проектів: про версії та складання коду (build) зафіксованих у процесі розробки продукту, про прийняті рішення, допущені прорахунки, помилки, успіхи і т.п. Провівши аналіз характеристик колишніх проектів, подібних до замовленої організації, можна оберігати нову розробку від старих помилок, наприклад, визначивши типи дефектів, пошук яких найбільш ефективний на різних етапах тестування.
У разі аналізується етап модульного тестування. Якщо аналіз не дав потрібної інформації, наприклад, у разі проектів, у яких відповідні дані не збиралися, то основним правилом стає пошук локальних дефектів, у яких код, ресурси та інформація, залучені до дефекту, характерні саме для даного модуля. У цьому випадку на модульному рівні помилки, пов'язані, наприклад, з невірним порядком або форматом параметрів модуля, можуть бути пропущені, оскільки вони залучають інформацію, що стосується інших модулів (а саме, специфікацію інтерфейсу), в той час як помилки в алгоритмі обробки параметрів досить легко виявляються.
Будучи за способом виконання структурним тестуванням або тестуванням "білої скриньки", модульне тестування характеризується ступенем, в якому тести виконують або покривають логікупрограми (початковий текст). Тести, пов'язані зі структурним тестуванням, будуються за такими принципами:
За підсумками аналізу потоку управління. У цьому випадку елементи, які мають бути покриті при проходженні тестів, визначаються на основі структурних критеріїв тестування С0, С1, С2. До них відносяться вершини, дуги, шляхи керуючого графа програми (УГП), умови, комбінації умов тощо.
За підсумками аналізу потоку даних, коли елементи, які мають бути покриті, визначаються з урахуванням потоку даних, т. е. інформаційного графа програми.
Тестування на основі потоку управління. Особливості використання структурних критеріїв тестування С0, С1, С2 були розглянуті в розділі 2. До них слід додати критерій покриття умов, що полягає в покритті всіх логічних умов у програмі. Критерії покриття рішень (гілок - С1) та умов не замінюють один одного, тому на практиці використовується комбінований критерій покриття умов/рішень, що поєднує вимоги щодо покриття та рішень, та умов.
До популярних критеріїв відносяться критерій покриття функцій програми, згідно з яким кожна функція програми повинна бути викликана хоча б один раз, і критерій покриття викликів, згідно з яким кожен виклик кожної функції програми повинен бути здійснений хоча б один раз. Критерій покриття дзвінків відомий також як критерій покриття пар дзвінків (call pair coverage).
Стратегія необхідних пар також тестує згадані взаємозв'язки. Використання змінної у предикаті дублюється відповідно до числа виходів рішення, і кожна з таких необхідних взаємозв'язків має бути протестована. До популярних критеріїв належить критерій СР, що полягає у покритті всіх таких пар дуг v і w, що з дуги vДосяжна дуга w, оскільки саме на дузі може статися втрата значення змінної, яка надалі вже не повинна використовуватися. Для "покриття" ще одного популярного критерію Cdu достатньо тестувати пари (вершина, дуга), оскільки визначення змінної відбувається у вершині УГП, а її використання - на дугах, що виходять із рішень, або обчислювальних вершин.
Методи проектування тестових шляхів для досягнення заданого ступеня тестованості у структурному тестуванні. Процес побудови набору тестів при структурному тестуванні прийнято поділяти на три фази:
Вибір тестових шляхів.
Генерація тестів, які відповідають тестовим шляхам.
Перша фаза відповідає статичному аналізу програми, завдання якого полягає в отриманні графа програми і залежить від нього та від критерію тестування безлічі елементів, які необхідно покрити тестами.
На третій фазі відомими шляхами тестування здійснюється пошук відповідних тестів, що реалізують проходження цих шляхів.
Друга фаза забезпечує вибір тестових шляхів. Виділяють три підходи до побудови тестових шляхів:
Методи реалізованих шляхів.
Статичні методи.Найпростіше і легко реалізоване рішення - побудова кожного шляху у вигляді поступового його подовження з допомогою додавання дуг, доки буде досягнуто вихідна вершина управляючого графа програми. Ця ідея може бути посилена в так званих адаптивних методах, які щоразу додають лише один тестовий шлях (вхідний тест), використовуючи попередні шляхи (тести) як посібник для вибору наступних шляхів відповідно до деякої стратегії. Найчастіше адаптивні стратегії застосовуються стосовно критерію С1. Основний недолік статичних методів полягає в тому,що не враховується можлива нереалізованість побудованих шляхів тестування.
Динамічні методи.Такі методи припускають побудову повної системи тестів, що задовольняють заданому критерію, шляхом одночасного вирішення задачі побудови безлічі шляхів і тестових даних. При цьому можна автоматично враховувати реалізованість чи нереалізованість раніше розглянутих шляхів чи їх частин. Основною ідеєю динамічних методів є приєднання до початкових реалізованих відрізків шляхів подальших їх частин так, щоб: 1) не втрачати при цьому реалізованості знову отриманих шляхів; 2) покрити необхідні елементи структури програми.
Методи реалізованих шляхів.Дана методика полягає у виділенні з безлічі шляхів підмножини всіх реалізованих шляхів. Після чого покриває безліч шляхів будується з отриманого підмножини шляхів, що реалізуються.
Гідність статичних методів полягає у порівняно невеликій кількості необхідних ресурсів, як при використанні, так і при розробці. Однак їх реалізація може містити непередбачуваний відсоток шлюбу (шляхів, що не реалізуються). Крім того, в цих системах перехід від безлічі шляхів до повної системи тестів користувач повинен здійснити вручну, а ця робота досить трудомістка. Динамічні методи вимагають значно більших ресурсів як під час розробки, і під час експлуатації, проте збільшення витрат відбувається, переважно, з допомогою розробки та експлуатації апарату визначення реалізованості шляху (символічний інтерпретатор, решатель нерівностей). Гідність цих методів полягає в тому, що їхня продукція має певний якісний рівень – реалізованість шляхів. Методи реалізованих шляхів дають найкращий результат.