что такое баг в коде

Что такое баг: поговорим об ошибках в программировании

Ошибки в программах – дело обыденное. Приложения зависают, вылетают, перестают запускаться. В простейшем случае пользователь решает проблему переустановкой ПО или чисткой от «мусора». Разработчикам же нужно четко понимать, что такое баг, как исправить его и каким образом получить своевременную обратную связь от пользователей.

Что такое баг?

Термин «баг» (в переводе «жук») у программистов обозначает ситуацию, когда определенный код выдает неверный результат. Причины возникновения разные: ошибки в исходном коде, интерфейсе программы или некорректной работе компилятора. Обнаруживают их на этапе отладки или уже на стадии бета-тестирования, выпуска продукта на рынок.

Сложнее всего работать с компьютерными играми, в которых чаще используют термин «краш» (crash). Он означает критическую проблему при запуске или использовании программы. Когда говорят о багах, то чаще имеют в виду сбои графики, например, если игрок «проваливается в текстуры».

Классификация багов

Точка зрения пользователей часто не совпадает с мнением программистов. Так, для первых всего лишь произошел сбой, «приложение перестало работать». Кодеру же предстоит головная боль с определением источника проблемы. Ведь ошибка в программе, вероятно, проявляется лишь на конкретном железе или при сочетании с другим софтом (часто с антивирусами).

Баги делят на категории в зависимости от их критичности:

Последние указывают на критическую программную или аппаратную проблему, из-за которой ПО теряет свою функциональность практически на 100%. Например, не удается авторизоваться через логин-пароль или перестала работать кнопка «Далее». Поэтому таким ошибкам отдают приоритет.

Также есть деление ошибок по частоте проявления. Проще всего исправлять постоянные, возникающие при одних и тех же обстоятельствах, независимо от платформы, аппаратной части компьютера или каких-то действий пользователя. Сложность возрастает при периодических сбоях, когда причиной вполне может оказаться глючная оперативная память или ошибки накопителей.

Есть вариант, когда проблема возникает только на машине конкретного клиента. Здесь приходится либо заказывать индивидуальную «работу над ошибками», либо менять компьютер. Потому что ПО для массового пользователя никто не будет редактировать из-за «одного». Только если наберется некая критическая масса одинаковых случаев.

Разновидности ошибок

Программисту еще важно деление на разные типы ошибок приложений исходя из типовых условий их эксплуатации. Например, возникающие при повышении нагрузки на процессор, в интерфейсе, в модуле обработки входящих данных. Существуют баги граничных условий, сбоя идентификаторов, банальной несовместимости с архитектурой процессора (чаще в мобильных устройствах).

Кодеры делят ошибки по сложности:

Последняя категория ошибок – одна из основных причин регулярного обновления операционных систем Windows. Вроде бы пользователя все устраивает, а разработчик раз за разом выпускает новые пакеты исправлений. Наиболее известный баг, попортивший нервы многим кодерам, это «ошибка 2000 года» (Y2K Error). Про нее успешно забыли, но уроки извлекли.

Программисты различают и те ошибки, что мешают скомпилировать программу, и ворнинги. Вторая категория представляет собой лишь предупреждение о найденных «косяках» в коде, но они не мешают ни сборке ПО, ни последующей эксплуатации. Например, речь идет об отсутствии точки или точки запятой в синтаксисе, когда компилятор способен сам решить проблему.

Логические

Наиболее серьезная из ошибок. Такие баги приводят к изменению функционирования программы вопреки техническому заданию. К чему это приведет, никто не знает – могут записаться на диске «не те данные», некорректно измениться важные документы или предоставиться доступ к коммерческой информации без авторизации. Исправить их получится только при знании изначальной логики.

Синтаксические

Ошибки синтаксиса существуют на уровне конкретного языка программирования: C, Java, Python, Perl и т.д. Что на одной платформе работает максимум с ворнингами, для другой будет серьезной проблемой. Такие баги легко исправить на этапе компиляции, потому что инструмент не позволит «пройти дальше» некорректного участка кода.

Компиляционные

Ситуация происходит, когда код, написанный на языке высокого уровня, преобразуют в «простой», машиночитаемый. Причиной может служить как серьезная ошибка в синтаксисе, так и сбои в самом компиляторе. Такие баги устраняют на этапе разработки-отладки программ, потому что выпустить их даже для бета-тестирования не получится.

