方法之二：搭建适应性强的框架

　　开源测试工具，我们组先后用过Selenium RC、WebDriver、WatiJ这几种工具模式，框架采用JUnit和TestNG，测试调度和CI使用Jenkins管理。做起来大的感受是，像WebDriver这种工具，它本质上是为互联网而生；如果要用于我们的企业ERP应用的自动化测试，如果没有做一系列适应性的API和组件封装，测试脚本开发对于大部分同事来说都是件头疼的事情。

　　经过摸索，我们结合PAFA（PingAn Foundation Architecture）架构的前端页面特征做了对象识别、页面加载和处理缓冲、运行监听、数据处理、断言和运行容错、报告、日志以及第三方组件（如Autoit、Cmd等）兼容的封装操作。这种封装属于Bot-Style，适用于我们基于业务操作驱动的自动化测试用例编写，能够大大地降低我们测试脚本开发的技术成本。虽然它们看起来运行起来效率并不是十分高，但是对于被测应用的响应速度来说已经是数十倍的效率胜出了。至于使用Page Object还是Bot-Style，还请大师们不要吐我的槽，这没什么可争论的，因为这只是面向前端业务操作的页面测试，二者的表现毫无优劣之分，完全在于队员的测试脚本编写风格偏好。

附图1：测试中的TestCase样例

附图2：测试中的TestApi样例

　　我们正在从瀑布开发模式下逐渐开展持续集成和敏捷转型，不难预见，达到一定成熟度之后我们大部分团队会使用ATDD或BDD模式。这种快速开发的基于前端的自动化验证测试虽然在验证测试中所占的比例会越来越小，但它们将依然有用武之地，同时对当下的系统前端的回归测试也可以完全支持。

　　自动化测试框架强大与否主要在于其适应性，所以与其说自动化测试框架是选择出来的，不如说它是被改造出来的。产品比较单一的小公司或者开发框架比较成熟的公司用一个工具、一个框架在一个测试平台下可以解决一个公司的自动化测试实施的绝大多数问题，而大型企业的应用繁多复杂，很难由一个简单工具或者框架来解决。

　　自动化测试框架，没有自己DIY过的永远都不要相信不造轮子这种说法，因为只有在你做的时候，你才能够更深入地理解你的工具、框架和你的被测应用及其所依赖的开发框架的特征，才会产出更具适应性的测试框架和特征库。