ZT - RFT ScriptAssure 技术解析及应用实例(1)

章 国俊, 高级软件工程师, IBM

章国俊，高级软件工程师，拥有 7 年软件测试自动化相关经验。近年来一直致力于 IBM Quickr 产品的自动化测试改进、创新和团队培训工作。对测试技术、软件过程及软件质量控制有着浓厚的兴趣。业余时间喜欢阅读、桌游、旅行和美食，并有若干 IT 和非 IT 类的文章发表。

简介： 本文由自动化测试中的脚本独立性谈起，深入介绍 Rational Functional Tester（RFT）中所提供的高级特性 ScriptAssure，看它是如何均衡脚本的可靠性和可维护性。文中实例可以帮助读者实践不同模式下的回放过程，增加对 ScriptAssure 技术的感性认识。

[@more@]

缘起：脚本独立性和脚本依赖性

在引入正题之前，让我们先了解一下自动化测试中的脚本独立性和脚本依赖性。自动化测试脚本的依赖性，是指在某些情况下，一个测试脚本必须依赖另一个测试脚本来完成一些关键性的工作。通常我们把这些依赖性分为两类：因为等待某些应用程序数据而依赖其他脚本，或因为等待某些应用程序状态而依赖其他脚本。

数据依赖

脚本的应用程序数据依赖于其他脚本来创建或维护。

状态依赖

脚本的应用程序起始状态依赖于其他一些脚本来导航和控制。这些脚本不启动应用程序，而是在应用程序中间某处开始执行。

通常情况下，执行顺序对于依赖性脚本非常重要。依赖性脚本仰仗于之前的程序数据或程序状态的变化，那些被依赖的脚本必须在它们之前以特定顺序运行。如果它们的运行顺序有变，脚本将极有因为数据丢失或错误数据而失败。“测试脚本的独立性”并不完全是“脚本的依赖性”的对立面，但很接近。脚本独立性是指您的脚本都完全可以自给自足。测试脚本不需要依赖其他脚本来完成一些必要的工作。通常情况下，脚本独立性使得执行顺序并不重要，任一脚本都可以在任意时间执行。

在这一点上，独立的测试脚本似乎是一项明智的选择，那么为什么还要有依赖性的脚本存在？通常，脚本依赖性可以提升模块化程度，减少脚本的代码量（由于代码重用率较高）。这往往导致对代码维护的成本降低，因为有代码重用后总量更少了。例如，假设您只有一个登录门户的脚本，其他所有脚本都必须依赖于它登录到应用程序。在这种情况下，如果登录界面更改或登陆流程发生变化，你只需要更新一个脚本（而非所有涉及到登录的脚本）。

这又引来了对于自动化测试里记录和回放模式的一个经典的争论：脚本的独立性越高，就意味着你受应用程序的牵制越多，增加了程序维护的成本；而脚本依赖性则是试图减少开支。通过共享应用程序数据来降低测试案例数目，通过共享应用程序状态及模块化帮助你得到更健壮的测试案例。一言以蔽之，脚本的依赖性，会有助于降低代码量及维护成本。

当然，另一方面，脚本依赖性也不是十全十美的。依赖性脚本会导致阻塞性的错误。这种阻塞问题往往是一个产品缺陷，但它在被修复前会阻碍之后所有相关任务的执行，这会形成自动化测试和脚本的瓶颈。有了依赖性后，如果第一个脚本失败，该脚本之后的所有脚本都有可能失败。而且有了脚本依赖性，应用程序状态和数据共享也成为一个问题，数据共享和程序状态共享会使得脚本更为复杂，开发人员很难定位出错原因，这会严重影响可靠性。一般来说，独立的测试脚本此时则显得更为可靠。

从下图可以看出，随着脚本可靠性的增加，它的可维护性会必然下降，两者相互牵制。

图 1. 脚本的可维护性和可靠性

这是我们在进行自动化测试的策略制定、规划及开发过程中必须要做出的抉择，与此同时，我们也积累了很多办法来在这两者间取得一个最佳的平衡，让可靠的独立性脚本更加易于维护，或让强依赖性脚本变得更加可靠。本文要介绍的 Rational Functional Tester 中所应用的 ScriptAssure 技术就是其中的佼佼者。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/16896827/viewspace-1036470/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/16896827/viewspace-1036470/