系统与软件工程 软件测试第5部分：关键字驱动测试

ICS35.080

CCSL77

中华人民共和国国家标准

GB/T38634.5—XXXX

`

系统与软件工程软件测试第5部分：

关键字驱动测试

Systemsandsoftwareengineering—Softwaretesting—Part5：Keyword-driven

testing

((ISO/IEC/IEEE29119-5:2016,Softwareandsystemengineering—Software

testing—Part5：Keyword-driventesting,IDT))

（征求意见稿）

（2023-01-11）

在提交反馈意见时，请将您知道的相关专利连同支持性文件一并附上。

XXXX-XX-XX发布XXXX-XX-XX实施

GB/T38634.5—XXXX

前言

本文件按照GB/T1.1—2020《标准化工作导则第1部分：标准化文件的结构和起草规则》的规定

起草。

本文件是GB/T38634《系统与软件工程软件测试》的第5部分。GB/T38634已经发布了以下部分：

——第1部分：概念和定义；

——第2部分：测试过程；

——第3部分：测试文档；

——第4部分：测试技术；

——第5部分：关键字驱动测试。

本文件等同采用ISO/IEC/IEEE29119-5:2016《软件与系统工程软件测试第5部分：关键字驱动测

试》。

本文件做了下列最小限度的编辑性修改：

——为与现有标准协调，将标准名称改为《系统与软件工程软件测试第5部分：关键字驱动测

试》；

——为符合GB/T1.1要求，将“符合性”从国际标准的第2章调整为第4章，保持本文件第2

章为规范性引用文件，第3章为术语和定义；将国际标准附录G参考文献调整为参考文献要

素格式。

——增加了附录G（资料性）国内示例，增加4个关键字驱动测试在我国的实践案例。

...........

本文件由全国信息技术标准化技术委员会（SAC/TC28）提出并归口。

本文件起草单位：

本文件主要起草人：

II

GB/T38634.5—XXXX

引言

GB/T38634软件测试标准的目的是定义一套公认的软件测试标准，任何组织在管理或执行任何形

式的软件测试时都可以使用这套标准。GB/T38634目前由5部分构成：

——第1部分：概念和定义。目的在于确立软件测试的概念和定义。

——第2部分：测试过程。目的在于定义软件测试的通用过程。

——第3部分：测试文档。目的在于规定软件测试的文档模板，适用于任何组织、项目或规模更

小的测试活动。

——第4部分：测试技术。目的在于定义在测试设计过程中使用的软件测试设计技术。

——第5部分：关键字驱动测试。目的在于定义一种高效一致的关键字驱动测试解决方案。

本文件定义了一种统一的方法，以模块化的方式描述测试用例，有助于项目创建如关键字驱动测试

规格说明和测试自动化框架。术语“关键字”指用来组合测试用例的元素，如构建块。本文件将解释关

键字驱动测试的主要概念和应用，也将定义用于支持关键字驱动测试的框架设计的属性。

GB/T38634的各部分与本文件的关系包括：

——GB/T38634.1中有关软件测试的概念和定义也适用于本文件。

——GB/T38634.2定义了关键字驱动测试框架所基于的测试过程模型，定义了组织级、测试管理

级和动态测试级的软件测试过程，还提供了描述这些过程的支持信息图表。本文件描述了

GB/T38634.2测试设计和实施过程在关键字驱动测试中的具体实现，特别是TD4(派生测试

用例)、TD5(集合测试集)和TD6(派生测试过程)来应用于关键字驱动的测试。

——GB/T38634.3中定义的测试文档模板和示例也适用于本文件。

——GB/T38634.4的应用是在设计测试用例时使用的，然后根据本文件的关键字来描述测试用

例。

III

GB/T38634.5—XXXX

系统与软件工程软件测试第5部分：

关键字驱动测试

1范围

本文件通过以下方式确立了一种高效一致的关键字驱动测试解决方案：

——介绍关键字驱动测试；

——提供实施关键字驱动测试的参考方法；

——定义关键字驱动测试框架的要求，使测试人员能够共享其工作项目，例如测试用例、测试数

据、关键字或完整的测试规范；

——定义支持关键字驱动测试工具的要求，可适用于支持关键字驱动方法的工具（例如，测试自

动化、测试设计和测试管理工具）；

——定义接口和通用数据交换格式，以确保不同供应商的工具之间能够进行数据交换（例如测试

用例、测试数据和测试结果）；

——定义分层关键字级别，建议使用分层关键字，包括描述特定类型的关键字（例如用于导航或

检查值的关键字）以及使用“平面”结构化关键字；

——提供通用技术（低层级）关键字示例的初始列表，例如“输入数据”或“检查值”。这些关

键字可用于在技术层级上的特定测试用例，并可根据需要组合创建业务层级关键字。

注：本文件适用于创建关键字驱动的测试规范，创建相应的框架，或基于关键字构建测试自动化的人员。

2规范性引用文件

下列文件中的内容通过文中的规范性引用而构成本文件必不可少的条款。其中，注日期的引用文件，

仅该日期对应的版本适用于本文件；不注日期的引用文件，其最新版本（包括所有的修改单）适用于本

文件。

ISO/IEC/IEEE29119-1软件与系统工程软件测试第1部分：概念和定义（Softwareandsystems

engineering—Softwaretesting—Part1:Conceptsanddefinitions）

注1：GB/T38634.1—2020系统与软件工程软件测试第1部分：概念和定义（ISO/IEC/IEEE29119-1:2013,MOD）

ISO/IEC/IEEE29119-2软件与系统工程软件测试第2部分：测试过程（Softwareandsystems

engineering—Softwaretesting—Part2:Testprocesses）

注2：GB/T38634.2—2020系统与软件工程软件测试第2部分：测试过程（ISO/IEC/IEEE29119-2:2013,MOD）

ISO/IEC/IEEE29119-3软件与系统工程软件测试第3部分：测试文档（Softwareandsystems

engineering—Softwaretesting—Part3:Testdocumentation）

注3：GB/T38634.3—2020系统与软件工程软件测试第3部分：测试文档（ISO/IEC/IEEE29119-3:2013,MOD）

ISO/IEC/IEEE29119-4软件与系统工程软件测试第4部分：测试技术（Softwareandsystems

engineering—Softwaretesting—Part4:Testtechniques）

注4：GB/T38634.4—2020系统与软件工程软件测试第4部分：测试技术（ISO/IEC/IEEE29119-4:2015,MOD）

ISO/IEC/IEEE24765系统与软件工程词汇(Systemsandsoftwareengineering–Vocabulary)

3术语和定义

1

GB/T38634.5—XXXX

ISO/IEC/IEEE24765界定的以及下列术语和定义适用于本文件。

注：本文件的术语部分是为了便于参考，并不需要强制符合。下列术语和定义用于理解本文件并提高其可读性。仅

包含了对本文件理解至关重要的术语，并不打算提供一个完整的测试术语列表——本文件中未定义的术语可参

考ISO/IEC/IEEE24765系统和软件工程词汇。ISO/IEC/IEEE29119-1可以作为一般软件测试相关术语的参考。

本文件仅定义针对关键字驱动测试的术语。

域层domainlayer

测试项的最高级别的抽象。

注：该层级的关键字将以域专家所熟悉的方式来进行选择识别。

高层级关键字high-levelkeyword

可涵盖复杂活动的关键字，可由其他关键字组成，并被域专家汇集成关键字测试用例。

关键字keyword

在执行一个或多个测试用例时，用于描述一组特定行为的一个或多个词汇。

注5：包括在测试、验证和特定行为建立的测试场景中与用户界面交互启动测试方案。

注6：关键字需至少使用一个动词命名。

注7：复合关键字可以基于其他关键字构造。

关键字字典keyworddictionary

关键字库keywordlibrary

包含一组关键字的库，反映用于编写测试使用的语言和抽象级别。

关键字驱动测试keyword-driventesting

使用由关键字组成的测试用例进行的测试。

关键字驱动测试框架keyword-driventestingframework

测试框架的功能组件包括关键字驱动编辑器、分解器、数据序列器，手动测试助手、桥接工具、数

据和脚本库、关键字库以及测试执行环境。

关键字执行代码keywordexecutioncode

由测试执行引擎执行的关键字的实现。

关键字测试用例keywordtestcase

由关键字序列及其关联参数（如适用）的所需值组成，用于描述测试用例的行为。

低层级关键字low-levelkeyword

只涵盖一个或极少的简单行为，且未由其他关键字组成的关键字。

手动测试manualtesting

由人工来手动操作在测试项中输入信息并验证结果实施测试。

注：自动化测试使用工具、机器人和其他测试执行引擎来执行测试。手动测试不使用这些工具。

2

GB/T38634.5—XXXX

测试执行引擎testexecutionengine

操作测试项来执行测试用例的工具，多由软件实现，有时也会由硬件实现。

注：一个典型的测试执行引擎包含单元测试框架、激励命令系统、录制回放工具或硬件机器人以及控制它们的软件。

测试框架testframework

便于测试的环境。

测试接口testinterface

用于激励测试项、获取响应（例如实测结果）或两者均包括的测试项的接口。

注1：典型的测试接口如GUI、API或SOA接口。

注2：激励测试项可能涉及通过计算机接口或附加硬件将数据传递到其中。

注3：获取响应包括从被测试的测试项或关联的硬件获取信息。

测试接口层testinterfacelayer

关键字的最低级别的抽象。它直接与测试项交互，在测试接口上封装了原子级的交互（最低级别）。

4符合性

预期用法

本文件的要求包含在第7章和附录A中，提供了支持关键字驱动测试应用的框架要求。特定项目或组

织可能不需要使用本文件中定义的所有组件。本文件的实施通常涉及选择适合组织或项目的一组组件

或组件的一部分。组织可通过两种方法声明符合本文件的规定。

组织或个人应声明是否完全符合或剪裁符合本文件。

完全符合

通过证明满足本文件定义的所有关键字驱动测试要求（即描述为“应”的语句），则可声称完全符

合。

注：本文件的一个预期用途是促进过程评估和提升。为了这个目的，每个过程的目标都以输出的形式写入兼容

ISO/IEC15504-2和ISO/IEC33002的规定中。这些标准提出了本文件过程的评估和提升的基础。想要过程评估

和提升的用户会使用写入本标准的过程输出，作为ISO/IEC15504-2和ISO/IEC33002所需的过程参考模型。

剪裁符合

当本文件用于执行框架组件不满足所有符合性要求时，宜记录声明剪裁符合性的组件子集。通过证

明记录的组件子集满足其全部要求（即描述为“应”的语句）实现剪裁符合。

当需要在剪裁情况下，若不完全遵循第7章和附录A中定义的要求，则应提供理由（无论是直接剪裁

还是通过参考剪裁）。应记录所有剪裁决策的理由，包括考虑任何适用的风险。剪裁决策应得到利益相

关方同意。

示例：工具供应商可能在其产品组合中只提供关键字驱动测试框架的部分内容，因此对未提供的其他部分的相应要

求不做满足（例如供应商仅提供执行引擎，但不提供关键字驱动的编辑器，那么执行引擎仍然可以符合标准）。

5关键字驱动测试介绍

3

GB/T38634.5—XXXX

概述

关键字驱动测试是一种测试用例描述方法，通常用于支持测试自动化和研发测试自动化框架，也可

以用于尚未考虑或未建立自动化测试方法的情况。

原则上，关键字驱动的测试可以应用于所有的测试级别(例如:组件测试、系统测试)和各种类型的

测试(如功能测试、可靠性测试)。关键字驱动测试的优点包括:

——易用性；

——可理解性；

——可维护性；

——测试信息可重用性；

——支持测试自动化；

——可能带来成本节约和进度提前。

关键字驱动测试的基本思想是提供一组“构建块”，称为关键字，可以用来创建手动或自动测试用

例，而无需编码或测试工具的专业知识。最终的目标是提供一组基本的、明确的足够全面的关键字，因

此大部分(如果不是全部的话)所需的测试用例都可以完全由这些关键字组成。因此，这些关键字字典或

关键字库中的词汇，反映了用于编写测试用例的语言和抽象层级，而不是任意一种计算机编程语言。

对于自动化测试，每个关键字都需要用软件实现。

注1：当没有使用关键字时，测试用例通常是用自然语言或计算机编程语言。与自然语言相比，关键字具有模糊度

小、精确度高等优点。与计算机编程语言相比，定义明确、结构清晰的关键字，具有可以被许多无软件工程技

能的人理解的优点。

一个关键字通常定义为以下两个层级：

——在低层级上，每个关键字都与一组详细的操作相关联，这些操作用于描述要执行的具体步

骤。

——在高层级上，使用有含义的名称来标识关键字。该关键字可能需要一组输入参数，这些参数

与关键字在结构上同属一层。关键字和参数共同组成了对与测试用例相关联的操作的高层级

描述。

这样就可以在更高的层级上用关键字抽象地定义测试，而不是描述测试用例中的每个操作。也可以

使用复合关键字实现更高层级的抽象，复合关键字由描述关联操作的关键字组成。

从手动和自动关键字驱动的测试用例中获得好处的一个例子是提高了可维护性。例如一组精确的

操作集，其中包含较多的重复性操作。当该操作出现变更时，引入关键字的模块化可以只在相关的较低

层级关键字中进行修改，变更其操作，而保留测试用例整体组成不变。如果没有模块化，可能需要修改

测试用例中所有出现该操作的全部场景。

模块化有助于普及该方法。如果需要自动化测试，可以创建一个框架，将手动创建的关键字测试用

例解释为可执行的测试自动化脚本。这是通过为每个关键字实现测试自动化代码（例如关键字执行代码）

来实现的。

注2：测试工具可以用来支持关键字驱动的测试，但是所选的工具可能会受到能力限制，不能支持本文件中描述的所

有概念。

4

GB/T38634.5—XXXX

测试规程

1...n

测试用例

1...n111...n

关键字测试用例手工测试用例

实现

1...n1...n

1...n1...n

实现

关键字操作实现

描述

1

实现

测试接口/不依赖工具

测试接口/依赖工具

0...1

关键字执行代码

1...n

被应用于

1...n

框架生成自动测试脚本

1手工生成自动测试脚本

1

自动测试脚本

图1两种关键字驱动测试实体间的关系

测试规程可以有多个测试用例，反之，测试用例又可以是不同测试规程的一部分（见图1）。测试

用例可以是手动测试用例，也可以是关键字测试用例。关键字测试用例可以实现手动测试用例。

关键字测试用例通常由一系列序列化的关键字组成，关键字选择宜基于模块化和通用，以便在测试

用例中重用。关键字也可以在同一测试用例中多次使用，测试用例由测试操作组成。关键字代表测试操

作。

注3：可以将多个关键字映射到单个操作。也可以用一个关键字表示一个操作的方式来定义关键字。在这些情况下，

操作和关键字之间存在一对一关系。但是，测试设计人员也可以用不同的方式构造关键字（例如，使用多个关

键字来实现一个操作，或者将两个或多个操作组合到一个关键字中）。在这种情况下，例如图1中操作和关键

字的关系就不再是1:1的关系。

在实现关键字驱动测试时，可以选择自动化测试，也可以采用手动测试的方法。如果关键字测试用

例是自动化的，那么每个关键字都通过关键字执行代码实现，关键字执行代码除了取决于所选的工具或

5

GB/T38634.5—XXXX

测试执行引擎之外，还取决于测试接口。对于手动测试方法，关键字描述的操作是手动执行的，因此没

有关键字执行代码。故图1中，关键字和关键字执行代码之间的映射关系是从1映射到(0...1)。

测试自动化通常高度依赖于技术和工具，依赖于测试接口和所选工具的能力。通常，关键字可以独

立于测试接口（例如用户界面）和用于执行测试用例的工具。

在此周境中，自动化测试脚本既可以由框架自动生成，也可以由测试自动化人员进行开发。开发自

动化测试脚本的测试人员通常具有编程经验。

注4：在开发自动化测试脚本时，将关键字的结构（例如层级）与自动化测试脚本的实现保持一致是有益的。

如果关键字测试用例或一组关键字测试用例是自动化的，那么关键字驱动测试的框架可以基于关

键字执行代码生成自动化测试脚本。

注5：关键字驱动测试的框架并不“生成”代码，所需的代码也可以由测试人员编写，并由框架执行。

关键字驱动测试中的层级

5.2.1概述

关键字可以表示不同抽象层级的操作。例如，一个关键字可以对应一组非常复杂的操作，如创建合

同，它包含大量步骤，而另一个关键字则对应一个非常简单的操作，如按下图形用户界面上的一个按钮。

第一个关键字更贴近业务和最终用户域，而第二个更贴近测试接口。以相似的细节级别进行编写、具有

相似的利益相关方视角关系的关键字属于同一个抽象层级。

关键字驱动测试可以使用一个或多个层级进行组织。典型的层级包括最终用户域层和测试接口层。

虽然许多关键字驱动测试的实现会包含两个或三个抽象层，但在某些情况下，可能需要在更多层中

构造关键字。

最高层级是最抽象的层，通常与该应用程序的用户业务语言一致。实际上，最顶层通常是域层。但

在某些情况下，可能不需要域层，而需要使用另一个更抽象的层（例如，如果测试用例需要跨越几个不

同的最终用户域，可以引入一个元域层）。

最低层级是最详细的层，它通常与测试接口元素的名称对应（例如"selectMenultem"）。实际上，

此层通常是测试接口层，但也有例外（例如，有时不需要测试接口层，或者出于特定原因，可以使用更

详细的层）。

考虑到关键字测试用例的可理解性、多层结构的可维护性和工作分工等因素，大多数关键字驱动的

测试系统有不止一个层。如果只实现为一个层，它要么处于较低层级，这会影响关键字测试用例的可读

性；要么在较高层级，这可能需要生成更多的关键字执行代码。

在图2中，给出了一个示例，演示如何使用两层关键字来构造两个不同的接口测试的测试用例。

6

GB/T38634.5—XXXX

启动应用初始化相机

创建文档创建预览

测试用例输入内容拍照

保存文档验证图片

退出退出

保存文档：拍照:

获取内容初始化

域层关键字选择目录调用API相机拍照

选择保存结束

选择目录()调用API(API)

{{

窗口句柄=获取窗口句柄()设置参数()

推送消息(窗口句柄,目录消息)返回结果=调用(API)

}验证(返回结果)

测试接口层关键字}

SelectMenu()InvokeAPI(API)

（脚本代码）

{{

hWnd=GetWindowHandler()setupParameter()

postMsg(hWnd,MenuMsg)Res=Call(API)

}Check(Res)

}

接口测试GUIAPI

图2多层关键字定义测试用例示例

示例：图2中显示了两个测试用例，它们使用域层和测试接口层进行设计。其中一个示例概述了GUI应用程序的测

试用例，另一个用于摄像机API。在这两个示例中，测试用例在测试接口层上完成。从上到下，该示例演示了对两个测

试项的测试用例，演示了如何在域层上用已使用的复合关键字构造两个测试项，同时介绍了如何在测试接口层上为测试

项实现一个基本关键字的方法。

5.2.2域层

域层中的关键字对应于域或业务相关活动，并反映域专家使用的术语。因此，测试人员可以更轻松

地在域层创建测试用例。

为域层开发的关键字通常与实现无关，也就是说，这些关键字只定义测试这项工作本身，无需考虑

用何种技术去实现测试项。

示例1：考虑为测试字处理应用程序而开发的关键字测试。域层关键字对应的活动属于"字处理业务"

启动应用<应用程序名字>

清空缓存

输入文字：“你好，世界！”

替换文字：“你好”，“再见”，“ALL_OCCURRENCES”

验证文字：“再见，世界！”

停止应用

此测试适用于提供全局替换函数的任意文本编辑器应用程序（例如记事本、MSWord、记事本*、GED、EMACS等）

示例2：常用的域层关键字"登录"和"创建帐户"测试，使用域层关键字构造相对不受实现中的变化的影响，并可以防

止在测试项的生存期内进行昂贵的重新设计。

注：对应用程序的大幅度变更（例如工作流的变更）可能需要重新设计测试用例。

5.2.3测试接口层

7

GB/T38634.5—XXXX

测试接口层中的关键字是指特定类型的测试接口，例如，图形用户界面（GUI）。通常可以轻松识

别其对测试项所进行的必需操作。测试接口层的关键字总数通常比域层少，因为测试接口的数量是有限

的。

示例1：GUI可用作测试接口，当GUI控件（以及关联的操作）映射到一组固定的关键字，只需要少量关键字即可。

与域相关的关键字既具有通用性，同时也可根据测试人员的需求进行扩展，从而产生更多的关键字。

如果需要自动化，测试接口层关键字执行代码通常更简单。但是，对于由测试接口层中的关键字组

成的关键字测试用例，可能很难看出接口层关键字与业务域的关联关系。

接口层关键字通常反映与测试项交互的基础实现技术。例如，“菜单选择”和“单击按钮”等关键

字反映的是GUI操作。使用上面的示例，它们将不适用于使用命令行接口（如vi）的文本编辑器，因为

它们对应于基于窗口的操作。

示例2：考虑一个图形化用户界面的测试接口。选择关键字以涵盖单个操作，如“单击”或“选择”。这些关键字将

被应用于不同的元素，如列表、网格或图像等。可以使用带有参数的关键字（见5.4）来选择特定元素。以此可以排除

某些元素和操作的组合。

5.2.4复合层

要兼得多个层的优势（例如域层和测试接口层），需要一个框架来帮助管理关键字的分层（有关测

试框架的详细信息，见第7章）。这样就可以由多个更贴近技术的低层级关键字（例如测试接口层关键

字）来构建更贴近业务的高层级关键字（例如域层关键字）。

图3说明了如何在关键字驱动测试中使用复合层。

在复杂的设置中，需要三个或更多的关键字层。图3中，其他的中间层由三个点表示[...]

使用复合层需要复合关键字（见5.3.2复合关键字）。

测试用例例：ATM完成取钱操作

域层关键字例：身份验证、选择取款、输入金额

关.

.

键.

字

层测试接口层关键字例：插入银行卡、输入密码、确认纸币金额

可选：自动化测试

（关键字执行脚本）例：实现用户接口操作或提供测试桩的自动化脚本

测试接口例：图形化用户界面、测试桩、API

图3多层在关键字驱动测试中的应用

注1：图3中明确显示了两个关键字层——一个域层和一个测试接口层，并暗示可能还存在其他中间层。只组织关键

字在一个层是可能的也是足够的。但是，在某些情况下可能至少还需要两个层。

注2：在图3中，域层的关键字取自一个ATM测试的域，用于创建测试用例。测试接口层中的关键字是指可应用于测试

8

GB/T38634.5—XXXX

接口的简单操作。此示例中的关键字"确认纸币金额"与测试接口相关，假设其仅涵盖一个小操作，并被用作域

层关键字的一部分。在其它示例中，它也可以由另外的方式设计，涵盖多个操作，也成为域层的一部分。

关键字类型

5.3.1简单关键字

在测试接口层经常使用的简单关键字（例如“菜单选择”或“单击按钮”）可以成为测试执行工具

与中间层或域层上更高级别关键字之间的连接。

仅在测试接口层使用关键字就足以定义测试用例及其执行。单独使用简单关键字将导致测试用例

中有许多操作。

根据测试项目的不同，测试接口层的关键字可能需要与不同的系统（例如数据库、系统注册表或SOA

消息）进行交互。自动化框架通常会通过提供一组预定义的关键字来支持这些交互，以使技术环境尽可

能清晰。

以类似的方式，自动化框架将支持访问测试接口或关键字可在其上操作的其他接口（例如鼠标、键

盘和触摸屏）。

根据测试接口的不同，可以使用数量非常有限的简单关键字进行操作。关键字词汇量有限，更容易

记忆、使用和维护，有利于编写测试用例。如果需要测试自动化，数量非常有限的关键字可能会增加实

现关键字执行代码的工作量。这是因为如果使用更少的关键字仍应涵盖相同的复杂性，则单个关键字需

要更灵活或更强大。

示例：实现所需的操作(如“选中”)。由于该目标仅具有极少量的关键字，该特定的操作只实现一次，在这种情况

下，单个关键字“选中”需要处理多种不同类型的界面元素，例如GUI、列表、表格和单选按钮。因此，关键字“选中”

将与复杂的实现（或者执行）相关联。

5.3.2复合关键字

简单关键字足以编写和执行测试用例，但通常不足以反映功能特征。复合关键字是由其他关键字组

成的关键字。这意味着关键字可以组织在不同的层中（见5.2）。对于复合关键字，可能需要复合参数

（例如数据结构）。

使用业务级别的关键字（例如“登录用户”）通常很有用。该关键字可以由一系列较低级别的关

键字组成，例如“输入用户名”，“输入密码”和“单击登录按钮”。对于更复杂的业务对象，例如用

于准备合同的大型表格，使用如“填写合同表格第1页”之类的关键字可能更有价值。

示例1：通常使用复合关键字进行验证（例如，从应用程序中检索值，将其与预期结果进行比较，然后将比较结果记

录在测试执行日志中）。

还可以用较高层级（例如域层）的关键字来定义具有较低层级（例如测试接口层）的单个关键字，

以表达不同的语义。

示例2：出于导航目的，由一个低层级关键字“单击结果按钮”定义一个高层级关键字“转到结果屏幕”。

也可以使用几个基本关键字的组合，来创建具有更高功能级别的复杂操作，例如“创建顾客账户”，

其中可能包含大量基本步骤。

复合关键字是包含一系列其他关键字的“包”。复合关键字的参数集可以是构成复合关键字的各关

键字的参数的并集。但是，有时复合关键字的实现者可能通过在组合中为其分配文本值来选择“隐藏”

一个或多个参数。如图4中的示例所示。接口层关键字“输入值（Enter_value）”有两个参数：被引用

对象的ID和要插入的值。在顶层关键字“登录（Login）”上仅可见值，如用户名（username），而对

于仅使用了复合关键字的测试人员，则隐藏了该ID。如果详细的技术信息与设计测试用例并在域层进行

操作的人员无关，那么这是特别有用的。

9

GB/T38634.5—XXXX

示例3：图4说明了如何将登录过程的关键字设计为三层的复合关键字。在域层，可以使用此关键字（例如“登录

Login（“John”，“secret”）”）。该关键字由中间层的三个关键字“设置用户名（Set_User）”，“设置密码（Set_Pwd）”

和“关闭登录操作（Close_Login）”组成。中间层的关键字“设置用户名（Set_User）”和“设置密码（Set_Pwd）”

都使用了更高层级的域层关键字“登录（Login）”的参数，而关键字“Close_Login”根本不需要任何参数或数据。在

第三层（测试接口层）使用的基本关键字“设置周境（Set_context）”，“输入参数（Enter_value）”和“选中（Select）”。

在此第三层上使用了一些文字值，例如“登录窗口（Login_Window）”，它没有随域层的关键字一起提供，但是每次使

用中间层关键字之一时，都将以相同的方式使用。

登录Login(username,password)

设置用户名Set_User(username)

设置周境

Set_context(“Login_Window”)

输入值

Enter_value(“Edit_User”,username)

设置密码Set_Pwd(password)

设置周境

Set_context(“Login_Window”)

输入值

Enter_value(“Edit_Pwd”,password)

关闭登录窗口Close_Login()

设置周境

Set_context(“Login_Window”)

选中

Select(“Button_OK”)

域层中间层测试接口层

图4带有数据的复合关键字的应用示例

图5说明了不同类型的关键字、关键字测试用例和最终应用于测试项的关键字级别之间的关系。其

中的关键字可以是低层级关键字、高层级关键字或复合关键字。

10

GB/T38634.5—XXXX

关键字测试用例

关键字

低层级高层级复合

关键字关键字关键字

应用于低层级

关键字

应用于应用于

测试项

图5不同级别的关键字组成的关键字测试用例

如果没有使用复合关键字，关键字测试用例可以从低层级关键字构建，例如从测试接口层构建。通

过这种方法，测试项的测试将通过使用低层级关键字来完成。

注1：在图5中，复合关键字可以是低层级关键字，也可以是高层级关键字。

测试用例对于手动测试人员和机器可读的测试执行引擎来说是可以理解的。另一方面，当阅读这样

的测试用例时，可能很难识别由测试用例处理的使用用例或业务用例。

通过专门使用高层级关键字（例如业务关键字或域关键字），相对于已解决的用例或测试用例，派

生的关键字测试用例通常将更易于理解。测试项的测试将通过使用高层级关键字来完成。因此，手动测

试人员需要更多有关执行更抽象的关键字所需的详细步骤的信息，尤其是在他们不熟悉业务领域的情

况下。如果使用执行引擎，则这些执行引擎也需要有关执行更抽象关键字所需的详细步骤的更多信息。

在组合了低层级关键字以形成较高级别的复合关键字之后（例如，将测试接口层的关键字与域层的

复合关键字组合在一起），关键字测试用例就可以由这些高层级关键字组成。这样的测试用例很容易理

解，因为它们类似于相关的用户用例或业务用例。

注2：如图5所示，复合关键字中存在两个级别的关键字：复合高层级关键字和低层级关键字。可能还会有更多级

别，例如中间的复合关键字。这些关键字由较低级别的关键字组成，并用于组成较高级别的关键字。

为了执行测试，通常可以使用框架将高层级关键字分解为低层级关键字（见7.2）。从而仅通过使

用低层级关键字即可完成测试项的测试，这使手动测试人员或测试执行引擎可以轻松地确定执行测试

所需的必要操作，因为他们使用低层级关键字时将遵循简单的步骤。

注3：可以混合使用来自不同层的关键字，并在一个关键字测试用例中使用它们，但不建议这样做，因为这可能导致

维护问题。

5.3.3导航/交互（输入）和验证（输出）

关键字至少可以分为两类:导航步骤(即测试项的输入)和验证步骤(即测试项的输出)。大多数关键

字属于第一类(即导航步骤)，因为大多数操作都需要准备测试项或对其执行某些将导致输出结果的操

11

GB/T38634.5—XXXX

作。导航步骤通常是不验证和记录测试结果的步骤。然后由一个或多个其他操作(即验证步骤)来检查结

果。

验证步骤与测试用例的结果有关。例如，如果不满足验证步骤的条件，则测试结果将设置为“失败”。

允许将导航步骤用于验证可能会很有用。

示例1：为测试用例准备数据时需要导航步骤“新增用户（AddUser）”。在某些情况下，可以在假定添加用户成功

的情况下使用它，在其他情况下，可以在预期添加失败的情况下使用它。因此，关键字可以验证是否成功创建了用户，

而无需将测试用例标记为“失败”。但是，由于该导航步骤的执行失败，测试设计人员也可以决定将一个测试用例标记

为“失败”，尽管该测试用例的实际目的是要验证执行流程稍后出现的结果。

如何查看测试失败的原因，见5.3.4“关键字与测试结果”。

关键字通常在语义上相互独立，因此，如果某个关键字旨在触发预期结果，则对该预期结果的验证

将是同一关键字的一部分，而不是另一个关键字。

示例2：当第二个关键字仅在第一个关键字之后使用时，通常避免使用诸如“打开对话框”-“验证对话框是否已打

开”之类的关键字对。

5.3.4关键字与测试结果

关键字可用于确定测试状态并捕获测试结果。可包括以下内容：

——测试输出；

——符合成功标准；

——测试执行日志文件；

——硬件输出；

——系统状态；

——测试失败。

测试执行失败的原因有多种，其中可能包括：

在测试用例中进行的检查表明实际输出与预期输出之间不匹配，这可能表示软件故障；

由于无法执行测试，因此无法执行测试用例中的某些步骤。

注：无法执行测试包括由于关键字、关键字执行代码或测试环境中的错误而无法执行的测试用例。

明显识别执行失败的原因很有用，而不必详细分析原因。因此，框架将相应地设置不同的测试结果

（例如，失败和/或阻止）。单个关键字执行的结果通常会影响测试结果，但该影响取决于上下文。

示例：可以将关键字设计为在用户界面的文本字段中输入几个值。根据应用程序的状态，可能可以输入一个值（例

如，文本字段处于活动状态），也可能无法输入一个值（例如，文本字段处于非活动状态）。这两个选项均有效。因此，

尽管关键字由于无法输入值而在这些选项之一中失败，但测试结果不会设置为“失败”。在这种情况下，暂时性故障不

会影响整体结果。

可以将测试框架设计为处理测试项上被中断的关键字，然后选择将关键字标记为“可以被中断”或

“不得被中断”。在第一种情况下，关键字的中断（执行失败）不会影响测试结果；在第二种情况下，

测试结果将受到影响。关键字可以是全局标记的（测试用例中所有应用程序的默认属性），也可以在测

试用例中使用时被覆盖。

测试框架还可以提供错误识别机制。该机制可以处理关键字返回的错误，可以尽可能清楚地记录和

描述故障，以简化自动化框架中的错误纠正并调查其原因，因这可能是软件缺陷。

关键字和数据

如果关键字与数据相关联，则可以增强关键字驱动的测试。在许多情况下，为了将关键字与数据关

联，关键字需要具有固定的或列表驱动的参数。

12

GB/T38634.5—XXXX

大多数关键字至少需要一个参数来指定它们所应用的对象。有些需要另一个参数来指定输入(例如，

true/false、要键入的字符串、组合框中要选择的选项)。这个输入通常取决于控件的类型和操作的类

型。

注1：在关键字表示验证步骤的情况下，关键字所需的输入可以是预期的输出，也可以是引用对象的状态。

一些关键字也可以接受一些可选的输入；在这种情况下，框架需要保存那些没有提供的默认值。例

如，“点击界面元素（456,123）”指的是界面元素中的一个特定坐标点，而“点击界面元素”没有指

定坐标的情况下，可能默认是点击该元素的中心。

对于可以涵盖大量功能的复合关键字，参数的数量可能会增加，测试数据可能会变得复杂。将数据

与操作进行解耦是一个很好的方法。因此，可以单独标记多个参数，并使用对数据的唯一引用作为关键

字的输入。

注2：复合关键字“创建客户（createCustomer）”需要客户的姓名和地址等数据，它并非使用关键字测试用例记录

测试数据，而是存储在数据库中，这允许对数据库中的复杂数据进行单个引用，并且可以通过提供与相同的操

作序列相关联的多组数据来扩展测试用例。

数据驱动测试是一种与将测试数据与操作序列分开存储的方法，它独立于关键字驱动测试，但经常

与关键字驱动测试结合使用。在数据驱动的测试中，对于一个具有已定义的操作序列的测试用例，可以

提供多组数据，然后针对每个数据集执行动作序列。根据实现方式，数据可以存储在表、电子表格或数

据库中。数据驱动测试是一种将参数与测试分离的选项，它与关键字驱动测试的概念非常吻合。

见6.4“关键字和数据驱动的测试”。

6关键字驱动测试的应用

概述

本章介绍一些有助于关键字驱动测试成功应用的概念。虽然并不强求关键字测试用例采用所有这

些概念的，但是采用它们对测试设计是有益的。

本章共介绍6种概念。

a）6.2中的“识别关键字”；

b）6.3中的“编写测试用例”；

c）6.4中的“关键字与数据驱动测试”；

d）6.5中的“模块化与重构”；

e）6.6中的“测试设计过程中的关键字驱动测试”；

f）6.7中的“将非关键字驱动的测试用例转换为关键字驱动的测试”。

识别关键字

关键字识别是关键字驱动测试中的一项关键任务，因为关键字的内容、颗粒度和结构都会影响关键

字测试用例的定义方式。关键字的命名要让相关使用者觉得自然。

识别关键字的步骤如下:

a）确定给定周境中所涉及的层，并定义什么类型的关键字（例如，功能、颗粒度）将被分配到哪

个层；

b）根据每个层的定义或范围来识别层中的关键字。

通常，定义关键字时，先识别测试中频繁出现的操作集，用一个名称（例如，关键字）定义一个或

一组操作，界定适用范围。再确定哪些操作是信息依赖（如时间、数据、情况等）的是很有用的，从而

识别关键字需要与哪些参数关联。

13

GB/T38634.5—XXXX

一个关键字由以下信息描述:

——关键字的名称，表达该关键字将做什么。

——关键字的参数，可以为空。

——关键字的文档描述，包括该关键字所在的层、关键字的类型(例如，导航或验证)、关键字的

使用周境、关键字包含的操作(作为描述或作为对较低层关键字的引用)以及关键字的目标。

——如果该关键字由其他关键字组成，则按照使用它们的顺序列出包含的关键字。

简单关键字可以通过观察测试输入界面中的不同交互来识别，例如与键盘、鼠标、触摸屏、麦克风、

API等的交互。

复合关键字可以通过观察用户在UI级别执行的常见操作来识别。例如，用“转到（GoTo）”代替“单

击按钮（ClickButton）”，用“选中（Select）”代替“ClickRowInTable”。

典型的业务行为可以封装在复合关键字中(例如“创建新用户（CreateNewUser）”)。其他复杂的

操作，如与数据库的交互，也可以是框架中的候选关键字。

宜考虑下列问题：

——唯一性：每个关键字在其使用周境中宜唯一。

——可重用性：关键字的定义宜采用能最好地支持未来可重用的方式。

——完整性：宜根据所有已知元素和测试接口可能的交互定义关键字。（例如，GUI及其对话框

中的所有已知对象)。

——清晰性：宜以清晰一致的结构来定义所有的关键字。

注1：层中的所有关键字均宜具有类似的抽象级别。

——特异性:关键字间不宜存在冗余，宜彼此独立（即不同关键字代表不同的明晰操作)，以简化

测试设计并减少维护工作。

注2：在某些环境中，使用面向对象的方法来识别和描述关键字是很有用的。在这种方法中，关键字可以通过分析域

中对象的可用对象和对象方法来识别，然后可以用“对象.动作/参数（OBJ.ActionParameter）”之类的样式

来描述。其中“对象（OBJ）”指要寻址的对象（例如，用户对话框中的按钮），“动作（Action）”指的是

对应的操作（例如:“按”按钮），“参数（Parameter）”是指需要附加的参数列表。如果在该环境中执行关

键字驱动测试的所有用户都熟悉面向对象，则此方法可能非常有用。

编写测试用例

关键字测试用例可以由以前定义的关键字组成。在编写测试用例的过程中，可能会发现遗漏的关键

字，可以再补充定义关键字。

注：关键