敏捷自动化测试(6)

　　3、采用统一的UI框架开发复杂控件

　　对于复杂控件，比如Tree、Grid，如果不基于统一的UI框架实现，开发、测试工作量都会很大。

　　4、对于需要设置ID的控件，一定要设置唯一、并且有业务意义的ID

　　当然对于一般不需要设置ID的控件(如，div)或者控件ID由UI框架自动生成的情况除外。

　　5、对于Form中最常见的label+input组合，尽量让label和input有逻辑对应关系

　　推荐为label设置for属性，属性值等于input的id，这样对最终用户也比较友好：双击label的时候，鼠标焦点能定位到对应的input中。

　　6、页面设计时考虑用户体验，往往用户使用方便的时候，自动化测试也会方便

　　比如，一个页面上不要有多个同名的按钮、通过点击上下微调按钮(箭头)改变输入域值的控件也支持直接输入值、日期选择控件支持用户直接输入、下拉列表控件支持输入过滤，等等

　　对以上几点最佳实践有如下补充说明：

　　1、这些最佳实践不仅能提高Web UI的可测试性，也非常有助于提升用户体验;

　　2、这些最佳实践如果能满足更好，即使不能全部满足，也可以开展自动化测试;

　　按照本文给出的方案，前文“我们的测试为什么不够敏捷”中用到的“用户管理(增加、删除)”功能的自动化测试脚本就可以改造为如下样式(示意代码)：

<event id="[button]新增" name="click"/>
<event id="[input]帐号" name="setValue" value="${account}"/>
<event id="[input]密码" name="setValue" value="1"/>
<event id="[input]姓名" name="setValue" value="${accountName}"/>
<event id="[input]性别" name="select" value="女"/>
<event id="[input]生日" name="setDate" value="1980-01-01"/>
<event id="[input ]国籍" name="select" value="中国"/>
<event id="[button]保存" name="click"/>
<event id="[gridRow]${account}" name="assertExist"/>
<event id="[gridRow]${account}" name="check"/>
<event id="[button]删除" name="click"/>
<event id="[ gridRow]${ account }" name="assertNotExist"/>

　　以上测试脚本完全基于界面上“可见”的内容进行编写，大家应该不需要看下面的解读，也能明白脚本的意思：

　　1)第1、8、11行表示点击“新增”、“保存”、“删除”按钮;

　　2)第2~7行表示为输入域赋值，赋值方式有输入文本、输入日期、选择下拉选项;

　　3)第10行表示选中表格中的指定行，即，选中指定行前面的Radio按钮;

　　4)第9、12行表示断言表格中指定的行“存在”或“不存在”;

　　5)${ account }表示使用外部的变量account;

　　让断言不再成为自动化测试的负担

　　在本系列的第一篇文章“我们的测试为什么不够敏捷”中，根据实例总结出敏捷自动化测试的两大阻碍：“脚本维护困难”、“断言条件繁琐”。本文针对在不失自动化测试有效性的前提下如何降低断言成本来分享一些实践经验。

　　目前业界常见的自动化测试工具在断言方面大多都是采用“指哪儿打哪儿”的细粒度模式，即，在自动化测试过程中只能对设置为断言条件的字段(页面元素)进行断言。而且这些测试工具即使提供录制脚本的功能，但对于断言往往还需要测试人员手工补充插入。

　　除了补充、维护断言条件的工作量大之外，这种断言模式还存在一些明显的不足，下面结合一个实际的例子(如下图)进行分析：

　　无法感知未设为断言对象的字段上发生的错误

　　以上图为例，如果在“增加用户”的测试脚本之后只对列表中的“用户姓名是否存在” 进行断言，那么就可能遗漏“入职日期没有提交成功”的错误。而且由于页面的信息量往往很大，我们是不可能对所有字段都设置为断言条件的。

原文转自：http://www.uml.org.cn/Test/201307154.asp