GB/T 38634.4-2020.Systems and software engineering一Software testing一Part 4:Test techniques.
1范围
GB/T 38634的本部分定义了在GB/T 38634.2测试设计和实现过程中使用的测试设计技术。
GB/T 38634.4适用于但不限于测试人员、测试经理.开发人员和项目经理,特别是那些负责管理和实施软件测试的人员。
2符合性
2.1 预期用途
本部分的规范性要求包含在第5章和第6章中。由于特定项目或组织可能不需要使用本部分定义的所有技术，因此,本部分的实施通常涉及选择适合于项目或组织的一组技术。组织或个人可以通过两种方式声明符合本部分的规定:完全符合或剪裁符合。组织或个人应声明是否要求完全或剪裁符合本部分。
2.2完全符合性
通过证明满足选定的第5章中技术集(不为空)和/或相应的第6章中测试覆盖率测量方法的所有要求(即描述为“应”的语句),则可声称完全符合。
示例:组织可以选择仅符合一种技术,例如边界值分析。在这种情况下,组织只需要提供证据证明他们已满足该技术的要求,可以声称符合本部分。
2.3 剪裁符合性
通过证明已经满足来自所选技术集(不为空)和/或相应的测试覆盖率测量方法的所选择要求的子集来实现剪裁符合。在剪裁情况下,如不完全遵循第5章中定义的技术或第6章中定义的测量规范性要求,应当提供理由(无论是直接剪裁或者是通过参考剪裁)。所有剪裁决策都应记录其理由,包括考虑任何适用的风险。剪裁应由利益相关方商定。
3规范性引用文件
下列文件对于本文件的应用是必不可少的。凡是注日期的引用文件,仅注日期的版本适用于本文件。凡是不注日期的引用文件,其最新版本(包括所有的修改单)适用于本文件。
GB/T 38634.1系统与软件工程 软件测试 第1部分:概念和定义(GB/T 38634.1-2020，ISO/IEC/IEEE 29119-1 :2013, MOD)
GB/T 38634.2系统 与软件工程软件测试 第2部分:测试过程(GB/T 38634.2-2020,ISO/IEC/IEEE 29119-2 :2013, MOD)
GB/T 38634.3系统 与软件工程软件测试 第3部分:测试文档(GB/T 38634.3-2020,ISO/IEC/IEEE 29119-3:2013,MOD)

