Прагнете досягти 100% покриття тестами, А Вас не бентежить питання – 100% для чого і від чого прораховувати?

Найчастіше використовують наступні метрики:

  1. Відсоток ручних тестів покритих автоматизованими тестами
  2. Відсоток покритих тестами фіч (features)
  3. Відсоток покриття коду

Відсоток ручних тестів покритих автоматизованими тестами

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

Відсоток покритих тестами фіч (features)

Як визначити скільки функціоналу системи покрито ручними або автоматизованими тестами? Навіть якщо нам відомий повний список функціоналу і список пов’язаних перевірок з ним, то навіть у цьому випадку не можна чітко говорити про покриття, бо кожен фукціонал має свій певний список тестів (який може бути не повним для перевірки даного функціоналу). Більш того, а де гарантія що представлений список реалізованого функціоналу відповідає тому що розроблено (закодовано)? Завжди будуть “невраховані” фічі. Більш об’єктивною метрикою тому буде метрика- відсоток покриття коду.

Відсоток покриття коду

Практично кожна сучасна мова програмування володіє вбудованим інструментарієм, що дозволяє перевіряти шматки коду – а чи був виконаний кожен рядок коду в ході виконання тестів чи ні. Іншими словами, Ви запускаєте ці інструменти, потім запускаєте свої тести і отримуєте звіт про те, скільки рядків коду було виконано а скільки ні. Ця техніка відома як – покриття коду і є досить точною і доволі об’єктивною метрикою. Зазвичай вважається, що вона придатна лише для Unit тестів, проте, ніхто не заважає використовувати даний підхід і в інших тестах! Використовуючи такі інструменти аналізу коду, дуже важливою перевагою буде можливість виявлення непокритих тестами частин коду. У підсумку ми можемо додати нові тести для поліпшення покриття або видаляти невикористаний код (мертвий функціонал). Отримавши 100% за такою метрикою, ми отримаємо серйозну ступінь впевненості в тому, що ми близькі до вільного від багів стан :-). Крім цього, високий ступінь покриття коду сприяє регресії тестування, рефакторингу і поліпшення внутрішньої якості коду загалом. Звичайно аналіз рядків коду буде залежати від можливостей використовуваного інструменту, наприклад одні перевіряють тільки виконання рядків коду, інші перевірять умови, цикли і т.д.

І звичайно, 100% покриття тестами коду не гарантує відсутності багів!

У доказ хоча б той факт, що якщо всі рядки коду відпрацювали це ж не означає, що відпрацювали всі можливі варіанти (скажімо умов if). І невиключено, деякі рядки коду відпрацюють лише за деяких специфічних умов, і часом буває дуже складно перевірити ці специфічні умови, а наш інструмент позначить такий код як мертвий …

Загалом як видно, всі описані тут метрики мають свої плюси і недоліки. Але все ж таки грубу оцінку вони можуть завжди нам дати. Більш того, ми можемо погодитися:

Завжди є “щілинка” між поточним покриттям і 100%, потрібно намагатися знаходити золоту середину.
Навіть якщо піде багато часу-завжди потрібно мінімізувати розрив у покритті між новим функціоналом і вже покритими тестами функціями, а не збільшувати цей розрив.

А що б ми робили маючи ідеальні 100% покриття коду?

Маючи таке щастя ми б все одно не спочивали б на лаврах, нам довелося би гарцювати в тому напрямку далі (щоб зберігати 100% покриття):

Нові тести повинні створюватися під новий функціонал

  1. Кожна зміна, що ламає наші тести, повинна бути якомога швидше виправлена (мова йде і про баги -які потрібно буде швидко залагодити, і про зміни в коді)
  2. Коротше кажучи, досягнувши 100% покриття ми повинні будемо бути в змозі додавати тести швидше, ніж ми додаємо нові функції, щоб забезпечувати 100% покриття завжди.

Переклад параграфу із ось такої книжечки:

“Complete Guide to Test Automation”: Techniques, Practices, and Patterns for Building and Maintaining Effective Software Projects. Arnon Axelrod – 2018 (посилання активне пропонуємо завантажити)

Related posts

Leave a Comment

Цей сайт використовує Akismet для зменшення спаму. Дізнайтеся, як обробляються ваші дані коментарів.