Структурне тестування програмного забезпечення. Формальні специфікації й верифікація програм. (Лекція 1.3)

1. Лекція 1. Тема. Структурне тестування програмного забезпечення

Дисципліна «Інженерія програмного
забезпечення»
Модуль 3. "Формальні специфікації й
верифікація програм. Методи перевірки
та тестування програм та систем"

2. Зміст

1. Загальні відомості про дисципліну.
2. Основні поняття й принципи тестування
ПЗ
3. Способи тестування умов
4. Спосіб тестування потоків даних
5. Контрольні питання

3. Загальні відомості про дисципліну

Лекції 17 год
Лабораторні роботи 18+16=34 год
Самостійна робота - 68 год
Курсова робота
– 4 семестр
Екзамен
– 4 семестр
Модуль 3. "Формальні специфікації й верифікація
програм. Методи перевірки та тестування програм
та систем"
Модуль №4. "Інтерфейси, взаємодія та зміна
програм і даних. Засоби програмної інженерії"

4. Література

1. Технологии разработки программного
обеспечения: Учебник/ С. Орлов. - СПб.:
Питер, 2002. - 464 с.
2. Андон Ф.И. Основи інженерії якості
програмних систем / Коваль Г.И., Коротун
Т.М., Лаврищева Е.М., Суслов В.Ю. - К.:
Академпериодика, 2007. - 672 с.
3. Архипенков С. Лекції по керуванню
програмними проектами, М.: 2009, 128 с.

5. Основні поняття й принципи тестування ПЗ

• Тестування - складова процесу програмної інженерії, один з
методів подальшого поліпшення якості розробленого
програмного забезпечення системи за допомогою виявлення
дефектів, що залишилися, не виявлених раніше всіма іншими
видами перевірок.
• Стандарти
ANSI/IEEE Std. 610.12:1990
ДСТУ 2844-94,
ДСТУ 2853-94
• Тестування - процес виконання програмної системи (або її
елементів) з метою перевірки її відповідності встановленим
вимогам і виявлення дефектів.

6. Історія формування поглядів на ЖЦ ПЗ

• до 1956 року - орієнтація на налагодження;
• з 1957 по 1978 р. - орієнтація на встановлення відповідності ПС
вихідним вимогам;
• з 1979 по 1982 р. - орієнтація на виявлення дефектів, що
залишилися після реалізації;
• з 1983 по 1987 р. - орієнтація на аналіз, перевірку й тестування з
метою оцінки якості ПС на всіх стадіях розробки;
• з 1988 по 1995 р. - інтеграція дій по перевірці й тестуванню в
життєвий цикл ПС із метою запобігання появи дефектів на всіх
стадіях розробки (з охватом всіх дій по верифікації, валідації й
тестуванню).
• в 1995 році - стандарт ISO/IEC 12207
• 2004 рік - SWEBOK

7. Історія формування поглядів на ЖЦ ПЗ

2010
2004
1995
2000
1990
1979
1978
1980
1983
1982
1987
1988
1970
1956
1960
1957
1950
1940
ох
в
ат
IS
Ж
O
Ц
/IE
C
12
20
7
SW
EB
O
K
об
ки
вс
і
х
ек
ти
ст
а
пі
с
ля
ді
й
ро
зр
ре
ал
іза
ці
ви
мо
га
м
де
ф
ві
дп
ов
ід
ні
с
ть
на
ла
го
дж
ен
ня
ї
1930

8. SWEBOK

• Guide to the Software Engineering Body of
Knowledge (), IEEE 2004 Version Руководство к Своду Знаний по
Программной Инженерии, “SWEBOK”.

9. Область знань «Тестування ПЗ» в SWEBOK-2004

10. Термінологія тестування

• динамічна перевірка
• кінцева множина тестових даних
• очікуваному поводженню
проблеми тестування
• адекватність тестування
• оцінка витрат (вартості, часу, персоналу) на
тестування
• вибір обмеженої множині тестів
• поняття «дефект» і «відмова»

11. мета тестування

Основні
• дефекти
• функціональна придатність
Додаткові
• зручність застосування,
• продуктивність та інші.
основні підходи до виконання тестування
• деструктивний (негативне, руйнівне тестування)
• конструктивний (позитивне або демонстраційне).

12. Ключові питання тестування SWEBOK

