JR∕T 0175—2019 《证券期货业软件测试规范》(金融).pdf

《JR∕T 0175—2019 《证券期货业软件测试规范》(金融).pdf》由会员分享，可在线阅读，更多相关《JR∕T 0175—2019 《证券期货业软件测试规范》(金融).pdf（61页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、ICS 03.060A11JR中 华 人 民 共 和 国 金 融 行 业 标 准JR/T 01752019证券期货业软件测试规范Specification for securities and futures industry software testXXXX-XX-XX 发布XXXX-XX-XX 实施中国证券监督管理委员会发 布JR/T 01752019I目次前言.III引言.IV1 范围.12 规范性引用文件.13 术语和定义.14 总体要求.25 单元测试.176 集成测试.187 系统测试.208 系统集成测试.219 验收测试.22附录 A（规范性附录）测试流程.24A.1 测试估

2、计.24A.2 测试计划.24A.3 测试设计.24A.4 测试执行.26A.5 测试报告.26附录 B（资料性附录）软件测试模板.28B.1 测试工作量估计书.28B.2 测试计划.29B.3 测试需求.30B.4 测试用例.31B.5 测试缺陷列表.32B.6 评审记录.33B.7 测试总结报告.33B.8 管理者报告.35B.9 里程碑总结报告.36附录 C（规范性附录）测试技术.38C.1 黑盒测试.38C.2 白盒测试.44C.3 灰盒测试.45附录 D（规范性附录）静态测试方法.46D.1 概述.46D.2 评审.46JR/T 01752019II附录 E（规范性附录）业务分类.4

3、9附录 F（规范性附录）缺陷管理.50F.1 缺陷管理目的.50F.2 缺陷管理的生命周期.50F.3 缺陷管理流程图.52F.4 缺陷严重度划分.53F.5 缺陷优先级划分.53F.6 根本原因举例.53参考文献.55JR/T 01752019III前言本标准按照GB/T 1.1-2009给出的规则起草。本标准由全国金融标准化技术委员会证券分技术委员会（SAC/TC180/SC4）提出。本标准由全国金融标准化技术委员会(SAC/TC180)归口。本标准起草单位：中国证券监督管理委员会信息中心、中国证券监督管理委员会证券基金机构监管部、大连商品交易所、上海证券交易所、深圳证券交易所、上海期货交

4、易所、郑州商品交易所、中国金融期货交易所、证券期货业信息技术测试中心（大连）、中国银河证券股份有限公司、南方基金管理有限公司。本标准主要起草人：张野、刘铁斌、蒋东兴、周云晖、马晨、高红洁、王恺、郭郛、陈楠、王凤海、许强、胥海涛、刘军、孙瑞超、陆素源、蒋凯、陈彦、喻华丽、万春波、顾军妹、陈亮、邹杏忠、徐玲、于三禄、刘相富、鲁继东、戴鹏、刘进、汪璇璇、董琳、徐艳、刘洁如、韩秀玲、邓志远、刘丹、唐沛来、邓廷勋、邱星、牛云峰。JR/T 01752019IV引言证券期货业市场的发展和平稳运行高度依赖行业信息系统。规范统一行业信息系统的测试标准，有助于规范行业信息系统的测试管理，提高行业软件测试过程的规范

5、化程度，促进行业软件测试水平整体提升，从而降低行业信息系统运行风险，促进证券期货业的可持续性健康发展。本标准具有鲜明的行业特征，将行业经验、实践与测试理论紧密结合，使标准更加易于落实和实施，能够有效指导行业软件测试活动、提高测试质量，其中：a)测试管理与测试流程基于CMMI 软件能力成熟度集成模型和TMMI 测试成熟度模型编制，并在此基础上提供以下适应行业特点的内容：1)提供各测试阶段的工作要求，更细致地指导测试工作开展，见 4.2.1；2)明确各测试文档规范、基本内容并提供参考模板，见 4.2.2 及附录 B；3)提供测试管理细则，明确各项管理工作具体要求和实施内容，以便测试管理工作切实开展

6、，见 4.6；4)针对行业特点细化测试流程中各阶段工作内容及要求，见附录 A；5)细化各测试类型及测试级别的测试准入/准出要求，用于更加细致地指导测试具体工作，见 4.5、5.5、6.5、7.5、8.5、9.5。b)系统内容与测试类型、测试级别与测试类型的基本要求遵循 GB/T 15532-2008计算机软件测试规范并根据行业特点明确以下关系：1)系统内容与测试类型之间的关系，便于行业机构根据软件产品可能涉及的测试内容选择适合的测试类型，同时增加应急演练、联网测试、全市场测试及选型测试四个测试类型。2)测试级别与测试类型的对应关系，便于行业机构根据其角色、软件产品特点等实际情况，选择适合的测试

