Класифікація видів тестування

ПО ЗНАННЮ ВНУТРІШНЬОЇ БУДОВИ СИТЕМИ

Чорна скринька

Біла скринька

Сіра скринька

ПО ОБ”ЄКТУ ТЕСТУВАННЯ

Functional

User interface

Localization

Load/stress/balancing

Security

Usability

Compability

ПО СУБ”ЄКТУ ТЕСТУВАННЯ

Альфа-тестер

Бета-тестер

ПО ЧАСУ ПРОВЕДЕННЯ ТЕСТУВАННЯ

Альфа-тестування

Smoke

New features

Regressive

Acceptance/sertification

Бета-тестування

ПО КРИТЕРІЮ ПОЗИТИВНОСТІ СЦЕНАРІЇВ

Positive

Negative

По ступеню ізольованості компонентів

Component

Integration

System/end-to-end

по ступеню підготовки

Formal/document

Ad hoc

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

1. Поняття якості ПЗ.

2. Визначення видів тестування.

3. Класифікація видів тестування.

Лекція 31 «Виконання процесів тестування»

1. Методи генерації, методи відбору тестування програмного забезпечення.

2. Виконання процесу тестування.

Навчальна мета: Вивчити методи оцінювання показників якості програмного забезпечення.

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

Актуальність: Останніми тенденціями в галузі розробки програмного забезпечення є методологія вибору методів оцінки продукту. Часто вибір методів супроводжується документп=ацією, що є частиною спеку.

Мотивація: Спеціаліст у сфері QA повинен вміти визначити найкращий та економічно вигідний метод тестування програмного забезпечення. Такі спеціалісти цінуються високо на ринку праці.

Методи оцінювання показників якості програмного забезпечення. Основними методами оцінки показників якості ПЗ повинні бути:

• інспекції (огляди);

• тестування ПЗ;

• статичний аналіз ПЗ;

• імовірнісна оцінка надійності ПЗ;

• аналіз видів, наслідків і критичності відмов програмного забезпечення – SFMECA;

• аналіз дерева відмов програмного забезпечення – SFTA.

Інспекції процесів розроблення програмного забезпечення

Інспекції або технічні огляди (Inspection/Walk-through Review) застосовують для перевірки коректності, повноти та несуперечності програмної документації, а також для виявлення аномалій і дефектів, пов’язаних з невірним розумінням вимог НД. Метод полягає у перевірці програмного документа або набору документів (у тому числі, і листінгів програмного коду) одним або більшою кількістю людей, які не брали участі у розробленні документів. Можливі типи аномалій і дефектів пов'язані з методами розроблення документів і з характером документів. Типи дефектів звичайно обмежують заздалегідь визначеним набором (наприклад, у вигляді контрольного списку). У таблиці 1 показано зв'язок між етапами розроблення ПЗ, відповідними видами програмного продукту та видами інспекцій.

Таблиця 1—Види інспекцій програмного забезпечення

Етап розроблення ПЗ	Вид програмного продукту (результат етапу)	Вид інспекції
Розроблення вимог до ПЗ	Вимоги до ПЗ (програмна специфікація)	Інспекція вимог до ПЗ на відповідність вимогам до системи
Проектування	Проект ПЗ	Інспекція проекту ПЗ на відповідність вимогам до ПЗ
Кодування	Програмний код	Інспекція програмного коду на відповідність проекту ПЗ

Інспекції поділяють на :

• інспекції вимог високого рівня;

• інспекції вимог низького рівня.

Методи тестування програмного забезпечення

Загальні положення щодо тестування програмного забезпечення

Тестування ПЗ повинно включати функціональне і структурне тестування. Функціональне тестування (Functional Testing), яке також називають тестуванням за принципом «чорної скриньки» (“Black Box” Testing), полягає у перевірці функцій, які виконуються елементами ПЗ, на відповідність вимогам, проекту ПЗ та документації користувача. Структурне тестування (Structural Testing), яке також називають тестуванням за принципом «білої скриньки» або «скляної скриньки» (“White Box” Testing або “Glass Box” Testing), полягає у перевірці внутрішньої структури елементів ПЗ.

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

