软件测试相关专业术语

　　●Software DevelopmentLifeCycle（软件生命周期）:SDLC是软件的产生直到报废的生命周期，周期内有问题定义，可行性分析，总体描述，系统设计，编码，调试和测试，验收与运行，维护升级到废弃等阶段，这种按时间分程的思想方法是软件工程中的一种思想原则，即按部就班，逐步推进，每个阶段都要有定义，工作，审查，形成文档以供交流或备查，以提高软件的质量。但随着新的面向对象的设计方法和技术的成熟，软件生命周期设计方法的指导意义正在逐步减少。

　　●Software Quality Assurance（软件质量保证）:SQA介入于整个软件开发过程——监督和改进过程，确认达成的标准和过程被正确的遵循，保证问题被发现和解决。它以预防为主。

　　●Software Testing（软件测试）: 软件测试是在一定控制的条件下，围绕一个系统或应用的操作并评价其结果（一个最简单的例子：如果用户使用硬件A，在应用接口B上做了操作C，那么结果D应 当出现），控制的条件应当包括正常和异常的条件。测试企图使事情变得很糟糕，从而来检测出一些应当发生而没有发生，或者不应当发生而发生的事情。测试以检 测为主。

　　●Black Box Testing（黑盒测试）: 又称功能测试或 数据驱动测试。它是通过测试来检测每个功能是否都能正常使用。在测试中，把程序看作一个不能打开的黑盒子，在完全不考虑程序内部和内部特性的情况下，在程 序接口进行测试，它只检查程序功能是否按照需求规格说明书的规定正常使用，程序是否能适当地接收输入数据而产生正确的输出信息。黑盒测试着眼于程序外部结 构，不考虑内部逻辑结构，主要针对软件界面和软件功能进行测试。（ISTQB/CSTQB）不考虑组件和系统内部结构的功能或非功能测试。

　　●White Box Testing（白盒测试）: 又称结构测试或逻辑驱动测试。它是按照程序内部的结构测试程序，通过测试来检测产品内部动作是否按照设计规格说明书的规定正常进行，检验程序中的每条通路 是否都能按预定要求正确工作。这一方法是把测试对象看作一个打开的盒子，测试人员依据程序内部逻辑结构相关信息，设计或选择测试用例，对程序所有逻辑路径 进行测试，通过在不同点检查程序的状态，确定实际的状态是否与预期的状态一致。（ISTQB/CSTQB）通过分析组件/系统内部结构进行的测试。

　 　●Functional Test（功能测试）: 是一种黑盒测试，同应用程序的功能需求紧密相关，对各功能进行验证。这类测试应当由测试人员来完成。这并不意味着开发人员在发布版本之前就不需要检查他们 的代码。（ISTQB/CSTQB）通过对组件/系统功能规格说明的分析而进行的测试。

　　●Performance Test（性能测试）: 该术语通常同负载测试和压力测试是可交换的。理想的性能测试是定义在需求文档或QA测试计划中的。性能测试是通过自动化工具模拟多种正常，峰值以及异常负载条件来对系统的各项性能指标进行测试。负载测试和压力测试都属于性能测试，两者可以结合进行。

　 　　　◆Load Testing（负载测试）:通过测试系统在资源超负荷情况下的表现，以发现设计上的错误或验证系统的负载能力，在这种测试中，将使测试对象承担不同的工 作量，以评测和评估测试对象在不同工作量条件下的性能行为，以及持续正常运行的能力。负载测试的目标是确定并确保系统在超出最大预期工作量的情况下仍能正 常运行。此外，负载测试还要评估性能特性，当负载逐渐增加时，系统各项性能指标的变化情况，例如，响应时间，事务处理速度和其他与时间相关的方面。

　　　　◆Stress Testing（压力测试）:压力测试是通过确定一个系统的瓶颈或者不能接收的性能点，来获得系统能提供的最大服务级别的测试。通俗地讲，压力测试是为了发现在什么条件下您的应用程序的性能会变得不可接受。

　　●Unit Testing（单元测试）: 单元测试是在软件开发过程中要进行的最低级别的活动，在单元测试活动中，软件的独立单元将在与程序的其他部分相隔离的情况下进行测试。单元测试不仅仅是作 为无错编码一种辅助手段在一次性的开发过程中使用，单元测试必须是可重复的，无论是在软件修复，或是移植到新的运行环境的过程中。因此，所有的测试都必须 在整个软件系统的生命周期中进行维护。该测试一般由开发者完成而不是由测试人员完成。该测试的容易程度同代码设计的好坏直接相关。

