4.3 Організаційні аспекти процесу тестування

Під організацією проведення тестування розуміється:

- виділення об'єктів тестування

- проведення класифікації помилок для даного класу тестованих програм

- підготовка тестів, їх виконання і пошук різного роду помилок і відмов в компонентах і в системі в цілому;

- служба проведення і управління процесом тестування.

Об'єктами тестування можуть бути компоненти, групи компонентів, підсистема і система. Для кожного з них формується стратегія проведення тестування. Якщо об'єкт тестування відноситься до білої або чорної "скрині", склад компонентів якої невідомий, то тестування проводиться за допомогою введенням в нього вхідних тестових даних для отримання вихідних даних. Стратегічна мета тестування полягає в тому, щоб переконатися, що кожен даний ввідний набір даних соответствуeт очікуваним вихідним вихідних даним. При такому підході до тестування не вимагається знання внутрішньої структури і логіки об'єкту тестування.

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

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

Тому переважним є метод "білої скрині", при якому можна використовувати структуру об'єкту для організації тестування по різних гілках.

Наприклад, можна виконати тестові набори, які проходять через усі оператори або усі контрольні точки компоненти для того, щоб переконатися в правильності їх роботи.

Налагодження (debugging) — процес визначення, локалізації й усунення помилки у програмі, наслідки якої проявилися під час тестування. Процес налагодження починається після встановлення факту помилки у результаті тестування і складається з двох етапів:

• встановлення причини помилки та її локалізація (визначення місця розташування помилки у програмі);

• виправлення помилки та перевірка працездатності програми після проведеного коригування.

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

Таблиця 4.1 АНАЛІЗ ПОМИЛОК ЗА СТАДІЯМИ РОЗРОБКИ ПВ

Стадії проектування	Елементи, що перевіряються	Найбільш ймовірні причини і характер помилок
1. Технічне завдання	Постановка задачі Критерії ефективності та якості (мета) Специфікація системи (вимоги)	Нечіткість постановки Недосяжність Неповні специфікації Некоректне розуміння вимог користувача Неоднозначність тлумачення

Закінчення табл. 4.1

Стадії проектування	Елементи, що перевіряються	Найбільш ймовірні причини і характер помилок
2. Ескізне проектування	Структури вхідних та вихідних даних Схема зовнішніх функцій Функціональні специфікації Обробка виключних ситуацій	Неповні вхідні дані Неповна відповідність вимогам Неповні специфікації Недостатність проробки
3. Технічне проектування	Проектування програми (схема ієрархії функцій)	Наявність горизонтальних зв’яз­ків, порушення незалежності мо­дулів Нечіткість функціональної деком­позиції
	Алгоритм (псевдокод, таблиця рішень, логічна схема)	Неправильний математичний метод Некоректний алгоритм Неефективний алгоритм Логічні помилки Помилки ініціалізації змінних
	Проектування бази даних	Неправильно вибрана модель Помилки у визначенні елементів і структур даних Порушення зв’язків між структурами даних
	Тести	Недостатньо повний набір Неправильне розуміння специфіка­цій при виборі тестового набору Неузгодженість через дані Неадекватність
4. Робоче проектування	Взаємодія модулів	Незафіксовані зв’язки Помилки міжпрограмних інтерфейсів Зв’язки з системним програмним забезпеченням
	Текст програми	Неправильне тлумачення проектних документів Логічні помилки Порушення форматів вводу /виводу Втрата значності або точності Помилки запису математичних виразів Помилки у початкових настановах змінних Помилки в операціях маніпулювання даними
	Опис бази даних	Помилки ініціалізації БД Помилки індексування даних Способи звернення до БД
	Тести	Неправильне розуміння специфі­кацій при виборі тестового набору Некоректне використання тестових наборів Неправильна інтерпретація результатів тестування Неправильні висновки щодо причин та джерел помилок
5. Випро­бування	Остаточна документація Остаточний продукт (відповідність результатів специфікаціям)	Відсутність критерію придатності документації Невідповідність специфікаціям

Імовірність появи помилок залежить від багатьох чинників. До найбільш поширених помилок належать логічні помилки (20—35% від загальної кількості помилок), помилки маніпулювання даними, помилки зовнішніх і внутрішніх інтерфейсів, опису даних (кожна категорія від 5 до 20%) [6].

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

Серед інструментальних засобів налагодження найбільш поширеними можна вважати:

• компілятори відповідної мови програмування;

• вбудовані засоби мови програмування для перевірки типів, фор­матів, межових значень даних; для обробки виключних ситуацій;

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

• пакети програм для стеження за потоками управління та даними у програмі, контролю індексів і реєстрації звернень до підпрограм;

• генератори тестових даних та аналізатори результатів тестування;

• пакети словників/довідників даних для контролю імен і типів даних та їх використання різними модулями;

• CASE-засоби для побудови схем потоків даних, моделей даних, схем алгоритмів і т. ін.

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

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

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