软件测试英文术语及中文解释

附录 A

软件测试英文术语及中文解释

- A -

Acceptance Testing 验收测试

软件或硬件开发的一个测试阶段，以检验所测试的系统是否正确实现了所有的用户需求，以保证其达到可以交付使用的状态，通常是产品发布之前最后一个测试阶段。

Accessibility 可接近性

使组成软件的各部分便于选择使用或维护的程度。

Active or Open 激活状态

未被解决的缺陷的一种状态，如新报告的 Bug, 或验证后 Bug 仍然存在的状态。

Adaptability 适应性

使不同的系统约束条件和用户需求得到满足的容易程度。

Analytical Model 分析模型

用一组可解方程来表示一个过程或一个现象。

Architecture 体系结构

系统各部件之间的结构和关系。

Automated Test Case Generator 自动测试用例生成器

Audit 审核

为获得审核证据并对其进行客观的评价，以确定满足经协商的准则的程度所进行的系统的、独立的并形成文件的过程。

Audit Scope 审核范围

审核的广度和界限。

Auditor 审核员

Auditor Qualifications 审核员资格

Availability 可用性

软件在投入使用时能实现其指定的系统功能的概率，可用系统正常工作时间和总的运行时间之比计算。

- B -

Behavioral Test 行为测试

基本计算机系统、硬件或软件假定完成的用途和功能测试，根据产品特征、操作描述和用户方案进行。也被称为黑盒测试或功能测试。

Baseline 基线

在配置项目生存周期的某一特定时间内，正式指定或固定下来的配置标识文件和一组这样的文件或数据，可用作下一步开发的基础。

Black-box Test 黑盒测试

不管程序内部结构是什么样的，把系统或软件看成一个黑盒，只是根据输入 / 输出条件、边界条件和限制，从用户观点 / 数据驱动的方式，来验证产品所应该具有的功能是否实现，是否满足用户的要求。参见行为测试。

Bottom-up Integration 自底向上系统集成方法

Boundary Condition 边界条件

描述极值的测试需求。如果子系统取范围 \([0\cdots12]\) 内的数，则 0 和 12 就是边界。边界条件比内部值更容易发现程序缺陷，因为程序员常常在边界犯错误。

Bug 软件缺陷

系统或程序中隐藏的功能缺陷、错误或瑕疵，而导致软件产品在某种程度上不能满足用户的需要。

Bug Crawl 错误评审会议

集中对测试系统中每个被报告的现存错误进行逐项评审的会议或讨论。在评审过程中，可以指定错误修改日期、优先级、推迟处理不严重的错误。也被称为错误剔除 (Bug Scrub)。

Build 构件

软件产品的一个工作版本，其中包含最终产品将拥有的能力的一个规定的子集。

B/S, Browser/Server 浏览 / 服务器 (结构)

- C -

Capability 能力

组织、体系或过程实现产品并使其满足要求的本领。

Capacity Test 容量测试

预先分析出反映软件系统应用特征的某项指标的极限值，如某个 Web 站点可以支持的并发用户的访问量。

Certification 认证

证实软件系统或程序在其运行环境中能满足规定需求的过程，认证使验证和确认的过程扩充到实际的或模拟的运行环境中。

Change Control 变更控制管理

提议作一项更动并对其进行估计、同意或拒绝、调度和跟踪的过程。

CCB, Change Control Bard 变更控制委员会

控制需求变化、代码修改的一种内部组织

Characteristic 特性

区分的特征。

Close or Inactive 关闭或非激活状态

已经被解决的缺陷的一种状态，即被测试人员验证后，确认 Bug 不存在之后的状态。

Closure Period 修复周期

在最初的缺陷报告到修复确认之间的时间。修复时期是衡量开发部门对缺陷报告响应的速度。

Code Audit 代码审计

由某人或小组对源代码进行的独立的审查，以验证其是否符合软件设计文件和程序设计标准，还可能对正确性和有效性进行估计。

Code Completed 代码完成

在某个版本所有新功能和改动的代码完成时间，是软件开发周期中的一个重要里程碑。

Code Freeze 代码冻结

所有的缺陷修改之后，不允许对代码做任何非授权的改动起始时间，是另一个重要的里程碑。

Code Inspection 代码审查

Code Walk—through 代码走查

Cohesion 内聚度

单个程序模块所执行的诸任务在功能上的互相关联的程度。

Compatibility 兼容性

软件从一个计算机系统或环境移植到另一个系统或环境的容易程度。

Compatibility Testing 兼容性测试