Среды выполнения

Так называемые ошибки Run-Time. Проявляются в скомпилированных программах, при запуске. Например, из-за нехватки ресурсов на машине, в результате аварийной ситуации (поломка памяти, носителя, устройств ввода-вывода). Такое происходит, если разработчик не учел реальных условий работы; придется вернуться к стадии проработки логики.

Арифметические

Одна из разновидностей логических ошибок. Происходят, когда программа при работе вычисляет массу переменных, но на каком-то этапе происходит непредвиденное. Например, деление на ноль или же приложение получает «бесконечный» результат. Изменить ситуацию получится только на уровне кода, внедренного в него алгоритма.

Ресурсные

Преимущественно к этой категории относят ошибки типа «переполнение буфера». Программист не учел необходимость очистки памяти перед размещением новых данных. Или интерфейс разработан без учета типовых разрешений экранов, и его элементы постоянно «съезжают», нарушается логика срабатывания кнопок и т.д. Исправить получится только переписыванием части кода.

Взаимодействия

Речь идет о взаимодействии с аппаратным или программным окружением. В случае с приложением для облачного ресурса программист мог допустить ошибку при использовании веб-протоколов. При постоянном появлении ошибки остается только переписывать участок кода, ответственный за появление бага, иначе программа останется неработоспособной.

Что такое исключение

Снизить риски появления непредвиденных ошибок позволяет внедрение в программу исключений. Это события, при возникновении которых начинается «неправильное» поведение. Такой механизм позволяет систематизировать обработку багов независимо от типа приложения, платформы и иных условий. И разработать единую систему реагирования, например, со стороны операционки.

Существуют программные и аппаратные исключения. Первые генерируются самой программой и ОС, под которой она запущена. К аппаратным относятся те, что создаются процессором. Например, деление на 0, переполнение буфера, обращение к невыделенной памяти. Исключениями кодеры охватывают наиболее серьезные, критические баги.

Как избежать ошибок?

Существует два эффективных способа избежать проблем еще на стадии разработки. Первый – это отладка при помощи специальных программ. Они отображают результаты выполнения в цифрах, которые объективно показывают кодеру, правильно ли был обработан следующий участок кода или нужно искать закравшуюся ошибку.

Второй способ представляет собой привлечение специальных людей, тестировщиков. Они помогут разобраться с работоспособностью интерфейса в различных ситуациях, на разных платформах. Это происходит максимально приближенно к реальным условиям. Поэтому любой серьезный продукт проходит такую стадию обязательно.

Выводы

Баги – сопутствующий фактор любой разработки. Большую их часть пользователь не видит, потому что устраняются они еще в «лаборатории», на этапе альфа-тестирования. В бета-версии попадают уже незначительные ошибки, например, связанные с конкретными «узкими» условиями эксплуатации. Редкие проблемы помогают решать краш-репорты – отчеты, отсылаемые производителю самой программой.

Источник

Моя объединенная теория багов

Типичное распределение видов багов в программе

Первая вещь, которую я подметил с тремя типами багов, — это то, что вероятность встретить каждый из них неравномерна. Кроме вероятности различны еще сложность их поиска и исправления в коде (я уверен, что вы так же помните это по своему опыту). Мой опыт построения веб-приложений говорит о том, что больше всех распространены логические баги, за ними следуют баги связывания, и в конце — баги отображения.

Сложность обнаружения Бага

Логические баги обнаружить сложнее всего. Одна из причин состоит в том, что они проявляются только при определенных входных условиях, и поиск этих загадочных наборов или их воспроизведение сопровождается большим напряжением извилин. Баги связывания проще обнаружить, поскольку они легко воспроизводимы на большинстве независимых входных условиях. А баги отображения вы можете просто увидеть своими глазами и быстро показать, что выглядит не так.

Сложность исправления Бага

