韩小明@xiammy的专栏

最近在考虑自动化测试框架的时候，发现原来的想法，虽然解决了定位及访问控件的困难。但是，用例代码却因此对程序实现细节有了很强的依赖。这些依赖可能对用例代码的开发带来一些困惑。在思考解决这个问题的时候，自然的方案，就是提供统一地访问控件的方式，而不是原来那种直接生成对象的方式(参考自动化测试框架：测试编程框架)。这种访问控件的方式，就好比访问网页一样，输入一个URL，就可以得到想要的控件。以此为基

周末参加了TestAge(测试时代: http://www.testage.com.cn)组织的一个专家讨论会。主要讨论测试自动化。说是专家讨论会，我参加实在是惭愧，我对测试的理解实在是太浅薄了。只是因为在博客上发表了一些谬论才收到邀请。想着可以帮助公司去接受一些新的思想，而自己也可以结识一些朋友，便去了。对于测试时代的会议组织，我以为定位和思路还是非常准确的。只不过个人感觉会议组织可以更好一

近来，将我们的测试框架和市面上流行的测试软件做了对比，发现大家的想法都是一致的。我们也认识到，除了协同工作方面，其他方面还是做得非常好的。办公协同？是的，Google已经退出在线版Office系列软件，而我们的测试框架也同样不能回避这个问题。一开始，我们是可能只有一两个人编写测试脚本，而且还可能两人商量着、研究着，因此开始时候，协同的需求并没有那么紧急。但随着脚本工程慢慢扩大（现在已经4000

目前，自动化测试框架已经基本成型。朋友们的一些建议，还在陆续消化中，在不久的将来或许都会加入到其中，谢谢大家的鼓励和支持。最近，在一次技术交流会中，我的一位同事向我提起QTP(QuickTest Pro)，肯定了它的描述性编程和我们框架中的设计有类似之处，并指出QTP的可扩展性比较强，比如流程控制（IF、LOOP、SWITCH等）。特别是装载数据批量操作软件方面比较强。我深以为然。因此，我

框架做到后期，大量的测试脚本已经编写完毕。大家可能会发现，量少和量多是完全不一样的概念。正如量多的时候你需要考虑运行性能一样，大量的测试脚本，必须考虑其组织方式。在上次重构中，已经和大家交流过，系统中为测试脚本预留了一个“测试包”的概念。而最近又正好在设计最后日志的分析功能，所以很自然地联系起来考虑。（测试包是一个非常简单的概念，就是允许多个测试步骤或测试包，作为另一个测试包的子节点存在。）

当自动化测试的脚本编辑器完成之后，根据使用者反馈，这样确实大大提高了工作效率。并且代码的管理确实变得有效和可控。现在此项目已经开始向另一个管理系统尝试应用。可以预计，会有一些新的功能加入。不过，我们回过头来思考一个问题——自动化的问题。这是我们最终的目的。虽然说自动化测试框架能够解决软件本身的执行问题，但是一次完整的测试，必然是要覆盖全过程的。很显然，我们的框架不能解决这个问题。我做过很多

在写这个自动化测试框架的时候，我一直在留意各方面的需求。毕竟，我本人并没有做过真正的自动化测试。管理测试方面的领导，提出一个需求，就是在用例运行失败的时候，应该将过程记录下来，并形成报告，Email给相关人员。个人认为这个需求是非常合理的。事实上，任何系统，如果没有输出，那么只能停留在程序员手里。有了报表，才叫真正解决了用户的目标需求。在分析这个需求的过程，我提出了针对每一个操作接口的每一

今日将框架完整走通，给测试试用。但从测试表情看，显然没有Surprise的意思，反而有种因为改变使用习惯并要学习新框架的厌烦。尽管事前，我们已经对需求做过自认为相当全面的分析，而且在框架设计上也充分进行了斟酌和权衡。但是，结果就是这样的。当然了，分析这个原因的前提，在于我对自己的要求还是挺高的。期望也是挺高的。那么，原因到底在什么地方了？人如何才会Surprise呢？惊奇，从字面上讲，

这段时间一直在为公司内部开发自动化测试框架，简称GTF。这些代码都是公司的财产，不方便共享。当然了，如果公司愿意，我倒愿意开源了。不说这些了，因为这个框架现在还属于开发阶段，很多事都是言之过早。最近几个博文中，我会持续将我在架构过程中的想法写下来。供自己和大家一起分享。这些想法，并不属于我一个人，我工作中的同事们给了我很大的帮助。这一篇主要说明架构方面的考虑。在现有的提供自动化测试

做任何事，要牢记你的用户是谁！设计一个框架，要知道你的用户的使用需求是什么，这样，框架设计才可能容易被接受，离成功也就越进一步了。框架的用户是测试人员。测试人员的特点是： 熟悉或精通业务 了解程序元素，但不了解程序结构 实现细节更是难以洞察 因此，在设计初期，就考虑将控件的访问封装起

前面讲到要做一体化自动化测试框架，那么，最重要的是要解决什么呢？相信了解Windows编程的人员，都能发现这个问题所在。在窗体中，写下代码，控制每一个控件的输入是非常简单的事。但是，一旦显示了一个模态窗体，原有的流程代码会不再往下执行，而是停留在新窗体中，等待消息相应。这就是我们代码控制界面的关键问题。这是什么道理呢？我使用的是Delphi系统，所以我可能使用VCL框架来解释这个问题。

最近对测试框架进行了重构，也对其中原有的一些设计进行了反思。其中不免有一些自我感觉得意之处，因此写出来和大家分享。这是一个重构的过程，所以将以重构的思路来讲述。重构对于一个系统来说，往往是必要的。他的必要性往往不在于重构的好处，而在于系统的成长的趋势。一个好的系统在初步阶段，在很多方面都会存在成长的空间，就如人在小时候长身体一样，如果补充的营养跟不上，一生都可能会受到影响。对于我们这个系统

经过一段时期的框架准备和测试方案编写，实际的冒烟测试已经开始进行。目前还算比较顺利。当然了，工作忙了一点，所以博客的更新速度也降低了。在编写的过程中，发现对于独立的子窗体的处理还是比较方便和简单的。这些窗体的普遍特点就是结构简单，功能单一，所以对应的处理过程也比较方便。但是对于主窗体来讲，就非常不一样了。可以说，一个系统中的绝大多数窗体，都包含在主窗体中，那么，对于主窗体上的控件的定位问题，就

自动化测试框架的基础是钩子，也就是常说的HOOK机制。但这在实际的应用过程中可能会遇到一些问题。一旦要做钩子，那么就必须获取函数地址。由于我原先设计的钩子的目标函数，都是Delphi的内部函数，也就是说，这些函数在编译之后，很难找到。当然了，也是有几种方式可以找到的： 将代码植入到系统中，编译的时候可以直接找到。 编译的时候，带上

今天偶然看到上次在TestAge交流的时候的录像， 我把链接附上，大家有兴趣的可以看看。 主要是关于前一段时间做的自动化测试的一个小报告。 第一段第二段第三段