上篇我们给框架又做了几个小修改，最后的TestRunner.java是这个样子：
注意，现在TestRunner.java里面还有bug，举个例子，程序进入try语句后如果在执行测试方法时抛出了异常，dm.cleanUp()还能执行到吗？就执行不到了。或许执行结果都无法被打印出来，所以我们还要继续修改。
介绍java的时候我们说到try...catch语句说我们还可以最后加一个finally，而且绝大多数情况下即使抛出了异常，finally块里的代码还是会被执行的。所以，我把打印测试结果和测试扫尾步骤放进去：
这样不管怎么样都会有测试结果。既然在这儿用了try...catch，我们就可以把其它测试类中的try...catch去掉，在方法名旁边抛出，这样所有的异常都会交给总控制类TestRunner.java来处理。以TCEmp1.java为例：
修改完成，你可以故意写错一些代码然后执行一下，看是不是异常被成功捕获。
下一步我想在抛异常的地方添加一个截图操作，忘记怎样操作截图的朋友可以再看前面文章复习一遍。和读取模块一样，截图属于功能性操作，我把它放在Utility.java里：
截出图片的名称会以“页面名称_时间.jpg”的格式出现。现在问题来了，应该在哪儿调用？是不是应该在catch里面呀？因为catch块被执行就意味着抛出了异常，所以我们把它加在TestRunner.java的catch块里：
故意改错一段代码让它抛个异常，可以看到截图生成在指定的文件夹，我就不截图了。
最后一个改动随你选择。有些人出于java封装概念的考虑，觉得是不是应该把从配置文件里读出来的浏览器、driver和路径都封装起来呀？不然总怕被随意访问。没问题，这三者属于环境信息，我们可以在com.testalliance.hrsystem.managers中新建一个类叫EnvManager.java：
然后写get/set过程，不多说，介绍封装的时候都说过：
最后修改DriverManager.java：
再运行一下，测试通过。
到此为止我就不再改了，经过这几篇文章对框架的修改，我们已经顺着数据驱动的思路搭建了一个简单的测试框架，其实还是个雏形。下一篇我们再总结一下我们这个雏形框架的组成。
