验收测试的名词解释_测试名词解释

V模型体现的是测试设计层面与测试执行层面的概念。文章基于笔者的理解展开对测试执行分层的探讨。然而在实际项目运行中发现真正实施这一策略的案例较为少见其原因种类繁多暂且不论。

1. UT

在LLD划分下确定的程序单元或模块被视为单元测试的对象，并且这也是在单元测试用例设计过程中可作为独立考察的核心部分。此类测试对象通常由单一函数、类或其他可独立运行的基本功能组件构成。而具体的测控方案则需通过建立相应的测控关系来完成。

UT的主要目标在于通过运行特定功能来检验模块代码是否严格遵守LLD文档的要求，并确保每个功能块（Function）的输入输出行为与其在详细设计文档中预设的一致性。其中的功能是产品开发过程中最为基础的单元，在此之后则是构建模块（Module）。从测试的角度而言，在完成这些单元测试后应确保其稳定性和可靠性。接下来阶段的产品测试工作则将聚焦于各功能块之间的协同配合能力是否能够满足系统资源分配的需求计划，并且无需过分关注单个功能块本身的输入输出行为表现。

单元测试比较适合开发人员做。

UT = unit testing 单元测试

通常被称为最小可测试单元的检查与验证过程。在元组测试领域内,关于元组的具体含义需要根据具体情况来确定:例如,C语言中的元组一般指的是函数,而Java环境中则一般指的是类;在图形界面软件领域,则可能对应于某个窗口或菜单选项等不同情况

2. IT

集成测试是指将多个经过单元验证并通过功能检测确认的有效组件进行整合并执行功能性检查的过程。遵循HLD原则进行集成测试能够有效发现系统设计中的缺陷并确保各子系统之间的协调性与兼容性。该过程的主要关注点在于识别接口、依赖关系中出现的问题以及未达到预期功能的地方，并通过系统的整体运行来验证各组成部分之间的相互影响与协作效果。集成测试的对象是多个单元目标组成的系统架构并确保至少包含两个以上的独立功能模块以形成完整的功能闭环。

IT的目标在于基于模块的设计进行分解，并从经过验证的功能开始层层向上整合以形成一个可运行的模块。

IT可以由开发人员做，也可以由测试人员做。

很明显, UT充当了每个单元的具体测试角色, 而IT则充当了各单元间接口的测试工具, 我们可以说 UT/IT可被视为"单元级别"测试的一种形式。

IT = integration testing 集成测试

集成测试亦称组装测试或联合测试。它通常被称为基于单元测试的基础上整合所有模块形成子系统或整体系统进而开展集成性检验工作

3. ST

基于CMM标准定义的系统测试是对由某软件项目组负责开发的整体系统的全面评估过程；它通过模拟预定义的行为模式来验证系统的功能；主要依赖于黑盒测试策略；无需深入关注程序内部的具体实现细节；以确认输入输出数据是否满足规格说明书中对需求的要求；而ST关注的是需求规格说明书中的内容；因此可将此称为MST（Module System Testing）；此外；根据MST的结果；每个模块在经过MST验证后被认为是可靠的

ST = system testing 系统测试

即通过整合已确认的软硬件设备以及网络等相关设施，
完成一系列组装型态及验证性测试任务。
该系统的功能验证工作主要针对整体产品体系展开，
其主要目标在于确保该系统能否满足既定的需求规格要求，
并能有效识别现有配置与既定需求标准之间的不一致或冲突之处。
进而提出更为优化完善的技术解决方案。
在发现潜在故障时需通过调试手段确定具体故障原因及其发生位置。
基于仅凭产品功能说明书来进行的功能验证工作属于黑盒型功能检测方法。
被检验的对象不仅涵盖了核心软件本身，
还包括相关硬件设备以及外围设备和一些附加的数据信息，
并能全面评估支持架构的整体兼容性和互操作性状况。

4. BBIT

BBIT主要负责对各系统模块之间进行接口测试，在实际应用中有时会与联调混淆使用。然而其核心目的也有所不同，在实际应用中具体而言，在实际应用中它旨在根据系统设计对系统的分解从已通过验证的模块开始逐步集成最终得到一个可运行的整体系统。相比之下在实际应用中联调一般涉及软件硬件或者不同产品间的配合测试而MST和BBIT则属于"模块级"的两种不同类型的测试其中MST主要用于评估单个系统的自测能力另一个则负责检验各系统模块之间能否良好配合工作。

以上UT/IT/MST/BBIT项目通常由开发团队负责实现,目前系统已进入试运行阶段,测试团队现在着手实施SDV项目组

5. SDV

尽管SDV主要由测试人员负责进行系统测试,但更接近灰盒测试.因为它主要验证各子系统的配合是否满足既定的设计需求(DR),并对于内部实现细节同样重视,并检查多个模块集成后的整体效果是否符合预期的需求.

