Compartilhar via

TAO 项目: 一个直观的UI 测试工具集（二）

  • Artigo

    上一篇文章向大家介绍了我们设计的一套GUI测试工具组，并称之为“Tao项目”，帮助我们更高效地测试软件的用户界面。在这篇文章里，我们将具体介绍Tao的重要组成部分和工作流程。

    让我们先看一下Tao项目的工作流程及其三个关键组成部分：

图1. TAO项目的工作流程

图1. TAO项目的工作流程

一、用户引导的测试用例生成器

   对于任何对话框，有经验的软件测试开发工程师都可以很快给出一些标准GUI测试用例。例如，测试一个输入框，你可能创建输入最长和最短字符串的测试用例，或者输入带有特殊字符但匹配正则表达式的字符串，或者输入带有Unicode的字符串。我们将这些经验归纳成知识基础，并输入到测试用例生成器（简称TAG）中，TAG把它们抽象成了模型。然后，用户只需提供最少的引导，TAG会自动完成这些模型的实例化，包括生成GUI状态、GUI操作、和测试准则等，并自动生成测试用例和相应测试用例自动化代码。测试用例自动化代码中包括如何打开对话框，如何发现GUI对象，如何实施GUI操作，GUI对象的输入数据是否合法，以及测试准则等。这些都会输入到自动化框架中，从而执行测试自动化。

   这里我们只用简单的例子来阐述测试用例生成器TAG是如何工作的，省去复杂的数学模型和公式的介绍。比如，检查textbox只接收包含 “.”的“字母数字”字符串。如果用户输入一个没有“.”的字符串，在编辑框旁边会出现一个错误提示图标。那么就有：

   GUI初始状态：控件textbox的值为空

   GUI操作1：输入字符串“abc”给控件textbox

   GUI操作1：输入字符串“microsoft.com” 给控件textbox

   GUI结果状态1：textbox的值为“abc”，控件旁显示错误提示图标

   GUI结果状态2： textbox的值为“microsoft.com”，没有错误提示图标

   那么TAG生成的测试自动化就会去验证：

   GUI初始状态 => 执行GUI操作1 => GUI变化到结果状态1，验证结果

   GUI初始状态 => 执行GUI操作2 => GUI变化到结果状态2，验证结果

   这里需要的用户引导是指出哪些GUI对象（比如控件textbox）和它们的哪些属性（比如值）需要进行测试。软件测试开发工程师需要做的是打开“测试用例自动化生成器”，指向对话框中的控件，指出哪些输入是合法的，哪些是非法的；我们称这些是检测规则。根据这些检测规则，TAG中数据生成器可以为这些控件随机生成合法的和非法的数据集，“abc”就是一个非法输入。检测规则包括允许的长度，正则表达式，字符集和类型等各种信息。图4显示一个XML格式的检测规则：

图2. 包含“.”的字母数字字符串的测试规则 图2. 包含“.”的字母数字字符串的测试规则

   此外，如果GUI的编写语言支持反射（REFLECTION），那么可以通过Static Binary Analysis (静态二进制分析器)获得指定对话框上所有的控件，TAG可以根据标准的GUI测试规则实施静态二进制分析，例如：Tab Order（Tab键顺序）, Hotkey（快捷键），Alignment（对齐方式），和Truncation（截断）等。

二、可视树图

   可视树图在这个工具组中扮演联结者的角色，它提供综合的、直观的报告机制。最开始，我们要么手动要么自动把需要测试的GUI结构表达输入可视树图，从此这个GUI结构表达会作为可视树图的基石，整个工具集收集到的数据都可以关联到可视树图。从而可视树图可以为GUI树的每个节点提供直观的报告，用户很容易把它和所测试的GUI联系起来，如：测试用例报告，自动化报告，test pass 结果报告，代码覆盖率的报告和UI差别的结果报告等。

三、 UI差别跟踪器

   在上一篇文章中我们提到，GUI的改变在整个软件开发生命周期中很常见，对软件测试开发工程师来讲，管理这些变化和尽量减少其带来的缺陷是巨大挑战，因此我们设计了UI差别跟踪器。它提供GUI的变化报告，以及需要更新的原有测试用例和测试自动化的信息。它在两个不同的层面上工作：

  1. GUI 层面，它会通知软件测试开发工程师GUI的结构变化，如：增加或者删除一个对话框。
  2. 源代码层面：它会用可视化形式显示源代码的变化，这些变化可能影响GUI的显示，它也会通知软件测试开发工程师去注意这些变化。

   UI差别跟踪器的工作过程：

  1. 当软件的新build发布后，UI差别跟踪器会自动执行。
  2. 任何结构变化，需要更新的测试用例和测试自动化建议信息都一起会自动发给软件测试开发工程师。
  3. 任何潜在的代码层的改变也会通知软件测试开发工程师，然后他们会相应评估这些变化对GUI的影响。
  4. 软件测试开发工程师更新相关的测试用例和自动化代码。

   我们的产品中有一个典型功能，包含110个测试用例，我们使用Tao之后看到了显著的变化。过去一个软件测试开发工程师平均两个小时自动化一个测试用例，现在使用TAO，只需要10分钟，从而大大提高了测试效率。更进一步，这个工具显著节省了软件测试开发工程师原本需要花在对比GUI变化上的时间，并告知软件测试开发工程师测试用例需要的修改和补充。目前，我们正在使用该工具集对一个有超过2，000个对话框的复杂系统上进行测试。

   未来我们计划进一步增加该工具集的通用性，使它可以用于其它产品或网络应用程序，同时也计划在以下两个方面扩展这个工具集：

   第一，定义更多相关的GUI测试标准。例如：自动化测试用例的平均错误时间（Mean Time To Failure），以衡量GUI的健壮性。

   第二，从GUI bug数据库中抽取出一些模式（pattern）并定义一些规则。有些Bug即使是在ad-hoc测试中也很难发现。通过分析这个bug数据库，我们希望可以抽取出一些模式并有效地处理这种情况。

    最后，希望Tao项目对各位从事UI测试的同行有所启发。如果您对这个流程还有疑问，欢迎您给我们留言。

 

王景村（测试经理）、李敏（测试主管）