在第二个流程中，同样会采用文件的方法去控制测试数据的变更，但这里我们将测试数据也进行分层控制。测试数据驱动关键的技术，是如何进行测试数据框架的设计。在笔者的实践中，我们将测试数据同样分为三层：高级数据层（测试行为层）、中级数据层（数据操作层）、低级数据层（数据定义层）。数据分层处理将有效降低数据的变化对测试脚本的影响。例如，一个登录案例：用户打开一个网页，在Userbox和passowrdBox中输入用户名（1234）和密码（1234）后按登录按钮，我们尝试将行为数据和测试数据进行分类控制，来确保测试数据变化引起的变更低。

　　从数据定义框架来看，软件中出现任何变更，只要修改相应部分数据的定义，而不会影响测试脚本的变化。比如：测试操作中需要增加一个校验码时，我们只需要在数据操作层增加一个校验码的行为，并补充上对应的测试数据定义层，程序仍然能够完成对应的测试操作，不涉及到程序的返工和重写等。而且程序的分层定义，带来另外一个好处，是测试框架具有可读性以及方便维护性。

　　2、测试框架的独立性

　　在测试数据独立性以及流程总控中，主要是控制由应用本身所引起的变化，在对于自动化框架来说，框架本身应提供足够的灵活性来支撑应用的变化，所以自动化框架后三点：独立性、原子性、可扩展性，主要是围绕着框架本身来定义的。所谓的框架，它所适应的不能是某一个应用，而是同一类型的许多测试应用。所以测试框架的搭建，先要避开应用的框架，而去寻求这一类型的框架公共组件，使得测试框架具有更好的复用性，而且每个组件之间也应具有相对的独立性，这样才能确保将影响降到低。一个应用往往在测试行为上表现为需要点击什么按钮、选择什么菜单、下拉列表框，从不同类型文件中读取或者书写测试数据等等，不同的应用，它所涉及到行为具有很多的通用性，只是数据选择的不同，所以测试框架搭建时，要提取这些通用性组件，然后进行封装，提供简易的接口交付上层的应用框架调用。这样的独立性保证了框架的变更同样不会影响脚本的执行。例如：watir框架中提供的为tesxtfield填写数据函数：

　　Object.text_field(:***， 'value').set(string)

　　这个函数的发布，只要涉及到向textfield中填写数据的脚本，都可以调用，而不涉及到框架的修改，即使特殊的需求需要修改框架，只要框架的接口不发生变化也同样不会影响到上层的应用程序。

　　3、测试框架的原子性

　　测试框架的原子性在测试同行中也有人说是测试模块化。大家都知道如果把测试行为合在一起，虽然可能前期的开发会减轻，但往往后来的维护性非常差。如果模块细化至低层，那将测试变化的力度控制在小范围内，例如上面的登录案例，按钮点击可以说是基础的一个操作，也是测试中控制的小单位，我们将这个行为作为一个原子封装起来，这样即使以后按钮的测试行为出现任何变化，我们的修改范围也仅缩小到button这一个函数内。如果独立性完成的非常好，可能仅仅涉及应用的某一个点或者框架的某一个点上，而不至于修改整套脚本。所以测试框架第三个原则，在对框架分析过程中，尽量使得测试框架原子化。

　　4、测试框架的可扩展性

　　可扩展性往往是很多人忽视的方面，比如说：现在很多自动化测试框架在写button这个函数时，会提供按照名字或者值进行判断然后进行点击操作，但是如果一个页面出现两个同名同值的button，而应用可以根据另外一个关键字来判断，但脚本中的其他页面都不存在这种问题，这时如果框架不提供足够的可扩展性将会导致整个框架的失效，当然可以再次修改框架，但是时间的消耗远远大于扩展性的脚本开发。所以在测试组件设计时应考虑到维护时的可扩展的行为。