Читайте также:
|
Об’єктно - орієнтоване тестування
Лекція 1 (2 години)
Тема: Інтеграційне тестування
Мета: ознайомити студентів з особливостями застосування методик тестування до об’єктно - орієнтованихпрограмних систем; визначити основні відмінності в тестуванні процедурно-орієнтованих та об’єктно - орієнтованихпрограмних систем.
Література:
1. Котляров В.П. „Основи тестування програмного забезпечення ” Інтернет – університет інформаційних технологій – ІНТУІТ.ру, 2006
2. Орлов С. А., „Технології розробки програмного забезпечення: Підручник для вузів ”. – Спб.: Пітер, 2004р.
Хід заняття
Організаційна частина
а) готовність групи до заняття;
б) психоемоційний настрій;
в) перевірка присутніх;
2. Актуалізація опорних знань студентів:
а) повідомлення теми та мети;
б) повідомлення основних тез теми.
3. Викладення нового матеріалу:
План лекції:
1. Основні поняття інтеграційного тестування
2. Розширення області застосування об’єктно – орієнтованого тестування.
3. Зміна методики при об’єктно – орієнтованому тестуванні.
Узагальнення та систематизація знань.
Підведення підсумків заняття.
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 застосовуються ітеративно, до кожного класу та на кожному кроці еволюції об’єктно–орієнтованої моделі.
2. Зміна методики при об’єктно-орієнтованому тестуванні.
В класичній методиці тестування дії починається з тестування елементів, а закінчується тестуванням системи. Спочатку тестують модулі, потім тестують інтеграції модулів, перевіряється правильність реалізації вимог, після чого тестуються взаємодії всіх блоків комп’ютерної системи. При розгляді об’єктно–орієнтованого ПЗ змінюється поняття модулю. Найменшим елементом, що тестується є клас (об’єкт). Клас містить декілька операцій та властивостей, що змінює зміст тестування модулів, а будь-яку операцію необхідно розглядати не ізольовано, а як частину класу. Наприклад, уявімо ієрархію класів, в якій операція ОР() визначена для суперкласу та успадковується декількома підкласами, кожен з яких використовує операцію ОР(), але вона застосовується в контексті його приватних властивостей та операцій. Цей контекст змінюється, тому операцію ОР () потрібно тестувати в контексті кожного підкласу.
Висновки:
- тестування модулів традиційного ПЗ відповідає тестуванню класів ООПЗ;
- тестування традиційних модулів орієнтоване на потік керування всередині модулю та потік даних через інтерфейс модулю;
- тестування класів орієнтоване на операції, що інкапсульовані в класі, та стани в просторі поведінки класу.
2.1 Тестування об’єктно–орієнтованої інтеграції. ООПЗ не має ієрархічної управляючої структури, тому тут не можна застосовувати методики як висхідної так і низхідної інтеграції. Крім того, класичний прийом інтеграції (додавання по одній операції до класу) найчастіше нездійсненний. Дослідник Р.Байндер пропонує дві методики інтеграції об’єктно-орієнтованих систем:
- тестування, засноване на потоках;
- тестування, засноване на використанні.
В першій методиці об’єктом інтеграції є набір класів, що обслуговує одиничний ввід даних в систему, тобто засоби обслуговування кожного потоку інтегруються та тестуються окремо. По другій методиці спочатку інтегруються та тестуються незалежні класи. Далі працюють з першим шаром залежних класів (використовують незалежні), з другим шаром і т.д. На відміну від стандартної інтеграції, кругом де можна, уникають драйверів та заглушок. Розробник Д. МакГрегор вважає, що одним з кроків ОО тестування інтеграцій повинно бути кластерне тестування. Кластер класів, що співпрацюють, визначається дослідженням CRC – моделі або діаграми співпраці об’єктів. Тестові варіанти для кластера орієнтовані на знаходження помилок співробітництва.
2.2 Об’єктно – орієнтоване тестування правильності. При перевірці правильності зникають подробиці відношень класів. Підтвердження правильності ООПЗ орієнтоване на видимі дії користувача та розпізнання користувачем вихідних даних з системи. Для спрощення розробки тестів використовуються елементи Use Case, які є частиною моделі вимог. Кожен елемент Use Case задає сценарій, що дозволяє віднайти помилки у взаємодії користувача з системою. Для підтвердження правильності може проводитись звичайне тестування „чорного ящика”. Корисну для формування тестів правильності інформацію містять діаграми взаємодії, а також схем станів.
Графова модель класу, як і об’єктно-орієнтованої програми, на інтеграційному рівні в якості вузлів використовує методи. Дуги даної ГМП (виклики методів) можуть бути визначені двома способами:
- прямим викликом одного методу з коду іншого, в випадку, якщо метод, що викликається, видимий (не закритий для доступу засобами мови програмування) з класу, що містить метод, що викликає. Присвоїмо такій конструкції назву Р – шлях (P-path, Procedure path,);
- обробкою повідомлення, коли явного виклику методу немає, але в результаті роботи „методу, що викликає” породжується повідомлення, яке повинно бути оброблене „методом, що викликається”.
Для другого випадку „метод, що викликає” може породити інше повідомлення, що приводить до виникнення ланцюга виконання послідовності методів, пов’язаних повідомленнями. Такий ланцюжок називають ММ – шлях (MM-path, Metod/Message path). ММ – шлях закінчується, коли досягає методу, який при відпрацюванні не видає нових повідомлень.
Розглянемо приклад. На малюнку 3.1 зображена конструкція, яка відображає подійно-управляючу природу ООП та може бути використана в якості основи для побудови графової моделі класу або ОО системи в цілому.
|
Рис. 3.1 Приклад ММ-шляху та Р - шляху
В ході інтеграційного тестування мають бути перевірені всі можливості зовнішніх викликів методів класу, як безпосередні звернення, так і виклики, що ініційовані отриманим повідомленням. Значення числа ММ – шляхів залежить від схеми обробки повідомлень даним класом, що має бути визначене в специфікації класу. Дані – члени класу (дані, що описані в самому класі, та успадковані від класів-предків дані, що видимі зовні) розглядаються як „глобальні змінні” та мають бути опротестовані окремо на основі принципів тестування потоків даних. Коли клас програми Р протестований, об’єкт даного класу може бути включений в загальний граф програмного проекту, що містить всі ММ – шляхи та всі виклики методів класів та процедур, що можливі в програмі. Формальним представленням описаного вище підходу до тестування програмного проекту є класова модель програмного проекту, що складається з дерева класів та моделі кожного класу, що входить до програмного проекту.
Методика проведення тестування програми, що представлена у вигляді класової моделі програмного проекту, включає в себе декілька етапів, що відповідають рівням тестування:
- на першому рівні проводиться тестування методів кожного класу програми, що відповідає етапу модульного тестування;
- на другому рівні тестуються методи класу, що утворюють контекст інтеграційного тестування кожного класу;
- на третьому рівні протестований клас включається в загальний контекст (дерево класів) програмного проекту. Тут стає можливим відстежувати реакцію програми на зовнішні події.
Другий та третій рівні моделі, що розглядається, відповідають етапу інтеграційного тестування. Для третього рівня важливим є поняття атомарної системної функції (АСФ). АСФ – це множина, що складається з зовнішньої події на вході системи, реакції системи на цю подію в вигляді одного або більше ММ – шляхів та зовнішньої події на виході системи. В загальному випадку, зовнішня вихідна подія може бути нульова, тобто неакуратно написане розробником ПЗ може не забезпечувати зовнішньої реакції на дії користувача. АСФ, що складається з вхідної зовнішньої події, одного ММ –шляху та вихідної зовнішньої події, може бути взята в якості моделі для нитки (thread). Тестування подібної АСФ в рамках моделі ГМП реалізується достатньо складно, т.я. хоча динамічна взаємодія ниток (потоків) в процесі виконання природно фіксується в log-файлах, які запам’ятовують результати трасування виконання програми, воно ж достатньо складно відображається на класовій ГМП. Причина в тому, що класова модель орієнтована на відображення статичних характеристик проекту, а в даному випадку потрібне відображення характеристик поведінки. Як правило, тестування ниток в ході виконання програмного комплексу виноситься на рівень системного тестування та використовує інші більш пристосовані до описання поведінки моделі.
Явне врахування меж між інтеграційним та системним рівнями тестування дає перевагу при плануванні робіт на фазі тестування, а можливість поєднувати різні методи та критерії тестування в ході роботи над програмним проектом дає найкращий результат.
При використанні об’єктно-орієнтованого підходу кожен клас розглядається як об’єкт модульного та інтеграційного тестування. Спочатку кожен метод класу тестується як модуль по обраному критерію. Потім клас стає об’єктом інтеграційного тестування. Далі відбувається інтеграція всіх методів всіх класів в єдину структуру – класову модель проекту, де в загальну ГМП опротестовані модулі входять у вигляді вузлів (інтерфейсів виклику) без врахування їх внутрішньої структури, а їх детальні описання створюють контекст всього програмного проекту.
Лекція 2 (2 години)
Дата добавления: 2015-07-15; просмотров: 344 | Нарушение авторских прав
| <== предыдущая страница | | | следующая страница ==> |
| Bibliography | | | Підведення підсумків заняття. |