软件指标测试除了功能验证，还会排查安全漏洞吗？

"指标测试"这个词听起来很宽泛，实际上它对应的是软件质量模型中的多个维度。依据GB/T 25000系列国家标准（尤其是GB/T 25000.10软件质量模型和GB/T 25000.51测试细则），软件产品的质量特性一共有八大维度：

功能性，功能是否正确、完整、适用；

性能效率，响应时间、吞吐量、资源利用率；

兼容性，不同环境下的适配能力；

易用性，界面友好度、操作便捷性；

可靠性，稳定性、容错性、可恢复性；

信息安全性，保密性、完整性、抗抵赖性、可核查性；

维护性，模块化、可分析性、可修改性；

可移植性，适应性、易安装性。

看到了吗？信息安全性是八大质量特性之一，不是额外附加的"选修课"，而是质量模型的"必修课"。所以严格来说，你说的"指标测试"如果指的是依据国标做的全项质量测试，那安全漏洞排查天然就在里面。

很多人一听"安全排查"就想到拿个漏洞扫描工具跑一遍。在指标测试的语境下，安全维度的测试内容比这丰富得多，大致分为三层。

这一层测的是"软件的安全功能设计对不对、实现有没有缺陷"，它是功能性测试和安全性测试的交叉地带。

具体测什么？身份认证机制是否可靠、访问控制是否严格、数据保护是否到位、审计功能是否完善等

这一层的核心逻辑是：软件声称自己有安全功能，那就验证这些功能是否真的有效。 它不是去找未知漏洞，而是验证已知安全设计的正确性，所以和功能验证的关系非常紧密。

这一层才是传统意义上的"漏洞排查"，主要手段包括：

漏洞扫描。用专业工具对系统做自动化扫描：Web应用漏洞（SQL注入、XSS、文件上传、命令执行）、中间件漏洞、操作系统漏洞、第三方组件已知漏洞（CVE）。扫描器对照庞大的漏洞特征库逐一匹配，快速定位"疑似问题"。

安全配置核查。默认口令改没改？不必要的端口关没关？日志审计开没开？SSL/TLS配置是否安全？数据库权限是否最小化？这些配置层面的疏漏，往往是最容易被利用的"低垂果实"。

代码安全检查。从代码层面排查安全隐患：硬编码密钥、不安全的加密算法（MD5、SHA1）、输入未校验、输出未编码、危险函数调用。这些问题是漏洞的"源头"，在代码层面堵住，比上线后打补丁高效得多。

如果指标测试的安全深度要求更高，还会包含渗透测试，模拟真实攻击者的思路和手法，验证漏洞的可利用性和实际危害。这一层技术含量最高，发现的问题也最接近真实攻击场景。

但请注意：不是所有"指标测试"都会做到第三层。 基础的指标测试通常覆盖第一层和第二层，渗透测试往往作为独立的安全测试项目单独委托。这个深度差异，就是很多人以为"指标测试不查漏洞"的根源。

安全维度测试（安全功能验证+已知漏洞排查+渗透测试）

问题出在哪里？不是标准没规定，而是执行层面的三个偏差。

偏差一：测试范围"缩水"。 有些机构或企业为了省钱省时间，把"指标测试"简化为"只测功能和性能"，安全维度直接跳过。测完出报告，功能通过、性能达标，看起来很漂亮，但安全是空白。这种"选择性测试"恰恰是问题所在。

偏差二：概念混淆。有些人把"指标测试"等同于"功能+性能"，把"安全测试"当作完全独立的另一件事。其实在国家标准的框架下，它们都是质量特性测试的组成部分，只不过安全测试因为技术门槛高、工具投入大，经常被"独立"出来单独报价，造成了"两者无关"的错觉。

偏差三：合同没约定。测试合同里只写了"功能测试、性能测试"，没提安全，测试机构按合同执行，自然不会做。等验收时甲方问起安全，才发现合同漏洞。这不是机构的问题，是需求沟通时的疏忽。

所以结论很清楚：不是指标测试"不管"安全，而是你做的那份测试"没做"安全。 标准里写着要做，做不做取决于你的测试方案怎么定。

回到开头那个问题：软件指标测试除了功能验证，会不会排查安全漏洞？会的，而且应该做。 在国家标准的质量模型里，安全性是和功能性、性能效率并列的核心质量特性，它们从来就不是割裂的三件事，而是同一个质量评价的三个维度。

区别只在于：你的测试方案有没有把安全包含进去、排查的深度够不够、发现的问题有没有闭环整改。这些做全了，指标测试就是完整的质量体检；省略了安全，指标测试就只是一张"半张脸的体检报告"。

与其上线后被攻击了才后悔，不如测试时就把安全纳入范围，功能验证看"能不能用"，性能测试看"扛不扛得住"，安全排查看"防不防得住"。三样都过关，软件质量才真正立得住。

标签：指标测试、八大质量特征