Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Samrab_testuvannya.doc
Скачиваний:
0
Добавлен:
01.07.2025
Размер:
639.49 Кб
Скачать

Тема 3.3 Тестування поверхневої та поглибленої структури системи

Завдання: законспектувати тему до зошита у вигляді відповідей на контрольні запитання, що містяться в кінці теми.

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

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

Як базис для тестування глибинної структури використаються моделі аналізу й проектування. Наприклад, розроблювач досліджує діаграму взаємодії (невидиму ззовні) і запитує: « чи Перевіряє тест співробітництво, відзначене на діаграмі?»

Діаграми класів забезпечують розуміння структури спадкування, що використається в тестах, заснованих на помилках. Розглянемо операцію ОБРОБИТИ (Посилання_на_Родительскийкласс). Що відбудеться, якщо у виклику цієї операції вказати посилання на дочірній клас? Є чи розходження в поводженні, які повинні відбиватися в операції ОБРОБИТИ? Ці питання ініціюють створення конкретних тестів.

Контрольні запитання:

  1. Поняття поверхневої структури об'єктно-орієнтованої системи та особливості її тестування.

  2. Поняття глибинної структури об'єктно-орієнтованої системи та особливості її тестування.

Тема 3.4 Тестування взаємодії класів

Завдання: законспектувати тему до зошита у вигляді відповідей на контрольні запитання, що містяться в кінці теми.

Для тестування співробітництва класів можуть використатися різні способи :

- стохастичне тестування;

- тестування розбивок;

- тестування на основі сценаріїв;

- тестування на основі станів.

Як приклад розглянемо програмну модель банківської системи, до складу якої входять класи Банк, Банкомат, ІнтерфейсБанкомата, Рахунок, Робота з готівкою, ПідтвердженняПравильності, що мають наступні операції:

Банк:

ПроверитьСчет( );

ЗапросДепозита ( );

РазрешитьКарту( );

ПроверитьРIN( );

ИнфоСчета( );

СнятьРазрешен( );

ПроверитьПолис( );

ОткрытьСчет( );

ЗакрытьСчет( ).

ЗапросСнятия( );

НачальнДепозит( );

Банкомат:

КартаВставлена( );

Покласти( );

СостояниеСчета( );

Пароль( );

Зняти( );

Завершити( ).

ИнтерфейсБанкомата:

ПроверитьСостояние( );

ВыдатьНаличные( );

ЧитатьИнфоКарты( );

СостояниеПоложить( );

ПечатьСостСчета( );

ПолучитьКолвоНалич( ).

Счет:

ОграничКредит( );

Залишок) );

Покласти( );

ТипСчета( );

Зняти( );

Закрити( ).

ПодтверждениеПравильности:

ПодтвРIN( );

ПодтвСчет( ).

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

Мал. 3.1. Діаграма співробітництва банківської системи

Стохастичне тестування

Стохастичні тестові варіанти генеруються наступною послідовністю кроків.

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

Для кожного створеного повідомлення визначається клас-співробітник і відповідна операція в класі-сервері.

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

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

Як приклад приведемо послідовність операцій для класу Банк, викликуваних класом Банкомат:

ПроверитьСчет ►ПроверитьРIN ►[[ПроверитьПолис ►

ЗапросСнятия]●ЗапросДепозита●ИнфоСчета]n.

ПРИМІТКА

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

Випадковий тестовий варіант для класу Банк може мати вигляд

Тестовий варіант N: ПроверитьСчет ►ПроверитьРШ ►ЗапросДепозита.

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

Тестовий варіант М:

ПроверитьСчетБанк►(ПодтвСчетПодтвПрав)►ПроверитьРINБанк ►(ПодтвРШПодтвПрав) ►ЗапросДепозитаБанк ►(ПоложитьСчет).

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

Тестування розбивок

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

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

Тестування на основі станів

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

Мал. 3.2. Діаграма схем станів класу Рахунок

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

Проектовані тести повинні забезпечити покриття всіх станів. Це значить, що тестові варіанти повинні ініціювати переходи через всі стани об'єкта:

Тестовий варіант 1: Відкрити ►УстановитьСчет ►Покласти (початкове) ►Зняти (кінцеве) ►Закрити.

Відзначимо, що ця послідовність аналогічна мінімальної тестової послідовності. Додамо до мінімальної послідовності додаткові тестові варіанти:

Тестовий варіант 2: Відкрити ►УстановитьСчет ►Покласти (початкове) ►Покласти ►Залишок ►Кредит ►Зняти (кінцеве) ►Закрити

Тестовий варіант 3: Відкрити ►Установити ►Покласти (початкове) ►Покласти ►Зняти ►ИнфоСчета ►Зняти (кінцеве) ►Закрити

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

Можлива інша методика дослідження станів.— «переважно завширшки». У цій методиці:

- кожний тестовий варіант перевіряє один новий перехід;

- новий перехід можна перевіряти, якщо повністю перевірені всі попередні переходи, тобто переходи між попередніми станами.

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

Мал. 3.3. Тестування «переважно завширшки»

Підхід «переважно завширшки» вимагає: не можна перевіряти Дозволена перед перевіркою Не визначена, Визначена й Пред'являється на розгляд. У противному випадку порушується умова цього підходу: перед тестуванням поточного переходу повинні бути протестовані всі переходи, що ведуть до нього.

Контрольні запитання:

  1. Які способи використовуються для тестування взаємодії (співробітництва) класів?

  2. Дайте визначення та призначення стохастичного тестування.

  3. Розкажіть про метод тестування розбивок.

  4. Розкажіть про метод тестування на осонові станів.

  5. Наведіть приклад тестування взаємодії класів.

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]