Что делать с ошибками, которые не воспроизводятся?

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

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

Что вы делаете в подобных сценариях?

Ошибка без контекста - это не ошибка, это случайность. Проблема может заключаться в вашем коде, в сторонней библиотеке, в аппаратном обеспечении или в солнечном излучении, которое заставляет мигать один бит. Если вы не можете воспроизвести его хотя бы с некоторой регулярностью (даже если только «это случается один раз каждые 10 или 20 раз, когда я делаю Х»), это не намного лучше, чем ваш тестер, говорящий вам «Что-то где-то пошло не так - исправьте это» ,

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

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

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

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

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

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

Еще несколько предложений:

1. Добавьте логирование (а не просто кейлоггер:}) в свой код продукта. Ошибки «no repro» могут быть случайными, но они могут быть повреждением памяти или состояния, которое происходит только в грязной системе, используемой непредвиденными способами (например, как компьютер клиента). Регистрация или отслеживание информации может помочь вам выяснить, что могло быть не так, когда тестер обнаружил случайность.

2. Сканирование остальных ошибок «no repro» в базе данных (или любых других, которые вы используете для отслеживания ошибок). Часто канавки слипаются в одной области продукта. Если кажется, что один компонент неисправен, просмотрите код на предмет возможных ошибок, добавьте дополнительную запись в этот компонент - или оба.

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

Я провожу тестирование большого коммерческого кода, этот раздражающий сценарий встречается слишком часто. Обычно это свидетельствует о том, что у нас нет железных процедур для сборки двоичного кода на всех платформах, которые мы поддерживаем. Таким образом, если разработчик создает свой собственный код (который он должен сделать для отладки и исправления) и не следует той же процедуре сборки, описанной в письме, существует вероятность, что системные зависшие ошибки будут магически исчезать (или появляться). , Конечно, эти вещи обычно закрываются с помощью «работает для меня» в базе данных ошибок, и, если они потерпят неудачу при следующем запуске этой проблемы, ошибку можно будет снова открыть. Всякий раз, когда я подозреваю, что ошибка может зависеть от системы, я пытаюсь проверить ее на различных платформах и сообщить, при каких условиях она возникает. Часто возникает проблема повреждения памяти, если поврежденные данные имеют достаточно большую величину, чтобы вызвать сбой. Некоторые платформы (комбинации HW и OS) могут давать сбой ближе к фактическому источнику повреждения, и это может быть очень полезно для бедного парня, который должен его отладить.

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

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

Существует два вида ошибок, которые невозможно воспроизвести:

1) Те, которые тестер (или пользователь) видел один раз, но не мог или не пытался воспроизвести.

В этих ситуациях вы должны:

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

• Поговорите с тестером / пользователем, чтобы узнать, есть ли какая-либо другая информация, которая может помочь.

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

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

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

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

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

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

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

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

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

прикрепите кейлоггер на рабочей станции этого тестера!

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

Есть эти три условия:

• Тот же бинарный
• Те же шаги
• Та же машина

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

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

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

Прежде всего, вы должны пройти строгую процедуру тестирования (но я вас понимаю, в моей компании то, что вы описали, происходит часто).

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