ОРГАНІЗАЦІЯ ПРОЦЕСУ

ТЕСТУВАННЯ ПРОГРАМНОГО
ЗАБЕЗПЕЧЕННЯ
1.Організація процесу
тестування
2.Тестування елементів
3.Тестування інтеграції
 ОРГАНІЗАЦІЯ ПРОЦЕСУ ТЕСТУВАННЯ
ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ
• Процес тестування об'єднує різні способи тестування в
сплановану послідовність кроків, які призводять до
успішного побудови програмної системи (ПС) [3], [13], [64],
[69]. Методика тестування ПС може бути представлена у
вигляді розгортається спіралі (рис. 8.1).
• На початку здійснюється тестування елементів
(модулів), що перевіряє результати етапу кодування ПС. На
другому кроці виконується тестування
інтеграції, орієнтоване на виявлення помилок
етапу проектування ПС. На третьому обороті спіралі
проводиться тестування правильності, що перевіряє
коректність етапу аналізу вимог до ПС. На заключному витку
спіралі проводиться системне тестування, що виявляє
дефекти етапу системного аналізу ПС.
Спіраль процесу тестування ПС
 Характеристика кроків процесу
тестування
. Тестування елементів. Мета - індивідуальна
перевірка кожного модуля. Застосовуються методи тестування
«білого ящика».
• Тестування інтеграції. Мета - тестування збірки модулів в
програмну систему. В основному застосовують способи
тестування «чорного ящика».
• 3. Тестирование правильности. Цель — проверить
реализацию в программной системе всех функциональных
и поведенческих требований, а также требования
эффективности. Используются исключительно способы
тестирования «черного ящика».
• 4. Системное тестирование. Цель — проверка
правильности объединения и взаимодействия всех
элементов компьютерной системы, реализации всех
системных функций.
• Організація процесу тестування у вигляді еволюційної
розгортається спіралі забезпечує максимальну ефективність
пошуку помилок. Однак виникає питання - коли закінчувати
тестування?
• Відповідь практика зазвичай заснований на статистичному
критерії: «Можна з 95% -ою впевненістю сказати, що провели
достатню тестування, якщо ймовірність безвідмовної роботи ЦП з
програмним виробом протягом 1000
годин становить щонайменше 0,995».
• Науковий підхід при відповіді на це питання полягає в застосуванні
математичної моделі відмов. Наприклад, для логарифмічною
моделі Пуассона формула розрахунку поточної інтенсивності
відмов де - поточна інтенсивність програмних відмов (кількість
відмов в одиницю часу); - початкова інтенсивність відмов (на
початку тестування); р - експоненціальне зменшення
інтенсивності відмов за рахунок виявляються і усуваються
помилок; t -Час тестування.
• За допомогою рівняння (8.1) можна передбачити зниження
помилок в ході тестування, а також час, потрібний для досягнення
допустимо низької інтенсивності відмов.
логарифмічна моделі Пуассона
 тестування елементів
