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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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