自动化脚本与用例

　　脚本和用例，永远是分不开的两个连合体，脚本对应着用例，用例依附着脚本。

　　到目前为止，我们一直是以用例为视角来管理脚本，从测试管理来看，这是合理的，因为我们在执行和分析执行结果时，用例更能反映产品的测试情况，因为整个测试工作是以测试用例为中心展开的。

　　但对于脚本的维护，我们如果从脚本的视角来管理，会给我们带来下面几个有利的地方。

　　其一：因为是从用例来看脚本，所以脚本和用例的N对一关系不清晰，无法一目了然的知道一个脚本对应哪些用例。而反过来从脚本视角看用例，那么脚本对应的用例就一目了然了；

　　其二：脚本编辑时，所有的脚本相关的信息都可以在一个界面完成展示，那么对于脚本的编辑维护是非常有利的；

　　其三：脚本视角，也让我们能更好的处理自动化脚本对功能测试用例的覆盖，毕竟是大包小的关系。反过来，相信大家已经能感受到其不方便的地方。

　　这里提到了脚本对用例的覆盖，其实我们一直强调脚本要尽量简单，而不是一个脚本尽量覆盖更多的功能测试用例，这样做会导致自动化脚本太重、太复杂，那么执行起来脚本的稳定性反而下降。我们覆盖更多的用例，本意是能让我们少写一些脚本，节省我们的工作量，然后脚本不稳定加大了脚本的维护成本，那么我们的工作量可能不降反升。并且复杂的脚本对于用例失败的排查也是不利的，因为覆盖的用例范围扩大了，那么排查的范围也就扩大了。自动化脚本也是代码脚本，所以也需要我们要求脚本的低耦合，高内聚，而不是一味覆盖更多用例。

　　自动化脚本和用例，个人看法是在维护管理上脚本视图是更为有利，执行和分析上用例视图是更为合理，两者很好的结合才能更好的帮助测试人员开展测试工作。

　　常用的自动化测试框架

　　1.1 录制/回放测试框架

　　录制/回放测试框架所采用的原理是通过录制应用程序产生的线性脚本进行回放从而达到自动化测试的目的。

　　其优点是简单，通过录制就可以得到所需脚本。但同时也有很大的缺点，它不具有逻辑判断的能力，可维护性差，效率低下，建容量差。

　　1.2 数据驱动的自动化测试框架

　　该种框架的原理是采用了数据驱动脚本进行测试，数据驱动脚本是将数据输入存储在独立的数据文件中，脚本只存放控制信息，测试时输入直接从文件中读取，这样同一脚本可以运行于不同的测试用例中，实现了脚本与数据的分离。

　　其优点为可以快速增加相似测试，测试者增加新的测试不必掌握测试工具语言，对此后的类似测试无额外维护开销。

　　缺点是初始建立测试脚本的开销较大，进行数据扩展的脚本需要针对相同的测试内容并具有相同的测试逻辑。

　　1.3 关键字驱动的自动化测试框架

　　关键字驱动（表驱动）是对数据驱动的逻辑扩展，它的核心思想可以概括为“三个分离”：

　　（1）界面元素名与测试内部对象名的分离：在被测应用程序和录制生成的测试脚本之间增加一个抽象层，它可以将界面上的所有元素映射成相对应的一个逻辑对象，测试针对这些逻辑对象进行，界面元素的改变只会影响映射表，而不会影响测试。

　　（2）测试描述与具体实现细节的分离:把测试描述和测试的具体实现细节分离开来。测试描述只说明软件测试要做什么以及期待什么样的结果，而不管怎样执行测试或怎样证实结果。这样做是因为测试的实现细节通常和特定的平台，以及特定的测试执行工具有着密切的联系。这种分离使得测试描述对于应用实现细节是不敏感的，而且有利于测试在工具和平台间的移植。

　　（3）脚本与数据的分离:最后，可以把测试执行过程中所需的测试数据从脚本中提取出来，在运行时测试脚本再从数据存放处读取预先定制好的数据，这样脚本和数据可以独立维护。

　　以上这“三个分离”各司其职、互相独立，最大程度地减少相互之间的影响。从关键字驱动的思想可以看出，该种测试框架不仅实现了将数据和脚本相分离，而且实现了测试逻辑和数据的分离，大大提高了脚本的复用度和维护性，从而更大限度得实现了测试工具的自动化。