4、脚本扩展性差

　　测试人员在书写测试脚本时，往往只着眼于本身的测试项目以及已经规划好的测试案例进行定制，所以往往对测试脚本的可扩展性考虑的极少或者不考虑，这个可能是测试人员非常容易犯的错误，因为脚本只是着眼于现有的案例，虽然脚本做了一定的通用性和维护性，但是因为固化的测试案例通常会固化测试人员设计的思路，比如说：一个案例中3个输入条件通过测试行为得出一个测试结果，如果输入条件在程序中无法向后扩展的话，一旦测试案例的变更将导致测试脚本的失效。

　　测试变更的分析

　　在上面花了大量的篇幅说明可能导致测试脚本失效的种种因素：维护性差、通用性差、扩展性差等等，实际归根结底是因为软件开发所产生的变更所导致的。我们要完善好自身的测试自动化脚本，首先要分析我们需要考虑到那些变更，我们该如何来控制软件的变更，从而来实现软件测试的自动化。我们先来看一个测试案例：

　　1、打开google页面（www.google.com）

　　2、在搜索框内输入“pickaxe”关键字

　　3、点击“搜索”按钮

　　4、等待下个页面的出现

　　5、校验结果页面是否包含“Program-ming Ruby”这个关键字，“是”代表成功。“否”代表失败。

　　首先我们分析一下这个测试案例，在以后的维护中可能产生的变更包括：

　　1、测试数据导致的变更

　　案例中pickexe，以及Programming Ruby输入和输出的测试数据都会变化。

　　2、测试行为的变更

　　打开测试页面（www.google.com），点击“搜索”按钮。

　　3、测试步骤地变更

　　本案例中共有5个测试步骤，在现实过程中有可能出现步骤地变化，步骤3先于步骤2。

　　4、测试案例的组合变更

　　在现实过程中不会只有一个测试案例，一套测试程序往往可能由成千上万个案例去执行，往往案例存在着相互依赖的关系，比如说：B案例的执行要依赖于A案例执行的结果，而C案例又得依赖于B案例，而D案例却要依赖于B与C案例的执行结果。随着案例的量的增多，各种组合关系也越来越复杂，而且在维护期经常出现组合关系的变化。

　　所以本文将可能引起的测试变更分为四类：测试数据、测试行为、测试步骤、测试案例的组合。那么我们怎样有效地控制测试变更，如何在测试自动化脚本中有效地去解决这些问题？这就涉及到本文重点要提出的测试自动化框架。

　　测试自动化框架

　　本文之所以题为“测试自动化框架”而不是测试自动化，是因为测试自动化着眼于被测应用，而框架是在被测应用的基础上去实现一套方法去控制或管理者测试自动化过程的变化，从而达到最大程度的不同条件下的测试自动化。在谈这个方面之前，本文首先提一下两种现在非常流行的测试自动化方法：数据驱动测试、关键字驱动测试

　　● 数据驱动测试：从数据文件（数据池、ODBC源、cvs文件、Excel文件、DAO对象等）中读取输入和输出数值并载入到捕获的或手工编码的脚本变量中的一种框架。在这种框架里，输入数值和输出验证数值都使用变量。在测试脚本中编写贯穿程序的导航、数据文件的读取、记录测试状态和信息的日志代码。