为什么自动化测试人员没有感觉工作变得轻松呢？

　　要回答这个问题，首先要分析“用户使用软件”与“自动化测试软件”之间的一些重要差异：

　　● 用户使用软件时只关注界面上能“看”到的，而不用总是“查看页面源码”；

　　● 用户会更关注整体业务的正确性、稳定性，而不仅仅是每个孤立页面功能的正确性；

　　● 用户对页面样式、响应时间、浏览器兼容性要求越来越高； 如果我们能像用户使用软件一样进行自动化测试，测试会变得更敏捷：

　　● 根据界面快速编写测试脚本：敏捷应对需求的变化；

　　● 降低对技术实现（UI框架、页面样式/布局）的依赖：敏捷应对设计/开发的变化；

　　● 测试脚本可以稳定支持各种浏览器：敏捷应对环境的变化；

　　（一）根据界面快速编写测试脚本的实现思路

　　还是以前文“我们的测试为什么不够敏捷”中用到的“用户增加”界面为例：

　　如果你是作为用户在使用上述功能时，心里一定也会默念下面内容吧：

　　“账号”输入***、“密码”输入***、“姓名”输入***、“性别”选择***、“生日”输入***、“国籍”选择***，点击“保存”按钮。

　　这可以理解为“根据界面编写的测试脚本”。

　　我们在使用Web应用时，心里常常默念的还包括：“展开/收拢/选中”树（Tree）的某个节点、数据表格（Grid）的下一页/上一页、选中数据表格（Grid）的某一行、点击/关闭某个Tab页，等等。

　　很多人在与笔者交流的过程中都会问“为什么还要手工编写脚本，怎么不提供脚本录制工具呢？”

　　因此在这里想澄清一下大家对“编写”脚本的误解，与传统自动化测试工具相比，“此脚本”非“彼脚本”。

　　传统的测试脚本是给特定测试工具执行时使用的，对人类而言可读性极差，更别谈手工编写了，因此“录制/回放”工具往往都是必备组件。即便如此，此类“录制/回放”工具的实际使用效果，也是不尽如人意的。

　　从这种角度来看，“录制”脚本是“下策”，“上策”应该是让测试脚本大幅简化，并且具备良好的可读性和可维护性，以达到人工编写很容易的程度。

　　——以上只是笔者的一点差异化见解，对业界的测试工具没有任何冒犯之意！

　　（二）降低测试脚本对技术实现依赖度的实现思路

　　Web页面开发中的技术实现细节主要包括UI框架的选择及版本升级、页面样式设计、页面布局设计，因此我们的主要目标是降低测试脚本对这些因素的依赖。

　　为了便于测试脚本的解析和组织管理，目前还不能直接写形如“点击(保存)按钮”这样的纯自然语言，但可以设计成接近自然语言的领域专用语言（DSL:Domain Specific Language），本文采用XML来实现这种DSL。比如：

<event id="[button]保存" name="click"/>