老宋的地盘

 找回密码
 我要加入
搜索
查看: 3750|回复: 3

[概念知识] 软件测试术语英语单词A B C

[复制链接]
发表于 2014-1-10 21:45:48 | 显示全部楼层 |阅读模式
abstract test case 抽象测试用例 参见 high level test case. acceptance 验收 参见 acceptance testing.
acceptance criteria 验收准则
为了满足组件或系统使用者、客户或其他授权实 体的需要,组件或系统必须达到的准则。[IEEE 610]
acceptance testing 验收测试
一般由用户/客户进行的确认是否可以接受一个 系统的验证性测试。是根据用户需求,业务流程 进行的正式测试以确保系统符合所有验收准则。 [与 IEEE 610 一致]
accessibility testing 可达性测试
可达性测试就是测试残疾人或不方便的人们 使用软件或者组件的容易程度[Gerrard]。即 被测试的软件是否能够被残疾或者部分有障 碍人士正常使用,这其中也包含了正常人在 某些时候发生暂时性障碍的情况下正常使 用,如怀抱婴儿等。
accuracy 准确性
软件产品的提供的结果的正确性、一致性和精确 程度的能力。[ISO9126] 参见 functionality testing
actual outcome 实际结果 参见 actual result actual result 实际结果 组件或系统测试之后产生或观察到的行为 ad hoc review 临时评审 非正式评审(和正式的评审相比)
ad hoc testing 随机测试
非正式的测试执行。即没有正式的测试准备、规 格设计和技术应用,也没有期望结果和必须遵循 的测试执行指南。 adaptability 适应性 软件产品毋需进行额外修改,而适应不同特定环 境的能力。[ISO9126] 参见 protability
agile testing 敏捷测试
对使用敏捷方法,如极限编程(Extreme programming)开发的项目进行的软件测试,强调 测试优先行的设计模式,见 test driven development algorithm test [TMap] 算法测试 参见 branch testing
alpha testing Alpha 测试
由潜在用户或者独立的测试团队在开发环境下或 者模拟实际操作环境下进行的测试,通常在开发 组织之外进行。通常是对现货软件(COTS)进行内 部验收测试的一种方式。
analyzability 可分析性
软件产品缺陷或运行失败原因可被诊断的能力, 或对修改部分的可识别能力。[ISO 9126] 参见 maintainability. analyzer 分析器 参见 static analyzer
anomaly 异常
任何和基于需求文档、设计文档、用户文档、标 准或者个人的期望和预期之间偏差的情况,都可 以称为异常。异常可以在但不限于下面的过程中 识别:评审(review)、测试分析(test analysis)、 编译(compilation)、软件产品或应用文档的使用 等。参见 defect, deviation, error, fault, failure, incident, problem arc testing 弧测试 参见 branch testing attractiveness 吸引力 软件产品吸引用户的能力.[ISO9126]参见 usability
audit 审计
对软件产品或过程进行的独立评审,来确认产品 是否满足标准、指南、规格说明书以及基于客观 准则的步骤等,包括下面的文档:(1)产品的内容 与形式(2)产品开发应该遵循的流程(3)度量符合 标准或指南的准则。[IEEE1028]
audit trail 审计跟踪
以过程输出作为起点,追溯到原始输入(例如: 数据)的路径。有利于缺陷分析和过程审计的开 展。[与 TMap 一致] automated testware 自动测试件 用于自动化测试中的测试件,如,工具脚本 availability 可用性 用户使用系统或组件的可操作和易用的程度,通 常以百分比的形式出现。[IEEE 610]
back-to-back testing 比对测试
用相同的输入,执行组件或系统的两个或多个变 量,在产生偏差的时候,对输出结果进行比较和 分析。
baseline 基线
通过正式评审或批准的规格或软件产品。以它作 为继续开发的基准。并且在变更的时候,必须通 过正式的变更流程来进行。[与 IEEE 610 一致] basic block 基本块 一个或多个连续可执行的语句块,不包含任何分 支语句。
basis test set 基本测试集
根据组件的内部结构或规格说明书设计的一组测 试用例集。通过执行这组测试用例可以保证达到 100%的指定覆盖准则(coverage criterion)的 要求。 bebugging 错误散播 参见 error seeding behavior 行为 组件或系统对输入值和预置条件的反应。
benchmark test 基准测试
(1)为使系统或组件能够进行度量和比较而制定 的一种测试标准;(2)用于组件或系统之间进行的 比较或和(1)中提到的标准进行比较的测试。[与 IEEE 610 一致] bespoke software 定制软件 为特定的用户定制开发的软件。与之对比的是现 货软件(off-the-shelf software)。 best practice 佳实践 在界定范围内,帮助提高组织能力的有效方法或 创新实践,通常被同行业组织视佳的方法或实践。
beta testing Beta 测试
用户在开发组织外,没有开发人员参与的情况下 进行的测试,检验软件是否满足客户及业务需求。 这种测试是软件产品获得市场反馈进行验收测试 的一种形式。
big-bang testing 大爆炸测试
非增量集成测试的一种方法,测试的时候将软件 单元、硬件单元或者两者同时,而不是阶段性的, 集成到组件或者整个系统中去进行测试。[与IEEE 610 一致]参见 integration testing。 black-box technique 黑盒技术 参见 black box test design technique black-box testing 黑盒测试 不考虑组件或系统内部结构的功能或非功能测 试。 black-box test design technique 黑盒测试设计技术 基于系统功能或非功能规格说明书来设计或者选 择测试用例的技术,不涉及软件内部结构。
bottom-up testing 自底向上测试
渐增式集成测试的一种,其策略是先测试底层的 组件,以此为基础逐步进行更高层次的组件测试, 直到系统集成所有的组件。参见 integration testing。
boundary value 边界值
通过分析输入或输出变量的边界或等价划分 (equivalence partition)的边界来设计测试用 例,例如,取变量的大、小值、中间值、比 大值大的值、比小值小的值等。 boundary value analysis 边界值分析 一种黑盒设计技术(black box test design technique),基于边界值进行测试用例的设计。 boundary value coverage 边界值覆盖 执行一个测试套件(test suite)所能覆盖的边界 值(boundary value)的百分比。 boundary value testing 边界值测试 参见 boundary value analysis。
branch 分支
在组件中,控制从任何语句到其它任何非直接后 续语句的一个条件转换,或者是一个无条件转换。 例如: case, jump, go to, if-then-else 语句. branch condition 分支条件 参见条件(condition) branch condition combination coverage 分支条件组合覆盖 参见 multiple condition coverage.  branch condition combination testing 分支条件组合测试 参见 multiple condition testing. branch condition coverage 分支条件覆盖 参见 condition coverage.  
branch coverage 分支覆盖
执行一个测试套件(test suite)所能覆盖的分支 (branch)的百分比。100%的分支覆盖(branch coverage)是指 100%判定条件覆盖(decision covergate) 和 100%的语句覆盖(statement covergage)。 bug 缺陷 参见 defect。 bug report 缺陷报告 参见 defect report。  business process-based testing 基于业务过程测试 一种基于业务描述和/或业务流程的测试用例设 计方法。
Capability Maturity Model (CMM)
能力成熟度模型
描述有效的软件开发过程关键元素的一个五个等 级的框架,能力成熟度模型包含了在软件开发和 维护中计划、工程和管理方面的佳实践(best practice),缩写为 CMM。[CMM]
Capability Maturity Model Integration (CMMI)
能力成熟度模型集 成
描述有效的软件产品开发和维护过程的关键元素 框架,能力成熟度模型集成包含了软件开发计划、 工程和管理等方面的佳实践,是 CMM 的指定 的继承版本。
capture/playback tool 捕获/回放工具
一种执行测试工具,能够捕获在手工测试过程中 的输入,并且生成可执行的自动化脚本用于后续 阶段的测试(回放过程)。这类工具通常使用在 自动化回归测试(regression test)中。 capture/replay tool 捕获/回放工具 参见 capture/playback tool
CASE
计算机辅助软件工 程
Computer Aided Software Engineering 的首字 母缩写。
CAST
计算机辅助软件测 试
Computer Aided Software Testing 的首字母缩 写,参见 test automation。在测试过程中使用 计算机软件工具进行辅助的测试。 cause-effect graph 因果图 用来表示输入(原因)与结果之间关系的图表, 因果图可以用来设计测试用例。 cause-effect graphing 因果图技术 通过因果图(case-effect graph)设计测试用例 的一种黑盒测试设计技术。 cause-effect analysis 因果分析 参见因果图技术(case-effect graphing)。 cause-effect decision table 因果决策表 参见决策表 (decision table)。 certification 认证 确认一个组件、系统或个人具备某些特定要求的 过程,比如通过了某个考试。 changeability 可变性 软件产品适应修改的能力,[ISO 9126] 参见 maintainability change control 变更控制 参见 configuration control
change control board
变更控制委员会 CCB
参见 configuration control board
checker 检验员 参见评审员(Reviewer) chow's coverage metrics N 切换覆盖度量 参见 N 切换覆盖(N-switch coverage)[Chow] classification tree method 分类树方法 运用分类树法而进行的一种黑盒测试设计技术, 通过输入和/或输出域的组合来设计测试用例 [Grochtmann]   
code 代码
计算机指令和数据定义在程序语言中的表达形式 或是汇编程序、编译器或其他翻译器的一种输出 形式。 code analyzer 代码分析器 参见静态分析器(static code analyzer)
code coverage 代码覆盖
一种分析方法,用于确定软件的哪些部分被测试 套件(test suite)覆盖到了,哪些部分没有。例 如:语句覆盖(statement covergage),判定覆盖 (decision coverage)和条件覆盖(condition covergate)。 code-based testing 基于代码的测试 参见 white box testing
co-existence 共存性
软件产品与通用环境下与之共享资源的其它独立 软件之间共存的能力。[ISO 9126] 参见可移植性 (portability)。
commercial off-the-shelf software
商业现货软件 参见现货软件(off-the shelf software)
comparator 比较器 参见 test comparator。 compiler 编译器 将高级命令语言编写的程序翻译成能运行的机器 语言的工具[IEEE 610]. complete testing 完全测试 参见穷尽测试(exhaustive testing) completion criteria 完成准则 参见退出准则(exit criteria) complexity 复杂性 系统或组件的设计和/或内部结构难于理解、维护 或验证的程度。参见 cyclomatic complexity. compliance 一致性 软件产品与法律和类似规定的标准、惯例或规则 的一致性方面的能力。[ ISO9126] compliance testing 一致性测试 确定组件或系统是否满足标准的测试过程。 component 组件 一个可被独立测试的小软件单元。 component integration testing 组件集成测试 为发现集成组件接口之间和集成组件交互产生的 缺陷而执行的测试。
component specification 组件规格说明
根据组件的功能定义为特定输入而应该产生的输 出规格进行的功能性和非功能性行为的描述。例 如:资源使用(resource utilization). compound condition 复合条件 通过逻辑操作符(AND, OR 或者 XOR)将两个或 多个简单条件连结起来:如,“A>0 AND B<1000” concrete test case 具体测试用例 参见低阶测试用例(low level test case). concurrency testing 并发测试 测试组件或系统的两个或多个活动在同样的间隔 时间内如何交叉或同步并发。[与 IEEE 610 一致] condition 条件 一个可被判定为真、假(true,false)的逻辑表达 式。例如: A>B. condition combination coverage 条件组合覆盖 参见多条件覆盖(multiple condition coverage). condition combination testing 条件组合测试 参见多条件测试(multiple condition testing).
condition coverage 条件覆盖
执行测试套件(test suite)能够覆盖到的条件百 分比。100%的条件覆盖要求测试到每一个条件语 句真、假(true,false)的条件。
condition determination coverage
条件决定覆盖
执行测试套件(test suite)覆盖到的能够独立影 响判定结果的单个条件的百分比。100%的条件决 定覆盖意味着 100%的判定条件覆盖。
condition determination testing
条件决定测试
一种白盒测试技术,是对能够独立影响决策结果 的单独条件的测试。 condition testing 条件测试 一种白盒测试技术,设计测试用例以执行条件的 结果。
condition outcome 条件结果 条件判定的结果,为真或假。 confidence test 置信测试 参见冒烟测试(smoke testing) configuration 配置 根据定义的数值、特性及其相关性综合设置一个 组件或者系统。 configuration auditing 配置审核 对配置库及配置项的内容进行检查的过程,比如 检查标准的一致性。 [IEEE 610]
configuration control 配置控制
配置管理的一个方面,包括在正式配置完成之后 对配置项进行评价、协调、批准或撤消、以及变 更修改的控制。 [IEEE 610]
configuration control board (CCB)
配置控制委员会
负责评估、批准或拒绝配置项修改的组织,此组 织应确保被批准的配置修改的执行。 [IEEE 610]
configuration identification
配置标识
配置管理的要素之一,包括选择配置项,并在技 术文档中记录其功能和物理特性。[IEEE 610]
configuration item 配置项
配置管理中的硬件、软件或软、硬件结合体的集 合,在配置管理过程中通常被当做一个实体。 [IEEE 610]
configuration management
配置管理
一套技术和管理方面的监督原则,用于确定和记 录一个配置项的功能和物理属性、控制对这些属 性的变更、记录和报告变更处理和实现的状态、 以及验证与指定需求的一致性。[IEEE 610]
configuration management tool
配置管理工具
支持对配置项进行识别、控制、变更管理、版本 控制和发布配置项基线(baseline)的工具.[IEEE 610] configuration testing 配置测试 参见可移植性测试(portability testing) confirmation testing 确认测试 参见再测试(re-testing) conformance testing 一致性测试 参见符合性测试(compliance testing)。 consistency 一致性 在系统或组件的各组成部分之间和文档之间无矛 盾,一致,符合标准的程度。[IEEE 610] control flow 控制流 执行组件或系统中的一系列顺序发生的事件或路 径。 control flow graph 控制流图 通过图形来表示组件或系统中的一系列顺序发生 的事件或路径。 control flow path 控制流路径 参见路径(path) conversion testing 转换(移植)测试 用于测试已有系统的数据是否能够转换到替代系 统上的一种测试。 COTS 现货软件 Commercial Off-The-Shelf software 的首字母 缩写。参见 Off-The-Shelf software coverage 覆盖 用于确定执行测试套件所能覆盖项目的程度,通 常用百分比来表示。
coverage analysis 覆盖分析
对测试执行结果进行特定的覆盖项分析,判断其 是否满足预先定义的标准,是否需要设计额外的 测试用例。
coverage item 覆盖项
作为测试覆盖的基础的一个实体或属性:如等价 划分(equivalent partitions)或代码语句(code statement)等。
coverage tool 覆盖工具
对执行测试套件(test suite)能够覆盖的结构元 素如语句(statement)、分支(branch)等进行客观 测量的工具。 custom software 定制软件 参见 bespoke software。
cyclomatic complexity 圈复杂度
程序中独立路径的数量。一种代码复杂度的衡量 标准,用来衡量一个模块判定结构的复杂程度,数 量上表现为独立现行路径条数,即合理的预防错 误所需测试的少路径条数,圈复杂度大说明程 序代码可能质量低且难于测试和维护,根据经验, 程序的可能错误和高的圈复杂度有着很大关系。 圈复杂度=L-N + 2P,其中 L 表示为结构图(程序 图)的边数;N 为结构图(程序图)的节点数目; P 为无链接部分的数目。[与 McCabe 一致] cyclomatic number 圈数 参见 cyclomatic complexity。

您需要登录后才可以回帖 登录 | 我要加入

本版积分规则

歌名 - 歌手
0:00

    QQ|手机版|小黑屋|工具箱|老宋 ( 备案中... )

    GMT+8, 2024-11-23 16:10 , Processed in 0.108093 second(s), 30 queries , Gzip On.

    Powered by Discuz! X3.5

    © 2001-2024 Discuz! Team.

    快速回复 返回顶部 返回列表