目录

软件测试术语四N-R

JAY.LIN 收录于软件测试技术探讨

2025-02-24 约 3878 字预计阅读 8 分钟

https://bing.ee123.net/img/rand?artid=2580465

目录

软件测试术语四(N-R)


N
N-switch coverage	N 切换覆盖	N+1 个转换的序列在一个测试套件中被覆盖的百分比。[Chow]
N-switch testing	N 切换测试	一种状态转换测试的形式，其测试用例执行N+1个转换的所有有效序列。 [Chow] 参见 state transition testing
negative testing	逆向测试	一种旨在表现组件/系统不能正常工作的测试。逆向测试取决于测试人员的想法，态度，而与特定的测试途径或测试设计技术无关，例如使用无效输入值测试或在异常情况下进行测试。 [Beizer]
non-conformity	不一致	没有实现指定的需求。 [ISO 9000]
non-functional requirement	非功能需求	与功能性无关，但与可靠性(reliability)、高效性(efficiency)、可用性(usability)、可维护性(maintainability)和可移植性(portability)等属性相关的需求。
non-functional testing	非功能测试	对组件/系统中与功能性无关的属性（例如可靠性、高效性、可用性、可维护性和可移植性）进行的测试。
non-functional test design techniques	非功能测试设计技术	推导或选择非功能测试所需测试用例的过程，此过程依据对组件/系统的规格说明进行分析，而不考虑其内部结构。参见 black box test design technique
O
off-the-shore software	现货软件	面向大众市场（即大量用户）开发的软件产品，并且以相同的形式交付给许多客户。
operability	可操作性	软件产品被用户操作或控制的能力。 [ISO 9126] 参见 usability
operational environment	运行环境	用户或客户现场所安装的硬件和软件产品，被测组件/系统将在此环境下使用。软件可能包括操作系统、数据库管理系统和其他应用程序。
operational profile testing	运行概况测试	对系统运作模型（执行短周期任务）及其典型应用概率的统计测试。[Musa]
operational testing	运行测试	在组件/系统的运作环境下对其进行评估的一种测试。 [IEEE 610]
oracle	基准	参见 test oracle
outcome	结果	参见 result
output	输出	组件填写的一个变量（无论存储在组件内部还是外部）。
output domain	输出域	可从中选取有效输出值的集合。参见 domain


output value	输出值	输出的一个实例/实值。参见 output
P
pair programming	结对编程	一种软件开发方式，组件的代码（开发和/或测试）由两名程序员在同一台计算机上共同编写。这意味着实时地执行代码评审。
pair testing	结对测试	两个人员，比如两个测试人员、一个开发人员和一个测试人员或一个最终用户和一个测试人员，一起寻找缺陷。一般地，他们使用同一台计算机并在测试期间交替操控。
partition testing	划分测试	参见 equivalence partitioning [Beizer]
pass	通过	如果一个测试的实际结果与预期结果相符，则认为此测试通过。
pass/fail criteria	通过/失败准则	用于判定测试项（功能）或特性通过或失败的决策规则。[IEEE 829]
path	路径	组件/系统从入口(entry point)到出口(exit point)的一系列事件（例如，可执行语句）。
path coverage	路径覆盖	测试套件执行的路径所占的百分比。100％的路径覆盖意味着100％的线性代码序列和跳转(LCSAJ)覆盖。
path sensitizing	路径感知	选择一组输入值，以强制执行某指定路径。
path testing	路径测试	一种白盒测试设计技术，设计的测试用例用于执行路径。
peer review	同行评审	由研发产品的同事对软件产品进行的评审，目的在于识别缺陷并改进产品。例如，审查(inspetion)、技术评审(technical review)和走查(walkthrough)。
performance	性能	组件/系统在给定的处理周期和吞吐率(throughput rate)等约束下，完成指定功能的程度。 [IEEE 610] 参见 efficiency
performance indicator	性能指标	一种有效性(effectiveness)和/或高效性(efficiency)的高级(抽象)度量单位，用于指导和控制开发进展。例如，软件交付时间的偏差(lead-time slip for software devlopment)。[CMMI]
performance testing	性能测试	判定软件产品性能的测试过程。参见 efficiency testing
performance testing tool	性能测试工具	一种支持性能测试的工具，通常有两个功能：负载生成(load gerneartion)和测试事务(test transation)测量。负载生成可以模拟多用户或者大量输入数据。执行时，对选定的事务的响应时间进行测量并被记录。性能测试工具通常会生成基于测试日志的报告以及负载－响应时间图表。
phase test plan	阶段测试计划	通常用于一个测试阶段的测试计划。参见 test plan
portability	可移植性	软件产品在不同硬件或软件环境之间迁移的简易性。[ISO 9126]
portability testing	可移植性测试	判定软件产品可移植性的测试过程。
postcondition	后置条件	执行测试或测试步骤后必须满足的环境和状态条件。
post-execution comparison	执行后比较	实际值与预期值的比较，在软件运行结束后执行。
precondition	前置条件	对组件/系统执行特定测试或测试步骤之前所必须满足的环境和状态条件。
predicted outcome	预期结果	参见 expected result
pretest	预测试	参见 intake test
priority	优先级	赋予某项（业务）重要性的级别，如，缺陷。
probe effect	探测影响	在测试时由于测试工具（例如，性能测试工具或监测器）对组件/系统产生的影响。比如，使用性能测试工具可能会使系统的性能有小幅度降低。
problem	问题	参见 defect
problem management	问题管理	参见 defect management
problem report	问题报告	参见 defect report


