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

все это демагогия.
интересуют методы.
я тестирую так:

1) Создаем абонента 222 в freepbx
2) добавляем sipp
[sipp]
host=192.168.0.83 ;адрес машины с sipp
port=5070
type=friend
context=sipp
canreinvite=no
disallow=all
allow=ulaw
call-limit=1000

3) делаем ему перенаправление, к примеру, на номер 333
database put CF 222 333
4) делаем контекст
[sipp]
exten => _X.,1,Dial(LOCAL/222@ext-local)

5) добавляем в from-internal-custom
exten => 333,1,Dial(SIP/sipp/100)

6) запускаем sipp
sipp -rtp_echo -mi 192.168.0.83 -sf uac_pcap.xml 192.168.0.5 -d 20000 -s 100 -rp 2000 -r 5 -i 192.168.0.83 -l 300 -trace_stat

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

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

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

ИМХО:

софту достаточно тестирования на чистоту логики и процессов - чтобы все работало "как часики" не съедая все ресурсы.. Таким путем можно установить предел нагрузки и честно предупреждать об этом клиента (сбросив процентов 20:)

а железо - под * ведь используется в большинстве случаев обычная бытовая техника, сделанная в Китае, подчас "на дому".. на нее даже производитель, если его реально найти, не даст 100% гарантии..

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

конечно получаю. Но за время кризиса (до июня) проектов небыло, зато появился новый дистриб. Не всю же жизнь сидеть на астере 1.2.

svoy:

...софту достаточно тестирования на чистоту логики и процессов - чтобы все работало "как часики" не съедая все ресурсы..

в этом и проблема. Под нагрузкой память утекает. И на trixbox 2.4 и на 2.6 и на 2.8 и на эластиксе 1.6. (разнообразия ради протестил. Элакстик так вообще в ступор входит через полчаса после работы, а триксы - терпят до последнего свободного байта)

svoy:

а железо - под * ведь используется в большинстве случаев обычная бытовая техника, сделанная в Китае, подчас "на дому".. на нее даже производитель, если его реально найти, не даст 100% гарантии..

я ширпотреб не использую. токо пром. железо. Для мелких систем требования попроще.

svoy:

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

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

Вот с этих проектов и получи информацию о реальной эксплуатации своих систем.

>> в этом и проблема. Под нагрузкой память утекает. И на trixbox 2.4 и на 2.6 и на 2.8 и на эластиксе 1.6. (разнообразия ради протестил.

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

switch, у вас ведь есть собственные разработки веба, почему бы на голой * это не сделать?

Alekz, это не серьезно...

Собственные разработки надо еще до ума довести, оттестировать наконец!
сырой продукт продавать низя.

Если это серьезно, удачи!