3 Функціональні критерії (клас II)

Функціональний критерій - найважливіший для програмної індустрії критерій тестування. Він забезпечує контроль ступеня виконання вимог замовника в програмному продукті. Оскільки вимоги формулюються до продукту в цілому, вони відбивають взаємодію тестованого додатка з оточенням. При функціональному тестуванні переважно використається модель "чорного ящика". Проблема функціонального тестування - це, насамперед, трудомісткість; справа в тому, що документи, що фіксують вимоги до програмного виробу (Software requirement specification, Functional specification і т.п.), як правило, досить об'ємні, але тим не менш, перевірка повинна бути всеосяжною.

Нижче наведені часткові види функціональних критеріїв.

• Тестування пунктів специфікації - набір тестів у сукупності повинен забезпечити перевірку кожного тестованого пункту не менш одного разу.

Специфікація вимог може містити сотні й тисячі пунктів вимог до програмного продукту й кожна із цих вимог при тестуванні повинна бути перевірена відповідно до критерію не менш чим одним тестом

• Тестування класів вхідних даних - набір тестів у сукупності повинен забезпечити перевірку представника кожного класу вхідних даних не менш одного разу.

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

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

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

• Тестування класів вихідних даних - набір тестів у сукупності повинен забезпечити перевірку представника кожного вихідного класу, за умови, що вихідні результати заздалегідь не класифіковані, причому окремі класи результатів ураховують, у тому числі, обмеження на ресурси або на час (time out).

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

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

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

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

• Комбіновані критерії для програм і специфікацій - набір тестів у сукупності повинен забезпечити перевірку всіх комбінацій несуперечливих умов програм і специфікацій не менш одного разу.

При цьому всі комбінації несуперечливих умов треба підтвердити, а умови протиріч варто виявити й ліквідувати.

Приклад застосування функціональних критеріїв тестування для розробки набору тестів за критерієм класів вхідних даних

Нехай для рішення завдання тестування системи "Система керування автоматизованим комплексом зберігання підшипників" (див. Додаток 1, FS) був розроблений наступний фрагмент специфікації вимог:

1. Зробити опитування статусу складу (викликати функцію GetStoreStat ). Додати в журнал повідомлень запис "СИСТЕМА : Запитана статус СКЛАДУ". Залежно від отриманого значення зробити наступні дії:

• Отриманий статус складу = 32. У прийомний осередок складу надійшов підшипник. Система повинна:

1. Додати в журнал повідомлень запис "СКЛАД : Статус СКЛАДУ = 32".

2. Одержати параметри підшипника, що надійшов, з термінала підшипника (повинна бути викликана функція GetRollerPar ).

3. Додати в журнал повідомлень запис "СИСТЕМА: Запитані параметри підшипника".

4. Залежно від повернутої функцією GetRollerPar значення повинні бути виконані наступні дії ( таблиця 3.2):

Таблиця 3.2. Дії за результатами функції GetRollerPar
Значення, повернутої функцією GetRollerPar	Дії системи
...	...
0	Додати на перше місце команду Get - "ПОЛУЧИТЬ ИЗ ПРИЕМНИКА В ЯЧЕЙКУ" Додати в журнал повідомлень запис "ТЕРМИНАЛ ПОДШИПНИКА: 0 - - параметри повернуті <Номер_группы>"
1	Додати в журнал повідомлень запис "ТЕРМИНАЛ ПОДШИПНИКА: 1 - немає даних "
...	...

2. Зробити опитування термінала осі (викликати функцію одержання повідомлення від термінала - GetAxlePar ). У журнал повідомлень повинне бути додане повідомлення "СИСТЕМА : Запитані параметри осі". Залежно від повернутої функцією GetAxlePar значення повинні бути виконані наступні дії ( таблиця 3.3):

Таблиця 3.3. Дії за результатами функції GetAxlePar
Значення, повернутої функцією GetAxlePar	Дії системи
...	...
1	Додати в журнал повідомлень запис "ТЕРМИНАЛ ОСИ: 1 - немає даних "
...	...

Визначимо класи вхідних даних для параметра - статус складу:

• Статус складу = 0 (правильний).

• Статус складу = 4 (правильний).

• Статус складу = 16 (правильний).

• Статус складу = 32 (правильний).

• Статус складу = будь-яке інше значення (помилковий).

Тепер розглянемо тестові випадки:

• Тестовий випадок 1 (покриває клас 4):

Стан оточення (вхідні дані - X ):

Статус складу - 32.

...

Очікувана послідовність подій (вихідні дані - Y ):

Система запитує статус складу (виклик функції GetStoreStat ) і одержує 32

...

• Тестовий випадок 2 (покриває клас 5):

Стан оточення (вхідні дані - X ):

Статус складу - 12dfga.

...

Очікувана послідовність подій (вихідні дані - Y ):

Система запитує статус складу (виклик функції GetStoreStat ) і відповідно до пункту специфікації при помилковому значенні статусу складу в журнал додається повідомлення "СКЛАД : ПОМИЛКА : Невизначений статус".

...