JRT 0362-2026《金融业应用软件测试术语》

3术语和定义注：业务通常包括一系列过程，每个过程都有明确的目的，涉及多个参与方，通过信息交换实现，旨在达成某个既定目标，并延续一段时间。注：1.信息系统通常被视为一个由相互作用和相互依赖的若干部分(要素)组成的有机整体，这些部分包括人、计算机、网络和通信设备、软件、数据、规章制度等。3.信息技术基础架构包括服务器、存储、网络设备、安全设备等硬件资源。4.平台软件包括操作系统、数据库、中间件、云平台等支撑应用软件运行的基础软件。25.应用软件是基于信息技术基础架构与平台软件构建的直接支撑业务处理、业务管理与经营决策的软件系统。示例：1.银行业信息系统包括渠道型系统、交易型系统、账户型系统、数据计算型系统、管理型系统、分析型系统等类型的应用系统。2.证券业信息系统包括证券交易系统、结算系统、风险管理系统、信息披露系统等类型的应用系统。3.保险业信息系统包括核心业务系统、客户关系管理系统、财务管理系统、风险管理系统等类型的应用系统。一种质量维度的类别，用以对质量进行规约和评价。注：1.经典软件质量特性包括功能性、性能效率、兼容性、易用性、可靠性、信息安全性、可维护性、可移植性。更新后质量特性包括交互能力、灵活性、物理安全性，其中交互能力覆盖易用性，灵活性覆盖可移植性。2.每一个质量特性具有多个子特性。3.并非所有质量特性都适用于所有软件产品和信息系统。4.分布式架构语境中，重点关注可扩展性(灵活性的子特性)。产品或系统在规定条件下，在指定时间、容量参数范围内执行其功能，并且有效利3.性能效率中资源类型可包括CPU、内存、存储、网络设备，也可包括其他软件产品、系统配置。3注：1.交互能力的子特性包括适当性、可识别性、可学习性、可操作性、用户错误保护、用户参与度、包容性、用户协助、自描述性。2.交互能力的子特性覆盖了易用性的子特性。注：信息安全性的子特性包括保密性、完整性、不可抵赖性、可追踪性、真实性、抗攻击性。a)通过修改产品或系统及其组件达到排除故障、改进性能或其他属性来适应变更环境的能力。可移植性portability注：可移植性中的环境要求符合所在国家、地区、行业的相关法律、政策、制度、规范。4产品或系统及其组件处理负载增减或调整容量以适配负载波动的能力。注：可扩展性通常分为纵向可扩展性(提升单个资源的处理能力或容量)和横向可扩展性(增加资源数量，提升整体处理能力或容量)。[来源：ISO/IEC25010:2023,有修改]注：1.测试依据可以采用文件形式，如需求规格说明、设计规格说明或模块规格说明，也可以是非书面形式对需求行为的理解。2.测试依据可以包括行业规范和行业标准等通用要求。5注：测试条件常用来导出测试覆盖项(3.2.8),或由其本身构成测试覆盖项(3.2.8)。注：软件测试实践中，测试需求较测试条件更为常用。覆盖项(3.2.8),并导出或选择测试用例。注：1.测试设计技术包括静态测试设计技术和动态测试设计技术。2.静态测试设计技术可以使用静态代码分析、跨文档可跟踪性分析、审查有关软件和系统的其他信息。应用静态测试设计技术的主要目的是发现缺陷，也包括其他目的，如走查用于知识交流，技术审查用于获得共识，评审有助于预防未来的缺陷。选择静态测试技术，不仅依赖于测试的类型，也依赖于涉及的风险及静态测试的其他目的。3.动态测试设计技术用于识别测试条件、测试覆盖项(3.2.8)以及随后在测试项上执行的测试用例(3.2.10)。经典动态测试设计技术根据测试输入的导出方式分为3类，分别是基于规格说明的技术、基于结构的技术和基于经验的技术。场景分析也常被视为一种动态测试设计技术。动态测试设计技术之间既相互独立又相互补充，组合使用技术保障测试有效性。测试的高层大纲或故事线。注：1.测试场景与用户故事和使用场景的层次相当。测试场景比测试条件层级更高、内涵更抽象。3.测试场景用于快速识别在被测系统上的测试。测试用例testcase基于测试条件构造的一组前置条件、输入(包括操作，如果适用)和预期结果的集合，用于驱动测6注：1.测试用例是测试子过程的最低测试输入级别，即测试用例无法再划分为更细的测试用例。2.测试用例的前置条件包括测试环境、已有数据、被测软件、硬件等。3.输入是用于驱动测试执行的数据信息。4.预期结果包含通过的准则、失效的校核。5.金融产品具备时间价值，在被测系统中设置不同会计日期会影响测试用例的执行结果。测试用例集testcaseset测试套件testsuite一组测试用例。测试用例的执行序列，以及任何与构建初始前置条件所需的相关动作和执行后的收尾动作。注：测试件可以包括文档、脚本文件、输入、预期结果、文件、数据库、环境以及任何用于测试过程中附加的软件或设备。示例：在软件需求规格说明中对业务需求或用户需求的遗漏或误解、需求表述的错误转述等。72.在软件工程语境中，差错可泛指缺陷(3.2.17)、故障(3.2.18)、失效(3.2.19)所引发的各类偏离、异常状态与异常运行表现。2.系统状态：计算机程序中存在不符合规格说明的错误定义，使系统处于错误运行状态。2.在软件可靠性语境中，缺陷可泛指表示原因的故障(3.2.18)和表示结果的失效(3.2.19)。2.风险主要分类包括产品风险和项目风险。产品风险指产品在其功能、质量或结构的某些特定方面可能存在缺陷的风险。项目风险指与项目管理有关并影响项目成功的风险。示例：功能缺失、性能效率达不到预期、不符合组织的技术路线、不符合监管要求等产品风险。人员短缺、不合理的期限、需求变更等项目风险。8注：测试类型可以在单个测试子过程中执行或跨多个测试子过程执行(性能测试在组件测试子过程中完成，也在系统测试子过程中完成)。示例：功能测试、易用性测试、信息安全性测试、性能测试、数据迁移测试、端到端测试。[来源：GB/T38634.1—2020,3.42,有修改]由测试项结构导出测试用例的测试。注：1.基于结构的测试并不局限于组件级别的使用，其可以被用于所有级别，如系统测试中菜单项覆盖。2.技术包括分支测试、判定测试、语句测试。3.白盒测试、基于结构的测试是同义词。主要基于测试项外部输入和输出的测试，通常是依据规格说明而不是源码实现或可执行软件。3.黑盒测试与基于规格说明的测试是同义词。注：与脚本化测试相对的测试类型是无脚本测试(unscriptedtesting)。9使用预定义的脚本、工具，自动执行测试过程，比较实际结果与预期结果差异并输出测试结果的测试方式。注：探索性测试寻找隐含属性(包括隐含的行为),虽然其自身存在危害的可能性很小，但其可能干扰被测软件的其他属性，并因此产生软件失效的风险。注：用于度量测试项的功能性符合程度。注：1.非功能测试包括性能测试、安全性测试、可靠性测试、易用性测试等。2.不同测试项的非功能测试重点存在差异。注：1.性能测试与性能效率测试是同义词。性能测试包括负载测试(loadtesting)、压力测试(stresstesting)、容2.负载测试，用于评价测试项在预期变化负载(用户、交易、数据存储等)下行为的性能测试，负载通常位于低谷、典型和高峰使用的预期条件之间。3.压力测试，用于评价测试项在高于预期或指定容量负载需求，或低于最少需求资源条件下的行为。5.容积测试，用于评价测试项在吞吐量、存储容量或两者兼考虑的情况下处理指定数据量(通常达到最大指定容量或接近最大值)的能力。6.持久测试，用于评价测试项在指定的时间段，是否能够持续承受所需要的负载。持久测试与稳定性测试是同义词。端到端测试end-to-endtes通过制定一套统一评测标准，对测试项在标准任务下的量化运行指标进行度量和对标评价的测试。选型测试evaluationtesting注：1.基础性系统软件包括操作系统、交易中间件、通讯中间件、Web服务中间件、工作流中间件、数据库、运行时环境等。数据迁移测试datamigrationtesting验证数据迁移的全面性、准确性、时效性的测试。2.数据迁移测试需要关注数据迁移中的数据安全要求。灾难恢复测试disasterrecoverytesting:DRtesting注：测试与评估范围包括人工智能模型、算法及应用的内部能力、外部行为及其依赖的数据和基础设施。对数据密集系统的功能性、非功能性质量特性开展验证评估，并对相关数据进行数据质量测量的测试活动。注：1.典型数据密集系统包括大数据系统、数据流处理系统、数据仓库、数据湖、分布式数据存储与处理系统。2.数据密集系统的主要性能瓶颈与运行挑战来源于数据的规模、速率、多样性或其组合，而非单纯的计算能力。示例：1.测量金融监管报送数据的质量，及测试相关系统的数据处理对数据完备性和时效性的影响。2.评估采用分布式架构的数据密集系统在网络分区故障场景下的数据一致性保障能力。组织级测试规范organizationaltestspecification注：1.成熟组织的组织级测试规范包括组织级测试方针和组织级测试策略。2.组织级测试规范存在与否并不是测试开展的前提条件，但会影响测试的连贯性和一致性。3.组织级测试规范通常以测试过程体系文件形式存在。4.组织级测试规范与组织级开发规范相匹配，定义开发过程与测试过程的协同以及在组织内的职责及分工。组织级测试策略organizationalteststrategy注：1.组织级测试策略与组织级测试方针保持一致。2.一个组织可以有多个组织级测试策略以应对不同类型的项目。注：特定项目的测试过程可能包含多个子过程，如测试计划子过程(较大测试管理过程的一部分)、静态测试子过程、系统测试子过程。(如易用性测试、性能测试)的测试管理和动态(和静态)测试过程。注：测试子过程可以包含一个或多个测试类型。测试子过程也被称为测试阶段或测试任务。注：1.以下是常用测试级别，可以实例化为测试子过程：单元测试级别或单元测试子过程、组件测试级别或组件测试子过程、集成测试级别或集成测试子过程、系统测试级别或系统测试子过程、验收测试级别或验收测试子过程。2.测试级别与测试阶段是同义词。注：1.以下是常用测试阶段，可以实例化为测试子过程：单元测试阶段或单元测试子过程、组件测试阶段或组件测试子过程、集成测试阶段或集成测试子过程、系统测试阶段或系统测试子过程、验收测试阶段或验收测试子过程。2.测试阶段与测试级别为同义词。注：测试环境可以包括多种环境以适应指定的测试子过程(如单元测试环境、性能测试环境等)。测试数据testdata注：见测试策划过程、测试监测和控制过程、测试完成过程。测试设计和实现过程testdesignandimplementa动态测试过程的子过程。用于在准备好的测试环境中执行测试用例和实现过程中创建的测试规程，并记录其结果。注：1.缺陷数据分析是统计分析活动，可用于评估测试项质量、改进开发和测试过程、预防同类缺陷再次发生，为决策提供支撑。注：1.单元测试通常由软件的提供方或开发方组织实施测试，也可以委托第三方进行软件单元测试。2.单元测试通常采取白盒测试方式。3.单元测试可以采取静态测试方法和动态测试方法。4.在针对某个具体软件单元的测试中有时需要集成相关单元组来进行测试。注：1.组件测试与组件集成测试通常由软件组件的提供方或开发方组织实施测试，也可以委托第三方进行测试。2.组件测试与组件集成测试可以采取白盒测试方式和黑盒测试方式。注：1.系统测试与系统集成测试通常由第三方实施测试。也可以由系统的提供方或开发方进行测试。2.系统测试与系统集成测试通常采取黑盒测试方式。注：1.验收测试通常由用户或用户代表实施测试，也可以委托第三方进行测试。2.验收测试采取黑盒测试方式。3.验收测试在用户真实使用环境或接近用户真实使用环境的测试环境中开展。4.验收测试也常称为用户验收测试(useracceptancetesting)。2.若冒烟测试不通过，通常表明该版本不具备开展全面测试的条件。接口测试interfacetesting回归测试regressiontesting集成在敏捷研发