Під час реалізації функціонального і структурного тестування ПЗ повинні бути виконані наступні дії:

а) планування тестування:

1) розроблення плану тестування;

б) розроблення вимог до тестів:

1) визначення складових якості ПЗ, які оцінюються за результатами тестування;

2) визначення складових ПЗ, які тестувались;

3) оцінка необхідних для тестування ресурсів (бюджет, час, персонал);

в) проектування тестів:

1) проектування специфікації тестів;

г) проектування тестових процедур;

1) проектування детальних тестів;

2) проектування інструментального середовища тестування;

3) розроблення тестів;

4) розроблення детальних тестів;

5) розроблення тестових даних;

6) розроблення інструментального середовища тестування;

д) виконання тестування та оцінка його результатів:

1) виконання тестових прикладів;

2) аналіз результатів тестування;

3) розроблення звіту про тестування.

Загальну структуру інструментального середовища тестування ПЗ представлено на рисунку 1. Складові частини представленого інструментального середовища можуть бути цілком або частково автоматизовані.

Рисунок 1—Структурна схема інструментального середовища тестування ПЗ

Методи функціонального тестування програмного забезпечення

Загальні положення щодо функціонального тестування програмного забезпечення. Функціональне тестування ПЗ повинно бути реалізовано у формі наступних методів (див. таблицю 2):

• тестування транзакцій (переходів);

• тестування областей вхідних даних;

• тестування синтаксису;

• тестування логічних умов;

• тестування станів.

Таблиця 2—Види функціонального тестування

Види тестування	Цілі тестування	Об'єкти тестування
Тестування транзакцій	Верифікація реалізації прикладних функцій	Транзакції (переходи) між режимами роботи системи
Тестування областей вхідних даних	Верифікація реалізації функціональних обчислень і умов для областей вхідних даних	Області значень вхідних даних, включаючи граничні та заборонені значення
Тестування синтаксису	Верифікація користувальницького інтерфейсу та повідомлень	Елементи користувальницького інтерфейсу
Тестування логічних умов	Верифікація реалізації логічних умов ПЗ	Комбінації логічних умов реального світу
Тестування станів	Верифікація реалізації станів ПЗ	Стани та переходи між ними

Тестування транзакцій

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

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

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

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

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

Рисунок 2—Приклад графа транзакцій

Тестування областей вхідних даних

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

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

Для виділення еквівалентних областей вхідних даних використовують дві основні можливості:

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

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

Еквівалентні області визначаються, виходячи з наступних умов:

• якщо вхідна умова являє собою діапазон, то існують одна валідна та дві невалідні області;

• якщо вхідна умова являє собою окреме чисельне значення, то існують одна валідна та дві невалідні області; якщо вхідна умова є елементом множини, то існують одна валідна та одна невалідна області;

• якщо вхідною умовою є булєва змінна, то існують одна валідна та одна невалідна області.

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

• помилки в обчисленнях;

• помилки у розмірності масивів;

• некоректне використання нульових вказівників.

Використання нульових значень найчастіше призводить до помилок і вимагає особливої уваги, наприклад, у наступних випадках:

• ділення на нуль;

• порожній ASCII-символ;

• порожній стек або список;

• нульова вхідна таблиця.

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

Як приклад на рисунку 3 наведено специфікацію керуючої функції, що базується на одній змінній – температурі, t:

• «Аварія», якщо t  –50 С;

• «Включити обігрів», якщо –50 С < t < +50 С;

• «Включити охолодження», якщо +50 С < t < +100 С;

• «Аварія», якщо t  +100 С.

Таким чином, має чотири області вхідних даних із границями у трьох точках: –50 С, +50 С, +100 С.

Рисунок 3—Приклад областей вхідних даних і граничних значень

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

1. Перерахувати методи оцінки показників якості ПЗ.

2. Визначити види інспекцій програмного забезпечення.

3. Які дії повинні бути виконані під час реалізації функціонального і структурного тестування ПЗ?

4. Тестування областей вхідних даних.

5. Як визначити еквівалентні області?

Лекція 33 «Робота з файловими системами та базами даних»