软件测试术语二(D-G)

 

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
  • 0
    点赞
  • 2
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值