7、级别和测试类型，确保行业机构履行测试工作职责、保证软件产品质量。c)本标准内容符合 JR/T 0146-2016（所有部分）证券期货业信息系统审计指南系列标准中与软件测试相关的审计要求。JR/T 017520191证券期货业软件测试规范1范围本标准规定了证券期货业信息系统建设过程中的总体要求、单元测试、集成测试、系统测试、系统集成测试、验收测试等测试活动的内容。本标准适用于证券期货业市场核心机构（以下简称市场核心机构）、证券期货基金经营机构（以下简称市场经营机构）、证券期货信息技术服务机构（以下简称市场服务机构）开展证券期货业计算机软件和外部信息系统测试工作。注 1：市场核心机构，如证券期货交

8、易所、证券登记结算机构、期货市场监控中心等；注 2：市场经营机构，如证券公司、期货公司、基金公司等；注 3：市场服务机构，如软件开发商、信息商、服务商等。2规范性引用文件下列文件对于本文件的应用是必不可少的。凡是注日期的引用文件，仅所注日期的版本适用于本文件。凡是不注日期的引用文件，其最新版本（包括所有的修改单）适用于本文件。GB/T 11457-2006信息技术 软件工程术语GB/T 15532-2008计算机软件测试规范GB/T 29834.3-2013系统与软件维护性 第3部分：测试方法JR/T 0145-2016资本市场交易结算系统核心技术指标3术语和定义GB/T 11457-2006

9、界定的以及下列术语和定义适用于本文件。为了便于使用，以下重复列出了GB/T11457-2006中的某些术语和定义。3.1测试级别 test level根据软件开发的生命周期、测试对象及测试人员的不同，将软件生命周期中的测试活动分为不同的级别。3.2测试流程 test process一个完整的测试任务按顺序经历的过程。3.3测试用例 test case为特定目标编写的测试输入、执行操作及期望结果的集合。注：改写GB/T 11457-2006，定义2.16953.4测试轮次 test cycles项目中在一个完整、全量发布版本上将项目计划的所有可执行用例执行一遍的次数。JR/T 017520192

10、3.5通关测试 production readiness test新系统、新业务、新产品上线启用前，由市场核心机构组织并由全市场参与者共同参与，在生产环境上模拟系统/业务/产品上线首日行为的测试。3.6第三方测试机构 the third party testing institute处于用户和产品开发商利益之外、根据有关标准或规范对产品进行客观质量检验的专业测试机构。3.7裁剪 tailor对相关测试活动、测试方法、测试内容、测试类型、测试输出文档等进行调整、增加、删除、替换、顺序变更等。4总体要求4.1测试目的验证软件满足软件开发合同、系统/子系统设计文档、系统需求规格说明书、系统设计说明书

11、、产品说明书、运维手册和操作手册等软件质量要求。通过测试发现软件缺陷，为软件产品的质量评价提供依据。4.2测试流程4.2.1测试阶段的工作要求各测试级别、测试类型的测试应遵循此测试流程。此测试流程分为测试估计、测试计划、测试设计、测试执行、测试报告五个阶段，各阶段的活动、输入输出见附录A。各测试阶段应遵守的工作要求见表1。表 1工作要求测试阶段测试阶段工作要求工作要求测试估计a)功能测试和非功能测试的测试范围合理、覆盖全面、无冗余；b)估计工作量时，测试策略选择合理、有效；c)功能测试及非功能测试均完成测试工作量估计，且有充分的估计依据；d)如有测试工具开发、验收测试支持、测试管理等其他工作，

12、均完成测试工作量估计，且有充分的估计依据。测试计划a)明确功能与非功能的测试范围、测试策略、测试执行的准入/准出要求；b)测试策略与测试工作量估计书中的测试策略存在明显差异时，应有合理的解释说明；c)详细测试进度安排合理、里程碑时间点明确，避免测试不足或过度测试；d)测试环境部署策略符合系统规划要求，使用的测试工具名称、版本和用途描述清晰；e)明确在测试活动中可能发生的风险及其影响和应急措施；f)明确测试过程中的问题管理流程、变更管理流程、进度管理流程、缺陷管理流程。JR/T 017520193表 1 工作要求（续）测试阶段测试阶段工作要求工作要求测试设计a)测试需求：应 100%覆盖业务需求

13、和系统需求规格说明书，并适当参考相关开发设计文档；b)测试用例：应 100%覆盖测试需求或按照测试级别不同 100%覆盖相关设计、需求文档，如单元测试、集成测试覆盖相关开发设计文档，系统测试覆盖系统需求规格说明书等；c)非功能测试场景的设计中充分考虑可能产生影响的业务数据量，且在真实生产环境下有效、在测试环境下可测。测试执行a)明确记录每条测试用例的执行结果，未执行的用例应写明未执行原因；b)对于核心、重要的系统及功能应对测试执行过程以截图或者保留日志的方式进行留痕；c)执行过程中发现的缺陷及问题，应及时记录在缺陷管理工具或者缺陷列表中，并进行及时处理，测试结束后无非最终状态的缺陷。测试报告a

