Как Вы приближаетесь к неустойчивым ошибкам? [закрытый]

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

, Как перейти к сути дела, где Вы понимаете ошибку?

Инструментуют кодекс (журнал как сумасшедший). Работайте со своим QA - они способны воссоздавать проблему, и Вы должны договориться иметь полный dev набор инструментов в наличии для Вас на их машинах. Используйте автоматизированные инструменты для неинициализированной памяти/ресурсов. Просто уставитесь на кодекс. Никакое легкое решение там.

Эти проблемы всегда вызывались:

1. проблемы Памяти
2. проблемы Пронизывания

, Чтобы решить проблему, Вы должны:

• Инструментуют Ваш кодекс (Добавьте отчеты журнала)
• Кодовый Обзор, пронизывающий
• Кодовое распределение памяти Обзора / dereferencing

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

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

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

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

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

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

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

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

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

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

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

В этой ситуации, где ничто иное не работает, я ввожу дополнительную регистрацию.

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

Иногда я добавляю в прилавках производительности... Я поместил те данные в таблицу и взгляд на тенденции.

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

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

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

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

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

Некоторые вопросы Вы могли спросить себя:

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

, Если бы кодекс никогда не работал, подход отличался бы естественно.

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

Определенный сценарий

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

проблема происходит, когда пользователь взаимодействует с пользовательским интерфейсом (TabControl, чтобы быть точным) в конкретной фазе процесса. Это не всегда происходит, и я полагаю это вызвано тем, что, что окно времени для проблемы, которая будет показана, маленькое. Мое подозрение - то, что инициализация UserControl (мы находимся в .NET, с помощью C#) совпадает с государственным событием изменения от другой области применения, который приводит к располагаемому шрифту. Между тем другой контроль (Маркировка) пытается нарисовать свою последовательность с тем шрифтом и следовательно катастрофу.

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

Подход

Мой подход был первым, чтобы посмотреть на трассировку стека из наших отчетов о катастрофе и исследовать кодекс Microsoft с помощью Отражателя. К сожалению, ведомый к GDI + звонит с небольшой документацией, которая только возвращает число для ошибки - .NET превращает, это в довольно бесполезное сообщение, указывающее на что-то, недействительно. Отличный.

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

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

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

Заключение

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

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

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

я думаю, что Вы совершенно правы, чтобы касаться подхода Вашего colleuge.

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

Вот некоторый опасный кодекс в c:

const int NITER = 1000;
int thread_unsafe_count = 0;
int thread_unsafe_tracker = 0;

void* thread_unsafe_plus(void *a){
  int i, local;
  thread_unsafe_tracker++;
  for (i=0; i<NITER; i++){
    local = thread_unsafe_count;
    local++;
    thread_unsafe_count+=local;
  };
}
void* thread_unsafe_minus(void *a){
  int i, local;
  thread_unsafe_tracker--;
  for (i=0; i<NITER; i++){
    local = thread_unsafe_count;
    local--;
    thread_unsafe_count+=local;
  };
}

, с которым я могу проверить (в pthreads enironment):

pthread_t th1, th2;
pthread_create(&th1,NULL,&thread_unsafe_plus,NULL);
pthread_create(&th2,NULL,&thread_unsafe_minus,NULL);
pthread_join(th1,NULL);
pthread_join(th2,NULL);
if (thread_unsafe_count != 0) {
  printf("Ah ha!\n");
}

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

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

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

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

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

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

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

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

Я использую то, что я называю «тяжелая оборона стиля программирование» : добавляют, утверждает во всех модулях, который кажется связанным проблемой. То, что я имею в виду, добавляют, что МНОГО из утверждает , утверждает доказательства, утверждайте государство объектов во всем их memebers, утверждайте, что государство «environnement», и т.д.

Утверждает помощь, Вы определяете кодекс, который НЕ связан с проблемой.

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

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

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

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

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

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