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

ACTFW就是你那个吗? 这名字....能念出来么, 建议增加几个原音..

关于Fitness增加了工作量的问题,这是我个人看法.上次我看fitness+wiki的做法是，他们在每一个wiki页面都提供一份page model和command，以便执行客户在wiki上写的command，这样虽然可以让客户真正的测试了，但我感觉很麻烦

我建议你的我建议你的ACTFW提供一个编辑工具或者也考虑和WIKI集成。如果让客户写xml这是绝对不可能的。他们会认为xml就是在编程了，而写wiki就不是。前两天见buaawhl，他推荐DSL，嘿嘿

对头，我最近正在思考这件事情，怎么设计一个好的交互 ，通过浏览器让用户输入他所需要的验收脚本。
估计是这么一种形式：
用户点击“定义操作流”，弹出定义操作的界面，用户输入操作名称，点击“增加输入参数”，用js增加input ，用户输入name 和 value ，注意，这里用户可以输入他所认为合适的描述性语言。 然后点击完成，用户可以依次定义多个操作，也可以调整这些操作的顺序。

然后用户接着定义验证集，用户点击“定义验证单元”，输入验证单元的名称，选择触发此验证的操作名称，选择验证单元的验证类型 ,然后根据用户选择的类型，弹出一些输入框让用户输入具体的信息，这些信息都是描述性的语言。
最后点击完成提交，后台生成一个ACTFW脚本，这个脚本作为整个验收测试的基本输入，然后经过开发人员开发，和修改，输出将是一个符合具体语法规范的可运行的验收脚本。

原来的QA之所以不顺利，这个和方法无关，我认为是QA的个人问题，因为这个QA是客户方提供的人员，各方面能力特别是学习能力、工作责任心等方面非常有限，而由于很多原因，没有去手把手教他。实际上新来的一位QA就做得很好。
另外selenium现在很多配套的工具没有开发，所以会在使用上有所限制。
而对于验收测试，其实关键是测试用例的设计，
具体的测试代码谁写并不重要，重要的是确定运行环境、输入和输出。
一般应该是QA和客户一同完成，在Iteration Plan Meeting时确认需求。

测试确实是最重要的，但并不意味着因为测试的增加带来的工作量就完全值得忽略或者义无反顾地投入，我们所关注的是测试的效率，特别是验收测试的效率。
让开发人员编写代码级别的验收测试， 会比较繁琐 ，而且很多输入和验证都是基本重复的代码，如果验收测试能够让用户编写，或者用户能够完成大约80%的工作量，这个对于整个团队的效率会起很大的作用。

问下，有RCP在编码前，或至少同步，支持测试先行，而不是在开发完后再来录制脚本的东东麽？

没说让开发人员写验收测试呀，不讨论乐......

这里代码级别的测试，具体是指什么？
在我看来，低级，琐碎的验证测试，应该在单元测试就该搞定的。
验收测试主要应当关注业务方面的问题，而不是琐碎的低级验证。

在这个贴子里面，意指selenium code， 赫赫，我没具体用过，不过看它的语法跟assert差不多，QA可以比较容易的写，用户可能就看不懂了。
我说了这么多废话，其实对它还是很喜欢的。 嘿嘿，现在还比较流行用Python,Ruby来写响应流的验收测试框架，估计这个也值得关注，看看是否能够出来比较cool的工具。

ruby有个Watir: http://wtr.rubyforge.org/

:(    
为什么我老也当不下来