6. SIT

同样地，在检验设计需求是否得到满足方面,SIT与之不同之处在于,它将整个系统视为一个不可知的黑色对象来进行功能验证,无需关注内部的具体实现细节.在实际应用中,尽管SDV与SIT都属于系统的级别测试,但由于它们分别由不同的项目组（或子系统的团队）负责实施,每个团队仅负责对应的部分,因此通常将SDV与SIT归类为"子系统级别"的功能验证.

7. SVT

作为验收测试, 产品OR被测对象为产品包需求. 产品包需求用于描述产品的范围, 它是从不同场景下的应用角度来描述系统的. SVT的主要目的是确认(或通过验证)在所有给定的应用场景下, 该系统都能满足相应的功能要求.

在处理产品包需求时，并未对内部的具体实现方式作出区分；而SVT则会采取更为全面的方式，在设计测试方案时全面考量各个可能的应用场景，并将此类型测试工作归类为'系统级'测试。

各层次的测试工作已经完成之后，请允许我们再次审视一下这个分层测试的模型图。通过这一图表的分析不谋而合地发现以下几点：主要存在以下四个方面的特点

遵循系统架构划分的层次化体系（包含系统、子系统、模块及单元），该体系通过由上而下的方式逐步进行设计工作，并采用从下而上的方法进行相应的测试工作；这种层次化体系在各个层级或各个阶段实现了开发与测试流程的有效结合。

在整个过程中，在每一层都涉及的内容涵盖需求分析成果及该阶段的设计文档），而两者在方法论上具有相互促进的关系（即每个阶段都需要根据前一阶段的结果进行相应的调整）。因此，在制定每个阶段的具体实施策略时（即决定了该不该开展哪些方面的验证工作），若仅从测试角度出发而不考虑开发进程，则容易出现片面看待的情况（单独看待，则显得片面而不全面）。评估一个测试流程的效果时（即判断该流程是否达到了预期目标），如果忽视了其与整个项目进度之间的有机联系，则难以实现全面的质量保障目标。

除了"系统级"的SVT评估之外，在其余各层中还包括两大主要内容：一方面是对本层每一个构件的具体测试工作；另一方面则是对各个构件之间的接口进行功能验证。具体而言包括：

• 如nSDV（表示每个测试项目组中的一个特定模块）与SIT；
• nMST（表示每个开发项目组中的一个模块）与BBIT；
• nUT与IT等。

功能测试亦称黑盒测试（Black-box Testing），属于软件开发中的一个重要环节。它是一种基于用户需求规格的方法，在这种情况下将待测系统视为一个‘黑匣子’。在应用黑盒测试法进行动态分析时，则需关注系统各主要功能模块的运行状态。

接口测试

接口测试属于一种用于评估系统组件间交互的有效方法。其主要针对的是外部系统与内部各个子系统的交互点。通过这一过程可以验证数据在不同组件间的交换、传递以及控制管理流程，并且能够检验各子系统间的相互依赖关系是否协调一致。

兼容性测试

该测试旨在考察测试软件在多样化的网络环境下与不同操作系统平台及应用系统之间的兼容性及稳定性表现

自动化测试

将人为驱动的测试行为转化为机器执行的过程被视为一种系统工程方法论的重要组成部分之一。在本质上来说,无论是自动化测验还是软件开发流程,都属于同一类别,区别仅在于前者主要依赖于自动化的测验工具来进行操作,而后者则更多地依赖于人工干预来完成任务流程.具体而言,这一流程主要包括以下几个环节:首先是在进行测试需求分析的基础上制定相应的自动化测验用例方案;其次是在明确系统功能目标后规划并构建自动生成式地执行相应功能的应用程序;最后则是通过编写详细的代码实现自动化的测验运行机制,并最终实现了这一套自动生成式地执行相应功能的应用程序。

安全测试

在整个IT软件产品的生命周期中，在特别关注于当产品开发基本完成并即将进入发布阶段时，在这个阶段实施严格的产品质量检验流程以确保其满足既定的安全需求定义和质量标准要求，并最终保证交付的产品达到预期的质量水平

基于Galois理论，在充足的数据量基础上选取具有典型代表性的样本点，并由此科学地规划（组织）相应的测试方案或实施步骤的一种系统化的科学实验设计体系。

性能测试

采用了自动化工具来模仿不同类型的正常、峰值以及异常负载条件来评估系统的各项关键绩效指标。无论是执行哪种类型的任务还是承受额外的压力任务而言，在这里所说的负载测试与压力测试都属于系统的性能评估范畴。通过持续上升的工作负载强度进行分析研究以观察其影响效果。压力测试的过程则是为了找出系统在超负荷运行时所存在的瓶颈或无法处理的特性并以此为基础计算出能够提供的最佳服务质量。