　　　　◆Code Review（代码走读）:

　　　　◆Static Analysis（静态分析）:对软件的源代码进行研读，查找错误或收集一些度量数据，并不需要对代码进行编译和执行。

　　　　◆Dynamic Analysis（动态分析）:通过观察软件运行时的动作，来提供执行跟踪，时间分析，以及测试覆盖度方面的信息。

　 　●Integration Testing（集成测试）: 又称组装测试或联合测试。在单元测试的基础上，将所有模块按照设计要求（如根据结构图）组装成为子系统或系统，进行集成测试。实践表明，一些模块虽然能够 单独地工作，但并不能保证连接起来也能正常的工作。程序在某些局部反映不出来的问题，在全局上很可能暴露出来，影响功能的实现。 这类型测试典型的是与客户/服务器和分布式系统相关。

　　　　◆（非增量式集成测试）:有些设计人员习惯于把所有模块按设计要求一次性全部 组装起来，然后进行整体测试。这种方法容易出现混乱。因为测试时可能发现一大堆错误，为每个错误定位和纠正非常困难，并且在改正一个错误的同时又可能引入 新的错误，新旧错误混杂，更难断定出错的原因和位置。

　　　　◆（增量式集成测试）:程序一段一段地扩展，测试范围一步一步地增大，错误易于定位和纠正，界面的测试亦可做到完全彻底。

　　●System Testing（系统测试）:

　 　●Acceptance Testing（验收测试）:系统开发生命周期方法论的一个阶段，这时相关的用户和/或独立测试人员根据测试计划和结果对系统进行测试和接收。它让系统用 户决定是否接收系统。它是一项确定产品是否能够满足合同或用户所规定需求的测试。这是管理性和防御性控制。

　　　　◆（正式验收测试）:正 式验收测试是一项管理严格的过程，它通常是系统测试的延续。计划和设计这些测试的周密和详细程度不亚于系统测试。选择的测试用例应该是系统测试中所执行测 试用例的子集。不要偏离所选择的测试用例方向，这一点很重要。在很多组织中，正式验收测试是完全自动执行的。

　　　　◆（非正式验收测 试）/Alpha Testing（α测试）: 由一个用户在开发环境下进行的测试，也可以是公司内部的用户在模拟实际操作环境下进行的测试。目的是评价软件产品的FLURPS（即功能，局域化，可使用 性，可靠性，性能和支持）。尤其注重产品的界面和特色。α测试可以从软件产品编码结束之时开始，或在模块（子系统）测试完成之后开始，也可以在确认测试过 程中产品达到一定的稳定和可靠程度之后再开始。它是一种受控测试。α测试不能由程序人员或测试人员完成。

　　　　◆Beta Testing（β测试）:软件开发公司组织各方面的典型用户在日常工作中实际使用β版本，并要求用户报告异常情况，提出批评意见，然后软件开发公司再对 β版本进行改错和完善。β测试也是黑盒测试。黑盒测试也称功能测试，它是通过测试来检测每个功能是否都能正常使用。它是一种不受控测试。β测试不能由程序 人员或测试人员完成。开发者通常不在现场。

　　●Regression Testing（回归测试）:在软件或环境被修改后进行的测试。理论上，对软件的任何新版本，都需要进行回归测试，验证以前发现和修改的错误是否在新软件 版本上再现。可能很难确定我们需要进行多少次的再测试，尤其接近到开发过程的末期。因此，通过选择正确的回归测试策略来改进回归测试的效率和有效性是非常 有意义的。自动测试工具可能会油很大的帮助。

　　●Pilot Testing（引导测试）:软件开发中，验证系统在真实硬件和客户基础上处理典型操作的能力。在软件外包测试中，引导测试通常是客户检查软件测试公司测 试能力的一种形式，只有通过了客户特定的引导测试，软件测试公司才能接受客户真实软件项目的软件测试。

　　●End to End Testing（端到端测试）: 同系统测试类似，包括模拟现实世界对一个完整的应用环境进行测试。例如同数据库进行交互，使用网络通信，或者其他的软件，硬件和系统进行交互。

　　●Rational Testing（理智测试）:这是一种典型的原始测试，其目的是要确定一个新的软件版本在一些主要的测试努力下表现得足够好并且可以接受。例如：如果一个 新软件每五分钟当机一次，使系统执行速度极其缓慢，或者破坏系统数据，那么该软件就处于不够“理智”状态，必须保证在当前状态下进行进一步测试。

