7 types software errors that every tester should know
Време е отново за публикация в основи на софтуерното тестване . Тази публикация е за видове софтуерни грешки, които всеки тестери трябва да знае.
как да изтрия елемент от масив java
Софтуерните грешки са много видове. Грешката е грешка, независимо от всичко. Но понякога е важно да разберем същността, нейните последици и причината да я обработим по-добре.
Това помага за по-бърза реакция и най-важното, подходяща реакция.
В тази статия ще обсъждаме често срещани видове софтуерни грешки и как да ги идентифицирате по време на тестване с някои примери и прости упражнения.
Нека започнем с дефиниране на софтуерни грешки и грешки.
Какво ще научите:
- Софтуерни грешки и грешки
- Често срещани категории софтуерни грешки:
- Упражнение:
- Заключение
- Препоръчително четене
Софтуерни грешки и грешки
Както е дефинирано в Уикипедия ' An грешка е отклонение от точността или коректността ' и ' ДА СЕ софтуерна грешка е грешка, недостатък, неизправност или грешка в компютърна програма или система, която я кара да доведе до неправилен или неочакван резултат или да се държи по непредвидени начини '.
И така, може да се направи следното:
- Грешка е отклонение на действителния резултат от очаквания резултат.
- Грешките са категория на софтуерни грешки .
- Грешки могат да бъдат въведени в резултат на непълни или неточни изисквания или поради проблеми с въвеждането на човешки данни.
Често срещани категории софтуерни грешки:
# 1) Грешки във функционалността :
Функционалността е начин, по който софтуерът е предназначен да се държи. Софтуерът има функционална грешка, ако нещо, което очаквате да направи, е трудно, неудобно, объркващо или невъзможно.
Проверете тази екранна снимка:
Очакваната функционалност за бутон Отказ е, че прозорецът „Създаване на нов проект“ трябва да се затвори и никоя от промените не трябва да бъде запазена (т.е. не трябва да се създава нов проект). Ако бутонът Отказ не може да се кликне, това е функционална грешка.
# 2) Комуникационни грешки:
Тези грешки възникват при комуникация от софтуер до краен потребител. Всичко, което крайният потребител трябва да знае, за да използва софтуерът трябва да бъде достъпен на екрана .
Малко примериот комуникационните грешки са - Не са предоставени помощни инструкции / меню, функции, които са част от изданието, но не са документирани в помощното меню, бутон с име „Запазване“ не трябва да изтрива файл и т.н.
# 3) Липсващи командни грешки:
Това се случва да възникне, когато липсва очаквана команда . Вижте тази екранна снимка:
Този прозорец позволява на потребителя да създаде нов проект. Обаче няма възможност потребителят да излезе от този прозорец, без да създаде проекта. Тъй като опцията / бутон „Отказ“ не се предоставя на потребителя, това е липсваща грешка в командата.
# 4) Синтактична грешка:
Синтактичните грешки са грешно написани думи или граматически неправилни изречения и са много очевидни при тестване на софтуерния графичен интерфейс . Моля, обърнете внимание, че НЕ се позоваваме на синтаксични грешки в кода. Компилаторът ще предупреди разработчика за всякакви синтаксисни грешки, които се появяват в кода
Обърнете внимание на грешно написаната дума „Отказ“:
Обърнете внимание на граматично неправилното съобщение:
# 5) Грешки при обработка на грешки:
Всички грешки, които възникват, докато потребителят взаимодейства със софтуера, трябва да бъдат обработвани на ясен и смислен начин . В противен случай се извиква като Error Handling Error.
Погледнете това изображение. Съобщението за грешка не дава информация за грешката всъщност. Липсва ли задължително поле, грешка при запазване, грешка при зареждане на страница или е системна грешка? Следователно, това е „Грешка при предаване на грешка“.
Когато е възможно, трябва да бъдат изброени допълнителни стъпки, които потребителят да следва.
Ако софтуерът има определени задължителни полета, които трябва да се попълнят, преди да могат да запазят информацията във формуляр, съобщенията за проверка трябва да са ясни и да показват действието, което се изисква от потребителя.
Ето и другипримери:
# 6) Грешки при изчисляване:
Тези грешки възникват поради някоя от следните причини:
- Лоша логика
- Неправилни формули
- Несъответствие на типа данни
- Грешки при кодиране
- Проблеми с повиквания на функции и т.н.
През 1999 г. НАСА загуби своя орбитален климатик на Марс, тъй като един от подизпълнителите, използвани от НАСА, използва английски единици вместо предвидената метрична система, което кара двигателите на орбита да работят неправилно. Поради тази грешка орбитата се разби почти веднага, когато пристигна на Марс.
# 7) Грешки в контролния поток :
Контролният поток на софтуера описва какво ще прави по-нататък и при какви условия.
Например, помислете за система, в която потребителят трябва да попълни формуляр, а опциите, достъпни за потребителя, са: Запазване, Запазване и затваряне и Отказ. Ако потребителят кликне върху бутона „Запазване и затваряне“, потребителската информация във формуляра трябва да бъде запазена и формулярът да се затвори. Ако щракването върху бутона не затвори формуляра, това е грешка в контролния поток.
Упражнение:
Нека да определим в кои категории грешки попадат следните:
Упражнение # 1:
софтуер, написан на c ++
Това са грешки при обработка на грешки.
Упражнение # 2:
Това е липсваща грешка в командата. Бутонът за отмяна е задължителен, но липсва. Също така и двата бутона ‘Proceed’ и ‘Delete’ са излишни и изпълняват една и съща функция.
Упражнение # 3
Това е синтактична грешка.
Следваща стъпка:
Отчитането на грешка, след като е идентифицирана, е от съществено значение. За най-добри резултати докладвайте веднага.
Включете описанието, приоритета, тежестта, задействанията и стъпките за пресъздаване на сценария, улавяне на екрана (ако има такива) в отчета за грешки.
За повече информация относно писането на ефективни отчети за дефекти, проверете тази публикация .
Заключение
Идентифицирането на дефекти, категоризирането, докладването и евентуалното отстраняване са част от дейностите по контрол на качеството.
Но профилактиката е по-добра от лечението. Същността на осигуряването на качеството на софтуера е да се установи мониторинг и инспекция на процесите на всеки етап от жизнения цикъл на разработката на софтуер.
Предложено четене = >> Как да коригирам грешка в Audio Renderer
Целта е да се открият грешки възможно най-рано. Това е така, защото разходите за намиране и отстраняване на грешки се увеличават драстично с развитието на софтуера. Следователно ранното идентифициране на грешки е от съществено значение.
Поправянето на грешка е най-евтиното по време на етапа на анализ на изискванията, постепенно се оскъпява с всеки етап и е най-скъпо във фазата на поддръжка след пускане.
Като QA инженери, ние можем или не да участваме пряко в определянето на изискванията. Също така може да имаме малък или никакъв пряк контрол върху качеството на изискванията.
Ето защо е от съществено значение да можем да идентифицираме, търсим и съобщаваме за всякакви грешки, с които се сблъскаме по време на фазата на тестване.
За автора: Тази полезна статия е написана от Неха Б. В момента тя работи като мениджър за осигуряване на качеството и е специализирана в ръководенето и управлението на вътрешни и офшорни екипи за осигуряване на качеството.
Уведомете ни за други видове софтуерни грешки, които знаете или сте срещали.
Препоръчително четене
- Видове рискове при софтуерни проекти
- Примерен доклад за грешка
- Обявявам новата си електронна книга „Кариерен пакет за тестване на софтуер - пътуване на тестера на софтуера от намирането на работа до ставането на лидер на теста!“
- Наистина ли работата на тестера на софтуер е нископрофилна работа?
- Идеално ръководство за възобновяване на тестване на софтуер (с проба за възобновяване на тестера на софтуер)
- 5 начина да бъдете смел и уверен софтуерен тестер
- 5 неща, които начинаещият разработчик (и тестер) трябва да знае за тестването на софтуер
- Характеристики на лош софтуерен тестер