Como essa questão ainda está em aberto, é melhor eu avaliar.
A boa notícia é que, nos últimos cinco anos, as ferramentas de código aberto realmente amadureceram e decolaram no espaço, a má notícia é que existem muitas delas por aí.
Aqui estão os meus pensamentos: -
Jmeter vs Grinder
O Jmeter é direcionado a partir de uma especificação de estilo XML, construída por meio de uma GUI.
O Grinder usa scripts Jython dentro de uma estrutura Java com vários threads, mais orientada para programadores.
Ambas as ferramentas lidam com HTTP e HTTPS e têm um gravador proxy para você começar. Ambas as ferramentas usam o modelo do controlador para conduzir vários agentes de teste, de modo que a escalabilidade não é um problema (acesso à nuvem).
Qual é melhor:-
Uma decisão difícil, pois a curva de aprendizado é íngreme com as duas ferramentas, à medida que você entra nos requisitos de script mais complicados para reescrita de URL, correlação, fornecimento de dados exclusivos por Usuário Virtual e simulação de usuários iniciantes ou recorrentes (manipulando os Cabeçalhos HTTP).
Dito isto, eu começaria com o Jmeter, já que esta ferramenta tem muitos seguidores e existem muitos exemplos e tutoriais na Web para usar essa ferramenta. Se e quando você chegar a um 'obstáculo', isso é algo que você não pode 'facilmente' fazer com a Jmeter, dê uma olhada no Grinder. A boa notícia é que essas duas ferramentas têm o mesmo requisito Java e uma solução de 'combinação e combinação' não está fora de questão.
Algo novo a acrescentar - navegadores sem cabeça executando várias instâncias do Selenium WebDriver.
Essa é uma abordagem relativamente nova, pois depende da disponibilidade de recursos que agora podem ser provisionados a partir da nuvem. Com essa abordagem, um script Selenium (WebDriver) é obtido e executado em um navegador sem cabeçalho (por exemplo, WebDriver = New HtmlUnitDriver ()) em vários threads.
Por experiência, cerca de 25 instâncias de 'navegadores sem cabeça' podem ser executadas na Instância Pequena do Amazon M1.
O que isto significa é que todos os problemas de correlação e reescrita de URL desaparecem à medida que você adapta novamente seus scripts de teste funcional para se tornarem scripts de teste de desempenho.
A escalabilidade é comprometida, pois mais VMs serão necessárias para impulsionar a carga, em comparação com um driver HTTP, como o Grinder ou o Jmeter. Dito isso, se você deseja impulsionar 500 usuários virtuais, então, com 20 pequenas instâncias da Amazon (6 centavos por hora cada) a um custo de apenas US $ 1,20 por hora, você terá uma carga muito próxima da experiência real do usuário.