不说这些了，因为这个框架现在还属于开发阶段，很多事都是言之过早。最近几个博文中，我会持续将我在架构过程中的想法写下来。供自己和大家一起分享。
这些想法，并不属于我一个人，我工作中的同事们给了我很大的帮助。
这一篇主要说明架构方面的考虑。
在现有的提供自动化测试解决方案的产品很多，包括：Robot，TestComplete，WinRunner等等。我只接触过这些，公司里也进行过很大的尝试，但是结果往往总是不竟如人意。
这中间，排除那些人员方面的原因，也总结这些自动化工具，在使用过程中的不方便的地方：
定位控件不方便。标准控件还好，非标准控件就只能靠很多非正常方法去获取。而且，控件的识别往往和界面布局相关。
验证数据不方便。这点更是针对非标准控件（什么？你不用非标准控件？），数据的检测，甚至夸张到使用图片检测。
代码维护不方便。由于在编写过程中，大量的和界面相关的代码，导致最后在需求变更的时候，代码的维护，成为测试人员的负担。
针对这些情况，我们经过讨论，何不自己做一个测试框架。当然了，这是基于我们的丰富的知识积累的决策。大家不需要关心这个决策的情况。不过，可以多关注一些我们在做的过程中的分析结果。
通过分析流行的测试框架，有多种方式：
第一、最典型的就是消息驱动，自动化工具通过脚本录制和编写，保存为测试脚本。在回放的过程中，将这些脚本转换成为Windows消息，发送给我们应用程序的窗体和各种控件。
文章来源于领测软件测试网 https://www.ltesting.net/
