Выборка данных через AOS vs SQL Server

[mazzy]

Цитата:

Сообщение от fed

Популизмом занимаешься.

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

Цитата:

Сообщение от fed

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

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

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

Лично мне абсолютно пофигу где ошибка - в логистике, в ядре в алгоритме тестирования. Главное что она есть. И меня клиент заставит ее исправлять.

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

Цитата:

Сообщение от fed

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

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

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

Где-то тут была тема со сравнением производительности арифметических операций в ax3, ax4, ax2009. Хоть там и говорилось про время. Но важны были относительные величины, а не абсолютные.

Цитата:

Сообщение от fed

Как я могу проверить что мой код не жрет много памяти, если средство тестирования само ее ест? (И по определению довольно много памяти - это ведь штука явно посложнее модуля HR например). Так что даже если аксапту перевести на C# (Ой - не дай бог это случиться), то проблема все равно останется.

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

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

Цитата:

Сообщение от fed

А то что система с хреновым качеством релизиться (и по косвенным данным в версии 6.0 это качество еще больше упадет), так это не от того что тестируют не через .net bc, а в целом от хреновой управляемости проектом (нет владельца продукта), приделыванием непонятно кому нужных фич (которые каждый по отдельности толкает) и избытком временщиков в топ-менеджменте MBS. А это, я извиняюсь, совсем не от того что они запросы к БД напрямую пишут...

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

Но обсуждение "управляемости проектом" - точно оффтопик в этой ветке.

[mazzy]

Цитата:

Сообщение от fed

Мы с тобой о разных вещах говорим. Как тестирование организовыватся:
1. Запускается некий скрипт на C#, который пишет в БД тестовые данные.
2. Запускается другой скрипт на C#, который вызывает один или несколько классов X++ (через .net bc), которые эти данные обрабатывает.
3. Запускается третий скрипт на C#, который сравнивает получевшиеся по результатам работы классов на X++ в аксаптовской базе данные с эталонными.
4. Запускается четвертый скрипт, который подчишает результируюшие и тестовые данные. (Шаг не обязательный).

Замечательно.
Только пусть не на C#, а на X++.
В Аксапте же есть замечательный модуль UnitTesting.

Что-что? Фиговый, говоришь? В нем не хватает функционала, говоришь? Не хватает средств интеграции с VS, говоришь?

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

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

[fed]

Проблема юнит-тестов (независимо от механизма доступа к данным), состоит в том что они, условно говоря, тестируют преобразование сферического коня в вакуууме в кубического кота в аргоне. И если сценарии тестирования и тестовые данные постановщиками не были корректно составлены, то никакие юнит-тесты тут не помогут...
А комплексное тестирование - его вообще непонятно как проводить, с условием того что система может быть настроена миллионом способов и все комбинации сценариев не протестировать даже при наличии 3-5 тысяч тестировщиков.
Так что системы подобной сложности заведомо не могут быть полностью оттестированы вендорами.
В случае, скажем, Excel/IE можно просто миллионам людей в мире выдать бета-версию и надеятся на то что они там потихоньку все баги найдут и зарепортят.
Тестировать подобным образом Аксапту не получиться, поскольку во первых мало кто рискнет ставить бету приложения критического для бизнеса, во вторых - затраты организации на тестирование будут мягко говоря побольше чем на тестирование беты excel.
Так что фактически Микрософт под видом версии x.0 без сервис-паков выпускает бету и смотрит что получится.

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

[mazzy]

Цитата:

Сообщение от fed

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

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

Я чувствую что мы не переспорим друг друга.
Твое мнение - понял. Но останусь при своем.

[Maximin]

Подпишусь под каждым словом Mazzy.
От себя добавлю:
MS, конечно, тоже можно понять - разработчики не под Ax стоят заметно дешевле, и, в общем-то, разработка модуля тестирования который никому не продашь, сложно обосновывается в свете необходимости. (разве что в кач-ве доп. маркетингового аргумента, но те, кто принимает решения, обычно в разработке ПО особо не разбираются). Так что приходится забивать гвозди микроскопом и брать обыкновенных Шарперов среднего звена. Про застрявшую в середине 200х IDE и нехватку инструментальных средств я тоже промолчу. Недавно видел среду, используемую нашим Web-разработчиком - только позавидовал (Comodo кажется, что ли).
Именно нехватка этих средств и приводит к тому, что решения тестируются по-старинке, вручную.
К слову, при использовании внешнего консалтинга, мало кто хочет платить лишние деньги за какое-то ни было автоматизированное тестирование, подготовку и поддержание актуальности тестовых наборов.
Вот и получается, что внешнего спроса нет, внутренняя потребность MS удовлетворяется другими путями, результат - налицо.

[mazzy]

еще раз проапдейтил свое сообщение: Выборка данных через AOS vs SQL Server

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

[sukhanchik]

Цитата:

Сообщение от mazzy

Ну, дык пусть дорабатывают модуль, суки.

Злой ты. Но справедливый.

