all one guide defect density its importance
Ръководство за дефектна плътност:
Тестови показатели са трудни. Те са единственият начин за измерване, но разнообразието е огромно.
Може да събирате нещо, което не ви дава анализите, които искате. Най-сигурният начин тук е да вървите по добре утъпканата пътека.
Почти всеки екип в света разчита на дефектната плътност, за да разбере дефектните тенденции.
Днешната статия е всичко-в-едно ръководство за дефектна плътност (DD).
кой от следните не е в състояние на тестване на системата?
Какво ще научите:
- Какво е плътност на дефектите?
- Как се изчислява Плътността на грешките?
- Защо плътността на бъговете е важна?
- Не
- Вариации
- При какви стойности на плътността на грешките софтуерът става неприемлив?
- Финални мисли:
- В заключение
- Препоръчително четене
Какво е плътност на дефектите?
Нека разгледаме какво буквално означава плътност.
Това е „степента на компактност на дадено вещество (Източник: Google)“.
И така, Defect Density е компактността на дефектите в приложението. (Добре, значи това е просто усъвършенствана версия на разпространението на дефекти.)
Приложенията са разделени на функционални области или по-технически БЛОК (Хиляди редове код). По този начин, средният брой дефекти в секция или за KLOC на софтуерно приложение е плътност на грешките.
Как се изчислява Плътността на грешките?
Това е проста математика.
Етап 1: Съберете суровината: Ще ви трябва общо не. на дефекти (за освобождаване / изграждане / цикъл).
Стъпка 2: Изчислете средното не. на дефекти / Функционална област или KLOC
Формула за плътност на дефекти с пример за изчисление:
Пример # 1: За определен тестов цикъл има 30 дефекта в 5 модула (или компоненти). Плътността ще бъде:
Общо не. от дефекти / Общ брой от модули = 30/5 = 6. DD на модул е 6.
Пример # 2: Друга перспектива би била, да речем, има 30 дефекта за 15KLOC. Тогава ще бъде:
Общо не. от дефекти / KLOC = 30/15 = 0,5 = Плътността е 1 Дефект за всеки 2 KLOC.
Пример 2 е само за тези отбори, които са наясно с KLOC и които се нуждаят от измерване срещу него. Повечето отбори не работят с такъв вид статистика. Но ако трябва, можете да разберете колко KLOC е вашето приложение.
Защо плътността на бъговете е важна?
Всеки показател, който тестовият екип събира, предава едно от следните:
- Напредък
- Производителност
- Качество
Ако не, губите времето си.
DD е най-ефективният начин за разбиране на качеството.
Например: Приложение с DD 5 за KLOC е с по-добро качество спрямо друго с 15 за KLOC.
Колкото по-висока е плътността на грешките, толкова по-лошо е качеството.
Той служи на две важни цели:
- Информирам: Информацията е сила, нали? Познаването на най-слабите области на вашето приложение помага да решите дали е „годно за използване“ или не.
- Призив за действие: Модул с по-висока DD има нужда от поправка. ДД помага да ги идентифицира.
Не
# 1)Не вземайте под внимание дубликати / върнати дефекти
Неточно изчислената дефектна плътност може да заблуди вашия екип.
Не включвайте дубликати / върнати дефекти (не грешка, работеща по предназначение, не се възпроизвежда и др.) Увеличава броя на общите не. на дефекти, което означава, че ДД ще се увеличи пропорционално. В резултат на това показателят ви за дефекти ще предполага лошо качество, което би било категорична фалшива аларма.
# две)Не правете това въз основа на данни от един ден
Нека разгледаме тази хипотетична ситуация:
На 1 ден ДД е по-висока. Това може незабавно да изпрати екипа ви в режим на паника.
Така, изчакайте, докато имате по-добра суровина. С други думи, данни за няколко дни.
Също така, когато изчислявате DD, искате кумулативен брой дефекти.
В горната таблица вашият ДД от Ден 2 нататък не отчита броя на дефектите до момента. Той разглежда само данните от този ден.
Това ми създава впечатлението, че: „Плътността на дефектите от ден 2 намалява и се увеличава и няма тенденция.“ Също така, как може да се намали плътността на дефектите, когато нищо не се прави по дефектите, отчетени в предния ден? Нали? Помисли за това.
По-добър начин да направите това е:
Още веднъж, ако правите това ежедневно, вземете предвид кумулативния брой дефекти.
Вариации
В зависимост от нивото на усъвършенстване, от което се нуждае вашият екип, можете да промените този показател за дефекти.
- За ДД на Проблеми с висока / критична тежест , вашата формула може да бъде:
Общо не. на високи / критични дефекти на KLOC или модули
- Можете да направите това и за връщане на проблеми по модули. Тук ще съберете само броя на проблемите, които продължават да се връщат в компилации / издания
При какви стойности на плътността на грешките софтуерът става неприемлив?
Индустриален стандарт за плътност на дефекти:
Е, това варира за всяка индустрия, приложение и всеки екип. Производството би имало специфичен праг и би било напълно различно за ИТ.
DD по номинална стойност показва лошо качество. Но от своя страна сериозността на отделните дефекти определя дали продуктът е годен за употреба или не.
Високата DD е вашият индикатор за задълбочаване и анализиране на вашите дефекти за техните последици.
Кой не би искал нулева плътност на дефектите, нали? Следователно, въпреки че няма конкретен стандарт, колкото по-ниска е тази стойност, толкова по-добре.
Финални мисли:
- Това не е предсказуем брой. Стойността на DD не помага да се очаква бъдещото качество на продукта. Може да е по-добре или по-лошо. Историческите данни няма да помогнат за бъдещи прогнози.
- По време на критични етапи / цикли на изпитване (като UAT), DD се изчислява въз основа на времето.Например: DD / първи час, DD на ден и др.
- Когато се съпоставят статистически данни за дефекти на множество освобождавания / цикли, плътността на дефектите може да бъде за цикъл или за издание.
- Просто графично представяне на табличните данни може да бъде както по-долу:
В заключение
Плътността на дефектите е ключов показател за качество. Не можете да сгрешите със събирането и представянето на този показател за дефекти. Какво още? Той е един от най-лесните за изчисляване.
Надявам се, че тази статия ви е предоставила достатъчно излагане, за да започнете да използвате плътността на дефектите за по-задълбочени прозрения.
Автор : Член на екипа на STH Swati е написал този подробен урок.
Изчислявате ли плътността на дефектите във вашите отбори? Ако да, правите ли го на цикъл, на модул или на KLOC? Ако не, какви други показатели ви помагат да разберете качеството? Моля, споделете вашите коментари и въпроси по-долу.
Препоръчително четене
- Какво представлява техниката за изпитване на базата на дефекти?
- Алфа тестване и бета тестване (Пълно ръководство)
- Най-добрите услуги за тестване на QA софтуер от SoftwareTestingHelp
- Видове тестване на софтуер: Различни видове тестване с подробности
- Софтуерното тестване е всичко за идеите (и как да ги генерирам)
- Перфектно ръководство за възобновяване на тестване на софтуер (с проба за възобновяване на софтуерния тестер)
- Функционално тестване срещу нефункционално тестване
- Какво представлява жизнения цикъл на дефекти / грешки при тестване на софтуер? Урок за жизнения цикъл на дефекти