Зміст лекції

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

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

2. Поліморфізм. При виклику поліморфної функції важко визначити, яка реалізація буде перевірятися. Нехай потрібно перевірити виклик функції: y=functionA(x). В ООПЗ потрібно розглядати поведінку реалізації Базовий_клас:: y=functionA(x), Дочірній_клас :: y=functionA(x), Спадкоємець_Дочірнього_класу:: y=functionA(x). Тут подвійною двокрапкою від імені операції відділяється ім’я класу, в якому вона розміщена. Таким чином, в ОО контексті кожного разу при виклику y=functionA(x) необхідно розглядати набір різних поведінок.

3. Спадкування. Воно також може ускладнити проектування тестових варіантів. Нехай Батьківський_клас містить операції Успадкована() та Перевизначена (). Дочірній_клас перевизначає операцію Перевизначена () по своєму. Очевидно, що реалізація Дочірній_клас :: Перевизначена () має повторно тестуватися. Для операції Дочірній_клас :: Успадкована () може проводитися підмножина тестів. Батьківський_клас :: Перевизначена () та Дочірній_клас :: Перевизначена () – це дві різні операції з різними специфікаціями та реалізаціями. Кожна з них перевіряється самостійним набором тестів, що націлені на виявлення ймовірних помилок: помилок інтеграцій, помилок умов, граничних помилок і т.д.. Проте самі операції як правило, схожі. Набори їх тестів будуть перекриватися. Чим краща якість ООП, тим більше перекриття. Таким чином, нові тести потрібно сформувати тільки для тих вимог до операції Дочірній_клас :: Перевизначена (), які не покриваються тестами для операції Батьківський_клас :: Перевизначена ().

Висновки:

• тести для операції Батьківський_клас :: Перевизначена () можуть бути частково застосовані для операцій Дочірній_клас :: Перевизначена ();

• вхідні дані тестів підходять до операцій обох класів;

• очікувані результати для операції Батьківського_класу відрізняються від очікуваних результатів для операції Дочірнього_класу.

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

Способи тестування „чорного ящика” також застосовуються до об’єктно-орієнтованих систем. Корисну вхідну інформацію для тестування „чорного ящика” та тестування станів забезпечують елементи Use Case.

Тестування, засноване на помилках. Метою цього виду тестування є проектування тестів, що орієнтовані на знаходження помилок, що припускаються. Розробник видає гіпотезу про помилки, що припускаються. Для перевірки його припущень розробляються тестові варіанти. В якості прикладу розглянемо булевий вираз: if (X and not Y or Z).

Інженер з тестування будує гіпотезу про припущені помилки виразу:

• операція not зсунута вліво від потрібного місця (вона має застосуватись до Z);

• замість and має бути or;

• навколо not Y or Z мають бути дужки.

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

Обговоримо першу передбачувану помилку. Значення (X = false, Y = false, Z = false) встановлює вказаний вираз в false. Якщо замість not Y повинно бути not Z, то вираз прийме невірне значення, яке приводить до неправильного галуження. Аналогічні роздуми застосовуються до генерації тестів по іншим двом помилкам.

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

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

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

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

Тестування, засноване на сценаріях. Тестування, засноване на помилках, не враховує два важливих типи помилок:

- некоректні специфікації;

- взаємодія між підсистемами.

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

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

Тестування, засноване на сценаріях, орієнтоване на дії користувача, а не на дії програмної системи. Це означає фіксацію задач, які виконує користувач, а потім застосування їх в якості тестових варіантів. Задачі користувача фіксуються з допомогою елементів Use Case.

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

Робочі сценарії опишемо в вигляді специфікації елементів Use Case.

Елемент Use Case: Виправляти чернетку.

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

1. Друкувати весь документ.

2. Читати документ, змінити деякі сторінки.

3. Після внесення змін сторінка передруковується.

4. Іноді передруковується декілька сторінок.

Цей сценарій визначає як вимоги тестів, так і вимоги користувачів. Таким чином, користувачеві потрібні:

• метод для друку окремих сторінок;

• метод для друку діапазону сторінок.

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

Елемент Use Case: Друкувати нову копію.

Перед посилки: хтось просить користувача надрукувати нову копію документу.

1. Відкрити документ.

2. Надрукувати документ.

3. Закрити документ.

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

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

Елемент Use Case: Надрукувати нову копію

1. Відкрити документ.

2. Вибрати в меню пункт Друк

3. Перевірити, що друкувалося, та, якщо друкувався діапазон сторінок, то обрати опцію Друкувати цілий документ.

4. Натиснути кнопку Друк.

5. Закрити документ.

Цей сценарій вказує на можливу помилку специфікації: редактор не виконує того, що від нього чекає користувач. Замовники часто забувають про перевірку на кроці 3 та обурюються, коли замість очікуваних 100 сторінок знаходять 1. Вони вважають, що це помилка специфікації. Розробник може опустити цю залежність в тестовому варіанті, але, ймовірно, проблема буде знайдена в ході тестування.

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

Тема: Способи тестування змісту класу

Мета: ознайомити студентів з способами тестування змісту класу та визначити особливості тестування класів.

Література:

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

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

Хід заняття

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

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

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

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

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

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

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

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

План лекції:

1. Стохастичне тестування класів

2. Тестування розбиття на рівні класів

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

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

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

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