这是应用 IBM Rational Functional Tester 实现测试自动化框架的三部系列的第二篇文章，重点在于创建一个数据驱动的框架。本系列的其他文章涵盖了模块化和关键字驱动的框架。 这是应用 IBM Rational Functional Tester 实现测试自动化框架的三部系列的第二篇文章。一个测试自动化框架是为软件自动化测试提供支持的一组假设、概念和实践。在本系列中所涵盖的三种框架类型包括模块化、数据驱动和关键字驱动。本文将特别侧重在创建一个数据驱动框架的方面。 数据驱动测试是一项单个测试脚本使用不同的输入和响应数据被重复地执行的技术，这些数据来源于一个预定义的数据集。在 Rational Functional Tester 中，数据驱动测试可以通过不同的数据池来实现，数据池是相关数据记录的集合，用以在测试脚本回放时为测试脚本提供变量的值。当您使用数据池时，Rational Functional Tester 能在您每次回放脚本时将一组不同的测试数据或相同的测试数据提交到测试脚本。您使用数据池来提供真实的数据，并用不同的数据和实际的数据量来产生对应用程序压力。当您运行一个数据驱动脚本时，Rational Functional Tester 将从数据池的当前行中输入每一个值（数据池中的一行看起来就象电子数据表中的一行）到应用程序的适当字段中。在每次执行脚本时，假定数据池光标在前面（数据池光标是对当前行的指针），下一个数据行将被输入。 在这个系列的三种框架中，数据驱动是最容易在 Rational Functional Tester 中实现的。下一部分我们将着眼于 Rational Functional Tester 中的数据池，帮您了解一下这个工具的内置特性。之后，文章将对这种方法进行利弊讨论。 在 Rational Functional Tester 中使用数据池进行工作 在 Rational Functional Tester 中，一个数据池是相关数据记录的一个集合，用以在测试脚本回放时为测试脚本提供变量的值。当您在 Rational Functional Tester 里创建一个数据驱动测试时，您可以用不同的输入和响应数据来重复地使用单个测试脚本。下面介绍的是一些在 Rational Functional Tester 里有关数据池的术语，以及如何创建和使用一个数据池。 Rational Functional Tester 通过引用数据驱动一个测试脚本来使用数据池 。当您在文档中看到这个术语时，它提到了构建您的测试脚本中的对象和您数据池中的数据之间的连通性的过程。要数据驱动一个脚本，您需要在被测试应用程序中选择一个对象，然后 Rational Functional Tester 将应用程序里的数据填充到一个数据池。 在 Rational Functional Tester 中使用数据池进行工作 让我们使用 Rational 的测试应用程序 ClassicsCD 来记录一个简单的数据池。 在 Rational Functional Tester 里开始记录一个新的测试脚本。 Datapool Record Selection Order 框的值是 Sequential 和 Random。Sequential 指在回放时，测试脚本访问数据池中的记录是按照它们出现在数据池中的顺序来进行。Random 是指在回放时，测试脚本每次随机地访问数据池中的每条记录。 这此例中，接受缺省设置并点击 Finish。 图2. ClassicsCD Member Login 窗口 图3. Insert Data Driven Actions 对话框 使用鼠标将 Object Finder 工具拖拽到 Member Login 窗口中的Full
Name 字段。 图4. 带有测试对象的 Insert Data Driven Actions 对话框 如果您在刚刚记录的脚本里查看代码，您应当看到类似于列表1中的一行代码。 列表1. 在 Rational Functional Tester 中记录的数据池调用
在这段代码中，您选择与命名为nameCombo的数据池列中的值相匹配的组合框值。如果您在 Script Explorer 中打开 Private Test Datapool，您应当看到在第一行中所列出的您所记录的数据，如图5所示。 图5. 在 Private Test Datapool 中记录的数据 图6. 在 Rational Functional Tester 里编辑一个数据池 数据池文字替换 Rational Functional Tester 提供了一种能力，可以用一个数据池引用（一个数据池引用是对有一个关联数据池的另一种说法）来查找或替换一个测试脚本中的文字值。在工具栏或者脚本菜单中，您可以访问 Datapool Literal Substitution 对话框，如图7所示。 图7. Datapool Literal Substitution 对话框 数据池作为验证点 您可以使用一个数据池引用来替代您正在验证点中测试的值的一个文字值。在记录时，如果您使用 Verification Point and Action 向导插入一个证实点，您可以通过点击向导的工具栏中的 Convert Value to Datapool Reference 按钮，将验证点值转换为一个数据池引用。这个按钮用红色圆圈标记，如图8所示。 图8. 将验证点转换成数据池引用 导入和导出数据 如果您在 IBM? Rational? TestManager 中已经有数据池了，那就没问题了。您可以将它们导入到 Rational Functional Tester 中，同样您也可以使用电子数据表格应用程序创建的任何简单格式的已有.csv文件。反过来也一样。只要您将所有数据放入 Rational Functional Tester 中，您就可以将数据池导入到一个 .csv 文件中，用一个电子数据表格应用程序来编辑它。在 Rational Functional Tester 的帮助文件中有如何进行这样做的指导。 一个用 Rational Functional Tester 进行数据驱动测试的简单例子 好了，已经向您介绍了使用数据池的基础知识，现在您将看一个有关数据驱动测试更加详细的例子。这个例子将使用 www.Google.com作为测试。Google Web 搜索有一些您将要测试的内置特性。这些特性包括：计算器、货币兑换、电影、号码搜索，以及旅游信息（以命名包含在强大的小文本字段中的许多特性）。记录的脚本如列表2所示，启动浏览器访问 Google.com ，然后执行一系列搜索和验证点，以验证上述特性。 列表2. 记录和回放 Google Web 搜索脚本
在图2所示的脚本中，测试的每个特性都记录了在搜寻文本字段中进行一下点击、输入搜索标准、点击搜索按钮、验证结果，并在结果页的左上角点击 Google 图象以为下个特性测试重新设置浏览器。在这里有许多重复的代码。列表3显示了相同的测试脚本，只是脚本现在是数据驱动的。 列表3. 数据驱动的 Google Web 搜索脚本
通过使用一个for循环（您也可以使用一些其它类型的循环），并且通过增量的移动数据池里的光标，您可以避免多次重复相同的代码。您所做的全部就是在 inputChars 中为搜索字段增加一个数据池调用，并向您的验证点上增加一个数据池引用。在您想要增加另一个测试时，只要向您的数据池中增加另一行，并在循环中增加计数器的值。在图9中显示的数据池显示了每个测试的搜索标准和搜索结果。 图9. 数据驱动脚本的数据池值 数据选择是沿着数据驱动测试之路的第一步。您需要选择驱动您的应用程序运行的数据，或者表示将输入到您的应用程序中的数据，或者两个都选。本节将迅速查看一下选择数据进行测试的5 种不同方式：基于风险、基于需求、基于可用性、使用生产数据，或者随机使用产生的数据。 选择基于风险的数据。选择测试数据的头号标准应当是风险。当您识别风险时，您要考虑到什么会导致出错。您正在寻找可能会发生的事件，这些事件将减少您能够交付带有正确特性、所要求的质量级别和在预算之内的项目的可能性。有三种划分风险种类的方法：
此外，考虑在被测试的元素上不同的目标部署环境将有什么冲突。您所选择的数据列表应当包括针对被测试应用和目标环境的数据。您需要测试什么数据：
用一种易于访问的格式生产数据（在以后的章节里详细讨论）
这里的想法是，如果数据是容易访问的，也是易用和有意义的，在您的测试中包括这些数据，可以节省时间和金钱。我强调易用性和有意义的，是因为您需要记住一件重要的事情，您不应该只是因为数据已经在那了并且是可以使用的就选择它－－因为它可能是坏数据。 使用生产数据。收集测试数据的另一个策略是使用生产数据。尽管您不应当单独地依赖这种类型的数据，它可以是自动化测试场景的最丰富的来源，因为数据是应用程序将面临的真实场景的代表，并且因为它很可能将提供大量的不同场景。在一个最近的项目中，我们大约每周从一张表格中读取一次生产数据，并且我们在没有付出多少努力的情况下得到了300到500个场景的奖赏。您可以直接将数据导入测试环境里，将它读入到数据文件中用于后面的处理，或者实时地读取它，并按照您所的需要的他们进行转换。生产数据也是并行测试的一个极好来源。如果您在正在开发的系统中使用生产数据，您就会迅速地知道是否被开发的系统能够象在生产环境一样工作。这项技术特别有助于发现使用浮点值、转换率，以及与数据类型相关长度的问题。 但是，使用生产数据有一些需要小心的地方。生产数据很可能不包含您想要测试的许多特殊情况, 并且这不是理想测试场景的一个替换。还有一些潜在的法律问题围绕着生产数据的使用。特别是如果您把一些您的测试外包给另一个公司，您将想要确保检查您的公司在生产数据使用上的公司政策；如果没有已有的正式政策，您需要询问您公司法律部门的某些人。即使如果您不能直接使用生产数据，您也可能有更改某些值（名字，社会安全号，等等)和使用其余数据的可能性。 使用随机数据生成。很多工具包括测试数据生成程序。随机数据生成程序在产生大量用户数据的过程中特别有帮助（这取决于您正在测试什么和您想在产生过程中花费多长时间）。例如，如果您需要对金融信息进行关于舍入错误的测试，您可以：
如果您需要，例如，要生成一组500个不同的客户名称及地址，您可以有一个生成程序(TestManager，Excel，Google Sets，等等)来创建一个带有名称和地址的表。 您应当避免一次选择您所有的测试用例中的数据。相反，采取一种增量和迭代的使用测试数据的方法，将您的工作量集中在您认为最有可能产生的对于既定测试周期有用的评估信息上。这会帮助缓和在一组单个数据或者测试类型上付出太多时间的风险 －－ 疏忽其它数据或测试任务 －－ 并且最小化在某些今后可能并不受关注的测试想法的数据上花费工作量的风险。 在本系列所涵盖的三类框架中（模块化、数据驱动, 以及关键字驱动），数据驱动框架对于非技术人员是最容易实现的，因为几乎所有的功能都被构建在 Rational Functional Tester 中，并且支持执行记录和回放。这对于非技术人员（对于我来说没有充分的理由推荐它）来说，不但是简单的，而且是强大的。它导致了半自动文档化测试用例，减少了创建大量测试用例所要求的代码数量，并且使您可以进行一些测试类型，否则您必须进行耗时或麻烦的手工测试工作。 数据驱动框架的主要优势是它减少了为很多类型的应用程序创建测试用例的成本。例如，在金融服务或者保险应用程序中数据驱动框架是非常有价值的。在您查看一千个变量中的一个变量是如何影响一笔复杂计算的最终金额的地方，对于金融服务或保险应用程序，很多次测试用例都只有细微的差别。对于一个数据驱动的工具，您将会很难找到一个更好的市场。另一方面，我曾经参与一个涉及化学制图和化学合成分析软件有关的项目。对于这个应用程序，测试用例非常特殊和集中（并且依靠于GUI），以至于数据驱动框架就没有意义了。 数据驱动框架最大的缺点之一是，它创建新的测试用例太容易了。因为测试用例易于创建，您能够简单地运行和维护测试，这有时会导致测试用例膨胀。这不一定是一件坏事 －－ 这就是您为什么想要使用类似的工具的原因之一。如果您只是因为测试用例容易创建，而不投入许多时间和金钱来维护测试集，那就要小心了。如果只是为了看到发生什么而创建一个廉价的测试并运行一次，那可能是值得的，但是一旦您开始在您的应用程序的多个版本上开始维护测试，测试的成本就开始提高了。您想要确保维护成本的合理性是足够有力的。 考虑一下能在您的自动化测试中使用的一些数据驱动测试的方式。寻找一下您发现您自己一再调用相同代码的地方 －－ 就有可能发现在这些地方使用数据池的机会。不要觉得好像如果您想要进行数据驱动测试，您就需要立刻转换您所有的脚本。您不用这样。只要创建所需要的数据池，并且随着时间的过去，您将会把您的测试自动化发展成一个框架，在框架中，您将数据池作为脚本生成的一个基本部分。在许多应用程序中，对已有的数据池有高级的重用。正如 DBA 花费时间组织它们的数据一样，您也要花费时间组织您的数据。 |
