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

一个以浏览器插件形式出现的捕捉用户动作流和构建验证脚本的web apps acceptance framework .

http://selenium.thoughtworks.com/index.html

extension here:

http://seleniumrecorder.mozdev.org/

editor here:

http://www.augure.com/dev/SeleniumEditor.xpi

偶1年前就推荐了，比你的那个啥xml好用多了......

http://forum.javaeye.com/viewtopic.php?t=8494&highlight=selenium

并不是插件哦。

切，我的XML 验证跟它关注的不是一个方面的东西。
它属于基于GUI的验收测试，而我的更关注的是基于业务逻辑的验收测试。
虽然它也可以冒烟到业务逻辑的测试，但是还是稍微重了一点，用起来也不是那么想象中那么好用的。
其实我做的那个冬冬是对比与Fitnesse的 。 Fitness跟我的框架所关注的是同一个方面的验收测试，不过它还需要用户编写test tables ，而让测试开发人员编写Fixcode ，这在小公司里面，可会累死一线开发人员的。考虑到Webwork 的输入输出作的比较统一，其实它已经实现了大部分Fixcode的功能了，所以我才写了这么一个省力的验收测试框架。就是只让用户编写验收脚本，开发人员在后期做一些修改脚本的工作就可以了，不用重新编写FixCode了。测试的环境完全是基于Actions的运行，基本可以模拟80%真实的生产环境了。

我想我的框架结合selenium会好一些，不过我让selenium专著做一些验证交互而已了。 赫赫。

赫赫，看到我下面的连接没，已经有extension出来了，不过还不是很好用，试用了一下，赫赫，也不期望它能过完成所有的工作，让用户专著体验一些交互就行了，哈哈。记录用户的体验过程，我们就可以作为一个可重复的收交互的东西了。

我想这么一个脚本还是可以很让用户易懂的吧：

[code:1]<!DOCTYPE root>
<ACTFW >
<测试报告 class="org.opensrc.actfw.report.DefaultLoggerReport" />
<操作执行者 class="com.redsoft.tfs.action.TfsWebWorkActionExecutor" />
<ValidateAround class="com.redsoft.tfs.action.OpenEmInSessionValidateArround" />
<验收测试 name="validate AddAccount">
<ValidatorArround class="com.redsoft.tfs.action.accountrelation.AccountRelationValidatorArround" />
<用户操作流>
<操作 id="action1" >
<操作名字>增加账户关系</操作名字>
<参数集>
<参数>
<key>银行标识</key>
<value>lala</value>
</参数>
<参数>
<key>银行地址</key>
<value>北京中关村</value>
</参数>
<参数>
<key>币种</key>
<value>RMB</value>
</参数>
</参数集>
</操作>
<操作 id="action2" >
<name>编辑账户关系</name>
<参数集>
<参数>
<key>被编辑的银行账户关系主键</key>
<value>ACTION1里已经新增的账户关系主键</value>
</参数>
<参数>
<key>银行标识</key>
<value>aaaa</value>
</参数>
<参数>
<key>银行地址</key>
<value>北京中关村会展Ö行Ä</value>
</参数>
</参数集>
</操作>

</用户操作流>


<验证集>


<验证 触发此验证的ActionID= "action1">
<验证单元 被比½系亩韵ó="新增完±系Ä账户关系">
银行标识==lala1
银行地址==北京中关村
币种==RMB1

</验证单元>
</验证>


<验证 触发此验证的ActionID= "action2">
<验证单元 验证类型="对象属Ð员冉Ï" 目标对象="已经修改的账户关系">
银行标识==aaaa
银行地址==北京中关村会展Ö行Ä
币种==RMB

</验证单元>
<验证单元 验证类型="表达式" >
1）已经修改的账户关系.银行标识==aaaa
2）已经修改的账户关系.银行地址==北京中关村会展Ö行Ä
3）已经修改的账户关系.币种==RMB
4）数据库中所Ó姓Ë户关系的数目==2


</验证单元>
<验证单元 验证类型="目标集合中仅包含一个符合期望属性值的对象" 目标对象="所Ó姓Ë户关系">
银行标识==1
银行地址==北京中关村会展Ö行Ä
币种==RMB

</验证单元>
<验证单元 验证类型="目标集合中仅包含一个符合期望属性值的对象" 目标对象="所Ó姓Ë户关系">
银行标识==2
银行地址==北京中关村会展Ö行Ä
币种==RMB

</验证单元>

<验证单元 验证类型="目标集合中至少包含一个符合期望属性值的对象" 目标对象="所Ó姓Ë户关系">
银行标识==aaaa
银行地址==北京中关村会展Ö行Ä
币种==RMB

</验证单元>

</验证>



</验证集>
</验收测试>

</ACTFW>
[/code:1]

我接下来要做的工作就是国际化标签（哈哈 ：-）），然后去掉一些程序语言的标签名，让所有验证标签尽可能统一，易懂。 希望用户能够接受吧 。

那个插件俺不喜欢。我们一般都是要求seleniumtest先，然后再坐叶面。这样还可以强制自己思考用户交互的方式。如果直接record，那就只能达到一个保证测试的效果了

赫赫，听了你的说法，没想到你们对于页面交互也是测试先行了，佩服佩服。
不过，这个做下来，如果页面够复杂的话，特别是基于AJAX的话，很多测试脚本需要很大的工作量吧。 页面开发人员需要这么多的工作量，还是比较难于应付的，如果推向UnitTest到前台的话，代码量和维护量也会成正比的。
就像你做单元测试一样，为了使得你的页面的测试能够保证这么一个结论：
页面测试通过 == 页面task ok .
我想你还是需要写足够多的selenium code的。这个工作量会让我们难以承受。

而且更重要的一点：
页面的验收怎么让用户直接参与进来，甚至让他们做主导的工作，测试开发人员只需要在旁边指导或者修改即可。

1 selenium test != unit test 这是功能测试
2 我们还没有用到AJAX，其实就算是AJAX应该也可以测吧，反正selenium是在frame里面运行。
3 这些工作量是必须的，不然你怎么知道以前的功能不被后面的代码破坏？
4 页面test通过 == story finish
5 写习惯了就快了，把工作量算入计划中，质量提高了更好
6 客户不可能直接写这东西的，还是有些复杂。我们希望QA能够写，但我们上个project里面的QA写的不是很顺利
7 相让客户参与的话，上次有人讲过Fitness+Wiki的做法，这个可能客户参与性更强，但相应的，程序员要开发的东西更多

1 selenium test != unit test 这是功能测试 ,赫赫，口误。
3 这些工作量是必须的，不然你怎么知道以前的功能不被后面的代码破坏？
这点，我想我们会通过Fitness或者ACTFW来进行基于业务逻辑的验收测试。

6 客户不可能直接写这东西的，还是有些复杂。我们希望QA能够写，但我们上个project里面的QA写的不是很顺利
赫赫，这点其实正是道出了我的担忧，连QA都难以写了，那么客户就更不用说了。 按照你们的这种方式的话，工作量我感觉还是偏大一些。 特别是对于开发人员来说。

7 相让客户参与的话，上次有人讲过Fitness+Wiki的做法，这个可能客户参与性更强，但相应的，程序员要开发的东西更多

不明白，难道这引起的工作量比页面开发人员编写selunium code还要多？ 基于ACTFW的话，我的业务逻辑的验收甚至可以不用写多少java 代码。