Практический опыт может показать нам, насколько сложно исправлять ошибки. Логический баг починить довольно сложно, поскольку для поиска решения вы должны понимать все пути выполнения кода. После внесения правок, мы так же должны быть уверены, что исправления не сломают уже существующую функциональность. Проблемы связывания попрвить легче, поскольку они проявляют себя с помощью exсeption’а или неверным местонахождением данных. Баги отображения сами наглядно показывают, что пошло не так, и вы сразу знаете как это исправить. Мы изначально проектируем нашу программу, учитывая частые изменения пользовательского интерфейса, и поэтому нам легче вносить подобные правки.

Как тестопригодность меняет распределение видов багов?

Так получается, что написание тестопригодного кода влияет на распределение видов багов в программе. Для тестопригодности код должен:

Следование этим правилам ведет к существенному сокращению багов связывания. В процентном отношении количество логических багов выросло, но общее количество всех багов сократилось.

Интересно отметить, что можно получить пользу от тестопригодного кода, не написав при этом ни строчки самих тестов. Подобный код — лучший код! (Когда я слышу, как люди приносят в жертву «хороший код» ради тестопригодности, то понимаю, что они совершенно не осознают, что такое на самом деле тестопригодный код)

Мы любим писать модульные тесты (unit tests)

Модульные тесты сфокусированы на логических багах. Они проверяют ваши i’ы и циклы, но не проверяют связывание напрямую (и конечно, не проверяют отображение)

Модульные тесты сфокусированы на КПТ (класс-под-тестом, CUT, class-under-test). Это важно, поскольку вы должны быть уверены, что эти тесты не встанут на пути будущего рефакторинга. Модульные тесты должны ПОМОГАТЬ рефакторингу, а не МЕШАТЬ ему. (Повторюсь: когда я слышу, как кто-то говорит, что тесты мешают рефакторингу, то полагаю, что этот человек не понимает, что такое модульный тест).

Модульные тесты напрямую не скажут, что все OK со связыванием. Они делают это неявно, путем принуждения вас к написанию тестопригодного кода.

Функциональные тесты проверяют связанность, однако это не все. Вы можете долго делать рефакторинг, если у вас много функциональных тестов ИЛИ если вы смешиваете функциональные и логические тесты.

Управление Багами

Я люблю думать о тестировании как об управлении багами (с целью от них избавится). Не все виды ошибок одинаковы, поэтому я выбираю тесты, на которых нужно сконцентрироваться. Я понял, что люблю модульные тесты. Но они должны быть хорошо сфокусированы! Если тест проверяет много классов за один проход, то я могу быть рад хорошему покрытию тестами, но на самом деле после этого сложно найти то место, которое зажгло «красный» тест. Это также может затруднить рефакторинг. Я стараюсь облегчить себе жизнь при функциональном тестировании: для меня достаточно одного теста, который доказывает правильность связывания.

Я слышу, как многие заявляют, что они пишут модульные тесты, но при ближайшем рассмотрении это оказывается смесь функциональных (проверка связывания) и модульных (логика) тестов. Это происходит, когда тесты пишутся после того, как написан код, и из-за этого он получается нетестопригодным. Нетестопригодный код ведет к появлению мокеров (от англ. «mock» — заглушка) — это тест, для которого необходимо много заглушек, а эти заглушки, в свою очередь, используют другие заглушки. Используя тесты с мокерами, вы будете мало в чем уверены. Подобные тесты работают на слишком высоком уровне абстракции, нужном для того, чтобы что-то утверждать на уровне методов. Эти тесты глубоко завязаны на реализации (это видно по наличию большого количества связей между заглушками), вследствие чего любой рефакторинг будет очень болезненным.

Источник

Отчеты о багах

После ручного закрытия приложения в диалоговом окне пользователя появляется автоматический отчет для разработчика, именуемый » bug report» (отчет об ошибке). При автоматическом завершении сеанса работы приложения появляется окно » crash report» (отчет об аварийном завершении).

Только программисты знают, что такое баг, как его локализовать, отладить и протестировать приложение.

Происхождение термина

Также термин «баги» применялся во времена Второй мировой войны. Тогда только военные знали, что такое баг, называя условно этим термином неполадки в работе радарной электроники.

Классификация багов

В отношении этапов программирования ошибки разделяют на следующие группы:

По своему объему баги бывают:

В зависимости от времени баги бывают:

В зависимости от места выявления ошибки бывают:

