JR/T 0175-2019
标准分类号
标准ICS号:
社会学、 服务、公司(企业)的组织和管理、行政、运输>>03.060金融、银行、货币体系、保险
中标分类号:综合>>经济、文化>>A11金融、保险
关联标准
相关单位信息
起草人:张野、刘铁斌、蒋东兴、周云晖、马晨等
起草单位:中国证券监督管理委员会信息中心、中国证券监督管理委员会证券基金机构监管部、大连商品交易所、上海证券交易所、深圳证券交易所、上海期货交易所、郑州商品交易所、中国金融期货交易所、证券期货业信息技术测试中心(大连)、中国银河证券股份有限公司等
归口单位:全国金融标准化技术委员会(SAC/TC180)
提出单位:全国金融标准化技术委员会证券分技术委员会(SAC/TC180/SC4)
发布部门:中国证券监督管理委员会
主管部门:全国金融标准化技术委员会(SAC/TC180)
标准简介
标准号:JR/T 0175-2019
标准名称:证券期货业软件测试规范
英文名称:Specification for securities and futures industry software test
标准格式:PDF
发布时间:2019-09-30
实施时间:2019-09-30
标准大小:1.16M
标准介绍:本标准规定了证券期货业信息系统建设过程中的总体要求、单元测试、集成测试、系统测试、系统集成测试、验收测试等测试活动的内容。
本标准适用于证券期货业市场核心机构(以下简称市场核心机构)、证券期货基金经营机构(以下简称市场经营机构)、证券期货信息技术服务机构(以下简称市场服务机构)开展证券期货业计算机软件和外部信息系统测试工作
注1:市场核心机构,如证券期货交易所、证券登记结算机构、期货市场监控中心等
注2:市场经营机构,如证券公司、期货公司、基金公司等
注3:市场服务机构,如软件开发商、信息商、服务商等
2规范性引用文件
下列文件对于本文件的应用是必不可少的。凡是注日期的引用文件,仅所注日期的版本适用于本文件。凡是不注日期的引用文件,其最新版本(包括所有的修改单)适用于本文件
GB/T11457-2006信息技术软件工程术语
GB/T15532-2008计算机软件测试规范
GB/T29834.3-2013系统与软件维护性第3部分:测试方法
2016资本市场交易结算系统核心技术指标
本标准按照GB/T1.1-2009给出的规则起草。
本标准由全国金融标准化技术委妈会证券分技术委员会(SAC/TC180/SC4)提出
本标准由全国金融标准化技术委员会(AC/TC180)归口
本标准起草单位:中国证券监督管理委员会信息中心、中国证券监督管理委员会证券基金机构监管部、大连商品交易所、上海证券交易所、深圳证券交易所、上海期货交易所、郑州商品交易所、中国金融期货交易所、证券期货业信息技术测试中心(大连)、中国银河证券股份有限公司、南方基金管理有限公司。
本标准规定了证券期货业信息系统建设过程中的总体要求、单元测试、集成测试、系统测试、系统集成测试、验收测试等测试活动的内容。
本标准适用于证券期货业市场核心机构、证券期货基金经营机构、证券期货信息技术服务机构开展证券期货业计算机软件和外部信息系统测试工作。
注 1:市场核心机构,如证券期货交易所、证券登记结算机构、期货市场监控中心等;
注 2:市场经营机构,如证券公司、期货公司、基金公司等;
注 3:市场服务机构,如软件开发商、信息商、服务商等。
本标准按照GB/T 1.1-2009给出的规则起草。
本标准由全国金融标准化技术委员会证券分技术委员会(SAC/TC180/SC4)提出。
本标准由全国金融标准化技术委员会(SAC/TC180)归口。
本标准起草单位:中国证券监督管理委员会信息中心、中国证券监督管理委员会证券基金机构监管部、大连商品交易所、上海证券交易所、深圳证券交易所、上海期货交易所、郑州商品交易所、中国金融期货交易所、证券期货业信息技术测试中心(大连)、中国银河证券股份有限公司、南方基金管理有限公司。
本标准主要起草人:张野、刘铁斌、蒋东兴、周云晖、马晨、高红洁、王恺、郭郛、陈楠、王凤海、许强、胥海涛、刘军、孙瑞超、陆素源、蒋凯、陈彦、喻华丽、万春波、顾军妹、陈亮、邹杏忠、徐玲、于三禄、刘相富、鲁继东、戴鹏、刘进、汪璇璇、董琳、徐艳、刘洁如、韩秀玲、邓志远、刘丹、唐沛来、邓廷勋、邱星、牛云峰。
下列文件对于本文件的应用是必不可少的。凡是注日期的引用文件,仅所注日期的版本适用于本文件。凡是不注日期的引用文件,其最新版本(包括所有的修改单)适用于本文件。
GB/T 11457-2006 信息技术 软件工程术语
GB/T 15532-2008 计算机软件测试规范
GB/T 29834.3-2013 系统与软件维护性 第3部分:测试方法
JR/T 0145-2016 资本市场交易结算系统核心技术指标
前言 III
引言 IV
1 范围 1
2 规范性引用文件 1
3 术语和定义 1
4 总体要求 2
5 单元测试 17
6 集成测试 18
7 系统测试 20
8 系统集成测试 21
9 验收测试 21
附录 A(规范性附录) 测试流程24
A1 测试估计 24
A2 测试计划 24
A3 测试设计 24
A4 测试执行 26
A5 测试报告 26
附录 B(资料性附录)软件测试模板28
B1 测试工作量估计书28
B2 测试计划 29
B3 测试需求 30
B4 测试用例 31
B5 测试缺陷列表 32
B6 评审记录 33
B7 测试总结报告 33
B8 管理者报告 35
B9 里程碑总结报告 36
附录 C(规范性附录)测试技术38
C1 黑盒测试 38
C2 白盒测试 44
C3 灰盒测试 45
附录 D(规范性附录)静态测试方法46
D1 概述 46
D2 评审 46
附录 E(规范性附录)业务分类49
附录 F(规范性附录)缺陷管理50
F1 缺陷管理目的 50
F2 缺陷管理的生命周期50
F3 缺陷管理流程图52
F4 缺陷严重度划分53
F5 缺陷优先级划分53
F6 根本原因举例 53
参考文献 55
标准内容
ICS03.060
TiikAa~cJouakAa
中华人民共和国金融行业标准
JR/T 0175—2019
证券期货业软件测试规范
Specification for securities and futures industry software test2019-09-30发布
中国证券监督管理委员会
2019-09-30实施
TiiKAa~cJouaKAa-
引言,
2规范性引用文件
3术语和定义..
4总体要求...
5单元测试
6集成测试.
7系统测试.
8系统集成测试.
9验收测试.
附录A(规范性附录)
A.1测试估计...
A.2测试计划.
A.3测试设计.
A.4测试执行..
A.5测试报告
iikAa~cJouakAa-
测试流程,
附录B(资料性附录)软件测试模板B.1测试工作量估计书.
B.2测试计划
B.3测试需求
B.4测试用例...
B.5测试缺陷列表.
B.6评审记录....
B.7测试总结报告.
B.8管理者报告
B.9里程碑总结报告
附录C(规范性附录)测试技术
C.1黑盒测试.
C.2白盒测试..
C.3灰盒测试
附录D(规范性附录)静态测试方法D.1概述
D.2评审.
JR/T0175—2019
JR/T0175—2019
iiKAa~cJouakAa-
附录E(规范性附录)业务分类
附录F(规范性附录)缺陷管理
F.1缺陷管理目的..
F.2缺陷管理的生命周期..
F.3缺陷管理流程图..
F.4缺陷严重度划分.
F.5缺陷优先级划分.
F.6根本原因举例.
参考文献
TiiKAacJouaKAa
本标准按照GB/T1.1-2009给出的规则起草,本标准由全国金融标准化技术委员会证券分技术委员会(SAC/TC180/SC4)提出。本标准由全国金融标准化技术委员会(SAC/TC180)归口。JR/T0175—2019
本标准起草单位:中国证券监督管理委员会信息中心、中国证券监督管理委员会证券基金机构监管部、大连商品交易所、上海证券交易所、深圳证券交易所、上海期货交易所、郑州商品交易所、中国金融期货交易所、证券期货业信息技术测试中心(大连)、中国银河证券股份有限公司、南方基金管理有限公司。
本标准主要起草人:张野、刘铁斌、蒋东兴、周云晖、马晨、高红洁、王恺、郭郭、陈楠、王凤海、许强、胥海涛、刘军、孙瑞超、陆素源、蒋凯、陈彦、喻华丽、万春波、顾军妹、陈亮、邹杏忠、徐玲、于三禄、刘相富、鲁继东、戴鹏、刘进、汪璇璇、董琳、徐艳、刘洁如、韩秀玲、邓志远、刘丹、唐沛来、邓廷勋、邱星、牛云峰。
JR/T0175—2019
iiKAacJouaKAa
证券期货业市场的发展和平稳运行高度依赖行业信息系统。规范统一行业信息系统的测试标准,有助于规范行业信息系统的测试管理,提高行业软件测试过程的规范化程度,促进行业软件测试水平整体提升,从而降低行业信息系统运行风险,促进证券期货业的可持续性健康发展。本标准具有鲜明的行业特征,将行业经验、实践与测试理论紧密结合,使标准更加易于落实和实施能够有效指导行业软件测试活动、提高测试质量,其中:a)测试管理与测试流程基于《CMMI软件能力成熟度集成模型》和《TMMI测试成熟度模型》编制,并在此基础上提供以下适应行业特点的内容:1)提供各测试阶段的工作要求,更细致地指导测试工作开展,见4.2.1:明确各测试文档规范、基本内容并提供参考模板,见4.2.2及附录B;2)
提供测试管理细则,明确各项管理工作具体要求和实施内容,以便测试管理工作切实开展,3)
见4.6;
针对行业特点细化测试流程中各阶段工作内容及要求,见附录A;4)
细化各测试类型及测试级别的测试准入/准出要求,用于更加细致地指导测试具体工作,5)
见4.5、5.5、6.5、7.5、8.5、9.5。系统内容与测试类型、测试级别与测试类型的基本要求遵循GB/T15532-2008《计算机软件测b)
试规范》并根据行业特点明确以下关系:系统内容与测试类型之间的关系,便于行业机构根据软件产品可能涉及的测试内容选择适1
合的测试类型,同时增加应急演练、联网测试、全市场测试及选型测试四个测试类型。2)
测试级别与测试类型的对应关系,便于行业机构根据其角色、软件产品特点等实际情况,选择适合的测试级别和测试类型,确保行业机构履行测试工作职责、保证软件产品质量。c)本标准内容符合JR/T0146-2016(所有部分)《证券期货业信息系统审计指南》系列标准中与软件测试相关的审计要求
1范围
iiKAacJouaKAa
证券期货业软件测试规范
JR/T0175—2019
本标准规定了证券期货业信息系统建设过程中的总体要求、单元测试、集成测试、系统测试、系统集成测试、验收测试等测试活动的内容。本标准适用于证券期货业市场核心机构(以下简称市场核心机构)、证券期货基金经营机构(以下简称市场经营机构)、证券期货信息技术服务机构(以下简称市场服务机构)开展证券期货业计算机软件和外部信息系统测试工作。注1:市场核心机构,如证券期货交易所、证券登记结算机构、期货市场监控中心等:注2:市场经营机构,如证券公司、期货公司、基金公司等;注3:市场服务机构,如软件开发商、信息商、服务商等。规范性引用文件
下列文件对于本文件的应用是必不可少的。凡是注日期的引用文件,仅所注日期的版本适用于本文件。凡是不注日期的引用文件,其最新版本(包括所有的修改单)适用于本文件。GB/T11457-2006信息技术软件工程术语GB/T15532-2008计算机软件测试规范GB/T29834.3-2013系统与软件维护性第3部分:测试方法JR/T0145-2016资本市场交易结算系统核心技术指标3术语和定义
GB/T11457-2006界定的以及下列术语和定义适用于本文件。为了便于使用,以下重复列出了GB/T11457-2006中的某些术语和定义3.1
测试级别testlevel
根据软件开发的生命周期、测试对象及测试人员的不同,将软件生命周期中的测试活动分为不同的级别。
测试流程testprocess
二个完整的测试任务按顺序经历的过程。3.3
测试用例testcase
为特定目标编写的测试输入、执行操作及期望结果的集合。注:改写GB/T11457-2006,定义2.16953.4
测试轮次testcycles
项目中在一个完整、全量发布版本上将项目计划的所有可执行用例执行一遍的次数。1
JR/T0175—2019
iiKAacJouakAa
通关测试production readiness test新系统、新业务、新产品上线启用前,由市场核心机构组织并由全市场参与者共同参与,在生产环境上模拟系统/业务/产品上线首日行为的测试。3.6
第三方测试机构the thirdparty testing institute处于用户和产品开发商利益之外、根据有关标准或规范对产品进行客观质量检验的专业测试机构。3.7
裁剪 tailor
对相关测试活动、测试方法、测试内容、测试类型、测试输出文档等进行调整、增加、删除、替换、顺序变更等。
4总体要求
4.1测试目的
验证软件满足软件开发合同、系统/子系统设计文档、系统需求规格说明书、系统设计说明书、产品说明书、运维手册和操作手册等软件质量要求通过测试发现软件缺陷,为软件产品的质量评价提供依据。4.2测试流程
4.2.1测试阶段的工作要求
各测试级别、测试类型的测试应遵循此测试流程。此测试流程分为测试估计、测试计划、测试设计、测试执行、测试报告五个阶段,各阶段的活动、输入输出见附录A。各测试阶段应遵守的工作要求见表1。表1工作要求
测试阶段
测试估计
测试计划
工作要求
a)功能测试和非功能测试的测试范围合理、覆盖全面、无允余b)估计工作量时,测试策略选择合理、有效;c)功能测试及非功能测试均完成测试工作量估计,且有充分的估计依据:d)如有测试工具开发、验收测试支持、测试管理等其他工作,均完成测试工作量估计,且有充分的估计依据。
a)明确功能与非功能的测试范围、测试策略、测试执行的准入/准出要求:b)测试策略与测试工作量估计书中的测试策略存在明显差异时,应有合理的解释说明:C)详细测试进度安排合理、里程碑时间点明确,避免测试不足或过度测试d)测试环境部署策略符合系统规划要求,使用的测试工具名称、版本和用途描述清晰;e)明确在测试活动中可能发生的风险及其影响和应急措施:f)明确测试过程中的问题管理流程、变更管理流程、进度管理流程、缺陷管理流程测试阶段
测试设计
测试执行
测试报告
TriKAa~cJouaKAa
表1工作要求(续)
工作要求
JR/T0175—2019
a)测试需求:应100%覆盖业务需求和系统需求规格说明书,并适当参考相关开发设计文档b)测试用例:应100%覆盖测试需求或按照测试级别不同100%覆盖相关设计、需求文档,如单元测试、集成测试覆盖相关开发设计文档,系统测试覆盖系统需求规格说明书等:c)非功能测试场景的设计中充分考虑可能产生影响的业务数据量,且在真实生产环境下有效、在测试环境下可测。
a)明确记录每条测试用例的执行结果,未执行的用例应写明未执行原因;b)对于核心、重要的系统及功能应对测试执行过程以截图或者保留日志的方式进行留痕:c)执行过程中发现的缺陷及问题,应及时记录在缺陷管理工具或者缺陷列表中,并进行及时处理,测试结束后无非最终状态的缺陷。a)明确功能及非功能的测试范围,如与测试计划中存在差异,可进行解释说明:b)明确测试结论,从功能及非功能角度分别描述具体的通过标准及实际测试结果,给出是否通过的结论:
c)写明测试环境部署情况,测试环境与生产环境的差异分析d)明确测试版本、测试执行情况、对缺陷进行汇总及分析:e)进行改善建议、经验教训总结,为后续工作提供参考。测试文档规范
各测试阶段的输出文档,宜包括的基本内容见表2,可根据实际需要适当裁剪,具体模板参见附录B。
表2文档的基本内容
测试估计
测试计划
测试设计
测试执行
测试报告
测试管理
输出文档
测试工作量估计书
测试计划
测试需求
测试用例
测试缺陷列表
测试执行结果
测试总结报告
管理者报告
里程碑总结报告
文档的基本内容
各系统模块的测试设计复杂度、测试执行复杂度、测试用例估计个数、测试设计工作量、测试执行工作量、非功能测试工作量等,测试目标、测试范围、测试策略、测试进度计划、测试环境、测试方法、测试管理、测试报告等。
需求功能、验证点、验证方式等。测试用例ID、优先级、场景说明、方法/函数、正常系/异常系、前提条件、测试目的、测试步骤、测试数据、期望结果等。缺陷ID、缺陷描述、再现步骤、期望结果、实际结果、测试轮次、测试类型、发现版本、发现日期、缺陷负责人、缺陷提交人、严重度、优先级、缺陷状态、根本原因、解决方案、关闭日期等。测试用例的实际执行结果、通过或不通过、对应的缺陷ID、测试人员、实际测试日期、测试步骤截图等。
测试范围、测试结论、测试环境与生产环境的差异分析、功能测试/非功能测试执行情况、缺陷汇总及遗留问题分析、测试结果分析、经验教训、改善建议等、进度情况、工作量偏差、质量目标达成情况、风险与问题等,里程碑的进度、成本和质量情况、风险与问题、经验教训、改善建议等。3
JR/T0175—2019
4.3测试类型
4.3.1功能测试
iiKAacJouaKAa
功能测试的主要目的、测试内容及测试技术如下:a)自的
以系统需求规格说明书为依据对其中要求的功能实现、业务操作等系统功能特性进行验证,目的是确保系统在指定的条件下满足客户的功能性和易用性要求。b)
测试内容/关注点
测试内容关注点包含实现的功能正确、不存在无用的功能和不存在功能的遗漏,具体如下1)实现的功能正确:与系统需求规格说明书上要求的功能一致:2)不存在无用的功能:实现的功能范围未超出系统需求规格说明书描述的范围;3)不存在功能的遗漏:实现的功能范围能完全覆盖系统需求规格说明书描述的范围。c)
测试技术
以黑盒测试技术为主,灰盒测试技术为辅。本标准中提及的黑盒测试技术、白盒测试技术及灰盒测试技术见附录C。4.3.2性能测试
性能测试的主要目的、测试内容及测试技术如下:a)目的
通过模拟真实、高压力等各种负载条件的业务场景,对系统的各项性能指标进行评估,通常包括负载测试、压力测试、容量测试、业务响应时间测试等。测试内容/关注点
测试内容/关注点包含负载测试、压力测试、容量测试和业务响应时间测试,具体如下:1)负载测试:对系统不断地增加压力或持续保持最大安全负载,直到系统的某项或者多项性能指标达到安全临界值(例如某种资源已经达到饱和状态等),获得系统在不同负载条件下的性能指标:
2)压力测试:超过安全负载的情况下,对系统不断地施加压力,通过确定一个系统的瓶颈或不能接收用户请求的性能点,来获得系统可提供的最大服务级别的测试:3)
容量测试:使用反映系统容量特征的极限值(如最大并发用户数、数据库记录数等)对系统施加压力,通过观察系统在极限容量状态下没有出现任何软件故障或还能保持主要功能正常运行来检测系统的容量指标:4)业务响应时间测试:被测系统在稳定压力持续运行过程中或达到一定容量后进行业务操作,记录系统处理所花费的时间,以此检测业务响应时间符合性能需求。c)测试技术
具体如下:
1)负载测试、压力测试和业务响应时间测试的测试方法是通过模拟单用户和多用户并发的场景,获取软件系统功能处理的延时、吞吐率及处理时间。利用自动化测试工具进行数据构造、负载压力构造,通常选择具有代表性或者核心业务的模块、访问量较高的业务构造各种性能测试场景,从而进行单机性能测试或并发性能测试。测试指标包括订单峰值吞吐速率、成交峰值吞吐速率、订单持续吞吐速率、成交持续吞吐速率、订单处理延时、日结算处理能力等;
TiiKAacJouaKAa
JR/T0175—2019
2)容量测试的测试方法是在不同的系统配置以及不同的业务场景下构造相应的容量数据,评估系统的极限容量和硬件资源占用率。其中,极限容量包括最大用户数、最大处理量、最大事务数(执行单元)、最大吞吐率、最大文件容量等:硬件资源占用率包括内存、CPU、硬盘、网络带宽、设备等。测试指标包括日订单处理容量、日成交处理容量等。4.3.3可靠性测试
可靠性测试的主要目的、测试内容及测试技术如下:a)目的
可靠性测试是通过模拟系统可能出现的各种异常或故障等场景,来验证系统在异常处理、故障容错、数据恢复及容灾等方面的能力,并对系统的可靠性进行评估,目的是确保系统在特定的环境部署条件下满足高可用性要求,通常包括成熟性测试、容错性测试、稳定性测试和可恢复性测试。
测试内容/关注点
测试内容/关注点包含成熟性测试、容错性测试、稳定性测试和可恢复性测试,具体如下:成熟性测试:当软件系统中出现代码判断错误、集成中的接口错误、通讯报文错误、系1
统中业务逻辑错误以及其他在设计、开发等环节中造成的错误时,验证系统能消除错误造成的影响并仍可正常工作;
容错性测试:当引入外部错误,如违规操作、删除数据、强行终止等严重的行为使系统(包2
括硬件、软件及附属程序)发生异常时,验证系统在异常情况下应具有防护性措施(处理异常的方法包括:系统自动处理和人工干预处理):稳定性测试:通过持续性测试的方法验证系统在一定压力下长时间运行的稳定性:3
可恢复性测试:系统在失效状态下,恢复至正常状态的能力。失效状态应是系统崩溃或4)bzxZ.net
者岩机停止所有功能,而不是带故障的运行状态;正常状态应是至少保证系统的主要功能可全部运行。获取系统恢复时间(RTO)、数据恢复时间(RPO),RTO、RPO定义见JR/T0145-2016。
c)测试技术
具体如下:
1)成熟性测试、容错性测试的测试方法是通过人工模拟故障场景,如进程崩溃及挂起、网络断开及延迟、服务器岩机等场景,或通过工具或手工制造异常操作或异常数据输入等,验证系统或组件在出现故障时进行有效处理的能力:稳定性测试的测试方法是7*24小时压力测试,即仿照生产的业务配比关系,根据实际生2
产需要,保持不同倍数下单压力,每天运行被测系统24小时,连续运行7天。在测试期间可通过查看系统进程状态、执行功能操作、查看运行日志信息的方式来验证系统运行状态的正确性:
3)可恢复性测试的测试方法是模拟在出现故障或灾难导致系统失效时,通过分析系统日志或流水计算得到系统恢复时间(RTO)和数据恢复时间(RPO)指标。4.3.4安全性测试
安全性测试的主要目的、测试内容及测试技术如下:a)目的
通过安全测试手段和方法,验证软件的安全特性实现与预期一致、检验软件产品对各种攻击情况的防范能力,从而保障产品的安全质量。5
JR/T0175—2019
测试内容/关注点
具体如下:
iiKAacJouaKAa
配置管理:按照信息安全等级保护要求对操作系统、应用程序、数据库、网络设备等进1)
行安全配置;
资源利用:应用程序内存使用和资源竞合问题,如变量未初始化、数组越界、内存溢出、资源泄露、进程线程异常等:
身份鉴别:对登录操作系统、数据库系统和应用系统的用户进行了身份标识和鉴别,如3)
应使用强密码策略、限定连续登录尝试次数、使用有效验证码等;4)
访问控制:用户应根据自已的权限大小来访问系统资源(如服务器、自录、文件等),不得越权访问:
数据保护:应用程序存储敏感信息的情况,存储的敏感信息应进行加密,包含但不限于密码、密钥等敏感信息应加密写入缓存、文件系统、数据库中等;6)
通信安全:应用程序使用安全通信协议(如SSL、TLS)的情况,对敏感信息的传输应进行加密等:
会话管理:本地及服务器端对会话超时的设置,会话结束后应用程序使用过的敏感信息7)
应从内存中删除,合法用户的会话不被劫持等;数据验证:应用程序在使用前正确验证来自客户端或外界输入数据的情况,避免发生如8)
跨站脚本攻击、命令注入、文件注入、SQL注入等漏洞:安全审计:对网络系统中的网络设备运行状况、网络流量、用户行为等进行日志记录;9)
审计记录应包括事件的日期和时间、用户、事件类型、事件成功及其他审计相关的信息等。
c)测试技术
常见的安全性测试技术有安全功能检查、代码安全测试、漏洞扫描、渗透测试和模糊测试,具体如下:
安全功能检查是指测试人员通过对相关系统管理人员进行访谈和对测试对象(如相关系1
统、各类设备、基线标准、开发设计文档)进行观察、验证、分析以确认测试对象符合信息安全等级保护、相关信息安全要求以及安全功能需求的过程2)
代码安全测试分为静态检测和动态检测。静态检测是使用代码检测软件进行代码静态扫描,并对扫描后结果进行人工分析来发现定位漏洞的过程;动态检测即在运行时进行错误检查,主要通过将已经写好的程序转换成一个新程序(其功能与原程序是等价的),新程序包含有一些额外的代码,它们的作用是在程序执行期间检查错误;漏洞扫描是指利用专业的漏洞扫描工具,基于公共漏洞和暴露(CVE)漏洞数据库或特征3)
库,通过扫描、探测等方法对目标系统的安全情况进行检测,发现可利用的漏洞;渗透测试是通过模拟恶意黑客的攻击方法对目标系统进行模拟入侵,以找出系统中的脆4)
弱点、技术缺陷和漏洞;
模糊测试是一种通过提供非预期的输入并监视异常结果来发现软件故障的方法,是一个5)
自动的或半自动的过程,通常包括识别目标、识别输入、生成模糊测试数据、执行模糊测试、监视异常、确定可利用性等阶段。4.3.5可移植性测试
可移植性测试的主要目的、测试内容及测试技术如下:a)目的
小提示:此标准内容仅展示完整标准里的部分截取内容,若需要完整标准请到上方自行免费下载完整标准文档。