14、)明确功能及非功能的测试范围，如与测试计划中存在差异，可进行解释说明；b)明确测试结论，从功能及非功能角度分别描述具体的通过标准及实际测试结果，给出是否通过的结论；c)写明测试环境部署情况，测试环境与生产环境的差异分析；d)明确测试版本、测试执行情况、对缺陷进行汇总及分析；e)进行改善建议、经验教训总结，为后续工作提供参考。4.2.2测试文档规范各测试阶段的输出文档，宜包括的基本内容见表2，可根据实际需要适当裁剪，具体模板参见附录B。表 2文档的基本内容阶段阶段输出文档输出文档文档的基本内容文档的基本内容测试估计测试工作量估计书各系统模块的测试设计复杂度、测试执行复杂度、测试用例估计个数、测试

15、设计工作量、测试执行工作量、非功能测试工作量等。测试计划测试计划测试目标、测试范围、测试策略、测试进度计划、测试环境、测试方法、测试管理、测试报告等。测试设计测试需求需求功能、验证点、验证方式等。测试用例测试用例ID、优先级、场景说明、方法/函数、正常系/异常系、前提条件、测试目的、测试步骤、测试数据、期望结果等。测试执行测试缺陷列表缺陷ID、缺陷描述、再现步骤、期望结果、实际结果、测试轮次、测试类型、发现版本、发现日期、缺陷负责人、缺陷提交人、严重度、优先级、缺陷状态、根本原因、解决方案、关闭日期等。测试执行结果测试用例的实际执行结果、通过或不通过、对应的缺陷ID、测试人员、实际测试日期、测

16、试步骤截图等。测试报告测试总结报告测试范围、测试结论、测试环境与生产环境的差异分析、功能测试/非功能测试执行情况、缺陷汇总及遗留问题分析、测试结果分析、经验教训、改善建议等。测试管理管理者报告进度情况、工作量偏差、质量目标达成情况、风险与问题等。里程碑总结报告里程碑的进度、成本和质量情况、风险与问题、经验教训、改善建议等。JR/T 0175201944.3测试类型4.3.1功能测试功能测试的主要目的、测试内容及测试技术如下：a)目的以系统需求规格说明书为依据对其中要求的功能实现、业务操作等系统功能特性进行验证，目的是确保系统在指定的条件下满足客户的功能性和易用性要求。b)测试内容/关注点测试内

17、容/关注点包含实现的功能正确、不存在无用的功能和不存在功能的遗漏，具体如下：1)实现的功能正确：与系统需求规格说明书上要求的功能一致；2)不存在无用的功能：实现的功能范围未超出系统需求规格说明书描述的范围；3)不存在功能的遗漏：实现的功能范围能完全覆盖系统需求规格说明书描述的范围。c)测试技术以黑盒测试技术为主，灰盒测试技术为辅。本标准中提及的黑盒测试技术、白盒测试技术及灰盒测试技术见附录 C。4.3.2性能测试性能测试的主要目的、测试内容及测试技术如下：a)目的通过模拟真实、高压力等各种负载条件的业务场景，对系统的各项性能指标进行评估，通常包括负载测试、压力测试、容量测试、业务响应时间测试等

18、。b)测试内容/关注点测试内容/关注点包含负载测试、压力测试、容量测试和业务响应时间测试，具体如下：1)负载测试：对系统不断地增加压力或持续保持最大安全负载，直到系统的某项或者多项性能指标达到安全临界值（例如某种资源已经达到饱和状态等），获得系统在不同负载条件下的性能指标；2)压力测试：超过安全负载的情况下，对系统不断地施加压力，通过确定一个系统的瓶颈或不能接收用户请求的性能点，来获得系统可提供的最大服务级别的测试；3)容量测试：使用反映系统容量特征的极限值（如最大并发用户数、数据库记录数等）对系统施加压力，通过观察系统在极限容量状态下没有出现任何软件故障或还能保持主要功能正常运行来检测系统的

19、容量指标；4)业务响应时间测试：被测系统在稳定压力持续运行过程中或达到一定容量后进行业务操作，记录系统处理所花费的时间，以此检测业务响应时间符合性能需求。c)测试技术具体如下：1)负载测试、压力测试和业务响应时间测试的测试方法是通过模拟单用户和多用户并发的场景，获取软件系统功能处理的延时、吞吐率及处理时间。利用自动化测试工具进行数据构造、负载压力构造，通常选择具有代表性或者核心业务的模块、访问量较高的业务构造各种性能测试场景，从而进行单机性能测试或并发性能测试。测试指标包括订单峰值吞吐速率、成交峰值吞吐速率、订单持续吞吐速率、成交持续吞吐速率、订单处理延时、日结算处理能力等；JR/T 0175