测试在特殊的硬件 / 软件 / 操作系统 / 网络环境下的软件表现。

Compile 编译

将高级语言程序变换成与之等价的浮动的或绝对的机器代码。

Complexity 复杂性

系统或系统组成部分的复杂程度，如：接口的数量和错综程度，条件转移的数量和错综程度，嵌套的深度，数据结构的类型等。

Component 组件，部件

构成系统或程序的基本部分、具有独立功能的单元。

Component Testing 组件测试

在系统集成之前，对构成系统的各个组件进行测试的阶段，类似于模块测试或单元测试。

Confirmation Tests 确认测试

一套选定的测试，用于对报告中不能完全修复的缺陷进行测试的方法，包含对每个缺陷报告都重新执行测试过程和隔离步骤。

Configuration 配置

为确定系统或系统组成部分的特定版本而在技术文档中提出的需求和制定的产品硬件、软件的特性要求。

Configuration Management 配置管理

标识和确定系统中配置项的过程，在系统整个生存周期内控制这些项的变化，记录并报告

配置的状态和更动要求，验证配置项的完整性和正确性。

Conformity 合格（符合）

满足要求。

Congruent 一致性

对测试系统体系结构的描述，其中测试系统的所有组件彼此相关，并与测试系统的目标相一致。

Continual Improvement 持续改进

增强满足要求的能力的循环活动。

Contractually Required Audit 合同所要求的审计

Correction 纠正

为消除已发现的不合格所采取的措施。

Corrective Action 纠正措施

为消除已发现的不合格或其他不期望情况的原因所采取的措施。

Coupling 耦合度

计算机程序中模块之间相互依赖的量度。

Coverage 覆盖率

是检查对系统或子系统测试是否彻底的一种程度衡量，是测试质量的近似度量。

Criteria 准则

确定为依据的一组方针、程序或要求。

Critical Bug 严重的缺陷

指导致主要功能或特性没有实现、丧失的严重缺陷。

Customer 顾客

接受产品的组织或个人。

Customer Satisfaction 顾客满意

顾客对其要求已被满足的程度的感觉。

C/S, Client/Server 客户 / 服务器 (结构)

- D -

Data Dictionary 数据字典

软件系统中的所有数据项的名字、含义及相关特性 (如数据项长度、表示等) 的集合。

Data Structure 数据结构

数据项之间的次序安排和可访问性的一种形式表示，其中不涉及其实际存储排列方法。

Data Flow Testing 数据流测试

测试需求需要检验所有已定义的数据输入、处理、输出的一种测试类型。

Debugging 调试

开发人员确定引起缺陷的根本原因和确定可能的修复措施的过程，通过调试来修复缺陷。

Defect 缺陷

未满足与预期或规定用途有关的要求。

Delivery 交付

软件研制周期中的一个阶段，将产品提交给计划中的用户供其使用。

Dependability 可信性

关于可用性及其影响因素：可靠性、维修性和维修保障性的全部特性。

Design and Development 设计与开发

将要求转换为规定的特性或产品、过程或体系的规范的一组过程。

Design Specification 设计规格说明

描述设计要求的正式文档，对系统或系统组成部分 (如软件配置项、算法、控制逻辑、数据结构、输入输出格式和接口等) 进行设计。

Development Life Cycle 开发生存周期

Deviation Permit 偏离许可

产品实现前，偏离原规定要求的许可。

Distributed Testing 分布式测试

在多个位置、涉及多个开发小组或两者兼备的情况下进行的测试。

Document 文件

信息及其承载媒体。

Driver 驱动模块

对底层或子层模块进行集成测试中，所编制的调用这些模块的程序。

- E -

Effectiveness 有效性

完成策划的活动并达到策划的结果的程度。

Efficiency 效率

得到的结果与所使用的资源之间的关系。

Encapsulation 封装

将系统功能隔离在一个模块中，并为该模块提供精确的规格说明的面向对象技术。

Entry Criteria 进入标准

一套决策的指导方针或数据指标，用于决定项目是否准备好进入特定的测试阶段。

Error Seeding 错误播种

一种有效性的理论方法。在测试时向被测试系统中加入已知的错误，然后检查这些已知错误被发现的比例，通过这个比例来衡量被测试系统中残留的错误并测量测试系统自身。一般不采用这个方法，人们普遍怀疑该方法的精确性。

Error, Faults and Failures 错误、缺陷与失效

根据 IEEE 83, 错误是人为的失误，产生一个或多个缺陷，这些缺陷被嵌入在程序的文本中。执行有缺陷的代码时，会产生零个或多个失效。