　　●Smoke Testing（冒烟测试）:冒烟测试的对象是每一个新编译的需要正式测试的版本，目的是确认软件基本功能正常，可以进行后续的正式测试工作。冒烟测试的执行者是版本编译人员。参考“Sanity Testing（健全测试）”。

　　●Sanity Testing（健全测试）:软件主要功能成份的简单测试以确认它是否能进行基本的测试。

　　●（恢复测试）:

　　●（安全性测试）:

　　●Compatibility Testing（兼容性测试）: 又称Configuration Testing（配置测试）或Portability Testing（可移植性测试）。

　　　　◆测试软件是否和系统中其它与之交互的元素之间兼容，如：浏览器，操作系统，硬件等。验证测试对象在不同软件和硬件配置中的运行情况。

　　　　◆测试软件软件软件是否可以被成功移植到指定的硬件或软件平台上。

　　●（安装和反安装测试）:

　　●Automated Testing（自动化测试）: 一般是指软件测试的自动化，把以人为驱动的测试行为转化为机器执行的一种过程。为了节省人力，时间或硬件资源，提高测试效率，便引入了自动化测试。使用自 动化测试工具来进行测试，这类测试一般不需要人干预，通常在GUI，性能等测试中用得比较多。

　　●Testing Plan（测试计划）:描述了要进行的测试活动的范围，方法，资源和进度的文档。它确定测试项，被测特性，测试任务，谁执行任务，各种可能的风险。测试计划可以有效预防计划的风险，保障计划的顺利实施。

　　●Testing Environment（测试环境）:进行测试的环境，包括测试平台，测试基础设施，测试实验室和其他设施。

　　●Testing Script（测试脚本）:一般指的是一个特定测试的一系列指令，这些指令可以被自动化测试工具执行。为了提高测试脚本的可维护性和可复用性，必须在执行 测试脚本之前对它们进行构建。测试脚本可以被创建（记录）或使用测试自动化工具自动生成，或用编程语言来完成，也可综合前三种方法来完成。

　　●Test Case（测试用例）:是为了某个特殊目标而编制的一组测试输入，执行条件以及与其结果，以便测试某个程序路径或核实是否满足某个特定需求。比较通常的说法是：指对一项特定的软件产品/系统进行测试任务描述。

　　●Testing Procedure（测试过程）:指设置，执行给定测试用例并对测试结果进行评估的一系列详细步骤。

　　●Bug（错误/缺陷）:又称Defect（缺陷）。（ISTQB/CSTQB）可能会导致软件组件或系统无法执行其定义的功能的瑕疵，例如：错误的语句或变量定义。如果在组件或系统运行中遇到缺陷，可能会导致运行的失败。

　　　　◆The software doesn't do something that the product specification says it should do.

　　　　◆The software does something that the product specification says it shouldn't do.

　　　　◆The software does something that the product specification doesn't mention.

　　　　◆The software doesn't do something that the product specification doesn't mention but should.

　　　　◆The software is difficult to understand, hard to use, slow, orin the software tester's eyes will be viewed by the end user as just plain not right.

　　●Bug Tracking System（错误跟踪系统）:BTS又称“Defect Tracking System，DTS”。管理软件测试缺陷的专用数据库系统，可以高效率地完成软件缺陷的报告，验证，修改，查询，统计，存储等任务。尤其适用于大型多语 言软件的测试管理。

　　●Screen Shot（抓屏/截图）:软件测试中，将软件界面中的错误（窗口/菜单/对话框等）的全部或一部分，使用专用工具存储成图像文件，以便于后续处理。

　　●Debug（调试）:开发人员确定引起错误的根本原因和确定可能的修复措施的过程。一般发生在子系统或单元模块编码完成时，或者根据测试错误报告指出错误以后，开发人员需要执行调试过程来解决已存在的错误。

　　●Build（工作版本）:

　　　　◆Build版在软件发布上主要区分不同时期的版本，它是编译时的版本标记，一般序号都是递增的。可用于辨别软件版本。版本号里面的Build说明这个版本是第几次编译结果，它后面一般跟数字或日期。

　　　　◆软件开发过程中用于内部测试的功能和性能等不完善的软件版本。工作版本既可以是系统的可操作版本，也可以是展示要在最终产品中提供的部分功能的部分系统。

　　●Exception（异常/例外）:一个引起正常程序执行挂起的事件。

　　●Crash（崩溃）:计算机系统或组件突然并完全的丧失功能，例如软件或系统突然退出或没有任何反应（死机）。

　　●Structured Query Language（结构化查询语句）:SQL是在一个关系数据库中查询和处理数据的一种语言。