20、201952)容量测试的测试方法是在不同的系统配置以及不同的业务场景下构造相应的容量数据，评估系统的极限容量和硬件资源占用率。其中，极限容量包括最大用户数、最大处理量、最大事务数（执行单元）、最大吞吐率、最大文件容量等；硬件资源占用率包括内存、CPU、硬盘、网络带宽、设备等。测试指标包括日订单处理容量、日成交处理容量等。4.3.3可靠性测试可靠性测试的主要目的、测试内容及测试技术如下：a)目的可靠性测试是通过模拟系统可能出现的各种异常或故障等场景，来验证系统在异常处理、故障容错、数据恢复及容灾等方面的能力，并对系统的可靠性进行评估，目的是确保系统在特定的环境部署条件下满足高可用性要求，通常包括

21、成熟性测试、容错性测试、稳定性测试和可恢复性测试。b)测试内容/关注点测试内容/关注点包含成熟性测试、容错性测试、稳定性测试和可恢复性测试，具体如下：1)成熟性测试：当软件系统中出现代码判断错误、集成中的接口错误、通讯报文错误、系统中业务逻辑错误以及其他在设计、开发等环节中造成的错误时，验证系统能消除错误造成的影响并仍可正常工作；2)容错性测试：当引入外部错误，如违规操作、删除数据、强行终止等严重的行为使系统(包括硬件、软件及附属程序)发生异常时，验证系统在异常情况下应具有防护性措施（处理异常的方法包括：系统自动处理和人工干预处理）；3)稳定性测试：通过持续性测试的方法验证系统在一定压力下长时

22、间运行的稳定性；4)可恢复性测试：系统在失效状态下，恢复至正常状态的能力。失效状态应是系统崩溃或者宕机停止所有功能，而不是带故障的运行状态；正常状态应是至少保证系统的主要功能可全部运行。获取系统恢复时间（RTO）、数据恢复时间（RPO），RTO、RPO 定义见 JR/T0145-2016。c)测试技术具体如下：1)成熟性测试、容错性测试的测试方法是通过人工模拟故障场景，如进程崩溃及挂起、网络断开及延迟、服务器宕机等场景，或通过工具或手工制造异常操作或异常数据输入等，验证系统或组件在出现故障时进行有效处理的能力；2)稳定性测试的测试方法是 7*24 小时压力测试，即仿照生产的业务配比关系，根据实

23、际生产需要，保持不同倍数下单压力，每天运行被测系统 24 小时，连续运行 7 天。在测试期间可通过查看系统进程状态、执行功能操作、查看运行日志信息的方式来验证系统运行状态的正确性；3)可恢复性测试的测试方法是模拟在出现故障或灾难导致系统失效时，通过分析系统日志或流水计算得到系统恢复时间（RTO）和数据恢复时间（RPO）指标。4.3.4安全性测试安全性测试的主要目的、测试内容及测试技术如下：a)目的通过安全测试手段和方法，验证软件的安全特性实现与预期一致、检验软件产品对各种攻击情况的防范能力，从而保障产品的安全质量。JR/T 017520196b)测试内容/关注点具体如下：1)配置管理：按照信息

24、安全等级保护要求对操作系统、应用程序、数据库、网络设备等进行安全配置；2)资源利用：应用程序内存使用和资源竞合问题，如变量未初始化、数组越界、内存溢出、资源泄露、进程线程异常等；3)身份鉴别：对登录操作系统、数据库系统和应用系统的用户进行了身份标识和鉴别，如应使用强密码策略、限定连续登录尝试次数、使用有效验证码等；4)访问控制：用户应根据自己的权限大小来访问系统资源（如服务器、目录、文件等），不得越权访问；5)数据保护：应用程序存储敏感信息的情况，存储的敏感信息应进行加密，包含但不限于密码、密钥等敏感信息应加密写入缓存、文件系统、数据库中等；6)通信安全：应用程序使用安全通信协议（如 SSL、

25、TLS）的情况，对敏感信息的传输应进行加密等；7)会话管理：本地及服务器端对会话超时的设置，会话结束后应用程序使用过的敏感信息应从内存中删除，合法用户的会话不被劫持等；8)数据验证：应用程序在使用前正确验证来自客户端或外界输入数据的情况，避免发生如跨站脚本攻击、命令注入、文件注入、SQL 注入等漏洞；9)安全审计：对网络系统中的网络设备运行状况、网络流量、用户行为等进行日志记录；审计记录应包括事件的日期和时间、用户、事件类型、事件成功及其他审计相关的信息等。c)测试技术常见的安全性测试技术有安全功能检查、代码安全测试、漏洞扫描、渗透测试和模糊测试，具体如下：1)安全功能检查是指测试人员通过对相