1CS35.080
中华人民共和国国家标准
GB/T38634.4—2020
系统与软件工程
软件测试
第4部分：测试技术
Systems and software engineeringSoftware testingPart4：Testtechniques
(ISO/IEC/IEEE29119-4:2015,Software and systems engineeringSoftwaretestingPart4:Testtechniques,MOD)2020-04-28发布
国家市场监督管理总局
国家标准化管理委员会
2020-11-01实施
2符合性
规范性引用文件
术语和定义
测试设计技术
基丁规格说明的测试设计技术
基于结构的测试设计技术
5.4基于经验的测试设计技术.
测试覆盖率测量
基于规格说明的测试设计技术的测试测量基于结构的测试设计技术的测试测量6.3
6.4基于经验的测试设计技术的测试测量附录^（资料性附录）测试质量特性次
附录B（资料性附录）基于规格说明的测试设计技术的应用指南和示例附录C（资料性附录）
基于结构的测试设计技术的应用指南和示例附录D（资料性附录）
基于经验的测试设计技术的应用指南和示例附录E（资料性附录）可交换的测试设计技术的应用指南和示例附录F（资料性附录）
附录G（资料性附录）
参考文献·
测试设计技术覆盖有效性
测试设计技术对照
GB/T38634.4—2020
GB/T38634《系统与软件工程软件测试》分为以下4个部分：第1部分：概念和定义；
一第2部分：测试过程；
—第3部分：测试文档；
第4部分：测试技术。
本部分为GB/T38634的第4部分。本部分按照GB/T1.1—20C9给出的规则起草。GB/T38634.4—2020
本部分使用重新起草法修改采用ISO/IEC/IEEE29119-4：2015《软件与系统工程软件测试第
4部分：测试技术》。
本部分与ISO/IEC/1EEE29119-4：2015的技术性差异及其原因如下：关于规范性引用文件，本部分做了具有技术性差异的调整，以适应我国的技术条件，调整的情况集中反映在第3章“规范性引用文件”中，具体调整如下：·用修改采用国际标准的GB/T38634.1代替了ISO/IEC/IEEE29119-1；：用修改采用国际标准的GB/T38634.2代替了ISO/IEC/1EEE29119-2；?用修改采用国际标准的GB/T38634.3代替了ISO/IEC/IEEE291193；·删除了1SO/IEC/IEEE29119-4:2015，本部分还做了下列编辑性修改：将标准名称改为《系统与软件工程软件测试第4部分：测试技术》：删除了A.1.1、A.3.1、A.4.1、B.1.1、C.1.1、D.1.1、F.1.1的标题：删除了E.1.1标题.将E.1.2和E.1.2.1~E.1.2.8标题顺改：一将附录B中国外的地名和货币修改为国内的地名和人民币将附录G中的内容由本部分与BS7925-2映射过程”修改为与GB/T155322C08的映射过程。
请注意本文件的某些内容可能涉及专利。本文件的发布机构不承担识别这些专利的责任。本部分由全国信息技术标准化技术委员会（SAC/TC28)提出并归口。本部分起草单位：上海计算机钦件技术开发中心、中国电了技术标准化研究院、中国航天系统科学与工程研究院、深圳赛西信息技术有限公司、国家应用软件产品质量监督检验中心、苏州洞察云信息技术有限公司、中国航发控制系统研究所、中国电子科技集团公司第五十四研究所、中国电子科技集团公司第十研究所、重庆市软件评测中心有限公司、北京航空航天大学、广东省科技基础条件平台中心、厦门理工学院、北京跟踪与通信技术研究所、北京轩宇信息技术有限公司、西宁市大数据服务管理局、中国司法大数据研究院有限公司，北方民族大学，中电菜斯信息系统有限公司，中国航天科工集团第三研究院第三〇四所、浙江省电子信息产品检验所、山东道普测评技术有限公司、南京大学、福建省电子产品监督检验所、内蒙古安盾信息安全评测有限公司、上海同思廷软件技术有限公司，上海第二工业大学本部分主要起草人：龚家瑜、李文鹏、张肠肠、左振雷、蔡立志、康京山、胡芸、孙云、沈颖、张元元、白万芳、土瑞、潘宇聪、赵明、卢俊文、吕雪、于志杰、杨隽、丁晓明、尹平、路云峰、张峻、郑丽娜、刘伟、徐宝文、王建强、赵毅、韩强、王风玲、柳毓龙、徐跃伟、郭新伟、周震漪、孟宪伟、李丽萍。日
GB/T38634.4—2020
本部分使用了GB/T38634.2的测试设计和实现过程来描述测试设计技术（也称为测试用例设计技术或测试方法）：本部分没有给出测试设计和实现的过程，而是描述了可以在GB/T38634.2中使用的技术。其目的是描述一系列软件测试行业广泛接受的技术，本部分中说明的测试设计技术可用于导出测试用例，执行测试用例后会产生结果，符合测试项的要求或测试项存在缺陷（即没有达到要求）。基于风险的测试用于确定特定情况下使用的技术集（基于风险的测试在GB/T38634.1和GB/T38634.2中进行说明）。注：“测试项”是需要测试的工作产品（见GB/T38G34.1)。示例：“测试项”包括系统，软件项、对象、类、需求文档、设计规格说明和用户指南。每项技术都符合GB/T38634.2中定义的测试设计和实现过程，如图1所示。测试设计和实现
测试设计规格说明
识别特征集
该过程中活动的输入可包括：
测试依据
测试计划：
测试策略：
测试项：
测试设计技术，
特征集
导出测试条件
测试条件bZxz.net
导出测试
覆盖项
测试覆益项
测试用例规格说明
测试用例
导出测试用创
形成测试集
图中仅给出了过程的序列示意图，在实际测试中，
一些过程可能会修改并
进行选代
详见GB/T38634.2
测试巢
测试规程规格说明
测试规程和
导出测试规程
图1GB/T38634.2中所述的测试设计和实现过程测试脚本
ISO/IECTR19759定义了两种类型的需求：功能性需求和质量需求，GB/T25000.10一2016定义了八个质量特性（包括功能性），用于识别适合测试特定测试项的测试类型。附录A提供了用于测试GB/T25000.10一2016中定义的测试质量特性对应的测试设计技术。基于经验的测试实践比如探索性测试，或者其他测试实践比如基于模型的测试不在本部分中定义，因为本部分只描述设计测试用例的技术。测试实践如探索性的测试在GB/T38634.1中描述。测试过程中生成的测试文档的模板和例子在GB/T38634.3中定义。本部分中的测试技术对测试用例的文档记录不进行说明（例如不包括分配唯一标识、测试用例描述、优先级、可追溯性或前置条件的信息或指导）。关于如何记录测试用例的信息见GB/T38634.3。本部分的目的是提供给任何组织的利益相关方设计测试用例的能力。IN
1范围
系统与软件工程软件测试
第4部分：测试技术
GB/T38634.4—2020
GB/T38634的本部分定义了在GB/T38634.2测试设计和实现过程中使用的测试设计技术。本部分适用于但不限于测试人员，测试经理、开发人员和项目经理，特别是那些负责管理和实施软件测试的人员。
2符合性
预期用途
本部分的规范性要求包含在第5章和第6章中。由于特定项日或组织可能不需要使用本部分定义的所有技术，因此，本部分的实施通常涉及选择适合于项目或组织的一组技术。组织或个人可以通过两种方式声明符合本部分的规定：完全衍合或剪裁符合。组织或个人应声明是否要求完全或剪裁符合本部分。
2.2完全符合性
通过证明满足选定的第5章中技术集（不为空）和/或相应的第6章中测试覆盖率测量方法的所有要求（即描述为“应“的语句），则可声称完全符合示例：组织可以选择仅符合一种技术，例如边界值分析。在这种情况下，组织只需要提供证据证明他们已满足该技术的要求，可以声称符合本部分。2.3剪裁符合性
通过证明已经满足来自所选技术集（不为空）和/或相应的测试覆盖率测量方法的所选择要求的子集来实现剪裁符合。在剪裁情况下，如不完全遵循第5章中定义的技个或第6章中定义的测量规范性要求，应当提供理由（无论是直接剪裁或者是通过参考剪裁）。所有剪裁决策都应记录其理由，包括考虑任何适用的风险。剪裁应由利益相关方商定3规范性引用文件
下列文件对于本文件的应用是必不可少的。凡是注日期的引用文件，仅注日期的版本适用于本文件。凡是不注日期的引用文件，其最新版本（包括所有的修改单）适用于本文件GB/T38634.1系统与软件工程软件测试第1部分：概念和定义（GB/T38634.12020，ISO/IEC/IEEE29119-1:2013.MOD)软件测试第2部分：测试过程（GB/T38634.2一2020，GB/T38634.2系统与软件工程
ISO/IEC/IEEE291192:2013,MOD)GB/T38634.3系统与软件工程
ISO/IEC/IEEE29119-3:2013,MOD)软件测试第3部分：测试文档（GB/T38634.3-20201
GB/T38634.4—2020
4术语和定义
下列术语和定义适用于本文件。4.1
巴科斯范式
Backus-Naur Form
一种形式化的元语言。用于以文本格式定义一种语言的语法。4.2
基本选择
basechoice
见基本值（4.3）。
基本值
basevalue
在“基木选择测试”中输入参数的取值，通常依据参数的代表值或典型值进行选择。也称为基木选择。
计算使用
见计算数据使用（4.5)。
computation data use
计算数据使用
在任何类型语句中，变量值的使用。4.6
condition
不包含布尔运算符的布尔表达式示例：“A控制流
control flow
在测试项运行期间所执行操作的序列。4.8
控制流子路径
control flow sub-path
测试项中的可执行语句的序列。4.9
数据定义
data definition
变量赋值语句。也被称为变量定义4.10
数据定义计算使用对
data definition c-use pair
数据定义和后续计算的数据使用，其中数据使用是使用数据定义中定义的值4.11
数据定义调词使用对
data definition p-use pair
数据定义和后续谓词的数据使用，其中数据使用是使用数据定义中定义的值。4.12
数据定义使用对
data definition-use pair
数据定义和后续的数据使用，其中数据使用是使用数据定义中定义的值。2
数据使用
data use
访问变量值的可执行语句。
判定结果
decision outcome
判定式的结果，可用于决定控制流选择方向。4.15
判定规则
decision rule
GB/T38634.4—2020
在判定表测试和因果图中产生特定结果的条件（也称为原因）和动作（也称为结果）的组合。4.16
定义使用对
definition-usepair
数据定义和后续谓词的数据使用或计算的数据使用，其中数据使用是使用数据定义中定义的值。4.17
定义使用路径
definition-use path
从变量定义到谓词使用(p-use)或计算使用(cuse)的控制流子路径。4.18
entrypoint
入口点
测试项中测试项开始执行的点。注：人口点是测试项的可执行语句，可由外部进程选择作为通过测试项的一个或多个路径的起点。它通常是测试项中的第一条可执行语句。
可执行语句
executable statement
在编译后将转换为目标代码的语句.该目标代码将在测试项运行时以程序化方式执行，并可能对程序数据执行操作。
exitpoint
出口点
测试项的最后一条执行的语句。注：出口点是通过测试项路径的终点，是测试项中的可执行语句。它或终止测试项，或将控制权返回到外部进程，这通常是测试项中的最后一条可执行语句。4.21
调词使用
见谓词数据使用（4.25）。
键值对
P-Vpair
测试项参数与赋给该参数的值的组合。在组合测试设计技术中，用作测试条件和测试覆盖项。4.23
测试项中可执行语句的序列。
predicate
计算结果为“真”或“假”的逻辑表达式，通常用于引导代码中的执行路径。4.25
请词数据使用
predicate data use
与判定语句中谓词部分的判定结果相关联的“数据使用”。3
GB/T38634.4—2020
子路径
sub-path
一个较大路径的一部分。
testmodel
测试模型
在测试用例设计过程中使用的测试项的表示4.28
变量定义
variabledefinition
见数据定义（4.9)。
5测试设计技术
5.1概述
本部分定义了基于规格说明的测试设计技术（5.2）、基于结构的测试设计技术（5.3)和基于经验的测试设计技术（5.4）。在基于规格说明的测试中，测试依据（如需求，规格说明，模型或用户需求）是设计测试用例的首要信息来源。在基于结构的测试中，测试项的结构（如源代码或模型结构)是设计测试用例的首要信息来源。在基于经验的测试中，测试人员的知识和经验是设计测试用例的首要信息来源。对手基于规格说明的测试，基于结构的测试和基于经验的测试，测试依据用于生成预期结果。上述测试设计技术是互补的，组合使用这些技术会使测试更加有效虽然在本部分中介绍的技术被划分为基于规格说明、基于结构和基于经验三类，但在实际使用中这些技术可以互换使用（如分支测试可以设计测试用例来测试一个互联网系统图形用户界面的逻鞋路径）。附录E中对此进行了举例。此外，尽管每种技术都是独立丁所有其他技术定义的.但实际上它们可以与其他技术结合使用
示例1：通过等价类划分导出的测试覆盖项可用于场景测试导出的测试用例的输人参数：本部分使用基于规格说明的测试和基于结构的测试的术语·这种技术分类也称为“黑盒测试”和“户盒测试”。术语“黑盒测试”和“白盒测试”指的是测试项内部结构的可见性。对于黑盒测试，测试项的内部结构是不可见的；对于白盒测试，测试项的内部结构是可见的。当一个测试设计技术同时基于测试项的规格说明和结构时，该测试设计技术被称为“灰盒测试”。本部分定义了GB/T38634.2（参见引言）中所述的通用测试设计和实现过程中步骤TD2（导出测试条件）、TD3（导出测试覆盖项）和TD1（导出测试用例）是如何应用于各测试设计技术的。本部分不提供使用这些技术的特定周境定义，即不说明每个技术在所有情况下使用的方法。本部分的用户可以参考附录B、附录C、附录D和附录E,以获得如何应用这些技术的详细示例。附录F对基于结构的测试设计技术之间的模盖关系给出了说明本部分定义的技术如图2所示，这组技术并不是全面的，部分测试人员和研究人员使用的技术未包含在本部分中。附录G给出了本部分定义的技术与GB/T15532一2008中测试设计技术的映射关系。基于规格说明的技术
等价类划分
分类树
边界值分析
语法测试
组合测试设计技术
本部分中的测试设计技术
基于结构的技术
谱句测试
分支测试
判定测试
分支条件测试
分支条件组合测试
完全组合测试
(5.2.5.3)
成对测试
(5.2.5.4)
单一选择测试
(5.2.5.5)
基本选择测试
(5.2.5.6)
判定表测试
因果图
状态转移测试
场景测试
随机测试
修正条件判定覆盖测试
数据流测试
全定义测试
(5.3.7.2)
全计算使用测试
(5.3.7.3)
全谓词使用测试
(5.3.7.4)
全使用测试
(5.3.7.5)
GB/T38634.4—2020
基于经验的技术
错误猜测法
全定义-使用路径测试
(5.3.7.8)
图2本部分包含的测试设计技术
在测试设计和实现过程的6个活动中，测试设计技术为导出测试条件（工D2）导出测试覆盖项（TD3）和导出测试用例（TD4）提供了独特而具体的指导。因此，每项技术都是采用这三个活动来定义的。
步骤TD2（导出测试条件）TD3（导出测试覆盖项）和TD4（导出测试用例）中存在不同级别的粒度。在每种技术中，术语\模型”用于描述准备测试项的逻辑，以便在步骤TD2中导出测试条件（例如，需要控制流模型来导出所有基于结构技术的测试条件）。某些情况可能要求整个模型作为测试条件，而在其他情况下，模型的一部分可作为测试条件示例2：在状态转移测试中，如果需要覆盖所有状态，则整个状态模型是测试条件。如果需要覆盖状态之间的特定转换，则每次转换都是一个测试条件。此外，由于某些技术有着共同的基础概念，所以它们的定义包含了相似的内容。5
GB/T38634.4—2020
示例3：等价类划分和边界值分析都基于等价类。在每种技术的导出测试用例步骤（TD4）中，创建的测试用例可以是“有效的”（即测试项的输入被当作正确而接受）或“无效”（即测试项至少有一个输入被当作不正确而拒绝，理想情况下给出适当的错误提示）。在某些技术中，例如等价类划分和边界值分析，通常使用“一对一”方法导出无效测试用例，因为它通过确保每个测试用例仅包含一个无效输入值来避免故障屏蔽，同时有效测试通常使用“最小化”方法导出用例.因此减少了覆盖有效测试覆盖项所需的测试用例数量（见5.2.1.3和5.2.3.3）。注：无效用例也被称为“负面测试用例”尽管本部分中定义的技术各自在单独的条目中进行了描述（看上去是互相排斥的），实际上它们可以结合使用。
示例4：可以使用边界值分析来选择测试输入值，之后使用成对测试来根据测试输入值设计测试用例。可以使用等价类划分来选择分类树的分类和所分的类，然后根据所分的类使用单一选择测试（技术）来构造测试用例。本部分提出的技术也可以与附录A中提供的测试类型结合使用。例如，等价类划分可用于易用性测试中识别用户组（测试条件）和代表性用户（测试覆盖项）。本章给出了技术的规范性定义。第6章给出了每种技术的相应规范性覆盖测量。附录B、附录C、附录D和附录E给出了每种技术的资料性案例。尽管本部分给出每种技术的示例都是人工操作的，但在实践中，可采用自动化操作来支持某些类型的设计和执行（例如，语句覆盖分析器可用于支持基于结构的测试）。附录A给出了如何将本部分中定义的测试设计技术应用于测试GB/T25000.10一2016中定义的质量特性的示例。
5.2基于规格说明的测试设计技术5.2.1等价类划分
5.2.1.1导出测试条件（TD2）
等价类划分使用测试项模型将测试项输入和输出划分为等价类（也称为“分区”），其中每个等价类都应当作为一个测试条件。这些等价类应该从测试依据导出，对于每个分区中的所有值，都可以被测试项类似地处理（即等价类中的值是“等同的”）。有效的输人输出以及无效的输人输出均可导出等价类划分。
示例：对于期望小写字母字符作为（有效）输人的测试项，可以派生的无效输人等价类包括包含整数、实数、大写字母字符、符号和控制字符的等价类，具体取决于测试期间所需的严遭程度。注1：对于输出等价类，基于测试项规格说明中描述的过程导出相应的输人分区。然后从输人分区中选择测试输人。
注2：无效的输出等价类通常对应于未明确指定的任何输出。由于未指定，通常会根据各测试人员的主观判断得到等价类。当应用基于经验的技术（如错误猜测)时，也可能出现这种主观形式的测试设计。注3：域分析法通常归类为等价类划分和边界值分析的结合。5.2.1.2导出测试覆盖项（TD3）每个等价类应该是一个测试覆盖项（即在等价类划分中，测试条件和测试覆盖项是同样的等价类）。5.2.1.3导出测试用例（TD4）
导出的测试用例应该实现每个测试覆盖项（即等价类）。下面是导出测试用例的步骤：a）确定选择测试用例所实现测试覆盖项的组合方法，下面是两种常见的方法：1）一对一，导出的每个测试用例用于覆盖一个特定的等价类；2
最小化，其中等价类由测试用例覆盖，使得导出的最小测试用例数至少覆盖所有等价类一次。
小提示：此标准内容仅展示完整标准里的部分截取内容，若需要完整标准请到上方自行免费下载完整标准文档。