Escalate 向上呈交

将问题递交到更高级管理层寻求解决方案。

Evaluation 评价，评估

决定某产品、项目、活动或服务是否符合它规定的准则的过程。

Exit Criteria 退出标准

与 Entry Criteria 相反，这里是决定项目是否可以退出或结束当前的测试阶段的标准或指标。

Experience of Quality 质量体验

客户和用户对于系统是否实现他们的期望和需求的看法。

Exploratory Testing 探索性测试

并行地进行测试的设计、开发和执行，通常伴随着学习被测试的系统和不重要的测试文档。

- F -

Failure 失效

系统或系统部件丧失了 (在规定的限度内) 执行所要求功能的能力。

Fatal Bug 致命的缺陷

造成系统或程序崩溃 (Crash)、死机、悬挂、或数据丢失、或主要功能完全丧失等缺陷。

Fault Injection 错误注入

参见 Error Seeding 错误播种。

Fault of Omission 遗漏缺陷

通过补充文本可以改正的缺陷。

Feasible Coverage 可行覆盖率

已满足覆盖率条件百分比的一种度量，除去不可能或太难满足的部分。

Feature 产品特性

系统中满足用户需求的某种功能、表现和特征。

Fidelity 逼真度

对测试系统，是指准确构造客户的硬件、软件和网络环境的模型和模拟客户行为的程度。

Field-reported Bug 现场报告缺陷

通常由客户或销售人员报告在发布、部署或交付产品时的缺陷。

First Customer Ship 首位客户送货

对于大宗市场系统，指它的系统完成彻底的测试、形成产品、发送给首位付款客户的阶段。也被称为发布或通用有效性。

Fixed or Resolved 已修正状态

缺陷被开发人员处理过并通过开发人员单元测试的状态，还需要测试人员的验证。

Flexibility 灵活性

测试组件能处理被测试系统的细小改变，而不报告不存在的或确实存在的缺陷的程度。

FMEA 失效模型和效果分析

Failure Mode and Effects Analysis 的缩写，一种用于识别和定义潜在质量风险的方法，该方法按风险的优先级别排序，并对每一个风险取相应措施预防和 / 或发现相关问题。

Functional Specification 产品功能规格说明 (书)

产品或系统要实现的、满足用户需求的各种功能、特性和界面的描述 (文档)。

Functional Tests 功能测试

参见行为测试或黑盒测试，但它还意味着集中于功能正确性方面的测试。功能测试必须和其他测试方法一起处理潜在的重要的质量风险，比如性能、负荷、容量等。

Functionality 功能性

软件所实现的功能达到它的设计规范和满足用户需求的程度。

- G -

GA 通用有效性

General Availability 的简称，参见首位客户送货。

Grade 等级

对功能用处相同但质量要求不同的产品、过程或体系所做的分类或分级。

Granularity 粒度

聚集的精确度或粗糙度。高粒度测试让测试者检查低级细节，如结构测试。而行为测试不是低粒度测试，它给测试者提供整体系统行为的信息，而不是细节。

- I -

Ideal Fault Condition 理想缺陷条件

在测试理论中，指可达性、必要性和传播性条件。

Identifier 标识符

用以命名、指示或定位的符号，标识符可以和数据结构、数据项或程序位置相关联。

Information 信息

有意义的资料。

Infrastructure 基础设施

组织运行所必需的一组设施、设备和服务。

Implementation Requirement 实现需求

对软件设计的实现产生影响或限制的任何需求。例如，设计描述、软件开发标准、程序设计语言需求、软件质量保证标准等。

Input 输入

一般术语，表示子系统所操作的任何数据，包括文件输入、函数参数传入值、全局变量值等。

Inspection 检验

通过观察和判断，必要时结合测量、试验所进行的符合性评价。

Integration Testing 集成测试

在单元测试的基础上，按照设计要求，将所有单元 (模块 / 组件) 组装成为系统而进行的测试，通过测试，可以发现单元之间关系和接口中的错误。

Interoperability 互操作性

两个或多个系统交换信息并相互使用已交换的信息的能力、或可互相操作的能力。

Isolation 隔离

对缺陷进行分析而找出导致问题的根本原因。如通过重复那些用于再现缺陷的步骤，并改变系统配置、权限、负载等环境因素或条件，从而识别影响缺陷的因素。

-L-

Log File 记录文件

包含测试运行时的实际输出的文件。

- M -

Maintainable 可维护性

