Есть ли хорошие стратегии для работы с «невоспроизводимыми» ошибками?

Question

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

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

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

Answer 1

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

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

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

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

• Сбор скриншотов и логов

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

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

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

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

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

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

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

Answer 2

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

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

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

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

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

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

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

Answer 3

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

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

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

Но, конечно, мы не пишем слишком много ошибок:)

Answer 4

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

Answer 5

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

У нас есть две закрытые категории ошибок для этой ситуации.

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

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

Answer 6

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

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

Answer 7

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

Answer 8

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

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

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

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

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

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

Answer 9

Входил в друзья!

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

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

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

Answer 10

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

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

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

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