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

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

Для случайных падений с поля, иногда вы просто не можете их воспроизвести. Я отлаживал редкие состояния гонки и «невозможные» сбои с помощью посмертных аварийных отказов, собранных службой отчетов об ошибках Microsoft Windows. Я думаю, что гуру Microsoft Раймонд Чен называет это «экстрасенсорной отладкой».

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

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

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

Это не было.

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

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

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

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

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

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

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

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

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

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

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

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

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

Good Manager : «Что вы делаете?»

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

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

Против:

Менеджер зад-шляп : «Что ты делаешь?»

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

Менеджер задниц :« Нет, у нас нет времени. Просто исправь это и откатись назад. Вы ответили на электронное письмо о встрече? Мне нужно идти - мне нужно 10 со Стивом. Хорошо. А, откатите это назад, а затем пошлите это электронное письмо. "

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

От макушки головы:

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

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

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

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

Я нахожу, что идея не репродуцирования ошибки фиксирует его не что иное как причудливый.

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

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

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

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

, Если Вы не делаете репродукции, затем Вы

• экономите время теперь, но
• подвергаются риску

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

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

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

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

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

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

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

Единственный случай, где Вы не должны воспроизводить его локально, - когда это неосуществимо. Возможно, этому нужно ПАРТИЯ из данных, собственных данных, аппаратных средств, или возможно это требует более сложной установки, чем Вы имеете.

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

Вы всегда должны ПОПЫТКА . Необходимо определить, является ли это ошибка, ошибка или дефект. Как можно продолжить фиксировать или смягчать проблему с пониманием его?

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

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

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

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

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

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

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

2. дефект может быть воспроизведен программно (например, с Perl или сценарием Python)? Если так, у команды QA должен, вероятно, быть автоматизированный тестовый сценарий, который покрывает ее и может быстро использоваться для проверки.

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

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

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

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

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

• забирание фиксации и наблюдение, если ошибка капризничает снова
• откладывание фиксации в и наблюдение, если ошибка исправлена снова

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

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

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

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

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

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

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

1. Обнаружить неисправность.
2. Остановить.
3. Исправить или исправить немедленное состояние.
4. Выявить основную причину и установить меры противодействия.

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