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

Обновлено: 06.01.2025

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

Я уверен, что это произошло со многими из вас там. Что вы делали в этой ситуации, и каков был конечный результат?

изменить: Меня больше интересует то, что было сделано с unfindable ошибка, не неразрешимая ошибка. Неустранимые ошибки таковы, что вы по крайней мере знаете, что есть проблема и есть отправная точка, в большинстве случаев, для поиска. В случае не поддающегося обнаружению, что вы делаете? Ты вообще можешь что-нибудь сделать?

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

добавление операторов отладки может сделать проблему невозможно потому что оператор отладки сам сдвигает указатели (достаточно далеко, чтобы избежать SEGFAULT). Проблемы с указателем-это кошмар для отслеживания и репликации, но есть отладчики (такие как GDB и DDD), которые могут помочь.

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

JavaScript

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

на сервере?
на рабочем столе?
в веб-браузере?

развития?

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

Это может помочь добавить кучу проверки ошибок и утверждений, чтобы подтвердить или опровергнуть ваши убеждения/предположения. Что-то может потерпеть неудачу, что вы никогда не ожидали.

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

вносить случайные изменения пока что-то не работает :-)

думаю. Трудный. Запрись, не допускай никаких вмешательств.

У меня однажды была ошибка, когда доказательством был шестнадцатеричный дамп поврежденной базы данных. Цепочки указателей были систематически скручены. Все пользовательские программы и программное обеспечение нашей базы данных работали безупречно в тестировании. Я смотрел на него в течение недели (это был важный клиент), и после устранения десятков возможных идей я понял, что данные были распределены по двум физическим файлам, и повреждение произошло там, где цепочки пересекали границы файлов. Я понял, что если операция резервного копирования/восстановления не удалась в критической точке, два файла могут оказаться "несинхронными", восстановленными в разные моменты времени. Если вы затем запустите одну из программ клиента на уже поврежденных данных, она будет производить именно узловатые цепочки указателей, которые я видел. Затем я продемонстрировал последовательность событий, которая точно воспроизводила коррупцию.

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

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

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

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

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

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

работать в обратном направлении от симптома. Подумать про себя.. "если бы я хотел создать симптом, о котором было сообщено, какой бит кода мне нужно было бы выполнить, и как я доберусь до него, и как я доберусь до этого?"D приводит к C приводит к B приводит к A. примите, что если ошибка не воспроизводима, то обычные методы не помогут. Я пришлось смотреть на код в течение многих часов с такого рода мыслительных процессов происходит, чтобы найти некоторые ошибки. Обычно это оказывается чем-то действительно глупо.
помните первый закон отладки Боба: если вы не можете найти что-то, это потому, что вы ищете в неправильном месте: -)

обсудите проблему, прочитайте код, часто довольно много. Часто мы делаем это в парах, потому что обычно вы можете устранить возможности аналитически довольно быстро.

начните с просмотра того, какие инструменты у вас есть в вашем распоряжении. Например, сбои на платформе Windows идут в WinQual, поэтому, если это ваш случай, у вас теперь есть информация о сбросе сбоев. Вы можете использовать инструменты статического анализа, которые выявляют потенциальные ошибки, инструменты анализа времени выполнения, инструменты профилирования?

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

наконец, как сказал Дэвид, смотрите на код.

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

поэтому я боюсь, что я, вероятно, закрою ошибку как WORKSFORME (Bugzilla), а затем исправлю некоторые более ощутимые ошибки. Или делать все, что решит руководитель проекта.

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

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

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

Что вы делаете в таких сценариях?

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

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

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

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

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

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

Еще несколько предложений:

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

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

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

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

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

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

Есть два типа ошибок, которые не воспроизводятся:

1) Те, которые один испытатель (или пользователь) видел один раз, но либо не смогли, либо не попытались воспроизвести.

В этих ситуациях вы должны:

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

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

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

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

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

Звучит так, как это происходит довольно часто, и это заставляет меня задуматься, потому что большинство ошибок действительно трудно воспроизвести, или по какой-то другой причине он не пытается? Знаете ли вы , почему он не пытается воспроизвести проблему? Это потому, что он не понимает, насколько это важно для вас? Или, может быть, у него есть другое давление - менеджер по тестированию, который просто хочет, чтобы он быстро прошел выделенные тесты и, например, выбросил ошибки через стену? Или, может быть, он просто не уверен, как это сделать?

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

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