Каждая ошибка может проявиться в любое время. Это зависит от ее характера, загруженности системы пользователя, настроек. Возникающие баги делают компьютер более уязвимым для несанкционированного доступа или DoS-атаки.

Типы сбоев

«Плавающий» и часто изменяющий свой свойства сбой, который сложно отследить, именуют гейзенбагом.

Критический сбой, приводящий к полному прекращению функционирования системы, называют шрединбагом.

Источник

Как искать и исправлять ошибки в коде

Авторизуйтесь

Как искать и исправлять ошибки в коде

Искать ошибки в программах — непростая задача. Здесь нет никаких готовых методик или рецептов успеха. Можно даже сказать, что это — искусство. Тем не менее есть общие советы, которые помогут вам при поиске. В статье описаны основные шаги, которые стоит предпринять, если ваша программа работает некорректно.

Шаг 1: Занесите ошибку в трекер

После выполнения всех описанных ниже шагов может так случиться, что вы будете рвать на себе волосы от безысходности, все еще сидя на работе, когда поймете, что:

Трекер поможет вам не потерять нить размышлений и о текущей проблеме, и о той, которую вы временно отложили. А если вы работаете в команде, это поможет делегировать исправление коллеге и держать все обсуждение в одном месте.

Вы должны записать в трекер следующую информацию:

Это должно подсказать, как воспроизвести ошибку. Если вы не сможете воспроизвести ее в любое время, ваши шансы исправить ошибку стремятся к нулю.

Шаг 2: Поищите сообщение об ошибке в сети

Если у вас есть сообщение об ошибке, то вам повезло. Или оно будет достаточно информативным, чтобы вы поняли, где и в чем заключается ошибка, или у вас будет готовый запрос для поиска в сети. Не повезло? Тогда переходите к следующему шагу.

Шаг 3: Найдите строку, в которой проявляется ошибка

Если ошибка вызывает падение программы, попробуйте запустить её в IDE под отладчиком и посмотрите, на какой строчке кода она остановится. Совершенно необязательно, что ошибка будет именно в этой строке (см. следующий шаг), но, по крайней мере, это может дать вам информацию о природе бага.

Шаг 4: Найдите точную строку, в которой появилась ошибка

Как только вы найдете строку, в которой проявляется ошибка, вы можете пройти назад по коду, чтобы найти, где она содержится. Иногда это может быть одна и та же строка. Но чаще всего вы обнаружите, что строка, на которой упала программа, ни при чем, а причина ошибки — в неправильных данных, которые появились ранее.

Если вы отслеживаете выполнение программы в отладчике, то вы можете пройтись назад по стектрейсу, чтобы найти ошибку. Если вы находитесь внутри функции, вызванной внутри другой функции, вызванной внутри другой функции, то стектрейс покажет список функций до самой точки входа в программу (функции main() ). Если ошибка случилась где-то в подключаемой библиотеке, предположите, что ошибка все-таки в вашей программе — это случается гораздо чаще. Найдите по стектрейсу, откуда в вашем коде вызывается библиотечная функция, и продолжайте искать.

Шаг 5: Выясните природу ошибки

Ошибки могут проявлять себя по-разному, но большинство из них можно отнести к той или иной категории. Вот наиболее частые.

Если ваша ошибка не похожа на описанные выше, или вы не можете найти строку, в которой она появилась, переходите к следующему шагу.

Шаг 6: Метод исключения

Если вы не можете найти строку с ошибкой, попробуйте или отключать (комментировать) блоки кода до тех пор, пока ошибка не пропадет, или, используя фреймворк для юнит-тестов, изолируйте отдельные методы и вызывайте их с теми же параметрами, что и в реальном коде.

Попробуйте отключать компоненты системы один за другим, пока не найдете минимальную конфигурацию, которая будет работать. Затем подключайте их обратно по одному, пока ошибка не вернется. Таким образом вы вернетесь на шаг 3.

Шаг 7: Логгируйте все подряд и анализируйте журнал

Пройдитесь по каждому модулю или компоненту и добавьте больше сообщений. Начинайте постепенно, по одному модулю. Анализируйте лог до тех пор, пока не проявится неисправность. Если этого не случилось, добавьте еще сообщений.

