3 Об’єктно - орієнтоване тестування

Лекція 1 (2 години)

Тема : Інтеграційне тестування

Мета: ознайомити студентів з особливостями застосування методик тестування до об’єктно - орієнтованих програмних систем; визначити основні відмінності в тестуванні процедурно-орієнтованих та об’єктно - орієнтованих програмних систем.

Література:

1. Котляров В.П. „Основи тестування програмного забезпечення ” Інтернет – університет інформаційних технологій – ІНТУІТ.ру, 2006

2. Орлов С. А., „Технології розробки програмного забезпечення: Підручник для вузів ”. – Спб.: Пітер, 2004р.

Хід заняття

1. Організаційна частина

а) готовність групи до заняття;

б) психоемоційний настрій;

в) перевірка присутніх;

2. Актуалізація опорних знань студентів:

а) повідомлення теми та мети;

б) повідомлення основних тез теми.

3. Викладення нового матеріалу:

План лекції:

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

2. Розширення області застосування об’єктно – орієнтованого тестування.

3. Зміна методики при об’єктно – орієнтованому тестуванні.

4. Узагальнення та систематизація знань.

5. Підведення підсумків заняття.

6. Домашнє завдання: вивчити матеріал лекції.

7. Самостійне вивчення: опрацювати тему „Особливості інтеграційного тестування для об’єктно - орієнтованого програмування ” з Методичного посібника для самостійної роботи або з будь-якого іншого джерела (наприклад, мережі Інтернет).

Зміст лекції

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

Задача, що вирішується методом інтеграційного тестування – тестування міжмодульних зв’язків, що реалізуються при виконання програмного забезпечення комплексу. Інтеграційне тестування застосовує модель „білого ящика ” на модульному рівні. Інтеграційне тестування застосовується на етапі зборки модульно відтестованих модулів в єдиний комплекс. Відомі два методи зборки модулів:

• монолітний, що характеризується одночасним об’єднанням всіх модулів в комплекс, що тестується; його особливість в тому, що для заміни нерозроблених на час тестування модулів, крім самого верхнього, необхідно розробляти відповідні драйвери та/або заглушки.

• інктерментальний, що характеризується покроковим (помодульним) нарощенням комплексу програм з покроковим тестуванням комплексу, що збирається. В цьому методі виділяють дві стратегії додавання модулів: „зверху вниз ” (висхідне тестування) та „знизу вверх” (низхідне тестування).

Програмний проект, написаний відповідно до об’єктно - орієнтованого підходу, буде мати граф модулю програми (ГМП), що відрізняється від традиційної „процедурної програми”. Сама розробка програми відбувається по другому принципу – від визначення класів, що використовуються в програмі, побудови дерева класів до реалізації коду проекту. При правильному використанні класів, що точно відображають прикладну область додатку, цей метод дає більш короткі, зрозумілі програми, що легко контролюються.

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

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

Особливості об’єктно - орієнтованих систем вносять суттєві зміни як в послідовність етапів та і в їх зміст. Згрупуємо ці зміни по трьом напрямкам:

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

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

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

Розглянемо кожен з цих напрямків.

1. Розширення області застосування об’єктно - орієнтованого тестування.

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

1)правильність. Про синтаксичну правильність судять по правильності використання мови моделювання (наприклад, UML). Про семантичну правильність судять по відповідності моделі реальним проблемам (для визначення цього застосовуються знання та досвід експертів в даній ПО);

2)погодженість. Про це судять шляхом розгляду протиріч між елементами в моделі. Непогоджена модель має в одній частині уявлення, що суперечать уявленням в інших частинах моделі; для оцінки погодженості потрібно дослідити кожен клас та його взаємодію з іншими класами. Для спрощення такого дослідження зручно використовувати модель Клас – Обов’язок – Співробітництво (CRC Class— Responsibility — Collaboration), основним елементом якої є CRC – карта. По суті CRC- карта – це розкреслена картка розміром 6 на 10 см. Вона допомагає встановити задачі класу та виявити його оточення (класи - співбесідники).

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

CRC – карта спеціально зроблена простою, навіть її обмежений розмір має зміст: якщо список обов’язків та співробітництв не вміщується на карті, то мабуть, даний клас потрібно розділити на декілька класів. Для оцінки моделі (діаграми) класів на основі CRC – карт рекомендуються наступні кроки:

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

2. досліджуються обов’язки CRC- карти з метою визначити, чи передбачений в картці співробітника обов’язок, який делегується йому з даної карти. Наприклад, в табл. 3.1 показана CRC – карта банкомата. Для цієї карти з’ясовується, чи виконується обов’язок Читати карту клієнта, який потребує використання співробітника Карта клієнта. Це означає, що клас Карта клієнта повинен мати операцію, що дозволяє йому бути прочитаним.

Таблица 3.1. CRC-карта Банкомат

Ім’я класу : Банкомат Обов’язки:	Співробітники:
Читати карту клієнта Ідентифікація клієнта Перевірка рахунку Видача готівки Видача квитанцій Захват карти	Карта клієнта База даних клієнтів База даних рахунків Блок готівки Блок квитанцій Блок карт

3. організується прохід по кожному з’єднанню CRC – карти. Перевіряється коректність запитів, що виконуються через з’єднання. Така перевірка гарантує, що кожен співробітник, який надає послугу, отримує обґрунтований запит. Наприклад, якщо виникла помилка і клас База даних клієнтів отримує запит на від класу Банкомат на Стан рахунку, він не може його обробити, т.я. не має відповідного методу.

4. визначається, чи є потреба в інших класах, або чи правильно розподілені обов’язки по класам. Для цього використовують проходи по з’єднанням, досліджені на 3-му кроці.

5. визначається, чи потрібно об’єднувати обов’язки, що часто запитуються. Наприклад, в будь-якій ситуації використовують пару обов’язків – Читати карту клієнта та Ідентифікація клієнта. Їх можна виділити в новий обов’язок – Перевірка клієнта, який передбачає як читання його карти так і ідентифікацію клієнта.

6. кроки 1-5 застосовуються ітеративно, до кожного класу та на кожному кроці еволюції об’єктно – орієнтованої моделі.