"Плавающие" ошибки. Что с ними делать?

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

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

С другой стороны "забывать" о таких проблемах тоже нельзя.

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

Спасибо, за внимание.

#2 greesha

ФИО: Печёнкин Григорий Михайлович
Город: Мытищи

Как раз вчера такую поймали. Гонялись неделю. Какой-то корейский умник написал собственную версию стандартной функции atoi (с дополнительным параметром) и вставил её в один из драйверов. При линковке вместо функции из stdlib подставлялся вызов этой функции, дальше - лотерея (возвращаемый результат зависит от состояния стека и процентах в 99,9 случаев оказывается правильным).

У нас это выглядело так: версии 5.19 и 5.21 приложения работает корректно, версия 5.20 при попытке установить TCP соединение использует неправильный номер порта, причём только в том случае, когда этот номер четырёхзначный (отрезает последнюю цифру). При включении отладки ошибка пропадает. Более того, она пропадает при малейшей попытке что-то изменить в коде (добавить переменную, вставить вызов любой функции и т. п.).

Как такие случаи регистрировать? Просто занесли в bug трекер, и там вели историю всех наших догадок и предположений (вплоть до ошибки в компиляторе :) ). Главное правило - не закрывать баг до тех пор, пока точно не выяснена его причина. Есть ещё пара таких запросов, висят в трекере уже около года.

#3 Darkus

Город: Казахстан, г.Астана

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

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

#4 Case

ФИО: Панкратов Вячеслав
Город: Украина, Киев.

Не всегда спасает.

Зачастую такие интеерсные наведённые баги возникают если пользователь А сделал АВС, пользователь В сделал БСА и симстема в этот момент производила КВАПР - то есть сумма факторов и не всегда завязанная только на действия одного пользователя.

#5 Darkus

Город: Казахстан, г.Астана

#6 LeshaL

ФИО: Алексей Лянгузов
Город: Saint-Petersburg

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

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

С другой стороны "забывать" о таких проблемах тоже нельзя.

Да есть такие противные ошибки. Сейчас предстоит одну такую разоблачать. Как я понимаю, речь не о каком-то одноразовом глюке, а об ошибке которая время от времени проявляется.Обычно веду себя так:1) При появлении ошибки, также как и вы запоминаю ее всторонке.2) Потом, когда все очевидные вещи записаны в дефект-трэкер, пытаюсь найти алгоритм воспроизведения. Или причину, например была одна - как оказалось, воспроизводилась только на одном определенном линуксовом хосте - какие-то на нем старые библиотеки ядра были.2а) Заношу проблему в дефект-трэкер с пометкой not 100% reproducible.3а) Если алгоритм нашелся - ура! Добавляю алгоритм и комент - Try to repeat actions 5-10 times.3б) Иначе, если ошибка имеет какое-либо явное указание на место где она произошла (типа брошен exception) заношу в дефект-трэкер как можно больше информации (логи, описание environment итд). Ребята разберутся по стэк-трейсу почему вообще такое возможно.3в) Совсем плохой случай - проблема есть, чего-го где-то перестает работать молча. В этом случае - иду к разработчикам и мы совместно пытаемся воспроизвести проблему. Иногда приходится добавлять в код дополнительное логирование, как здесь уже писали. Иногда при совместном воспроизведении разработчики понимают что может служить причиной.

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

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

📎📎📎📎📎📎📎📎📎📎