由于用户新的需求、功能增强或所发现的问题，对已开始使用的系统修改的难易程度。

Major Bug 一般的缺陷

这样的软件缺陷虽然不影响系统的基本使用，但没有很好地实现功能，没有达到预期效果。如次要功能丧失、提示信息不太准确、用户界面不友好、操作时间长等问题。

Management 管理

指导和控制组织的相互协调的活动。

Management System 管理体系

建立方针和目标并实现这些目标的体系。

Measurement Control System 测量控制体系

为完成计量确认并持续控制测量过程所必需的一组相互关联或相互作用的要素。

Measurement Process 测量过程

确定量值的一组操作。

Metrological Characteristic 计量特性

可影响测量结果的区分的特征。

Metrological Confirmation 计量确认

为了确保测量设备处在符合其预期使用要求的状态所要求的一组操作。

Metrological Function 计量职能

组织建立并实施测量控制体系的职责。

Milestone 里程碑

项目中完成阶段性工作的标志，即将一个过程性的任务用一个结论性的标志来描述任务结束的、明确的起止点。

Minor Bug 微小的缺陷

对功能几乎没有影响，产品及属性仍可使用。如有个错别字、文字排列不对齐等一些小问题。

Modified Top-down Integration 改进的自顶向下集成

集成测试中的一种混合策略。

Modularity 模块性

软件由若干部分组成的离散程度，即表明改变一个组成部分时对另外的组成部分的影响程度。

Module 模块

是离散的程序单元，且对于编译、与其他单元相结合是可识别的。

MTBF 失效平均时间

Mean Time Between Failure 的缩写，其数据预测系统的现场错误率，暗示了稳定性、可靠性。

MTTR 平均维修时间

Mean Time to Repair 的缩写。这个数字表明了系统的可恢复性。

- N -

Necessity Condition 必要性条件

在测试理论中，采用导致程序出现错误内部状态的值来检验缺陷的需求。

Nest 嵌套

把某一类的一个结构或多个结构合并到同一类结构中去，如程序中的循环嵌套，形成自我迭代。

-0-

Objective Evidence 客观证据

支持事物存在或其真实性的资料。

Organization 组织

职责、权限和相互关系得到安排的一组人员及设施。

Organizational Structure 组织结构

人员的职责、权限和相互关系的安排。

Orthogonal 正交

两个或多个变量之间的关系描述，或集合中元素值互不影响的一组集合元素之间关系的描述。

Output 输出

作为子系统执行结果的任何内容，包括文件输出、函数返回值等。

- P -

Peer Review 同级评审

在一个项目组内，组员之间相互阅读和审查对方的代码、缺陷报告、计划书等。

Performance 性能

在指定条件下，用软件实现某种功能所需的计算机资源 (包括时间) 的有效程度。

Performance Test 性能测试

确定系统运行时的性能表现，如得到运行速度、响应时间、占有系统资源等方面的系统数据。

Pilot Testing 引导测试

验证系统在真实硬件和客户基础上处理典型操作的能力。其测试通过后可以开始系统的部署。

Preventive Action 预防措施

为消除潜在不合格或其他潜在不期望情况的原因所采取的措施。

Priority 优先权

缺陷要被修复的重要性，从用户的角度看，是指缺陷对系统的可行性和可接受性的影响。

Procedure 程序，过程

为进行某项活动或过程所规定的途径。

Program Specification 概要说明

Process 过程

将输入转化为输出的相互关联或相互作用的、有目标的、有组织的、有次序的一系列活动。

Product 产品

过程的结果。

Product Testing 产品测试

参见集成测试。

Project 项目

由一组有起止时间的、相互协调的受控活动所组成的特定过程，该过程要达到符合规定要求的目标，包括时间、成本和资源的约束条件。

- Q -

Qualification Process 鉴定过程

证实满足规定要求的能力的过程。

Quality 质量

是产品或服务满足固有特性 (明示或暗示的) 要求的程度或其能力的特性和特征的集合。

Quality Assurance 质量保证

通过对软件产品和活动有计划地进行评审和审计来确保任何经过认可的标准和步骤都被遵循、并且保证问题被及时发现和处理。质量管理的一部分，致力于提供能满足质量要求的信任。

Quality Characteristic 质量特性

有关要求的产品、过程或体系的固有特性。

Quality Control 质量控制

质量管理的一部分，致力于满足质量要求。

Quality Improvement 质量改进

质量管理的一部分，致力于增强满足质量要求的能力。

Quality Management 质量管理

