扫一扫
分享文章到微信
扫一扫
关注官方公众号
至顶头条
做任何事,要牢记你的用户是谁!设计一个框架,要知道你的用户的使用需求是什么,这样,框架设计才可能容易被接受,离成功也就越进一步了。
框架的用户是测试人员。测试人员的特点是:
因此,在设计初期,就考虑将控件的访问封装起来。对于测试人员来说,所有的控件都已经封装好了,他们只需要调用就可以了。
这一点,应该已经初步解决问题了。但是我们并没有满足这一点。
对于测试来讲,他们了解的是业务元素,而我们常规做法,是把控件封装成编程元素。这是不一样的。举个例子:
我们在界面编程的时候,命名一个按钮控件,叫btnOk,标题是“确定”。对于程序员来说,btnOk可能是自然的标识名称,而对于测试来说,“确定”反而是更自然的选择。
我们考虑,测试最后编程的代码,应该接近DSL(domain-specific language领域描述语言)。可能有这样的几种方式:
由于我采用了VCL的控件封装策略,所以倾向于使用接口的访问方式(使用.的方式),向测试人员开放接口。在这点上和同事有过争论。不过后来,对测试人员做过简单调查,发现第二种方式还是可以接受的。
下面的考虑问题是,这些控件的访问代码,怎么让测试写了?最直接想到的方法,就是通过遍历窗体,通过访问每一个控件,逐个封装成代码,这样测试就不需要关心这段复杂代码的编写了。
比如:
其中DoTestCase是真正完成业务功能的虚拟函数。通过覆盖,完成实际业务代码。属性Edit直接封装给测试人员调用。但是,注意到业务代码和我们自动生成的代码混合在一起,这有两个坏处:
这两个缺点,让我们决定,为每一个窗体都建立一个基类,在这个基类中,完成所有控件的定义和访问。并将所有这些控件封装类,集中在一个单元中。每一个类,一个单元也想过,但是感觉太复杂了。也没必要。
这里面还有另外一个易用性问题。这和第一篇中讲到的组件架构有关。如果我们的测试业务代码,都是和主程序混在一起,那么对于测试人员,
另外,从程序代码的封装角度来看,也有可能遭受破坏的可能。所以,决定将所有业务代码都封装到一个独立的Dll中。另外,为了降低Dll对程序代码的依赖,所有对控件的访问,都通过对应的接口(如IEdit,IForm,IButton)来访问,而这些接口的对象实例的创建,都可以留在程序代码中(这是为了方便扩展)。
整个框架过程中,还有几个重要的问题。第一个就是控件名称的命名问题。本来可能通过控件的属性来生成,但后来发现,不一定有中文信息,比如Edit控件啊,Grid控件啊。所以支持了字典表的方式来做翻译。首先将控件Name按照骆驼命名法分离,然后将那些缩写或者单词,到对应表中,查找中文解释,最后组合称为名称。
还有就是业务流程的Log问题。这个实现,后来采用的是AOP模式。具体的实现思路,后面会有专门介绍。
当然了,实际应用中,还可能有很多其他问题。这些都需要细细解决。总之一句话,由于充分考虑了用户的感受,所以这部分的框架,改了又改,现在才稍微满意了。
Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=1627221
如果您非常迫切的想了解IT领域最新产品与技术信息,那么订阅至顶网技术邮件将是您的最佳途径之一。
现场直击|2021世界人工智能大会
直击5G创新地带,就在2021MWC上海
5G已至 转型当时——服务提供商如何把握转型的绝佳时机
寻找自己的Flag
华为开发者大会2020(Cloud)- 科技行者