Меню

Посібник «Все в одному» щодо густини дефектів - її значення та як його розрахувати.

all one guide defect density its importance

Спробуйте Наш Інструмент Для Усунення Проблем

Посібник з густини дефектів:

Тестові показники хитрі. Вони є єдиним способом вимірювання, однак різноманітність надзвичайна.

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

Майже кожна команда у світі покладається на Щільність дефектів, щоб зрозуміти тенденції дефектів.

Сьогоднішня стаття - це універсальний посібник з густини дефектів (ДД).

Керівництво по густині дефектів

Запитання та відповіді на інтерв’ю для тестування програмного забезпечення за 2 роки досвіду

Що ви дізнаєтесь:

Що таке щільність дефектів?

Давайте подивимось, що буквально означає щільність.

Це «ступінь компактності речовини (Джерело: Google)».

Отже, густина дефектів - це компактність дефектів у застосуванні. (Гаразд, це просто вдосконалена версія розподілу дефектів.)

Програми поділяються на функціональні області або більш технічно БЛОК (Тисяча рядків коду). Таким чином, середня кількість дефектів у розділі або на KLOC програмного додатка - це щільність помилок.

Як розраховується щільність помилок?

Це проста математика.

Крок 1: Зберіть сировину: Вам знадобиться загальна кількість. дефектів (для випуску / складання / циклу).

Крок No2: Обчисліть середнє значення no. дефектів / Функціональна зона або KLOC

Формула щільності дефекту на прикладі розрахунку:

Приклад №1: Для конкретного тестового циклу існує 30 дефектів у 5 модулях (або компонентах). Щільність буде:

Всього немає дефектів / Загальна кількість модулів = 30/5 = 6. DD на модуль дорівнює 6.

Приклад №2: Скажімо, іншою перспективою є 15 дефектів для 15KLOC. Тоді це буде:

Всього немає дефектів / KLOC = 30/15 = 0,5 = Щільність становить 1 Дефект на кожні 2 KLOC.

Приклад 2 призначений лише для тих команд, які знають про KLOC і яким потрібне вимірювання проти нього. Більшість команд не працюють із такою статистикою. Але якщо вам потрібно, ви можете дізнатися, скільки KLOC становить ваша заявка.

Чому важлива щільність помилок?

Кожен показник, який збирає команда тестування, передає одне з наступного:

  • Прогрес
  • Продуктивність
  • Якість

Якщо ні, ви марно витрачаєте час.

ДД - найефективніший спосіб зрозуміти якість.

Наприклад: Додаток із DD 5 на KLOC є кращою якістю порівняно з іншим із 15 на KLOC.

Чим вища щільність помилок, тим гірша якість.

Він служить двом важливим цілям:

  • Повідомте: Інформація - це сила, чи не так? Знання найслабших областей вашої програми допомагає вирішити, чи вона придатна для використання чи ні.
  • Заклик до дії: Модуль із вищим значенням DD потребує виправлення. ДД допомагає їх ідентифікувати.

Не можна

# 1)Не враховуйте дублікати / повернені дефекти

Неточно розрахована щільність дефектів може ввести вашу команду в оману.

Не включайте дублікати / повернені дефекти (не помилка, яка працює за призначенням, не відтворюється і т. д.) Це збільшує кількість загальних номерів. дефектів, що означає, що DD збільшиться пропорційно. Як результат, показник вашої дефектності буде свідчити про низьку якість, що може бути безумовним помилковим сигналом.

# два)Не робіть цього на основі даних за один день

Давайте розглянемо цю гіпотетичну ситуацію:

DD1

На 1-й день ДД вища. Це може негайно перевести вашу команду в режим паніки.

Тому, почекайте, поки у вас буде краща сировина. Іншими словами, дані за кілька днів.

Крім того, при обчисленні DD вам потрібен сукупний підрахунок дефектів.

У наведеній вище таблиці ваш ДД з 2-го дня не враховує кількість дефектів на сьогодні. Це лише дані цього дня.

У мене складається враження, що: 'Щільність дефектів з 2-го дня зменшується і збільшується, і немає тенденції'. Крім того, як можна зменшити щільність дефектів, коли нічого не робиться щодо дефектів, повідомлених напередодні? Чи не так? Подумай над цим.

Кращий спосіб зробити це:

LO2

Ще раз, якщо ви робите це щодня, враховуйте сукупну кількість дефектів.

Варіації

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

Всього немає високих / критичних дефектів на KLOC або модулі

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

При яких значеннях Щільності помилок програмне забезпечення стає неприйнятним?

Промисловий стандарт густини дефектів:

Ну, це різниться для кожної галузі, програми та кожної команди. Виробництво мало б певний поріг, і для ІТ це було б зовсім інакше.

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

Високий DD - це ваш показник, щоб глибше заглибитися та проаналізувати свої дефекти на їх наслідки.

Кому б не сподобалася нульова щільність дефектів, правда? Отже, навіть якщо не існує конкретного стандарту, чим нижче це значення, тим краще.

Заключні думки:

  • Це не передбачувальний підрахунок. Значення DD не допомагає очікувати майбутньої якості продукту. Це може бути краще чи гірше. Історичні дані не допоможуть передбачити майбутні прогнози.
  • Під час критичних етапів / циклів випробувань (таких як UAT), DD розраховується на основі часу.Наприклад: DD / Перша година, DD на день тощо.
  • При збиранні статистики кількох випусків / циклів дефектів щільність дефектів може бути за цикл або за випуск.
  • Просте графічне представлення табличних даних може бути таким:

DD3

Графік густини дефектів

На закінчення

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

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

Автор : Член команди STH Сваті написав цей детальний підручник.

Чи розраховуєте ви щільність дефектів у своїх командах? Якщо так, чи робите ви це за цикл, за модуль або за KLOC? Якщо ні, то які ще показники допомагають зрозуміти якість? Будь ласка, поділіться своїми коментарями та питаннями нижче.

Рекомендована література

^