注明：自动化的理论网上也比较多了，我就不再转述了。以下主要谈谈我自己的想法，欢迎大家讨论。谢谢！
自动化基本原理为用工具来模拟人的操作，不过具体模拟方式还是有一些区别，如可以模拟鼠标定位和键盘操作，也可以只模拟用户在哪些控件中有输入或其他操作，而不管用户是如何操作的。
自动化主要是由计算机应用自动化工具执行，因此也就有了计算机工具的普遍特点。自动化测试工具（如QTP）不懂得执行的对与错，更不懂页面是否符合要求，只有你告诉它并给出明确的标准，它才会按此标准给出对错。因此如果用自动化来实现新系统的新模块的测试，那就要求软件的界面和提示即使是错误类型都要有一定的标准，并且在编写自动化测试脚本时要考虑所有可能的情况，这样才能真正实现此模块测试的自动化。其实这也是在模拟人的操作。手工测试一个新模块时，人眼一看就知道结果是否符合要求，而自动化工具是需要通过编码进行判断的，因此可以想象一下，手工测试会有多少咱们无意的瞬时操作在应用自动化时要进行大量编码的。所以自动化测试要重点考虑项目的适用性，应用成本和时间成本的问题。
根据成本问题，制定自动化的细度和覆盖率，力求达到一个利益最大化的平衡点，这样才能达到应用自动化的最优化。如果一味追求自动化，则将会发现成本是指数级的增长。
根据自动化测试的性质，自动化测试将不会发现太多的缺陷，但是它为评估软件质量提供了数据支持。
自动化工具本身也是有缺陷的。自动化程度越高（是指没有进行手工测试的情况），则风险也越大。
根据自动化的特点，以及其他公司的使用经验，我认为咱们公司可以把自动化测试应用到以下范围：
* 迭代式开发过程，目前的软件开发或多或少使用了迭代式开发过程，这就导致了我们需要进行一轮又一轮的测试。[如用于冒烟测试]
* 回归测试
* 提高数据覆盖率
* 兼容性
IBM介绍的自动化测试应用步骤为：
* 建立自动化测试团队：包括业务测试人员，技术测试人员；
* 建立测试规范；
* 培训和提高测试人员的水平；
* 先用典型项目切入，熟悉自动化应用；
* 选取适合自动化测试的用例进行自动化测试，可以辅予手工测试；
* 建立命名规范；
* 不断改进和积累脚本，重视脚本的复用；
* 定期提交测试报告。
咱们公司要应用自动化测试工具进行自动化测试时，
首先就是要选择合适的项目，项目要满足一些需求：
* 工具对项目的应用界面上的控件的识别程度，
* 项目的周期要比较长，且经常有升级，
* 项目的界面变化不大，
* 开发已经完成，
* 用于回归测试阶段
* 用于检查已知的错误是否修正
* 用于发现修改是否造成新的错误
其次，要选择项目中适合进行自动化测试的用例（或功能），如：
* 手工测试重复性高的功能
* 业务风险较高的功能
* 实现自动化不需要大量编写脚本的功能，也就是所花成本合理。
* 前期测试发现较多缺陷的功能
再次，在项目中应用自动化脚本时要注意：
* 要先对整套脚本进行规划
* 按需求和成本划分细度
* 进行编码，要考虑数据驱动和后期维护成本
* 考虑脚本的多功能应用
* 考虑运行脚本的方便性
最后，要总结知识点，实现脚本复用
* 要对应用的知识点进行总结
* 要对实现测试的新方法进行总结归类
* 要对脚本进行整理归档，以便实现复用
测试部门现在选用的是QTP软件，QTP支持VBS和WSH，而比较新的版本，还可以通过使用QTP提供的内置对象调用Windows API，.NET库，和dll库（C#编写的支持会比较好）。QTP还提供API供其他程序调用管理控制QTP的工作，对VBS，VB，和C#支持较好。
QTP的应用级别有：
1. 录制回放
2. 使用控制语句简单修改脚本
3. 抽取公用脚本
4. 数据维护于外部文件
5. 检查点和逻辑操作维护于外部文件
6. 建立自动化框架
7. 对QTP控件对象进行封装
目前QTP的使用属于刚在项目中应用，正在推广的阶段，因此建议把QTP应用目标定在第4到第5级之间。等到测试人员的QTP水平提高后，再考虑把目标定位到第6到第7级别。当然到了能熟练掌握工具时，就可以把QTP只当作执行工具，而各种其他自动化测试实现都应用其他方式实现。甚至可以自己编写一个测试小工具来进行测试。
