Размещено на http://www.allbest.ru/

ЗМІСТ

ВСТУП

РОЗДІЛ 1. ТЕСТУВАННЯ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ

1.1 Основні поняття

1.2 Організація процесу тестування

1.3 Принципи тестування

РОЗДІЛ 2. ОБ'ЄКТНО-ОРІЄНТОВАНА МОДЕЛЬ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ

2.1 Об'єктно-орієнтована технологія в програмуванні

2.2 Основні принципи об'єктно-орієнтованого підходу

2.3 Переваги та недоліки

РОЗДІЛ 3. ОБ'ЄКТНО-ОРІЄНТОВАНЕ ТЕСТУВАННЯ

3.1 Особливості тестування

3.2 Методи тестування

3.3 Інтеграція об'єктів

3.4 Різновиди тестування

3.5 Інструментальні засоби тестування

РОЗДІЛ 4. ТЕСТУВАННЯ ІНФОРМАЦІЙНОЇ СИСТЕМИ «НАВЧАЛЬНО-МЕТОДИЧНИЙ РЕСУРС»

Висновок

Список літератури

Додаток



ВСТУП

За останні роки технології створення програмного забезпечення (ПЗ) стали основою різних розділів комп`ютерних наук як засіб подолання складності, що притаманна сучасним програмним системам.

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

Тестування програмного забезпечення проходить у кілька етапів:

1. тестування моделі програмного забезпечення;

2. тестування його класів;

3. перевірка взаємодії компонентів;

4. системне тестування;

5. приймальні випробування;

6. перевірка розгортання системи.

Відразу ж після остаточного формулювання технічного завдання до проекту починається етап проектування, тобто створення моделі розроблюваного програмного забезпечення. Для цього проводиться аналіз предметної області, що дозволяє врахувати помилки інших систем, подібних тій, що розробляється, і уточнити сумнівні нюанси розроблюваної системи, а також аналіз програми, тобто аналіз задачі і вимог до її вирішення. Результатом проектування є проектна модель системи, частіше всього представляється у вигляді UML-діаграми, яка і підлягає тестуванню. Тестуванню підлягають всі вхідні до складу моделі UML-діаграми, серед яких діаграми варіантів використання, діаграми класів, діаграми послідовності, діаграми станів та інші.

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

Досить багато матеріалів присвячено тому, як створюються інформаційні системи і реалізуються проекти з розробки програмного забезпечення. Автори можуть дотримуватися різних методологій розробки, сперечатися про переваги того чи іншого підходу в плануванні процесів або документуванні процедур, а також гнучкості останніх, проте загальна схема створення інформаційних систем досить проста і складається як правило з одних і тих самих модулів і процесів:

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

- постановка задачі у вигляді визначення вимог і наступних робіт з ними;

- управління змінами в проекті: зміна може стосуватися як безпосередньо самих вимог до системи, так і торкатися організаційної схеми процесу, і можуть породжуватися або самим Замовником (бізнес-аналітиком) або бути наслідком виявлених в ІС дефектів;

- розробка ПЗ, як безпосереднє кодування програмної реалізації функціональних вимог і проектування схем збереження і руху інформації в ІС;

- тестування ПЗ - процес, вирішальне завдання верифікації відповідності вимог висунутих до ІС та їх програмної реалізації;

- експлуатація ПЗ як сума завдань, спрямована на забезпечення технічної і технологічної підтримки процесу роботи ІС, включаючи підтримку і необхідне системне адміністрування.

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

Мета роботи -- розглянути детально процес тестування моделей об'єктно-орієнтованого програмного забезпечення, а також теоретично обґрунтувати основні положення даного процесу і перевірити їх практично на основі розробленої інформаційної системи «Навчально-методичний ресурс».

Відповідно до мети роботи необхідно вирішити основні завдання:

1. розглянути поняття «програмне забезпечення» та «інформаційні системи»;

2. ознайомитись із тестуванням програмного забезпечення;

3. проаналізувати організацію процесу тестування та його принципи;

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

5. провести тестування інформаційної системи «Навчально-методичний ресурс».

Об'єкт дослідження - поняття про «тестування інформаційної системи».

Предмет дослідження - процес тестування моделей об'єктно-орієнтованого програмного забезпечення.

Наукова новизна дослідження полягає в тому, що вперше здійснено ґрунтовний аналіз процесу тестування моделей об'єктно-орієнтованого програмного забезпечення, а також теоретично обґрунтовано основні положення даного процесу і перевірено їх практично на основі розробленої інформаційної системи «Навчально-методичний ресурс».

Структура роботи. Дипломна робота складається зі вступу, чотирьох розділів основної частини, висновків та списку використаних джерел.



РОЗДІЛ 1. ТЕСТУВАННЯ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ

1.1 Основні поняття

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

Якість програмного продукту характеризується набором властивостей, що визначають, наскільки продукт «хороший» з точки зору зацікавлених сторін, таких як замовник продукту, спонсор, кінцевий користувач, розробники і тестувальники продукту, інженери підтримки, співробітники відділів маркетингу, навчання і продажів. Кожен з учасників може мати різне уявлення про продукт і те, наскільки він хороший чи поганий, тобто про те, наскільки висока якість продукту. Таким чином, постановка задачі забезпечення якості продукту виливається у завдання визначення зацікавлених осіб, їх критеріїв якості і потім знаходження оптимального рішення, що задовольняє цим критеріям.

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

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

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

Тестування не є пошуком помилок у програмі! Розглянемо відмінності між пошуком помилок та тестуванням у Таблиці 1.1.

Таблиця 1.1

	Пошук помилок	Тестування
Мета	знайти найбільшу кількість багів;	пропустити як найменше критично важливих для користувача багів;
Тести	максимально нестандартні випадки;	стандартні;
Що тестується	найбільш нестабільні частини програми;	найбільш пріоритетні для користувача частини програми.

Основні класифікаційні ознаки тестування:

Ш за об'єктом тестування:

ь функціональне,

ь завантажувальне,

ь тестування безпеки,

ь тестування локалізації та інше;

Ш тестування за знанням системи:

ь чорний ящик (black box),

ь білий ящик (white box),

ь сірий ящик (grey box);

Ш за часом проведення:

ь альфа-тестування,

ь димове тестування,

ь регресійне тестування,

ь бета-тестування;

Ш за ступенем ізольованості:

ь компонентне,

ь інтеграційне,

ь системне.

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

Тестування - це процес виконання ПЗ системи або компонента в умовах аналізу або запису одержуваних результатів з метою перевірки (оцінки) деяких властивостей тестованого об'єкта. [11, c. 5]

Тестування - це процес аналізу пункту вимог до ПЗ з метою фіксації відмінностей між існуючим станом ПЗ і необхідним (що свідчить про прояв помилки) при експериментальній перевірці відповідного пункту вимог. [2, с. 13]

Тестування - це контрольоване виконання програми на кінцевій множині тестових даних та аналіз результатів цього виконання для пошуку помилок. [7, c. 27]

1.2 Організація процесу тестування

На сьогодні тестування програмного забезпечення - один з найбільш дорогих етапів життєвого циклу програмного забезпечення, на нього відводиться від 50% до 65% загальних витрат. У кодуванні ПЗ широкого розповсюдження набули різноманітні CASE-засоби, які дозволяють прискорити процеси створення коду. На жаль, в галузі тестування відчувається нестача таких засобів і більшість зусиль витрачається на ручне тестування.

Організація тестування (згідно Майерсу):

a) кожен тест повинен включати опис очікуваних результатів роботи програми, щоб можна було швидко з'ясувати наявність або відсутність помилок в ній;

b) бажано, щоб окрім автора тестування проводили і інші спеціалісти, оскільки виявлення недоліків в своїй діяльності протирічить людській психології (однак, відладка програми найефективніше виконується саме автором програми);

c) організація-розробник програмного забезпечення не повинна "одноосібно" тестувати ПП, потрібно організовувати бета-тестування з залученням інших організацій;

d) результати кожного тесту повинні бути документовані і детально вивчені, щоб не пропустити малопомітну на перший погляд помилку в програмі;

e) тести для неправильних (непередбачуваних) даних повинні підбиратися так само ретельно, як і для правильних (передбачуваних) вхідних даних;

f) при аналізі результатів кожного тесту необхідно перевіряти, чи не робить програма того, що вона не повинна робити;

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

h) тестування не повинно плануватися виходячи з припущення, що в програмі не будуть виявлені помилки (зокрема, слід виділяти на тестування достатньо часових і матеріальних ресурсів);

i) слід враховувати так званий "принцип накопичення помилок": вірогідність наявності не виявлених помилок в деякій частині програми прямо пропорційна числу помилок, вже виявлених в цій частині;

j) слід завжди пам'ятати, що тестування - творчий процес, і не варто ставитися до нього як до рутинного заняття.

Процес тестування об'єднує різні способи тестування в сплановану послідовність кроків, які приводять до успішної побудови програмної системи (ПС). Методика тестування ПС може бути представлена у вигляді спіралі, що розгортається (рисунок 1.1)

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

Рисунок 1.1. Спіраль процесу тестування

Розглянемо кожен крок процесу тестування:

1. Тестування елементів.

Мета -- індивідуальна перевірка кожного модуля. Використовуються способи тестування «білого ящика».

2. Тестування інтеграції.

Мета -- тестування збірки модулів в програмну систему. В основному застосовують способи тестування «чорного ящика».

3. Тестування правильності.

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

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

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

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

Отже, тестування - важлива частина будь-якої програми контролю якості, а часто і єдина. Це сумно, тому що різноманітні методики спільної розробки дозволяють знаходити більше помилок, ніж тестування, і в той же час обходяться більш ніж удвічі дешевше в розрахунку на одну виявлену помилку. Кожен з окремих етапів тестування (блочне тестування, тестування компонентів і інтеграційне тестування) зазвичай дозволяють знайти менше 50% помилок. Комбінація етапів тестування часто призводить до виявлення менше 60% помилок.

1.3 Принципи тестування

тестування програмний забезпечення інформаційний

Тестування не може показати відсутність дефектів (воно може показувати тільки присутність дефектів). Важливо пам'ятати це твердження при проведенні тестування.

Тестування забезпечує:

– виявлення помилок;

– демонстрацію відповідності функцій програми її призначенням;

– демонстрацію реалізації вимог до характеристик програми;

– відображення надійності як індикатора якості програми.

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

Види тестування:

Блокове тестування - це тестування повного класу, методу або невеликої програми, написаної одним програмістом або групою, що виконується окремо від інших частин системи.

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

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

Регресивне тестування - це повторне виконання тестів, спрямоване на виявлення дефектів у програмі, що вже пройшла цей набір тестів.

Тестування системи - це виконання ПЗ в його остаточній конфігурації, інтегрованої з іншими програмними та апаратними системами [20, c. 48].

Тестувати програмні додатки стає все важче, оскільки продовжує зростати їх технічна і функціональна складність. На жаль, технологія більшості процесів тестування не встигає за новими типами додатків. Виникає ризик невідповідності якості програм та бюджету проекту, процес тестування потребує перегляду.

Для більшості проектів цей процес включає тестування коду програми з очікуваними результатами. Потім розробники «фіксують» додаток до тих пір, поки він не забезпечить потрібний результат. Або відбувається коригування очікуваного результату, якщо виникла помилка. Такий підхід фокусується на коді програми та його поведінці на безлічі тестових умов. Виявляється, що ретельне тестування додатка вимагає великої кількості тестових умов. При такому підході до тестування передбачається, що якість програми є функцією від кількості тестів -- чим більше тестів, тим краща якість.

Кожен тест визначає:

– свій набір вихідних даних і умов для запуску програми;

– набір очікуваних результатів роботи програми.

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

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

Метою проектування тестових варіантів є систематичне виявлення різних класів помилок при мінімальних витратах часу і вартості.

Якщо у програміста запитати, який з етапів розробки ПЗ найменше схожий на інші, він напевно відповість: «Тестування». Більшість розробників відчувають при тестуванні труднощі з таких причин:

1) Мета тестування протилежна цілям інших етапів розробки. Його метою є знаходження помилок. Успішним вважається тест, що порушує роботу ПЗ. Всі інші етапи розробки спрямовані на запобігання помилок та недопущення порушення роботи програми.

2) Тестування ніколи не доводить відсутність помилок. Відсутність помилок може вказувати як на бездоганність програми, так і на неефективність або неповноту тестів.

3) Тестування не підвищує якості ПЗ - воно вказує на якість програми, але не впливає на нього.

Основні принципи тестування:

Принцип 1. Тестування виявляє присутність дефектів.

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

Принцип 2. Вичерпне тестування неможливе.

Тестування всього (усіх комбінацій введень і передумов) є неможливе за виключенням тривіальних випадків. Замість намагань, протестувати все, використовується аналіз ризиків та пріоритетів, що допомагає провести цілеспрямоване тестування.

Принцип 3. Раннє тестування.

Тестування розпочинається так швидко як це можливо і фокусується на визначенні цілей.

Принцип 4. Групування дефектів.

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

Принцип 5. Парадокс пестицидів.

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

Принцип 6. Тестування залежить від контексту.

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

Принцип 7. Відсутність дефектів оманлива.

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

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

Тестування забезпечує:

– виявлення помилок;

– демонстрацію відповідності функцій програми її призначенням;

– демонстрацію реалізації вимог до характеристик програми;

– відображення надійності як індикатора якості програми.

Тестування не може показати відсутність дефектів (воно може показувати тільки присутність дефектів). Важливо пам'ятати це твердження при проведенні тестування.

Процес тестування об'єднує різні способи тестування в сплановану послідовність кроків:

- тестування елементів (викор-ться «white-box»);

- тестування інтеграції (в основному «black-box»);

- тестування правильності (тільки «black-box»);

- системне тестування.

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



РОЗДІЛ 2. МОДЕЛЬ ОБ'ЄКТНО-ОРІЄНТОВАНОГО ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ

2.1 Об'єктно-орієнтовані моделі життєвого циклу

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

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

Таким чином це має бути методологія, яка включає в себе наступні компоненти: модель життєвого циклу, дії, нотація мови.

Фірма Rational Software, яка розробила мову UML, запропонувала так само і свою модель життєвого циклу, яка називається Rational Objectory Process (цей термін важкий для перекладу, тому що, по-перше, слово Rational має значення «раціональний» і назва фірми одночасно, по-друге, слова objectory немає в англійській мові, воно побудовано за аналогією зі словом repository (накопичувач)).

Можна перерахувати такі основні властивості даної технології:

§ процес інтерактивний, тобто відбувається послідовне уточнення результатів;

§ дії процесу спрямовані на створення моделей, а не інших елементів проекту, наприклад, текстових документів;

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

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

- початок (Inception);

- удосконалення (Elaboration);

- побудова (Construction);

- перехід (Transition).

2.2 Концепції об'єктно-орієнтованого підходу

При об'єктно-орієнтованому підході в якості будівельних блоків використовуються об'єкти, що містять свої власні коди і дані. Структура програм при об'єктно-орієнтованому підході представляється графом взаємодії об'єктів, а не деревом ієрархії, як це має місце в структурному проектуванні.

Об'єктно-орієнтований аналіз (object-oriented analysis) - це методологія, при якій вимоги до системи сприймаються з точки зору класів та об'єктів, виявлених у предметній області. Об'єктно-орієнтований аналіз спрямований на створення моделей реальної дійсності на основі об'єктно-орієнтованого підходу.

Об'єктно-орієнтоване проектування (object-oriented design) - це методологія проектування, що поєднує в собі процес об'єктної декомпозиції та прийоми представлення моделей, які відображають логічну (класи і об'єкти) і фізичну структуру системи (процеси і розподіл на компоненти, файли або модулі), а також її статичні й динамічні аспекти.

Об'єктно-орієнтоване програмування (object-oriented programming) - це технологія реалізації програм, заснована на представленні програми у вигляді сукупності об'єктів, кожний з яких є екземпляром певного класу, а класи утворюють ієрархію спадкування.

За результатами об'єктно-орієнтованого аналізу формуються моделі, на яких ґрунтується об'єктно-орієнтоване проектування, а воно, у свою чергу, створює фундамент для остаточної реалізації системи з використанням мовних засобів об'єктно-орієнтованого програмування.

Основна перевага об'єктно-орієнтованого підходу полягає в тому, що завдання вирішується новим способом. Замість формування набору процедур, призначених для вирішення конкретного завдання, формується набір об'єктів властивих даної предметної області. Якщо такий набір складається грамотно, то не тільки конкретне завдання може бути вирішене, але і потенційно закладається фундамент для вирішення всіх завдань в даній предметній області. Звичайно при структурному програмуванні такий підхід стихійно складався при розробці програм у вигляді бібліотек підпрограм по темам. Але об'єктно-орієнтований підхід дає нові механізми, перераховані нище (3 основні властивості об'єктно-орієнтованого підходу), які дозволяють створювати дійсно незалежні від завдання опису предметної області у вигляді набору об'єктів.

Основні властивості об'єктно-орієнтованого підходу:

Інкапсуляція - така властивість, при якій об'єкти містять опис атрибутів і дій одночасно.

Успадкування - такий метод визначення об'єктів, при якому похідні об'єкти (нащадки) успадковують властивості (атрибути та дії) від своїх батьків.

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

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

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

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

Можна сформулювати основні ключові принципи об'єктно-орієнтованого підходу:

o Що завгодно є об'єктом. Об'єкт можна представляти як своєрідну змінну: він містить дані, але водночас здатний виконувати певні дії над ними. Теоретично, будь-який елемент предметної області задачі може бути представлений в програмі як об'єкт.

o Програма - це комплекс об'єктів, які обмінюються повідомленнями. Щоб попросити об'єкт щось зробити, йому треба надіслати повідомлення. Більш конкретно, повідомлення можна представляти як виклик функції, яка є методом деякого об'єкту.

o Можна створювати нові типи об'єктів, використовуючи вже наявні. Ця можливість реалізується завдяки механізму спадкування.

o Кожний об'єкт має певний тип. Тип об'єкту визначається повідомленнями, які йому можна надсилати.

o Різні об'єкти певного типу можуть отримувати однакові повідомлення, реагуючи на них по-різному. Наприклад, оскільки об'єкт типу “коло” є одночасно об'єктом типу “форма”, успадковуючи його методи, то об'єкт “коло” гарантовано повинен приймати всі повідомлення, призначені для об'єкту “форма”. Реалізація такої можливості називається поліморфізмом об'єктів.

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

Об'єкт ООП - це сукупність змінних стану і пов'язаних з ними методів. Ці методи визначають, як об'єкт взаємодіє із зовнішнім світом.

2.3 Переваги та недоліки об'єктно-орієнтованого підходу

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

Переваги об'єктно-орієнтованого підходу:

Скорочення числа можливих помилок. Типові помилки при вирішенні різних завдань:

– неузгоджені параметри підпрограм

Часто може спостерігатися передача в підпрограму різних параметрів, неузгоджених один з одним. Нехай є підпрограма, що виводить на екран матрицю А розміром N x M. Її заголовок може бути таким: procedure ShowMatrix (A: TMatrix; N, M: integer); при виклику підпрограми, за рахунок помилки програміста, N і M можуть не відповідати реальному розміру матриці. Це завдання вирішується за рахунок інкапсуляції, коли N та M включаються в якості атрибутів в матрицю.

– неузгоджена зміна атрибутів

Нехай у матриці є поля даних, що характеризують поточний розмір матриці. Якщо метод вставки елемента не враховує можливу зміну розміру матриці, то може скластися така ситуація, коли вміст матриці і поля даних N M не відповідатимуть один одному.

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

– повторного використання існуючого коду для вирішення модифікованої завдання;

– повторне використання і для вирішення інших завдань у даній галузі.

В обох випадках об'єктно-орієнтований підхід дає переваги. За рахунок використання класів легко модифікувати існуючі елементи без зміни вже готових.

Недоліки об'єктно-орієнтованого підходу:

Ускладнення методології. Застосування об'єктно-орієнтованого підходу вимагає введення додаткових способів подання інформації про предметну область і методів її аналізу. Мова UML включає більше 100 різних умовних позначень. Для успішного використання подібного механізму потрібна наявність певного рівня кваліфікації у фахівців. Для невеликих проектів більш ефективним може виявитися застосування класичних методів розробки. Розробка проектів, для яких найважливішим завданням є опис предметної області, і для яких неможливо знайти людину, яка розуміє цю предметну область в цілому також вимагає використання традиційних підходів, на увазі їх більшої доступності для неспеціалістів.

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

При об'єктно-орієнтованому підході в якості будівельних блоків використовуються об'єкти, що містять свої власні коди і дані. Структура програм при об'єктно-орієнтованому підході представляється графом взаємодії об'єктів, а не деревом ієрархії, як це має місце в структурному проектуванні.

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

Основні властивості підходу:

Ш інкапсуляція;

Ш успадкування;

Ш поліморфізм.

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

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



РОЗДІЛ 3. ТЕСТУВАННЯ ОБ'ЄКТНО-ОРІЄНТОВАНИХ СИСТЕМ

3.1 Особливості тестування

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

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

Основні властивості об'єктів (інкапсуляція, успадкування, поліморфізм) додають нові аспекти тестування. Інкапсуляція створює проблему видимості даних, так як вони доступні тільки через операції. В процесі тестування це може створити певні проблеми з виведенням значень. Спадкування ставить питання про повторення тестування успадкованих операцій. Припустимо операція А належить базовому класу, і вона протестована. Операція В належить похідному класу і викликає операцію А. Чи повинна операція А тестуватися повторно? Поліморфізм призводить до неоднозначності з викликом операцій, яка може бути дозволена тільки на етапі виконання. Отже заздалегідь побудувати і спланувати набір тестів стає просто неможливим.

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

Формулюється кілька питань, які необхідно вирішити для успішного проведення тестування:

· яка частина успадкованих властивостей повинна заново тестуватися;

· коли і як можна перевіряти інформацію про стан класу;

· як можна перевірити поведінку системи, залежно від стану, коли відсутній єдиний механізм управління станами в програмі;

· як варто тестувати інтеграцію класів і які стратегії тестування застосовувати.

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

Стосовно до об'єктно-орієнтованих систем можна визначити чотири рівні тестування:

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

2. Тестування окремих класів об'єктів. Принцип тестування методом чорного ящика залишається без змін, однак, поняття "Класу еквівалентності" необхідно розширити.

3. Тестування кластерів об'єктів. Низхідна і висхідна зборки виявляються не придатними для створення груп пов'язаних об'єктів. Тому тут слід застосовувати інші методи тестування, наприклад засновані на сценаріях.

4. Тестування системи. Верифікація і атестація об'єктно-орієнтованої системи виконується точно так само, як і для будь-яких інших типів систем.



3.2 Методи тестування

Основною одиницею тестування повинен бути клас (об'єкт). Окремі методи класу марно розглядати у відриві від самого класу, а інші компоненти є зазвичай агрегацією класів. Призначення класу в системі (наприклад, абстрактний клас) визначає особливості його тестування. Клас являє собою набір атрибутів і методів (зазвичай частина з них прихована) і, отже, граф керування не застосуємо. Відзначимо основні риси нового модуля тестування:

- немає глобальних даних (або вони зведені до мінімуму у вигляді констант),

- клас не є тестованим елементом, тестуватися можуть тільки об'єкти, тобто екземпляри класу,

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

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

Тестування успадкування. Успадковані методи повинні бути протестовані заново при перевизначенні або доповненні базового методу. Це пов'язано з тим, що новий контекст атрибутів, нові аспекти поведінки можуть додати нові помилки. Таким чином якщо клас А є базовим для класу В, то спочатку тестуються всі методи класу А, потім все методи класу В причому так, що всі методи класу А, що викликаються з В тестуються заново.

Інкапсуляція, сама по собі, не є джерелом помилок, однак представляє перешкоду для проведення тестування, так як при тестуванні потрібне отримання повної інформації про стан класу, в тому числі і всіх його атрибутів, багато з яких можуть бути оголошені як «невидимі» ззовні. Вирішення цієї проблеми може бути знайдено у визначенні спеціальних оцінних методів, які повертають інформацію про стан класу або в використанні низькорівневих відладчиків програмного коду.

Тестування поліморфізму. Кожен можливий варіант поліморфного виклику методу повинен бути протестований. Прикладом такого випадку є клас А, що містить метод МА, що викликає в свою чергу поліморфний метод МАV. Тоді для будь-якого похідного класу В, перевизначеного метода MAV, повинен бути виконаний тест за викликом методу МА.

Тестування з урахуванням внутрішньої структури. Такий метод зазвичай називають "white-box testing" (метод "прозорого ящика"). Тестування виконується шляхом розгляду структури і визначення можливих тестових послідовностей. Існує два варіанти подібного тестування: тестування, засноване на інтерфейсі класу і тестування, засноване на методах класу. У першому випадку набір тестів складається так, щоб перевірити функціонування інтерфейсних властивостей об'єкта, таких як повідомлення і виключення. Основними методами складання тестів є аналіз графа передачі управління в рамках методів об'єкта, і аналіз потоку даних.

Тестування без урахування внутрішньої структури. Так зване тестування методом "чорної скриньки" ( "Black-box testing"). Набір тестів складається спираючись на специфікацію і вимоги до класу. Структура класу при цьому не аналізується. Треба враховувати, що будь-яка специфікація не відображає (і не повинна відображати) всіх деталей реалізації, тому аналіз програмного коду все ж буде потрібно. Тому, відмінності між "white-box" та "black-box" тестуванням зменшуються.

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

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

Тестування класів об'єктів. Підхід до тестового покриття систем вимагає, щоб всі оператори в програмі виконувалися хоча б один раз, а також, щоб виконувалися всі гілки програми. При тестуванні об'єктів повне тестове покриття включає: роздільне тестування всіх методів, асоційованих з об'єктом; перевірку всіх атрибутів, асоційованих з об'єктом; перевірку всіх можливих станів об'єкта (для цього необхідно моделювання подій, призводять до зміни стану об'єкта). Використання спадкування ускладнює розробку тестів для класів об'єктів. Якщо клас надає методи, успадковані від підкласів, то необхідно протестувати всі підкласи з усіма успадкованими методами. Поняття класів еквівалентності можна застосувати також і до класів об'єктів. Тут тестові дані з одного класу еквівалентності тестують одні й ті ж властивості об'єктів [5, 6].

Інтеграція класів для створення прикладної системи тісно переплітається із загальним підходом до розробки. Існують дві стратегії інтеграції: що базується на задачі і базується на використанні. Перша визначає весь ланцюжок класів, починаючи з головного (керуючого) класу і закінчуючи класами "виконавцями". Якщо кожен клас перевірений, то всі завдання вважаються протестованими. Інтеграція, заснована на використанні, застосовується коли існує кілька або взагалі не існує керуючих класів. Окремі класи використовують інші групи класів для виконання своїх завдань. Тестування такого виду інтеграції здійснюється шляхом виділення окремих груп класів, і тестування кожного класу, що використовує дану групу. Об'єктно-орієнтований підхід відрізняється тим, що з переходом на більш високий рівень ієрархії класів, обсяги робіт по створенню класу і, відповідно, можливості тестування зменшуються. Проблемою в цьому випадку є визначення того, коли слід тестувати успадковані властивості класу, інтеграцію класів. У кожному конкретному випадку слід складати план тестування

3.3 Інтеграція об'єктів

При розробці об'єктно-орієнтованих систем відмінності між рівнями інтеграції менш помітні, оскільки методи і дані компонуються (інтегруються) у вигляді об'єктів і класів об'єктів. Тестування класів об'єктів відповідає тестуванню окремих елементів. В об'єктно-орієнтованих системах немає безпосереднього еквівалента тестування модулів. Проте вважається, що групи класів, які спільно надають набір сервісів, слід тестувати разом [3, 6]. Такий вид тестування називається тестуванням кластерів.

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

Ш Тестування сценаріїв і варіантів використання. Варіанти використання або сценарії описують один режим роботи системи. Тестування може базуватися на описі цих сценаріїв і кластерів об'єктів, що реалізують даний варіант використання.

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

Ш Тестування взаємодій між об'єктами. Це метод тестування груп взаємодіючих об'єктів [4, 6]. Цей проміжний рівень тестування збирання системи заснований на визначенні шляхів "Метод-повідомлення", що відстежують послідовності взаємодій між об'єктами.

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

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



3.4 Різновиди тестування

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

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

Системне тестування виконується над проектом з допомогою методів «чорного ящика». Структура програми не має ніякого значення, для перевірки доступні тільки входи та виходи, що доступні користувачеві. Тестуванню підлягають коди та користувацька документація.

Категорії тестів системного тестування:

– повнота рішення функціональних задач;

– стресове тестування - на граничних обсягах навантаження вхідного потоку;

– коректність використання ресурсів (проблеми пам'яті, повернення ресурсів );

– оцінка працездатності;

– ефективність захисту від викривлення даних та некоректних дій;

– перевірка інсталяції та конфігурації на різних платформах;

– коректність документації.

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

Регресійне тестування. Це цикл тестування, який виконується при внесені змін на фазі системного тестування або супроводу продукту. Головною проблемою регресійного тестування є вибір між повним та частковим пере тестуванням та поповненням тестових наборів. При частковому пере тестуванні контролюються тільки ті частини проекту, що пов'язані зі зміненими компонентами. На ГМП - це шляхи, що містять змінені вузли та, як правило, це методи та класи, що лежать вище модифікованих по рівню, але такі що містять їх в своєму контексті. Пропуск великого об'єму тестів, що характерно для етапу системного тестування, вдається здійснити без втрат якісних показників продукту тільки з допомогою регресійного підходу. Отримавши звіт про помилку, програміст аналізує початковий код, знаходить помилку та виправляє її та модульно або регресійно тестує результат.

В свою чергу тестувальник, перевіряючи внесені програмістом зміни, повинен:

– перевірити та підтвердити виправлення помилки. Для цього необхідно виконати вказаний у звіті тест, з допомогою якого була знайдена помилка;

– спробувати відтворити помилку якимось іншим способом;

– протестувати наслідки виправлення. Можливо, що внесені виправлення привнесли помилку до коду, який до цього добре працював.

Комбінування рівнів тестування. В кожному конкретному проекті повинні бути певні задачі, ресурси та технології для кожного рівня тестування таким чином, щоб кожен з типів дефектів, що очікуються в системі, був «адресним», тобто, в загальному наборі тестів повинні бути тести, що направлені на виявлення дефектів подібного типу.



Таблиця 2

	Модульне	Інтеграційне	Системне
Типи дефектів	Локальні дефекти, такі як опечатки в реалізації алгоритму, неправильні операції, логічні та математичні вирази, цикли, помилки в використанні локальних ресурсів, рекурсія і т.п	Інтерфейсні дефекти, такі як неправильне трактування параметрів та їх формат, неправильне використання системних ресурсів та засобів комунікації.	Відсутня або некоректна функціональність, незручність використання, непередбачені дані та їх комбінації, непередбачені або не підтримані сценарії роботи, помилки сумісності, помилки користувацької документації помилки переносу на різні платформи, проблеми працездатності, інсталяції, інше.
Необхідність в системі тестування	Так	Так	Ні
Ціна розробки системи тестування	Низька	Низька до помірної	Помірна до високої або неприйнятної
Ціна процесу тестування	Низька	Низька	Висока

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

3.5 Інструментальні засоби тестування

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

1. Організатор тестів. Управляє виконанням тестів. Він відстежує тестові дані, очікувані результати та тестовані функції програми.

2. Генератор тестових даних. Генерує тестові дані для тестованої програми. Він може вибирати тестові дані з бази даних або використовувати спеціальні шаблони для генерації випадкових даних необхідного виду.

3. Оракул. Генерує очікувані результати тестів. В якості оракулів можуть виступати попередні версії програми або досліджуваного об'єкта. При тестуванні паралельно запускаються оракул і тестована програма і порівнюються результати їх виконання.

...