指导和控制组织的关于质量的相互协调的活动。

Quality Management System 质量管理体系

指导和控制组织的关于质量的管理体系。

Quality Manual 质量手册

规定组织质量管理体系的文件。

Quality Metric 质量度量

对软件所具有的，影响其质量的给定属性所进行的定量测量。

Quality Objective 质量目标

关于质量的所追求的目的。

Quality Plan 质量计划

对特定的项目、产品、过程或合同，规定由谁及何时应用程序和相关资源的文件。

Quality Planning 质量策划

质量管理的一部分，致力于制定质量目标并规定必要作业过程和相关资源以实现质量目标。

Quality Policy 质量方针

由组织的最高管理者正式发布的该组织总的质量意图和质量方向。

Quality Risk Management 质量风险管理

以预防或发现并消除风险为目的，识别、优化、管理被测试系统质量风险的过程。

- R -

Railroading 铁路运输方式

一种在新的测试循环开始时，不是重新开始测试，而是按测试包的顺序、或从所处位置继续执行测试的技术。这种技术的目标是当范围不是很明确的时候，测试范围达到可接受程度，并使得回归测试间距达到最小。

Record 记录

阐明所取得的结果或提供所完成活动的证据的文件。

Recovery Testing 恢复测试

对系统崩溃或失效之后的系统和数据重新恢复的能力和效率。

Regression 回归

作为被测试系统改变的结果，当系统新的修改版本 \(S_{n}+1\) 包含从 \(S_{1}\) 次修改到 \(S_{n}\) 次修改都没有描述的缺陷时所出现的问题。

Regression Tests 回归测试

用于验证改变了的系统或其组件仍然保持应有的特性，即保证不会因为处理存在的缺陷、添加产品新功能等进行的程序修改而导致原有正常功能的失效。

Regression Test Gap 回归测试间距

对于被测试系统任何给定的改变或修改，整个测试系统提供的测试范围和实际重新执行的部分测试系统提供的测试范围之间的差别。

Release 产品发布

对进入一个过程的下一阶段的许可。

Reliability 可靠性

质量的一种特性，在规定的时间和条件下，软件所能维持其性能水平的程度。

Reporting Logs 报告日志

测试工具产生的原始测试输出，如通过 SoftICE 所捕获的程序运行状态的文本文件。

Requirement 要求

明示的、通常隐含的或必须履行的需求或期望。

Reusability 可重用性，复用率

一个模块可在多种应用中加以利用的程度。

Review 评审

为确定主题事项达到规定目标的适宜性、充分性和有效性所进行的活动。

Root Cause 根本原因

缺陷发生的潜在原因，可能与观察到的缺陷表象不一致。

- S -

Scalability 可扩展性

软件系统可以在不同规模、不同档次的硬件平台上运行的能力。

Script 脚本

自动测试工具的程序指令，程序指令由解释性语言 (被称为脚本语言) 写成。

Security 安全性，保密性

对软件系统的保护能力，以防止其受到意外的或蓄意的存取、使用、修改、毁坏或泄密。

Security Testing 安全测试

测试系统在应付非授权的内部 / 外部访问、故意的损坏时的防护情况。

Service Manageability 可维护性

在一个运行软件中，当环境改变或软件发生缺陷时，进行相应修改所做努力的程度。

Severity 严重性

缺陷对被测试系统的影响，在终端客户条件下发生的可能性或失败妨碍系统使用的程度。

SDLC, Software Development Life Cycle 软件开发生命周期

从需求分析、设计、编程、测试到维护的整个软件开发过程。

Software Development Process 软件开发过程

Software Engineering 软件工程

为解决软件开发中各种问题所采用的系统方法和工程技术、工具等的一门学科。

Specification 规范

阐明要求的文件。

Stability 稳定性

在有干扰或破坏事件影响下仍能保持不变的能力或返回到原始状态的能力。

Standard Combining Rules 标准组合规则

组合测试需求来构成测试规格说明的方式。每个测试需求都至少使用一次，每个测试规格说明要满足尽可能多的合理的测试需求。

Stress Testing 压力测试

测试是用来检查系统在大负荷条件下系统运行的情况。

Structured Programming 结构化程序设计

一种定义良好的软件开发技术，采用自顶向下设计和实现方法，并具有结构化程序的控制构造。

Structural Test 结构测试

基于代码的或程序结构内部的测试技术和方法，又称为白盒测试。

Stub 桩模块

对顶层或上层模块进行集成测试中，所编制的替代下层模块的程序。