26、关系统管理人员进行访谈和对测试对象（如相关系统、各类设备、基线标准、开发设计文档）进行观察、验证、分析以确认测试对象符合信息安全等级保护、相关信息安全要求以及安全功能需求的过程；2)代码安全测试分为静态检测和动态检测。静态检测是使用代码检测软件进行代码静态扫描，并对扫描后结果进行人工分析来发现定位漏洞的过程；动态检测即在运行时进行错误检查，主要通过将已经写好的程序转换成一个新程序（其功能与原程序是等价的），新程序包含有一些额外的代码，它们的作用是在程序执行期间检查错误；3)漏洞扫描是指利用专业的漏洞扫描工具，基于公共漏洞和暴露（CVE）漏洞数据库或特征库，通过扫描、探测等方法对目标系统的安全情

27、况进行检测，发现可利用的漏洞；4)渗透测试是通过模拟恶意黑客的攻击方法对目标系统进行模拟入侵，以找出系统中的脆弱点、技术缺陷和漏洞；5)模糊测试是一种通过提供非预期的输入并监视异常结果来发现软件故障的方法，是一个自动的或半自动的过程，通常包括识别目标、识别输入、生成模糊测试数据、执行模糊测试、监视异常、确定可利用性等阶段。4.3.5可移植性测试可移植性测试的主要目的、测试内容及测试技术如下：a)目的JR/T 017520197通过模拟部署在不同的运行平台来验证系统运行的适应性，目的是确保系统在运行环境发生变化时运行及处理可满足预期要求，通常包括可安装性测试、兼容性测试、适应性测试和可替换性测试

28、。b)测试内容/关注点测试内容/关注点包含可安装性测试、兼容性测试、适应性测试和可替换性测试，具体如下：1)可安装性测试：在目标环境对软件安装程序所进行的测试，包括操作系统安装软件或在客户个人电脑上安装软件产品的安装向导软件。主要关注：安装文档应齐全、软件安装的程序文件应齐全、文件格式应与安装指导中要求的文件格式相同；所有预置的数据应齐全；软硬件环境的配置应合理；所有文件应正确产生并确有所需要的内容等；2)兼容性测试：如果不存在相互依赖关系的计算机系统可在同一环境（例如：同一个硬件平台）中运行，而不影响彼此的行为（如资源冲突），则称之为兼容，包括应用软件与硬件平台、应用软件与操作系统、操作系统

29、与硬件平台间的兼容性，例如：当新的或升级之后的软件被大量装入已经安装了应用程序的环境（例如：服务器）时，应执行兼容性测试；3)适应性测试：软件系统能在所有特定的目标环境（硬件、软件、中间件、操作系统等）中正确运行，包括软件系统在不同处理器配置下的适应性、在台式机与专业服务器下的适应性、在不同操作系统下的适应性、在不同网络环境下的适应性；4)可替换性测试：软件系统中组件能被替换的能力以及软件升级引起的新旧版本的可替换性。c)测试技术可安装性测试、兼容性测试、适用性测试和可替换性测试的测试方法如下：1)可安装性测试的测试方法：模拟软件系统在目标环境中进行安装、升级及卸载等操作，验证其正常运行能力；

30、2)兼容性测试的测试方法：模拟软件系统在目标环境中与其他应用程序、升级后操作系统等软硬件共存的场景，验证其正常运行能力；3)适应性测试的测试方法：模拟软件系统在不同的特定目标环境下运行的场景，验证其正常运行能力；4)可替换性测试的测试方法：模拟系统在不同软件组件或者版本上运行的场景，验证其正常运行能力，尤其对于以第三方商业软件为特定组件的软件系统。4.3.6可维护性测试可维护性测试的主要目的、测试内容及测试技术如下：a)目的通过评审系统设计结构、开发语言、系统文档及用户文档来评估系统后续易于修改、优化及能满足新需求的开发，目的是确保系统在交付后直至到期被淘汰的整个时期内易于理解和改进。b)测试

31、内容/关注点具体如下：1)软件系统具有错误的易分析性，内部：检验设计、文档、代码的书写规格，代码注释和错误标注规范性和充分性等，外部：检验错误发生时系统的响应结果，便于发现和准确定位问题；JR/T 0175201982)软件系统具有使指定的修改可被实现的能力，包括编码、设计和文档的更改，实现参数文件、数据库、表、操作方式、个性化配置；3)修改后的软件系统仍然能达到所需功能要求和运行指标。c)测试技术常见的维护性测试技术有：专家评审法、技术测试法和用户调查法，具体见 GB/T29834.3-2013。1)专家评审法是一种主观的评审方法。评审时，应根据被评审对象和评审目的，设计评审项目表，列出栏目