Ваша задача состоит в том, чтобы вернуться к шагу 3, обнаружив, где проявляется ошибка. Также это именно тот случай, когда стоит использовать сторонние библиотеки для более тщательного логгирования.

Шаг 8: Исключите влияние железа или платформы

Замените оперативную память, жесткие диски, поменяйте сервер или рабочую станцию. Установите обновления, удалите обновления. Если ошибка пропадет, то причиной было железо, ОС или среда. Вы можете по желанию попробовать этот шаг раньше, так как неполадки в железе часто маскируют ошибки в ПО.

Если ваша программа работает по сети, проверьте свитч, замените кабель или запустите программу в другой сети.

Ради интереса, переключите кабель питания в другую розетку или к другому ИБП. Безумно? Почему бы не попробовать?

Если у вас возникает одна и та же ошибка вне зависимости от среды, то она в вашем коде.

Шаг 9: Обратите внимание на совпадения

Шаг 10: Обратитесь в техподдержку

Наконец, пора попросить помощи у того, кто знает больше, чем вы. Для этого у вас должно быть хотя бы примерное понимание того, где находится ошибка — в железе, базе данных, компиляторе. Прежде чем писать письмо разработчикам, попробуйте задать вопрос на профильном форуме.

Ошибки есть в операционных системах, компиляторах, фреймворках и библиотеках, и ваша программа может быть действительно корректна. Но шансы привлечь внимание разработчика к этим ошибкам невелики, если вы не сможете предоставить подробный алгоритм их воспроизведения. Дружелюбный разработчик может помочь вам в этом, но чаще всего, если проблему сложно воспроизвести вас просто проигнорируют. К сожалению, это значит, что нужно приложить больше усилий при составлении багрепорта.

Полезные советы (когда ничего не помогает)

Что вам точно не поможет

Ошибка, которую я недавно исправил

Источник

Что такое баг в коде

Простыми словами о сложном

Краткое содержание

Вы узнаете, что это такое – баг, какие баги бывают на веб-сайтах и в целом в интернет-маркетинге, и чем они чреваты. Понятным языком сделаны акценты на принципиальные вопросы – существенные для понимания владельцами веб-ресурсов. Для бизнесменов эта информация особенно полезна, поскольку к коммерческим сайтам предъявляются повышенные требования, ибо речь о деньгах. В «Конкретике» выделены наиболее актуальные вопросы по работе с багами, и традиционно предложена помощь от «SeoTemple». В конце, как обычно, – ссылки на дополнительные материалы.

Оглавление

1. «Классические» баги

Баг – жаргонное слово, используемое в основном создателями и тестировщиками программного обеспечения.

Баг означает ошибку в программировании, приводящую к некорректной работе или вообще серьёзным сбоям программы, вплоть до её отказа. Но эти ошибки не всегда явные, а потому и называются «баги», что в переводе с английского (bug) означает насекомое, а в конкретном смысле – «жучки», т.е. скрытые дефекты.

Сам программист может не видеть такие дефекты (на то они и баги). Соответственно, большинство из них выявляется уже в процессе работы с программой. Поэтому перед выпуском программного продукта, например, в продажу, он обязательно проходит этап тестирования. Этот этап как раз и направлен на выявление багов. Затем ещё может проводиться «обкатка» программы на пользователях в так называемой бета-версии. На этом этапе – уже пользователями – выявляются дополнительные недочёты – баги. Наконец, даже после выпуска коммерческой версии программного продукта, в нём всё равно могут «вылезать» баги. Типичный пример – операционная система Windows. Помимо выхода её новых версий, к каждой версии Microsoft выпускает постоянные обновления, призванные в т.ч. устранить недочёты – «заткнуть дыры».

Но баги могут возникать не только вследствие изначально допущенных ошибок в программе. Программный продукт может со временем эволюционировать, например, дополняться новыми функциями. Этот процесс также связан с появлением багов, которые часто выявляются и исправляются уже в рабочей версии программы – по откликам от пользователей.

2. Баги сайта

В основном баги сайта можно разделить на три основные категории, каждая из которых имеет собственные особенности.

2.1. Программные баги сайта

Поскольку веб-сайт – это тоже программный продукт, для него также актуально явление баг.