process	过程	一组将输入转变为输出的相关活动。 [ISO 12207]
process cycle test	过程周期测试	一种黑盒测试设计技术，设计的测试用例用于执行业务流程或过程。 [TMap]
product risk	产品风险	与测试对象有直接关系的风险。参见 risk
project	项目	一个项目是一组以符合特定需求为目的的，相互协同的，具有开始和结束时间的受控活动。这些特定需求包括限定的周期、成本和资源。 [ISO 9000]
project risk	项目风险	与（测试）项目的管理与控制相关的风险。参见 risk
program instrumenter	程序插装器	参见 instrumenter
program testing	程序测试	参见 component testing
project test plan	项目测试计划	参见 master test plan
pseudo-random	伪随机	一个表面上随机的序列，但事实上是根据预定的序列生成的。
Q
quality	质量	组件、系统或过程满足指定需求或用户/客户需要及期望的程度。 [IEEE 610]
quality assurance	质量保证	质量管理的组成部分，提供达到质量要求的可信程度。 [ISO 9000]
quality attribute	质量属性	影响某项质量的特性或特征。 [IEEE 610]
quality characteristic	质量特征	参见质量属性（quality attribute）。
quality management	质量管理	在质量方面指导和控制一个组织的协同活动。通常包括建立质量策略和质量目标、质量计划、质量控制、质量保证和质量改进。 [ISO 9000]
R
random testing	随机测试	一种黑盒测试设计技术，选择测试用例以匹配某种运行概貌情况（可能使用伪随机生成算法）.这种技术可用于测试非功能性的属性，比如可靠性和性能。
recorder	记录员	参见 scribe
record/playback tool	录制/回放工具	参见 capture/playback tool
recoverability	可恢复性	软件产品失效(faliure)后，重建其特定性能级别以及恢复数据的能力。 [ISO 9126] 参见 reliability
recoverability testing	可恢复性测试	判定软件产品可恢复性的测试过程。参见 reliability testing
recovery testing	恢复测试	参见 recoverability testing
regression testing	回归测试	测试先前测试过并修改过的程序，确保更改没有给软件其他未改变的部分带来新的缺陷(defect)。软件修改后或使用环境变更后要执行回归测试。
regulation testing	规范性测试	参见 compliance testing
release note	发布说明	标识测试项、测试项配置、目前状态及其他交付信息的文档，这些交付信息是由开发、测试和可能的其他风险承担者在测试执行阶段开始的时候提交的。[ISO 9126]
reliability	可靠性	软件产品在一定条件下(规定的时间或操作次数等)，执行其必需的功能的能力。 [ISO 9126]
reliability testing	可靠性测试	判定软件产品可靠性的测试过程。
replaceability	可替换性	在相同环境下，软件产品取代另一指定软件产品以达到相同目的的能力。 [ISO 9126] 参见 portability


requirement	需求	系统必须满足的，为用户解决问题或达到目的，条件或者能力。通过系统或者系统的组件的运行以满足合同、标准、规格或其它指定的正式文档定义的要求。[IEEE 610]
requirements-based testing	基于需求的测试	根据需求推导测试目标和测试条件以设计测试用例的方法。例如,执行特定功能的测试或探测诸如可靠性和可用性等非功能性属性的测试。
requirements management tool	需求管理工具	一种支持需求记录、需求属性（例如，优先级)和注解的工具，能够通过多层次需求和需求变更管理达到可追踪性。一些需求管理工具还支持静态分析，如一致性检查以及预定义的需求规则之间的冲突。
requirements phase	需求阶段	在软件生命周期中定义和文档化软件产品需求的阶段。 [IEEE 610]
resource utilization	资源使用	软件产品在规定的条件下执行其功能时，使用适当数量和类型资源的能力。例如，程序使用的主存储器和二级存储器容量，需要的临时或溢出文件的大小。 [ISO 9126] 参见 efficiency
resource utilization testing	资源使用测试	判定软件产品资源使用的测试过程。参见 efficiency testing
result	结果	测试执行的成果，包括屏幕输出、数据更改、报告和发出的通讯消息。参见 actual result, expected result
resumption criteria	继续准则	在重新启动被中断(或者延迟)的测试时，必须重复执行的测试活动。 [After IEEE 829]
re-testing	再测试	重新执行上次失败的测试用例，以验证纠错的正确性。
review	评审	对产品或产品状态进行的评估，以确定与计划的结果所存在的误差，并提供改进建议。例如，管理评审(management review)、非正式评审(informal review)、技术评审(technical review)、审查(inspection)和走查(walkthrough)。 [After IEEE 1028]
reviewer	评审人	参与评审的人员，辨识并描述被评审产品或项目中的异常。在评审过程中，可以选择评审人员从不同角度评审或担当不同角色。
review tool	评审工具	对评审过程提供支持的工具。典型的功能包括计划评审、跟踪管理、通讯支持、协同评审以及对具体度量（单位）收集与报告的存储库。
risk	风险	将会导致负面结果的因素。通常表达成可能的（负面）影响。
risk analysis	风险分析	评估识别出的风险以估计其影响和发生的可能性的过程。
risk-based testing	基于风险的测试	倾向于探索和提供有关产品风险信息的测试。 [After Gerrard]
risk control	风险控制	为降低风险到或控制风险在指定级别而达成的决议和实施防范（度量）措施的过程。
risk identification	风险识别	使用技术手段（例如，头脑风暴(brainstorming)、检验表(checklists)和失败历史记录（faliure history））标识风险的过程。
risk management	风险管理	对风险进行标识、分析、优先级划分和控制所应用的系统化过程和实践。
risk mitigation	风险缓解	参见 risk control
robustness	健壮性	在出现无效输入或压力环境条件下，组件/系统能够正常工作的程度。 [IEEE 610] 参见 error-tolerance, fault-tolerance
robustness testing	健壮性测试	判定软件产品健壮性的测试。
root cause	根本原因	导致不一致的根本因素，并具有通过过程改进彻底清除的可能。