Если честно - я поэтому и спросил - что это такое. У меня ж в голове не укладывался тот факт, что тестировать систему можно не на самой системе. Это операционные системы пофиг на каком языке (C#, X++, VBA) тестировать. А тут-то вся фишка в коде. Если какая-нибудь функция ядра (FormDataSource.findRecord() к примеру) тормозит на больших объемах - то либо нужно рекомендовать обходной вариант (Best Practice), либо исправить в ядре, если это возможно. Сделали ж класс RecordInsertList для быстрой вставки данных. Вряд ли его тестировали "извне" .

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

[George Nordic]

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

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

Да, спасибо, что подняли тему. Надеюсь, наши аргументы будут услышаны.

С Уважением,
Георгий

[sukhanchik]

Цитата:

Сообщение от fed

Так что фактически Микрософт под видом версии x.0 без сервис-паков выпускает бету и смотрит что получится.

А еще новый офис и Windows распространяется среди сотрудников МС, которых де-факто вынуждают тестировать эти продукты. А вот АХ к сожалению так не протестируешь.

А если МС хотя бы изнутри протестировал - он бы много багов нашел, о которых и не подозревал

[fed]

Цитата:

Сообщение от sukhanchik

А еще новый офис и Windows распространяется среди сотрудников МС, которых де-факто вынуждают тестировать эти продукты. А вот АХ к сожалению так не протестируешь.

А если МС хотя бы изнутри протестировал - он бы много багов нашел, о которых и не подозревал

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

[lev]

Скажу честно, для меня новость, что Microsoft Dynamics Ax тестируется не из аксапты, а внешними какими то программами
Все равно что тестировать ладу Калину, катаясь на БМВ

[sukhanchik]

Цитата:

Сообщение от George Nordic

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

Ну... видишь ли... одно дело протестировать накатанное _сами понимаем чего_ (что кстати - может сделать и Микрософт при желании). А другое дело - всю систему. Вот как сейчас - смотришь на стиль написания кода в sys-слой - и понимаешь как надо писать. И это все-таки на порядок превышает по функционалу _сами понимаем чего_.

Кстати - если что - то исправление _сами понимаем чего_ может быть более оперативно реализовано, нежели фундаментального кода.

[sukhanchik]

Цитата:

Сообщение от fed

По моему это беда любых ERP.

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

Другое дело - что у МСа АХ не единственная система (GP, SL, NAV еще есть).
Но при желании - придумать как протестировать ту же АХ вполне возможно.

[fed]

Цитата:

Сообщение от sukhanchik

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

Другое дело - что у МСа АХ не единственная система (GP, SL, NAV еще есть).
Но при желании - придумать как протестировать ту же АХ вполне возможно.

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

[mazzy]

Цитата:

Сообщение от sukhanchik

Вот как сейчас - смотришь на стиль написания кода в sys-слой - и понимаешь как надо писать. И это все-таки на порядок превышает по функционалу _сами понимаем чего_.

Не зна-а-а-аю... За DirParty* и PrintMgmtSetup* просто убить готов... Руки кодерам/постановщикам оторвать...

[mazzy]

Цитата:

Сообщение от sukhanchik

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

Локальный - на Навике (по слухам).
В полном соответствии со своими же рекомендациями по выбору систем.

[fed]

Цитата:

Сообщение от lev

Скажу честно, для меня новость, что Microsoft Dynamics Ax тестируется не из аксапты, а внешними какими то программами
Все равно что тестировать ладу Калину, катаясь на БМВ

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

[mazzy]

Цитата:

Сообщение от fed

По секрету тебе скажу - все системы автоматизированного тестирования являются внешними программами

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

будет ли это внутренней программой (ключевое слово select, класс query на том же самом AOS, запись логов из AOS в отдельную базу как в TraceParser) или внешней программой - не важно. Важен механизм доступа (select/query - один механизм, прямой запрос/connection - другой механизм).

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

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

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

[sukhanchik]

Цитата:

Сообщение от fed

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

Ну это уже лучше чем ничего. В целом - конечно согласен.

Цитата:

Сообщение от mazzy

Не зна-а-а-аю... За DirParty* и PrintMgmtSetup* просто убить готов... Руки кодерам/постановщикам оторвать...

Да я еще в сладких грезах в 4.0/3.0 . Хотя за этот многочисленный распил таблиц на более мелкие - тоже б руки оторвал.

Цитата:

Сообщение от mazzy

Локальный - на Навике (по слухам).
В полном соответствии со своими же рекомендациями по выбору систем.

Ну тогда АХ "попала" из-за того, что у МСа не одна система. Не могут же МСы работать сразу во всех системах, которые купили.

[Maximin]

Кстати, о доступе из Axapta к SQL - как я мог забыть!!!.
Мы столкнулись, что при использовании определенного запроса из Ax, ничем особым не выделяющимся, на SQL сервере 2005 "течёт" tempdb, по 8Кб на запись, причем только если SQL версии >SP1. В результате, отгрузки более, чем на 500 строк начинали жутко тормозить, т.к. размер tempdb вырастал до 2+ Гб и появлялись многочисленные PAGE_LOCKS. Отловили только после ручного прохождения всего кода, что использовался и одновременном мониторинге SQL сервера.
Вылечили, слегка видоизменив запрос (скорее, даже выкинув этот кусок - он был некритичен для нас, это был автоподбор отгрузок по клиенту/и пр. признакам).