Должны ли мы всегда воспроизводить ошибки для проверки исправлений?

Ответ 1

Если вы не воспроизвели ошибку, ваше "исправление" не лучше, чем предположение.

Ответ 2

Сверху моей головы:

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

Ответ 3

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

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

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

Ответ 4

Характер ошибки также под вопросом:

• Можно ли быстро восстановить дефект с помощью unit test? Если это так, разработчик, работающий над исправлением, должен написать упомянутый unit test, интегрируя его в более полный набор регрессии. Это гарантирует, что будущая работа не повторяет дефект.

• Можно ли программно воспроизвести дефект (например, с помощью Perl или Python script)? Если это так, команда QA, вероятно, должна иметь автоматизированный тестовый сценарий, который его охватывает, и его можно быстро использовать для проверки.

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

Эти три принципа очень помогают управлять процессом QA в моей тестовой команде.

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

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

Ответ 5

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

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

Ответ 6

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

В этом случае вы создаете тест, демонстрирующий ошибку. Тест не работает.

Исправлена ​​ошибка. Тест проходит. Как и все другие тесты. Вы действительно исправили ошибку, не создавая других проблем.

Ответ 7

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

Если вы не воспроизводите, то вы

• сэкономить время/усилие, но
• нести риск

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

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

Ответ 8

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

Ответ 9

Я прочитал хорошую книгу об отладке, которая рекомендовала не только воспроизвести ошибку, но и после ее исправления:

• удаление исправления и просмотр, если ошибка снова активируется.
• вернем исправление и посмотрим, исправлена ​​ли ошибка снова.

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

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

РЕДАКТИРОВАТЬ: Я работал в месте, где владелец очень расстроен в отношении ошибок, которые, как утверждается, были исправлены, но не были. Это произошло потому, что хотя я (или другой разработчик) смог воспроизвести ошибку, я не воспроизвел ее точно так же, как это сделал тестер. Мало того, что вы должны воспроизвести ошибку, но , вы должны убедиться, что вы воспроизводите ошибку так же, как тестер сделал.

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

Ответ 10

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

Как это будет разрешено для записи или набора тестов? Соответствующий статус
- "Исправлено", "Открыть", "Невозможно воспроизвести", "Не исправить", "Функция"?

Если вы не можете воспроизвести его, все еще нужно сделать desicion, позволяя ему дрейфовать в /dev/null, просит его вернуться и укусить вас.

Ответ 11

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

Хороший менеджер: "Что вы делаете?"

Хороший разработчик: "Мы снова получили эту ошибку. Я перестраиваю тестовую среду, чтобы мы могли ее воспроизвести".

Хороший менеджер: "WTF?" Я подумал, что Дэйв сказал, что он это исправил? Эй, Дейв, ты не исправил эту ошибку? Почему мы снова тратим наше время на это?

Versus:

Ass-hat Manager: "Что вы делаете?"

Хороший разработчик: "Мы снова получили эту ошибку. Я перестраиваю тестовую среду, чтобы мы могли ее воспроизвести".

Ass-hat Manager: "Нет - у нас нет времени. Просто исправьте его и отбросьте назад. Вы ответили на письмо о встрече? Я должен идти - мне нужно 10 с Стивом. Хорошо. Ах, отбросьте это назад, и отправьте его по электронной почте.

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

Ответ 12

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

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

Ответ 13

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

• Используете ли вы инструмент автоматического тестирования (например, инфраструктуру xUnit, Fit/Fitnesse и т.д.)?
• Используете ли вы автоматизированный процесс сборки?
• Этот процесс автоматической сборки вызывает тесты и записывает результаты?

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

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

Для моего проекта мы используем подрывную функцию для управления версиями, Jira для управления деятельностью, Hudson for builds, Fitnesse и MSTest для тестирования. Все они связаны друг с другом, используя непрерывную интеграцию. Fitnesse принимает приемочные тесты и MSTest модульное тестирование, и они запускаются автоматически каждый раз, когда выполняется сборка, чтобы дать нам количественный показатель того, насколько "хороша" сборка.

Ответ 14

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

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

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

Вот почему вы воспроизводите проблему.

Ответ 15

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

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

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

Ответ 16

да, когда это возможно/возможно; см. Регрессионное тестирование

Ответ 17

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

Например, у клиентов возникла ошибка связи с проектом, над которым я работал. Мы охотились через код, чтобы исправить любые возможные ошибки. Одна ошибка включала ошибку ASIC в микропроцессоре PIC, а исправления обложек обеспечивали обходное решение, которое мы реализовали. Затем один из моих коллег преодолел крайние меры, чтобы воспроизвести ошибку, чтобы он мог утверждать, что проблема наших клиентов была, вероятно, исправлена.

Это не так.

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

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

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

Ответ 18

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

Я особенно согласен с тем, что касается разработчиков и QA, включая проверки. Это часть японского вызова Jidoka (что означает "автоматизация с человеческим прикосновением" ):

[...] Автономность предотвращает производство дефектных изделий, устраняет перепроизводство и фокусирует внимание к пониманию проблемы и гарантировать, что он никогда не повторится. Это является процессом контроля качества, который применяет следующие четыре принципа:

• Обнаружение ненормальности.
• Стоп.
• Исправить или исправить ближайшее условие.
• Исследуйте основную причину и установите контрмер.

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

Ответ 19

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

• Изменение конфигурации, отключение некоторой части логики и т.д. при производстве - временное решение.

• Нам нужно убедиться, что продукт является надежным и отвечает требованиям клиентов, тестируя его локально, Cross-device (Mobile, tablet и т.д.) и кросс-платформенное (Firefox, Chrome, Internet Explorer) тестирование также важную роль здесь.

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

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

• Как вы упомянули, что ошибки исправляются (т.е. не воспроизводятся), изменяя конфигурацию, отключая часть логики и т.д. Но если клиент имеет ту же конфигурацию, что и для времени, когда вы меняетесь, это на самом деле будет большой проблемой, поэтому Cross-device (Mobile, tablet etc) и кросс-платформенное (Firefox, Chrome, Internet Explorer) тестирование очень важно.

Ответ 20

Для случайных сбоев из поля иногда их просто невозможно воспроизвести. Я отлаживал редкие условия гонки и "невозможные" сбои, используя postmortem crashdumps, собранные службой отчетов об ошибках Microsoft Windows. Я думаю, что гуру Microsoft Raymond Chen называет эту "психическую отладку".

Если ваша компания предоставляет программное обеспечение Windows (С++ или .NET) для общественности, я настоятельно рекомендую использовать службу отчетов об ошибках Microsoft Windows (WER). Это бесплатно, даже для коммерческих программных компаний. Это проще, чем создавать собственные отчеты об ошибках и службу сбора аварийных сообщений. WER даже сопоставляет все трассировки стека, поэтому вы знаете, какие сбои являются дубликатами, что полезно, если вы не чувствуете, что отлаживаете тысячи дубликатов сбоев.:)

Ответ 21

Попытайтесь уволить своего менеджера из-за его глупости и получить его работу, это может быть возможность!

Ответ 22

Возможно повторить то, что уже написано, но ДА!!! Обоснование: только найти ошибку один раз. Если вы можете написать тест, который повторяет ошибку, вам не придется вручную проверять его снова - ваш автоматический тест найдет его.
Итак, вы исправляете ошибку, и можете быть в безопасности, зная, что ваше программное обеспечение никогда не пострадает от этой ошибки снова. Это хорошо. Это сэкономит вам время. Это сэкономит вам деньги.

Ответ 23

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