D
| ||
daily build
|
每日构建
|
每天对整个系统进行编译和链接的开发活动,从而保证在任何时候包含所有变更的完整系统是可用的。
|
data definition
|
数据定义
|
给变量赋了值的可执行语句。
|
data driven testing
|
数据驱动测试
|
将测试输入和期望输出保存在表格中的一种脚本技术。通过这种技术,运行单个控制脚本就可以执行表格中所有的测试。像录制/回放这样的测试执行工具经常会应用数据驱动测试方法。[Fewster and Graham],参见keyword driven testing.
|
data flow
|
数据流
|
数据对象的顺序的和可能的状态变换的抽象表示,对象的状态可以是:创建、使用和销毁。[Beizer]
|
data flow analysis
|
数据流分析
|
一种基于变量定义和使用的静态分析(static analysis)模式。
|
data flow coverage
|
数据流覆盖
|
执行测试套件(test suite)能够覆盖已经定义数据流的百分比。
|
data flow testing
|
数据流测试
|
一种白盒测试设计技术:设计的测试用例用来测试变量的定义和使用路径。
|
data integrity testing
|
数据完整性测试
|
参见database integrity testing。
|
database integrity testing
|
数据库完整性测试
|
对数据库的存取和管理进行测试的方法和过程,确保数据库如预期一样进行存取、处理等数据功能,同时也确保数据在存取过程中没有出现不可预料的删除、更新和创建。
|
dead code
|
死代码
|
参见unreachable code。
|
debugger
|
调试器
|
参见debugging tool。
|
debugging
|
调试
|
发现、分析和去除软件失败根源的过程。
|
debugging tool
|
调试工具
|
程序员用来复现软件失败、研究程序状态并查找相应缺陷的工具。调试器可以让程序员单步执行程序、在任何程序语句中终止程序和设置、检查程序变量。
|
decision
|
判定
|
有两个或多个可替换路径控制流的一个程序控制点。也是连接两个或多个分支的节点。
|
decision condition coverage
|
判定条件覆盖
|
执行测试用例套件
(test suite)
能够覆盖的条件结果
(condition outcomes)
和判定结果
(decision outcomes)
的百分比,
100%
的判定条件覆盖意味着
100%
的判定覆盖和
100%
的条件覆盖。
|
decision condition testing
|
判定条件测试
|
一种白盒测试(white box)设计技术,设计的测试用例用来测试条件结果(condition outcoems)和判定结果(decision outcomes)。
|
decision coverage
|
判定覆盖
|
执行测试套件能够覆盖的判定结果(decsion outcomes)的百分比。100%的判定覆盖(decision converage)意味着100的分支覆盖(branch coverage)和100%的语句覆盖(statement coverage)。
|
decision table
|
决策表
|
一个可用来设计测试用例的表格,一般有条件桩、行动桩和条件规则条目和行动规则条目组成。
|
decision table testing
|
决策表测试
|
一种黑盒测试设计技术,设计的测试用例用来测试判定表中各种条件的组合。[Veenendaal]
|
decision testing
|
决策测试
|
白盒测试设计技术的一种,设计测试用例来执行判定结果。
|
decision outcome
|
判定结果
|
判定的结果(可以来决定执行哪条分支)。
|
defect
|
缺陷
|
可能会导致软件组件或系统无法执行其定义的功能的瑕疵,例如:错误的语句或变量定义。如果在组件或系统运行中遇到缺陷,可能会导致运行的失败。
|
defect density
|
缺陷密度
|
将软件组件或系统的缺陷数和软件或者组件规模相比的一种度量(标准的度量术语包括,如每千行代码、每个类或功能点存在的缺陷数)。
|
Defect Detection Percentage (DDP)
|
缺陷发现百分比
|
在一个测试阶段发现的缺陷数除以在测试阶段和之后其他阶段发现的缺陷总数所得的百分比数。
|
defect management
|
缺陷管理
|
发现、研究、处置、去除缺陷的过程。包括记录缺陷、分类缺陷和识别缺陷可能造成的影响。[与IEEE 1044一致]
|
defect management tool
|
缺陷管理工具
|
一个方便记录和跟踪缺陷的工具,通常包括以缺陷修复操作流程为引导的任务分配、缺陷修复、重新测试等行为的跟踪和控制,并且提供文档形式的报告。参见 incident management tool.
|
defect masking
|
缺陷屏蔽
|
一个缺陷阻碍另一个缺陷被发现的情况[与IEEE 610一致]
|
defect report
|
缺陷报告
|
对造成软件组件或系统不能实现预期功能的缺陷进行描述的报告文件。
|
defect tracking tool
|
缺陷跟踪工具
|
参见defect management tool
|
definition-use pair
|
定义-使用对
|
变量在程序中定义和使用的相关性,变量使用包括变量计算(比如:乘)或者变量引导程序执行一条路径(预定义)。
|
deliverable
|
交付物
|
过程中生成的交付给客户的(工作)产品。
|
design-based testing
|
基于设计的测试
|
根据组件或系统的构架或详细设计设计测试用例的一种测试方法(例如:组件或系统之间接口的测试)。
|
desk checking
|
桌面检查
|
通过手工模拟执行来对软件或规格说明而进行的测试。参见 static analysis.
|
development testing
|
开发测试
|
通常在开发环境下,开发人员在组件或系统实现过程中进行的正式或非正式的测试。[与IEEE 610 一致]
|
deviation
|
偏离
|
参见incident。
|
deviation report
|
偏离报告
|
参见incident report。
|
dirty testing
|
负面测试
|
参见negative testing。
|
documentation testing
|
文档测试
|
关于文档质量的测试,例如:对用户手册或安装手册的测试。
|
domain
|
域
|
一个可供有效输入和/或输出值选择的集合。
|
driver
|
驱动器
|
代替某个软件组件来模拟控制和/或调用其他组件或系统的软件或测试工具。[与TMap一致]
|
dynamic analysis
|
动态分析
|
组件或系统的执行过程中对其行为评估的过程,例如对内存性能、CPU使用率等的估算。[与IEEE 610一致]
|
dynamic analysis tool
|
动态分析工具
|
为程序代码提供实时信息的工具。通常用于识别未定义的指针,检测指针算法和内存地址分配、使用及释放的情况以及对内存泄露进行标记。
|
dynamic comparison
|
动态比较
|
在软件运行过程中(例如用测试工具执行),对实际结果和期望结果的比较。
|
dynamic testing
|
动态测试
|
通过运行软件的组件或系统来测试软件。
|
E
| ||
efficiency
|
效率
|
一定条件下根据资源的使用情况,软件产品能够提供适当性能的能力。[ISO 9126]
|
efficiency testing
|
效率测试
|
确定测试软件产品效率的测试过程。
|
elementary comparison testing
|
基本比较测试
|
一种黑盒测试设计技术:根据判定条件覆盖的理念,设计测试用例来测试软件各种输入的组合。[TMap]
|
emulator
|
仿真器
|
一个接受同样输入并产生同样输出的设备、计算机程序或系统。[IEEE 610]参见simulator
|
entry criteria
|
入口准则
|
进入下个任务(如测试阶段)必须满足的条件。准入条件的目的是防止执行不能满足准入条件的活动而浪费资源
[Gilb and Graham]
。
|
entry point
|
入口点
|
一个组件的第一个可执行语句。
|
equivalence class
|
等价类
|
参见equivalence partition。
|
equivalence partition
|
等价类划分
|
根据规格说明,输入域或输出域的一个子域内的任何值都能使组件或系统产生相同的响应结果。
|
equivalence partition coverage
|
等价划分覆盖
|
执行测试套件能够覆盖到的等价类的百分比。
|
equivalence partitioning
|
等价类划分技术
|
黑盒测试用例设计技术:该技术从组件的等价类中选取典型的点进行测试。原则上每个等价类中至少要选取一个典型的点来设计测试用例。
|
error
|
错误
|
人为的产生不正确结果的行为。[与IEEE 610一致]
|
error guessing
|
错误推测
|
根据测试人员以往的经验,猜测在组件或系统中可能出现的缺陷以及错误,并以此为依据来进行特殊的用例设计以暴露这些缺陷。
|
error seeding
|
错误散播
|
在组件或系统中有意插入一些已知缺陷(
defect
)的过程,目的是为了得到缺陷的探测率和除去率,以及评估系统中遗留缺陷的数量。[IEEE 610]
|
error tolerance
|
容错
|
组件或系统存在缺陷的情况下保持连续正常工作状态的能力。[与IEEE 610一致]
|
evaluation
|
评估
|
参见testing。
|
exception handling
|
异常处理
|
组件或系统对错误输入的行为反应。错误输入包括人为的输入、其他组件或系统的输入以及内部失败引起的输入等。
|
executable statement
|
可执行语句
|
语句编译后可以转换为目标代码,同时在程序运行的时候可以按步骤执行并且可以对数据进行相应的操作。
|
exercised
|
被执行
|
测试用例运行后被执行的语句、判定和程序的结构元素
|
exhaustive testing
|
穷尽测试
|
测试套件包含了软件输入值和前提条件所有可能组合的测试方法。
|
exit criteria
|
出口准则
|
和利益相关者达成一致的系列通用和专门的条件,来正式的定义一个过程的结束点。出口准则的目的可以防止将没有完成的任务错误地看成任务已经完成。测试中使用的出口准则可以来报告和计划什么时候可以停止测试。[与Gilb和Graham一致]
|
exit point
|
出口点
|
组件中最后一个可执行语句。
|
expected outcome
|
预期结果
|
参见expected result。
|
expected result
|
预期结果
|
在特定条件下根据规格说明或其他资源说明,组件或系统预测的行为。
|
experienced-based test design technique
|
基于经验的测试设计技术
|
根据测试人员的经验、知识和直觉来进行用例设计和/或选择的一种技术。
|
exploratory testing
|
探索性测试
|
非正式的测试设计技术:测试人员能动的设计一些测试用例,通过执行这些测试用例和在测试中得到的信息来设计新的更好的测试用例。[和Bach一致]
|
F
| ||
fail
|
失败
|
假如测试的实际结果与预期结果不一样,我们就认为这个测试的状态为失败。
|
failure
|
失效
|
组件/系统与预期的交付、服务或结果存在的偏差。[与Fenton一致]
|
failure mode
|
失效模式
|
失效在物理上或功能上的表现。例如,系统在失效模式下,可能表现为运行缓慢、输出错误或者执行的彻底中断。[IEEE 610]
|
Failure Mode and Effect Analysis (FMEA)
|
失效模式和影响分析 (FMEA)
|
一个系统的进行风险识别和标识可能的失效模式的系统方法,用来预防失效的发生。
|
failure rate
|
失效率
|
指定类型中单位度量内发生失效的数目。例如,单位时间失效数、单位处理失效数、单位计算机运行失效数。[IEEE 610]
|
fault
|
故障
|
参见 defect。
|
fault density
|
故障密度
|
参见 defect density。
|
Fault Detection Percentage (FDP)
|
故障发现率(FDP)
|
参见 Defect Detection Percentage (DDP)。
|
fault masking
|
故障屏蔽
|
参见 defect masking。
|
fault tolerance
|
故障容限
|
软件产品存在故障或其指定接口遭到破坏时,继续维持特定性能级别的能力。[ISO 9126] 参见 reliability。
|
fault tree analysis
|
故障树分析
|
分析产生故障原因的一种方法。
|
feasible path
|
可达路径
|
可通过一组输入值和入口条件而执行到的一条路径。
|
feature
|
特性
|
需求文档指定的或包含的一个组件或者系统的属性(例如:reliability, usability 或者 design constraints)。 [与IEEE 1008一致]
|
field testing
|
现场测试
|
参见 beta testing
|
finite state machine
|
有限状态机
|
包含有限数目状态和状态之间转换的一种计算模型,同时可能伴随一些可能的(触发)行为。[IEEE 610]
|
finite state testing
|
有限状态测试
|
参见 state transition testing。
|
formal review
|
正式评审
|
对评审过程及需求文档化的一种特定的评审。例如,检视(inspection)。
|
frozen test basis
|
冻结测试基准
|
测试基准文档,只能通过正式的变更控制过程进行修正。参见baseline
|
Functional Point Analysis (FPA)
|
功能点分析
|
对信息系统功能进行规模度量的一种方法。该度量独立于具体的技术实现,可以作为生产率度量、资源需求估算和项目控制的基础。
|
functional integration
|
功能集成
|
合并组件/系统以尽早实现基本功能的一种集成方法。参见integration testing。
|
functional requirement
|
功能需求
|
指定组件/系统必须实现某项功能的需求。[IEEE 610]
|
functional test design technique
|
功能测试设计技术
|
通过对组件或系统的功能规格说明分析来进行测试用例的设计和/或选择的过程,该过程不涉及软件的内部结构。参见 black box test design techinque。
|
functional testing
|
功能测试
|
通过对组件/系统功能规格说明的分析而进行的测试。参见 black box testing。
|
functionality
|
功能性
|
软件产品在规定条件下使用时,所提供的功能达到宣称的和隐含需求的能力。[ISO 9126]
|
functionality testing
|
功能性测试
|
判断软件产品功能性的测试过程。
|
G
| ||
glass box testing
|
玻璃盒测试
|
参见 white box testing
|