Defect |
缺陷 |
|
||
Defect Rate |
缺陷率 |
|
||
Verification & Validation |
验证和确认 |
|
||
Failure |
故障 |
|
||
White-box Testing |
白盒测试 |
|
||
Black-box Testing |
黑盒测试 |
根据软件的规格对软件进行的测试,这类测试不考虑软件内部的运作原理,因此软件对用户来说就像一个黑盒子 |
||
Unit Testing |
单元测试 |
|
||
Integration Testing |
集成测试 |
|
||
System Testing |
系统测试 |
|
||
regression testing |
回归测试 |
|
||
Acceptance Testing |
接受测试 |
|
||
actual outcome |
实际结果 |
被测对象在特定的条件下实际产生的结果。 |
||
application software |
应用软件 |
|||
ASQ |
自动化软件质量 |
automated software quality |
||
assertion |
断言 |
指定一个程序必须已经存在的状态的一个逻辑表达式,或者一组程序变量在程序执行期间的某个点上必须满足的条件 |
||
automated testing |
自动化测试 |
使用自动化测试工具进行测试,这类测试一般不需要人干预,通常在GUI、性能等测试中用的较多 |
||
baseline |
基线 |
一个已经被正式评审和标准的规格产品,她作为进一步开发的一个基础,并且必须通过正式的变更流程来变更 |
||
Basis test set |
基本测试集 |
根据代码逻辑引出来的一个测试用例集合,它保证能获得100%的分支覆盖 |
||
boundary value |
边界值 |
一个输入或输出,他处在等价类的边界上 |
||
boundary value coverage |
边界值覆盖 |
通过测试用例,测试组件等价类的所有边界值 |
||
boundary value testing |
边界值测试 |
通过边界值分析方法来生成测试用例的一种测试策略 |
||
boundary value Analysis |
边界值分析 |
该分析一般与等价类一起使用,经验认为软件的错误经常在输入边界上产生,因此边界值分析就是分析软件输入边界的一种方法 |
||
branch condition |
分支条件 |
|
||
branch condition combination testing分支条件组合测试 |
|
通过执行分支条件结果组合来设计测试用例的一中方法 |
||
branch condition combination coverage |
分支条件覆盖 |
在每个判定中所有分支条件结果被测试用例覆盖到的百分比 |
||
branch coverage |
分支覆盖 |
功过测试执行到的分支的百分率 |
||
branch outcome |
分支结果 |
见判定结果(decision outcome) |
||
breadth testing |
广度测试 |
在测试中测试一个产品的所有功能,但是不测试更细节的特性 |
||
bug |
缺陷 |
|
||
CASE |
计算机辅助软件工程用于支持软件开发的一个自动化系统 |
Computer aided software engineering |
||
CAST |
计算机辅助测试 |
在测试过程中使用计算机软件工具进行的辅助测试 |
||
cause-effect graph |
因果图 |
一个图形,用来表示输入(原因)与结果之间的关系,可以被用来是设计测试用例 |
||
change control |
变更控制 |
一个用于计算机系统或系统数据修改的过程,该过程是质量保证程序的一个关键子集,需要被明确的描述 |
||
code audit |
代码审计 |
由一个人、组或工具对原代码进行的一个独立的评审,以验证其与设计规格、程序标准的一致性。正确性和有效性也会被评价。 |
||
Code coverage |
代码覆盖率 |
一种分析方法,用于确定在一个测试套执行后,软件的那些部分被执行到了,那些部分没有被执行到 |
||
code inspection(检查,视察)n. |
代码检视 |
一个正式的同行评审手段,在该评审中,作者的同行根据检查表对程序的逻辑进行提问,并检查其与编码规范的一致性 |
||
code walkthrough |
代码走读 |
一个非正式的同行评审手段,在该评审中,代码被使用一些简单的测试用例进行人工执行,程序变量的状态被手工分析,以分析程序的逻辑和假设 |
||
code-based testing |
基于代码的测试 |
根据从实现中引出的目标设计测试用例 |
||
coding standards(标准,规范) |
编程规范 |
一些编程方面需要遵循的标准,包括命名方式、排版格式等内容。 |
||
Compatibility Testing |
兼容性测试 |
测试软件是否和系统的其它与之交互的元素之间兼容,如:浏览器、操作系统、硬件等 |
||
stress |
压力 |
stress test 压力测试 |
||
load |
负荷 |
load test 负荷测试 |
||
Open system testing architecture |
开放系统测试架构 |
OpenSTA |
||
QA |
质量保证 |
Quality Assurance |
||
SQA |
软件质量保正 |
software quality Assurance |
||
software testing |
软件测试 |
|
||
Implementation Plan |
实施计划 |
|||
Software Requirement Specifications |
软件需求说明书 |
|||
System User's Manual |
用户手册 |
|||
Preliminary Design |
概要设计 |
|||
Detail Design |
详细设计 |
|||
Correctness |
正确性 |
|||
Reliability |
可靠性 |
|||
Efficiency |
效率 |
|||
Integrity |
完整性 |
|||
complete path texting |
完全路径测试 |
|||
completeness |
完整性 |
|||
complexity |
复杂性 |
|||
componet |
组件 |
|||
Componet testing |
组件测试 |
|||
computer system security |
计算机系统安全性 |
计算机软件和硬件对偶然的或故意的访问、使用、修改或破坏的一种保护机制 |
||
codition |
条件 |
一个不包含布尔操作的布尔表达式 |
||
condition coverage |
条件覆盖 |
通过测试执行到的条件的百分比 |
||
condition outcome |
条件结果 |
条件为真为假的评价 |
||
configuration control |
配置控制 |
配置管理的一个方面,包括评价、协调、批准、和实现配置项的变更。 |
||
configuration management |
配置管理 |
一套技术和管理方面的原则用于确定和文档化一个配置项的功能和物理属性、空控制对这些属性的变更、记录和报告变更处理和实现的状态、以及验证与指定需求的一致性 |
||
Usability |
可用性 |
|||
Maintainability |
可维护性 |
|||
Flexibility |
灵活性 |
|||
Testability |
可测试性 |
|||
Portability |
可移植性 |
|||
Reusability |
可复用性 |
|||
conformace testing |
一致性测试 |
测试一个系统的实现是否个其基于的规格相一致的测试。 |
||
control flow |
控制流 |
程序执行中所有可能的事件顺序的一个抽象表示 |
||
control flow graph |
控制流图 |
通过一个组件的可能替换控制流路径的一个图形表示 |
||
conversion testing |
转换测试 |
用于测试已有系统的数据是否能够转换到替代系统上的一种测试 |
||
correctness |
正确性 |
软件在其规格、设计和编码中没有故障的程度。软件、文档和其他项满足需求的程度。软件、文档和其他项满足用户明显的和隐含的需求的程度 |
||
coverage |
覆盖率 |
用于确定测试所执行到的覆盖项的百分比 |
||
coverage item |
覆盖项 |
作为测试基础的一个入口或属性:如语句、分支、条件等 |
||
crash |
崩溃 |
计算机系统或组件突然并完全的丧失功能 |
||
criticality |
关键性 |
需求、模块、错误、故障、失效或其他项对一个系统的操作或开发影响的程度 |
||
data definition |
数据定义 |
一个可执行语句,在该语句上一个变量被赋予了一个值 |
||
data definition C-use pair |
数据定义C-use使用对 |
一个数据定义个一个计算数据使用,数据使用的值是数据定义的值 |
||
data definition C-use coverage |
数据定义C-use覆盖 |
在组件中被测试执行到的数据定义C-use使用对的百分比 |
||
data dictionary |
数据字典 |
一个软件系统中使用的所有数据项名称,以及这些相关属性的集合;数据流、数据元素、文件、数据基础、和相关处理的一个集合 |
||
data flow analysis |
数据流分析 |
一个软件验证和确认过程,用于保证输入和输出数据和它们的格式是被适当定义的,并且数据流是正确的 |
||
data flow coverage |
数据流覆盖 |
测试覆盖率的度量是根据变量在代码中的使用情况 |
||
data flow diagram |
数据流图 |
把数据源、数据接受、数据存储和数据处理作为节点描述的一个图形,数据之间的逻辑体现为节点之间的边 |
||
data flow testing |
数据流测试 |
根据代码中变量的使用情况进行的测试 |
||
data integrity |
数据完整性 |
一个数据集合完全、正确和一致的程度 |
||
data validation |
数据确认 |
用于确认数据不正确、不完整、不合理的过程 |
||
dead code |
死代码 |
在程序操作过程中永远不可能被执行到的代码 |
||
debugging |
调试 |
发现和去除软件失效根源的过程 |
||
decision |
判定 |
一个程序控制点,在该控制点上,控制流有两个或多个可替换路由 |
||
decision condition |
判定条件 |
判定内的一个条件 |
||
decision coverage |
判定覆盖 |
在组件中被测试执行到的判定结果的百分比 |
||
decision outcome |
判定结果 |
一个判定的结果,决定控制流走哪条路径 |
||
decision table |
判定表 |
一个表格,用于显示条件和条件导致动作的集合 |
||
depth testing |
深度测试 |
执行一个产品的一个特性的所有细节,但不测试所有特性。比较广度测试 |
||
design-based testing |
基于设计的测试 |
根据软件的构架或详细设计引出测试用例的一种方式 |
||
desk checking |
桌面检查 |
通过手工模拟软件执行的方式进行测试的一种方式 |
||
disaster recovery |
灾难恢复 |
一个灾难的恢复和重建过程或能力 |
||
documentation testing |
文档测试 |
测试关注于文档的正确性 |
||
domain |
域 |
值被选择的一个集合 |
||
domain testing |
域测试 |
|
||
dynamic analysis |
动态分析 |
根据执行的行为评价一个系统或组件的过程 |
||
Dynamic testing |
动态测试 |
通过执行软件的手段来测试软件 |
||
End-to-End testing |
端到端测试 |
在一个模拟现实使用的场景下测试一个完整的应用环境,例如和数据库交互,使用网络通信等 |
||
Equivalence Class |
等价类 |
组件输入或输出域的一个部分,在该部分中,组件的行为从组件的规格上来看认为是相同的 |
||
Equivalence partition coverage |
等价划分覆盖 |
在组件中被测试执行到的等价类的百分比 |
||
equivalence partition testing |
等价划分测试 |
根据等价类设计测试用例的一种技术 |
||
Equivalence Partitioning |
等价划分 |
组件的一个测试用例设计技术,该技术从组件的等价类中选取典型的点进行测试 |
||
error guessing |
错误猜测 |
根据测试人员以往的经验猜测可能出现问题的地方来进行用例设计的一种技术 |
||
errot seeding |
错误播种/错误查值 |
故意插入一些已知故障到一个系统中去的过程,目的是为了根据错误检测和跟踪的效率并估计系统中遗留缺陷的数量 |
||
exception |
异常/例外 |
一个引起正常程序执行挂起的事件 |
||
executable statement |
可执行语句 |
一个语句在被编译后会转换成目标代码,当程序运行是会被执行,并且可能对程序数据产生动作。 |
||
Exhaustive Testing |
穷尽测试 |
测试覆盖软件的所有输入和条件的组合 |
||
exit point |
出口点 |
一个组件的最后一个可执行语句 |
||
expected outcome |
期望结果 |
|
||
bottleneck |
瓶颈 |
|
||
load testing |
负载测试 |
通过测试系统在资源超负荷情况下的表现,以发现设计上的错误或验证系统的负载能力 |
||
logic analysis |
逻辑分析 |
(1)评价软件设计的关键安全程式、算法和控制逻辑的方法(2)评价程序操作的顺序并且检测可能导致灾难的错误 |
||
logic-coverage testing |
逻辑覆盖测试 |
|
||
maintainability |
可维护性 |
一个软件系统或组件可以被修改的容易程度,这个修改一般是因为缺陷纠正、性能改进或特性增加引起的 |
||
maintainability testing |
可维护性测试 |
测试系统是否满足可维护性目标 |
||
modified condition /decision coverage |
修改条件/判定覆盖 |
在组件中被测试执行到的等价类的百分比 |
||
modified condition /decision testing |
修改条件/判定测试 |
根据MC/DC设计测试用例的一种技术 |
||
mutation analysis |
变体分析 |
一种确定测试用例套完整性的方法,该方法通过判断测试用例套能够区别程序与其变体之间的程度。 |
||
Negative Testing |
逆向测试/反向测试/负面测试 |
测试瞄准于使系统不能工作。 |
||
operational testing |
可操作性测试 |
在系统或组件操作的环境中评价它们的表现 |
||
output domain |
输出域 |
所有可能输出的集合 |
||
Partition testing |
分类测试 |
|
||
path |
路径 |
一个组件从入口到出口的一条可执行语句顺序 |
||
performance testing |
性能测试 |
评价一个产品或组件与性能需求是否符合的测试 |
||
Portability testing |
可移植性 |
测试瞄准于证明软件可以被移植到指定的硬件或软件平台 |
||
Positive testing |
正向测试 |
测试瞄准于显示系统能够正常工作 |
||
Race Condition |
竞争状态 |
并行问题的根源,对一个共享资源的多个访问,至少包含了一个写操作,但是没有一个机制来协调同时发生的访问 |
||
recovery testing |
恢复性测试 |
验证系统从失效中恢复能力的测试 |
||
Regression analysis and testing |
回归分析和测试 |
一个软件验证和确认任务以确定在修改后需要重复测试和分析的范围 |
||
Regression testing |
回归测试 |
在发生修改之后重新测试先前的测试以保证修改的正确性 |
||
release |
发布 |
一个批准版本的正式通知和分发 |
||
reliability |
可靠性 |
一个系统或组件在规定的条件下在指定的时间内执行其需要功能的能力 |
||
reliability assesment |
可靠性评价 |
确定一个已有系统或组件的可靠性级别的过程 |
||
requirements-based testing |
基于需求的测试 |
根据软件组件的需求导出测试用例的一种设计方法 |
||
review |
评审 |
在产品开发过程中,把产品提交给项目成员、用户、管理者或其他相关人员评价或批准的过程 |
||
risk |
风险 |
不期望效果的可能性和严重性的一个度量 |
||
risk assessment |
风险评估 |
对风险和风险影响的一个完整的评价 |
||
security testing |
安全性测试 |
验证系统是否符合安全性目标的一种测试 |
||
security |
安全性 |
|
||
serviceability testing |
可服务性测试 |
|
||
simple subpath |
简单子路径 |
控制流的一个字路径,其中没有不必要的部分被执行 |
||
simulation |
模拟 |
使用另一个系统来表示一个物理的或抽象的系统的选定行为特性 |
||
SLA |
服务级别协议(service level agreement) |
服务提供商与客户之间的一个协议,用于规定服务提供商应当提供什么服务 |
||
Smoke Testing |
冒烟测试 |
对软件主要功能进行快餐式测试,最早来自于硬件测试实践,以确定新的硬件第一次使用的时候不会着火 |
||
software development process |
软件开发过程 |
一个把用户需求转换为软件产品的开发过程 |
||
software diversity |
软件多样性 |
一种软件开发技术,其中,由不同的程序员或开发组开发的相同规格的不同程序,目的是为了检测错误、增加可靠性 |
||
software element |
软件元素 |
软件开发或维护期间产生或获得的一个可交付的或过程内的文档 |
||
software engineering |
软件工程 |
一个应用于软件开发、操作和维护的系统性的、有纪律的、可量化的方法。 |
||
software engineering environment |
软件工程环境 |
执行一个软件工程工作的硬件、软件、各固件 |
||
software life cycle |
软件生命周期 |
开始于一个软件产品的构思,结束于该产品不再被使用的这个阶段 |
||
SOP |
标准操作过程(standard operation procedures) |
书面 的操作步骤,这对保证生产和处理的控制是必须的 |
||
source code |
源代码 |
用一种适合于输入到汇编器、编译器或其他转换设备的计算机指令和数据定义 |
||
source statement |
源语句 |
|
||
spiral model |
螺旋模型 |
软件开发过程的一个模型,其中的组成活动,典型的包括需求分析、概要设计、详细设计、编码、集成和测试等活动被迭代的执行直到软件被完成 |
||
SQL (structured query language) |
结构化查询语句 |
在一个关系数据库中插叙和处理数据的一种语言 |
||
state |
状态 |
一个系统、组件或模拟可能存在其中的一个条件或模式 |
||
state diagram |
状态图 |
一个图形,描绘一个系统或组件可能假设的状态,并且显示引起或导致一个状态切换到另一个状态的事件或环境。 |
||
state transition |
状态转换 |
一个系统或组件的两个允许状态之间的切换 |
||
state transition testing |
状态转换测试 |
根据状态转换来设计测试用例的一种方法 |
||
statement |
语句 |
程序语言的一个实体,是典型的最小可执行单元 |
||
statement coverage |
语句覆盖 |
在一个组件中,通过执行一定的测试用例所能达到的语句覆盖百分比 |
||
statement testing |
语句测试 |
根据语句覆盖来设计测试用例的一种方法 |
||
static analysis |
静态分析 |
分析一个程序的执行,但是并不实际执行这个程序 |