上两篇我们结合数据驱动讨论了page object模型，分别用了Excel和csv进行演示。其中Excel参与的演示项目叫SeleniumExcelDataDrivenPOM，现在打开这个项目，看Test.java文件：
虽然我们已经把object，测试步骤和验证过程都加到了LoginPage.java中，可现在这个主类还是很长。关键问题不是长，而是非常冗余。比如我现在再写一个关于登录模块的用例，比如验证登录失败吧，除了测试步骤和验证过程不一样之外，你要把开头的driver初始化，打开网页，最大化网页，读取测试数据源等等等等重写一遍。有多少个测试用例你就得写多少遍这些步骤，非常麻烦。所以，我们需要把一个更加标准的系统来简化我们的工作量。从这篇开始，我就带着大家继续一点点改进我们的数据驱动测试系统，搭建一个框架雏形。
所谓的自动化测试框架，我理解就是一个标准化的测试系统，其特征是一致、复用、扩展性强：
我先不解释这几个词，大家可以随着程序的改进慢慢体会这几个词。其实市面上已经有不少自动化的测试框架，很多还是开源的，比如Robot Framework等等，有的公司用现成的框架，有的公司在其基础上扩展改进。不得不说现在纯写代码搞框架已经是越来越少了，因为维护起来有些困难。这一点随着程序改进大家也能慢慢体会。有些人问那为什么你不直接讨论现成框架呢？知其然知其所以然，之所以我一定要带着各位一点一点改进，尝试搭建框架过程，就是想让大家熟悉一个自动化测试系统的内部结构，便于以后大家理解其它的现成框架，同时也锻炼了写代码的能力，有助于未来在现成框架的基础上进行小规模扩展。当然，我也分别写了Robot Framework，TestNG，和Cucumber的教程供大家学习。不过我强烈建议你们先别走，先跟着我把框架的结构搞清楚：)
我们开始改，因为读取数据源大多数测试用例都需要，所以我先把读取数据源的步骤封装在一个方法里，并写到另一个类中。从现在开始我也要规范包名，之前介绍过包名的规范，用的是“所在公司的互联网域名.公司名.项目名.功能名”这个格式，我新增一个包命名为叫com.testalliance.hrsystem.test，里面专门放测试过程中需要的一些前提或条件：
然后在该包下创建一个叫Test.java的文件，把读取数据源的步骤放进去。因为com.test里已经有一个叫Test.java的文件了，一个项目里最好不要有两个同名文件，把com.test改成com.testalliance.hrsystem.managers(为什么起名为managers一会儿再说)，然后它下面的Test.java改成TestRunner.java：
读取数据源的步骤封装在Test.java的getTestData()方法中：
第33行我修改了一下，以前testDataCell位置是直接写死了两列，但这里我动态求了列数，因为有些用例的测试数据Excel表格可能是两列，有些可能是多列，我们不好把握。那么现在TestRunner就可以简化一些了，直接调用方法。这样，以后写其它test case需要测试数据时直接调用就行了，唯一注意的地方就是传入的文件不一样罢了。还一点，以前我们用的都是文件的绝对路径，这回我改成了相对路径。System.getProperty("user.dir")返回的是项目的路径，你只需要在后面加上剩余的部分就行了。这么做的好处就是一不用写大长串，二如果项目的路径改了你也不用修改，System.getProperty("user.dir")会自动定位到新的项目。我们以后最好使用相对路径。
顺带着把另外两个包名也改过来：
接下来就该把另一部分重复的代码挪出去了，也就是driver初始化，打开网页，最大化网页，关闭driver这几步，每个测试用例都会用到。仔细想一下，初始化driver属于一个测试过程的准备步骤，而关闭driver属于扫尾步骤，严格说它们都是在控制管理driver实例，那可不可以单独创建一个管理driver的类，然后把它们也封装到相应的方法里呢？我们在com.testalliance.hrsystem.managers中新建一个类叫DriverManager.java：
然后粘贴如下代码：
初始化和关闭driver分别封装在preTest()和cleanUp()里。同样，未来使用它们时直接调用即可。打开网页和最大化网页这两步其实可以放在LoginPage.java中，因为我们一般都把网址当作是一个特殊的object并写在object repository中。打开loginPage.properties，把网址填进去：
然后把这两步写入LoginPage.java:
回到TestRunner.java中，对它们分别调用：
现在问题来了，TestRunner.java里面目前只有一个测试用例，如果我想再加一个呢？TestRunner.java已经是主类了，我总不能再继续追加吧？那所有的用例岂不都写在一起了？所以，测试用例也要挪出去。我再建一个包com.testalliance.hrsystem.tests.login，目的是装所有和login相关的测试用例。再新建一个类叫TCLogin1.java(同时也把存数据的文件名称改成TCLogin1.xlsx)：
把TestRunner.java里面的内容全部挪到TCLogin1.java里，注意把路径中的文件名也改过来：
封装的方法叫test()，这样我们只用在TestRunner.java中直接实例化TCLogin1并调用test()方法即可：
这篇的改进就到这儿。如果这时你再给登录模块添加一个测试用例，起名为TCLogin2.java，那它也可以被TestRunner类调用、控制，有几个管几个。TestRunner类就好像一个中控一样管理着测试用例的调度:
这下明白为什么把TestRunner.java和DriverManager.java所在的包叫做managers了吧？一个管理测试用例，一个管理其核心driver。下一篇我们新增几个登录模块的用例，大家再体会一下。
这篇文章的源代码在SeleniumExcelDataDrivenFrame1项目里边。