Например, баги могут приводить к некорректной работе самого сайта: некорректным загрузке и отображению страниц в браузере, некорректным кодам ответа сервера, нерабочим скриптам и т.д. – может быть много всего. Некоторые баги на сайтах могут быть незаметны большинству пользователей, а некоторые существенно осложняют взаимодействие с сайтом. Например, вследствие ошибок программирования могут не работать или некорректно работать поиск на сайте, фильтр для выбора товаров, форма регистрации, некоторые функции в корзине интернет-магазина и проч. Также могут очень долго грузиться или вообще не отображаться картинки, не загружаться какие-то материалы, отсутствовать страницы по ссылкам (ошибка 404), присутствовать странные редиректы (перенаправления) пользователей на другие страницы и т.д. Могут быть допущены и ошибки в веб-верстке сайта (HTM-коде), приводящие к некорректному отображению страниц сайта во всех браузерах или отдельных из них (отсутствие кроссбраузерной верстки). То есть программных ошибок – классических багов – на сайтах встречается достаточно много.

2.2. SEO-баги

Кроме этого, на сайте могут быть ошибки, которые хоть и не относятся к типичным багам, но тем не менее значительно ухудшают качество сайта как для пользователя, так и, например, с точки зрения поисковой оптимизации (SEO).

В отношении SEO ошибки могут быть технического характера – по своей сути близкие к багам.

К таким ошибкам относятся, например, технические внутренние дубли сайта, возникающие вследствие некорректной работы CMS (багов в ней) и недочётов в файле robots.txt; технические внешние дубли, возникающие при неправильной склейке зеркал; неграмотное оформление метатегов, прочих участков HTML-кода и т.д. Вообще SEO-ошибок может быть очень много, и рассматривать (выявлять) их следует отдельно для каждого сайта. Сама по себе, это очень важная и комплексная работа – SEO-аудит сайта.

Да, большинство SEO-ошибок не являются классическими багами, т.е. это не ошибки программирования. Однако, они могут существенно осложнять продвижение сайта, а главное – носят неявный характер, т.е. в сути своей – баги. Об этих ошибках владелец сайта, как правило, не догадывается, да и квалифицированные SEO-специалисты выявляют их только в процессе комплексного аудита сайта, о чём говорилось выше. При этом SEO-недочеты (баги), ухудшая продвижение бизнес-сайта в поисковых системах – основном канале трафика, – снижают его продающую способность. То есть здесь речь уже о прямой потере денег (падении продаж).

2.3. Юзабилити-баги

Ошибки могут быть допущены и в отношении юзабилити, т.е. удобства работы пользователей с сайтом. Выше уже были перечислены некоторые технические ошибки такого рода: нерабочие поиск, фильтры, форма регистрации и проч. Но и само наполнение сайта – его контент в широком смысле: структура, навигационные возможности, например меню, – а также картинки, тексты, кнопки и ссылки на отдельных страницах и т.д., – во всех этих вещах могут быть допущены ошибки. Они могут существенно осложнять взаимодействие пользователей с сайтом (плохое юзабилити). И «фишка» в том, что самому веб-разработчику, а также владельцу сайта эти ошибки далеко не всегда очевидны. А между тем, подобные ошибки могут существенно ухудшать качество сайта, что особенно критично в отношении бизнес-ресурсов: падает их продающая способность. Более того, неудобство сайтов для пользователя видно и поисковым системам через так называемые поведенческие факторы (ПФ). Для поисковиков это сигнал к понижению ранжирования сайта в своей выдаче. И это дополнительный фактор, снижающий коммерческую эффективность веб-ресурса, о чём говорилось выше (см. раздел 2.2 «SEO-баги»).

3. Конкретика

Таким образом, классические ли это баги или нет, если речь о сайте, – все они критичны для его качества, а, следовательно, для его коммерческой эффективности, если это бизнес-сайт. И общая суть этих ошибок в том, что большинство из них являются неявными – известными только профессионалам.

Мы знаем об этих ошибках и заранее учитываем их при создании и продвижении сайтов для наших клиентов. Кроме того, наши специалисты сделают профессиональный аудит ваших сайтов и дадут конкретные рекомендации по исправлению багов, а также окажут практическую помощь – вытравят всех «насекомых»!

А ниже, собственно, конкретика:

Источник