实际项目中，GB/T 25000.51-2016八大质量特性应该怎么选？

GB/T 25000.51-2016 的八大质量特性不必在一个项目里全部启用：功能性是所有验收项目的必选项，性能效率、可靠性、信息安全性按系统性质与合同指标取舍，兼容性、易用性、维护性、可移植性则由交付对象与运行环境决定。选择依据落在合同、需求规格说明书与验收办法三个文件里，由委托方与测评机构共同确认，而不是照搬固定清单。

一、GB/T 25000.51-2016八大质量特性分别关注什么？

GB/T 25000.51-2016 的正式名称是《系统与软件工程 系统与软件质量要求和评价（SQuaRE）第51部分：就绪可用软件产品（RUSP）的质量要求和测试细则》，全国标准信息公共服务平台收录的标准信息显示：

“该标准确立了就绪可用软件产品（RUSP）的质量要求、测试文档集要求和符合性评价细则。”

八大质量特性是这套质量要求的组织框架，每项特性之下还有子特性，测评报告里的测试项正是在子特性这一层展开的。选择特性之前，先弄清每项特性管什么、什么情况下会被触发：

二、实际项目应该根据什么选择质量特性？

特性选择不是拍脑袋，背后有五个可操作的判断维度。

业务用途

验收交付、招投标、软件产品登记、政策申报对报告的要求各不相同：招投标关注功能性与性能效率能否支撑采购指标；涉及个人信息处理的系统，信息安全性通常是必测项；登记测试则围绕功能性组织。报告用途先定下来，特性范围才有基准。

使用规模

用户数与并发量直接决定性能效率做不做、做到什么档位。一个百人内部使用的管理系统，性能测试做基准档即可；面向数十万公众开放的办事系统，就需要分档加压，把响应时间、资源利用率与容量上限都纳入范围。

系统架构与集成情况

对外接口多、需要与第三方系统对接的项目，兼容性里的互操作性权重明显上升，接口清单要逐项进范围；单体封闭系统则可以把这部分压缩。浏览器与终端分布复杂的 Web 应用，共存性验证也不能省。

项目风险

从故障后果倒推：业务中断影响面大的，可靠性要覆盖长时间运行与异常恢复；数据泄露后果严重的，信息安全性的保密性、访问控制、日志审计都要进范围。风险大小与特性深度成正比。

合同和验收要求

合同、招标文件与验收办法里写明的指标是刚性边界——并发数、响应时间、连续运行时长，写进合同的就必须测，没写的按前四个维度协商补充。脱离合同谈特性选择，验收阶段容易返工。

三、不同类型项目应该重点关注哪些质量特性？

把五个维度落到典型项目类型上，侧重点会很清晰。

普通业务管理系统

内部使用的 OA、ERP、业务管理系统，功能性是绝对主力，性能效率做基准档验证，易用性视用户面决定，其余特性按合同与风险补充。

高并发系统

电商促销、票务、公共服务平台这类访问量集中的系统，性能效率与功能性并列为核心：并发分档设计、响应时间曲线、资源利用率随负载的变化、容量上限都要进范围，可靠性中的容错性也应同步关注。

多系统集成项目

数据共享交换、跨部门业务协同类项目，兼容性中的互操作性是重头——接口协议、数据格式、调用时序逐项验证；功能性则要覆盖端到端业务流程，不能只看单系统。

长时间运行系统

监控调度、工业控制、生产值班类系统，可靠性升为核心特性：成熟性（长期运行稳定性）、容错性（异常输入与中断处理）、易恢复性（故障后数据一致与快速恢复）一个都不能缺。

涉及重要数据的系统

存储公民个人信息、金融数据、商业敏感信息的系统，信息安全性的保密性、完整性、可核查性进必测范围；数据分级越高，访问控制与日志审计的验证深度越深。

国产化迁移适配项目

信创迁移场景下，可移植性从边缘特性变成核心：适应性（在国产操作系统、数据库、中间件上的运行验证）、易安装性、易替换性（数据迁移与原系统替换方案）单独成块验证，功能性做迁移后的回归确认。

四、不同项目的质量特性应该如何组合？

六类典型项目的组合起点如下，实际范围仍要回到第二节的五个维度校验：

这张表给的是起点而非终点：组合完成后，还要按业务用途、风险与合同指标再过一遍，必要时叠加第二甚至第三项重点特性。范围的大小，以覆盖风险、对齐指标为准。

五、项目验收时如何确定测试范围？

明确验收目标

这次测试是竣工签字、招投标资质还是申报材料，目标不同，报告的口径与深度不同。目标先与验收方书面确认，避免按经验定范围。

分析合同和需求资料

