自动化测试框架：自己的框架

        不说这些了，因为这个框架现在还属于开发阶段，很多事都是言之过早。最近几个博文中，我会持续将我在架构过程中的想法写下来。供自己和大家一起分享。

        这些想法，并不属于我一个人，我工作中的同事们给了我很大的帮助。

        这一篇主要说明架构方面的考虑。

        在现有的提供自动化测试解决方案的产品很多，包括：Robot，TestComplete，WinRunner等等。我只接触过这些，公司里也进行过很大的尝试，但是结果往往总是不竟如人意。

        这中间，排除那些人员方面的原因，也总结这些自动化工具，在使用过程中的不方便的地方：

        定位控件不方便。标准控件还好，非标准控件就只能靠很多非正常方法去获取。而且，控件的识别往往和界面布局相关。
        验证数据不方便。这点更是针对非标准控件（什么？你不用非标准控件？），数据的检测，甚至夸张到使用图片检测。
        代码维护不方便。由于在编写过程中，大量的和界面相关的代码，导致最后在需求变更的时候，代码的维护，成为测试人员的负担。
        针对这些情况，我们经过讨论，何不自己做一个测试框架。当然了，这是基于我们的丰富的知识积累的决策。大家不需要关心这个决策的情况。不过，可以多关注一些我们在做的过程中的分析结果。

        通过分析流行的测试框架，有多种方式：

        第一、最典型的就是消息驱动，自动化工具通过脚本录制和编写，保存为测试脚本。在回放的过程中，将这些脚本转换成为Windows消息，发送给我们应用程序的窗体和各种控件。

原文转自：http://www.ltesting.net