– Критерії вибору тестів/Критерії
адекватності тестів
– Ефективність тестування/Мети
тестування
– Тестування для виявлення дефектів
– Проблема оракула.
– Теоретичні й практичні обмеження
тестування.
– Проблема нездійсненних шляхів.
– Тестопридатність

13. Зв'язок тестування з іншими видами діяльності

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

14. Різниця між валідацією та верифікацією

• Верифікация — проводиться практично завжди,
виконується методом перевірки (звірення)
характеристик продукції з заданими вимогами,
результатом є висновок про відповідність (чи
невідповідності) продукції.
• Валідація — проводиться за необхідності, шляхом
аналізу заданих умов застосування та оцінки
відповідності характеристик продукції цим вимогам,
результатом є висновок про можливість застосування
продукції до конкретних вимог.

15. Види й рівні тестування

Модульне (IEEE 1008-87 "Standard for Software Unit Testing“)
інтеграційне (ДСТУ 2941)
тестування ПЗ
Системне (ISO/IEC 12207)
по цілям якості, (акцент на нефункціональні
вимоги: надійність, стійкість, продуктивність,
переносимость і ін.,
зовнішнім інтерфейсам з іншими системами,
середовищем, апаратним забезпеченням.

16.

17. Види випробувань ПС

• Попередні
• Приймальні
• Настановні
• експлуатаційні
(ДСТУ 2853-94)

18. Мета приймальних випробувань

• приймальне тестування виконується в рамках
процесів «Поставка» і «Приймання
замовником» (споживачем) і зв'язується із
процесом «Валідації»
(ISO/IEC 12207)
• Тестування інсталяції (настановні
випробування) виконується в середовищі
експлуатації
• Альфа й Бета тестування
• Регресійне (regression test) і повторне
( re-test) тестування

19. Види тестування характеристик ПС

• Функціональне тестування (на відповідність або тестування
коректності)
• Тестування безпеки (Security testing)
• Тестування зручності застосування (ергономічності)
• Тестування технічних характеристик
• Тестування на надійність.
• Тестування продуктивності (Performance testing)
види:
– навантажувальне тестування (load testing)
– тестування на стійкість (stress testing);
– тестування обсягу (volume testing) .
Тестування конфігурації (Configuration testing).
Порівняльне тестування ( Back-to-back testing).
Тестування відновлення (Recovery testing).
Керована тестами розробка ( Test-driven development)

20. Методи тестування

21. Тестування розгалужень

• if (A<B) then
else
endif
• if (A<B and C = 1) then
else
endif
A<B
A>B
A<BC=1
A<BC 1
A B C=1
A B C 1

22. Методи спрямованого пошуку помилок

• припущення про помилки (error guessing);
• підсів помилок (error seeding);
• мутаційне тестування (mutation testing).

23. Методи, засновані на аналізі очікуваного використання

• статистичне тестування;
інтервали між відмовами MTBF (Mean
Time Between Failure)
• тестування по операційному профілі
метод SRET (Software Reliability
Engineered Testing)
• тестування по сценаріях можливого
використання
• тестування на базі моделей

24. Методи, що враховують специфіку програмної системи

тестування об’єктно-орієнтованих програм;
компонентне тестування;
тестування Web-Додатків;
тестування графічного інтерфейсу
користувача;
• тестування протоколів на відповідність;
• тестування систем реального часу;
• тестування критичних систем.

25. Основні методи тестування ООП

Завдання
тестування
Розробка тестових
наборів
( test-case)
Тестування
внутрішньої
структури класу
Тестування
взаємодії класів
Методи/підходи
Тестування, засноване на помилках
(шаблонах помилок)
Тестування, засноване на сценаріях
використання
Стохастическое тестування класів
Еквівалентна розбивка на рівні класу
Таблиці рішень
Стохастическое тестування класів
Еквівалентна розбивка на рівні класів
Тестування переходів між станами

26. Тестування протоколів

тестування відповідності (атестаційне);
тестування продуктивності;
тестування спільного функціонування;
тестування взаємодії;
тестування функціональності;
моніторинг.

27. Дослідницьке тестування

Крок 1. Дослідження.
Крок 2. Проектування тестів.
Крок 3. Виконання тестів.
Крок 4. Побудова евристик.
Крок 5. Визначення критерію
покриття.

28. Крок 1. Дослідження

Формування списку функцій (ієрархії функцій).
Розбивка функцій на основні й другорядні.
Виявлення областей можливої нестійкості продукту (підданих
відмовам функцій і даних).
Визначення
Критерії віднесення
Основна функція - будь- 1. Функції, що є визначальними для
яка зовнішня функція,
використання продукту по призначенню.
відмови
в
якій 2. Функції, часто використовувані звичайними
означають
користувачами в сеансі роботи.
невідповідність
3. Функції, які можуть використовуватися
продукту
своєму
рідко, але їхні відмови приводять до
призначенню.
значних негативних наслідків.
Другорядна функція - Рідко використовувані функції, відмови при
функція, без якої
виконанні яких не можуть мати істотних
продукт
може
наслідків.
використовуватися.

29. Приклади областей можливої нестійкості функцій

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

30. Крок 2. Проектування тестів.

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

31. Крок 3. Виконання тестів

Завдання кроку:
• тестування всіх основних функцій;
• тестування ідентифікованих областей
потенційної нестійкості;
• вибіркове тестування другорядних
функцій;
• реєстрація відмов;
• фіксація будь-яких виявлених проблем
(для подальшого вивчення).

32. Крок 5. Визначення критерію покриття.

• протестовані всі основні функцій;
• протестовані обрані другорядні функції;
• протестовані обрані області можливої
нестійкості (п'ять - десять функцій, , які
можуть привести до нестійкої роботи
продукту, протестувати їх на тестових даних).
Розподіл часу
• 80% часу - на основні функції,
• 10% - на другорядні й
• 10% - на області потенційної нестійкості.

33. Еквівалентна розбивка

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

34. Приклад опису класів еквівалентності

Вхідні події
Припустимі
класи
еквівалентнос
ті
Неприпустимі класи
еквівалентності
Уведення
числа
Числа від 0 до
9000
Числа менше 0 і числа більше 9000
Пробіл
Нечислові символи
Вираз, що обчислюється, результат
обчислення якого перебуває поза
припустимим інтервалом
Уведення
першої
букви
прізвища
Перший символ
повинен бути
заголовною
буквою
Перший символ мала літера
Перший символ - не буква

35. Розбивка вхідного простору на категорії

• Крок 1. Декомпозиція функції на функціональні
елементи, які можуть тестироваться незалежно.
• Крок 2. Ідентифікація параметрів і умов
середовища, що впливають на поводження функції.
• Крок 3. Виділення категорій інформації, що
характеризує кожний параметр і умова середовища.
• Крок 4. Розбивка кожної категорії на чіткі
альтернативи, які включають різні види значень,
можливі для категорії.
• Крок 5. Формування формальної специфікації тесту
для кожного функціонального елемента.

36. Крок 5. Формування формальної специфікації тесту для кожного функціонального елемента

Параметр
Категорія
Альтернативи
Поле вибору
Зміст
Текст
Піктограма
Значок з текстом
Стан
Поле не зазначене/обране
Поле не зазначене/не обране
Поле зазначене/обране
Поле зазначене/не обране
Тип поля
Однозначний вибір
Багатозначний вибір
Розширений вибір
Спосіб вибору
Вибір курсором
Виділена буква/(комбінація букв)
Функціональна клавіша
Вибір за допомогою клавіатури
Меню

37. Переваги методу

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

38. Тестування переходів між станами

39. Тестування, засноване на моделях програмної системи

Моделі
• модель представлена у формальному
виді;
• модель застосовується для генерації
тестів або еталона.

40. Тестування Web-Додатків

для взаємодії з користувачем використовується Web-Браузер;
взаємодія з користувачем чітко розділяється на етапи,
протягом яких браузер працює з одним описом інтерфейсу, а
ці етапи, у свою чергу, розділяються однозначно
локализуемыми обігами від браузера до додатка;
для опису інтерфейсу застосовується стандартне подання;
взаємодія між браузером і додатком здійснюється по
стандартному протоколі (HTTP) і чітко формалізовано;
функціональність Web-Додатка розподілена між вилученим
сервером і клієнтськими комп'ютерами користувачів.

41. Функціональне тестування

Контрольні питання для перевірки зручності застосування Web-Додатків
Архітектура й навігація сайту
Чи відповідає структура сайту цілям, для досягнення яких він призначений?
Чи зрозуміла схема навігації?
Чи можна визначити, у якому місці сайту ви перебуваєте?
Чи легко знайти на сайті потрібну інформацію?
Чи розумно кількість елементів у панелях навігації?
Чи логічно відсортовані елементи?
Чи відповідають назви гіперпосилань назвам сторінки?
Чи чітко виділені гіперпосилання ?
Чи чітко виділене посилання на головну сторінку?
Чи існує можливість пошуку інформації на сайті?
Чи існує карта сайту?
Чи кожна сторінка дозволяє зрозуміти, на якому сайті ви перебуваєте?
Чи можна управляти навігацією по сайті?
Планування й дизайн сайту
Чи не перевищує розмір сторінки розмір вікна?
Чи повторюється схема планування на всіх сторінках?
Чи існує виразний фокус на кожній сторінці?
Чи видна візуально планування?
Чи ефективно використовується вирівнювання й угруповання?

42.

Зміст сайту
Зрозумілі й чи лаконічні тексти на сайті?
Чи організований текст у вигляді невеликих блоків?
Чи зустрічаються в тексті граматичні й орфографічні помилки й
помилки?
Чи містять сторінки вступний текст?
Чи підтримують мультимедійні компоненти завдання користувача?
Чи є одиниці виміру, використовувані на сайті, зрозумілими?
Чи представлені на сайті час і дата створення сторінок?
Чи представлені на сайті номера контактних телефонів?
Чи представлені на сайті адреси з поштовими індексами?

43.

Форми й взаємодія
Чи відповідають форми завданням користувача?
Чи підтримують діалоги логічну послідовність кроків?
Чи очевидна кнопка або посилання для переходу до наступного кроку діалогу?
Чи всі елементи форм використовуються по призначенню?
Чи згруповані елементи форми по значеннєвому призначенню?
Чи зрозуміло виглядає кнопка відправлення форми?
Графіка
Чи прийнятно якість використовуваної графіки ?
Чи всі графічні елементи мають альтернативні текстові написи?
Чи містять графічні елементи інформацію про розмір файлу?
Чи оптимізовані графічні елементи для передачі по Інтернету?
Чи реагують графічні елементи на рухи мишки?
Чи використовується анімація? Чи прийнятний обсяг графічних файлів?

44.

Кольори
Чи підходить вибір кольорів для сайту?
Чи не багато кольорів?
Чи використовуються кольори логічно й послідовно?
Чи адекватно розрізняються кольори в чорно-білому режимі?
Оформлення тексту
Чи зрозумілі тексти?
Чи прийнятний розмір шрифту?
Чи має шрифт підходящий колір і чи досить він контрастний?
Чи відформатований текст так, щоб у рядку було від 10 до 12 слів?
Чи достатня ширини поля навколо тексту?
Стійкість до помилок
Чи належний користувач що-небудь запам'ятовувати, переходячи між сторінками?
Чи виникає попередження при спробі здійснення необоротних дій?
Чи можна скасувати ризиковані дії?
Чи перехоплюються виникаючі помилки локально, без звертання до сервера?
Чи містять сторінки з повідомленням про виниклі помилки корисну інформацію?
Чи містять сторінки з порожніми результатами пошуку ради по розширенню умов пошуку?
Чи існує система контекстної допомоги (довідки)?
Чи структурована допомога по завданнях користувача? Чи пояснює вона користувачу, як зробити ту або іншу дію?
Платформа й особливості реалізація
Чи досить швидко відбувається завантаження сторінок (від 3 до 15 секунд)?
Чи всього гіперпосилання працюють правильно?
Чи існують ушкоджені графічні елементи?
Чи написаний текст на сторінках так, щоб його могли знайти пошукові системи?
Чи працює сайт із різними браузерами користувача?
Чи працює сайт на моніторах високого й низького розрізнення?

45. Підходи до тестування, застосовувані в моделях ЖЦ

Модель ЖЦ
Застосовувані підходи до тестування
Каскадна
Ключова особливість моделі: Каскадна модель із циклами зворотного зв'язка, моделюванням
або прототипування. Тестування починається після завершення кодування.
Основні методи/підходи:
1.Передача коду групі тестування після його готовності.
2.Користувачі залучаються до тестування на етапі приймальних випробувань.
3.Після випуску продукту проводиться додаткове тестування (експериментальна експлуатація).
Примітка: Поліпшення тестування можливо наприкінці проекту, що збільшує час для
можливості поліпшення процесу й тільки в наступних проектах.
Модель ЖЦ
Застосовувані підходи до тестування
Спіральна
Ключова особливість моделі: використовує прототипирование й перепланування з постійним
оцінюванням ризиків і обмежень у рамках кожного прототипу.
Основні методи/підходи:
1.Тестування, засноване на оцінці ризику ( risk-driven testing). Тестування застосовується для
ідентифікації ризиків. Аналіз дефектів служить ключем для ідентифікації «вузьких» місць у
ПЗ.
2.Тестування починається на ранніх стадіях ЖЦ.
3.Критерій завершення тестування, заснований на ризику. Тестове покриття - не основна мета.
Стратегія тестування формується з урахуванням ризиків потенційно, що залишилися дефектів,
і допомагає ухвалити рішення щодо переході до наступного витка спирали.
Примітки:
1.У рамках стадії ЖЦ в одному витку спирали тестування виконується так само, як і в
каскадній моделі, але на меншому обсязі ПС і менш тривало.
2.Загальний час тестування в рамках ЖЦ більше, оскільки більший проміжок часу між
його початком і випуском ПС

46. Інформаційні потоки процесу тестування

47. Тестування «чорна скринька»

• Відомі: функції програми.
• Досліджується: робота кожної функції
на всій області визначення.

48. Тестування «біла скринька»

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

49. Недоліки та переваги тестування “біла скриня”

Недоліки :
1.
Дуже велика кількість незалежних маршрутів.
2. Вичерпне тестування маршрутів не гарантує відповідності програми
вихідним вимогам до неї.
3.
У програмі можуть бути пропущені деякі маршрути.
4.
Не можна виявити помилки, появу яких залежить від оброблюваних
даних
Достоїнства :
1.
Кількість помилок мінімально в «центрі» і максимально на
«периферії» програми.
2.
Попередні припущення про ймовірність потоку керування або даних у
програмі часто бувають некоректні. У результаті типовим може стати
маршрут, модель обчислень по якому пророблена слабко.
3.
При записі алгоритму ПЗ у вигляді тексту мовою програмування
можливе внесення типових помилок трансляції (синтаксичних і
семантичних).
4.
Деякі результати в програмі залежать не від вихідних даних, а від
внутрішніх станів програми.

50. Спосіб тестування базового шляху

• Особливості потокового графу
1. Граф будується відображенням керуючої структури програми. У ході
відображення закриваючі дужки умовних операторів і операторів циклів
(end if; end loop) розглядаються як окремі (фіктивні) оператори.
2. Вузли (вершини) потокового графа відповідають лінійним ділянкам
програми, включають один або декілька операторів програми.
3. Дуги потокового графа відображають потік керування в програмі
(передачі керування між операторами). Дуга - це орієнтоване ребро.
4. Розрізняють операторні й предикатні вузли. З операторного вузла
виходить одна дуга, а із предикатного - дві дуги. Предикатні вузли
відповідають простим умовам у програмі. Складена умова програми
відображається в кілька предикатних вузлів. Складною називають
умова, у якій використовується одна або декілька булевих операцій
(OR, AND).
5. Замкнуті області, утворені дугами й вузлами, називають регіонами.
6. Навколишнє середовище графа розглядається як додатковий регіон.

51. приклад

if a OR b
then x
else y
end if;
Не правильно
правильно

52. процедуру стиска

процедура стиск
1 виконувати поки немає EOF
1
читати запис;
2
якщо запис порожній
3
те видалити запис:
4
інакше якщо поле а >= поля b
5
то видалити b;
6
інакше видалити а;
7а
кінець якщо;
7а
кінець якщо;
7b
кінець виконувати;
8 кінець стиск;

53. Перетворений потоковий граф процедури стиску

54. Цикломатична складність

-
метрика ПЗ, що забезпечує кількісну оцінку логічної складності
програми.
У способі тестування базового шляху цикломатична складність
визначає:
• кількість незалежних шляхів у базовій множині програми;
• верхню оцінку кількості тестів, що гарантує однократне виконання
всіх операторів.
Незалежні шляхи для потокового графа із приклада 1:
• Шлях 1: 1-8.
• Шлях 2: 2-3-7а-7 b-1-8.
• Шлях 3: 4-5-7а-7 b-1-8.
• Шлях 4: 4-6-7а-7 b-1-8.

55. Обчислення цикломатичної складності

1) дорівнює кількості регіонів потокового графа;
2)
V(G)= E-N+2,
де Е — кількість дуг, N — кількість вузлів
потокового графа;
3) За виразом V(G) =p+ 1,
де р — кількість предикатних вузлів у потоковому
графі G.
Цикломатична складність графа із приклада 1 :
1) потоковий граф має 4 регіони;
2) V(G) = 11 дуг - 9 вузлів + 2 = 4;
3) V(G) = 3 предикатних вузли +1=4.

