Софт, хард - інтернет - Оцінка якості тестування ПЗ
Особистий досвід приборкання комп'ютерів
Оцінка якості тестування ПЗ. Частина 1: Вступ
Обговоримо способи оцінки якості тестування ПЗ. Не так існуючі методики, як логічне обґрунтування — чому роблять саме так, чи можна робити краще і як чинити у випадках, з якими ще ніхто не стикався.
Ви тестувальник ПЗ. Які ваші завдання? По-перше, перевірити, щопрограма поводиться відповідно до поставленихвимог. Розглядаємо функціональні вимоги до системи чи її частини. По-друге, звітувати перед замовником, що ви свою роботу зробилиякісно.
Для вирішення першого завдання потрібен набіртестів. Кожен тест являє собою варіант взаємодії з системою, що тестується, з перевіркою коректності поведінки системи. Спосіб взаємодії визначаєтьсяінтерфейсом системи, наприклад:
- програмний інтерфейс - послідовність викликів функцій чи методів;
- командний рядок - запуск із деяким набором аргументів (з попередньою підготовкою оточення - файлів даних тощо);
- графічний інтерфейс - послідовність впливів на керуючі елементи (кнопочки, поля введення тощо);
- протоколи – послідовність відправлених пакетів.
У будь-якому випадку доведеться вирішувати два основні завдання - вибір тестових даних і аналіз коректності поведінки системи. Гаразд, сяк-так — із цим завданням ви впоралися. Переходимо до другої проблеми – як переконати замовника, що ви свій бутерброд із ікрою заробили?
Ідеальний випадок - перевірені всі варіанти взаємодії (повне або вичерпне тестування) - на те і ідеальний, щоб не зустрічатися насправді. ВжеЦі варіанти багато. Отже, доведеться вибирати, шукати компроміс між трудомісткістю тестування та якістю результату. На цьому етапі всі погоджуються з тим, що шукати помилки за допомогою тестування можна, але гарантувати відсутність помилок - на жаль, не можна.
Отже, ми дійшли необхідності вибору набору тестів, який з прийнятною трудомісткістю дозволяє досягти необхідного рівня якості ПЗ.Процедура перевірки того, що набір тестів має ці характеристики,має бути формальною, щоб бутиоб'єктивною, тобто виключити розбіжності сторін.
У такій ситуації у всіх галузях загальноприйнято вимірювати деякі числові характеристики і на цій підставі робити висновок про рівень досягнення заданої мети. Ці числові характеристики називаютьметриками. Слід зазначити, щоцінність метрик залежить від ступеня їхньоїадекватності, тобто того, наскільки точно вони відображають досягнення мети.
У разі метрики називаються критеріями тестового покриття, а обчислені значення метрик — досягнутим рівнем тестового покриття.
Як приклад неадекватної метрики якості тестування можна навести кількість знайдених під час тестування помилок — мала кількість може означати як низьку якість тестування, і високу якість продукту за високої якості тестування. Проте кількість знайдених помилок може використовуватися для оцінки якості самого продукту.
Наступного разу будемо розглядати та класифікувати існуючі критерії покриття.
[…] Попередня частина закінчилася висновком про необхідність використання метрик для оцінки якості тестування та обіцянкою класифікувати використовувані метрики (вони — критерії тестового покриття).Обіцянки треба виконувати. Майєрс безумовно має рацію, визначаючи тестування, як процес виконання програми з метою виявлення помилок [1]. Хоча на мій погляд, позитивні визначення теж мають право на існування, при спробі їх перевірки "від протилежного" якраз і виходить визначення Майєрса. […]