Поняття тестів та тестового покриття

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

Тест дизайн (Test Design) — це етап процесу тестування програмного забезпечення, на якому проектуються і створюються тестові випадки (тест кейси), відповідно до визначених раніше критеріями якості та цілями тестування.

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

Баг/Дефект Репорт (Bug Report) — це документ, що описує ситуацію або послідовність дій (Steps), що призвела до некоректної роботи об'єкта тестування (Misbehavior), із зазначенням причин та очікуваного результату (Expected Result).

Тестове Покриття (Test Coverage) — це одна з метрик оцінки якості тестування, що представляє із себе щільність покриття тестами вимог або коду, що виконується.

Деталізація Тест Кейсів (Test Case Specification) — це рівень деталізації опису тестових кроків і необхідного результату, при якому забезпечується розумне співвідношення часу проходження до тестового покриття.

Час Проходження Тест Кейса (Test Case Pass Time) — це час від початку проходження кроків тест кейса до отримання результату тесту.

Перевірка на моделях

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

 

Рис. 4.  Схема процесу перевірки властивостей ПО на моделях

 

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

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

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

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

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

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