56. процедуру обчислення середнього значення

1
1
1
1
процедура сред;
i := 1;
введено := 0;
колич := 0;
сум := 0;
вып пока 2 -вел( i ) <> stop и введено <=500 - 3
4
введено:= введено + 1;
если 5 -вел( i ) >= мин и вел( i ) <= макс - 6
7
то колич := колич + 1;
7
сум := сум + вел( i );
8
конец если;
8
i := i + 1;
9 конец вып;
10 если колич > 0
11
то сред := сум / колич;
12 иначе сред := stop;
13 конец если;
13 конец сред;

57. Потоковий граф процедури

58. цикломатична складність

1) V(G) = 6 регіонів;
2) V(G) = 17 дуг - 13 вузлів + 2 = 6;
3) V(G) = 5 предикатних вузлів + 1 = 6.

59. Визначається базова множина незалежних лінійних шляхів

Шлях 1: 10-11-13; /вел=stор, колич>0.
Шлях 2: 10-12-13;/вел=stop, колич=0.
Шлях 3: 10-11-13; /спроба обробки 501-й
величини.
Шлях 4: 8-9-2-... /вел<хв.
Шлях 5: 8-9-2-... /вел>макс.
Шлях 6: 8-9-2-... /режим нормальної
обробки

60. Способи тестування умов

