Содержание
Дефекты, ошибки, сбои, отказы в тестирование ИС
Дефекты. Ошибки, сбои, отказы
Дефект — расхождение ожидаемого и фактического результата. Или дефект — отклонение фактического результата от ожиданий наблюдателя, сформированных на основе требований, спецификаций, иной документации или опыта и здравого смысла.
Ожидаемый результат — поведение системы, описанное в требованиях.
Фактический результат — поведение системы, наблюдаемое в процессе тестирования.
Ошибки совершает человек , которые приводят к возникновению дефектов в коде, которые, в свою очередь, приводят к сбоям и отказам приложения (однако сбои и отказы могут возникать и из-за внешних условий, таких как электромагнитное воздействие на оборудование и т.д.). Таким образом, упрощённо можно изобразить следующую схему
Ошибка (error , mistake) — действие человека, приводящее к некорректным результатам.
Дефект (defect, bug, problem, fault) — недостаток в компоненте или системе, способный привести к ситуации сбоя или отказа.
Дефекты могут быть в документации, настройках, входных данных и т.д.
Сбой или отказ — отклонение поведения системы от ожидаемого.
В ГОСТ 27.002-89 даны краткие определения сбоя и отказа :
Сбой — самоустраняющийся отказ или однократный отказ, устраняемый незначительным вмешательством оператора.
Отказ — событие, заключающееся в нарушении работоспособного состояния объекта.
Сбои и отказы являются тем, что тестировщик замечает в процессе тестирования и отталкиваясь от чего, проводит исследование с целью выявить дефект и его причины.
Отчёт о дефекте и его жизненный цикл
При обнаружении дефекта тестировщик создаёт отчёт о дефекте .
Отчёт о дефекте — документ, описывающий обнаруженный дефект, а также содействующий его устранению
Отчёт о дефекте пишется со следующими основными целями:
- предоставить информацию о проблеме — уведомить проектную команду и иных заинтересованных лиц о наличии проблемы, описать суть проблемы; приоритизировать проблему — определить степень опасности проблемы для проекта и желаемые сроки её устранения;
- содействовать устранению проблемы — качественный отчёт о дефекте не только предоставляет все необходимые подробности для понимания сути случившегося, но также может содержать анализ причин возникновения проблемы и рекомендации по исправлению ситуации.
Хорошо написанный отчёт о дефекте — половина решения проблемы для программиста. От полноты, корректности, аккуратности, подробности и логичности отчёта о дефекте зависит очень многое — одна и та же проблема может быть описана так, что программисту останется исправить пару строк кода, а может быть описана и так, что сам автор отчёта на следующий день не сможет понять, что же он имел в виду.
Отчёт о дефекте (и сам дефект вместе с ним) проходит определённые стадии жизненного цикла, которые схематично можно показать так (рисунок 2на следующем слайде):
- Обнаружен (submitted) — начальное состояние отчёта (иногда называется «Новый» (new)), в котором он находится сразу после создания. Некоторые средства также позволяют сначала создавать черновик (draft) и лишь потом публиковать отчёт.
- Назначен (assigned) — в это состояние отчёт переходит с момента, когда кто — то из проектной команды назначается ответственным за исправление дефекта. Назначение ответственного производится или решением лидера команды разработки, или коллегиально, или по добровольному принципу, или иным принятым в команде способом или выполняется автоматически на основе определённых правил.
- Исправлен (fixed) — в это состояние отчёт переводит ответственный за исправление дефекта член команды после выполнения соответствующих действий по исправлению.
- Проверен (verified) — в это состояние отчёт переводит тестировщик, удостоверившийся, что дефект на самом деле был устранён. Как правило, такую проверку выполняет тестировщик, изначально написавший отчёт о дефекте.
Назначение ответственного производится или решением лидера команды разработки, или коллегиально, или по добровольному принципу, или иным принятым в команде способом или выполняется автоматически на основе определённых правил.Свежий взгляд человека, ранее не знакомого с данным дефектом, позволяет ему в процессе верификации с большой вероятностью обнаружить новые дефекты.
Жизненный цикл отчёта о дефекте с наиболее типичными переходами между состояниями
Набор стадий жизненного цикла, их наименование и принцип перехода от стадии к стадии может различаться в разных инструментальных средствах управления жизненным циклом отчётов о дефектах.
Более того — многие такие средства позволяют гибко настраивать эти параметры.
- Закрыт (closed) — состояние отчёта, означающее, что по данному дефекту не планируется никаких дальнейших действий.
Здесь есть некоторые расхождения в жизненном цикле, принятом в разных инструментальных средствах управления отчётами о дефектах:
В некоторых средствах существуют оба состояния — « Проверен » и « Закрыт », чтобы подчеркнуть, что в состоянии « Проверен » ещё могут потребоваться какие-то дополнительные действия (обсуждения, дополнительные проверки) в то время как состояние « Закрыт » означает «с дефектом покончено, больше к этому вопросу не возвращаемся».
- В некоторых средствах одного из состояний нет (оно поглощается другим)
В некоторых средствах в состояние «Закрыт» или «Отклонён» отчёт о дефекте может быть переведён из множества предшествующих состояний с резолюциями наподобие:
- «Не является дефектом» — приложение так и должно работать, описанное поведение не является аномальным.
- «Дубликат» — данный дефект уже описан в другом отчёте.
- «Не удалось воспроизвести» — разработчикам не удалось воспроизвести проблему на своём оборудовании.
- «Не будет исправлено» — дефект есть, но по каким-то серьёзным причинам его решено не исправлять.
- «Невозможно исправить» — непреодолимая причина дефекта находится вне области полномочий команды разработчиков, например существует проблема в операционной системе или аппаратном обеспечении, влияние которой устранить разумными способами невозможно. В подобных случаях будет переведён в состояние «Закрыт», в некоторых — в состояние «Отклонён», в некоторых — часть случаев закреплена за состоянием «Закрыт», часть — за «Отклонён».
- Открыт заново (reopened) — в это состояние (как правило, из состояния «Исправлен») отчёт переводит тестировщик, удостоверившийся, что дефект попрежнему воспроизводится на билде, в котором он уже должен быть исправлен.
- Рекомендован к отклонению (to be declined) — в это состояние отчёт о дефекте может быть переведён из множества других состояний с целью вынести на рассмотрение вопрос об отклонении отчёта по той или иной причине. Если рекомендация является обоснованной, отчёт переводится в состояние «Отклонён» (см. следующий пункт).
- Отклонён (declined) — в это состояние отчёт переводится в случаях, подробно описанных в пункте «Закрыт», если средство управления отчётами о дефектах предполагает использование этого состояния вместо состояния «Закрыт» для тех или иных резолюций по отчёту.
- Отложен (deferred) — в это состояние отчёт переводится в случае, если исправление дефекта в ближайшее время является нерациональным или не представляется возможным, однако есть основания полагать, что скоро ситуация исправится (выйдет новая версия библиотеки, вернётся из отпуска специалист по данной технологии, изменятся требования заказчика и т.д.).
Если рекомендация является обоснованной, отчёт переводится в состояние «Отклонён» (см. следующий пункт).Атрибуты (поля) отчёта о дефекте
Общий вид всей структуры отчёта о дефекте представлен на рисунке
- Идентификатор представляет собой уникальное значение, позволяющее однозначно отличить один отчёт о дефекте от другого и используемое во всевозможных ссылках. В общем случае идентификатор отчёта о дефекте может представлять собой просто уникальный номер, но может быть : включать префиксы, суффиксы и иные осмысленные компоненты, позволяющие быстро определить суть дефекта и часть приложения (или требований), к которой он относится.
- Краткое описание должно в предельно лаконичной форме давать исчерпывающий ответ на вопросы «Что произошло?» «Где это произошло»? «При каких условиях это произошло?».
В общем случае идентификатор отчёта о дефекте может представлять собой просто уникальный номер, но может быть : включать префиксы, суффиксы и иные осмысленные компоненты, позволяющие быстро определить суть дефекта и часть приложения (или требований), к которой он относится.Например: «Отсутствует логотип на странице приветствия, если пользователь
является администратором»:
— Что произошло? Отсутствует логотип.
— Где это произошло? На странице приветствия.
— При каких условиях это произошло? Если пользователь является
администратором.
Заполнение поля « краткое описание », которое одновременно должно:
— содержать предельно краткую, но в то же время достаточную для
понимания сути проблемы информацию о дефекте;
— быть достаточно коротким, чтобы полностью помещаться на экране;
— при необходимости содержать информацию об окружении, под
которым был обнаружен дефект;
— по возможности не дублировать краткие описания других
дефектов (и даже не быть похожими на них), чтобы дефекты
было сложно перепутать или посчитать дубликатами друг друга;
— быть законченным предложением русского или английского (или
иного) языка, построенным по соответствующим правилам
грамматики.
Для создания хороших кратких описаний дефектов рекомендуется пользоваться следующим алгоритмом:
- Полноценно понять суть проблемы. До тех пор, пока у тестировщика нет чёткого понимания того, «что не работает», писать отчёт о дефекте не стоит.
- Сформулировать подробное описание
- 3. Убрать из получившегося подробного описания всё лишнее, уточнить важные детали.
4. Выделить в подробном описании слова (словосочетания, фрагменты фраз), отвечающие на вопросы, «что, где и при каких условиях случилось».
5. Оформить получившееся в пункте 4 в виде законченного грамматически правильного предложения.
6. Если предложение получилось слишком длинным, переформулировать
его, сократив длину (за счёт подбора синонимов, использования
общепринятых аббревиатур и сокращений). К слову, в английском языке
предложение почти всегда будет короче русского аналога.
Пример применения этого алгоритма.
Тестированию подвергается некое веб-приложение, поле описания товара должно допускать ввод максимум 250 символов; в процессе тестирования оказалось, что этого ограничения нет.
- Суть проблемы: исследование показало, что ни на клиентской, ни на серверной части нет никаких механизмов, проверяющих и/или ограничивающих длину введённых в поле «О товаре» данных.
- Исходный вариант подробного описания: в клиентской и серверной части приложения отсутствуют проверка и ограничение длины данных, вводимых в поле «О товаре» на странице http://testapplication/admin/goods/edit.
- Конечный вариант подробного описания:
— Фактический результат: в описании товара (поле «О товаре»,
http://testapplication/admin/goods/edit/) отсутствуют проверка и
ограничение длины вводимого текста (MAX=250 символов).
— Ожидаемый результат: в случае попытки ввода 251+ символов
выводится сообщение об ошибке.
- Определение «что, где и при каких условиях случилось»:
— Что: отсутствуют проверка и ограничение длины вводимого текста.
— Где: описание товара, поле «О товаре»,
http://testapplication/admin/goods/edit/.
— При каких условиях: – (в данном случае дефект присутствует всегда, вне
зависимости от каких бы то ни было особых условий).
- Первичная формулировка: отсутствуют проверка и ограничение максимальной длины текста, вводимого в поле «О товаре» описания товара.
- Сокращение (итоговое краткое описание): нет ограничения максимальной длины поля «О товаре». Английский вариант: no check for «О товаре» max length.
- Подробное описание представляет в развёрнутом виде необходимую информацию о дефекте, а также (обязательно!) описание фактического результата, ожидаемого результата и ссылку на требование (если это возможно).
Пример подробного описания :
Если в систему входит администратор, на странице приветствия отсутствует логотип. Фактический результат: логотип отсутствует в левом верхнем углу страницы.
Ожидаемый результат: логотип отображается в левом верхнем углу страницы. Требование: R245.3.23b.
В отличие от краткого описания, которое является одним предложением, здесь нужно давать подробную информацию. Если одна и та же проблема (вызванная одним источником) проявляется в нескольких местах приложения, можно в подробном описании перечислить эти места.
- Шаги по воспроизведению описывают действия, которые необходимо выполнить для воспроизведения дефекта.
Это поле похоже на шаги тест-кейса, за исключением одного отличия: здесь действия прописываются максимально подробно, с указанием конкретных вводимых значений и самых мелких деталей, т.к. отсутствие этой информации в сложных случаях может привести к невозможности воспроизведения дефекта.
Пример шагов воспроизведения :
- Открыть http://testapplication/admin/login/.
- Авторизоваться с именем «defaultadmin» и паролем «dapassword». Дефект : в левом верхнем углу страницы отсутствует логотип (вместо него отображается пустое пространство с надписью «logo»).
Воспроизводимость показывает, при каждом ли прохождении по шагам воспроизведения дефекта удаётся вызвать его проявление. Это поле принимает всего два значения: всегда или иногда. Можно сказать, что воспроизводимость «иногда» означает, что тестировщик не нашёл настоящую причину возникновения дефекта. Это приводит к серьёзным дополнительным сложностям в работе с дефектом:
- Тестировщику нужно потратить много времени на то, чтобы удостовериться в наличии дефекта (т.к. однократный сбой в работе приложения мог быть вызван большим количеством посторонних причин).
- Разработчику тоже нужно потратить время, чтобы добиться проявления дефекта и убедиться в его наличии. После внесения исправлений в приложение разработчик фактически должен полагаться только на свой профессионализм, т.к. даже многократное прохождение по шагам воспроизведения в таком случае не гарантирует, что дефект был исправлен (возможно, через ещё 10–20 повторений он бы проявился).
- Важность показывает степень ущерба, который наносится проекту существованием дефекта. В общем случае выделяют следующие виды важности:
— Критическая — существование дефекта приводит к масштабным последствиям катастрофического характера, например: потеря данных, раскрытие конфиденциальной информации, нарушение ключевой функциональности приложения и т.д.
— Высокая — существование дефекта приносит ощутимые неудобства многим пользователям в рамках их типичной деятельности, например: недоступность вставки из буфера обмена, неработоспособность общепринятых клавиатурных комбинаций, необходимость перезапуска приложения при выполнении типичных сценариев работы.
— Средняя — существование дефекта слабо влияет на типичные
сценарии работы пользователей, и/или существует обходной путь
достижения цели, например: диалоговое окно не закрывается
автоматически после нажатия кнопок «OK»/«Cancel», при распечатке
нескольких документов подряд не сохраняется значение поля
«Двусторонняя печать», перепутаны направления сортировок по
некоему полю таблицы.
— Низкая — существование дефекта редко обнаруживается
незначительным процентом пользователей и (почти) не влияет на их
работу, например: опечатка в глубоко вложенном пункте меню
настроек, некоторое окно при отображении расположено неудобно
(нужно перетянуть его в удобное место), неточно отображается время
до завершения операции копирования файлов.
- Срочность показывает, как быстро дефект должен быть устранён. В общем случае выделяют следующие виды срочности:
- Наивысшая срочность указывает на необходимость устранить дефект настолько быстро, насколько это возможно.
- Высокая срочность означает, что дефект следует исправить вне очереди, т.к. его существование или уже объективно мешает работе, или начнёт создавать такие помехи в самом ближайшем будущем.
- Обычная срочность означает, что дефект следует исправить в порядке общей очерёдности. Такое значение срочности получает большинство дефектов.
- Низкая срочность означает, что в обозримом будущем исправление данного дефекта не окажет существенного влияния на повышение качества продукта.
- С имптом — позволяет классифицировать дефекты по их типичному проявлению. Не существует никакого общепринятого списка симптомов.
В качестве примера рассмотрим следующие значения симптомов дефекта.
- Косметический дефект — визуально заметный недостаток интерфейса, не влияющий на функциональность приложения (например, надпись на кнопке выполнена шрифтом не той гарнитуры).
- Повреждение/потеря данных — в результате возникновения дефекта искажаются, уничтожаются (или не сохраняются) некоторые данные (например, при копировании файлов копии оказываются повреждёнными).
- Проблема в документации (— дефект относится не к приложению, а к документации (например, отсутствует раздел руководства по эксплуатации).
- Некорректная операция — некоторая операция выполняется некорректно
- Проблема инсталляции — дефект проявляется на стадии установки и/или конфигурирования приложения.
- Ошибка локализации — что-то в приложении не переведено или переведено неверно на выбранный язык интерфейса.
- Нереализованная функциональность — некая функция приложения не выполняется или не может быть вызвана (например, в списке форматов для экспорта документа отсутствует несколько пунктов, которые там должны быть
- Проблема масштабируемости — при увеличении количества доступных приложению ресурсов не происходит ожидаемого прироста производительности приложения
- Низкая производительность — выполнение неких операций занимает недопустимо большое время
- Крах системы — приложение прекращает работу или теряет способность выполнять свои ключевые функции
- Неожиданное поведение — в процессе выполнения некоторой типичной операции приложение ведёт себя необычным (отличным от общепринятого) образом (например, после добавления в список новой записи активной становится не новая запись, а первая в списке).
- Недружественное поведение — поведение приложения создаёт пользователю неудобства в работе (например, на разных диалоговых окнах в разном порядке расположены кнопки «OK» и «Cancel»).
- Расхождение с требованиями — этот симптом указывают, если дефект сложно соотнести с другими симптомами, но тем не менее приложение ведёт себя не так, как описано в требованиях.
- Предложение по улучшению — во многих инструментальных средствах управления отчётами о дефектах для этого случая есть отдельный вид отчёта
Часто у одного дефекта может быть сразу несколько симптомов.
- Возможность обойти — показывает, существует ли альтернативная последовательность действий, выполнение которой позволило бы пользователю достичь поставленной цели (например, клавиатурная комбинация Ctrl+P не работает, но распечатать документ можно, выбрав соответствующие пункты в меню). В некоторых инструментальных средствах управления отчётами о дефектах это поле может просто принимать значения «Да» и «Нет», в некоторых при выборе «Да» появляется возможность описать обходной путь. Традиционно считается, что дефектам без возможности обхода стоит повысить срочность исправления.
- Комментарий— может содержать любые полезные для понимания и исправления дефекта данные.
- Вложения — представляет собой не столько поле, сколько список прикреплённых к отчёту о дефекте приложений (копий экрана, вызывающих сбой файлов и т.д.).
Откуда берутся ошибки в ПО?
Почему бывает так, что программы работают неправильно? Все очень просто – они создаются и используются людьми. Если пользователь допустит ошибку, это может привести к проблеме в работе программы – она используется неправильно, а значит, может повести себя не так, как ожидалось.
Ошибка (error) – это действие человека, которое порождает неправильный результат.
Однако программы разрабатываются и создаются людьми, которые также могут допускать (и допускают) ошибки. Это значит, что недостатки есть и в самом программном обеспечении. Они называются дефектами или багами (оба обозначения равносильны). Здесь важно помнить, что программное обеспечение – нечто большее, чем просто код.
Дефект, Баг (Defect, Bug) – недостаток компонента или системы, который может привести к отказу определенной функциональности. Дефект, обнаруженный во время исполнения программы, может вызвать отказ отдельного компонента или всей системы.
При исполнении кода программы дефекты, заложенные еще во время его написания, могут проявиться: программа может не делать того, что должна или наоборот – делать то, чего не должна, – происходит сбой.
Сбой (failure) – несоответствие фактического результата (actualresult) работы компонента или системы ожидаемому результату (expectedresult).
Сбой в работе программы может являться индикатором наличия в ней дефекта.
Таким образом, баг существует при одновременном выполнении трех условий:
- известен ожидаемый результат;
- известен фактический результат;
- фактический результат отличается от ожидаемого результата.
Важно понимать, что не все баги становятся причиной сбоев – некоторые из них могут никак себя не проявлять и оставаться незамеченными (или проявляться только при очень специфических обстоятельствах).
Причиной сбоев могут быть не только дефекты, но также и условия окружающей среды: например, радиация, электромагнитные поля или загрязнение также могут влиять на работу как программного, так и аппаратного обеспечения.
Всего существует несколько источников дефектов и, соответственно, сбоев:
- ошибки в спецификации, дизайне или реализации программной системы;
- ошибки использования системы;
- неблагоприятные условия окружающей среды;
- умышленное причинение вреда;
- потенциальные последствия предыдущих ошибок, условий или умышленных действий.
Дефекты могут возникать на разных уровнях, и от того, будут ли они исправлены и когда, будет напрямую зависеть качество системы.
Качество (Quality) – степень, в которой совокупность присущих характеристик соответствует требованиям.
Качество программного обеспечения (Software Quality) – это совокупность характеристик программного обеспечения, отражающих его способность удовлетворять установленные и предполагаемые потребности.
Требование (Requirement) – потребность или ожидание, которое установлено. Обычно предполагается или является обязательным.
В первом случае все было сделано правильно и мы получили продукт, полностью соответствующий ожиданиям заказчика и удовлетворяющий критериям качества.
Во втором случае ошибки были допущены уже при кодировании, что привело к появлению дефектов в готовом продукте. Но на этом уровне баги достаточно легко обнаружить и исправить, поскольку мы видим несоответствие требованиям.
Третий вариант хуже – здесь ошибки были допущены на этапе проектирования системы. Заметить это можно лишь проведя тщательную сверку со спецификацией. Исправить такие дефекты тоже непросто – нужно заново перерабатывать дизайн продукта.
В четвертом случае дефекты были заложены еще на этапе формирования требований; вся дальнейшая разработка и даже тестирование пошли по изначально неправильному пути. Во время тестирования мы не найдем багов – программа пройдет все тесты, но может быть забракована заказчиком.
Условно, можно выделить пять причин появления дефектов в программном коде.
- Недостаток или отсутствие общения в команде. Зачастую, бизнес требования просто не доходят до команды разработки. У заказчика есть понимание того, каким он хочет видеть готовый продукт, но если должным образом не объяснить его идею разработчикам и тестировщикам, результат может оказаться не таким, как предполагалось. Требования должны быть доступны и понятны всем участникам процесса разработки ПО.
- Сложность программного обеспечения. Современное ПО состоит из множества компонентов, которые объединяются в сложные программные системы. Многопоточные приложения, клиент-серверная и распределенная архитектура, многоуровневые базы данных – программы становятся все сложнее в написании и поддержке, и тем труднее становится работа программистов. А чем труднее работа, тем больше ошибок может допустить исполняющий ее человек.
- Изменения требований. Даже незначительные изменения требований на поздних этапах разработки требуют большого объема работ по внесению изменений в систему. Меняется дизайн и архитектура приложения, что, в свою очередь, требует внесения изменений в исходный код и принципы взаимодействия программных модулей. Такие текущие изменения зачастую становятся источником трудноуловимых дефектов. Тем не менее, часто меняющиеся требования в современном бизнесе – скорее правило, чем исключение, поэтому непрерывное тестирование и контроль рисков в таких условиях – прямая обязанность специалистов отдела обеспечения качества.
- Плохо документированный код. Сложно поддерживать и изменять плохо написанный и слабо документированный программный код. Во многих компаниях существуют специальные правила по написанию и документированию кода программистами. Хотя на практике часто бывает так, что разработчики вынуждены писать программы в первую очередь быстро и это сказывается на качестве продукта.
- Средства разработки ПО. Средства визуализации, библиотеки, компиляторы, генераторы скриптов и другие вспомогательные инструменты разработки – это тоже зачастую плохо работающие и слабо документированные программы, которые могут стать источником дефектов в готовом продукте.
В чем разница между ошибкой, дефектом и отказом?
Мы используем это программное обеспечение в повседневной жизни, например, дома, на работе, в банке, в магазинах и т. д. Однако иногда программное обеспечение не работает должным образом. Например, неправильная загрузка веб-сайта, ошибка в счете, задержка в обработке кредитной карты — типичные примеры проблем, которые могут возникнуть из-за ошибок, дефектов и сбоев в программном обеспечении. Сегодня мы обсудим общие термины, которые мы используем, когда программное обеспечение не работает должным образом, т. е. Ошибка, дефект и сбой .
- Что такое ошибка, дефект и сбой?
- Каковы причины ошибок в программном обеспечении?
- Не все непредвиденные результаты испытаний являются неудачными
- Что такое дефекты, основные причины и их последствия?
Попробуем понять взаимосвязь между Ошибка, Дефект и Ошибка :
Хорошо сказано у Томаса Мюллера « Человек может совершить ошибку (ошибку), которая порождает дефект (ошибку, баг) в коде, в программном обеспечении или системе, или документе. Если произойдет выполнение дефекта в коде, система не сможет сделать то, что должна (или что-то не должна), что вызовет сбой ».
Возьмем в качестве примера организацию, которая разработала новое приложение под названием « Saff Promotion System » для ежегодной оценки. Но удовлетворенность сотрудников даже после оценки была низкой. Потому что посчитали это не на должном уровне. Тогда руководство решило проанализировать первопричину этого недовольства.
Поэтому они отследили процесс и обнаружили, что программное обеспечение помечало полный рабочий день для сотрудников, прибывающих в офис после 10 часов утра. Это было связано с некоторыми ошибками кодирования. Тестер также пропустил эти ошибки в кодировании. Итак, ПО с этим дефектом пошло в производство. Что, в свою очередь, вызвало общую деградацию и отказ системы.
На рисунке ниже показана взаимосвязь между ошибкой, дефектом и сбоем.
Ошибки:
Ошибка является человеческой ошибкой. Ошибка появляется не только из-за логической ошибки в коде, допущенной разработчиком. Любой член команды может ошибаться на разных этапах разработки программного обеспечения. Например,
- BA (бизнес-аналитик) может неверно истолковать или неправильно понять требования.
- Клиент может предоставить недостаточную или неправильную информацию.
- Архитектор может вызвать ошибку в разработке программного обеспечения.
- Люди в команде также могут ошибаться из-за неясных или недостаточных требований, нехватки времени, апатии или по другим причинам.
Рассмотрим основные типы ошибок при тестировании ПО:
Типы ошибок
- Ошибка пользовательского интерфейса : это ошибки, которые обычно появляются во время взаимодействия пользователя с системой. Например, отсутствие или неправильная функциональность системы, отсутствие функции резервного копирования или реверса и т. д.
- Ошибка обработки ошибок : любая ошибка, возникающая при взаимодействии пользователя с программным обеспечением, требует точной и осмысленной обработки. Если нет, это сбивает с толку. Поэтому такие ошибки известны как ошибки обработки ошибок .
- Синтаксическая ошибка : Ошибки в словах или грамматически неправильные предложения являются синтаксическими ошибками и очень очевидны при тестировании графического интерфейса программного обеспечения.
- Ошибки расчета : Эти ошибки возникают из-за неправильной логики, неправильных формул, несоответствия типов данных и т. д.
- Ошибка управления потоком : Ошибки, связанные с передачей управления программой в неправильном направлении, когда программа ведет себя неожиданно, являются ошибками управления потоком. Например, наличие бесконечного цикла, сообщение об ошибке синтаксиса во время выполнения и т. д. .
- Ошибки тестирования : Подразумеваются ошибки, возникшие при внедрении и выполнении процесса тестирования. Например, сбой сканирования ошибок, неэффективность сообщения об ошибке или дефекте .
- Ошибки оборудования : Такие ошибки связаны с аппаратным обеспечением устройства. Типа нет доступности и нет совместимости с устройством .
Дефект:
A Дефект — разница между ожидаемыми и фактическими результатами. Ошибка, которую обнаруживает тестер, называется дефектом. Дефект в программном продукте отражает его неспособность или неэффективность соответствовать заданным требованиям и критериям и, как следствие, препятствовать выполнению программным приложением желаемой и ожидаемой работы. Дефект также известен как Ошибка .
Типы дефектов:
Серьезность Основание:
Серьезность определяет степень воздействия. Следовательно, серьезность дефекта отражает степень или интенсивность конкретного дефекта, отрицательно влияющего на программный продукт или его работу. В зависимости от показателя серьезности дефект попадает в следующие категории:
- Критический : Дефекты « критический «требует немедленного внимания и лечения. Критический дефект напрямую влияет на основные функции, которые в противном случае могут повлиять на программный продукт или его крупномасштабную функциональность. Например, сбой функции/функции или сбой всей системы и т. д.
- Значительный : Дефекты, влияющие на основные функции программного продукта, являются серьезными дефектами. Хотя эти дефекты не приводят к полному отказу системы, но могут нарушить работу нескольких основных функций программного обеспечения.
- Незначительный : Эти дефекты оказывают меньшее влияние и не оказывают существенного влияния на программный продукт. Результаты этих дефектов видны в работе продукта. Однако это не мешает пользователям выполнять задачу. Задание можно выполнить, используя какой-либо другой вариант.
- Trivial : Эти типы дефектов не влияют на работу продукта. Поэтому иногда мы игнорируем и опускаем их. Например, орфографические или грамматические ошибки.
Основание вероятности:
Еще один аспект обнаружения дефекта в программном приложении — это вероятность его возникновения и вероятность того, что пользователь его обнаружит. В зависимости от вероятности или возможности возникновения дефекта в программном продукте в процентном соотношении классифицируется следующим образом:
- Высокий : Практически все пользователи приложения могут отслеживать наличие дефектов. Это указывает на высокую вероятность.
- Средний : Половина пользователей могут отследить наличие дефектов в программном продукте.
- Низкий : Как правило, ни один пользователь не обнаруживает его, или только несколько пользователей смогут его обнаружить.
Основа приоритета:
У дефектов также есть сравнение с точки зрения бизнеса. Сначала должно произойти исправление некоторых дефектов. Точно так же некоторые из них можно решить на более позднем этапе. Так же, как бизнес, где все происходит в соответствии с текущими потребностями и спросом на рынке. Так же, как и база вероятностей, классификация по приоритету также происходит следующими способами:
- Высокий : Высокий приоритет определяет наиболее важную потребность компании в исправлении дефекта. Это должно произойти как можно скорее, в той же компиляции .
- Средний : Дефекты со средним приоритетом следуют за дефектами с высоким приоритетом. И любая следующая версия или выпуск продукта включает их адресацию .
- Низкий : Этот тип дефекта не требует индивидуального исправления. Рассмотрение вопроса об устранении этих типов дефектов, наряду с любыми другими дефектами, является добровольным .
Ошибка:
Отказ является следствием Дефекта. Это наблюдаемое некорректное поведение системы. Сбой возникает, когда программное обеспечение не работает в реальной среде.
Другими словами, после создания и выполнения программного кода, если система не работает должным образом из-за возникновения какого-либо дефекта; тогда это называется Неудачей. Не все дефекты приводят к сбоям; некоторые остаются неактивными в коде, и мы можем их никогда не заметить. Сбои случаются и по следующим причинам:
- Любое физическое повреждение или перегрев оборудования может привести к отказу всей системы.
- Если программное обеспечение несовместимо с аппаратным обеспечением, система также может работать некорректно.
- Отказы также происходят из-за условий окружающей среды, таких как выброс радиации, сильное магнитное поле, электронные поля или загрязнение, которые могут вызвать сбои в аппаратном или программном обеспечении.
Не все неожиданные результаты испытаний являются неудачными:
Сбои также могут
- Происходит из-за человеческой ошибки при взаимодействии с программным обеспечением, например, при вводе неверного входного значения или неправильной интерпретации выходных данных.
- Происходит, когда кто-то преднамеренно пытается вызвать сбой системы или причинить злонамеренный ущерб.
- Происходит из-за неправильного обращения с тестовыми данными, тестовой средой и т. д. Такие состояния известны как дефекты, но на самом деле они не являются Дефектом.
- Иногда тесты, которые приводят к необнаруженным дефектам, также могут привести к сбою.
Каковы причины ошибок в программном обеспечении?
Здесь мы обсудим некоторые возможные причины этих ошибок.
- Нехватка времени : Иногда разработка программного обеспечения происходит в условиях ограниченных/недостаточных ресурсов с нереалистичными сроками. Разработчики не имеют достаточно времени для тестирования своего кода, прежде чем передать его команде тестирования. Что, в свою очередь, вносит ошибки.
- Человеческая склонность к ошибкам : Люди склонны совершать ошибки. Было бы глупо ожидать, что программное обеспечение будет совершенным и без каких-либо изъянов! По иронии судьбы, мы еще не обнаружили никакого другого нечеловеческого агента, который мог бы разрабатывать программное обеспечение лучше, чем люди. Поэтому мы продолжаем полагаться на человеческий интеллект при разработке программного обеспечения. Тем самым увеличивая вероятность ошибок в нем.
- Неопытные или недостаточно квалифицированные участники проекта : Правильное распределение работы по правильному ресурсу имеет основополагающее значение для успеха любого проекта. Члены команды должны быть поставлены задачи в соответствии с их навыками и способностями. Неопытный участник проекта может ошибиться, если не будет иметь надлежащих знаний о работе. Например, ресурс, хорошо разбирающийся в базе данных, но имеющий ограниченные знания HTML/CSS, не подходит для разработки веб-сайта .
- Недопонимание между участниками проекта : Неправильная координация и плохая коммуникация между различными отделами проекта могут привести к нарушению хода выполнения. Конфликты могут возникать каждый раз, когда участник проекта неверно истолковывает или неправильно понимает слова или действия другого. Например, бизнес-аналитик занимается сбором требований, а затем другой член команды документирует требования. Любое недопонимание между ними может привести к неполному/неправильному документу требований, что, в свою очередь, повлияет на структуру проекта .
- Сложность кода, дизайна, архитектуры или технологии, которая будет использоваться. : По мере увеличения сложности программы в отношении кода, дизайна или технологии программное обеспечение становится более важным и появляется больше ошибок. Это потому, что наш мозг может иметь дело только с разумной степенью сложности или изменения. Наш разум может быть не в состоянии обрабатывать сложную информацию, такую как форма дизайна, архитектура или технология и т. д. Таким образом, это приводит к низкому качеству и ошибочному кодированию .
- Неправильное понимание внутрисистемных и межсистемных интерфейсов : Высока вероятность ошибки при установлении внутрисистемных и межсистемных интерфейсов. Попробуем разобраться что такое внутрисистемный и межсистемный интерфейсы: —
- Внутрисистемный интерфейс . Подразумевает интеграцию различных модулей/функций в систему/приложение. Например, на портале онлайн-покупок у нас есть три модуля: онлайн-заказ, доставка и цепочка поставок . Эти три модуля образуют внутреннюю систему портала онлайн-покупок. Когда эти разные модули объединяются, в конечном продукте возможны ошибки.
- Межсистемный интерфейс — это совместимость приложения с другими приложениями при совместной работе. Например, совместимость смартфонов и планшетов при передаче данных по Bluetooth.
- Внутрисистемный интерфейс . Подразумевает интеграцию различных модулей/функций в систему/приложение.
- Новые, незнакомые технологии : Иногда разработчикам и тестировщикам необходимо разработать приложение, используя неизвестный им метод. Отсутствие надлежащих знаний и понимания может привести к ошибкам. В то время им требуется определенный уровень исследований и разработок, мозгового штурма и обучения, чтобы найти надежное решение .
- Условия окружающей среды : Стихийные бедствия, такие как пожары, наводнения, молнии, землетрясения и т. д., могут повлиять на работу компьютеров. Например, система может работать неправильно, если на программное обеспечение внутри воздействует радиация, электромагнитное излучение или загрязнение.
Прочитав эту статью, я уверен, вы согласитесь со мной, что различные проблемы и несоответствия, возникающие в процессе работы над программным обеспечением, взаимозависимы и взаимосвязаны. Как правило, появление одного приводит к появлению другого. Что, в свою очередь, влияет на функциональность программного обеспечения и, таким образом, приводит к неожиданным результатам.
Разница между ошибкой, дефектом, ошибкой, отказом и отказом
следующий → В этом разделе мы собираемся обсудить разницу между ошибкой, дефектом, ошибкой, сбоем и сбоем , поскольку мы поняли, что все термины используются всякий раз, когда система или приложение действуют ненормально. Иногда мы называем это ошибкой , а иногда ошибкой или дефектом и так далее. Как правило, мы использовали эти термины в жизненном цикле разработки программного обеспечения (SDLC) на основе фаз. Но есть конфликт в использовании этих терминов. Другими словами, можно сказать, что в эпоху тестирования программного обеспечения термины баги, дефекты, ошибки, сбои и сбои встречаются каждую секунду в день. Но для новичка или неопытного в этой области все эти термины могут показаться синонимами. Стало важно понимать каждый из этих терминов независимо, если программное обеспечение не работает должным образом. Что такое ошибка? В тестировании программного обеспечения ошибка — это неофициальное название дефекта, означающее, что программное обеспечение или приложение не работает в соответствии с требованиями. Когда у нас есть какая-то ошибка кодирования, это приводит к сбою программы, который известен как ошибка . Если QA (аналитик качества) обнаружит ошибку, он может воспроизвести ошибку и записать ее с помощью шаблона отчета об ошибке . Что такое дефект?Когда приложение не работает в соответствии с требованиями, это называется дефектом . Он определяется как отклонение от фактического и ожидаемого результата приложения или программного обеспечения. Другими словами, мы можем сказать, что ошибка, объявленная программистом и внутри кода, называется Дефект . Что такое ошибка? Проблема в коде приводит к ошибкам, что означает, что ошибка может возникнуть из-за ошибки кодирования разработчика, так как разработчик неправильно понял требование или требование было определено неправильно. Разработчики используют термин ошибка . Что такое неисправность?Ошибка может возникнуть в программном обеспечении, поскольку оно не добавило код для обеспечения отказоустойчивости, из-за чего приложение начинает барахлить. В программе может произойти сбой по следующим причинам:
Что такое неудача?Многие дефекты приводят к сбою программного обеспечения . Другими словами, мы можем сказать, что если конечный пользователь обнаруживает проблему в продукте, то эта конкретная проблема называется ошибка . Возможны один дефект, который может привести к одному или нескольким сбоям. Например, , в банковском приложении, если модуль Перечисление суммы не работает для конечных пользователей, когда конечный пользователь пытается перевести деньги , кнопка отправки не работает. Поток вышеуказанных терминов показан на следующем изображении: Ошибка против. Дефект против. Ошибка против. Ошибка против. ОшибкаМы перечислили некоторые существенные различия между ошибкой , дефектом, ошибкой, сбоем и сбоем в приведенной ниже таблице .
|