根据项目网站的说法，Grinder的 主要目标用户是“理解他们所测代码的人——Grinder不仅仅是带有一组相关响应时间的‘黑盒’测试。由于测试过程可以进行编码——而不是简单地脚本 化，所以程序员能测试应用中内部的各个层次，而不仅仅是通过用户界面测试响应时间。”Grinder 3的主要新功能有：
支持用于执行测试脚本的Jython脚本引擎。
由分开的源码和二进制压缩文件组成的新的发布包。
HTTP测试现在可以通过HTTP代理被管理，还有一些其他更改。
在采访中，Grinder项目领导者Philip Aston与InfoQ分享了一些关于促进新版本功能的技术决策的背景，并提供了更多的Grinder背景资料。Aston首先解释了添加脚本支持的原因：
Grinder 2广受欢迎，但是对基于属性文件的HTTP测试来说，它的脚本格式极为有限。我引入了动态脚本来支持HTTP测试脚本中的分支、循环和自定义验证。脚本语言另外一处巨大的优势是，可以直接在脚本中进行执行其他类型的测试，不需要自定义的插件。
关于为什么选定Python做为脚本语言，而不使用Java、或者其它JVM支持的脚本语言来编写测试脚本，Aston也给出了一些见解和背后的故事：
我避免使用Java做为脚本语言，是因为对于HTTP测试来说，Grinder 3的一个目标是要像Grinder 2一样使用简单。而Java单独的编译周期、类路径处理等都会妨碍这一目标。尽管这样，Jython还是可以与Java相当好地整合，并且Java代码可 以很容易地用Jython进行测试（参看脚本库中的多数例子）。
我在2001年开始Grinder 3的工作，当时Jython和Groovy是JVM脚本阵营中的佼佼者，所以我并没必要费劲地去思考。对Grinder来说，Jython已经被证实是一 个很好的选择。Python对偶尔采用的人来说，比其它大部分语言都要简单。很多Grinder用户都不是Java专家，只想对已录制的脚本做极小的修 改。而另一方面，Python对想在更高级情境中使用Grinder的开发人员来说，则是一个强大的工具；而且Jython允许现有的Java库随意地混 合在其中。
在讨论中，Aston接着分享了TCPProxy相关的详细情况——TCPProxy是一个TCP流中的代理进程，就像浏览器和服务器之间的 HTTP连接一样。Aston提到，TCPProxy可以使用Python录制测试脚本，还能识别URL参数和表单中的动态变量。他补充说，“用户通常以 录制的脚本做为开始，然后对其进行修改，以包含/更改用户帐号和使用到的其它应用数据，或者与其它脚本合并来产生覆盖混合情景的负载。”一旦测试脚本建立 起来，就能通过Grinder控制台来管理和监控这些测试脚本。
先前版本的grinder.properties文件中有大量设置，版本3减少了对这些设置的支持，因为现在这些配置可以直接在测试脚本中进行设置。他讲解了对于为Grinder 2编写的那些测试脚本，值得推荐的转换之路是：
Grinder 3有一个可以体现Grinder 2属性文件的脚本范例，但我还是建议重新录制测试脚本。脚本可以用TCPProxy重新录制，然后用与Grinder 2几乎一样的方式来重放脚本。在使用Grinder 2时，更改或扩展脚本行为的唯一方式是编写一个插件，或者在极端情况下对Grinder本身进行修改。而使用Grinder 3，几乎任何情况都可以在测试脚本内部进行。
在采访的最后，Aston提到了最近出现的3个相关项目：Grinderstone、webFlange、Grinder Analyzer——它最终给了Aston从Grinder中移除掉beta标签的信心。
