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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Тестування розгалужень
if (A
else
endif
if (A
else
endif
A
A >
B
A < B C = 1
A < B C ≠ 1
A ≥ B C=1
A ≥ B C≠1

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

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

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

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

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

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

Крок 1. Дослідження
Формування списку функцій (ієрархії функцій).
Розбивка функцій на основні й другорядні.
Виявлення областей
можливої нестійкості продукту (підданих відмовам функцій і даних).

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

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

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

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

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

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

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

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

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

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

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

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

Функціональне тестування
Контрольні питання для перевірки зручності застосування Web-Додатків

Чи представлені на сайті адреси з поштовими індексами?

Чи використовується анімація? Чи прийнятний обсяг графічних файлів?

Чи використовуються нестандартні plug-in? чи Є вони необхідними й корисними?

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

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

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

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

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

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

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

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

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

Цикломатична складність
метрика ПЗ, що забезпечує кількісну оцінку логічної складності програми.
У способі тестування
базового шляху цикломатична складність визначає:
кількість незалежних шляхів у базовій множині програми;
верхню оцінку кількості тестів, що гарантує однократне виконання всіх операторів.
Незалежні шляхи для потокового графа із приклада 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.

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

процедуру обчислення середнього значення
процедура сред;
1 i := 1;
1 введено :=
0;
1 колич := 0;
1 сум := 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 конец сред;

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

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

Визначається базова множина незалежних лінійних шляхів
Шлях 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-... /режим нормальної обробки

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