合同附件、招标文件的技术参数、需求规格说明书是范围的原始输入。把这些文件里的指标逐条摘出来，能直接对应到质量特性与子特性上。

确定重点质量特性

按第二节的五个维度过滤，参照第三、四节的类型组合，圈出本项目的重点特性与必测子特性，砍掉与风险、指标无关的项。

明确测试内容和判定依据

范围落到子特性一级，判定依据写具体值：并发数、响应时间、连续运行时长、终端与浏览器清单。判定指标空着，测试就只能凭经验取值，报告结论的说服力会打折。

六、质量特性是不是越多越好？

不是。特性范围越大，测试工作量与周期同比上升，成本压力先到；与风险不匹配的测试项挤占工期，关键特性反而测不深；报告里堆满低关联度的测试项，还会稀释核心结论的分量。衡量范围合理与否的标准只有一条：覆盖风险、对齐指标。超出这两条边界的特性，删掉不影响验收效力。

七、实际项目确定测试范围的三种方法

以功能性为基础

功能性是底座。先保证功能完备性与正确性覆盖全部核心业务流程，再叠加其他特性。任何项目都不能以「测过了性能、安全」为由跳过功能性验证。

围绕项目风险

从故障后果倒推范围：中断后果严重，可靠性进范围并明确连续运行时长；数据敏感，信息安全性的保密性与访问控制进范围；接口出错会阻断业务，互操作性逐接口验证。风险导向能让有限的测试预算落在刀刃上。

根据验收指标倒推

合同写明 500 并发、页面响应不超过 3 秒，测试范围就从这两个数字反推：加压档位、监控项、判定阈值全部跟着指标定。指标倒推法得出的范围与验收口径天然一致，验收阶段分歧少。

八、确定测试范围时常见的5个问题

问题一：委托文件只写特性大类

只写「做功能测试」，交付时双方对覆盖深度容易产生分歧。应把范围写到子特性一级，例如「功能完备性、正确性；成熟性、易恢复性」。

问题二：判定指标空缺

特性选了，但并发数、响应时间、运行时长没有具体值，测试只能凭经验取值，结论无法复核。指标要在委托阶段与验收方逐项确认。

问题三：测试环境与实际运行环境差距过大

用低配环境测高配生产系统，性能结论不能外推；数据库规模、网络条件、终端分布与生产不一致，测试结果的说服力都会打折。环境差异要在报告中如实说明。

问题四：为压缩成本砍掉功能完备性

功能性是底线特性，砍掉完备性验证等于把验收建立在未经确认的业务流程上。预算紧张时，应压缩的是与风险无关的附加项，而不是底座。

问题五：报告结论超出实际测试范围

只测了功能性却给出「系统质量符合标准要求」的整体结论，属于结论越界。报告结论必须与实际测试范围一致，未测内容不得写成已验证。

九、案例：一个政务系统如何选择质量特性？

某省级一体化政务服务平台，B/S 架构，面向公众办事与窗口审批，对接省数据共享交换平台，存储公民身份与证照信息，核心模块 7×24 小时服务，当年有部分模块迁移到信创环境。验收前，委托方与测评机构按三步确定范围。

头一步明确目标：这次测试同时服务竣工验收与上线依据，结论要能支撑正式对外运行，深度按上线标准定。

第二步按维度过滤：公众访问有集中高峰，性能效率进必测，分档加压；对接交换平台，兼容性里的互操作性按接口清单逐项验证；涉及公民个人信息，信息安全性的保密性、访问控制、日志审计进范围；7×24 小时窗口服务，可靠性安排连续运行验证；信创迁移模块，可移植性单独成块测适应性与易安装性。

第三步把范围写进委托文件：功能性覆盖全部核心业务流程的功能完备性与正确性；性能效率明确并发档位与页面响应上限；互操作性覆盖与交换平台的全部接口；信息安全性、可靠性、可移植性各写明对应子特性与判定指标。验收阶段，双方没有再为测试范围补充材料或产生分歧——范围一次谈清的效果，在交付时体现得直接。

十、八大质量特性的选择清单

把前面的方法收成一张可执行的清单：

• 功能性永远在范围内，功能完备性与正确性覆盖核心业务流程；
• 其余七项特性，按业务用途、使用规模、架构集成、项目风险、合同验收五个维度逐项过滤；
• 圈出的组合对照项目类型模板校验，缺漏的补上，无关的删掉；
• 范围落到子特性一级，判定指标写具体值，与验收方书面确认；
• 报告结论与实际测试范围保持一致，未测内容不写成已验证。

标准给的是框架，范围要靠委托双方谈定。北京尚云（尚拓云测）在软件验收测试、性能测试与安全测试方向承接项目，可在委托前协助梳理质量特性覆盖范围与判定指标，把测试范围一次谈清。