Тестове покриття в тестуванні програмного забезпечення: як його виміряти

⚡ Розумний підсумок

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

  • 🎯 Визначення: Покриття тестами повідомляє, які вимоги, функції та шляхи коду вже виконуються існуючими тестами.
  • 🧭 типи: Оператор, гілка, умова, шлях, вимоги та покриття ризиків відповідають на різні запитання.
  • 🇧🇷 Code проти тесту: Code покриття вимірює виконані вихідні лінії, тоді як тестове покриття вимірює загальний план тестування.
  • 🧮 формула: Поділіть виконані рядки на загальну кількість рядків, потім помножте на 100, щоб отримати відсоток.
  • 🛠️ Техніка: Аналіз граничних значень, таблиці рішень та тестування переходів станів розширюють охоплення без перебільшення набору.
  • 📈 Оптимізація: Ранжуйте модулі за ризиком, автоматизуйте набір регресій та переглядайте тенденцію покриття кожного спринта.
  • 🤖 Допомога AI: Інструменти штучного інтелекту генерують відсутні модульні тести та ранжують непротестовані шляхи за ризиком виробництва.

Що таке тестове покриття?

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

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

Що робить тестове покриття?

У реальному проекті тестове покриття підтримує чотири практичні дії:

  • Пошук області вимоги, не реалізованої набором тестів
  • Допомагає створити додаткові тестові випадки для збільшення покриття
  • Визначення кількісної міри охоплення тестом, яка є непрямим методом перевірки якості
  • Виявлення безглуздих тестових випадків, які не збільшують покриття

Переваги тестового покриття в розробці програмного забезпечення

Ці дії перетворюються на конкретні інженерні переваги.

  • Це може гарантувати якість тесту
  • Це може допомогти визначити, які частини коду були фактично застосовані для випуску чи виправлення
  • Він може визначити всі точки прийняття рішень та шляхи у вашій програмі, які не були протестовані, що дозволяє збільшити охоплення тестуванням.
  • Запобігати дефект витік
  • Час, обсяг і вартість можна тримати під контролем
  • Запобігання дефектам на ранній стадії життєвого циклу проекту
  • Прогалини у вимогах, тестових випадках і дефекти на рівні модуля та коду можна знайти простим способом

Типи тестового покриття

Покриття ніколи не буває одним числом. Команди track кілька типів одночасно, оскільки кожен відповідає на різні запитання щодо одного й того ж набору. У таблиці нижче згруповано типи, які ви зустрічаєте найчастіше.

Тип покриття Що він вимірює Найкраще використовувати для
Покриття виписки (рядка) Виконувані рядки виконуються принаймні один раз Модульні тести та аудит застарілого коду
Покриття відділень або рішень Правдивий та хибний результат кожного рішення Умовна та валідаційна логіка
Покриття стану Кожен логічний підвираз як істина та хибність Складені вирази І або АБО
Покриття шляху Унікальні маршрути, пройдені через модуль Критично важливі для безпеки та фінансові потоки
Функціональне покриття Функції або методи, що викликаються тестами API та сервісні рівні
Покриття вимог Вимоги, зіставлені принаймні з одним тестом Прийняття та протиtracвнутрішнє підписання
Покриття ризиків Визначені зони високого ризику, що підлягають навчанню Короткі цикли випуску

Перші п'ять типів є мірами рівня коду та належать до тестування білої скриньки, тоді як вимоги та покриття ризиків знаходяться на рівні плану тестування.

Які основні відмінності між Code Покриття та покриття тестами?

Code охоплення і тестове покриття — це методи вимірювання, які дозволяють оцінити якість коду програми.

Ось деякі критичні відмінності між кабінами цих методів покриття:

Параметри Code Покриття Покриття тесту
Визначення Code термін покриття, який використовується, коли код програми виконується під час її роботи. Тестове покриття означає загальний план тестування.
Мета Code Метрики покриття можуть допомогти команді контролювати свої автоматизовані тести. Тестове покриття містить інформацію про рівень, до якого було перевірено письмове кодування програми.
Підтипи Code покриття, поділене на підтипи, такі як покриття операторів, покриття умов, покриття гілок, Togglелектронне покриття, покриття FSM. Немає підтипу методу тестового покриття.

Формула тестового покриття

Щоб розрахувати тестове покриття, вам потрібно виконати наведені нижче дії.

Крок 1) Рахувати Y, загальна кількість рядків коду у програмному забезпеченні, яке ви використовуєте Тестування

Крок 2) Рахувати X, кількість рядків коду, які виконуються на даний момент усі тестові випадки

Тепер вам потрібно знайти (X, поділене на Y), помножене на 100. Результатом цього обчислення є % вашого тестового покриття.

Наприклад:

Якщо кількість рядків коду в системному компоненті становить 500, а кількість рядків, виконаних у всіх існуючих тестових випадках, становить 50, тоді ваше тестове покриття буде:

(50 / 500) * 100 = 10%   // executed lines divided by total lines

Приклади тестового покриття

Сам лише відсоток ніколи не вирішує всієї проблеми, як показують наведені нижче приклади.

Приклад 1:

Наприклад, якщо «ніж» – це предмет, який ви хочете протестувати, тоді вам потрібно зосередитися на перевірці, чи він точно ріже овочі чи фрукти. Однак є й інші аспекти, на які слід звернути увагу, наприклад, чи повинен користувач мати змогу зручно ним користуватися.

