Змістовий модуль 8. Тестування програмних модулів

Лекція 14. Метиди тестування

Література:1 [136-175]; 3[116-166]; 3[354-387];11

Призначення тестування. Види тестування. Методи тестування чорного та білого ящику. Тестування модулів. Драйвери і заглушки.

Основні визначення

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

Тестові дані – входи, які використовуються для перевірки системи.

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

Добра тестова ситуація – така ситуація, яка має велику ймовірність виявлення поки ще невиявленої помилки.

Успішний тест – тест, що виявляє поки ще невиявлену помилку.

Тестування не може показати відсутність дефектів.

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

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

• якість і надійність ПЗ задовільні,

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

Усунення виявлених користувачем помилок обходиться розробнику в 60-100 разів дорожче, ніж усунення їх на етапі налагодження. Дуже важливе питання – коли закінчити тестування.

На практиці використовують наступний критерій: «Якщо ймовірність безвідмовної роботи програмного виробу протягом 1000 годин становить щонайменше 0.995, то можна з 95% впевненістю сказати, що проведено достатнє тестування». Методи тестування «чорного» і «білого ящика» Існують два принципи тестування програми:

• функціональне тестування (тестування «чорного ящика»);

• структурне тестування (тестування «білого ящика»).

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

Рис. 14.1 Тестування методом «чорного ящика»

Тести демонструють:

· як виконуються функції програми;

· як приймаються вихідні дані;

· як виробляються результати;

· як зберігається цілісність зовнішньої інформації.

Вичерпне тестування, як правило, неможливо, тестування не реагує на багато особливостей програмних помилок.

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

Рис. 14.2 Тестування методом «білого ящика»

Вичерпне тестування також важко реалізувати.

Тестування модулів

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

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

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

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

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

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

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

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

Драйвери можуть бути наступних типів:

• драйвер типу А – тільки викликає підлеглий модуль;

• драйвер типу В – посилає елемент даних (параметр); - драйвер типу С – відображає параметр із підлеглого модуля;

• драйвер типу D – є комбінацією драйверів В та С.

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

Використовують наступні типи заглушок:

• заглушка типу А – імітує звернення до підлеглого модуля;

• заглушка типу В – здатна прийняти дані, з якими викликається підлеглий модуль;

• заглушка типу С – моделює роботу підлеглого модуля, відповідаючи на виклик передачею деяких фіксованих даних, які модуль, що тестується, використовує як результат виклику підлеглого модуля;

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

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

1. Що таке тестування?

2. Які тестові варіанти вважаються добрими й успішними?

3. Що розуміють під надійністю програмного продукту?

4. Яку інформацію можна одержати в результаті тестування?

5. У чому особливості тестування методом «чорного ящика»?

6. У чому особливості тестування методом «білого ящика»?

7. Для чого розраховують прогноз надійності?

8. Чому вичерпне тестування методом «чорного ящика» дуже важко реалізувати?

9. Чому вичерпне тестування методом «білого ящика» дуже важко реалізувати?

10. У чому полягають переваги й недоліки методів тестування «білого й чорного ящиків»?

11. Що перевіряється при тестуванні модуля?

12. Які існують критерії закінчення процесу тестування?

13. Для чого використовуються драйвери при тестуванні?

14. Які типи драйверів ви знаєте?

15. Для чого використовуються заглушки при тестуванні?

16. Які типи заглушок ви знаєте?

17. Що на вашу думку легше створити – драйвер або заглушку?

18. Які методи тестування («білого або чорного ящиків»), на вашу думку, роблять процес налагодження більш швидким?

Лекція 15. Об’єктно-орієнтоване тестування

Література: 1 [136-175]; 3[116-166]; 3[354-387];11

Особливості тестування об’єктно-орієнтованих систем. Тестування моделей. Тестування об’єктних модулів. Тестування об’єктної інтеграції. Простеження від функцій блоків до прецедентів.

Особливості тестування об'єктно-орієнтованих систем

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

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

1. Тестування моделей.

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

3. Тестування окремих класів об'єктів. Тут застосовне тестування методом «чорного ящика».

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

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

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

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

Про погодженість судять шляхом розгляду протиріч між елементами в моделі. Для такого дослідження зручно використовути модель Клас – Обов'язок – Співробітництво – CRC (Class – Responsibility – Collaboration). Основний елемент цієї моделі – CRC-карта .

Особливості тестування об'єктно-орієнтованих модулів

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

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

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

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

Тестування окремих методів

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

Розглянемо застосування класичного метода тестування «білого ящика» – тестування базового шляху. Метод дає можливість:

· одержати оцінку комплексної складності програми;

· використати цю оцінку для визначення необхідної кількості тестових варіантів.

Тестові варіанти гарантують однократне виконання кожного оператора програми при тестуванні.

Тестування окремих класів і кластерів класів

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

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

Тестування спадкування

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

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

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

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

· тестування сценаріїв і варіантів використання;

· тестування потоків;

· тестування взаємодії між об'єктами.

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

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

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

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

1. У чому полягають особливості тестування об'єктно-орієнтованих систем?

2. Які рівні тестування застосовні до об'єктно-орієнтованих систем?

3. Як організується тестування моделей?

4. Що еквівалентно модулю у випадку тестування об'єктно-орієнтованих систем? Що в цих умовах відповідає повному тестовому покриттю?

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

6. З яких класів слід починати тестування?

7. Як формуються кластери класів для тестування?

8. Які проблеми виникають при розробці тестових варіантів для тестування класів?

9. Як потрібно тестувати спадкування?

10. Як провести тестування на основі прецедентів?

11.

Приклад тестування класів для RTS- системи

Для нашого приклада можна починати тестування із класів Train, Way,

StationSpecification, Tariff, які мають мало зв’язків з іншими класами.

Розглянемо тестування класу Train. Очевидно, що клас повинен містити інформацію про кожний поїзд наступного виду:

· номер поїзда;

· початкова станція маршруту;

· кінцева станція маршруту;

· клас поїзду;

· час відправлення; · час прибуття.

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

Драйвер тестування повинен створити об'єкт Train і визначити групу тестових варіантів маршрутів для вибору відповідних номерів поїздів. На рис. 15.1 наведена схема тестування класу Train.

Рис. 15.1 Схема тестування класу Train.

Нижче наведена відповідна програма драйвера.

void main( )

{ Train t=new Train( ); //Створюємо екземпляр класу

//Раніше

int i, n;

cout<<”\n уведіть кількість тестових варіантів”; cin>>n; int mn=new int[n]; int nomer; char st1[20]; char st2[20]; char cl[20]; char date[8]; for(i=0;i<n;i++)

{cout<<”\n початкова станція”;cin>>st1; cout<<”\n кінцева станція”;cin>>st2; cout<<”\n клас поїзда”;cin>>cl; cout<<”\n дата відправлення”;cin>>date; mn[i]=t->getTrain(st1,st2,cl,date);

}

cout<<”\n результати тестування”;

for(i=0;i<n;i++)

cout<<”\n номер тестового варіанта “<<i<<” номер поїзду ”<<mn[i]; }

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