1
软件测试规范
XXX 信息技术有限公司
编号 修订人 修订时间 版本号 修订内容说明
文档编号
版 本 号
密 级 内部使用
2
1
2
3
4
5
6
7
8
9
10
目录
1、范围 ......................................................................................................................................4
2、规范性引用文件 ..................................................................................................................4
3、总则 ......................................................................................................................................5
、目的 ...............................................................................................................................5
3
、产品的质量特性及测试范围 .......................................................................................5
、测试类别 .......................................................................................................................6
、质量特性与测试类别的关系 .......................................................................................6
、测试工具 .......................................................................................................................6
、测试工具分类 ........................................................................................................6
、测试工具选择 ........................................................................................................7
、测试项目过程 ...............................................................................................................7
、测试项目结构 ...............................................................................................................8
、测试文档 .......................................................................................................................8
4、测试过程 ..............................................................................................................................9
、流程图及说明 ...............................................................................................................9
、测试类型流程图及准入准出 .....................................................................................10
单元测试 .................................................................................................................10
集成测试 .................................................................................................................10
系统测试 .................................................................................................................12
验收测试 .................................................................................................................13
5、测试管理 ............................................................................................................................13
、人员管理 .....................................................................................................................13
、测试挂起、恢复与终止 .............................................................................................14
测试挂起 ................................................................................................................14
测试恢复 ................................................................................................................14
测试终止 ................................................................................................................15
处罚标准 .................................................................................................................15
、BUG 管理 ....................................................................................................................15
缺陷严重等级划分 ................................................................................................15
缺陷响应时间 ........................................................................................................17
缺陷管理流程 ........................................................................................................17
6、产品上线判定准则 ............................................................................................................18
、测试判定准则 .............................................................................................................18
测试项结果判定定义 .............................................................................................18
4
测试类结果判定原则 .............................................................................................18
、产品上线评价准则 .....................................................................................................19
7、专业测试人员与非专业测试人员 ....................................................................................19
项目或产品由非测试人员进行产品测试的判定 ........................................................19
附录：产品质量名词说明 ......................................................................................................20
5
1、范围
本规范规定了 XXX 公司的各产品、项目在软件开发生命周期内的基本测试方法、过程和
准则。
2、规范性引用文件
计算机软件测试规范 GB/T15532-2008
软件工程 产品质量 GB 16260-2006
计算机软件测试文档编制规范 GB/T 9386-2008
软件评审标准 IEEE Std 1028-2008
中国人民银行《非金融机构支付服务系统技术标准符合性和安全性检测规范》
内部标准：标准委员会制定的项目划分标准
3、总则
、目的
验证软件是否满足软件开发合同或项目开发计划、系统／子系统设计文档、软件需求规
格说明、软件设计说明和软件产品说明等规定的软件质量要求；
通过测试，发现软件缺陷；
为软件产品的质量测量和评价提供依据。测试类别（单元测试、集成测试、系统测试、
验收测试）
、产品的质量特性及测试范围
产品质量特性
产品架构 特定质量要求 基本质量要求
C 端应用 易用性、可移植性（适应性）、中文特性
行业产品 易用性、可移植性（适应性）、中文特性
基础产品 维护性、中文特性、可移植性（适应性）
平台 易用性、维护性、可移植性
外包&第三方产品 易用性、可移植性（适应性）、中文特性
功能性
可靠性
效率
安全性（WEB）
标准符合性（央行
行业标准）
6
举例：
C 端应用： 信用卡还款、手机充值
行业产品： 信用支付、ePOS
基础产品： 委托结算、商户后台（新/老）
平 台： oltp、olap
外包&第三方： 基金
测试范围
已有产品测试范围：
C 端：开放平台
行业产品： ePOS、集团账户、教育线产品、保险理赔通、外卡、航空线信用支付、航
空线风控平台
基础产品：委托结算、新商户后台、老商户后台、风控系统
平台：支付、boss 后台的一部分
第三方&外包：预付费卡、供应链融资、基金
注：以上内容为举例，不代表质量部的完整测试范围。具体范围可参考本部门定期维护
的测试范围表。
测试范围外或未来产品，必须要纳入质量部测试范围的条件（满足一条即可成立）：
1. 日平均交易额度高于 100 万。
2. 产品出现问题后会导致“致命”级缺陷。
3. 产品出现问题后将影响其他产品线。
注：如产品线有响应速度的要求，而质量部现有资源不能满足，则需要由产品线增加测
试人员。
、测试类别
本标准对如下测试类别作详细描述：
单元测试；
集成测试；
系统测试（功能测试、性能测试、安全性测试、兼容性测试）；
验收测试（功能测试、性能测试、安全性测试、兼容性测试）。
可根据软件的规模、类型、完整性级别选择执行测试类别。
回归测试可出现在上述每个测试类别中，并贯穿于整个软件生存周期，故单独分类进行
描述。
、质量特性与测试类别的关系
测试类别 质量特性
功能性单元测试
集成测试 维护性
7
系统测试-功能测试
可靠性系统测试-性能测试
效率
可移植性单元测试
系统测试-功能测试
系统测试-兼容性测试
中文特性
系统测试-易用性测试 易用性
系统测试-安全性测试 应用安全（WEB）
、测试工具
、测试工具分类
软件测试工具可分为测试执行工具和支持测试活动的工具，每类测试工具在功能和其他
特征方面具有相似之处，支持一个或多个测试活动。应根据测试要求选择合适的工具。
工具类型 功能和质量要求 测试工具 备注
功能性、可维护性 QTP、Selenium 提高测试效率减少人员投
入，使用自动化测试工具
可靠性、效率 Loadrunner 针对测试对象的性能和效
率进行性能压力测试
测试执行工具
应用安全（WEB） APPScan 针对安全性进行安全工具
扫描测试
支持测试过程活
动的工具
支持测试计划、测试设计、
缺陷管理整个测试过程的
工具
QC、JIRA 对于缺陷的管理、测试设
计工作的管理
、测试工具选择
软件测试应尽量采用测试工具，避免或减少人工工作。为让工具在测试工作中发挥应有
的作用，应确定工具的详细需求，并制定统一的工具评价、采购(开发)、培训、实施和维护
计划。
选择软件测试工具应考虑如下因素：
软件测试工具的需求及确认：
a) 应明确对测试工具的功能、性能、安全性等需求，并据此进行验证或确认；
b) 可通过在实际运行环境下的演示来确认工具是否满足需求，演示应依据工具的功能
和技术特征、用户使用信息（安装和使用手册等）以及工具的操作环境描述等进行。
成本和收益分析：
a) 估计工具的总成本，除了最基本的产品价格，总成本还包括附加成本，如工具的挑
选、安装、运行、培训、维护和支持等成本，以及为使用工具而改变测试过程或流
程的成本等；
8
b) 分析工具的总体收益，如工具的首次使用范围和长期使用前景、工具应用效果、与
其他工具协同工作所提高的生产力程度等。
测试工具的整体质量因素：
a) 易用性；
b) 互操作性；
c) 稳定性；
d) 经济实用性；
e) 维护性；
、测试项目过程
大型项
目
中型项
目
小型项
目
微型项
目
BUG 修
改
需求确认 √ √ √ √ Ⅹ
测试计划、测试方案 √ √ √ ○ Ⅹ
测试策
划
测试计划、方案评审 √ √ √ Ⅹ Ⅹ
测试用例 √ √ √ ○ ○测试准
备 测试用例评审 √ √ √ √ Ⅹ
测试执行 √ √ √ √ Ⅹ测试执
行 缺陷记录及跟踪 √ √ √ √ √
测试总
结
测试分析及总结报
告
√ √ √ √ ○
√ -- 需要（详版模板） ○ -- 需要（简版模板） Ⅹ --不需要
说明：
1、大型项目：公司立项的项目，或开发周期 3 个月以上的项目；
2、中型项目：开发周期 1-3 个月的项目；
3、小型项目：开发周期 1 个月内的项目；
4、微型项目：开发周期 2 周以内的项目；
5、BUG 修复：对于已知 bug 的修复工作；
、测试项目结构
测试项目的内容主要来源于两个方面：
1.由项目开发周期决定的测试类别。
2.由产品技术评审确定的测试类别
项目性质
产品技术评审测试类别
大型 中型 小型 微型 BUG 修改
9
单元测试 Ⅹ Ⅹ × × ×
集成测试 Ⅹ Ⅹ Ⅹ × ×
系统测试 Ⅹ Ⅹ Ⅹ Ⅹ Ⅹ
验收测试 Ⅹ Ⅹ Ⅹ Ⅹ Ⅹ
备注：Ⅹ 必须做； × 可以不做
注：产品技术评审的流程和细则参见《产品技术评审流程》
、测试文档
软件测试文档一般包括测试计划、测试用例、测试报告，测试文档的基本内容和要求见 GB
／T 9 3 8 6。
根据软件的完整性级别和软件规模等级进行合理的取舍与合并，其要求见下表。
项目性质
输出文档
大型 中型 小型 微型 BUG 修改
测试计划 Ⅹ Ⅹ Ⅹ Ⅹ ×
测试用例 Ⅹ Ⅹ Ⅹ Ⅹ Ⅹ
测试报告 Ⅹ Ⅹ Ⅹ Ⅹ Ⅹ
备注：Ⅹ 详版文档； Ⅹ 简版文档； × 可以不需要文档
测试项目与输出文档裁剪表
10
4、测试过程
、流程图及说明
说明：
工作内容 输入 输出
测试策
划
确认测试对象、范围；
分析测试需求；
制定测试计划
需求说明书；概要设计/详细设计；
数据库说明
测试计划
测试设
计
设计测试用例、测试数据；
部署测试环境
需求说明书；概要设计/详细设计；
数据库说明；
测试计划
测试用例（评审通
过）；评审记录
测试执
行
执行/维护测试用例；
提交并跟踪缺陷
测试用例（评审通过） 缺陷记录
测试总
结
评估测试结果；
撰写测试报告
测试计划；测试用例；缺陷记录 测试报告
、测试类型流程图及准入准出
单元测试
单元测试目的
测试活动流程图
测试策划 测试设计 测试执行 测试总结
测
试
工
程
师
研
发
工
程
师
产
品
经
理
项
目
负
责
人
评审通过
验收通过
通过
验收未通过
编码技术设计
用例设计
产品设计
需求确
认
用例评审
确认
评审未通过
未通过
确认未通过
测试计划确认通过
生产测试
验收
生产验收验收
测试总结
计划评审
评审未通过
评审通过
11
软件单元测试的目的是检查每个软件单元能否正确地实现设计说明中的功能、性能、接
口和其他设计约束等要求，发现单元内可能存在的各种差错。
说明：单元测试由开发人员操作
二代：
准入标准：
无要求
准出标准：
1. 被测模块达到软件判定标准的“符合”等级，具体参考 ；
2. 开发组长审核通过，并签字；
三代：
准入标准：
1.单元模块通过编译；
2.单元模块代码已进入受控库。
准出标准：
1.被测模块达到软件判定标准的“符合”等级，具体参考 ；
2.开发组长审核通过；
3.出具书面测试结果。
集成测试
集成测试目的：
软件集成测试的目的是检验软件单元之间、软件单元和已集成的软件系统之间的接口关
系，并验证已集成软件系统是否符合设计要求。
说明：
二代由开发人员完成
三代集成测试由开发人员和测试人员共同操作
12
二代（由开发人员操作）：
准入标准：
1. 单元测试通过
2. 系统设计已经基本稳定，概要设计通过初评；
3. 代码集成完毕，通过编译；
4. 代码进入受控库
准出标准：
1. 被测模块达到软件判定标准的“符合”等级，具体参考 ；
2. 开发组长审核通过，开发组长签字；
三代（由开发人员和测试人员共同操作）：
准入标准：
1．系统设计已经基本稳定，概要设计通过初评；
2．详细的接口对外说明文档，具体参照三代账户系统第一次迭代 API；
3．开发自测通过，自测内容至少包含概要设计上的所有功能点，单元测试代码覆盖率高于
75%；
4．开发提交代码时，同时提交自测报告， 报告体现为 jira（相应的管理记录）上该任务状
态为完成或“**接口测试完成”邮件；
5．代码集成完毕，通过编译；
6．测试人员审核有自测报告，并得到配置组通知代码通过编译后，接收测试工作。
准出标准：
1．提交测试方案；
2．接口测试用例设计已经通过评审；
3．接口测试代码已经通过评审；
集成测试流程图
测试策划 测试设计 测试执行 测试总结
研
发
工
程
师
测
试
工
程
师
/
研
发
工
程
师
项
目
负
责
人 需求说明书
概要设计
详细设计
数据字典
设计确认 测试策划 用例设计
用例评审
确认未通过
确认通过
评审未通过
验收
评审通过
验证通过
验收未通过
验收通过
测试总结
编码
验证
验证未通过
13
4．源代码和测试代码均被标识，并纳入受控库；
5．按照测试计划完成了整个系统的接口测试；
6．最后一次回归测试 bug 全部通过；
7．遗留问题均已通过项目负责人、产品经理的评审允许存在或给出修复时间（遗留 bug 必
须在 3 级以下）；
8．迭代结束之后输出测试报告，测试报告内容及形式参见《xx 平台_XX 测试报告》
系统测试
系统测试目的：
系统测试的目的是在真实系统或仿真系统工作环境下检验完整的软件配置项能否和系
统正确连接，并满足系统/子系统设计文档和软件开发合同规定的要求。
说明：系统测试阶段由测试人员完成
准入标准：
1. 产品部分：
具有明确的需求文档或者需求说明，并通过需求确认。
a) 说明为什么要有该功能，该功能实现了什么，如何实现
b) 如有业务流程，业务规则，需给出流程图
c) 包含功能点列表
d) 需求文档或说明进入受控库（三代适用）。
质量人员审核符合以上要求，接收需求文档
2. 开发部分：
1.概要设计中业务规则文档。（三代适用）
2.开发自测通过：
基本流程能够通畅的完成，核心功能可以体现
开发组长签字确认。（二代适用）
开发提交代码时，同时提交自测报告，报告体现为功能点列表的勾选（三代适用）
3.代码集成完毕，通过编译：
系统测试流程图
测试策划 测试设计 测试执行 测试总结
研
发
工
程
师
测
试
工
程
师
项
目
负
责
人 需求说明书
概要设计
详细设计
数据字典
设计确认 测试策划 用例设计
用例评审
确认未通过
确认通过
评审未通过
验收
评审通过
验证通过
验收未通过 测试总结
编码
测试验证
验证未通过
14
测试人员审核有自测报告，且已经勾选所测的功能点，并得到配置组通知代码通
过编译后，接收测试工作。（三代适用）
开发组长完成集成测试，并在流程中签字确认，并得到配置组通知代码通过编译
后，接收测试工作。（二代适用）
准出标准：
1.按照测试计划完成相关测试工作
2.测试已覆盖所有测试用例/测试点
3.客观、详细的记录了所有软件测试过程中发现的缺陷
4.被测产品达到软件判定标准的“符合”等级，具体参考
5.遗留问题均已通过项目负责人、产品经理的评审并给出计划修复时间
6.出具测试报告并通过评审
验收测试
验收测试是以项目负责人为主导的测试，其对象是完整的、集成的计算机系统。
验收测试的目的是在真实的系统或仿真环境上作环境下检验完整的软件系统．是否满足
软件开发技术合同(或软件需求规格说明)规定的要求。其结论是软件的需方确定是否接收陔
软件的主要依据。
验收测试应由软件的项目负责人组织．由独立于软件开发的人员实施。
应加强验收测试的配置管理，已通过测试的验收状态和各项参数应详细记录，归档保存，
未经测试负责人允许，任何人无权改变。
软件验收测试的技术依据是用户需求或系统需求 (或软件研制合同)。其测试工作的准
入条件与准出条件应满足“软件测试准入准出标准”的要求。
说明：验收测试由项目负责人/产品经理实施。
5、测试管理
、人员管理
软件测试应由相对独立的人员进行。根据软件项目的规模等级和完整性级别以及测试类
别，软件测试可由不同机构组织实施。
应对测试过程中的测试活动和测试资源进行管理。有关管理要求见 GB／T 8566。一般
情况下，软件测试的角色见下表。
工作角色 具 体 职 责
测试负责人
1) 代表测试组与项目中项目负责人、开发组、产品组进行沟
通
2) 主持测试用例、测试计划、测试预估时间评审
3) 编写测试计划
4) 测试报告分析
15
5) 负责本次测试项目的进度与测试工作
测试用例设计工程师
1) 设计测试用例
2) 确定测试用例优先级
3) 确定测试环境
测试程序员 1) 编写测试辅助软件
测试实施工程师
1) 实施测试用例，执行测试
2) 记录测试结果
3) 提交并报告缺陷
4) 缺陷跟踪、缺陷回归
测试系统管理员 1) 对测试环境和资产进行管理和维护
配置管理员 1) 设置、管理和维护测试配置管理数据库
注1: 当软件的供方实施测试时，配置管理员由软件开发项目的配置管理员承担；当独立
的测试组织实施测试时，应配备测试活动的配置管理员。
注2: 一个人可承担多个角色的工作，一个角色可由多个人承担。
、测试挂起、恢复与终止
注意：测试挂起、终止、恢复时需要测试负责人通知项目负责人以及该中心主管。
测试挂起
定义
因某种原因导致测试无法继续，测试活动暂停，等待解决问题后恢复测试。
导致原因
测试挂起主要由以下几种情况导致：
1. 主要模块、功能存在缺陷导致无法继续测试；
2. 测试环境无法达到测试要求；
3. 因项目计划发生变动，需要调整测试计划；
4. 需求变更范围达到 10%以上（大、中、小型项目适用）；
5. 技术人员因各种原因导致无法配合缺陷修改；
6. 项目负责人发生变动；
7. 出现非上述情况的突发事件，导致测试无法继续，报项目负责人，决定是否挂起。
测试恢复
测试挂起后，当导致挂起的问题被解决后，测试恢复。
测试终止
定义
测试终止即为测试活动结束，重新进入排期。
16
导致原因
当测试过程中，出现如下情况时，测试终止。具体如下：
主要模块通过率小于 50% ；
测试挂起达到两次后，第三次出现无法继续测试的情况；
需求变更范围达到 30%以上（大、中、小型项目适用）；
需求变更导致测试无法继续（微型、Bug 修复适用）；
由于技术需要，代码重构；
测试挂起超过 5 个工作日；
测试资源耗尽；
出现非上述情况的突发事件，报项目负责人，决定是否终止。
处罚标准
因提交代码导致产生缺陷等级为“灾难”级别，处罚项目负责人每次 100 元，存入该部门文
化建设基金。
因提交代码导致产生缺陷等级为“严重”级别，处罚项目负责人每次 50 元，存入该部门文化
建设基金
由于开发原因导致测试终止每月超过 3 次，处罚部门文化建设基金每次 100 元。
由于开发原因导致测试被挂起每月超过 3 次，处罚部门文化建设基金每次 50 元。
注：目前没有纳入到质量部测试环节的产品，相关的处罚依据“风险事件”调查责任认定结
果。
、BUG 管理
缺陷严重等级划分
严重性
等级
检测类 问题严重程度划分标准
功能类问题
造成系统崩溃、死机、异常退出
数据库数据发生不可挽救的丢失或损坏（例如：资金计算错误、
用户信息误删除 ）
未提供必备的风险监控措施
性能类问题
系统出现异常，且无法自动恢复
性能未满足业务需求致命（5
级）
安全类问题
直接危害您的应用程序、Web 服务器或信息。（包括但不限于：
对服务器执行命令，偷取客户信息，拒绝服务）
敏感数据泄漏、丢失或者篡改。（包括但不限于：密钥、密码、
身份信息、账户信息、银行卡信息、交易信息）
系统核心配置文件、源代码泄漏、对视或者篡改
影响交易数据完整性。
17
导致越权访问。
外包类问题
未与第三方服务机构签订支付服务系统外包合同和安全保密协
议
未对外包服务建立风险评估制度
未对外包商资质建立认定制度
功能类问题
功能失效导致主要流程出现断点（用户无法用其它方式绕过）
数据库数据处理错误，但可以挽救（例如：账户状态）
系统缺少必要的负载限制导致大负载时系统失效
未提供必备的功能，或者必备的功能未正确实现（例如：有支付
接口，无退款接口）
性能类问题 系统在高并发后不能及时恢复
严重（4
级）
安全类问题
尽管数据库和操作系统没有危险，但会通过未授权的访问威胁私
有区域（例如：脚本源代码泄露，强制浏览）
功能类问题
必备功能实现不完善，但不影响业务功能使用，或者有替代方法
可选功能未正确实现
必选项数据未进行校验，或者校验不严格
查询数据时数据显示错误或局部数据显示计算错误
提示信息错误
用户界面错误
页面功能问题（页面校验、数据排序、报表下载、翻页等）
页面级需求未实现或实现与需求描述不一致
安全性类问
题
非敏感数据泄漏、丢失或者篡改
系统一般的配置文件泄露、丢失或者篡改
允许未授权的侦测（例如：服务器路径公开，内部 IP 地址公开）
一般（3
级）
文档类问题
文档缺失
文档自身、文档之间或者文档与实际情况不一致
文档内容不完整
功能类问题
页面级与整体风格处理不一致
缺少必要的缺省信息
警告信息不全面、不准确
常识类问题
可选项数据未进行校验，或者校验不严格
系统操作不方便
系统出现偶发性错误，但不影响正常业务使用
轻微（2
级）
安全类问题
您应当了解的问题，未必是安全问题（例如：启用了不安全的方
法）
功能类问题
界面不友好
错误提示不够直观 建议（1
级）
文档类问题
文档格式不统一，不易于浏览，文档内容不容易理解
文档管理不规范
18
缺陷响应时间
响应级
别
描述 响应时间
紧急 导致测试环境或系统不能正常使用的缺陷 立即解决
高
基本业务流程缺陷、功能类错误，特别是对继续进行测试有
阻碍的缺陷
两小时内响应，1 个
工作日内解决
一般 不影响业务流程的功能缺失或错误 3 工作日内解决
低 非功能类缺陷，如界面元素位置、提示信息等 资源允许情况下修改
挂起 因技术或者环境原因不能按照以上时间要求解决的缺陷 挂起
注：响应时间为参考值，具体时间需依据项目时间有项目负责人进行确定
缺陷管理流程
19
6、产品上线判定准则
、测试判定准则
测试结果：分为“符合”、“基本符合”和“不符合”。测试结果判定原则如下：
测试点结果判定定义
Ⅹ 不通过
测试结束后，若存在 5 级（致命）或 4 级（严重）缺陷，该测试点判定为“不通过”；
Ⅹ 基本通过
测试结束后，若存在 3 级（一般）或 2 级（轻微）缺陷，该测试点判定为“基本通过”；
Ⅹ 通过
测试结束后，若不存在问题或仅存在 1 级（建议）缺陷，该测试点判定为“通过”。
产品结果判定原则
产品类型：指公司内部研发产品或外包产品。
Ⅹ 通过
全部测试点的测试结果均为“通过”，该测试类判定为“通过”；
Ⅹ 基本通过
“基本通过”的测试点占全部测试点的比例达标，该产品的测试结果判定为“基本通过”。
比例见“达标比例表”；
例：产品“基本通过”比例低于 10%，判定为此产品基本符合质量要求
达标比例表
产品架构产品类型
C 端应用 行业产品 基础产品 平台
内部产品 ＜10% ＜10% ＜8% ＜5%
外包产品 ＜7% ＜7% ＜5% ＜3%
Ⅹ 不通过
若存在“不通过”的测试点，或“基本通过”的测试点占全部测试点比例不达标，该产品的
测试结果判定为“不通过”。
、产品上线评价准则
Ⅹ 允许上线或接收外部软件评价准则：
20
前提条件 状态结果
产品测试结果判定为“通过”。 允许上线
产品测试结果判定为“基本通过”且已经得到后续缺陷的改进计划。 允许上线
特殊情况：没有 5 级或 4 级 BUG，但“基本通过”比例不达标，项目负责人
制定缺陷的改进计划后，可由 CEO 审批或者 COO 与本中心领导联合审批。
允许上线
Ⅹ 不允许上线或拒绝接收外部软件评价准则：
前提条件 状态结果
产品测试结果存在“不通过”，测试结果判定为“不允许”。 不许上线
产品测试结果判定为“基本通过”，但项目负责人未按时完成之前项目的缺陷
改进计划，测试结果判定为“不允许”。
不许上线
突发情况或稳定性要求规定的停止上线（例如：长假前 1 周、系统不稳定
排查问题）
不许上线
7、专职测试人员与非专职测试人员
项目或产品由非专职测试人员进行产品测试的判定
原则上基础产品、平台产品必须要由专职测试人员主导进行产品的测试工作。专职测试
人员与非专职测试人员可根据下表定义：
序号 质量特性 子特性 测试人员 非测试人员
适合性 √ √（产品人员）
准确性 √ Ⅹ1 *功能性
互操作性 √ Ⅹ
成熟性 √ Ⅹ
容错性 √ Ⅹ
易恢复性 √ Ⅹ
2 *可靠性
数据校验 √ Ⅹ
易理解性 √ √
3 易用性
易操作性 √ √
时间特性 √ Ⅹ
4 *效率
资源利用性 √ Ⅹ
易分析性 √ √
易改变性 √ √
稳定性 √ Ⅹ
5 维护性
易测试性 √ Ⅹ
适应性 √ √
6 可移植性
易替换性 √ √
7 标准符合性 行业标准（央行） √ √
8 *中文特性 中文显示 √ √
21
编码支持程度 √ √
身份鉴别 √ Ⅹ
WEB 页面安全 √ Ⅹ
访问控制 √ Ⅹ
应用容错 √ Ⅹ
报文完整性 √ Ⅹ
报文保密性 √ Ⅹ
抗抵赖 √ √（安全人员）
9 应用安全（web）
电子认证应用 √ √（产品人员）
备注：√ 为可执行； Ⅹ 为不可执行
注：角色结构对应关系只阐述什么人能做什么事，不应违背其他规则。
附录：产品质量名词说明
功能性
当软件在指定条件下使用时，软件产品提供满足明确和隐含要求的功能的能力。
适合性
软件产品为指定的任务和用户目标提供一组合适的功能的能力。
准确性
软件产品提供具有所需精度的正确或相符的结果或效果的能力。
互操作性
软件产品与一个或更多的规定系统进行交互的能力。
安全保密性
软件产品保护信息和数据的能力，以使未授权的人员或系统不能阅读或修改这些信息
和数据，而不拒绝授权人员或系统对它们的访问。
功能性的依从性
软件产品遵循与功能性相关的标准、约定或法规以及类似规定的能力。
可靠性
在指定条件下使用时，软件产品维持规定的性能级别的能力。
成熟性
软件产品为避免由软件内部的故障而导致失效的能力。
容错性
在软件出现故障或者违反其指定接口的情况下，软件产品维持规定的性能级
别的能力。
易恢复性
在失效发生的情况下，软件产品重建规定的性能级别并恢复受直接影响的数据
的能力。
可靠性的依从性
软件产品遵循与可靠性相关的标准、约定或法规的能力。
22
易用性
在指定条件下使用时，软件产品被理解、学习、使用和吸引用户的能力。
易理解性
软件产品使用户能理解软件是否合适以及如何能将软件用于特定的任务和使用条件
的能力。
易学性
软件产品使用户能学会其应用的能力。
易操作性
软件产品使用户能操作和控制它的能力。
吸引性
软件产品吸引用户的能力。
易用性的依从性
软件产品遵循与易用性相关的标准、约定、风格指南或法规的能力。
效率
在规定条件下，相对于所用资源的数量，软件产品可提供适当性能的能力。
时间特性
在规定条件下，软件产品执行其功能时，提供适当的响应和处理时间以及吞吐
率的能力。
资源利用性
在规定条件下，软件产品执行其功能时，使用合适数量和类别的资源的能力。
效率依从性
软件产品遵循与效率相关的标准或约定的能力。
维护性
软件产品可被修改的能力。修改可能包括修正、改进或软件对环境、需求和功能规
格说明变化的适应。
易分析性
软件产品诊断软件中的缺陷或失效原因或识别待修改部分 的能力。
易改变性
软件产品使指定的修改可以被实现的能力。
稳定性
软件产品避免由于软件修改而造成意外结果的能力。
易测试性
软件产品使已修改软件能被确认的能力。
维护性的依从性
软件产品遵循与维护性相关的标准或约定的能力。
可移植性
软件产品从一种环境迁移到另外一种环境的能力。
适应性
软件产品毋需采用额外的活动或手段就可适应不同指定环境的能力。
易安装性
软件产品在指定环境中被安装的能力。
共存性
软件产品在公共环境中同与其分享公共资源的其他独立软件共存的能力。
易替换性
23
软件产品在同样环境下，替代另一个相同用途的指定软件产品的能力。
可移植性的依从性
软件产品遵循与可移植性相关的标准或约定的能力。
