Тема. Метрики покриття й глибини тестування
План
1.
Метрики підрахунку дефектів.
2.
Ефективність тестування.
3.
Проблема оракула.
1.
Метрики
підрахунку дефектів
Програма, що тестується, може
оцінюватися на основі підрахунку та класифікації знайдених дефектів. Для
кожного класу дефектів можна визначити відношення між кількістю відповідних
дефектів і розміром програми (в термінах обраних метрик оцінки розміру).
Статистичні
очікування щодо надійності програмної системи можуть використовуватися для
ухвалення рішення про продовження або припинення (закінчення) тестування,
виходячи із заданих параметрів прийнятної якості (наприклад, щільності дефектів
заданого класу).
Моделі зростання надійності (Reliability growth models).
Дані
моделі забезпечують можливості прогнозування надійності системи, базуючись на
виявлені збоїв. Моделі такого роду розбиваються на дві групи:
Ø
за кількістю
збоїв (failure-count);
Ø
часу між збоями (time-between-failure).
Оцінка виконаних тестів (Evaluation
of the tests performed).
Метрики
покриття / глибини тестування (Coverage / thoroughness measures).
Критерії
"адекватності" тестування, у ряді випадків, вимагають систематичного
виконання тестів для певного набору елементів програми, що задаються її
архітектурою або специфікацією. Відповідні метрики дозволяють оцінити ступінь
охоплення характеристик системи (наприклад, відсоток тестованих різних
параметрів продуктивності) і глибину їх деталізації (наприклад, випадкове
тестування параметрів продуктивності або з урахуванням граничних значень і
т.п.). Такі
метрики допомагають прогнозувати розподіл усіх досягненнь заданих параметрів якості системи.
Введення штучних дефектів (Fault
seeding).
На практиці, цей підхід
допомагає класифікувати можливі помилки і наступні за ними збої, застосовуючи в
подальшому отримані результати для моделювання можливих причин реальних збоїв,
виявлених в процесі тестування.
Безумовно, ця техніка повинна
використовуватися з максимальною обережністю досвідченими фахівцями.
Критерії
відбору тестів / критерії адекватності тестів, правила припинення тестування (Test selection criteria / test adequacy criteria, or stopping rules).
Критерії
відбору тестів можуть використовуватися як для створення набору тестів, так і
для перевірки, наскільки вибрані тести адекватні вирішуваних завдань
(тестування). При цьому, обговорювані критерії допомагають визначити,
коли можна або необхідно припинити тестування.
2. Ефективність тестування
Тестування — це
спостереження за виконанням програми, запущеної з метою тестування з заданими
параметрами, за заданим сценарієм або з іншими заданими початковими умовами або
цілями тестування. Ефективність тесту може бути визначена лише в контексті
заданих умов.
Тестування
для ідентифікації дефектів (Testing for defect
identification).
Даний випадок тестування на
увазі успішність процедури тестування, якщо дефект знайдено. Це відрізняється
від підходу у тестуванні, коли тести запускаються для демонстрації того, що
програмне забезпечення задовольняє пропонованим вимог і, відповідно, тест
вважається успішним, якщо не знайдено дефектів.
3.
Проблема оракула
"Оракул", в даному
контексті, будь-який
агент (людина або програма), що оцінює поведінку програми, формулюючи вердикт —
тест пройдено ("pass") чи ні ("fail").
Теоретичні і
практичні обмеження тестування (Theoretical
and practical limitation of testing)
Теорія тестування виступає
проти необгрунтованого рівня довіри до серії успішно пройдених тестів. На жаль,
більшість встановлених результатів теорії тестування — негативні, означаючи, за
словами Дейкстри (Dijkstra), те, що
"тестування програми може використовуватися для демонстрації наявності
дефектів, але ніколи не покаже їх відсутність". Основна причина цього в
тому, що повне (всеосяжне) тестування недосяжне для реального програмного
забезпечення.
Проблема
нездійсненних шляхів (The
problem of infeasible paths)
Ця складна проблема
автоматизованого тестування пов’язана з тим, що шлях, по якому виконуються
потоки робіт тестованої програмної системи, не можуть бути задані вхідними
параметрами.
Придатність
до тестування (Testability)
Це
поняття може мати на увазі дві різні ідеї:
Ø Перша описує ступінь легкості опису критеріїв
покриття тестами для заданої програмної системи.
Ø Друга визначає можливість ймовірності,
можливість статистичного вимірювання того, що під час тестування проявиться збій програмної системи. Обидві
інтерпретації цього поняття однаково важливі для тестування.
Зв’язок тестування з іншими видами діяльності (Relationships of testing with other activities)
Тестування
програмного забезпечення відрізняється від статичних технік управління якістю і
перевірки коректності, налагодження та програмування, але пов’язане з усіма
цими роботами. Слід розглядати тестування з точки зору аналітиків і фахівців з
сертифікації якості.
Розробка, що управляється тестуванням (Test—driven development)
Це не
стільки техніка тестування, скільки стиль організації процесу розробки,
життєвого циклу, коли тести є невід’ємною частиною вимог (і відповідних
специфікацій) замість того, щоб розглядатися незалежною діяльністю з перевірки
задоволення вимог програмною системою.
Питання для самоконтролю:
1.
Надати
визначення метрикам покриття, глибині тестування (Coverage / thoroughness measures).
2.
Пояснити,
навіщо вводять штучні дефекти (Fault seeding) під час
тестування програмних продуктів.
3.
Навести
критерії відбору тестів, критерії адекватності тестів, правила припинення
тестування (Test selection criteria / test adequacy criteria, or stopping rules).
4.
Описати
тестування для ідентифікації дефектів (Testing for defect identification), обґрунтувати
доцільність його використання.
5. Пояснити
в чому полягає проблема оракула (The oracle problem), навести приклади.
6. Обґрунтувати
теоретичні та практичні обмеження тестування.
7. Проаналізувати
особливості розробки програмного забезпечення, керованої тестуванням (Test-driven development).
8.
Зв’язок тестування з іншою діяльністю
(Relationships
of testing with other activities).