Показатели за тестване на софтуер: какво е, видове и пример
Томас Хамилтън
⚡ Умно обобщение
Метриките за софтуерно тестване са количествени мерки за напредъка, качеството и производителността на процеса на тестване. Това ръководство обхваща трите типа показатели, разграничението между базови и изчислени, жизнения цикъл на показателите и речник на формулите, които можете да прилагате директно.
Какво представляват показателите за тестване на софтуер?
Показатели за тестване на софтуер са количествените мерки, използвани за оценка на напредъка, качеството, производителността и здравето на процеса на тестване на софтуера. Целта на показателите за тестване на софтуер е да се подобри ефикасността и ефективността в процеса на тестване на софтуера и да се помогне при вземането на по-добри решения за по-нататъшния процес на тестване чрез предоставяне на надеждни данни за процеса на тестване.
Метриката изразява количествено степента, до която дадена система, компонент или процес притежава даден атрибут. Проста аналогия е действителният седмичен разход на гориво на автомобила в сравнение с цифрата, посочена от производителя.
Показатели за тестване на софтуер – Подобрява ефективността и ефективността на процеса на тестване на софтуер.
Метриките за тестване на софтуер или измерването на теста на софтуера е количествена индикация за степента, капацитета, измерението, количеството или размера на някои атрибути на процес или продукт.
Пример за софтуерно тестово измерване: Общ брой дефекти
Защо са важни тестовите показатели?
„Не можем да подобрим това, което не можем да измерим.“ Тестовите показатели съществуват, за да направят процеса на тестване измерим.
- Решете каква трябва да бъде следващата фаза от дейностите
- Предоставете доказателства за твърдение или прогноза относно качеството
- Определете какъв вид подобрение е необходимо
- Обосновете промяна на процеса или технологията
Прочетете повече за него Значение на тестовите показатели
Видове тестови показатели
- Показатели на процеса: Може да се използва за подобряване на ефективността на процеса на 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 процента, екипите започват да игнорират червените компилации и в този момент пакетът спира да предоставя информация, независимо от това колко високо е покритието му.
Жизнен цикъл на тестови показатели в софтуерното инженерство
| Различни етапи от жизнения цикъл на Metrics | Стъпки по време на всеки етап |
|---|---|
| Анализ |
|
| Общувайте |
|
| Оценка |
|
| доклад |
|
Как да изчислим тестов показател
| 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
Речникът в края на този урок изброява всички често използвани формули. На практика, един пакет за отчитане рядко се нуждае от повече от осем. Това са формулите, които постоянно водят до вземане на решение.
| метричен | На какво отговаря | Внимавай за |
|---|---|---|
| Процент на изпълнение на тестовия случай | Докъде сме стигнали с планираното бягане? | Не говори нищо за качество, само за напредък |
| Плътност на дефектите | Дефекти на единица размер, така че кой модул е най-слаб? | Зависи от постоянна мярка за размер |
| Ефективност на отстраняване на дефекти | Какъв дял от дефектите открихме преди пускането им? | Може да бъде финализирано едва след получаване на производствените данни |
| Дефектно изтичане | Колко дефекта са достигнали до клиента? | Най-важният сигнал за качество |
| Тестово покритие | Каква част от зададеното изискване се изпълнява? | Високото отразяване със слаби твърдения не доказва нищо |
| Индекс на тежест на дефекта | Сериозни ли са откритите дефекти или козметични? | Броенето на дефекти без претегляне подвежда |
| Средно време за ремонт | Колко бързо екипът решава проблема? | Изкривено от няколко дългогодишни дефекта |
| Производителност на изпълнението на тестовете | Колко случая завършва един тестер на ден? | Насърчава повърхностни тестове, ако се използват като цел |
Две формули, които си струва да се добавят към речника, защото ръководството изисква именно тях:
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
- Средно време за екип за разработка за отстраняване на дефекти = (Общо време, необходимо за корекции на грешки/Брой грешки)
- Брой тестове, изпълнени за период от време = Брой изпълнени тестове/Общо време
- Тествайте ефективността на дизайна = Брой проектирани тестове/Общо време
- Тествайте ефективността на прегледа = Брой прегледани тестове / Общо време
- Процент на откриване на грешки, или дефекти на час тест = Общ брой дефекти / Общ брой часове тест
