Жизнен цикъл на дефект/бъг при тестване на софтуер

по: Томас Хамилтън Томас Хамилтън
Hours Обновено
Ключови храни за вкъщи Това ръководство обяснява етапите от жизнения цикъл на дефекта, помагайки на читателите да разберат проследяването на грешки, комуникационния процес и ефективното разрешаване на проблемите от откриването до затварянето им.

Жизнен цикъл на дефект/бъг

Какво е жизнен цикъл на дефект/бъг?

Жизнен цикъл на дефекта или Жизнен цикъл на грешка в софтуерното тестване е специфичният набор от състояния, през които преминава дефектът или грешката през целия си живот. Целта на жизнения цикъл на дефекта е лесно да координира и комуникира текущото състояние на дефекта, което се променя на различни правоприемници, и да направи процеса на коригиране на дефект систематичен и ефективен.

👉 Запишете се за безплатен проект за тестване на софтуер на живо

Състояние на дефекта

Състояние на дефекта или Състояние на грешка в жизнения цикъл на дефекта е настоящото състояние, от което дефектът или грешката преминава в момента. Целта на статуса на дефекта е да предаде точно текущото състояние или напредъка на дефект или грешка, за да може по-добре да се проследи и разбере действителния напредък на жизнения цикъл на дефекта.

Работен процес на състояния на дефекти

Броят на състоянията, през които преминава даден дефект, варира от проект до проект. По-долу диаграмата на жизнения цикъл обхваща всички възможни състояния

  • Ново: Когато нов дефект се регистрира и публикува за първи път. Присвоен му е статус НОВ.
  • Възложено: След като грешката бъде публикувана от тестера, лидерът на тестера одобрява грешката и я присвоява на екипа от програмисти
  • отворено: Разработчикът започва да анализира и работи по отстраняването на дефекта
  • определен: Когато програмист направи необходимата промяна на кода и потвърди промяната, той или тя може да направи състояние на грешка като „Поправено“.
  • Предстои повторен тест: След като дефектът бъде коригиран, разработчикът дава конкретен код за повторно тестване на кода на тестера. Тъй като тестване на софтуер остава в очакване от края на тестерите, присвоеният статус е „предстоящ повторен тест“.
  • ретест: Тестерът прави повторно тестване на кода на този етап, за да провери дали дефектът е коригиран от разработчика или не и променя състоянието на „Повторно тестване“.

Работен процес на състояния на дефекти

  • Потвърден: Тестерът тества отново грешката, след като е била коригирана от разработчика. Ако няма открита грешка в софтуера, тогава грешката е коригирана и зададеният статус е „потвърден“.
  • Повторно отваряне: Ако грешката продължава дори след като програмистът е коригирал грешката, тестерът променя състоянието на „отново отворено“. За пореден път грешката преминава през жизнения си цикъл.
  • Затворен: Ако грешката вече не съществува, тогава тестерът присвоява статус „Затворено“. 
  • Дубликат: Ако дефектът се повтаря два пъти или дефектът съответства на една и съща концепция на грешката, състоянието се променя на „дубликат“.
  • Отхвърлено: Ако разработчикът смята, че дефектът не е истински дефект, той променя дефекта на „отхвърлен“.
  • Разсрочено: Ако настоящата грешка не е с първостепенен приоритет и ако се очаква да бъде коригирана в следващото издание, тогава на такива грешки се присвоява статус „Отложено“
  • Не е грешка: Ако не засяга функционалността на приложението, тогава статусът, присвоен на грешка, е „Не е грешка“.

СВЪРЗАНИ СТАТИИ

Обяснен жизнен цикъл на дефект/бъг

Жизнен цикъл на дефект или жизнен цикъл на бъгове – неща, които трябва да знаете!

  1. Тестерът открива дефекта
  2. Статус, присвоен на дефект - Нов
  3. Дефектът се изпраща на ръководителя на проекта за анализ
  4. Мениджърът на проекта решава дали даден дефект е валиден
  5. Тук дефектът не е валиден – даден е статус „Отхвърлен“.
  6. И така, мениджърът на проекта присвоява статус отхвърлена. Ако дефектът не е отхвърлен, следващата стъпка е да се провери дали е в обхвата. Да предположим, че имаме друга функция – имейл функционалност за същото приложение и вие откривате проблем с това. Но това не е част от текущата версия, когато такива дефекти са присвоени като a отложено или отложено статус.
  7. След това мениджърът проверява дали подобен дефект е бил повдигнат по-рано. Ако да, на дефекта се присвоява статус дубликат.
  8. Ако не, дефектът се възлага на разработчика, който започва да коригира кода. По време на този етап на дефекта се присвоява статус в ход.
  9. След като кодът е фиксиран. На дефект се присвоява статус фиксиран
  10. След това тестерът ще тества отново кода. В случай, Тестов случай преминава дефектът е затворен. Ако тестовите случаи се провалят отново, дефектът е отваря врати отново и се възлага на разработчика.
  11. Помислете за ситуация, при която по време на 1-вото издание на резервация за полет е открит дефект в поръчката за факс, който е коригиран и му е присвоен статус затворен. По време на второто издание на надстройката същият дефект отново се появи отново. В такива случаи ще има затворен дефект отворен отново.

Това е всичко за жизнения цикъл на бъгове

Това видео за обучение описва различните етапи в жизнения цикъл на грешка, известна още като дефект, и нейното значение с помощта на пример

 

Кликнете тук ако видеото не е достъпно

Въпроси и Отговори

Когато обяснявам жизнен цикъл на дефекта В интервюто яснотата и структурата са важни. Започнете, като споменете, че това се отнася до пътя на дефекта от неговото откриване до отстраняването му. След това можете да го разделите на етапи:

  • Ново/Отворено – Дефектът е идентифициран и регистриран.
  • Целеви – Предоставя се на разработчика за поправка.
  • Фиксирано/Решено – Разработчикът прилага решение.
  • Повторно тестване/Проверка – Тестерите валидират поправката.
  • Затворен – Дефектът е потвърден като отстранен, или отворена отново ако продължи.

Жизненият цикъл на дефекта (наричан още жизнен цикъл на бъгове) е поредица от стъпки Дефектът се регистрира по време на тестване: идентифициран, регистриран, присвоен, отстранен, повторно тестван и затворен. Това осигурява систематично проследяване и подобрява качеството на софтуера в екипите. Този систематичен подход осигурява отчетност, прозрачност и по-качествена доставка на софтуер. Мислете за него като за светофар за дефекти – всеки знае кога да спре, да тръгне или да провери отново.

Налични са множество инструменти за управление на жизнения цикъл на дефектите, в зависимост от нуждите на проекта. Някои от популярните опции са JIRA, Bugzilla, HP ALM, Redmine и MantisBTТе позволяват на екипите да регистрират, разпределят и проследяват дефекти. JIRA е най-широко използваната методология в Agile и интервютата.

In ДЖИРА, жизненият цикъл на дефекта се управлява чрез персонализиране състояния на работния процесПо подразбиране, то отразява стандартното проследяване на дефекти, но екипите често го адаптират. Типичен цикъл на дефекти в JIRA изглежда така:

  • За да направим / Отворим – Регистриран е дефект.
  • Напред – Разработчикът започва поправките.
  • Решено / Готово – Поправката е приложена, чака се валидиране от тестер.
  • отворена отново – Ако поправката не успее, дефектът се връща в активно състояние.
  • Затворен – Проверено от тестери и маркирано като завършено.

Термините „жизнен цикъл на грешката“ и „жизнен цикъл на дефекта“ често се използват взаимозаменяемо, но някои професионалисти правят едва доловима разлика:

  • Жизнен цикъл на бъгове – Обикновено се използва в технически контекст, отнасяйки се до проблеми в кода, които причиняват неизправност.
  • Жизнен цикъл на дефекта – По-широк обхват, обхващащ отклонения от изискванията, които могат да бъдат или да не са свързани с кодирането.

На практика:

  • Буболечка = Грешка в програмирането.
  • дефект = Всяка разлика между очакваните и действителните резултати (може да е свързана с дизайна, изискванията или процеса).

Въпреки това, циклите са едни и същи – открит → поправен → повторно тестван → затворен.

Това са предимствата на жизнения цикъл на дефекта:

  • Осигурява яснота: Определя състоянието на всяка грешка за прозрачно проследяване.
  • Подобрява сътрудничеството: Разработчиците, тестерите и мениджърите остават в крак с другите.
  • Повишава ефективността: Оптимизираният работен процес намалява разхищението на усилия.
  • Помощ за приоритизиране: Помага за класиране на грешки по тежест и въздействие.
  • Подкрепя отчетността: Проследява собствеността на всеки етап.
  • Прозрения, управлявани от данни: Историята на жизнения цикъл подхранва по-доброто вземане на решения.

Oбобщение

Разбирането на жизнения цикъл на дефектите осигурява структурирано управление на грешките, по-плавно сътрудничество и по-бързо разрешаване. Следвайки всеки етап, екипите могат да подобрят качеството на софтуера, да намалят рисковете и да предоставят надеждни и лесни за ползване приложения с увереност.  

Обобщете тази публикация с: