Поиск ошибок в программе что это

Содержание

Поиск ошибок в программе.

Добрый вечер! Здравствуйте, уважаемые дамы и господа! Пятница! В эфире капитал-шоу «Поле чудес»! И как обычно, под аплодисменты зрительного зала я приглашаю в студию тройку игроков. А вот и задание на этот тур:

Вопрос: Поиск ошибок в программе. (Слово из 7 букв)

Ответ: Отладка (7 букв) Если этот ответ не подходит, пожалуйста воспользуйтесь формой поиска.
Постараемся найти среди 775 682 формулировок по 141 989 словам .

Источник: pole-chudes-otvet.ru

Поиск ошибок в программе, 7 букв

Альтернативные варианты определений к слову «отладка», всего найдено — 15 вариантов:

Слова на букву «о»
Слова c «а» на конце
Слова на «от»
Слова, оканчивающиеся на «ка»
Слова на «отл»
Слова, оканчивающиеся на «дка»
Слова, начинающиеся на «отла»
Слова, оканчивающиеся на «адка»
Составить слова из слова «отладка»

Только что искали: анемометр сейчас расентж сейчас о в с я н к а сейчас тартоланп сейчас контузия 1 секунда назад семеновское-красное 1 секунда назад вальст 1 секунда назад путевка 1 секунда назад г л а м у р д 1 секунда назад р а к е т а 1 секунда назад летчик 1 секунда назад парадте 1 секунда назад л о т о с е 1 секунда назад зоаорбд 2 секунды назад рваетцс 2 секунды назад

Поиск ошибок в Excel. Подсчет и работа с ошибками

Источник: makeword.ru

Дебаг и поиск ошибок

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

По опыту работы с начинающими разработчиками, я сталкиваюсь с тем, что поиск ошибок порой занимает слишком много времени. Не из-за того, что они глупее более опытных товарищей или не разбираются в процессах, а из-за отсутствия понимания с чего начать и на чём акцентировать внимание. В статье я собрал общие советы о том где обитают ошибки и как найти причину их возникновения. Примеры в статье даны на JavaScript и .NET, но они актуальны и для других платформ с поправкой на специфику.

Как обнаружить ошибку

Прочитай информацию об исключении

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

В каждом языке есть свои способы уведомления об исключениях. Например в JavaScript для обработки ошибок связанных с Web Api существует DOMException. Для пользовательских сценариев есть базовый тип Error. В обоих случаях в них содержится информация о наименовании и описании ошибки.

Для .NET существует класс Exception и каждое исключение в приложении унаследовано от данного класса, который представляет ошибки происходящие во время выполнения программы. В свойстве Message читаем текст ошибки. Это даёт общее понимание происходящего. В свойстве Source смотрим в каком объекте произошла ошибка.

ОТЛАДКА ПРОГРАММ НА PYTHON И ПОИСК ОШИБОК | ЕГЭ 2022 по информатике

В InnerException смотрим, нет ли внутреннего исключения и если было, то разворачиваем его и смотрим информацию уже в нём. В свойстве StackTrace хранится строковое представление информации о стеке вызова в момент появления ошибки.

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

Всю полученную информацию читаем вдумчиво и внимательно. Любая деталь важна при поиске ошибки. Иногда начинающие разработчики не придают значения этому описанию. Например в .NET при возникновении ошибки NRE с описанием параметра, который разработчик задаёт выше по коду. Из-за этого думает, что параметр не может быть NRE, а значит ошибка в другом месте.

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

Разверните стек

Когда выбрасывается исключение, помимо самого описания ошибки полезно изучить стек выполнения. Для .NET его можно посмотреть в свойстве исключения StackTrace. Для JavaScript аналогично смотрим в Error.prototype.stack (свойство не входит в стандарт) или можно вывести в консоль выполнив console.trace(). В стеке выводятся названия методов в том порядке в котором они вызывались. Если то место, где падает ошибка зависит от аргументов которые пришли из вызывающего метода, то если развернуть стек, мы проследим где эти аргументы формировались.

Загуглите текст ошибки

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

Прочитайте документацию

Если ошибка связана с использованием внешней библиотеки, убедитесь что понимаете как она работает и как правильно с ней взаимодействовать. Типичные ошибки, когда подключив новую библиотеку после прочтения Getting Started она не работает как ожидалось или выбрасывает исключение. Проблема может быть в том, что базовый шаблон подключения библиотеки не применим к текущему приложению и требуются дополнительные настройки или библиотека не совместима с текущим окружением. Разобраться в этом поможет прочтение документации.

Проведите исследовательское тестирование

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

Бинарный поиск

В неочевидных случаях, если нет уверенности что проблема в вашем коде, а сообщение об ошибке не даёт понимания где проблема, комментируем блок кода в котором обнаружилась проблема. Убеждаемся что ошибка пропала. Аналогично бинарному алгоритму раскомментировали половину кода, проверили воспроизводимость ошибки. Если воспроизвелась, закомментировали половину выполняемого кода, повторили проверку и так далее пока не будет локализовано место появления ошибки.

Где обитают ошибки

Ошибки в своём коде

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

Ошибки в чужом коде

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

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

