Цитата:
Сообщение от
fed
Популизмом занимаешься.
Как скажешь.
Я думаю, что высказал свое личное мнение и свою личную озабоченность происходящим.
Цитата:
Сообщение от
fed
Во первых - если при тестировании логистики вылезут ошибки .net bc, то логистика ведь тоже не оттестируется нифига, правда ? Могу предположить что в такой ситуации по полной программе вставят комманде .net bc, но в результате логистику зарелизят неоттестированой (потому что ждали починки .net bc вместо того чтобы тестировать).
Если честно, то плевать какой команде вставят.
Меня сильно волнует, что в логистике вылезают ошибки.
Если честно, то лично меня не устраивает механизм тестирования, который сильно отличается от стандартного механизма. Потому что сам механизм тестирования может содержать баги. Как и ядро может содержать баги.
Лично мне абсолютно пофигу где ошибка - в логистике, в ядре в алгоритме тестирования. Главное что она есть. И меня клиент заставит ее исправлять.
Лично я хочу видеть максимально похожий на стандартный механизм тестирования.
Только так я могу быть уверен, что разработчик получает при тестировании те же ошибки, что и я.
Только так я могу быть верить разработчикам (хоть с какой-то степенью).
Цитата:
Сообщение от
fed
Во вторых - то что средство тестирования и тестовая среда должны быть разделены - это некоторый очевидный постулат. Как я могу померить производительность системы, если средство измерения само съедает тики?
Во-первых, это проблемы разработчиков
Во-вторых, во ходе замеров производительности никогда не оперируют абсолютными числами. Оперируют некими попугаями.
операция сложения - столько то попугаев.
операция деления - столько то попугаев.
операция доступа к записив базе - столько то попугаев.
а вот этот тривиальный алгоритм выборки суммы вдруг отжирает в несколько сот попугаев больше. значит надо разбираться с алгоритмом.
Где-то тут была тема со сравнением производительности арифметических операций в ax3, ax4, ax2009. Хоть там и говорилось про время. Но важны были относительные величины, а не абсолютные.
Цитата:
Сообщение от
fed
Как я могу проверить что мой код не жрет много памяти, если средство тестирования само ее ест? (И по определению довольно много памяти - это ведь штука явно посложнее модуля HR например). Так что даже если аксапту перевести на C# (Ой - не дай бог это случиться), то проблема все равно останется.
Во-первых, это проблема разработчиков.
Во-вторых, это не повод использовать для валидации какие-то левые механизмы (см. первое сообщение в этой ветке
)
В-третьих, тут также важны относительные значения. Вот этот алгоритм - столько то канареек, а вот этот в сотни раз больше.
Ну, не хочешь же ты сказать, что средство тестирования жрет память неконтролируемо. Ни за что не поверю.
Цитата:
Сообщение от
fed
А то что система с хреновым качеством релизиться (и по косвенным данным в версии 6.0 это качество еще больше упадет), так это не от того что тестируют не через .net bc, а в целом от хреновой управляемости проектом (нет владельца продукта), приделыванием непонятно кому нужных фич (которые каждый по отдельности толкает) и избытком временщиков в топ-менеджменте MBS. А это, я извиняюсь, совсем не от того что они запросы к БД напрямую пишут...
ну, прямые запросы к БД пишут по той же самой причине. Нормальный руководитель никогда бы такого не допустил.
Но обсуждение "управляемости проектом" - точно оффтопик в этой ветке.