Метрики тестування (Software Test Metrics)
Метрика (metric): Шкала вимірювань та метод, що використовується для вимірювання (ISO 14598)
"Ви не можете контролювати те, що не можете виміряти" - Том Демакро.
Основна мета тестування полягає у наданні інформації, необхідної для управління ризиками. Щоб контролювати та керувати тестуванням, а також надавати своєчасну інформацію заінтересованим сторонам, необхідні ефективні вимірювання процесу тестування. Для вимірювання процесу тестування потрібно визначити, яка інформація має бути надана, як її отримати та як вона має бути подана. Таким чином, для всіх дій тестування необхідно визначити та використовувати метрики, а також надати показники вимірювань як для продуктів, так і для процесів.
Метрики тестування програмного забезпечення поділяються на два типи:
Метрики процесу (Process metrics): використовуються у процесі підготовки та виконання тестування.
Продуктивність підготовки тест-кейсів (Test Case Preparation Productivity): використовується для розрахунку кількості підготовлених тест-кейсів та зусиль (Effort), витрачених на їхню підготовку.
Test Case Preparation Productivity = (No of Test Case) / (Effort spent for Test Case Preparation)
Охоплення тестового дизайну (Test Design Coverage): відсоток покриття тест-кейс вимог.
Test Design Coverage = ((Total number of requirements mapped to test cases) / (Total number of requirements)*100
Продуктивність виконання тестів (Test Execution Productivity): визначає кількість тест-кейсів, які можуть бути виконані за годину.
Test Execution Productivity = (No test tests executed) / (Effort spent for execution of test cases)
Покриття виконаних тестів (Test Execution Coverage): призначене для вимірювання кількості виконаних тест-кейсів порівняно з кількістю запланованих тест-кейсів.
Test Execution Coverage = (Всієї дії.
Успішні тест-кейс (Test Cases Passed): для вимірювання відсотка пройдених успішно тест-кейсів.
Test Cases Pass = (Total no. of test cases passed) / (Total no. of test cases executed) * 100
Неуспішні тест-кейс (Test Cases Failed): для вимірювання відсотка завалених тест-кейсів.
Test Cases Failed = (Total no. of test cases failed) / (Total no. of test cases executed) * 100
Заблоковані тест-кейс (Test Cases Blocked): для вимірювання відсотка блокованих тест-кейсів.
Test Cases Blocked = (Total no. of test cases blocked) / (Total no. of test cases executed) * 100
Метрики продукту (Product metrics):
Рівень виявлення помилок (Error Discovery Rate): визначення ефективності тест-кейсів.
Error Discovery Rate = (Додатковий номер звільнених дій / Total no. of test cases executed)*100
Відсоток виявлення дефектів (DDP): Кількість дефектів, виявлених у фазі тестування, поділена на кількість дефектів, знайдених у цій фазі тестування, а також у всіх наступних фазах. також дефект, що вислизнув. (ISTQB)
Рівень виправлення дефектів (Defect Fix Rate): допомагає дізнатися якість складання (build) з погляду усунення дефектів.
Дефект fix = = (До кінця не позначається дефекти - пов'язаний з тим, що не реагує) / (То не зроблено дефектів, що зменшується + Total no. of new Bugs due to fix)*100
Щільність дефектів (Defect Density): кількість дефектів, виявлених у компоненті або системі, поділена на розмір компонента або системи (виражений у стандартних одиницях вимірювання, наприклад, рядках коду, числі класів або функцій). (ISTQB)
Defect Density = Total no. of defects identified / Actual Size (requirements)
Виток дефектів (Defect Leakage): використовується для перевірки ефективності процесу тестування перед UAT.
Defect Leakage = ((Total no. of defects found in UAT)/(Total no. of defects found before UAT)) * 100
Ефективність усунення дефектів (Defect Removal Efficiency): дозволяє порівнювати загальну (дефекти, виявлені до та після постачання) ефективність усунення дефектів.
Defect Removal Efficiency = ((Total no. defects found pre-delivery) /( (Total no. of defects found pre-delivery )+ (Total no. of defects found post-delivery)))* 100
Тестове покриття (Test Coverage)
Тестове Покриття - це одна з метрик оцінки якості тестування, що представляє собою щільність покриття тестами вимог або виконуваного коду. Складність сучасного програмного забезпечення та інфраструктури зробило нездійсненним завдання проведення тестування зі 100% тестовим покриттям. Тому для розробки набору тестів, що забезпечує більш-менш високий рівень покриття, можна використовувати спеціальні інструменти або техніки тест дизайну.
Існують такі підходи до оцінки та вимірювання тестового покриття:
Відмінності: Метод покриття вимог зосереджений на перевірці відповідності набору тестів, що проводяться вимогам до продукту, в той час як аналіз покриття коду - на повноті перевірки тестами розробленої частини продукту (вихідного коду), а аналіз потоку управління - на проходженні шляхів у графі або моделі виконання тестованих функцій (Control Flow Graph).
Обмеження:
Метод оцінки покриття коду не виявить нереалізовані вимоги, оскільки працює не з кінцевим продуктом, а з вихідним кодом.
Метод покриття вимог може залишити неперевіреними деякі ділянки коду, тому що не враховує кінцевої реалізації.
Альтернативна думка
Покриття коду – абсолютно марна метрика. Немає «правильного» показника. Це питання-пастка. У вас може бути проект із близьким до 100% покриттям коду, в якому, як і раніше, залишаються баги та проблеми. Насправді потрібно стежити за іншими метриками - добре відомими показниками CTM (Codepipes testing Metrics).
PDWT (відсоток розробників, що пишуть тести) – ймовірно, найважливіший показник. Немає сенсу говорити про антипатерни тестування ПЗ, якщо у вас взагалі немає тестів. Усі розробники у команді мають писати тести. Будь-яку нову функцію можна оголошувати зробленою лише якщо вона супроводжується одним чи кількома тестами.
PBCNT (відсоток багів, які призводять до створення нових тестів). Кожен баг у продакшні - чудовий привід для написання нового тесту, що перевіряє відповідне виправлення. Будь-який баг повинен з'явитися в продакшні не більше одного разу. Якщо ваш проект страждає від появи повторних багів навіть після їхнього початкового «виправлення», то команда дійсно виграє від використання цієї метрики.
PTVB (відсоток тестів, які перевіряють поведінку, а чи не реалізацію). Тісно пов'язані тести пожирають багато часу при рефакторингу основного коду.
PTD (відсоток детермінованих тестів від загальної кількості). Тести повинні завершуватися помилкою лише в тому випадку, якщо щось не так із бізнес-кодом. Якщо тести періодично ламаються без видимої причини – це величезна проблема. Якщо після прочитання про метрики ви, як і раніше, наполягаєте на встановленні жорсткого показника для покриття коду, я дам вам число 20%. Це число має використовуватися як емпіричне правило, що базується на законі Парето. 20% вашого коду викликає 80% ваших помилок
Джерела:
Дод. матеріал:
Last updated