testing - сделать - отличие debug и release c++




Раздельные сборки 'debug' и 'release'? (13)

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

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

Часть, в которой вы поступили неправильно, - это утверждение:

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

Разработчики не проверяют код. Тест-код.

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

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

Я думаю, что лучше выпустить версию программного обеспечения, которое ваши разработчики действительно тестировали; Поэтому я стараюсь удалить цель «debug» из файла project / makefile, так что есть только одна версия, которая может быть построена (и протестирована, и отлажена, и выпущена).

По той же причине я не использую «утверждения» (см. Также « Утверждения всегда плохие? ...).

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

Кто-то еще сказал, что «это такая плохая идея»; это политика, которую я разработал несколько лет назад, будучи сожжен:

  • Некоторые разработчики тестируют свои отладочные, но не выпускающие версии
  • Некоторые ошибки разработчиков, которые появляются только в версии выпуска
  • Компания выпустила версию релиза после неадекватного тестирования (действительно ли это полностью соответствует?)
  • Призыв к отладке версии выпуска

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

Какова ваша политика?


В моей компании у нас есть как Debug, так и Release. - Разработчики используют отладочную версию для правильного поиска и исправления ошибок. - Мы используем TDD, поэтому у нас есть большой набор тестов, который мы запускаем на нашем сервере, который тестирует как конфигурацию отладки, так и выпуск, а также сборки 64/32, которые у нас есть.

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


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

На стороне плюса с использованием отладочных версий:

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

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

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

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


Наша политика заключается в том, чтобы разработчики работали над сборками Debug, но EVERYONE else (QA, BAs, продажи и т. Д.) Запускает версию. Вчера мне пришлось исправить ошибку, которая появилась только в релизе, она была очевидна, что происходило просто ПОТОМУ ЧТО это только появилось в выпуске

Это первый в этом магазине, и я здесь уже 18 месяцев.

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

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


По моему мнению, в этой дискуссии отсутствует очень важный момент:

Это действительно зависит от того, какой проект это!

Если вы создаете собственный (C / C ++) проект, вы будете вынуждены создавать отладочные сборки просто потому, что оптимизация компилятора может сделать отладку почти невозможной в некоторых случаях.

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

Хотя собственный проект на C ++ и веб-приложение PHP, очевидно, не все виды проектов, которые существуют, я надеюсь, что мой вопрос перевернулся.

PS: При разработке для C # вы сталкиваетесь с пограничным случаем, поскольку, хотя использование отладочной сборки отключает оптимизацию компилятора, по моему опыту вы не столкнетесь с почти такими же различиями, как с C ++


Смотрите это Что ваше самый противоречивое мнение программирования?

цитата:

Мнение: никогда не бывает другого кода между сборками «debug» и «release»

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


Согласно моему ответу в связанном потоке, мы также используем ту же самую сборку для отладки и выпуска по очень похожим причинам. Прирост 10% -20% от оптимизатора, как правило, очень незначительный по сравнению с ручными оптимизациями на уровне алгоритма. Одна сборка удаляет множество потенциальных ошибок. В частности,

  • Неинициализированные переменные и небольшие переполнения буфера могут привести к совершенно другим результатам в отладочных и оптимизированных версиях.

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

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


Это компромисс. Учитывая, что циклы CPU дешевы и дешевле, а человеческие циклы остаются дорогостоящими, имеет смысл поддерживать только одну версию большой сложной программы - отладочной (gable) версии.

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


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

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

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


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

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


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

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


здесь мы развиваемся в режиме отладки и выполняем все модульные тесты в режиме выпуска. мы являемся небольшим магазином с несколькими (до 12) приложений для поддержки от классических ASP, ASP.Net, VB.Net и C #. У нас также есть преданный человек для обработки всех тестов, отлаженные проблемы отбрасываются разработчикам.





release-management