●换个角度，框架到底用来做什么，最终的目的无非是将不同层次的对象和逻辑进行抽象和分离封装，从而使得被测试程序的变更所导致的测试脚本框架的变更维护工作量减少到最少，更进一步，如果不懂自动化编程的普通测试工程师能不需要了解测试工具和框架本身的知识就能维护控件对象和业务逻辑，这样就可以将自动化测试工程的工作量进行很好的分摊。具体实施就是将控件对象，动作，参数等等从框架或工具本身剥离出来放在普通Excel表格中，组织成如下形式：
|
Window |
Control |
Action |
Arguments |
|
Calculator |
Menu |
View, Standard | |
|
Calculator |
Pushbutton |
Click |
1 |
|
Calculator |
Pushbutton |
Click |
+ |
|
Calculator |
Pushbutton |
Click |
3 |
|
Calculator |
Pushbutton |
Click |
= |
|
Calculator |
Verify Result |
4 | |
|
Calculator |
Clear |
||
|
Calculator |
Pushbutton |
Click |
6 |
|
Calculator |
Pushbutton |
Click |
- |
|
Calculator |
Pushbutton |
Click |
3 |
|
Calculator |
Pushbutton |
Click |
= |
|
Calculator |
Verify Result |
3 |
框架本身所要做的就是识别Excel表格中的这些控件对象以及Action
注：以上表格中还可以将数据剥离出去，以单独的数据Excel表格进行维护
优点：
●极大的减少了自动化开发工程师维护量，毕竟在测试团队中，自动化开发工程师占的比较少
●普通测试工程师，可以很好的维护自身负责的模块中涉及的测试case和测试数据
缺点：框架的抽象程度比较高，对自动化测试工程师的开发能力比较高
总结：个人认为以上的四种架构是存在递进关系的，至少前三个是肯定的，原文中最后总结的图认为还是需要多种框架特点组合在一起的，还是有很好的借鉴意义的，这里一并附上
