Web系统自动验收测试框架－ACTFW 测试版发布。

用例的验收测试脚本最好能够以用户可理解的脚本语言来编写，这个原则可以放宽到在我们的指导下。

如果用例的验收测试不能让终端用户来编写，而是让开发者与用户一起来编写，无疑大大加大开发者的工作量，而且也不能更好的将终端用户融入进来。

开发一套适合具体应用的自动测试脚本对项目的进展显得格外重要，针对webwork的web应用，其实做起这个并不时很难。 要实现基于webwork的自动验收测试脚本引擎更是容易。
这里是一个我设计的粗浅的例子，或许，在我们正在进行的项目中，我们就使用它来让用户在编写用例的同时编写验收测试脚本，
用户编写的验收测试脚本我们称之为 初级版本，
在每一个迭代后期，开发者需要和用户一起完善这个脚本，包括去掉用户原来用于描述被验证对象的中文描述，然后改为特定的描述。通过自动验收框架运行验收测试。

具体的例子请看这个XML脚本：

因为有些乱码，我只能把其中的中文描述放到这里来了：
<!--定义一个验证单元Validator -->
<!--
一个验证单元由一个动作流+验证集+清除动作流 三个部分组成.
1) <Action-Flows>；动作流反映了终端用户与系统的交互动作，它代表客户对于一个用户故事的
验证操作流程记录。如图中的Action-Flows所示。 基本对应于
ww:form 的形式
2) <validates>：验证集主要采用一些较为简单的自定义比较语法，一般有这几个需求表达：
                            a) 验证某个集合中是否包含某个对象，这个对象符合用户所描述的属性（与3相同规则)。
                            b）验证某个集合的尺寸大小。
                            c）验证某个对象中的某些属性值是否符合用户所期望的值。
                             d)精确取出集合/map中某个元素，然后对这个元素进行3）的比较。
  针对这种规律，我认为一个标准的验证语法大概可以这么组成：
需要被验证的对象   +    验证的行为   +    返回结果
  在下面的例子中，请看<validates/validate 部分，我大致针对上面提到的四种基本验证规则
作了四种表达定义：
                  a） contains-object ,适用于Collection/Map
                   b) size 适用于Collection/Map
                    c)collection-index-object /map-key-object/object
                      主要分别用来从集合按索引取出/Map按Key取出/直接取出 需要比较属性的对象，分别进行属性的比较。
operation-field="所有的帐户" ，表示用户期望被验证的对象描述/需要精确描述 。
对于这个中文的描述，我认为很有必要。因为终端用户此时并不知道开发者怎么提供这个被验证的对象。
而此时，对于编写验证测试的人员来说，首要的任务是根据具体的用户故事编写出有效的验证测试脚本
来。 注意，此时，我们并不希望这段脚本能够被我们的自动测试框架识别和进行自动测试。
等到开发者完成后台的开发后，他需要将这个中文的表述替换成他对应的Action中所能提供的fields.
比如： operation-field="allAccounts",对应到Action中为:
AddAccountAction extends ActionSupport{
public List getAllAccounts(){
return service.findAllAccounts();
}
....


}
3)<Clean-Actions>测试完成后，有可能需要清除前面的数据



-->










[code:1]<!DOCTYPE root>
<ACTFW>
<!--可以重用已经定义的validators -->
<include>test.xml</include>

<!--定义一个验证单元Validator -->
<!--
一个验证单元 由 一个动作流 + 验证集 + 清除动作流 三个部分组成.
1) <Action-Flows>；动作流反映了终端用户与系统的交互动作，它代表客户对于一个用户故事的
验证操作流程记录。如图中的Action-Flows所示。 基本对应于
ww:form 的形式
2) <validates>：验证集主要采用一些较为简单的自定义比较语法，一般有这几个需求表达：
1) 验证某个集合中是否包含某个对象，这个对象符合用户所描述的属性（与3相同规则)。
2）验证某个集合的尺寸大小。
3）验证某个对象中的某些属性值是否符合用户所期望的值。
4)精确取出集合/map中某个元素，然后对这个元素进行3）的比较。
  针对这种规律，我认为一个标准的验证语法大概可以这么组成：
需要被验证的对象+ 验证的行为 +返回结果
  在下面的例子中，请看<validates/validate 部分，我大致针对上面提到的四种基本验证规则
  作了四种表达定义：
