Какие-нибудь хорошие стратегии для борьбы с "невоспроизводимыми" ошибками?

Ответ 1

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

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

• Проверить систему/среду, используемую для создания ошибки

Я нашел много "неподходящих" ошибок и только позже обнаружил, что они воспроизводятся в Mac OS (10.4). Запуск X версии Safari. И это не относится только к браузерам и рендерингу, оно может применяться ко всему; другие приложения, которые в настоящее время выполняются, независимо от того, является ли пользователь RDP или локальным, администратором или пользователем и т.д. Убедитесь, что вы максимально приближаетесь к своей среде, прежде чем называть ее непригодной.

• Сбор скриншотов и журналов

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

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

Скриншоты также помогают в этом, потому что вы можете обнаружить, что "часть X загрузилась правильно, но она не должна быть, потому что она зависит от Y", и это может дать вам подсказку. Даже если пользователь может описать, что делает, снимки экрана могут помочь еще больше.

• Соберите пошаговое описание от пользователя

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

• Попробуйте альтернативные подходы для получения ошибки

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

Ответ 2

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

Ответ 3

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

Иногда это работает (например, другое оборудование, двойное ядро ​​против гиперпотока, диск с ноутбуком и рабочей станцией,...).

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

Но, конечно, мы не пишем слишком много ошибок в первую очередь:)

Ответ 4

разрешены "стерильные" и "жуткий"

У нас есть две закрытые категории ошибок.

стерильный - не может воспроизводиться.

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

Ответ 5

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

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

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

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

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

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

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

Ответ 6

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

Ответ 7

Некоторые из новых функций в Visual Studio 2010 помогут. См:

• Исторический отладчик и анализ результатов тестирования в Visual Studio Team System 2010
• Лучшее качество программного обеспечения с помощью Visual Studio Team System 2010
• Ручное тестирование с помощью Visual Studio Team System 2010

Ответ 8

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

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

Ответ 9

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

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

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

Ответ 10

Вы говорите о проблемах, которые воспроизводимы, но только в некоторых системах. Они просты в обращении:

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

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

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

Как только вы сможете воспроизвести его, вы можете исправить его. Не имеет значения, в какой системе.

Сложная проблема - это действительно нерепирумпируемые проблемы, то есть вещи, которые происходят только с перерывами. Для этого мне придется перекликаться с сообщениями, журналами и суровыми требованиями.:)

Ответ 11

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

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

Иногда вам повезло, и у вас есть журналы аудита, которые вы можете воспроизвести, что значительно увеличивает вероятность воссоздания проблемы. Вы также можете подчеркнуть среду с большими объемами транзакций. Это эффективно сжимает время, так что если ошибка возникает один раз в неделю, вы можете надежно воспроизвести ее в течение 1 дня, если вы нажмете систему на 7 X на производственную нагрузку.

Последнее средство - это проверка белых ящиков, где вы проходите тесты кода по строкам, когда вы идете.

Ответ 12

Регистрация - ваш друг!

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

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

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

Ответ 13

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

• Четкое описание проблемы вместе с шагами по воспроизведению и наблюдаемому поведению. Недвусмысленная отчетность помогает понять проблему всей командой, устраняя неправильные выводы. Например, пустой экран отчета пользователя отличается от зависания HMI при действии пользователя. Также важна последовательность шагов и приблизительное время действия пользователя. Пользователь сразу выбирает параметр после перехода на экран или ждет несколько минут? Интересная ошибка в отношении времени - это автомобиль, вызывающий аллергию на ванильное мороженое, которое сбивало с толку инженеров-автомобилестроителей.

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

• Обширная регистрация. Это зависит от условий ведения журнала, которые следуют в соответствующих проектах. Работая со встроенными системами Linux, мы не только предоставляем общие диагностические журналы, но также журналы системного уровня, такие как dmesg или верхние журналы команд. Вы, возможно, никогда не узнаете, что неправильная часть - это не поток кода, а аномальное использование памяти/использование ЦП. Определите тип проблемы и сообщите соответствующие журналы для расследования.

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

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

Ответ 14

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

Ответ 15

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

Ответ 16

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

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