Въведение в бъга при тестване на софтуер

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

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

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

По-долу е диаграмата на жизнения цикъл на бъгове:

Състояние на бъг

Нека видим всеки компонент от жизнения цикъл на бъговете.

1. Отворете

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

2. Ново

Това е първото състояние на класификация на бъгове в жизнения цикъл на бъговете. В по-късните етапи на жизнения цикъл на бъговете се проверяват и тестват тези грешки, ако бъде открит нов дефект.

3. Възлага се

На екипа за разработка се разпределя новосъздадена повреда за работа на грешката на това ниво. Това ще бъде делегирано на дизайнер от ръководителя на проекта или шефа на екипа.

4. Предстоящ тест

След поправяне на дефекта, дизайнерът ще даде на изпитателя вината за повторно тестване на неизправността и състоянието на престоя на дефекта в очакване на повторно тестване “, докато тестерът не работи за повторно тестване на повредата.

5. Поправен

Ако разработчикът изпълни задачата да поправи дефект, като направи необходимите промени, състоянието на дефекта може да се нарече „Поправен“.

6. Проверени

Ако тестерът няма проблем с дефекта, след като дизайнерът е назначил дефекта на изпитващото устройство и е помислил, че ако е бил поправен правилно, състоянието на дефекта се назначава „потвърдено“.

7. Отворете отново

Ако все още има някакъв проблем с недостатъка, програмистът ще бъде инструктиран да провери отново и състоянието на дефекта ще бъде отворено отново.

8. Затворен

Ако дефектът отсъства, тестерът променя състоянието на дефекта на „Затворен“.

9. Тествайте отново

След това тестерът започва задачата да повторно тества дефекта, за да провери дали дефектът е коригиран правилно от разработчика, както се изисква от изискването.

10. Дубликат

Ако разработчикът счита дефекта подобен на който и да е друг дефект или дефиницията на дефекта се смеси с всеки друг дефект, състоянието на дефекта се променя от програмиста за „дублиране“.

Параметър на грешка при тестване на софтуер

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

Ръководство за прилагане на жизнения цикъл на дефицита

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

заключение

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

Препоръчителни статии

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

  1. Тестване на жизнения цикъл на софтуера
  2. Какво е тестване на софтуер?
  3. Видове тестване на софтуер
  4. Дефектен жизнен цикъл при тестване на софтуер

Категория:

Разработване на софтуер