Тема 3.1 Особливості інтеграційного тестування для об’єктно-орієнтованого програмування

Завдання: законспектувати тему до зошита у вигляді відповідей на контрольні запитання, що містяться в кінці теми.

Тестування об'єктно-орієнтованих програмних засобів (ООПЗ) має ряд істотних відмінностей від класичного тестування:

-розширення області застосування тестування;

-зміна методики тестування;

-облік особливостей ООП при проектуванні тестових варіантів.

Розширення області застосування. Розробка об'єктно-орієнтованого програмного засобу починається зі створення його візуальних моделей.

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

Критерії тестування моделей. Моделі розроблювальної системи повинні задовольняти критеріям:

-синтаксичної й семантичної правильності,

-повноти,

-погодженості.

Правильність моделі. Синтаксична правильність пов'язана з коректним використанням нотацій язика опису моделей.

Семантична правильність визначається відповідністю моделі реальній системі й пов'язаної з нею завданню. Тестування підтверджує, що модель правильна у відношенні конкретного тестового випадку, якщо результат його виконання є очікуваним.

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

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

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

Методи повинні тестуватися в контексті приватних властивостей і операцій класу.

Тестування класів

Автономне тестування класу припускає розробку драйвера, що буде:

-створювати екземпляри классу, що тестується;

-викликати методи классу, що тестується, й передавати їм фактичні параметри з тестових варіантів;

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

Екземпляри окремих класів активно взаємодіють між собою.

Створення драйвера для автономного тестування класу може виявитися не менш складним завданням, ніж розробка самого класу.

Рішення про автономне тестування класу приймається з урахуванням наступних факторів:

-ролі класу в системі;

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

-обсягу трудозатрат, пов'язаних з розробкою тестового драйвера.

Види взаємодії класів:

1. Метод одного класу містить у списку своїх формальних параметрів імена інших класів.

2. Метод одного класу створює екземпляр іншого класу як частину своєї реалізації

3. Метод одного класу посилається на глобальний екземпляр іншого класу

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

Особливості методики інтеграційного тестування об'єктно-орієнтованих систем. Тестування кластерів і потокове тестування. Тестування інтеграції

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

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

Основне завдання - виділення підмножини взаємодіючих класів.

Види взаємодії класів:

1. Метод одного класу містить у списку своїх формальних параметрів імена інших класів.

2. Метод одного класу створює екземпляр іншого класу як частину своєї реалізації

3.Метод одного класу посилається на глобальний екземпляр іншого класу

Найбільш популярними є наступні методики тестування інтеграції об'єктно-орієнтованих систем:

-тестування, засноване на потоках;

-кластерное тестування.

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

2)Кластерне тестування. Об'єктом тестування є кластер - набір класів, що співробітничають. Для виділення кластерів можна використати діаграми взаємодії, що відповідають окремим прецедентам.

Розмір кластера. При малих розмірах кластера неможливе відтворення в повному обсязі ефекту інтеграції (системного ефекту).

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

Середовище тестування. Тестування кластерів можна проводити:

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

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

Контрольні запитання:

1. Критерії тестування моделей ООПЗ.

2. Дайте поняття тестування класів.

3. Які фактори впливають на рішення про автономне тестування класів?

4. Які види взаємодії класів використовуються?

5. Дайте поняття тестуванню ООПЗ, заснованого на потоках.

6. Дайте визначення та призначення тестування кластерів.