敏捷自动化测试(2)——像用户使用软件一样享受自动化测试(3)

发表于:2016-04-26来源:infoq作者:殷坤点击数: 标签:
采用统一的UI框架开发复杂控件 对于复杂控件,比如Tree、Grid,如果不基于统一的UI框架实现,开发、测试工作量都会很大。 对于需要设置ID的控件,一定

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

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

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

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

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

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

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

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

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

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

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

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

  

  

  

  

  

  

  

  

  

  

  

  

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

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

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

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

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

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

  自动化测试中最关键的两部分是“脚本”和“断言”。至此,自动化测试脚本的编写、维护以及执行已经可以跟上敏捷开发的步伐了。本系列的下一篇文章会就“如何让断言不再成为自动化测试的负担”这个话题来分享一些实践经验,敬请关注!

原文转自:http://www.infoq.com/cn/articles/Agile-test-automation-2