• Об'єктом тестування елементів є найменша одиниця проектування ПС -
модуль. Для виявлення помилок в рамках модуля тестуються його найважливіші
керуючі шляху. Відносна складність тестів і помилок визначається як результат
обмежень області тестування елементів. Принцип тестування - «білий ящик»,
крок може виконуватися для набору модулів паралельно.
• Тестуванню піддаються:
•  інтерфейс модуля;
•  внутрішні структури даних;
•  незалежні шляхи;
•  шляхи обробки помилок;
•  граничні умови.
• Інтерфейс модуля тестується для перевірки правильності введення-виведення
тестової інформації. Якщо немає впевненості в правильному введенні-виведенні
даних, немає сенсу проводити інші тести.
• Дослідження внутрішніх структур даних гарантує цілісність даних, що
зберігається.
• Тестування незалежних шляхів гарантує одноразове виконання всіх операторів
модуля. При тестуванні шляхів виконання виявляються такі категорії помилок:
помилкові обчислення, некоректні порівняння, неправильний потік управління
[3].
• Найбільш загальними помилками обчислень є:
• 1) неправильний або незрозумілий пріоритет арифметичних операцій;
• 2) змішана форма операцій;
• 3) некоректна ініціалізація;
• 4) неузгодженість в поданні точності;
• 5) некоректне символічне уявлення виразів.
• Джерелами помилок порівняння і неправильних потоків управління є:
• 1) порівняння різних типів даних;
• 2) некоректні логічні операції і пріоритетність;
• 3) очікування еквівалентності в умовах, коли помилки точності роблять еквівалентність неможливою;
• 4) некоректне порівняння змінних;
• 5) неправильне припинення циклу;
• 6) відмова в виході при відхиленні ітерації;
• 7) Неправильне внесення змін до змінних циклу.
• Зазвичай при проектуванні модуля передбачають деякі помилкові умови. Для захисту від помилкових умов в модуль вводять шляху обробки
помилок. Такі шляхи теж повинні тестуватися. Тестування шляхів обробки помилок можна орієнтувати на такі ситуації:
• 1) донесення про помилку незрозуміло;
• 2) текст донесення не відповідає, помічені помилки;
• 3) втручання системних засобів реєстрації аварії сталося до обробки помилки в модулі;
• 4) обробка виняткового умови некоректна;
• 5) опис помилки не дозволяє визначити її причину.
• І, нарешті, перейдемо до граничного тестування. Модулі часто відмовляють на "межі". Це означає, що помилки часто відбуваються:
• 1) при обробці n -го елемента n -елементного масиву;
• 2) при виконанні m -й ітерації циклу з т проходами;
• 3) при появі мінімального (максимального) значення.
• Тестові варіанти, орієнтовані на дані ситуації, мають високу ймовірність виявлення помилок.
• Тестування елементів зазвичай розглядається як доповнення до етапу кодування. Воно починається після розробки тексту модуля. Так як модуль не
є автономною системою, то для реалізації тестування потрібні додаткові кошти, представлені на рис. 8.2.
• Додатковими засобами є драйвер тестування і заглушки. Драйвер -
керуюча програма, яка приймає вихідні дані ( InData ) І очікувані
результати ( ExpRes ) Тестових варіантів, запускає в роботу
тестовий модуль, отримує з модуля реальні результати ( OutData )
І формує донесення про тестування. Алгоритм роботи тестового
драйвера наведено на рис. 8.3.
• Заглушки заміщають модулі, які викликаються тестованим
модулем. Заглушка, або «фіктивна підпрограма», реалізує
інтерфейс підлеглого модуля, може виконувати мінімальну
обробку даних, імітує прийом і повернення даних.
• Створення драйвера і заглушок на увазі додаткові витрати, так як
вони не поставляються з кінцевим програмним продуктом.
• Якщо ці кошти прості, то додаткові витрати невеликі. На жаль,
багато модулі не можуть бути адекватно протестовані за
допомогою простих додаткових коштів. У цих випадках повне
тестування може бути відкладено до кроку тестування інтеграції (де
драйвери або заглушки також використовуються).
• Тестування елемента просто здійснити, якщо модуль має високу
зв'язність. При реалізації модулем тільки однієї функції кількість
тестових варіантів зменшується, а помилки легко передбачаються і
виявляються.
Програмне середовище для
тестування модуля
• Заглушки заміщають модулі, які викликаються тестованим
модулем. Заглушка, або «фіктивна підпрограма», реалізує
інтерфейс підлеглого модуля, може виконувати мінімальну
обробку даних, імітує прийом і повернення даних.
• Створення драйвера і заглушок на увазі додаткові витрати,
так як вони не поставляються з кінцевим програмним
продуктом.
• Якщо ці кошти прості, то додаткові витрати невеликі. На
жаль, багато модулі не можуть бути адекватно протестовані
за допомогою простих додаткових коштів. У цих випадках
повне тестування може бути відкладено до кроку
тестування інтеграції (де драйвери або заглушки також
використовуються).
• Тестування елемента просто здійснити, якщо модуль має
високу зв'язність. При реалізації модулем тільки однієї
функції кількість тестових варіантів зменшується, а помилки
легко передбачаються і виявляються.
 тестування інтеграції
• Тестування інтеграції підтримує збірку цільної програмної системи.
• Мета побудови та тестування інтеграції: взяти модулі, протестовані
як елементи, і побудувати програмну структуру, необхідну
проектом [3].
• Тести проводяться для виявлення помилок
інтерфейсу. Перерахуємо деякі категорії помилок інтерфейсу:
•  втрата даних при проходженні через інтерфейс;
•  відсутність в модулі необхідної посилання;
•  несприятливий вплив одного модуля на інший;
•  подфункции при об'єднанні не утворюють необхідну
головну функцію;
•  окремі (допустимі) неточності при інтеграції виходять за
допустимий рівень;
•  проблеми при роботі з глобальними структурами даних.
• Існує два варіанти тестування, що підтримують процес інтеграції:
спадний тестування і висхідне тестування. Розглянемо кожен з них.
 Спадне тестування інтеграції
