这种方式的好处在于，自动化工具和应用程序之间能够做到完全的隔离。但是，由于使用了Windows消息，它也拥有了一个非常致命的缺点。那就是消息队列的异步性与程序的顺序性之间的矛盾。很多消息发送给了应用程序，但是应用程序的处理可能已经和消息队列错位了。有一些关于代码的时间片等待，就是因为这个问题。
另外，就是由于完全的隔离，对于操纵控件数据的能力大大降低。毕竟，拥有大量数据的控件都不是标准控件。
第二、嵌入式。TestComplete就是这类工具。它有支持不同语言的版本。大概思路，就是在程序编译的时候，注入自己的控件代理。脚本的回放，直接可以通过代理，操纵到应用程序。
可惜的是，这类软件开发的时候，更多的是考虑平台的兼容性。对于特有平台上的支持不是十分完美。特别是对自定义控件（比如Delphi中，除了VCL的标准控件）支持也没有做到最好。不过，我这里必须承认，TC的内部实现机制可能十分强大，我不能窥探所有。如果有人清晰，可以指点一二。
针对上面的两种，我们想到的第三种方式：一体式。这种方式中，通过给程序在打包的过程中，添加额外的框架代码，是的程序自动提供控件的访问方式。自动化的模块也会作为测试程序的一部分运行。
应用程序在执行脚本的时候，自动通过脚本，控制各控件界面的显示和关闭。它应该是第二种方式的变种。但是由于是自己实现的，所以在对各类自定义控件支持的都非常好。
针对一开始提出的几个自动化测试的难题，我们提出了，自动封装窗体上所有控件的概念（这些概念后面会详细介绍），对于测试人员，只要关心真正的业务操作流程。而业务流程中涉及到的控件，已经为他们自动提供好。这样，脚本也自然只成了业务流程的脚本。其复杂度也就大大降下来了。
按照这个思路，最主要的是可以充分发挥“程序是我们自己的”的优势，对于测试人员，开发人员是他们的最好的访问控件的工具。有什么控件找不到，开发人员可以快速地给他们适配一个访问方式。这也大大降低了测试人员对软件系统内部的了解程度。
因此，自定义的测试框架，最大的优势来源于其无限的扩充能力，以及简洁的封装界面。相信这个框架一定能给我们自动化测试方面带来很多优势。
文章来源于领测软件测试网 https://www.ltesting.net/
