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

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

Висновки:

• тестування модулів традиційного ПЗ відповідає тестуванню класів ООПЗ;

• тестування традиційних модулів орієнтоване на потік керування всередині модулю та потік даних через інтерфейс модулю;

• тестування класів орієнтоване на операції, що інкапсульовані в класі, та стани в просторі поведінки класу.

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

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

- тестування, засноване на використанні.

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

2.2 Об’єктно – орієнтоване тестування правильності. При перевірці правильності зникають подробиці відношень класів. Підтвердження правильності ООПЗ орієнтоване на видимі дії користувача та розпізнання користувачем вихідних даних з системи. Для спрощення розробки тестів використовуються елементи Use Case, які є частиною моделі вимог. Кожен елемент Use Case задає сценарій, що дозволяє віднайти помилки у взаємодії користувача з системою. Для підтвердження правильності може проводитись звичайне тестування „чорного ящика”. Корисну для формування тестів правильності інформацію містять діаграми взаємодії, а також схем станів.

Графова модель класу, як і обєктно- орієнтованої програми, на інтеграційному рівні в якості вузлів використовує методи. Дуги даної ГМП (виклики методів) можуть бути визначені двома способами:

• прямим викликом одного методу з коду іншого, в випадку, якщо метод, що викликається, видимий (не закритий для доступу засобами мови програмування) з класу, що містить метод, що викликає. Присвоїмо такій конструкції назву Р – шлях (P-path, Procedure path,);

• обробкою повідомлення, коли явного виклику методу немає, але в результаті роботи „методу, що викликає” породжується повідомлення, яке повинно бути оброблене „методом, що викликається”.

Для другого випадку „метод, що викликає” може породити інше повідомлення, що приводить до виникнення ланцюга виконання послідовності методів, пов’язаних повідомленнями. Такий ланцюжок називають ММ – шлях (MM-path, Metod/Message path). ММ – шлях закінчується, коли досягає методу, який при відпрацюванні не видає нових повідомлень.

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

На рисунку можна виділити 4 ММ – шляхи (1-4) та 1 Р – шлях (5)

msg a метод 3 msg 3 метод 4 msg d

msg b метод 1 msg 1 метод 4 msg d

msg b метод 1 msg 2 метод 5

msg c метод 2

call метод 5

Тут клас зображений як об’єднана множина методів.

Рис. 3.1 Приклад ММ-шляху та Р - шляху

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

Методика проведення тестування програми, що представлена у вигляді класової моделі програмного проекту, включає в себе декілька етапів, що відповідають рівням тестування:

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

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

• на третьому рівні протестований клас включається в загальний контекст (дерево класів) програмного проекту. Тут стає можливим відстежувати реакцію програми на зовнішні події.

Другий та третій рівні моделі, що розглядається, відповідають етапу інтеграційного тестування. Для третього рівня важливим є поняття атомарної системної функції (АСФ). АСФ – це множина, що складається з зовнішньої події на вході системи, реакції системи на цю подію в вигляді одного або більше ММ – шляхів та зовнішньої події на виході системи. В загальному випадку, зовнішня вихідна подія може бути нульова, тобто неакуратно написане розробником ПЗ може не забезпечувати зовнішньої реакції на дії користувача. АСФ, що складається з вхідної зовнішньої події, одного ММ –шляху та вихідної зовнішньої події, може бути взята в якості моделі для нитки (thread). Тестування подібної АСФ в рамках моделі ГМП реалізується достатньо складно, т.я. хоча динамічна взаємодія ниток (потоків) в процесі виконання природно фіксується в log-файлах, які запам’ятовують результати трасування виконання програми, воно ж достатньо складно відображається на класовій ГМП. Причина в тому, що класова модель орієнтована на відображення статичних характеристик проекту, а в даному випадку потрібне відображення характеристик поведінки. Як правило, тестування ниток в ході виконання програмного комплексу виноситься на рівень системного тестування та використовує інші більш пристосовані до описання поведінки моделі.

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

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

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

Тема: Різновиди тестування: системне та регресійне тестування

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

Література:

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

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

Хід заняття

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

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

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

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

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

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

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

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

План лекції:

1. Системне тестування

2. Регресійне тестування

3. Комбінування рівнів тестування

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

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

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

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