• В даному підході модулі об'єднуються рухом
зверху вниз по керуючої ієрархії, починаючи від
головного керуючого модуля. Підлеглі модулі
додаються в структуру або в результаті пошуку в
глибину, або в результаті пошуку в ширину.
• Розглянемо приклад (рис. 8.4). Інтеграція
пошуком в глибину буде підключати всі модулі,
що знаходяться на головному керуючому шляху
структури (по вертикалі). Вибір головного
керуючого шляху частково довільний і залежить
від характеристик, які визначаються
Наприклад, при виборі лівого шляху насамперед
будуть підключені модулі Ml ,
М 2, М5. Наступним підключається модуль М8 або
Мб (якщо це необхідно для правильного
функціонування М 2). Потім будується
центральний або правий керуючий шлях.
При інтеграції пошуком в ширину структура
послідовно проходиться по рівням-
горизонталях. На кожному рівні підключаються
модулі, безпосередньо підлеглі керуючому
модулю - начальнику. В цьому випадку перш за
все підключаються модулі М 2, М 3 , М4. На
наступному рівні - модулі М5, Мб і т. Д.
Низхідна інтеграція системи
• Опишемо можливі кроки процесу низхідній
інтеграції.
• 1. Головний керуючий модуль
(знаходиться на вершині ієрархії)
використовується як тестовий драйвер. Все
безпосередньо підлеглі йому модулі тимчасово
заміщуються заглушками.
• 2. Одна з заглушок замінюється
реальним модулем. Модуль вибирається
пошуком в ширину або в глибину.
• 3. Після підключення кожного модуля (і
установки на ньому заглушок) проводиться
набір тестів, перевіряючих отриману структуру.
• Якщо в модулі-драйвер вже немає заглушок,
проводиться заміна модуля-драйвера
(пошуком в ширину або в глибину).
• 5. Виконується повернення на крок 2
(до тих пір, поки не буде побудована ціла
структура).
• переваги низхідній інтеграції: помилки в
головній, керуючої частини системи
виявляються в першу чергу.
• недоліки: труднощі в ситуаціях, коли для
повного тестування на верхніх рівнях потрібні
результати обробки з нижніх рівнів ієрархії.
• Існують 3 можливості боротьби з цим недоліком:
• 1) відкладати деякі тести до заміщення заглушок модулями;
• 2) розробляти заглушки, частково виконують функції модулів;
• 3) підключати модулі рухом знизу вгору.
• Перша можливість викликає складності в оцінці результатів
тестування.
• Для реалізації другої можливості вибирається одна з наступних
категорій заглушок:
•  заглушка А - відображає трассируемого повідомлення;
•  заглушка В - відображає проходить параметр;
•  заглушка С - повертає величину з таблиці;
•  заглушка D - виконує табличний пошук по ключу
(вхідному параметру) і повертає пов'язаний з ним вихідний
параметр.
категорії заглушок
• Очевидно, що заглушка А найбільш проста,
а заглушка D найбільш складна в
реалізації.
• Цей підхід працездатний, але може
привести до істотних витрат, так як
заглушки стають все більш складними.
 Висхідне тестування інтеграції
• При висхідному тестуванні інтеграції сборка и
тестування системи починаються з модулів-атомів, які
розташовані на нижніх рівнях ієрархії.Модулі
підключаються рухом знизу вгору. Підлеглі модулі
завжди доступні, і немає необхідності в заглушках.
• Розглянемо кроки методики висхідній інтеграції.
• 1. Модулі нижнього рівня об'єднуються в
кластери (групи, блоки), які виконують певну програмну
подфункцию.
• 2. Для координації вводів-висновків тестового
варіанту пишеться драйвер, керуючий тестуванням
кластерів.
• 3. Тестується кластер.
• 4. Драйвери видаляються, а кластери
об'єднуються в структуру рухом вгору. Приклад
висхідній інтеграції системи наведено на рис. 8.6.
Модулі об'єднуються в кластери 1,2,3. Кожен
кластер тестується драйвером. Модулі в
кластерах 1 і 2 підпорядковані
модулю Ма, тому драйвери D 1 і D 2
видаляються і кластери підключають прямо
до Ма. аналогічно драйвер D 3 видаляється
перед підключенням кластера 3 до
модулю Mb . В останню чергу до
модуля Мс підключаються модулі Ма і Mb
• Розглянемо різні типи драйверів:
•  драйвер А - викликає підлеглий
модуль;
•  драйвер В - посилає елемент даних
(параметр) з внутрішньої таблиці;
•  драйвер З -о тображает параметр з
підлеглого модуля;
•  драйвер D - є комбінацією
драйверів В і С.
• Очевидно, що драйвер А найбільш простий, а
драйвер D найбільш складний в
реалізації. Різні типи драйверів представлені
на рис. 8.7.
Різні типи драйверів
У міру просування інтеграції вгору необхідність у виділенні драйверів
зменшується. Як правило, в дворівневій структурі драйвери не потрібні.

Порівняння спадного і висхідного тестування інтеграції

Спадний тестування:
• 1) основний недолік не обходимо заглушок і пов'язані з ними труднощі
тестування;
• 2) основна перевага - можливість раннього тестування головних
керуючих функцій.
Висхідне тестування:
• 1) основний недолік - система не існує як об'єкт до тих пір, поки не буде
додано останній модуль;
• 2) основна перевага - спрощується розробка тестових варіантів, відсутні
заглушки.
• Можливий комбінований підхід. У ньому для верхніх рівнів ієрархії
застосовують низхідну стратегію, а для нижніх рівнів - висхідну стратегію
тестування [3], [13].
• При проведенні тестування інтеграції дуже важливо виявити критичні
модулі. Ознаки критичного модуля:
ЛІТЕРАТУРА:
1. С. А. Орлов Технология разработки
программного обеспечения.
Разработка сложных программных
систем. Питер 2003 г.
2. С. А. Орлов Програмная инженерия
Питер 2016 г.

• Вивчити:
1. Методики тестування програмних
систем.

Опрацювати [1] Глава 8, [2]

Глава 16