（e）自动化运行管理

　　测试运行的主体是测试调度管理，QTP自动化测试的运行调度方式有很多种，下面简单罗列一下几种常见的方式：

　　◆ 最为经典的就是QC自带的任务控制工具，使用起来快捷方便，并且QC本身就包含对邮件服务的配置、使用，同时也有着比QTP场景恢复更为宏观有效的异常处理机制，有着灵活的参数配置功能；只是定制并行执行计划比较不方便，由于无法预知每个流程运行的结束时间从而导致后一个流程开始的时间无法确定。这种调度主要使用在多人监管的情况下，多人使用多台机器登录，同时使用QC调度测试任务，否则在批量设置任务的时候比较不方便，容易造成执行冲突或者时间浪费。

　　◆ 还有一种思路就是基于QC预留的Open API重新开发控制工具，结合EXCEL或者数据库表的执行队列统计控制。引入对QC接口的调用，获取QC中指定测试脚本、测试集实例，配置一定的参数去执行，测试结果依然保存在QC中，测试报告依旧可以通过QC的报表系统出具。这种模式的调度控制的好处是可以轻易的批量设置任务，控制执行的先后顺序，通过主机状态的判断就可以判断上一个流程是否运行完毕；能够根据项目和系统的特点定制周期性的工作计划；同时这样做也保留了QC测试集本身的异常处理机制和灵活的参数配置功能。

　　◆ 最后一种是完全脱离QC，使用VBS或者其他程序直接控制脚本运行，把测试结果统一写入指定的数据库或者EXCEL中去。这是广泛应用于那些没有正式采购QC工具但是使用着QTP进行自动化测试的公司的一种常见的方法，这种做法在工具采购上比较节省，开发出来的程序轻巧灵便，但是管理起来较为复杂、费力。

　　流程和执行任务（Schedule）的定义要根据运行频度需求和运行的数量、所具备的执行客户端资源数量来进行。例如今晚需要执行40个系统的8000个自动化测试案例，其中30个系统必须完成测试执行，其余10个可延后，能够提供的虚拟机有25台，那么总的执行时间长度和每个系统的先后顺序，每个系统内部流程的先后顺序等该如何定义都需要有一套易于设置并且支持随时变更的规则和方法。我们公司的方法是把所有任务队列都录入数据库中，编写一组package用于任务设置和数据计算，支持每天几万个自动化测试脚本的运行调度。至于如何配置测试设备和理清测试优先级想必无需多说，也说不清，因为咱们的情况可能不一样。除了任务的配置和调度之外，笔者想指出两点：

　　◆ 运行时的异常恢复机制应在测试运行管理中突出完成。因为异常本身就是出现在自动化测试执行的时候，在运行平台中对异常的规避和处理是理所应当的；如果有能力和资源去实现这部分功能，最容易实现的就是在测试运行管理组件设计的时候。除上文的数据异常处理之外，运行时的操作系统错误、工具异常（如QTP、EXCEL等）、运行载体（如IE等）异常等都需要在运行管理组件中得到处理。异常处理其实并不是很复杂的东西，例如我们可以使用简单的vbs写一个轮询操作系统进程的小程序，在出错时结合批处理脚本程序等进行运行环境清理和恢复，并且对当前被终止的测试流程做标记或者触发重新运行等。

　　◆ 自动化运行期间对测试环境需要进行监控和管理。尤其在一个业务系统较多、系统之间的耦合性较强、版本发布频繁的公司，由于种种因素，测试环境显得比较脆弱。例如在一个公司中，所有的系统可能都要经过同一个用户验证系统，那么所有系统的自动化测试执行都将依赖这个系统服务的正常运行。对测试环境常见的监控包含如下方面：

　　● 确保公共系统和关联系统的正常运作，必要时可以强制启动其对应的服务，如果不能保证的情况下如果发生异常就应该停掉所有的测试运行，否则就是对测试资源的浪费；

　　● 确保版本的部署正常，通过对中间件日志的监控可以得知相关的应用状态，如果一个系统的部署失败导致服务无法正常启动，无人工干预的情况下应该停止该系统的测试运行；如果只是部署人员正在进行版本发布，则可以考虑延后一个或几个小时再开始测试运行；

　　● 某个系统如果只是简单的服务Down掉，则在运行之前可以通过测试运行调度程序去启动该系统的应用服务，当然每次这种由平台触发的操作都需要记录到平台日志当中的。

　　监控测试环境的目的主要是确保测试运行的有效性，以不至于因为对批量异常数据进行分析而浪费时间和人力，其他类型的问题处理笔者这里不再赘述。