Вираз відносини має вигляд
• Е1 <оператор відносини> E2,
де E1, Е2 — арифметичні вираження, а оператор відносини
використовується один з : <, >, =, , , .
• Складна умова складається з декількох простих умов, булевых
операторів
• можливі наступні типи помилок:
• помилка булевого оператора (наявність некоректних /
відсутніх / надлишкових булевих операторів);
• помилка булевої змінної;
• помилка булевої дужки;
• помилка оператора відносини;
• помилка арифметичного вираження

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

1. Визначити поняття тестування.
2. Що таке тест? Поясните зміст процесу тестування.
3. Що таке вичерпне тестування?
4. Які завдання вирішує тестування?
5. Яких завдань не вирішує тестування?
6. Які принципи тестування ви знаєте? У чому їхня відмінність друг від друга?
7. У чому складається суть тестування «чорного ящика»?
8. У чому складається суть тестування «білого ящика»?
9. Які особливості тестування «білого ящика»?
10. Які недоліки має тестування «білого ящика»?
11. Які достоїнства має тестування «білого ящика»?
12. Дайте характеристику способу тестування базового шляху.
13. Які особливості має потоковий граф?
14. Поясните поняття незалежного шляху.
15. Поясните поняття цикломатичної складності.
16. Що така базова множина?
17. Які властивості має базова множина?
18. Які способи обчислення цикломатичної складності ви знаєте?
19. Поясните кроки способу тестування базового шляху.
20. Поясните достоїнства, недоліки й область застосування способу тестування базового шляху.
21. Дайте загальну характеристику способів тестування умов.
22. Які типи помилок в умовах ви знаєте?
23. Які методики тестування умов ви знаєте?
24. Поясните суть способу тестування галузей і операторів відносин. Які він має обмеження?
25. Що таке обмеження на результат?
26. Що таке обмеження умови?
27. Що така обмежуюча множина? Чим зручно його застосування?
28. Поясните кроки способу тестування галузей і операторів відносин.
29. Поясните достоїнства, недоліки й область застосування способу тестування галузей і операторів відносин.
30. Поясните суть способу тестування потоків даних.
31. Що така множина визначень даних?
32. Що така множина використань даних?
33. Що таке ланцюжок визначення-використання?
34. Поясните кроки способу тестування потоків даних.
35. Поясните достоїнства, недоліки й область застосування способу тестування потоків даних.
36. Поясните особливості тестування циклів.
37. Які методики тестування простих циклів ви знаєте?
38. Які кроки тестування вкладених циклів?