Ошибки в библиотеках

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

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

Во втором случае определите откуда из вашего кода пришли невалидные данные. Для этого смотрим стек выполнения и по цепочке прослеживаем место в котором библиотека вызывается из нашего кода. Далее с этого места начинаем анализ, как туда попали невалидные данные.

Ошибки не воспроизводимые локально

Ошибка воспроизводится на develop стенде или в production, но не воспроизводится локально. Такие ошибки сложнее отлавливать потому что не всегда есть возможность запустить дебаг на удалённой машине. Поэтому убеждаемся, что ваше окружение соответствует внешнему.

Проверьте версию приложения

На стенде и локально версии приложения должны совпадать. Возможно на стенде приложение развёрнуто из другой ветки.

Проверьте данные

Проблема может быть в невалидных данных, а локальная и тестовая база данных рассинхронизированы. В этом случае поиск ошибки воспроизводим локально подключившись к тестовой БД, либо сняв с неё актуальный дамп.

Проверьте соответствие окружений

Если проект на стенде развёрнут в контейнере, то в некоторых IDE (JB RIder) можно дебажить в контейнере. Если проект развёрнут не в контейнере, то воспроизводимость ошибки может зависеть от окружения. Хотя .Net Core мультиплатформенный фреймворк, не всё что работает под Windows так же работает под Linux. В этом случае либо найти рабочую машину с таким же окружением, либо воспроизвести окружение через контейнеры или виртуальную машину.

Коварные ошибки

Метод из подключенной библиотеки не хочет обрабатывать ваши аргументы или не имеет нужных аргументов. Такие ситуации возникают, когда в проекте подключены две разных библиотеки содержащие методы с одинаковым названием, а разработчик по привычке понадеялся, что IDE автоматически подключит правильный using. Такое часто бывает с библиотеками расширяющими функционал LINQ в .NET. Поэтому при автоматическом добавлении using, если всплывает окно с выбором из нескольких вариантов, будьте внимательны.

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

Дополнительные материалы

Алгоритм отладки

Повтори ошибку.
Опиши проблему.
Сформулируй гипотезу.
Проверь гипотезу — если гипотеза проверку не прошла то п.3.
Примени исправления.
Убедись что исправлено — если не исправлено, то п.3.

Подробнее ознакомиться с ним можно в докладе Сергея Щегриковича «Отладка как процесс».

Чем искать ошибки, лучше не допускать ошибки. Прочитайте статью «Качество вместо контроля качества», чтобы узнать как это делать.

Итого

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

Источник: habr.com

Тестирование и поиск ошибок: в чем разница

«Тестирование — это поиск ошибок». Это та самая фраза, которую опасно говорить тестировщику) Но почему? Что в ней такого? Вроде же ошибки то ищут.

Это для опытного специалиста разница очевидна. А для начинающего между этими двумя процессами обычно стоит знак равно. Давайте раз и навсегда закроем вопрос о том, почему тестирование и поиск багов — это разные вещи.

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

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

Поиск багов

Итак, моя задача — найти баги. Что я буду делать? Искать как можно больше багов. Это логично. А чем больше я их найду, тем лучше.

Ну и тем моя ценность, как сотрудника, выше.

Так, а где найти как можно больше багов? Конечно в самых нестабильных областях программы. И не важно значимы они или нет. Чем нестабильней, тем привлекательней.

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

Тестирование

Теперь к тестированию. Какими наши действия будут тут?

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

А что главное для пользователя в продукте? Отсутствие проблем при работе с основными важными функциями. Чтобы при вводе корректных данных мы получили ожидаемый результат.
Получается, что тестировать начнем не с самых нестабильных участков, а самых значимых и с тех, где высока вероятность нахождения критических багов.

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

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

Что мы имеем в итоге?

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

Разница

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

А теперь ближе к тестированию. Возьмем сайт по заказу пиццы. Где искать ошибки? Конечно будем добавлять в корзину невообразимое количество пицц. Еще попробуем уменьшать и увеличивать количество персон 50 раз подряд.

Потом в поле отправки заказа будем вводить такое, что просто не вообразить.
А банальную проверку отправки заказа обойдем стороной. И если там был баг, то никто не сможет оформить заказ.

Чувствуете разницу? Она просто колоссальная.

В случае с поиском ошибок мы по факту совсем не заботимся о качестве продукта.

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

Как верно отметил Дмитрий Безносов, продукт может быть без единого дефекта (условно), но совершенно непригоден к использованию юзерами как в плане UI/IX, так и в плане функциональности.

А Ольга Журавлёва написала, что как раз на первых порах идет эта гонка за багами, потому что они создают ощущение выполненной работы. А вот уже кто эту зависимость преодолел и понял сакральный смысл тестирования — тот уже не джун, а мидл.
То есть начинающему специалисту трудно, когда он не может измерить результат своей работы, поэтому и начинается гонка за количеством. А это путь в никуда.

Кто-то может сказать, что я сильно преувеличиваю. Может в краткосрочной перспективе так и покажется. Но на длинной дистанции однозначно придем к тому, что продукт перестанет соответствовать ожиданиям пользователей и от него попросту отвернутся.

Источник: sedtest-school.ru