Показники тестування програмного забезпечення: що таке, типи та приклади
Редакційна колегія
⚡ Розумний підсумок
Метрики тестування програмного забезпечення – це кількісні показники прогресу, якості та продуктивності процесу тестування. У цьому посібнику розглядаються три типи метрик, розмежування між базовими та обчислюваними, життєвий цикл метрик та глосарій формул, які можна застосовувати безпосередньо.
Що таке метрики тестування програмного забезпечення?
Показники тестування програмного забезпечення це кількісні показники, які використовуються для оцінки прогресу, якості, продуктивності та працездатності процесу тестування програмного забезпечення. Метою показників тестування програмного забезпечення є підвищення ефективності та результативності процесу тестування програмного забезпечення та сприяння прийняттю кращих рішень щодо подальшого процесу тестування шляхом надання надійних даних про процес тестування.
Метрика кількісно виражає ступінь, до якої система, компонент або процес володіє певною характеристикою. Проста аналогія — це фактичне тижневе споживання палива автомобілем у порівнянні з показником, зазначеним виробником.
Показники тестування програмного забезпечення – покращує ефективність і результативність процесу тестування програмного забезпечення.
Показники тестування програмного забезпечення або вимірювання тестування програмного забезпечення є кількісним показником ступеня, потужності, розміру, кількості або розміру деяких атрибутів процесу або продукту.
Приклад тестового вимірювання програмного забезпечення: Загальна кількість дефектів
Чому важливі показники тестування?
«Ми не можемо покращити те, що не можемо виміряти». Метрики тестування існують для того, щоб зробити процес тестування вимірюваним.
- Визначте, яким має бути наступний етап діяльності
- Надайте докази твердження або прогнозу щодо якості
- Визначте, який вид покращення необхідний
- Обґрунтуйте зміну процесу або технології
Докладніше про це Важливість тестових показників
Типи тестових метрик
- Показники процесу: Його можна використовувати для підвищення ефективності процесу SDLC (Життєвий цикл розробки програмного забезпечення)
- Показники продукту: Це стосується якості програмного продукту
-
Показники проекту: Його можна використовувати для вимірювання ефективності команди проекту чи будь-якої іншої інструменти тестування використовується членами команди
Вибір правильних показників важливіший, ніж просто збір багатьох з них. Перш ніж зупинитися на певному наборі, врахуйте наступне:
- Визначте цільову аудиторію для підготовки метрики
- Визначте мету для показників
- Введіть усі відповідні показники на основі потреб проекту
- Зважте витрати та вигоди кожного показника, а також фазу життєвого циклу проекту, на якій він забезпечує найбільшу цінність
Ручні тестові метрики
In Розробка програмного забезпеченняМетрики ручного тестування поділяються на два класи
- Базові показники
- Розраховані метрики
Базові показники — це необроблені дані, зібрані Test Analyst під час розробки та виконання тесту (Кількість виконаних тестів, Кількість тестів). Тоді як обчислені показники виводяться з даних, зібраних у базових показниках. Менеджер тестування зазвичай стежить за розрахованими показниками для звітування про тестування (% виконано, % тестове покриття).
Залежно від проекту або бізнес-моделі, найважливішими показниками зазвичай є:
- Показники продуктивності виконання тестів
- Показники продуктивності підготовки тестів
- Показники дефектів
- Дефекти за пріоритетністю
- Дефекти за ступенем тяжкості
- Коефіцієнт ковзання дефекту
Метрики ручного та автоматизованого тестування
Описані вище метрики передбачають ручне виконання набору. Автоматизований набір вимірюється по-іншому, оскільки обсяг виконуваних дій більше не є обмеженням.
| Критерії | Метрики ручного тестування | Метрики автоматизованого тестування |
|---|---|---|
| Основний фокус | Зусилля та прогрес у виконанні | Покриття, стабільність та час роботи |
| Типова міра | Тестові випадки, що виконуються щодня | Відсоток покриття автоматизації |
| Якісний сигнал | Дефектів, виявлених за годину тестування | Нестабільний рівень тестування, частка нестабільних тестів |
| Вимірювання вартості | Години тестування | Години обслуговування скриптів на реліз |
| Вимірювання швидкості | Тривалість циклу в днях | Час виконання пакету в хвилинах |
Automation Coverage = (Test cases automated / Total test cases) x 100 Flaky Test Rate = (Tests with inconsistent results / Total automated tests) x 100
Нестабільний рівень тестування заслуговує на особливу увагу. Як тільки він перевищує приблизно 5 відсотків, команди починають ігнорувати червоні збірки, і в цей момент пакет перестає надавати інформацію незалежно від того, наскільки високий рівень покриття.
Життєвий цикл тестових показників у програмній інженерії
| Різні етапи життєвого циклу метрики | Кроки на кожному етапі |
|---|---|
| Аналіз |
|
| Комунікація |
|
| Оцінка |
|
| доповідь |
|
Як розрахувати тестовий показник
| Sr# | Кроки для тестування показників | Приклад |
|---|---|---|
| 1 | Визначте ключ тестування програмного забезпечення процеси, що підлягають вимірюванню | Хід тестування tracкоролівський процес |
| 2 | На цьому кроці тестувальник використовує дані як базову лінію для визначення показників | Кількість тестів, які планується виконати на день |
| 3 | Визначення інформації, якої слід дотримуватися, частоти tracкороль і відповідальна особа | Фактичне виконання тесту за день буде зафіксовано менеджером тестування в кінці дня |
| 4 | Ефективний розрахунок, управління та інтерпретація визначених показників | Фактичні тестові випадки, виконані за день |
| 5 | Визначте сфери покращення залежно від інтерпретації визначених показників | If тестовий випадок виконання не відповідає узгодженій меті, дослідити причину та запропонувати коригувальні заходи |
Приклад розрахунку тестової метрики
Розглянемо відсоток виконаних тестових випадків як приклад розв'язання задачі. Щоб виразити стан виконання у відсотках, використовуйте формулу:
Percentage test cases executed= (No of test cases executed/ Total no of test cases written) X 100
Якщо було написано 250 тестових випадків і виконано 175, результат буде (175 / 250) x 100 = 70 відсотків.
Така ж схема застосовується до всіх інших параметрів виконання: тестові випадки, що не виконані, пройдені, не виконані та заблоковані. Кожен з них — це просто різний чисельник у знаменнику.
Найважливіші показники тестування для Track
У глосарії в кінці цього посібника перелічені всі формули, що зазвичай використовуються. На практиці пакет звітів рідко потребує більше восьми. Саме ці формули постійно впливають на прийняття рішення.
| Metric | На що це відповідає | Слідкуйте |
|---|---|---|
| Відсоток виконання тестового випадку | Як далеко ми пройшли запланований пробіг? | Нічого не говорить про якість, лише про прогрес |
| Щільність дефектів | Дефекти на одиницю розміру, тож який модуль найслабший? | Залежить від послідовної міри розміру |
| Ефективність усунення дефектів | Яку частку дефектів ми виявили до релізу? | Може бути остаточно визначено лише після отримання виробничих даних |
| Витік дефектів | Скільки дефектів дійшло до замовника? | Найважливіший сигнал якості |
| Випробування покриття | Яка частина встановленої вимоги виконується? | Високе висвітлення зі слабкими твердженнями нічого не доводить |
| Індекс серйозності дефектів | Відкриті дефекти є серйозними чи косметичними? | Підрахунок дефектів без зважування вводить в оману |
| Середній час ремонту | Як швидко команда виправляє проблему? | Спотворено кількома довготривалими дефектами |
| Продуктивність виконання тестів | Скільки справ виконує тестер на день? | Заохочує поверхневі тести, якщо їх використовувати як ціль |
Дві формули, які варто додати до глосарію, оскільки саме їх запитує керівництво:
Defect Removal Efficiency = (Defects found before release / Total defects found) x 100
Defect Leakage = (Defects found in production / Defects found before release) x 100
Пастка вимірювання. Будь-яка метрика, яка використовується як ціль, перестає бути хорошим виміром. Встановіть ціль продуктивності в 30 тестових випадків на день, і тестувальники напишуть 30 тривіальних. Повідомляйте про метрики як набір, ніколи окремо, і поєднуйте кожен показник продуктивності з показником якості.
Глосарій формул метрик тестування програмного забезпечення
- Коефіцієнт зусиль переробки = (Фактичні зусилля, витрачені на цьому етапі/загальні фактичні зусилля, витрачені на цьому етапі) X 100
- Вимога Creep = (Загальна кількість доданих вимог/кількість початкових вимог) X100
- Відхилення графіка = (Фактична дата доставки – запланована дата доставки)
- Вартість виявлення дефекту при тестуванні = (Загальні зусилля, витрачені на тестування/дефекти, виявлені під час тестування)
- Розклад розкладу = (Фактична дата закінчення – Орієнтовна дата завершення) / (Запланована дата завершення – Запланована дата початку) X 100
- Відсоток пройдених тестів = (Кількість пройдених тестів/Загальна кількість виконаних тестів) X 100
- Відсоток невдалих тестів = (Кількість невдалих тестів/Загальна кількість виконаних тестів) X 100
- Відсоток заблокованих тестових випадків = (Кількість заблокованих тестів/Загальна кількість виконаних тестів) X 100
- Відсоток виправлених дефектів = (Виправлені дефекти/Повідомлено про дефекти) X 100
- Відсоток прийнятих дефектів = (Дефекти, прийняті командою розробників як дійсні /Загальна кількість повідомлених дефектів) X 100
- Відкладений відсоток дефектів = (Дефекти, відкладені для майбутніх випусків /Загальна кількість повідомлених дефектів) X 100
- Відсоток критичних дефектів = (Критичні дефекти / Загальна кількість зареєстрованих дефектів) X 100
- Середній час, необхідний групі розробників для усунення дефектів = (Загальний час, витрачений на виправлення помилок/кількість помилок)
- Кількість проведених тестів за період часу = Кількість проведених тестів/Загальний час
- Тест ефективності дизайну = Кількість розроблених тестів / Загальний час
- Ефективність перевірки тесту = Кількість перевірених тестів / Загальний час
- Коефіцієнт знаходження помилок, або кількість дефектів за годину випробувань = Загальна кількість дефектів / Загальна кількість годин випробувань
