如何构建自动化测试框架？（10-05-24）（获奖名单已公布）

san

自动化测试知识分两个方面
1. 使用策略
2. 工具
我们自由学习和讨论时候更多的是讨论工具使用。但其实从工具演变的历史看，都是为了某个目的，且配合能在项目高效使用的具体策略服务。工具一直在发展在变，策略也是在变，但我们使用自动化的原因和目的不变。测试框架和工具的不同，是在工具本身提供的功能上，集成了相应部分策略的系统。为了了解他们的不同，要从工具发展和演变说起。
我们在这里先讨论GUI层面的自动化：
1). 最初的GUI自动化工具只提供了录制和回放的功能，记录底层鼠标和键盘的操作轨迹，并回放，但并不能以某种方式(例如某种语言/脚本)展现出来。
2). 而后大家发现这样做的不灵活和不稳定性，于是考虑不仅仅从底层的鼠标键盘模拟，而且从识别并控制GUI底层所采用的技术对象来模拟。并且把录制的结果以某种方式解析出来。这样做的好处显而易见，有了可展现且易于用编程语言展现的平台，直接为模块化，参数化提供了条件。于是有了大家通常看到的UI自动化工具：能识别和操作界面对象，提供录制回放功能，且通常提供某种过程化语言的展示和修改平台。
3). 在此之后进入类似百家争鸣时期，大批的商业和open source的UI自动化工具涌现。他们在对象识别方面各有偏向和优劣，提供的展现平台也各有差异。在工具选择上我们正是依据他们在这两方面的表现作出决策。但同样工具在不同公司使用上差异也很大。正如同样一门语言，做出来的东西和使用效果迥异一样。依据工具提供的展现平台/语言，具体公司在使用上定制出自己的代码规范，积累自己的函数库。于是在具体使用上出现了数据参数化/外部化，过程化和模块化，包括独立出环境初始化库/异常处理库/报告处理库等等。尔后在这些细节处理方法总结和实际目的上，萃取提炼出通用性和方向性的策略，如数据脚本分离，数据驱动，对象脚本分离，关键字驱动等等。一时风云涌动，依据需求而变的东西呼之欲出。
4). 某些工具提供商和使用工具的公司本身，于是考虑是否能把某些使用策略和思想集成到工具本身，从而提高易用性和效率。于是自动化测试框架被提出。这时候的自动化框架并不仅仅提供对象识别和控制，录制回放，脚本展示，且常常集成了test case的管理，对象库的管理，与CI系统集成等等。人们不仅仅追求对象捕捉的精准，更多的开始分析test case类型本身，更多的开始分析展现的其他更直观和易维护的形式，更多的开始分析系统在真实项目过程的需求。