История изменений

Проекты все одинаковые, и если ты гонишь обычный смок-тест или регрешен

и при чем тут это? тестирование производительности - отдельный вид тестирования

И что ты же ты замеришь? Ну вот что?

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

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

Проекты все одинаковые, и если ты гонишь обычный смок-тест или регрешен

и при чем тут это? тестирование производительности - отдельный вид тестирования

И что ты же ты замеришь? Ну вот что?

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

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

Проекты все одинаковые, и если ты гонишь обычный смок-тест или регрешен

и при чем тут это? тестирование производительности - отдельный вид тестирования

И что ты же ты замеришь? Ну вот что?

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

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