3、除以上两种运行恢复机制外，还有一种恢复机制是针对运行失败产生的数据异常进行恢复清理的，它不是对当次测试运行实时产生作用的，只是对测试运行失败之后再一次运行所进行的处理。通常，由于运行失败之后产生了“脏数据”，再次运行很容易因为数据问题而出错，那么对运行失败之后产生的“脏数据”进行恢复清理是很有必要的，与上文提及的实现数据复用的方法类似，清理可分为前台和后台：
● 前台的清理操作，利用被测系统本身的功能，对运行失败的流程进行做类似流程撤销的操作，这种方法能使用的范围不大，仅限于有撤销功能的业务系统和操作。
● 后台的清理操作，使用数据库函数、过程，回退或删除已经运行失败的记录，以保证下一次运行可能成功。例如，使用上文中的QC场景恢复，在再次运行之前就需要调用一下测试流程实例运行失败之后的清理操作（参见图三）。
除此之外还有一些其他的恢复机制，比如开发插件程序等，对QTP运行的异常也可以进行处理，这里不再赘述。笔者个人认为，尽管QC+QTP这套工具在运行场景的恢复处理上比较有优越性，但是我们还是要尽量避免使用这些功能，因为使用这种功能无外乎三种情况：第一，测试环境因素导致的运行失败；第二，测试脚本程序逻辑、对象、数据本身存在问题；第三，被测程序功能存在问题。对于第一种情况，例如网络异常、执行客户端的资源紧张或者应用系统服务本身有问题导致的运行失败，我们需要着力解决环境的稳定性问题。如果环境出现问题，运行恢复使用的再好也是没有意义的，除非有一套能够实时修复测试环境的机制。对于第二、第三种情况，笔者认为有两种流程结构：
● 执行流中的业务操作之间是相互独立的，如一系列的查询或设置操作，假设由于第1个查询出现了程序异常，页面上出现了未预期的对话框或模态窗口，那么如果不做处理，后续的查询操作都可能因此运行失败，那么我们可以选择使用QTP的场景恢复也可以选择QC的运行恢复来保证其他功能的运行。但是我们需要注意，场景恢复默认只是给测试结果中添加一个告警，而从整体的报告里观察出来的结果只有成功、失败两种，如果不够细致，那么很多人会因为告警的测试结果太多而忽略它，从而忽略了测试脚本程序逻辑、对象、数据问题甚至是被测程序功能的缺陷。
● 执行流程中的操作有逻辑先后关系或者是有数据依赖关系，那么场景恢复在整个测试流程中的作用就好比是VBS运行时catch exception使用的on error resume next，如果是为了获取错误码，用起来则是无可厚非，如果后续的对象是来自于已经发生异常的声明或构造中，那么运行下去就没有意义了！试想一下，前一个步骤运行失败了，后续的业务流程能够成功么？追求更多的测试覆盖只能带来更多运行失败的测试结果，消耗测试、编码人员更多定位问题的精力，所以笔者认为QTP的场景恢复功能是不能用于有逻辑先后关系的流程测试当中的。当然QC的运行恢复可以有限制的使用一些，在一些能够重新运行的节点上可以试着重新运行一次，如果两次连续失败，那么我们认为必定是存在某一方面的问题的，如果能够重新运行成功，那么环境、数据存在问题的可能性就比较大了。
抛开运行环境问题不论，无论是QTP的场景恢复功能还是QC的运行恢复机制，他们的最终的目的是在运行已经发生异常的情况下争取最大的测试执行覆盖面，最直接的作用就是在测试脚本程序开发的时候节省手工的运行逻辑判断，减少开发工作量，降低开发难度。特别是在测试脚本程序层面上，QTP场景恢复的使用实质上是降低了对测试脚本程序的要求，是录制、回放级别自动化测试应用较多的功能之一。笔者提倡将异常判断写在程序里面，并且根据各自系统的特点对判断逻辑加以丰富，不要过于依赖场景恢复功能。这些判断处理可以写在一个公共的可复用Action中或者Function文件里，测试操作一旦触发了业务系统前后台交互，都可以进行调用，这样，牺牲几秒钟的判断时间可以赢得最真实的测试结果，并且一定程度上能够根据用户的选择对系统的异常进行相应的处理。
这样看来，其实场景恢复是不应该出现在关键字驱动的框架里面的，我们框架下所需要的异常恢复机制应该从不同的层面划分，然后分别纳入测试脚本资源和运行平台等各个关键模块中去。当然也可以把异常恢复机制抽取出来，独立成一个框架组件。
版权声明：本文出自 lyscser 的51Testing软件测试博客：http://www.51testing.com/?68857
原创作品，转载时请务必以超链接形式标明本文原始出处、作者信息和本声明，否则将追究法律责任。
相关链接：
