| ·被测(协议)实现： | 一个或多个以相邻用户/提供者关系实现的OSI协议，这类协议作为一个实开放系统的
组成部分将通过测试进行研究分析。 |
| ·被测系统： | IUT所在的实开放系统。 |
| ·动态一致性要求： | 规范通信例中由有关OSI国际标准或CCITT建议所允许的可观察行为的一种要求。 |
| ·静态一致性要求： | 规范符合OSI国际标准或CCITT建议的实开放系统所允许的能力实现组合限制的要
求。 |
| ·(实现的)能力： | 由该实现所支持的有关协议的功能集合。 |
| ·协议实现一致性申明： | 由OSI实现或系统的提供者所作的一种申明，陈述一给定的OSI协议所应实现的有关能
力。 |
| ·PICS书写形式： | 由协议制定者或一致性测试套制定者编写的一种以问题形式而出现的文件，与某一OSI
实现或系统相关的文件完成后就成为PICS,， |
| ·测试协议实现的附加信息： | 由IUT的提供者或实现者提出的一种陈述，它包含或引用了与IUT及其测试环境有关
的全部信息(PICS给出的信息除外)，该陈述将能使测试实验室运行IUT的相应测试套。 |
| ·PIXIT书写形式： | 由测试实验室提供的一种以问题形式而出现的文件，这种文件在测试的准备期间完成后
就成为PIXIT。 |
| ·一致性实现： | 一个满足静态和动态一致性要求的IuT，它应与PICS所陈述的能力一致。 |
| ·系统一致性申明： | 综述实现的并与其一致的OSI国际标准或CCFIT建议的一种文件。 |
| ·(-个测试实验室的)客户： | 提交需进行-致性测试的系统或实现的组织。 |
| ·测试实验室： | 完成一致性测试的组织。它可能是第三方、一个用户组织、一个电信主管部门或一个公认
的私人运行机构，或者是一个提供者组织的可标识部分。 |
| ·静态-致性评审： | 通过对PICS与相关的国际标准或CCITT建议中表达的静态一致性要求进行比较，检验
IUT满足静态一致性要求的程度。 |
| ·基本互连测试： | 为了确定IUT与相关协议是否有足够的一致性以使互连成为可能而进行的有限范围的
测试，而不是进行全部测试。 |
| ·能力测试： | 验证IUT所声称的一种或多种能力是否存在的测试。
能力测试包括检查PICAS申明所支持的全部必备能力和任选能力，但不检查PICS申明
IUT不支持的那些任选能力。 |
| ·行为测试： | 确定IUT对一种或多种动态一致性要求满足程度而进行的测试。 |
| ·一致性分辨测试： | 为达到标准测试例中没有定义的测试目的而进行的非标准的，且很可能与系统相关的测
试，它可以根据一个或多个特定的一致性要求来考察OSI协议实现的行为。 |
| ·一致性测试： | 对IUT-致性实现的程度的测试。 |
| ·一致性评价过程： | 完成能对一种实现或系统与一个或多个OSI国际标准或CCITT建议的一致性进行评价
所需的全部一致性测试活动的完整过程。 |
| ·测试活动： | 对一个特定的IUT执行已参数化的可执行测试套并产生一致性记录的过程。 |
| ·嵌入测试： | 对多协议IUT中某个特定协议的测试，该IUT包含上述被测试的一个协议活动说明，但
并不规定多协议IUT中服务界面的控制或观察。
注：这个定义假定IUT的协议是按照连续的相邻用户和提供者关系排列的。 |
| ·(抽象)测试法： | 以适当的抽象程度描述测试IUT的方法，以使该描述与任何测试手段的具体实现无关，
但它所描述的这种测试方法应规范出足够详细的测试细节。 |
| ·抽象测试方法学： | 一种对抽象测试法进行描述和分类的方法。 |
| ·抽象测试例： | 以某种特定抽象测试法的抽象级所定义的、为获得特定测试目的(或测试目的特定组合)
所需活动的一种完整和独立的规范。它起始和终止于稳定的测试状态，该规范可能包含一个
或多个连续或并行的连接。
注：①从某种意义上讲，该规范应是完整的，即对于每个可观察的测试结果(即测试事件序列)来说，都能足以获得一个
清晰的测试裁决。
②从某种意义上讲，该规范应是独立的，即应能执行由其它这类测试例分离而来的某个可执行测试例(即该规范总
应包括起始和结束于“空闲”状态的可能性)。 |
| ·可执行测试例： | 抽象测试套的一种实现。
注：在GJB 2765.1—96～GJB 2765.5—96中所使用的“测试”一词，一般是指其普通的英语含义。在时可以作为抽象测
试例或可执行测试例的简称使用。应在上下文中理解其含义。 |
| ·测试目的： | 严密定义测试目标的非形式化描述，其焦点集中于诸如适当的OSI国际标准或CCITT
建议中所规定的单个一致性要求(例如，验证对特定参数的特定值的支持程度)。 |
| ·测试组目标： | 对指定测试组中测试目的所要达到的共同目标的非形式化描述。 |
| ·通用测试例： | 为达到一特定测试目的所需的动作规定，由测试体和该测试体开始的初始状态的描述来
定义。 |
| ·(测试)前序： | 从测试例起动的稳定状态直至测试体开始时的初始状态之间的一组测试步。 |
| ·测试体： | 为达到测试目的的-组测试步。 |
| ·(测试)后序： | 从测试体结束直至完成测试例的稳定状态之间的一组测试步。 |
| ·测试步： | 测试例命名的划分，它由测试事件和/或其它测试步构成。 |
| ·测试事件： | 在规范抽象级上的测试规范不可分的单元(如，发送或接收一个PDIJ)。 |
| ·无标识测试事件： | 用于提供PDU和/或ASP接收的测试事件，它们在测试项中没标识出来。 |
| ·测试状态： | 测试中涉及到的状态，包括SUT的状态、测试系统、抽象测试套(ATM)规范的控制观察
协议及其低层服务的状态(如果有关的话)的组合。 |
| ·稳定测试状态： | 能够维持，但没有指定下测试器行为的测试状态，其长度应足以跨越测试活动中从一个测
试例到另一测试例之间的间隙。 |
| ·空闲测试状态： | 没有建立相关协议连接，且SUT状态独立于以前执行的任何测试项的一种稳定测试状
态。 |
| ·暂态测试状态： | 除稳定测试状态以外的任何测试状态。 |
| ·初始测试状态： | 测试体起始的测试状态。 |
| ·(一致性)测试套： | 需要对一个或多个OSI协议进行动态一致性测试的测试例的完整集合，它可能组成嵌套
的测试组。 |
| ·测试例： | 一种通用的、抽象的或可执行的测试例。 |
| ·测试组： | 命名的有关测试例集合。 |
| ·通用测试套： | 由通用测试例组成的测试套。 |
| ·抽象测试套： | 由抽象测试例组成的测试套。 |
| ·可执行测试套： | 由可执行测试例组成的测试套。 |
| ·已选抽象测试套： | 利用特定的PICS和PIXIT所选择的某抽象测试套的子集。 |
| ·已选可执行测试套： | 利用特定的PICS和PIXIT所选择的某可执行测试套的子集。 |
| ·参数化抽象测试例： | 全部相应参数都支持符合特定PICS和PIXIT的值的测试例。 |
| ·参数化可执行测试例： | 全部相应参数都支持符合特定PICS和PIXIT的值，并且符合参数化抽象测试例的可执
行测试例。 |
| ·参数化抽象测试套： | 符合相应PICS和PIXIT的参数化的全部测试例的已选抽象测试套。 |
| ·参数化可执行测试套： | 符合相应的PICS和PIXIT的相应参数化的抽象测试套的全部参数化测试例中的已选可
执行测试套。 |
| ·一致性测试标准： | 包含标准化抽象测试套的国际标准或CCITT建议，或其草案。 |
| ·(结果的)可重复性： | 测试例的一种特性，即在相同条件下的相同IUT上进行重复执行，将导致相同的测试裁
决，并且通过扩展也可能成为测试套的一种特性。 |
| ·(结果的)可比较性： | 一致性评价过程的特性，即在不同的测试环境下，在相同的IUT上执行评价过程将对指
定的IUT应产生全部相同的一致性结论。 |
| ·(观察到的)测试结果： | 在特定参数化可执行测试例执行期间所产生的测试事件序列及其相关的数据、参数值序
列。 |
| ·预知测试结果： | 观察到的抽象测试例中标识过的测试结果。 |
| ·非预知测试结果： | 观察到的抽象测试例中未标识过的测试结果。 |
| ·(测试)裁决： | 在抽象测试例中规定的涉及测试例执行后有关IUT一致性的“通过”、“失败”、“不确定”
的声明。 |
| ·系统一致性测试报告： | 在一致性评价过程结束时编写的一种文件，它给出了有关系统或实现同进行一致性测试
的一组建议之间一致性的全部结论。 |
| ·协议一致性测试报告： | 在一致性评价过程结束时编写的一种文件，它给出了对某个特定协议进行测试的详细内
容，列出了所有的抽象测试例，标识出其中执行了相应可执行测试套的部分，并对执行过的每
个测试例给出测试裁决。 |
| ·有效测试事件： | 协议规范所允许，语法和语义都正确，且在协议规范允许时发生的测试事件。 |
| ·无效测试事件： | 至少违反了有关协议或传送语法规范的一个一致性要求的测试事件。 |
| ·不合适测试事件： | 在协议规范中不允许时出现的测试事件。 |
| ·语法无效测试事件： | 协议规范中语法上不允许的测试事件。 |
| ·语义无效测试事件： | 即非不合适，也非语法无效，但相应的有关协议规范含有语义错误(例如，PDU包含了超
过参数协商范围的参数)的测试事件。 |
| ·“通过”(裁决)： | 当观测到的测试结果在所关注的测试目的上对一致性要求给出一致性证据，且当涉及到
有关国际标准或CCITT建议的所有测试事件都有效时，给出一致性证据的测试裁决。 |
| ·“失败”(裁决)： | 当观察到的测试结果在该测试例所关注的测试目的上说明至少同一条一致性要求不一致
所给出的测试证据，或当其中至少含有一条相对于有关国际标准或CCITT建议是无效的测试
事件时所给出的测试裁决。 |
| ·“不确定”(裁决)： | 当观察到的测试结果既非“通过”，也非“失败”时，所给出的测试裁决。 |
| ·测试例错误： | 用于描述在测试例本身中检测出错误时测试例执行结果的术语。 |
| ·抽象测试例错误： | 因抽象测试例的错误所导致的测试例错误。 |
| ·可执行测试例错误： | 在抽象测试例的实现中的测试例错误。 |
| ·(测试例)异常终止： | 用于描述抽象测试例被测试系统提前终止时其执行结果的术语。 |
| ·一致性记录： | 作为一个测试活动结果而生产的可人工阅读的记录，它应是有关观察到的测试结果和验
证指定测试结果(包括测试裁决)的足够信息。 |
| ·控制观察点： | 抽象测试方法定义的在测试环境中发生测试事件被观察和控制的点。 |
| ·下测试器： | 在GJB 2765.1～GJB 2765.5用来表示在测试执行期间，通过下层服务提供者间接对IUT
的下层服务界面进行控制和观测的手段。 |
| ·上测试器： | 按照已选择的抽象测试方法的定义，在GJB 2765.1～2765.5，表示在测试执行期间用于
提供IUT上服务边界进行控制和观测的手段。 |
| ·抽象(N)服务原语： | 按照OSI服务定义的规定，与(N)服务边界上服务用户和服务提供者之间相互作用的独
立、于实现的描述。 |
| ·测试协调规程： | 在测试期间，上、下测试器之间合作的规则。 |
| ·测试管理协议： | 针对特定测试套的用于测试协调规程的协议。 |
| ·测试系统： | 包括下测试器实现的实系统。 |
| ·局部测试法： | 下测试器和上测试器都设置在测试系统内，且在IUT的服务边界有—PCO的抽象测试
方法。 |
| ·分布式测试法： | 上测试器在SUT中且在IUT服务边界上有—PCO的抽象测试方法。 |
| ·协调测试法： | 上测试器位于SUT中且为测试协调规程定义了标准TMP的抽象测试方法。从而可使
控制观察能单独依据下测试器活动进行规范，其中包括对测试管理PDU的控制和观察。 |
| ·远程测试方法： | 单独依据下测试器活动，规范测试事件的控制观察的抽象测试方法。其中有关测试协调
规程的某些要求可能在ATS中稳含地或非形式地加以说明，但其中对它们的可行性或实现不
做任何假设。 |
| ·测试手段： | 能完成测试例推论、选择、参数化和执行的设备和规程的组合。它应与参考的标准化
ATS一致，且能产生一致性记录。 |
| ·测试实现： | 产生测试IUT、手段的过程。 |
| ·(OSI)参考的标准化抽象测试套： | 实现了测试手段的标准化ATS。 |
| ·测试实现者： | 独立于测试实验室用户及其IUT，负责提供与ATS一致的IUT测试手段的组织。 |
| ·综合测试服务： | 由测试实验室对其用户提供的对一个或多个OSI协议进行一致性评价的一种服务。该
服务可以选择测试方法足以使得该服务适用于所有声称实现了某特定协议的实开放系统。 |