值得关注ThoughtWorks 开发的这个web验收测试框架。

想请问各位，你们使用selenium是用的哪种模式？TestRunner or Driven？使用TestRunner的话，每增加一个testcase，就需要增加一个测试页面，并更新testsuite页面，项目组中你们是如何保证这个过程规范化的呢？？而如果使用Driven模式的话，考虑到很多应用都在部署时需要配置容器的连接池、数据源等，所以不能采用内置的jetty作为web服务器，而且，jetty好像也不支持ear方式的部署吧？所以就只能采用adjacent web server或Remote web server方式，可是，这两种方式都要一个selenium proxy，请问谁有配置这个selenium proxy的资料或经验呢？？

very cool .
决定使用它了。 因为它的扩展比较容易。
原来的ajax支持不是很好的，扩展一些函数后一切都ok。先试着用一段时间，看看实际效果。

搞定了？星期一试用

这么久都没有人，回答我的问题，郁闷。另外，发现selenium不支持frame框架的web应用；也不知道selenium如何支持activex控件的测试。唉，到底还用不用selenium呢？？

firebody
你写的框架如果基于Fit开发，不是效率更快吗？
Fit并不像你所说的那么差劲。其主要功能还是解决测试数据的表达问题。至于如何与实际系统地连接完全是独立的。你完全可以自己实现一套fixture来完成与webwork的连接工作以达到业务规则的测试。当你不采用webwork，只需调整相应的fixture，如同你需要重新调整你的现有测试框架以适应新的web框架。甚至同一套Fit Table在少量修改的前提下，可以针对不同层进行测试，只需要开发相应层次的Fixture，例如针对业务规则层的fixture，针对Web表示层的fixture等。当然涉及数据库访问的的确是比较麻烦的地方。

应该说Fit要拿来现用时不那么实际的，但是提供了相当好的扩展功能。将测试数据的表示，实际的测试运行等过程通过Fit Table和Fit Fixture完全解耦。

最近开始维护一套很早开发J2EE的系统，开发时连Struts都还没有，外方自己设计一套框架，层次性上不那么清晰。我尝试用Fit的表示+HttpUnit实现模拟操作的fixture，感觉开发方便，测试人员对于Fit的表达方式更容易接受。至少比起之前一套基于XML的表达是好得多。

对的。但是那套fixture代码不知道工作量是否打了些呢？

自己开发的模拟Web操作的fixture工作量不大，本质就是将测试数据的用户动作转换成HttpUnit的方法，时间更多是花在结果的判断上，因为从HttpUnit得到的Html有些判断依靠正则表达式去解析，这个缺点是框架的特性造成的，暂时没想到好办法去解决。

不错不错,利用了浏览器代替了HTTP CLIENT,还是基于web的,结果的发布很方便,并且测试数据和测试环境分离开了.
不过好像开发工具还不太多,另外,那个editor怎么用啊?