自动化测试框架：测试编程框架

做任何事，要牢记你的用户是谁！设计一个框架，要知道你的用户的使用需求是什么，这样，框架设计才可能容易被接受，离成功也就越进一步了。

框架的用户是测试人员。测试人员的特点是：

熟悉或精通业务 了解程序元素，但不了解程序结构 实现细节更是难以洞察

因此，在设计初期，就考虑将控件的访问封装起来。对于测试人员来说，所有的控件都已经封装好了，他们只需要调用就可以了。

这一点，应该已经初步解决问题了。但是我们并没有满足这一点。

对于软件测试来讲，他们了解的是业务元素，而我们常规做法，是把控件封装成编程元素。这是不一样的。举个例子：

我们在界面编程的时候，命名一个按钮控件，叫btnOk，标题是“确定”。对于程序员来说，btnOk可能是自然的标识名称，而对于测试来说，“确定”反而是更自然的选择。

我们考虑，测试最后编程的代码，应该接近DSL（domain-specific language领域描述语言）。可能有这样的几种方式：

设置文本(标题编辑框, "新的标题") 标题编辑框.设置文本("新的标题")

由于我采用了VCL的控件封装策略，所以倾向于使用接口的访问方式（使用.的方式），向测试人员开放接口。在这点上和同事有过争论。不过后来，对测试人员做过简单调查，发现第二种方式还是可以接受的。

下面的考虑问题是，这些控件的访问代码，怎么让测试写了？最直接想到的方法，就是通过遍历窗体，通过访问每一个控件，逐个封装成代码，这样测试就不需要关心这段复杂代码的编写了。

比如：

TMyFormTestCase=class
private
  FEdit1: IEdit;
public
  property Edit: IEdit read FEdit1;
  procedure DoTestCase; override;
end;

其中DoTestCase是真正完成业务功能的虚拟函数。通过覆盖，完成实际业务代码。属性Edit直接封装给测试人员调用。但是，注意到业务代码和我们自动生成的代码混合在一起，这有两个坏处：

自动生成的代码，需要和编写的代码进行混合处理。降低了自动化的可能性。 两者混合，其实是增加了测试学习的成本。相反，如果隔离，可以使得应用变得简单。

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