32、、分值、权重和打分规则。专家根据自身的经验与认知，进行判断打分，然后根据专家的权重和统计规则计算最终评分；2)技术测试法是一种客观的评分方法。技术测试时，可依据被测对象和测试目的，选择适用的自动化测试工具，也可人工进行手动测试。技术测试获得的结果是一种量化的测量结果；3)用户调查法是一种面向用户群的问卷征询方法。用户调查时，应根据调查的目的和特定的用户群，设计调查表，让被调查对象填写并反馈，调查表回收数应达到一定的数量，并不低于发出的适当比例。然后对回收的调查表进行汇总计算，其计算值作为用户调查的结果。4.3.7应急演练应急演练的主要目的、测试内容及测试技术如下：a)目的充分分析可能出现的各种

33、突发事件并对其制定相应应急预案，通过评审及演练，检验预案的实用性、可用性、可靠性，相关人员应急行动实施的有效性以及避免事故、防止事故、抵抗事故的能力，目的是确保在上线过程或上线后突发重大事故、设备故障等情况下，相关人员可及时反应、妥善处理，从而使事故造成的影响和损失降到最低。b)测试内容/关注点具体如下：1)应急预案具有完整性、正确性、一致性及易理解性，符合应急要求；2)突发事件场景考虑全面，应急过程所用工具、脚本可用，按照应急预案中描述的操作步骤可将系统恢复至正常运行状态；3)系统恢复时间（RTO）、数据恢复时间（RPO）符合应急要求。与可靠性测试的区别在于测试环境不同，且测试场景更贴近于生

34、产已经发生过的或者可能发生的紧急情况；c)测试技术以黑盒测试为主，通过应急预案静态检查、应急预案模拟演练、分析系统日志或流水等方法，保证应急预案的有效性和正确性。4.3.8联网测试联网测试的主要目的、测试内容及测试技术如下：a)目的市场核心机构组织部分或全部市场参与方，在测试环境或准生产环境开展的接口处理及业务流程测试，目的是验证交易所和各参与方的接口处理及业务流程的正确性，以及网络的连通性。此测试类型可根据实际情况进行裁剪。b)测试内容/关注点JR/T 017520199具体如下：1)验证机构间接口含义理解及处理的一致性、正确性；2)验证机构间业务及数据交互流程的正确性。c)测试技术以黑盒测

35、试为主，参测各方通过场景设计对测试关注点进行验证。4.3.9全市场测试全市场测试也称为全网测试，其主要目的、测试内容及测试技术如下：a)目的利用非交易日，市场核心机构组织部分或全部市场参与方，利用生产环境进行联网测试，目的是通过模拟真实的市场行为来验证交易所和各参与方的系统功能、性能、可靠性以及整体业务流程等功能测试和非功能测试与需求规格说明书的一致性，确定系统具备上线条件。b)测试内容/关注点具体如下：1)各参与者系统和具体业务的功能及流程应正确，性能、可靠性等非功能测试应满足需求规格说明书；2)系统上线所需线路等技术条件应完备并可正常使用；3)参与市场业务各方上线条件应已完备；4)新程序或

36、系统上线后，相关系统能正常适应；5)可根据实际情况需要，增加通关测试。c)测试技术以黑盒测试为主，参测各方通过场景设计对测试关注点进行验证。4.3.10选型测试选型测试的主要目的、测试内容及测试技术如下：a)目的在软件竞品选择的过程中，使用测试理论和方法对软件竞品进行多种技术指标的评测，通过多个维度对软件竞品进行评测对比，为软件竞品选择提供参考指标数据。b)测试内容/关注点测试内容/关注点包含软件可靠性选型、软件性能选型、安全选型和软件功能选型，具体如下：1)软件可靠性选型：使用相同的可靠性测试方法针对不同软件竞品进行可靠性测试，检测不同竞品的可靠性指标差异；2)软件性能选型：使用相同硬件环境

37、和相同的性能测试方法针对不同的软件竞品进行性能测试，检测不同竞品的性能指标差异；3)安全选型：使用相同的安全测试方法针对不同的软件竞品进行安全测试，检测不同竞品的安全指标差异；4)软件功能选型：根据产品需求对软件功能进行功能测试，检测不同竞品在满足相同需求条件下功能实现的差异性。c)测试技术根据选型目的选择一种或多种测试方法进行选型测试，具体测试方法见 4.3.1、4.3.2、4.3.3、4.3.4。4.3.11选择原则JR/T 0175201910行业机构根据软件产品可能涉及的测试内容需选择适合的测试类型，具体选择原则见表3，其中【类别】不可裁剪，【内容】可根据行业特点进行裁剪，相关的测试内

38、容宜使用画圈的测试类型。表 3各测试类型的测试内容类别内容测试类型功能测试性能测试可靠性测试安全性测试可移植性测试可维护性测试应急演练联网测试全市场测试选型测试基础架构通信线路网络结构主机硬件操作系统及编译环境存储设备灾备架构应用软件数据交换接口数据存储方式应用程序数据库等第三方应用业务规则根据实际业务情况填写，如交易规则、清算业务上线运维上线步骤应急方案数据迁移运维管理注：“”表示选取4.4测试级别4.4.1工作目标根据软件生命周期和测试周期自然形成的阶段，测试级别包含单元测试、集成测试、系统测试、系统集成测试、验收测试。待上线系统应经过五个测试级别及全市场测试之后，才能达到上线要求，允许上