1） contains-object ,适用于Collection/Map
2) size 适用于Collection/Map
3)collection-index-object /map-key-object/object
主要分别用来从集合按索引取出/Map按Key取出/直接取出 需要比较属性的对象，
分别进行属性的比较。
operation-field="所有的帐户" ，表示用户期望被验证的对象描述/需要精确描述 。
对于这个中文的描述，我认为很有必要。因为终端用户此时并不知道开发者怎么提供这个被验证的对象。
而此时，对于编写验证测试的人员来说，首要的任务是根据具体的用户故事编写出有效的验证测试脚本
来。 注意，此时，我们并不希望这段脚本能够被我们的自动测试框架识别和进行自动测试。
等到开发者完成后台的开发后，他需要将这个中文的表述替换成他对应的Action中所能提供的fields.
比如： operation-field="allAccounts",对应到Action中为:
AddAccountAction extends ActionSupport{
public List getAllAccounts(){
return service.findAllAccounts();
}
....


}
3)<Clean-Actions>测试完成后，有可能需要清除前面的数据



-->
<validator name="validate AddAccount">
<Action-Flows>
<!--类似通过IE发送请求 /service/addAccout.action?name=test&age=22  -->
<Action name="addAccount-test">
<name>addAccount</name>
<namespace>/service</namespace>
<parameters>
<parameter>
<key>name</key>
<value>test</value>

</parameter>
<parameter>
<key>age</key>
<value>22</value>

</parameter>
</parameters>
</Action>
<Action name="addAccount-blahblah">
<name>addAccount</name>
<namespace>/service</namespace>
<parameters>
<parameter>
<key>name</key>
<value>blahblah</value>

</parameter>
<parameter>
<key>age</key>
<value>29</value>

</parameter>
</parameters>
</Action>


</Action-Flows>
<!--使用自动验收测试框架来执行用户的验证脚本 -->
<validates>
<validate after-action= "addAccount-test">
<contains-object operation-field="所有的帐户">
<name>test</name>
</contains-object>
<size operation-field="所有的帐户">
<value>1</value>
</size>
<collection-index-object index="0" operation-field="所有的帐户">
<age>1</age>
<name>test</name>
</collection-index-object>
<map-key-object key="savedAccount" operation-field="所有的帐户">
<age>1</age>
<name>test</name>
</map-key-object>
<object operation-field="已经保存的帐户">
<age>1</age>
<name>test</name>
</object>

</validate>
<validate after-action= "addAccount-blahblah">
<contains-object operation-field="所有的帐户">
<name>blahblah</name>
</contains-object>
<!-- 注意，前面已经保存了一个账户-->
<size operation-field="所有的帐户">
<value>2</value>
</size>
<collection-index-object index="0" operation-field="所有的帐户">
<age>29</age>
<name>blahblah</name>
</collection-index-object>
<map-key-object key="savedAccount" operation-field="所有的帐户">
<age>29</age>
<name>blahblah</name>
</map-key-object>
<object operation-field="已经保存的帐户">
<age>29</age>
<name>blahblah</name>
</object>

</validate>

</validates>


<Clean-Actions>
<!-- 为了下一个Validator验证能够使用已经有的数据，这里不作数据  清除             -->
</Clean-Actions>
</validator>

<!-- 接着上面保存两个账户后，继续作   查询     和     删除的验证-->
<validator>

</validator>
</ACTFW>[/code:1]

you can try fitness

fitness 不够好用。 我们希望得到一个短小精悍的。 赫赫

自动验收测试是很有前途的想法
对开发的价值也很大
期待firebody的实现

问题在于如何让客户方便的编写测试用例
XML作为存储介质是可以的
但是让用户去编写XML就不太好了吧？

我认为用户能接收的极限也就是填类似于excel那样的表格了

写的不错，感觉很清晰，验证太弱。

Clean-Actions写起来太难吧？

可用性再慢慢考虑，可以弄开发工具支持

我们用的是Rational Robot,支持录制，回放，编写测试脚本

Robot好像只能用于GUI的界面吧。

另外类似fitness ,httpunit等等框架，显得有些笨重，语法也不够精简。

Web也可以。
你说的验收测试不限于有界面的？

可以基本对应于页面来编写脚本。
但是对于界面的验收是不可能自动化的，因为涉及到用户体验的问题。

我这里的验收测试严格来说是针对单个功能的验收。
界面的验收我一般分开来做，不会太重复，频繁的进行，毕竟它是靠用户来手工体验的。 对于新作的界面，用户负责去手工体验一次，满意则对这个页面的task通过。  假如第二次迭代 没有对这个页面作过大的]修改，那么基本可以不再手工测试一次了。微量修改的调试需要界面编写人员自己来完成了。

嗯，还是你们的测试要求严格。
俺们做的测试松松垮垮，客户验收测试，完全是给他们的高层做个样子，跑了一遍脚本就算通过了。
不过功能确是随时可以改进，增加。