http://blog.csdn.net/roger_ge/article/details/5531941
第一部分：前言
自动化测试或许是众多测试同行都在研究或准备研究的领域。结合自己的能力和公司的状况，选择合适的自动化工具、搭建正确而又高效的框架或许是个永远讨论不完的话题，正如应了那句话，没有最好，只有更好。
个人所在的公司当前开展的很多项目都是基于Win7和WPF开发的，之前想尝试用QTP对之进行录制和回放操作，不幸的是，需要额外的WPF插件支持；另外QTP的脚本语言是VBScript，虽然说是功能强大且容易上手，但是其逻辑严谨性还是不如诸多类C的高级语言。自身对QTP的掌握程度也只能算是入门级的，想到开发自动化程序前还要先深入学习QTP，感觉有点戴着枷锁跳舞。其实当前个人急切想掌握和学习的事情的自动化测试框架的知识，因为毕竟录制和编写过程化的自动化程序不是件难事，搭建出高效的框架才是核心，只有掌握了框架的东东，才能用之于四海而皆准。
在苦寻之中，UI Automation出现在了我面前。其有如下几个优点：
n 微软提供的新一代自动化framework，内嵌于.net framework，对WPF完全支持
n 编程语言采用C#
n MSDN提供非常详细的帮助文档，并有详细的代码示例
n 弹性非常优良，只提供窗口、控件等元素的识别、动作、属性等公共方法，至于上层的架构搭建完全由编程人员自行决定
第二部分：搭建框架
先来看一下最普通的自动化测试流程：
如果编写一个过程化的自动化程序，每执行一个测试用例，那么很多代码和动作基本都是重复冗余的，那好吧，研究一下有哪些方面可以抽象封装的：
n 自动化程序的配置：在App.config中定义
n 测试场景套准备和清理：考虑到不同的场景之间肯定是不同的，故采用interface规范之
n 启动被测试程序
n 测试场景准备和清理：考虑到不同的场景之间肯定是不同的，故采用interface规范之
n 控件元素的组织：XML列举每个Element的几个重要属性
n 控件元素的创建
n 控件元素的行为
n 测试结果的判断
n 测试结果的存储：采用开源NLog
n 异常的处理：在底层定义用户异常类，由顶层类处理捕获这些异常
抽象封装后的框架图：
说明：
C#中的delegate，相当于以前的回调函数，但其优点是可以迭代添加要运行的方法链，这使得其Launch AUT所在的类中的代码在添加或删除测试用例的时候都无需进行修改。只需要在外部测试场景套中动态的添加测试场景即可，非常的方便。
类C语言还有一个优点就是良好的异常处理机制，这在多层应用程序中该优点更是显现的淋漓尽致。试想如果一个程序有十多层的函数调用，如果没有很好的异常传导和处理机制，在每层处理异常将是非常头疼的一件事情。有了该异常传导机制，底层如果遇到异常，且该异常的出现有必要终止当前自动化测试场景进行的话，只需放弃处理，且抛出该异常，那么中间层所有方法就可以不关心异常处理的操作，顶层的调用方法自然会捕获并处理该异常。这在编写中间层方法的时候是一件非常爽的事情，因为你只要按照正常流程去编写方法就可以了，不需要去关心那些异常和与之应该作出的动作。（这里并不是说像VBScript没有此项功能，相反VBScript也有相类似的功能，可参看我另一篇博文：VBScript 的异常传递与处理）
第三部分：后记
搭建框架的时候发现一些问题，那就是你如果想使自己搭建的自动化测试程序框架能高效且以后变动尽可能的小，那么就需要完全走一遍软件开发的过程：
n 分析自动化测试需求
n 架构设计
n 模式设计
对于这些方面，自己还是比较欠缺。努力学习吧！
第一部分：前言
自动化测试或许是众多测试同行都在研究或准备研究的领域。结合自己的能力和公司的状况，选择合适的自动化工具、搭建正确而又高效的框架或许是个永远讨论不完的话题，正如应了那句话，没有最好，只有更好。
个人所在的公司当前开展的很多项目都是基于Win7和WPF开发的，之前想尝试用QTP对之进行录制和回放操作，不幸的是，需要额外的WPF插件支持；另外QTP的脚本语言是VBScript，虽然说是功能强大且容易上手，但是其逻辑严谨性还是不如诸多类C的高级语言。自身对QTP的掌握程度也只能算是入门级的，想到开发自动化程序前还要先深入学习QTP，感觉有点戴着枷锁跳舞。其实当前个人急切想掌握和学习的事情的自动化测试框架的知识，因为毕竟录制和编写过程化的自动化程序不是件难事，搭建出高效的框架才是核心，只有掌握了框架的东东，才能用之于四海而皆准。
在苦寻之中，UI Automation出现在了我面前。其有如下几个优点：
n 微软提供的新一代自动化framework，内嵌于.net framework，对WPF完全支持
n 编程语言采用C#
n MSDN提供非常详细的帮助文档，并有详细的代码示例
n 弹性非常优良，只提供窗口、控件等元素的识别、动作、属性等公共方法，至于上层的架构搭建完全由编程人员自行决定
第二部分：搭建框架
先来看一下最普通的自动化测试流程：
如果编写一个过程化的自动化程序，每执行一个测试用例，那么很多代码和动作基本都是重复冗余的，那好吧，研究一下有哪些方面可以抽象封装的：
n 自动化程序的配置：在App.config中定义
n 测试场景套准备和清理：考虑到不同的场景之间肯定是不同的，故采用interface规范之
n 启动被测试程序
n 测试场景准备和清理：考虑到不同的场景之间肯定是不同的，故采用interface规范之
n 控件元素的组织：XML列举每个Element的几个重要属性
n 控件元素的创建
n 控件元素的行为
n 测试结果的判断
n 测试结果的存储：采用开源NLog
n 异常的处理：在底层定义用户异常类，由顶层类处理捕获这些异常
抽象封装后的框架图：
说明：
C#中的delegate，相当于以前的回调函数，但其优点是可以迭代添加要运行的方法链，这使得其Launch AUT所在的类中的代码在添加或删除测试用例的时候都无需进行修改。只需要在外部测试场景套中动态的添加测试场景即可，非常的方便。
类C语言还有一个优点就是良好的异常处理机制，这在多层应用程序中该优点更是显现的淋漓尽致。试想如果一个程序有十多层的函数调用，如果没有很好的异常传导和处理机制，在每层处理异常将是非常头疼的一件事情。有了该异常传导机制，底层如果遇到异常，且该异常的出现有必要终止当前自动化测试场景进行的话，只需放弃处理，且抛出该异常，那么中间层所有方法就可以不关心异常处理的操作，顶层的调用方法自然会捕获并处理该异常。这在编写中间层方法的时候是一件非常爽的事情，因为你只要按照正常流程去编写方法就可以了，不需要去关心那些异常和与之应该作出的动作。（这里并不是说像VBScript没有此项功能，相反VBScript也有相类似的功能，可参看我另一篇博文：VBScript 的异常传递与处理）
第三部分：后记
搭建框架的时候发现一些问题，那就是你如果想使自己搭建的自动化测试程序框架能高效且以后变动尽可能的小，那么就需要完全走一遍软件开发的过程：
n 分析自动化测试需求
n 架构设计
n 模式设计
对于这些方面，自己还是比较欠缺。努力学习吧！
基于UI Automation的自动化测试框架 .,布布扣,bubuko.com
原文地址：http://www.cnblogs.com/xu-neal/p/3755048.html
