软件测试自动化的探索与管理（七）

　　（a）自动化资源管理

　　公共函数和外部加载的其他组件资源是指自动化测试程序开发的时候能够被大部分编码人员引用的公共的类、函数、过程，这些公共函数是所有自动化测试框架必备内容。公共函数包括两大类，一种是测试程序里常用的自定义操作操作，这些公共操作的使用能够加快自动化测试的程序开发，实现一些测试工具之外的程序支持以满足测试模拟实现和测试结果校验的需要，是传统意义上的共有程序；另外一种是在测试工具自身函数基础上再次封装的处理操作，典型的代表就是前文提到的SAFRRON框架，它就是在QTP自带的类和方法上封装了一套新的操作，以VBS或者QFL和TXT等文件形式加载到QTP中去的。

　　公共函数文件的版本一定要进行严格的控制，不能随意更改。即便是有权限的人修改也要经过所有系统自动化测试开发负责人评审同意，如函数内容变更、参数变化等，可能对现有已经开发的测试程序有着非常大的影响。如果必须修改而又不能兼顾已有的引用，那么最好在原文件中新增一个函数以满足新的需求，只不过我们要尽量避免这种情况的发生，否则函数文件会越来越大，不利于维护管理。

　　提到异常恢复机制，大家自然会想起QTP的场景恢复这个功能来，事实上场景恢复只是异常恢复的一个方面。QTP的场景恢复是QTP自身的功能，他所能支持的异常恢复是比较有局限性的，下面我们简单讨论一下几种常见的异常恢复处理方法。

　　1、QTP的场景恢复，它能够发生异常的时候进行错误页面的清理，在一些特定的错误下做特定的处理，甚至能够重启操作系统。笔者理解，QTP的场景恢复是一个轮询任务，能够时刻关注测试运行是否发生异常，它的好处就是不用在每一个可能发生异常的步骤都去人工的写一个判断，测试脚本程序的开发比较简单；另一方面，场景恢复的用作是忽略或者处理掉一些非预期的异常，以便于下一操作步骤的继续进行，追求在一次测试执行中覆盖到更多的内容。

　　2、QC的运行恢复，位于QC测试实验室（Test Library）中，它能够针对测试流程中的每个可能运行失败的脚本程序做比较宏观的清理操作，对于运行环境不稳定所造成的运行失败、无逻辑先后关系的流程前置功能运行失败导致的后续测试运行无法继续，做很好的恢复操作。我们可以通过QC中的设置（参见下图三）使因别的运行失败而受阻导致失败的操作重新运行，并且可以在运行之前选择一个清理测试，通常笔者会选择重新登陆作为清理的主要手段，当然，在登陆操作中不会忘记先执行清理应用进程的操作。

图三Quality Center中的运行失败清理功能

　　3、除以上两种运行恢复机制外，还有一种恢复机制是针对运行失败产生的数据异常进行恢复清理的，它不是对当次测试运行实时产生作用的，只是对测试运行失败之后再一次运行所进行的处理。通常，由于运行失败之后产生了“脏数据”，再次运行很容易因为数据问题而出错，那么对运行失败之后产生的“脏数据”进行恢复清理是很有必要的，与上文提及的实现数据复用的方法类似，清理可分为前台和后台：

　　● 前台的清理操作，利用被测系统本身的功能，对运行失败的流程进行做类似流程撤销的操作，这种方法能使用的范围不大，仅限于有撤销功能的业务系统和操作。

　　● 后台的清理操作，使用数据库函数、过程，回退或删除已经运行失败的记录，以保证下一次运行可能成功。例如，使用上文中的QC场景恢复，在再次运行之前就需要调用一下测试流程实例运行失败之后的清理操作（参见图三）。

　　除此之外还有一些其他的恢复机制，比如开发插件程序等，对QTP运行的异常也可以进行处理，这里不再赘述。笔者个人认为，尽管QC+QTP这套工具在运行场景的恢复处理上比较有优越性，但是我们还是要尽量避免使用这些功能，因为使用这种功能无外乎三种情况：第一，测试环境因素导致的运行失败；第二，测试脚本程序逻辑、对象、数据本身存在问题；第三，被测程序功能存在问题。对于第一种情况，例如网络异常、执行客户端的资源紧张或者应用系统服务本身有问题导致的运行失败，我们需要着力解决环境的稳定性问题。如果环境出现问题，运行恢复使用的再好也是没有意义的，除非有一套能够实时修复测试环境的机制。对于第二、第三种情况，笔者认为有两种流程结构：

　　● 执行流中的业务操作之间是相互独立的，如一系列的查询或设置操作，假设由于第1个查询出现了程序异常，页面上出现了未预期的对话框或模态窗口，那么如果不做处理，后续的查询操作都可能因此运行失败，那么我们可以选择使用QTP的场景恢复也可以选择QC的运行恢复来保证其他功能的运行。但是我们需要注意，场景恢复默认只是给测试结果中添加一个告警，而从整体的报告里观察出来的结果只有成功、失败两种，如果不够细致，那么很多人会因为告警的测试结果太多而忽略它，从而忽略了测试脚本程序逻辑、对象、数据问题甚至是被测程序功能的缺陷。

　　● 执行流程中的操作有逻辑先后关系或者是有数据依赖关系，那么场景恢复在整个测试流程中的作用就好比是VBS运行时catch exception使用的on error resume next，如果是为了获取错误码，用起来则是无可厚非，如果后续的对象是来自于已经发生异常的声明或构造中，那么运行下去就没有意义了！试想一下，前一个步骤运行失败了，后续的业务流程能够成功么？追求更多的测试覆盖只能带来更多运行失败的测试结果，消耗测试、编码人员更多定位问题的精力，所以笔者认为QTP的场景恢复功能是不能用于有逻辑先后关系的流程测试当中的。当然QC的运行恢复可以有限制的使用一些，在一些能够重新运行的节点上可以试着重新运行一次，如果两次连续失败，那么我们认为必定是存在某一方面的问题的，如果能够重新运行成功，那么环境、数据存在问题的可能性就比较大了。

　　抛开运行环境问题不论，无论是QTP的场景恢复功能还是QC的运行恢复机制，他们的最终的目的是在运行已经发生异常的情况下争取最大的测试执行覆盖面，最直接的作用就是在测试脚本程序开发的时候节省手工的运行逻辑判断，减少开发工作量，降低开发难度。特别是在测试脚本程序层面上，QTP场景恢复的使用实质上是降低了对测试脚本程序的要求，是录制、回放级别自动化测试应用较多的功能之一。笔者提倡将异常判断写在程序里面，并且根据各自系统的特点对判断逻辑加以丰富，不要过于依赖场景恢复功能。这些判断处理可以写在一个公共的可复用Action中或者Function文件里，测试操作一旦触发了业务系统前后台交互，都可以进行调用，这样，牺牲几秒钟的判断时间可以赢得最真实的测试结果，并且一定程度上能够根据用户的选择对系统的异常进行相应的处理。

　　这样看来，其实场景恢复是不应该出现在关键字驱动的框架里面的，我们框架下所需要的异常恢复机制应该从不同的层面划分，然后分别纳入测试脚本资源和运行平台等各个关键模块中去。当然也可以把异常恢复机制抽取出来，独立成一个框架组件。