H | ||
heuristic evaluation | 启发式评估 | |
high level test | 概要测试用 | 没有具体的（实现级别）输入数据和预期结果的测试用例。实际值没有定义或是可变的，而用逻辑概念来 |
case | 例 | 代替。参见 low level test case。 |
horizontal traceability | 水平可追踪性 | 一个测试级别的需求和相应级别的测试文档（例如测试计划、测试设计规格、测试用例规格和测试过程规格或测试脚本）之间的可追踪性。 |
I | ||
impact analysis | 影响分析 | 对需求变更所造成的开发文档、测试文档和组件的修改的评估。 |
incident | 事件 | 任何有必要调查的事情。[与IEEEE 1008 一致] |
incident logging | 事件日志 | 记录所发生的（例如，在测试过程中）事件的详细情况。 |
incident management | 事件管理 | 识别、调查、采取行动和处理事件的过程。该过程包含对事件进行记录、分类并辨识其带来的影响。 [IEEE 1044] |
incident management tool | 事件管理工具 | 辅助记录事件并对事件进行状态跟踪的工具。这种工具常常具有面向工作流的特性，以跟踪和控制事件的资源分配、更正和再测试，并提供报表。参见 defect management tool |
incident report | 事件报告 | 报告任何需要调查的事件(如在测试过程中需要调查的事件)的文档。[IEEE 829] |
incremental development model | 增量开发模型 | 一种开发生命周期：项目被划分为一系列增量，每一增量都交付整个项目需求中的一部分功能。需求按优先级进行划分，并按优先级在适当的增量中交付。在这种生命周期模型的一些版本中（但不是全部），每个子项目均遵循一个“微型的V模型”，具有自有的设计、编码和测试阶段。 |
incremental testing | 增量测试 | 每次集成并测试一个或若干组件/系统，直到所有组件/系统都已经被集成或测试的一种测试。 |
independence | 独立 | 职责分离，有助于客观地进行测试。 [DO-178b] |
infeasible path | 不可达路径 | 通过任何输入都无法执行到的路径。 |
informal review | 非正式评审 | 一种不基于正式（文档化）过程的评审。 |
input | 输入 | 被组件读取的变量（无论存储于组件之内还是之外）。 |
input domain | 输入域 | 有效输入的集合。参见domain |
input value | 输入值 | 输入的一个实例。参见input |
inspection | 审查 | 一种同级评审，通过检查文档以检测缺陷，例如不符合开发标准，不符合更上层的文档等。这是最正式的评审技术，因此总是基于文档化的过程。 [IEEE 610, IEEE 1028] 参见 peer review |
inspection leader | 审查负责人 | 参见 moderator |
inspector | 检视人/审查员 | 参见 reviewer |
installability | 可安装性 | 软件产品在指定环境下进行安装的性能。 [ISO 9126] 参见 portability |
installability testing | 可安装性测试 | 测试软件产品可安装性的过程。 参见 portability testing |
installation guide | 安装指南 | 帮助安装人员完成安装过程的使用说明，可存放在任何合适的介质上。可能是操作指南、详细步骤、安装向导或任何其他类似的过程描述。 |
installation wizard | 安装向导 | 帮助安装人员完成安装过程的软件，可存放在任何合适的介质上。它通常会运行安装过程、反馈安装结果，并提示安装选项。 |
instrumentation | 探测 | 在程序中插入附加代码，以便在程序执行时收集其执行信息。例如，用于度量代码覆盖。 |
instrumenter | 探测工具 | 用于执行探测的软件工具。 |
intake test | 预测试 | 冒烟测试的一种特例，用于决定组件/系统是否能够进行更深入的测试。通常在测试执行的初始阶段实施。 |
integration | 集成 | 把组件/系统合并为更大部件的过程。 |
integration testing | 集成测试 | 一种旨在暴露接口以及集成组件/系统间交互时存在的缺陷的测试。参见 component integration testing, system integration testing |
integration testing in the large | 系统集成测试 | 参见 system integration testing |
integration testing in the small | 组件集成测试 | 参见 component integration testing |
interface testing | 接口测试 | 一种集成测试类型，注重于测试组件/系统之间的接口。 |
interoperability | 互操作性 | 软件产品与一个或多个指定组件/系统进行交互的能力。 [ISO 9126] 参见 functionality |
interoperability testing | 互操作性测试 | 判定软件产品可交互性的测试过程。参见 functionality testing |
invalid testing | 无效性测试 | 使用应该被组件/系统拒绝的输入值进行的测试。参见 error tolerance |
isolation testing | 隔离测试 | 将组件与其周边组件隔离后进行的测试。如果有必要，使用桩(stubs)或驱动器(drivers)来模拟周边程序。 |
item transmittal report | 版本发布报告 | 参见 release note |
iterative development model | 迭代开发模型 | 一种开发生命周期：项目被划分为大量迭代过程。一次迭代是一个完整的开发循环，并（对内或对外）发布一个可执行的产品，这是正在开发的最终产品的一个子集，通过不断迭代最终成型的产品。 |
K | ||
key performance indicator | 关键性能指标 | 参见 performance indicator |
keyword driven testing | 关键字驱动测试 | 一种脚本编写技术，所使用的数据文件不单包含测试数据和预期结果，还包含与被测程序相关的关键词。用于测试的控制脚本通过调用特别的辅助脚本来解释这些关键词。 |
L | ||
LCSAJ | LCSAJ | （Linear Code Sequence And Jump）线性代码序列和跳转。包含以下三项（通常通过源代码清单的行号来识别）：可执行语句的线性序列的开始、结束以及在线性序列结尾控制流所转移到的目标行。 |
LCSAJ coverage | LCSAJ覆盖 | 测试套件所检测的组件的 LCSAJ 百分比。 LCSAJ 达到100％意味着决策覆盖(decision coverage)为100％。 |
LCSAJ testing | LCSAJ测试 | 一种白盒测试设计技术，其测试用例用于执行 LCSAJ。 |
learnability | 易学性 | 软件产品具有的易于用户学习的能力。[ISO 9126] 参见usability |
level test plan | 级别测试计划 | 通常用于一个测试级别(test level)的测试计划。参见 test plan |
link testing | 组件集成测试 | 参见 component integration testing |
load testing | 负载测试 | 一种通过增加负载来测量组件或系统的测试方法。例如：通过增加并发用户数和（或）事务数量来测量组件或系统能够承受的负载。参见 stress testing |
logic-coverage testing | 逻辑覆盖测试 | 参见 white box testing [Myers] |
logic-driven testing | 逻辑驱动测试 | 参见 white box testing |
logical test case | 逻辑测试用例/抽象测试用例 | 参见 high level test case |