39、线。每个测试级别的测试应根据4.2的要求展开相关工作。各测试级别的工作目标见表4。表 4测试级别的工作目标测试级别测试级别目标目标单元测试验证程序及模块内部逻辑符合系统设计说明书，又称为模块测试，是动态测试的最早期阶段。JR/T 0175201911表 4测试级别的工作目标（续）测试级别测试级别目标目标集成测试将应用内部的模块组合在一起进行测试，测试接口，各类集成以确保接口数据不会丢失，一个模块的功能不会影响其他模块的功能，各模块组合起来能达到预期要求等。系统测试针对单一被测系统以及系统内部组件间接口进行的测试，通过功能测试和非功能测试相结合的方式验证该系统应正确运行、满足项目需求规格说明书，

40、从而确保系统功能及操作性上的成熟度和健康度。系统集成测试针对多个被测系统之间数据交互以及系统间接口进行的测试，验证整个系统承载的业务流程实现正确及系统整体与外界的硬件、网络间合作运行正确，从而确保整个系统在生产环境中的运行可达到客户预期。验收测试在模拟的客户环境中，验证产品能满足客户的需求。4.4.2选择原则根据行业机构角色及软件产品来源的不同，明确各机构的测试职责范围，以指导行业机构履行职责、把控软件质量，具体如下：a)市场核心机构与市场经营机构：1)对于完全外购的软件产品，因其需经过配置、联调才可与其他系统整体协同工作，故应对外购软件产品进行系统集成测试及验收测试；2)对于部分模块或组件为

41、外购的软件产品，因其外购模块或组件需与自主研发或其他产品集成，故应对外购模块或组件进行集成测试、系统测试、系统集成测试及验收测试；3)对于完全自主研发的软件产品，应进行单元测试、集成测试、系统测试及验收测试；4)对于接入期货公司信息系统的外部信息系统，期货公司要对其进行必要的系统集成测试及验收测试，保证外部信息系统的合规性和安全性。b)市场服务机构：对于向行业提供的软件产品，应至少进行单元测试、集成测试及系统测试。各证券期货业机构可委托第三方测试机构完成所需的验收测试工作，但是应遵循以下原则：1)市场服务机构不能代替用户对本机构研发或代理销售的软件产品进行验收测试。2)对于完全外购或部分外购软

42、件产品的验收测试应由用户或其委托的第三方测试机构完成。3)第三方测试机构的测试过程均需符合本标准要求。4)市场监管机构可依据本标准要求，监督、检查相关机构执行情况。测试级别和测试类型的对应关系见表5。表 5测试级别与测试类型的对应关系测试类型测试级别备注单元测试集成测试系统测试系统集成测试验收测试功能测试性能测试可靠性测试安全性测试JR/T 0175201912表 5测试级别与测试类型的对应关系（续）测试类型测试级别备注单元测试集成测试系统测试系统集成测试验收测试可移植性测试可维护性测试应急演练联网测试全市场测试验收测试完成后，进入上线准备阶段，应和系统的关联方进行全市场测试。在采购前期或采购

43、过程中实施，不对应任何测试级别。各个测试级别的具体描述见59章。4.5测试准入/准出要求4.5.1准入要求在测试执行前，应达到准入要求后，才可展开测试执行。测试准入要求如下：a)上一个测试级别达到准出要求；b)测试计划已经通过审核；c)测试用例设计完成并通过审阅；d)测试用例已完全 100%覆盖测试需求；e)阻碍进一步测试的问题已经解决，如冒烟测试通过；f)测试环境（软件、硬件）搭建完成、测试工具已安装配置完成，发布的程序代码已经被安装到测试环境中。4.5.2准出要求测试执行阶段的准出将标志着整个测试实施过程的结束，故该阶段的准出要求主要关注以下三个方面：a)用例执行情况；b)缺陷解决情况；c

44、)系统质量情况。具体的测试准出要求见表6，可根据不同的测试级别进行调整。表 6测试执行准出要求测试类型测试类型准出要求准出要求功能测试a)计划实施的测试范围 100%覆盖；b)计划执行的测试用例 100%执行完成，未执行的用例已写明原因；c)所有提交的缺陷都被记录并有最终状态，测试执行结束后仍未修复完成的缺陷作为遗留缺陷在测试报告中记录说明未修复原因及修复计划；d)缺陷整体呈收敛；经过讨论确认应修改的缺陷均已修复。JR/T 0175201913表 6测试执行准出要求（续）测试类型测试类型准出要求准出要求性能测试a)测试执行情况：可执行场景 100%执行完毕，未执行场景均有相关说明并评审通过；b