Если он не был воспроизведен в этой точке, он закрыт, но может быть вновь открыт, если он встречается снова.

изменить: Меня больше интересует, что было сделано о unfindable ошибка, не неразрешимая ошибка. Неразрешимые ошибки таковы, что вы хотя бы знаете, что есть проблема и имеете отправную точку, в большинстве случаев, для ее поиска. В случае с неуловимым, что вы делаете? Ты вообще можешь что-нибудь сделать?

Они известны как Heisenbugs.

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

добавление операторов отладки может сделать проблему невозможно потому что сам оператор отладки сдвигает указатели (достаточно далеко, чтобы избежать SEGFAULT). Проблемы с указателем-кошмар для отслеживания и репликации, но есть отладчики (такие как GDB и DDD), которые могут помочь.

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

JavaScript

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

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

на сервере?
на рабочем столе?
в веб-браузере?

In в какой среде приложение создает проблему?

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

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

ваш приложение номер версии, номер сборки и т. д.? Вам нужно это, чтобы точно определить, какую версию вы отлаживаете (или нет!).

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

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

У меня были хорошие результаты (не появился снова, и код был лучше для него), и плохо (потратил слишком много времени, не исправляя проблема, независимо от того, Исправлена ошибка или нет). Вот для чего нужны оценки и приоритеты.

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

Это может помочь добавить кучу проверки ошибок и утверждений, чтобы подтвердить или опровергнуть ваши убеждения/предположения. Что-то может не получиться, чего вы никогда не ожидали.

общие рекомендации, которые могут помочь в этой ситуации.

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

вносить случайные изменения пока что-то не работает :-)

думаю. Трудный. Запрись, не допускай никаких вмешательств.

У меня однажды была ошибка, когда доказательством был шестнадцатеричный дамп поврежденной базы данных. Цепочки указателей были систематически скручены. Все программы пользователя и программное обеспечение нашей базы данных работали безупречно при тестировании. Я смотрел на него в течение недели (это был важный клиент), и после устранения десятков возможных идей я понял, что данные были распределены по двум физическим файлам, и повреждение произошло там, где цепочки пересекали границы файлов. Я понял, что если операция резервного копирования/восстановления не удалась в критический момент, два файла могут оказаться "не синхронизированными", восстановленными в разные моменты времени. Если затем запустить одну из программ клиента на уже поврежденных данных, то получится именно та цепочка указателей, которую я видел. Затем я продемонстрировал последовательность событий, которая точно воспроизводила коррупцию.

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

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

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

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

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

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

предполагая, что вы уже добавили все журналы, которые, по вашему мнению, помогут, и это не так. на ум приходят две вещи:--1-->

работать в обратном направлении от симптома. Подумать про себя.. "если бы я хотел произвести симптом, о котором сообщалось, какой бит кода мне нужно было бы выполнить, и как бы я до него добрался, и как бы я до него добрался?"D приводит к C приводит к B приводит к A. примите, что если ошибка не воспроизводима, то обычные методы не помогут. Я пришлось смотреть на код в течение многих часов с такого рода мыслительных процессов происходит, чтобы найти некоторые ошибки. Обычно это оказывается чем-то действительно глупо.

помните первый закон отладки Боба: если вы не можете найти что-то, это потому, что вы ищете в неправильном месте: -)

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

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

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

наконец, как сказал Дэвид, посмотрите на код.

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

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

поэтому я боюсь, что, вероятно, закрою ошибку как WORKSFORME (Bugzilla), а затем исправлю некоторые более ощутимые ошибки. Или делать то, что решит руководитель проекта.

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

«Оно просто не работает»

Хороший отчет

какое поведение ожидалось;
что же на самом деле произошло;
что вы при этом сделали или делали.

Какое поведение ожидалось

Что же на самом деле произошло

«Форма не отправляется — я остаюсь на той же странице, где был».

Но, возможно, в результате отправки формы появляется пустая страница:

«После отправки формы загружается пустая страница».

Что вы при этом делали

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

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

Любые введенные данные

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

Браузер и операционная система

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

какое поведение ожидалось;
что же на самом деле произошло; и
что вы при этом сделали или делали.

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

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

Читайте также: