Хід виконання роботи:
5.1 За завданням викладача підготувати три програми (додаток А) на мовах програмування Java, C# на вибір студента. Вимоги до програм: наявність графічного інтерфейс.
5.2 Розробити діаграму дії (UML activity) для програмного коду.
5.3 Оформити звіт по лабораторной роботі №1.
Питання до захисту роботи:
Які діаграм містяться в пакеті Use Case View Відповідь____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________
Назвіть та поясніть, для чого застосовують основні конструктивні
елементи (абстракції) UML Відповідь_______________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________
Привести основні стереотипи UML-розширення WAE, які
використовуются для розширення можливостей пакету Logical View Відповідь_______________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________
Висновок
Лабораторна робота №2 тестування методами “білого ящика” метод покриття операторів
Тема роботи: Огляд методу покриття операторів тестування ПЗ
2 Мета роботи: Знайомство з методами тестування логіки програми (методами покриття), створення формалізованого опису результатів тестування й проведення тестування на реальному прикладі програмного коду.
3 Опис робочого місця: На кожному робочому місці повинен бути комп`ютер з операційною системою Windows.
Теоретичний матеріал:
Тестування програмного забезпечення охоплює цілий ряд видів діяльності, аналогічні послідовності процесів розробки програмного забезпечення. У нього входять:
а) постановка завдання для тесту,
б) проектування тесту,
в) написання тестів,
г) тестування тестів,
д) виконання тестів,
е) вивчення результатів тестування.
Вирішальну роль грає проектування тестів. Можливі різні підходи до проектування тестів. Перший полягає в тому, що тести проектуються на основі зовнішніх специфікацій програм і модулів, або специфікацій сполучення програми або модуля. Програма при цьому розглядається як чорний ящик (стратегія 'чорного ящика'). Суть такого підходу - перевірити чи відповідає програма зовнішнім специфікаціям. При цьому логіка модуля зовсім не приймається в увагу.
Другий підхід заснований на аналізі логіки програми (стратегія 'білого ящика'). Суть підходу - у перевірці кожного шляху, кожної галузі алгоритму. При цьому зовнішня специфікація в увагу не приймається.
Жоден із цих підходів не є оптимальним. З аналізу першого підходу ясно, що його реалізація зводиться до перевірки всіх можливих комбінацій значень на вході програми. Тестування будь-якої програми для всіх значень вхідних даних неможливо, тому що їхня нескінченна безліч, тому обмежуються меншим. При цьому виходять із максимальної віддачі тесту в порівнянні з витратами на його створення. Вона виміряється ймовірністю того, що тест виявить помилки, якщо вони є в програмі. Витрати виміряються часом і вартістю підготовки, виконання й перевірки результатів тесту.
Проанализируем тепер другий підхід до тестування. Навіть якщо припустити, що виконано тести для всіх шляхів програми, не можна з повною впевненістю затверджувати, що модуль не містить помилок.
Очевидна підстава цього твердження полягає в тому, що виконання всіх шляхів не гарантує відповідності програми її специфікаціям. Допустимо, якщо було потрібно написати програму для обчислення кубічного кореня, а програма фактично обчислює корінь квадратний, то програма буде зовсім неправильної, навіть якщо перевірити всі шляхи. Друга проблема - відсутні шляхи. Якщо програма реалізує специфікації не повністю (наприклад, відсутня така спеціалізована функція, як перевірка на негативне значення вхідних дані програми обчислення квадратного кореня), ніяке тестування існуючих шляхів не виявить такої помилки. І, нарешті, проблема залежності результатів тестування від вхідних даних. Шлях може правильно виконуватися для одних даних і неправильно для інших. Наприклад, якщо для визначення рівності 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 |
неуспішно |