45、)缺陷解决情况：无非最终状态缺陷；c)监控指标情况：监控并收集了用户关注的关键的资源指标和系统指标，其中资源指标包括 CPU、内存、I/O、带宽等，系统指标包括并发用户数、响应时间、事务成功率、超时错误率等；d)测试报告情况：清晰的评价系统当前性能，判断系统满足预期性能需求的情况；指出系统可能存在的性能问题，定位性能瓶颈；判定系统性能表现，预见系统负载压力承受力；e)测试工具情况：使用既有工具的，需确保测试脚本在当前系统版本条件下可反复稳定运行；自行研发工具的，需确保测试工具至少可产生系统最大承载力 1 倍及以上的压力，在常规压力条件下至少可稳定加压 1 小时以上，至少具备响应时间和事务成功率

46、等指标的监控能力。可靠性测试a)测试执行情况：可执行的测试场景全部执行完毕，未执行场景均有相关说明并评审通过；b)缺陷解决情况：无非最终状态缺陷；c)系统及组件的容错、恢复能力和成熟性指标满足需求；d)系统灾备处理能力满足需求。安全性测试a)安全性测试整体要求：应完成代码级安全漏洞扫描、系统级安全漏洞扫描，可选完成拒绝服务式攻击测试；b)代码级安全漏洞扫描：至少覆盖 OWASP Top 10、CWE、SANS 等安全静态标准，并给出不合规代码的修复建议；c)系统级安全漏洞扫描：至少覆盖了 CVE 已发现的安全漏洞以及隐患漏洞，对于关键性的严重级别漏洞应通过渗透测试验证；d)拒绝服务式攻击测试：

47、至少完成资源比拼型（ICMP Flood、ACK Flood、Connection Flood）、软件缺陷利用型（SYN Flood、ARP Spoof、Ping of Death）等类型的拒绝服务式攻击测试，并针对被测系统表现情况给出改善建议。可移植性测试a)测试执行情况：可执行的测试场景全部执行完毕，未执行场景均有相关说明并评审通过；b)缺陷解决情况：无非最终状态缺陷；c)软件的安装/升级程序、安装/升级文档齐全，按照安装文档的指导能正确安装/升级程序；d)软件能在其支持的所有硬件平台、操作系统、网络环境中安装/升级、使用。可维护性测试a)软件系统的需求、设计等过程文档清晰规范，不存在引起

48、歧义的描述；相应的专家评审意见均需确认且不存在遗留未修改的问题；b)软件的代码实现规范，注释描述清晰，注释率不低于 20%，函数、类、全局变量以及逻辑复杂的代码段、算法等应有相应注释；c)每个函数最大代码行不超过 1000 行（非空、非注释行）；圈复杂度不超 10，如有必要超过的情况应经相关专家评审通过。应急演练a)应急方案演练成功；b)未发现重大缺陷或发现缺陷已经处理完成。联网测试a)接口联网测试成功；b)未发现重大缺陷或发现缺陷已经处理完成。全市场测试a)全市场联网测试成功；b)未发现重大缺陷或发现缺陷已经处理完成。JR/T 0175201914表 6测试执行准出要求（续）测试类型测试类型

49、准出要求准出要求选型测试a)测试执行情况：所有测试场景全部执行完毕，每个测试场景在不同备选竞品上均执行完毕且不存在测试场景只运行在某个或某几个备选竞品的情况，未执行场景均有相关说明并评审通过；b)测试报告情况：竞品评定指标数据均采集完成，未填写项均有相关说明并评审通过；清晰地阐述竞品指标执行步骤和指标结果，对相同指标项应明确写出不同备选竞品的测试数据差异。4.6测试管理4.6.1角色职责从测试级别和测试类型的角度，描述在相关测试活动中的责任主体和参与者，如表7、表8所示。表 7测试级别参与团队测试级别测试级别责任主体责任主体单元测试单元测试开发团队。集成测试集成测试系统测试系统测试测试团队。系

50、统集成测试系统集成测试验收测试验收测试需求提出方、市场服务机构。表 8测试类型参与团队测试类型测试类型责任主体责任主体参与者参与者功能测试功能测试需求提出方、开发团队、测试团队。需求提出方、开发团队、测试团队、运维团队及供应商等干系人。性能测试性能测试可靠性测试可靠性测试安全性测试安全性测试可移植性测试可移植性测试可维护性测试可维护性测试应急演练应急演练需求提出方、运维团队。测试发起方或组织方应根据实际的业务需求和测试需求选择必要的关联方参与测试。关联方主要包括但不限于市场核心机构、市场经营机构、市场服务机构等市场各参与方。联网测试联网测试全市场测试全市场测试选型测试选型测试需求提出方、运维团