Метод покриття операторів

1 Тема роботи: Огляд методу покриття операторів тестування ПЗ

2 Мета роботи: Знайомство з методами тестування логіки програми (методами покриття), створення формалізованого опису результатів тестування й проведення тестування на реальному прикладі програмного коду.

3 Опис робочого місця: На кожному робочому місці повинен бути комп`ютер з операційною системою Windows.

4 Теоретичний матеріал:

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

а) постановка завдання для тесту,

б) проектування тесту,

в) написання тестів,

г) тестування тестів,

д) виконання тестів,

е) вивчення результатів тестування.

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

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

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

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

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

IF (A+B+C)/3=A,

де воно буде вірним не для всіх значень A, B і З (помилка виникає в тому випадку, коли із двох значень В або З одне більше, а інше на стільки ж менше А). Якщо концентрувати увагу тільки на тестуванні шляхів, немає гарантії, що ця помилка буде виявлена.

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

Методи стратегії 'білого ящика'

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

Метод покриття операторів

Метою цього методу тестування є виконання кожного оператора програми хоча б один раз.

Приклад:

Рисунок - 2.1 Рисунок – 2.2

 

У цій програмі можна виконати кожен оператор, записавши один єдиний тест, що реалізував би шлях ace, т. е., якби на вході було: А=2, В=0, Х=3, кожен оператор виконався б один раз. Але цей критерій насправді гірше, ніж він здається на перший погляд. Нехай у першій умові замість “ and”®“or” і в другому замість “x>1”®“x<1” (блок-схема правильної програми наведена на рисунку 2.1, а неправильної - на рисунку 2.2). Результати тестування наведені в таблиці 2.1. Зверніть увагу: очікуваний результат визначається по алгоритму на малюнку 2.1, а фактичний - по алгоритму рисунка 2.2, оскільки визначається чутливість методу тестування до помилок програмування. Як видно із цієї таблиці, жодна із внесених в алгоритм помилок не буде виявлена.

 

Таблиця 2.1 - Результат тестування методом покриття операторів

Тест	Очікуваний результат	Фактичний результат	Результат тестування
A=2, B=0, X=3	X=2,5	X=2,5	неуспішно

 

5 Хід виконання роботи:

5.1. Як основу для виконання завдання взяти програмний код, реалізований у лабораторній роботі № 1 відповідно до завдання викладача.

5.2. Як схему програми взяти діаграму дії (UML activity), реалізовану в ході виконання лабораторної роботи № 1, а також граф керування по метриці Маккейба.

5.3. Позначити буквами або цифрами галузі алгоритму на графі керування або діаграмі дій (UML activity).

5.4. Виписати шляхи алгоритму, які повинні бути перевірені тестами для даного методу тестування.

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

5.6. Протестувати розроблену Вами програму. Результати оформити у вигляді таблиць. Виводи за результатами тестування: а) кількість виявлених помилок у програмі; б) час, витрачений на тестування програми; в) який тест привів до виявлення помилки.

5.7. Оформити звіт по лабораторній роботі № 2.

Питання до захисту роботи:

Дайте визначення Мм-шляху Відповідь_______________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________