кстати да, насчёт тестирования... больная тема, однако. вот привезли кучу железа. перед тем, как я начинаю проводить наши специфические тесты железа и софта, есть необходимость тестирования самого железа. то есть, тупые стандартные тесты на температуру проца, на проверку памяти, на скорость чтения с диска и т.п. наши программисты соорудили для этой цели совершенно ниибическое нечто (я это даже описать не могу) из кучи отдельных фриварных программ, которые надо запускать все отдельно, которые имеют разные интерфейсы (да ещё и графические!), совершенно не запускаются из командной строки, имеют странные форматы вывода результатов. и вот это сборище мелких тестов чего попало наши тестеры должны прогонять на всех машинах. а их иногда десятки. я считаю, что неразумно это - тратить столько времени на такой мудизм. а у меня нет времени, чтобы рыться в сети и искать удобные утилиты. на меня сейчас ещё 64-битные драйверы свалились, кроме прочего софта по железу... не подскажешь по делу: нет ли какой фриварной (ну или хрен с ним, даже хорошо сломаной) сотфины под венду, которая бы тихо-мирно, из командной строки запускала базовые тесты на устойчивость железа и выдавала скромные, но читабельные результаты?
Бгвахаха, за такое поделие купить старпонов для разных интерфейсов и ебсти с пробором.
Чтоб программисты не смогли прикрутить интерфейс? Ебсти начальника их или вашего постановщика задачи.
Айронбаг, мы не продакшн, мы разработка, нам надежность неважна, нам критична только производительность. Я по железу ноль полный, поэтому не посоветую ничего.
Как инфраструктурщики разработки мы делали так: - если железо дрянь - комитили конфиги в svn и клали болт на надежность. - если нет - удовлетворялись заводскими тестами вшитыми в биос и все равно коммитили конфиги.
Чтоб оценить глубину грехопадения - все наши железки работают на нулевых рейдах. Из 5 устройств минимум.
просто у нас задачи на пару порядков сложнее. с типовыми тестами некогда возиться, если честно. да и некому этим заняться. тестеры и сборщики заняты продукцией. а вот используемые материнки и процы тестируются абы как, причём это отнимает кучу времени и никто этим заниматься не хочет. отдел программистов говорит, что это железо, а наш отдел аппаратного обеспечения говорит, что это софт - ибо нам на не наше железо по барабану и его программисты под свои нужды выбирают :) вот и выходит, что "у семи нянек..." увы, у нас нельзя так просто отделаться от глюков железа. у нас не софт, а управление очень скоростными риалтаймовыми процессами и отказ аппаратуры означает существенный ущерб для заказчика, простой производства и даже иногда поломку дорогой механики. так что тестируется по возможность всё. конечно, генеральные тесты всей системы проводятся по сто раз, но так как в системе может быть,к примеру, больше 60 вычислителей, а в каждом стоят мамки, процы, память, бла-бла-бла... и если где-то есть мелкий сбой - хрен найдёшь! а система должна работать на полном ходу целыми днями напролёт. и потом усираться искать такие глюки весьма накладно. плюс ещё режимные предприятия, пропускная система, первые отделы... внос-вынос любой хренотени - это чуть ли не через разрешение от самого главного, с кучей бумаги. поэтому и хочется заоптимизировать хотя бы простые, базовые тесты. так как я на своём уровне проблему понимаю, но времени решить её у меня просто не хватает.
кстати да, насчёт тестирования...
ОтветитьУдалитьбольная тема, однако. вот привезли кучу железа. перед тем, как я начинаю проводить наши специфические тесты железа и софта, есть необходимость тестирования самого железа. то есть, тупые стандартные тесты на температуру проца, на проверку памяти, на скорость чтения с диска и т.п. наши программисты соорудили для этой цели совершенно ниибическое нечто (я это даже описать не могу) из кучи отдельных фриварных программ, которые надо запускать все отдельно, которые имеют разные интерфейсы (да ещё и графические!), совершенно не запускаются из командной строки, имеют странные форматы вывода результатов. и вот это сборище мелких тестов чего попало наши тестеры должны прогонять на всех машинах. а их иногда десятки. я считаю, что неразумно это - тратить столько времени на такой мудизм. а у меня нет времени, чтобы рыться в сети и искать удобные утилиты. на меня сейчас ещё 64-битные драйверы свалились, кроме прочего софта по железу... не подскажешь по делу: нет ли какой фриварной (ну или хрен с ним, даже хорошо сломаной) сотфины под венду, которая бы тихо-мирно, из командной строки запускала базовые тесты на устойчивость железа и выдавала скромные, но читабельные результаты?
Бгвахаха, за такое поделие купить старпонов для разных интерфейсов и ебсти с пробором.
ОтветитьУдалитьЧтоб программисты не смогли прикрутить интерфейс? Ебсти начальника их или вашего постановщика задачи.
Айронбаг, мы не продакшн, мы разработка, нам надежность неважна, нам критична только производительность.
Я по железу ноль полный, поэтому не посоветую ничего.
Как инфраструктурщики разработки мы делали так:
- если железо дрянь - комитили конфиги в svn и клали болт на надежность.
- если нет - удовлетворялись заводскими тестами вшитыми в биос и все равно коммитили конфиги.
Чтоб оценить глубину грехопадения - все наши железки работают на нулевых рейдах. Из 5 устройств минимум.
просто у нас задачи на пару порядков сложнее. с типовыми тестами некогда возиться, если честно. да и некому этим заняться. тестеры и сборщики заняты продукцией. а вот используемые материнки и процы тестируются абы как, причём это отнимает кучу времени и никто этим заниматься не хочет. отдел программистов говорит, что это железо, а наш отдел аппаратного обеспечения говорит, что это софт - ибо нам на не наше железо по барабану и его программисты под свои нужды выбирают :) вот и выходит, что "у семи нянек..."
ОтветитьУдалитьувы, у нас нельзя так просто отделаться от глюков железа. у нас не софт, а управление очень скоростными риалтаймовыми процессами и отказ аппаратуры означает существенный ущерб для заказчика, простой производства и даже иногда поломку дорогой механики. так что тестируется по возможность всё. конечно, генеральные тесты всей системы проводятся по сто раз, но так как в системе может быть,к примеру, больше 60 вычислителей, а в каждом стоят мамки, процы, память, бла-бла-бла... и если где-то есть мелкий сбой - хрен найдёшь! а система должна работать на полном ходу целыми днями напролёт. и потом усираться искать такие глюки весьма накладно. плюс ещё режимные предприятия, пропускная система, первые отделы... внос-вынос любой хренотени - это чуть ли не через разрешение от самого главного, с кучей бумаги.
поэтому и хочется заоптимизировать хотя бы простые, базовые тесты. так как я на своём уровне проблему понимаю, но времени решить её у меня просто не хватает.