2 Графічні методи тестування
Графова модель класу, як й об’єктно-орієнтованої програми, на інтеграційному рівні як вузли використовує методи. Дуги даного ГМП (виклики методів) можуть бути утворені двома способами:
-
Прямим викликом одного методу з коду іншого, у випадку, якщо викликуваний метод видний (не закритий для доступу засобами мови програмування) із класу, що містить викликаючий метод, привласнимо такій конструкції назву Р-путь (P-path, Procedure path, процедурний шлях) .
-
Обробкою повідомлення, коли явного виклику методу нема, але в результаті роботи "викликаючого" методу породжується повідомлення, що повинне бути оброблене "викликуваним" методом.
Для другого випадку "викликуваний" метод може породити інше повідомлення, що приводить до виникнення ланцюжка виконання послідовності методів, зв'язаних повідомленнями. Подібний ланцюжок зветься Мм-шлях (MM-path, Metod/Message path, шлях метод/повідомлення). Мм-шлях закінчується, коли досягається метод, що при відпрацьовуванні не виробляє нових повідомлень (тобто виробляє "повідомлення спокою").
Приклад Мм-шляхів наведений на малюнку 6.1.
Рис. 6.1. Приклад MM-шляхів й P-шляхів у графової моделі класу
Дана конструкція відбиває керовану подіями природу об’єктно-орієнтованого програмування й може бути взята як основа для побудови графової моделі класу або об’єктно-орієнтованої програми в цілому. На малюнку 6.1 можна виділити чотири Мм-шляхи (1-4) і один P-шлях (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
Тут клас зображений як об'єднана безліч методів.
Уведемо наступні позначення:
Kmsg - число методів класу, що обробляють різні повідомлення;
Kem - число методів класу, які не закриті від прямого виклику з інших класів програми.
Якщо розглядати клас як програму P, то можна виділити наступні відмінності від програми, побудованої по процедурному принципі:
Значення Kext (число точок входу, які можуть бути викликані ззовні) визначається як сума методів - оброблювачів повідомлень Kmsg і тих методів, які можуть бути викликані з інших класів програми Kem. Це визначається самим розроблювачем шляхом розмежування доступу до методів класу (за допомогою ключових слів розмежування доступу public, private, protect ) при написанні методів, а також призначенні дружніх ( friend ) функцій і дружніх класів. Таким чином, Kext = Kmsg + Kem, і має новий у порівнянні із процедурним програмуванням фізичний зміст.
Принцип з'єднання вузлів у ГМП, що відбиває два можливих типи викликів методів класу (через Мм-шляхи й Р-шляхи ), що приводить до нового наповнення для безлічі М необхідних елементів.
Методи (модулі) непрозорі для зовнішніх об'єктів, що спричиняє незастосовність механізму спрощення графа модуля, використовуваного для одержання графа викликів у процедурному програмуванні.
З урахуванням наведених зауважень, інформаційні зв'язки між модулями програмного проекту одержують новий фізичний зміст, а формула оцінки складності інтеграційного тестування класу Cls приймає вид: V(Cls, C) = f (Kmsg, Kem)
У ході інтеграційного тестування повинні бути перевірені всі можливі зовнішні виклики методів класу, як безпосередні обіги, так і виклики, ініційовані одержанням повідомлень
Дані - члени класу (дані, описані в самому класі, і успадковані від класів-батьків видимі ззовні дані) розглядаються як "глобальні змінні", вони повинні бути протестовані окремо на основі принципів тестування потоків даних.
Коли клас програми P протестовано, об'єкт даного класу може бути включений у загальний граф G програмного проекту, що містить всі Мм-шляхи й всі виклики методів класів і процедур, можливі в програмі мал. 6.2
Програма P, що містить n класів, має складність інтеграційного тестування класів
Формальним поданням описаного вище підходу до тестування програмного проекту служить класова модель програмного проекту, що складає з дерева класів проекту мал. 6.3 і моделі кожного класу, що входить у програмний проект мал. 6.4.
Рис. 6.2. Приклад включення об'єкта в модель програмного проекту, побудованого з використанням MM-шляхів й P-шляхів
У такий спосіб і визначається класова модель проекту для тестування об’єктно-орієнтованої програми. Як буде показано надалі, вона підтримує ітераційний інкрементальний процес розробки програмного забезпечення.
Рис. 6.3. Дерево класів проекту
Рис. 6.4. Модель класу, що входить у програмний проект
Методика проведення тестування програми, представленої у вигляді класової моделі програмного проекту, містить у собі кілька етапів, що відповідають рівням тестування мал. 6.5:
-
На першому рівні проводиться тестування методів кожного класу програми, що відповідає етапу модульного тестування.
-
На другому рівні тестуются методи класу, які утворять контекст інтеграційного тестування кожного класу.
-
На третьому рівні протестований клас включається в загальний контекст (дерево класів) програмного проекту. Тут стає можливим відслідковувати реакцію програми на зовнішні події
Другий і третій рівні розглянутої моделі відповідають етапу інтеграційного тестування.
Для третього рівня важливим виявляється поняття атомарної системної функції (АСФ).
АСФ - це безліч, що складається із зовнішньої події на вході системи, реакції системи на цю подію у вигляді одного або більше Мм-шляхів і зовнішньої події на виході системи. У загальному випадку зовнішня вихідна подія може бути нульовою, тобто неакуратно написане програмне забезпечення може не забезпечувати зовнішньої реакції на дії користувача. АСФ, що складається із вхідної зовнішньої події, одного Мм-шляху й вихідної зовнішньої події, може бути взята як модель для нитки (thread). Тестування подібної АСФ у рамках класової моделі ГМП реалізується досить складно, тому що хоча динамічна взаємодія ниток (потоків) у процесі виконання природно фіксується в log-файлах, що запам'ятовують результати трасування виконання програм, воно ж достатно складно відображається на класовому ГМП (графі моделі програми). Причина в тім, що класова модель орієнтована на відображення статичних характеристик проекту, а в цьому випадку потрібне відображення поведінкових характеристик. Як правило, тестування взаємодії ниток у ході виконання програмного комплексу виноситься на рівень системного тестування й використовує інші, більше пристосовані для опису поводження моделі. Наприклад, опис поводження програмного комплексу засобами мов специфікацій MSC, SDL, UML.
Явний облік границь між інтеграційним і системним рівнями тестування дає перевагу при плануванні робіт на фазі тестування, а можливість сполучати різні методи й критерії тестування в ході роботи над програмним проектом дає найкращі результати.
Об’єктно-орієнтований підхід, що став у цей час неявним стандартом розробки програмних комплексів, дозволяє широко використати ієрархічну модель програмного проекту. Наведена на мал. 6.5 схема ілюструє спосіб застосування.
Кожен клас розглядається як об'єкт модульного й інтеграційного тестування. Спочатку кожен метод класу тестється як модуль за обраним критерієм C. Потім клас стає об'єктом інтеграційного тестування. Далі здійснюється інтеграція всіх методів всіх класів у єдину структуру - класову модель проекту, де в загальну ГМП протестовані модулі входять у вигляді вузлів (інтерфейсів виклику) без обліку їхньої внутрішньої структури, а їхні детальні описи утворять контекст усього програмного проекту.
Рис. 6.5. Рівні тестування класової моделі програмного проекту
Сама технологія об’єктно-орієнтованого програмування (одним з визначальних принципів якої є інкапсуляція з можливістю обмеження доступу до даних і методів - членам класу) дозволяє застосувати подібне трактування входження модулів у загальну ГМП. При цьому тести для окремо розглянутих класів перевикористаються, входячи в загальний набір тестів для програми P.