这两个缺点，让我们决定，为每一个窗体都建立一个基类，在这个基类中，完成所有控件的定义和访问。并将所有这些控件封装类，集中在一个单元中。每一个类，一个单元也想过，但是感觉太复杂了。也没必要。
这里面还有另外一个易用性问题。这和第一篇中讲到的组件架构有关。如果我们的测试业务代码，都是和主程序混在一起，那么对于测试人员，
他们必须在有主程序代码的前提下，才可以调试业务测试代码 程序代码，也会成为他们的负担另外，从程序代码的封装角度来看，也有可能遭受破坏的可能。所以，决定将所有业务代码都封装到一个独立的Dll中。另外，为了降低Dll对程序代码的依赖，所有对控件的访问，都通过对应的接口（如IEdit,IForm,IButton）来访问，而这些接口的对象实例的创建，都可以留在程序代码中（这是为了方便扩展）。
整个框架过程中，还有几个重要的问题。第一个就是控件名称的命名问题。本来可能通过控件的属性来生成，但后来发现，不一定有中文信息，比如Edit控件啊，Grid控件啊。所以支持了字典表的方式来做翻译。首先将控件Name按照骆驼命名法分离，然后将那些缩写或者单词，到对应表中，查找中文解释，最后组合称为名称。
还有就是业务流程的Log问题。这个实现，后来采用的是AOP模式。具体的实现思路，后面会有专门介绍。
当然了，实际应用中，还可能有很多其他问题。这些都需要细细解决。总之一句话，由于充分考虑了用户的感受，所以这部分的框架，改了又改，现在才稍微满意了。
延伸阅读
文章来源于领测软件测试网 https://www.ltesting.net/