Supplier 供方

提供产品的组织或个人。

System Testing 系统测试

软件测试的一个阶段，将软件放在整个计算机环境下，包括软硬件平台、某些支持软件、数据和人员等，在实际运行环境下进行一系列的可用性测试。

- T -

TBD 待定

To Be Determined 的简称；在测试文档中表示一项进行中的工作的有用标记。

Test automation 测试自动化

通过软件工具自动执行软件测试的方法。

Test Case 测试用例

为了特定目的 (如考察特定程序路径或验证是否符合特定的需求) 而设计的测试数据及与之相关的测试规程的一个特定的集合，或称为有效地发现软件缺陷的最小测试执行单元。在 IEEE 829 中，被称为测试规格说明和测试过程。

Test Case Library 测试用例库

独立的、可重用的测试用例集合。

Test Casually 随机测试

模拟客户操作的随意性，进行大量的、自动化的随机测试，来发现今后用户可能会碰到的问题。

Test Coverage 测试覆盖

测试系统覆盖被测试系统的程度，这种度量可以表示为结构化元素 (如代码行) 或功能点被覆盖的百分比。

Test Environment 测试环境

进行测试的环境，包括测试平台、测试基础设施、测试实验室和其他设施。

Test Escape 测试遗漏

在测试过程中任何应该被捕捉却没有被捕捉到的现场报告缺陷。

Test Phase 测试阶段

指定特殊的质量风险集合并由一个或更多测试通过组成的测试期。

Test Platform 测试平台

被测试系统的任何硬件或软件支持环境，不是测试对象。

Test Specification 测试规格说明

测试规格说明是用来测试子系统的一个特定输入集。测试规格说明满足一个或多个测试需求。例如，单个测试规格说明 \(A = -1\) 和 \(B = 0\) 可以满足 \(A < B\) 和 \(A < 0\) 两个测试需求。测试规格说明还包含根据这些值执行子系统后，预期应得到结果的精确描述。

Test Suite 测试包，测试套件

一组测试用例的集合、执行框架，是组织测试用例的方法，通过测试用例组合可以创造新的测试条件或满足某个特定的测试目标。

Test System 测试系统

集成的和可维护项的集合，用于在被测试的软件或硬件中发现、再生产、隔离、描述和管理缺陷。这些项由测试环境、测试过程和测试组件组成。

Test to Fail 基于失效的测试

以尽可能多地发现系统功能失效、问题为目的，在设计、开发和执行测试时所涉及的想法。这个态度代表了测试的正确思维方法。

Test to Pass 基于通过的测试

以证明符合需求和操作的正确性为目的，在设计、开发和执行测试时所涉及的想法。主要

用于验收测试。

Test Tool 测试工具

应用于测试用例执行、安装或撤销测试环境、创造测试条件或者度量测试结果的过程中的软件系统或程序。

Testability 可测试性

软件的一种性质，表明既便于测试准则的建立又便于就这些准则对软件进行评价的程度。

Tolerance Test 容错测试

对系统在各种异常条件下提供继续操作的能力的测试。

Traceability 可追溯性

追溯所考虑对象的历史、应用情况或所处场所的能力。

- U -

Unit Testing 单元测试

指一段代码、一个函数或子程序、模块或组件的基本测试，一般由开发者执行，采用白盒测试方法，可从程序的内部结构出发设计测试用例。

Usability 可用性

软件在用户学习、操作和理解等方面所做努力的程度，如安装性、使用性、界面友好性等，并能否适用于不同特点的用户，包括对残疾人、有缺陷的人能提供产品使用的有效途径或手段。

- V -

Validation 确认

通过提供客观证据对特定的预期使用或应用要求已得到满足的认定，要能保证所生产的软件可追溯到用户需求的一系列活动。

Verification 验证

即检验软件是否已正确地实现了产品规格书所定义的系统功能和特性。验证过程提供证据表明软件相关产品与所有生命周期活动的要求（如正确性、完整性、一致性、准确性等）相一致。

Version 版本

某一配置项的一个可标识的实例。

- W -

White-box Tests 白盒测试

已知产品的内部工作过程 (如计算机程序的结构和语句), 检验程序中的变量状态、语句、路径、条件、逻辑结构等是否符合设计规格要求、或达到预定要求的结果。参见结构测试。

Walk-through 走查

评审的一种方式，指由某个设计 / 开发者通读已书写的设计或编码，其他成员负责提出问题并对有关技术、风格、可能的错误、是否违背开发标准的地方等进行评论。