У нас есть ошибка в нашем приложении, которая не возникает каждый раз, и поэтому мы не знаем ее "логики". Я даже не заставляю его воспроизводиться в 100 раз сегодня.
Отказ от ответственности: эта ошибка существует, и я ее видел. Это не pebkac или что-то подобное.
Каковы распространенные подсказки для воспроизведения такого рода ошибок?
Проанализируйте проблему в паре и прочитайте код с паролем. Делайте заметки о проблемах, которые вы ЗНАЕТ, чтобы быть правдой, и пытайтесь утверждать, какие логические предпосылки должны быть истинными для этого. Следуйте свидетельствам, подобным CSI.
Большинство людей инстинктивно говорят "добавьте больше протоколирования", и это может быть решением. Но для многих проблем это только усугубляет ситуацию, поскольку ведение журнала может значительно изменить временные зависимости, чтобы сделать проблему более или менее частым. Изменение частоты от 1 в 1000 до 1 в 1 000 000 не приблизит вас к истинному источнику проблемы.
Итак, если ваши логические соображения не решают проблему, это, вероятно, даст вам несколько специфических особенностей, которые вы могли бы исследовать с протоколированием или утверждениями в вашем коде.
Добавьте какой-то журнал или трассировку. Например, зарегистрируйте последние действия X, которые пользователь совершил, прежде чем вызвать ошибку (только если вы можете установить условие для соответствия ошибке).
Нет общего хорошего ответа на вопрос, но вот что я нашел:
Для этого требуется талант. Не все разработчики лучше всего подходят для него, даже если они суперзвезды в других областях. Так что знайте свою команду, у которой есть талант к ней, и надеюсь, что вы сможете дать им достаточно конфет, чтобы заставить их в восторге от помощи вам, даже если это не их область.
Работайте назад и относитесь к ней как к научным исследованиям. Начните с ошибки, что вы видите неправильно. Разработайте гипотезы о том, что может это сделать (это творческая/творческая часть, искусство, для которого не все имеют талант), и это помогает многому узнать, как работает код. Для каждой из этих гипотез (предпочтительно отсортированных по тому, что вы считаете наиболее вероятным), снова чистая кишка чувствуется здесь), разработать тест, который пытается устранить его как причину, и проверить гипотезу. Любое заданное несоблюдение предсказания не означает, что гипотеза неверна. Протестируйте гипотезу, пока она не будет подтверждена как неправильная (хотя, поскольку она становится менее вероятной, вы можете сначала перейти к другой гипотезе, просто не уменьшайте ее до тех пор, пока не получите окончательный отказ).
Соберите как можно больше данных во время этого процесса. Обширная регистрация и все остальное применимо. Не снижайте гипотезу, потому что вам не хватает данных, а скорее устраняйте нехватку данных. Довольно часто вдохновение для правильной гипотезы происходит от изучения данных. Заметив что-то в трассе стека, странную проблему в журнале, что-то не хватает, что должно быть в базе данных и т.д.
Двойная проверка каждого предположения. Так много раз я видел, что проблема не исправлялась быстро, потому что какой-то общий вызов метода еще не исследовался, поэтому проблема считалась неприменимой. "О, это должно быть просто". (См. Пункт 1).
Если у вас заканчиваются гипотезы, это обычно связано с недостаточным знанием системы (это верно, даже если вы написали каждую строку кода самостоятельно), и вам нужно пройти и просмотреть код и получить дополнительное представление о чтобы придумать новую идею.
Конечно, ни одно из перечисленных выше ничего не гарантирует, но это тот подход, который я нашел, получает результаты последовательно.
Очень часто программисты не могут повторить потерю пользовательского опыта просто потому, что вы разработали определенный рабочий процесс и привычки в использовании приложения, которое явно обошло ошибку.
На этой частоте 1/100 я бы сказал, что первое, что нужно сделать, - это обрабатывать исключения и записывать что угодно в любом месте, или вы могли бы потратить еще одну неделю на поиски этой ошибки. Также сделайте список приоритетов потенциально чувствительных артикуляций и функций в вашем проекте. Например: 1 - Многопоточность 2 - Дикие указатели/свободные массивы 3 - Опора на устройствах ввода и т.п. Это поможет вам сегментировать области, которые вы можете перетащить с силой до момента разрыва, как это было предложено другими плакатами.
Так как это язык-агностик, я упомянул несколько аксиом отладки.
Ничего, что когда-либо делал компьютер, является случайным. "Случайное вхождение" указывает на еще нераскрытый шаблон. Отладка начинается с выделения шаблона. Разделите отдельные элементы и оцените, что делает изменения в поведении ошибки.
Разный пользователь, тот же компьютер? Тот же пользователь, другой компьютер? Является ли возникновение сильно периодическим? Перезагружает ли периодичность?
FYI- Я однажды увидел ошибку, с которой столкнулся один человек. Я буквально подразумеваю человека, а не учетную запись пользователя. Пользователь A никогда не увидит проблему в своей системе, Пользователь B будет сидеть на этой рабочей станции, подписанный как пользователь A и может сразу воспроизвести ошибку. Не должно быть мыслимого способа для приложения узнать разницу между физическим телом в кресле. Однако -
Пользователи использовали приложение по-разному. Пользователь Пользователь обычно использовал горячую клавишу для вызова действия, а Пользователь B использовал экранное управление. Разница в поведении пользователя каскадируется в видимую ошибку несколькими действиями позже.
Любая разница, влияющая на поведение ошибки, должна быть исследована, даже если это не имеет смысла.
Хорошая вероятность того, что ваше приложение будет MTWIDNTBMT (Multi Threaded, когда вам не нужно многопоточно), или, может быть, просто многопоточным (чтобы быть вежливым). Хороший способ воспроизвести спорадические ошибки в многопоточных приложениях - это покрасить такой код (С#):
Random rnd = new Random();
System.Threading.Thread.Sleep(rnd.Next(2000));
и/или это:
for (int i = 0; i < 4000000000; i++)
{
// tight loop
}
для имитации потоков, выполняющих свои задачи в разное время, чем обычно, или привязки процессора к длительным отрезкам.
На протяжении многих лет я унаследовал множество багги, многопоточных приложений, и код, подобный приведенным выше примерам, обычно приводит к тому, что спорадические ошибки происходят гораздо чаще.
Добавьте подробное ведение журнала. Для понимания сценария потребуется несколько - иногда дюжина (и) - итераций, чтобы добавить достаточную регистрацию. Теперь проблема заключается в том, что если проблема является условием гонки, которая, скорее всего, не будет надежно воспроизведена, поэтому регистрация может изменить время, и проблема перестанет происходить. В этом случае не регистрируйтесь в файле, но держите вращающийся буфер журнала в памяти и удаляйте его только на диск, когда обнаруживаете, что проблема произошла.
Изменить: немного больше мыслей: если это тест запуска приложения gui с помощью инструмента автоматизации qa, который позволяет воспроизводить макросы. Если это приложение типа службы, попробуйте придумать хотя бы предположение о том, что происходит, а затем программно создать шаблоны использования "freak", которые будут использовать код, который вы подозреваете. Создайте более высокие, чем обычно, нагрузки и т.д.
Какая среда разработки? Для С++ лучшим выбором может быть запись/воспроизведение рабочей станции VMWare, см. http://stackframe.blogspot.com/2007/04/workstation-60-and-death-of.html
Другие предложения включают проверку трассировки стека и тщательный обзор кода... на самом деле нет серебряной пули:)
Попробуйте добавить код в приложение, чтобы автоматически отслеживать ошибку после ее возникновения (или даже оповещать вас по почте или SMS).
запишите, что вы можете сделать, когда это произойдет, вы можете поймать правильное состояние системы.
Еще одна вещь - попробуйте применить автоматическое тестирование, которое может охватывать больше территории, чем человеческое тестирование в форме. Это длинный выстрел, но хорошая практика в целом.
все вышеперечисленное, плюс бросьте на него некоторый грубой силовой робот-робот, который является полуразмерным, и scater много утверждают/проверяют (c/С++, вероятно, похожие в других языках) через код
Тонны ведения журнала и тщательный обзор кода - это ваши единственные варианты.
Это может быть особенно болезненно, если приложение развернуто, и вы не можете настроить ведение журнала. В этот момент ваш единственный выбор проходит через код с тонкой зубной гребенкой и пытается понять, как программа может войти в плохое состояние (научный метод спасения!)
Часто такие ошибки связаны с поврежденной памятью, и по этой причине они могут появляться не очень часто. Вы должны попытаться запустить свое программное обеспечение с каким-то профилировщиком памяти, например, valgrind, чтобы убедиться, что что-то пошло не так.
Наряду с большим терпением, тихой молитвой и бичем вам понадобится:
НТН.
Предположим, что Im начинается с производственного приложения.
Я обычно добавляю журнал отладки вокруг областей, где, как я думаю, возникает ошибка. Я настраиваю инструкции регистрации, чтобы дать мне представление о состоянии приложения. Затем я включил уровень журнала отладки и попрошу пользователя/оператора (ей) сообщить мне о времени следующего появления ошибки. Затем я анализирую журнал, чтобы узнать, какие подсказки он дает о состоянии приложения, и если это приведет к лучшему пониманию того, что может пойти не так.
Повторяю шаг 1, пока у меня не будет хорошей идеи, где я могу начать отладку кода в отладчике
Иногда число итераций выполняемого кода является ключевым, но в других случаях это может быть взаимодействие компонента с внешней системой (база данных, конкретная пользовательская машина, операционная система и т.д.). Потратьте немного времени, чтобы настроить среду отладки, которая соответствует производственной среде как можно ближе. Технология VM - хороший инструмент для решения этой проблемы.
Далее я перехожу через отладчик. Это может быть связано с созданием тестового жгута, который помещает код/компоненты в состояние Ive, наблюдаемое из журналов. Знание того, как настроить условные точки останова, может сэкономить много времени, поэтому ознакомьтесь с этим и другими функциями вашего отладчика.
Отладка, отладка, отладка. Если вы не пойдете никуда через несколько часов, сделайте перерыв и немного поработайте над чем-то, не связанным. Вернитесь с новым умом и перспективой.
Если вы до сих пор не получили нигде, вернитесь к шагу 1 и выполните еще одну итерацию.
Для действительно трудных проблем вам, возможно, придется прибегнуть к установке отладчика в системе, где происходит ошибка. Это в сочетании с тестовой упряжкой с шага 4 обычно может взламывать действительно непонятные проблемы.
Единичные тесты. Тестирование ошибки в приложении часто ужасает, потому что столько шума, сколько переменных факторов. В общем, чем больше (сена) стек, тем сложнее выявить проблему. Творчески расширяя рамки unit test, чтобы охватить кромки края, можно сэкономить часы или даже дни просеивания
Сказав, что нет серебряной пули. Я чувствую вашу боль.
Добавить проверку до и после условия в методах, связанных с этой ошибкой.
Вы можете взглянуть на Дизайн по контракту
Предполагая, что вы находитесь в Windows, и ваша "ошибка" - это сбой или некоторая коррупция в неуправляемом коде (C/С++), а затем посмотрите Application Verifier от Microsoft. У инструмента есть несколько остановок, которые можно включить для проверки вещей во время выполнения. Если у вас есть идея сценария, в котором происходит ваша ошибка, попробуйте запустить сценарий (или стресс-версию сценария) при запуске AppVerifer. Обязательно включите переборщик в AppVerifier или подумайте о компиляции кода с помощью переключателя /RTCcsu (см. http://msdn.microsoft.com/en-us/library/8wtf2dfz.aspx для получения дополнительной информации).
Прочитайте трассировку стека и попытайтесь угадать, что могло случиться; затем попробуйте трассировать \log каждую строку кода, которая потенциально может вызвать проблемы.
Следите за тем, чтобы распоряжаться ресурсами; многие скрытые спорадические ошибки, которые я обнаружил, были связаны с близкими \dispose things:).
" Heisenbugs" требуют больших навыков для диагностики, и если вы хотите помочь людям здесь, вам нужно описать это гораздо подробнее, и терпеливо слушайте различные тесты и проверки, сообщайте о результатах здесь и повторяйте это до тех пор, пока вы его не решите (или решите, что это слишком дорого с точки зрения ресурсов).
Вам, вероятно, придется рассказать нам о вашей реальной ситуации, языке, БД, оперативной системе, оценке рабочей нагрузки, времени дня, в котором это происходило в прошлом, и о множестве других вещей, о тестах, которые вы уже делали, о том, как они прошли, и будьте готовы сделать больше и поделиться результатами.
И это не гарантирует, что мы коллективно можем его найти, либо...
Я бы предложил записать все, что делал пользователь. Если вы позволите сказать 10 таких отчетов об ошибках, вы можете попытаться найти что-то, что их связывает.
Для проектов .NET Вы можете использовать Elmah (модули регистрации ошибок и обработчики ошибок) для отслеживания вашего приложения для исключенных исключений, он очень прост в установке и обеспечивает очень хороший интерфейс для просмотра неизвестных ошибок.
http://code.google.com/p/elmah/
Это спасло меня только сегодня, когда вы обнаружили очень случайную ошибку, которая происходила во время процесса регистрации
Кроме этого, я могу только рекомендовать, чтобы как можно больше получить как можно больше информации от ваших пользователей и иметь полное представление о рабочем процессе проекта
Они в основном выходят ночью... в основном
Команда, с которой я работаю, заверила пользователей в том, что они записывают свое время, которое они проводят в нашем приложении, с CamStudio, когда у нас есть жуткая ошибка для отслеживания. Он прост в установке и для их использования, и значительно облегчает воспроизведение этих ошибок, поскольку вы можете наблюдать за тем, что делают пользователи. Он также не имеет отношения к языку, на котором вы работаете, поскольку он просто записывает рабочий стол Windows.
Однако этот маршрут представляется жизнеспособным только в том случае, если вы разрабатываете корпоративные приложения и имеете хорошие отношения с вашими пользователями.
Это изменяется (как вы говорите), но некоторые из вещей, которые могут быть полезны с этим, могут быть
@p.marino - недостаточно комментариев для комментариев =/
tl; dr - сбои сборки из-за времени суток
Вы упомянули время дня, и это привлекло мое внимание. Если бы однажды кто-то остался на работе в ночное время, попытался построить и совершить до того, как они ушли, и продолжал провал. Они в конце концов сдались и пошли домой. Когда они поймали на следующее утро, они построили штраф, они совершили (вероятно, должно было быть более подозрительным =]), и сборка работала для всех. Через неделю или две кто-то задержался и неожиданно закончил неудачу. Оказывается, в коде произошла ошибка, которая сделала любую сборку после разрыва 7PM > . >
Мы также обнаружили ошибку в одном редко используемом углу проекта в этом январе, что вызвало проблемы с сортировкой между различными схемами, потому что мы не учитывали разные календари, основанные на 0 и 1 месяц. Поэтому, если бы никто не перепутал эту часть проекта, мы бы не нашли ошибку до jan. 2011
Это было легче исправить, чем проблемы с потоками, но все же интересно, что я думаю.
нанять некоторых тестеров!
Это сработало для действительно странных heisenbugs. (Я также рекомендовал бы получить копию "Отладки" Дэйва Арганса, эти идеи частично получены из его идей!)
(0) Проверьте RAM системы, используя что-то вроде Memtest86!
Вся система обнаруживает проблему, поэтому создайте тестовое приспособление, которое выполняет все это. Скажите, что это серверная штука с графическим интерфейсом, вы запускаете все это с помощью графического интерфейса GUI, делающего необходимый ввод, чтобы спровоцировать проблему.
Это не выйдет из строя в течение 100% времени, поэтому вам придется чаще его терпеть.
Начните с резания системы наполовину (бинарная отбивная) В худшем случае вам нужно удалить подсистемы по одному. заглушите их, если они не могут быть прокомментированы.
Посмотрите, все еще не удается. Это происходит чаще?
Сохраняйте правильные записи тестов и изменяйте только одну переменную за раз!
В худшем случае вы используете джиг, и вы тестируете несколько недель, чтобы получить значимую статистику. Это трудно; но помните, что джиг выполняет работу.
У меня нет потоков и только один процесс, и я не говорю с оборудованием
Если система не имеет потоков, никаких коммуникационных процессов и контактов нет аппаратного обеспечения; это сложно; heisenbugs, как правило, синхронизируются, но в случае без потоков нет процессов, скорее всего, это неинициализированные данные или данные, используемые после выпуска, либо в куче, либо в стеке. Попробуйте использовать checker, как valgrind.
Для проблем с многопоточными/многопроцессорными процессами:
Попробуйте запустить его на другом количестве процессоров. Если он работает на 1, попробуйте 4! Попробуйте заставить 4-компьютерную систему на 1. Это в основном гарантирует, что все происходит по очереди.
Если есть потоки или процессы обмена сообщениями, это может избавиться от ошибок.
Если это не помогает, но вы подозреваете, что это синхронизация или потоки, попробуйте изменить размер времени ожидания OS. Сделайте это так хорошо, как позволяет ваш поставщик ОС! Иногда это приводило к тому, что условия гонок случались почти каждый раз!
Напоследок, попробуйте сделать медленнее на тайм-листах.
Затем вы устанавливаете тестовый джойстик, работающий с отладчиком (-ами), прикрепленным повсюду, и дождитесь остановки тестового зажима по ошибке.
Если все остальное не удается, поместите оборудование в морозильник и запустите его там. Сроки всего будут сдвинуты.
Отладка сложна и требует много времени, особенно если вы не можете детерминистически воспроизвести проблему. Мой совет вам - выяснить шаги, чтобы воспроизвести его детерминистически (а не только иногда).
Прошло много исследований в области воспроизводства неудач в последние годы и по-прежнему очень активно. Рекордные методы воспроизведения были (до сих пор) ориентированы на исследования большинства исследователей. Это то, что вам нужно сделать:
1) Проанализируйте исходный код и определите, каковы источники недетерминированности в приложении, то есть какие аспекты могут принимать ваше приложение через разные пути выполнения (например, пользовательский ввод, сигналы ОС)
2) Запишите их в следующий раз, когда вы выполните приложение
3) Когда ваше приложение снова не работает, у вас есть шаги по воспроизведению сбоя в вашем журнале.
Если ваш журнал все еще не воспроизводит сбой, тогда вы имеете дело с ошибкой concurrency. В этом случае вы должны посмотреть, как ваше приложение обращается к общим переменным. Не пытайтесь записывать обращения к общим переменным, потому что вы регистрируете слишком много данных, тем самым вызывая серьезные замедления и большие журналы. К сожалению, я не могу сказать, что это поможет вам воспроизвести ошибки concurrency, потому что исследование все еще имеет долгий путь в этом вопросе. Самое лучшее, что я могу сделать, это дать ссылку на самый последний шаг (пока) в теме детерминированного воспроизведения ошибок concurrency:
http://www.gsd.inesc-id.pt/~nmachado/software/Symbiosis_Tutorial.html
С наилучшими пожеланиями
Используйте расширенный репортер аварийной ситуации. В среде Delphi мы имеем EurekaLog и MadExcept. Другие инструменты существуют в других средах. Или вы можете диагностировать дамп ядра. Вы ищете трассировку стека, которая покажет вам, где она взорвалась, как она попала туда, что в памяти и т.д. Также полезно иметь скриншот приложения, если это взаимодействие с пользователем. И информация о машине, на которой он врезался (версия ОС и исправление, что еще работает в то время и т.д.). Оба этих инструментария могут это сделать.
Если это что-то происходит с несколькими пользователями, но вы не можете воспроизвести его, и они могут, сидеть с ними и смотреть. Если это не очевидно, переключите места - вы "едете", и они расскажут вам, что делать. Таким образом вы обнаружите тонкие проблемы юзабилити. дважды щелкнуть по кнопке с одним нажатием, например, инициировать повторное включение в событии OnClick. Что-то в этом роде. Если пользователи удалены, используйте WebEx, Wink и т.д., Чтобы записать их сбой, чтобы вы могли проанализировать воспроизведение.