Приклад 2:

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

Методи тестового покриття

Обидва приклади вказують на один і той самий висновок: досягнення цільового показника охоплення залежить не стільки від написання більшої кількості тестів, скільки від вибору правильної методики розробки тестів. Наведені нижче методи розширюють охоплення, зберігаючи при цьомуping люкс маленький.

  • Аналіз граничних значень: Вибирає вхідні дані на межах кожного допустимого діапазону, де дефекти скупчуються найбільше. Див. аналіз граничних значень для опрацьованих справ.
  • Розбиття еквівалентності: Групує вхідні дані, які програма обробляє однаково, тому один випадок може безпечно представляти цілий клас значень.
  • Тестування таблиці рішень: Охоплює комбінації умов та їх очікуваних результатів в межах однієї сітки.
  • Тестування переходу станів: Виконує кожен дійсний та недійсний перехід між станами програми.
  • Тестування базового шляху: Виводить мінімальний набір незалежних шляхів з графа потоку керування.
  • Тестування на основі ризику: Ранжує функції за впливом на бізнес та спочатку охоплює ті, що мають найвищий ризик.
  • Пошукове тестування: Виявляє прогалини, які ніколи не розкриваються у сценаріях справ та звітах про висвітлення.

Як можна забезпечити охоплення тестуванням?

Після вибору методів покриття забезпечується чотирма встановленими маршрутами.

  • Тестове покриття можна здійснити за допомогою методів статичної перевірки, таких як експертні оцінки, інспекції та покрокове керівництво
  • Шляхом перетворення спеціальних дефектів у виконувані тестові випадки
  • На рівні коду або модульного тестування охоплення тестом можна досягти, скориставшись інструментами автоматизованого покриття коду або модульного тестування
  • Функціональне покриття тесту можна здійснити за допомогою відповідних інструментів керування тестуванням

Як покращити охоплення тестуванням

Встановлення покриття – це відправна точка; його підвищення – це повторювана процедура. Виконуйте цю послідовність на початку кожного циклу випуску.

  1. Встановіть поточне число в базовій точці. Запустіть звіт про покриття та оператор запису, гілку та покриття вимог окремо, щоб прогалини залишалися видимими для кожного модуля, а не прихованими в одному середньому показнику для всього проекту.
  2. Зіставте тести з вимогами. Побудуйте a tracсітка зручності, яка пов'язує кожну вимогу принаймні з одним тестовим випадком. Будь-який порожній рядок є підтвердженим прогалином, а не підозрою.
  3. Ранжуйте модулі за ризиком. Логіка платежів, автентифікації та міграції даних заслуговує на набагато глибше висвітлення, ніж статичний екран довідки, тому витрачайте бюджет там, де збій завдасть найбільшого шкоди.
  4. Додайте негативні та граничні випадки. Порожні входи, завеликі значення, тайм-аути мережі та помилки дозволів досягають гілок, яких тести щасливого шляху ніколи не торкаються.
  5. Викладіть рівні тесту нашаруваннями. Поєднувати одиничне тестування, інтеграційне тестування, та наскрізні перевірки, оскільки кожен рівень охоплює те, що інші структурно не можуть.
  6. Автоматизуйте набір регресійних алгоритмів. Promoстабільні випадки в тестування автоматизації та виконати їх усередині Конвеєр CI/CD після кожного коміту.
  7. Вилучіть зайві справи. Видаліть дублікати тестів, які додають хвилини виконання, не додаючи жодного непокритого рядка.
  8. Revпереглядайте тренд кожного спринта. Tracпокриття k поруч щільність дефектівЗростання витоку на тлі плоского покриття є раннім попередженням про сліпу зону.

⚠️ Попередження: Не ставтеся до 100 відсотків як до мети. Набір на 85 відсотках із сильними твердженнями захищає реліз набагато краще, ніж 95 відсотків поверхневих перевірок, які виконують код без перевірки жодного результату.

Недоліки тестового покриття

Висвітлення залишається цінним, проте воно має обмеження, які варто врахувати, перш ніж повідомляти будь-який відсоток.

  • Більшість завдань у тестовому покритті виконуються вручну, оскільки немає інструментів для автоматизації. Тому для аналізу вимог і створення тестових випадків потрібно багато зусиль.
  • Тестове покриття дозволяє підрахувати функції, а потім порівняти з кількома тестами. Однак завжди є простір для помилкових суджень.

Поширені запитання

Більшість команд розглядають 70-80 відсотків як практичну ціль, а для критично важливих для безпеки модулів — 90 відсотків або вище. Прагнення до 100 відсотків рідко окуповує зусилля. Надайте пріоритет глибині роботи з логікою високого ризику, замість того, щоб рівномірно розподіляти тести по всій кодовій базі.

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

Звіт про покриття містить перелік покритих та непокритих рядків, гілок та функцій для кожного файлу, а також відсотки, зведені за модулями та проектами. Такі інструменти, як JaCoCo також позначте частково закриті гілки, зазвичай найшвидші прогалини для закриття.

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

Так. Такі інструменти, як Diffblue автоматично писати модульні тести для невиявленої логіки, а генеративні моделі перетворюють вимоги, написані простою мовою, на виконувані випадки. Перевірка людиною залишається важливою, оскільки згенеровані твердження можуть пройти перевірку без перевірки змістовної поведінки.

Підсумуйте цей пост за допомогою: