Ноу Інти, лекція, інтеграційне тестування

Анотація: Лекція є другою з трьох розглядають рівні процесу верифікації. Тема даної лекції - процес інтеграційного тестування, його завдання та цілі. Розглядаються організаційні аспекти інтеграційного тестування - структурна і тимчасова класифікації методів інтеграційного тестування, планування інтеграційного тестування. Мета даної лекції: дати уявлення про процес інтеграційного тестування, його технічної і організаційної складових

20.1. Завдання і цілі інтеграційного тестування

Результатом тестування і верифікації окремих модулів, що складають програмну систему, має бути висновок про те, що ці модулі є внутрішньо повинні суперечити одна одній і відповідають вимогам. Однак окремі модулі рідко функціонують самі по собі, тому наступне завдання після тестування окремих модулів - тестування коректності взаємодії декількох модулів, об'єднаних в єдине ціле. Таке тестування називають інтеграційним. Його мета - переконатися в коректності спільної роботи компонент системи.

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

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

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

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

20.2. Організація інтеграційного тестування

20.2.1. Структурна класифікація методів інтеграційного тестування

Як правило, інтеграційне тестування проводиться вже по завершенні модульного тестування для всіх інтегрованих модулів. Однак це далеко не завжди так. Існує кілька методів проведення інтеграційного тестування:

• висхідне тестування;
• монолітне тестування;
• спадний тестування.

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

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

Мал. 20.1. Розробка драйверів і заглушок при висхідному інтеграційному тестуванні

Однак, у висхідного методу тестування є істотний недолік - необхідність в розробці драйвера і заглушок для модульного тестування перед проведенням інтеграційного тестування і необхідність в розробці драйвера і заглушок при інтеграційному тестуванні частини модулів системи (Рис 20.1)

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

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

Монолітне тестування має ряд серйозних недоліків.

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

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

збільшити зображення
Мал. 20.2. Поступова інтеграція модулів при низхідному методі тестування

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

Незалежно від застосовуваного методу інтеграційного тестування, необхідно враховувати ступінь покриття інтеграційними тестами функціональності системи. В роботі [17] було запропоновано спосіб оцінки ступеня покриття, заснований на керуючих виклики між функціями і потоках даних. При такій оцінці код всіх модулів на структурної діаграмі системи повинен бути виконаний (повинні бути покриті всі вузли), всі виклики повинні бути виконані хоча б один раз (повинні бути покриті всі зв'язки між вузлами на структурної діаграмі), все послідовності викликів повинні бути виконані хоча б один раз (всі шляхи на структурної діаграмі повинні бути покриті) [10].