软件指标测试

先说句实在话，很多团队做测试，指标是测了，合规也过了，但回头一看，要么标准用错了，要么测了个寂寞。新标准已经变了不少，还按老路子来，报告拿出去人家不认。

一、指标测试：别再只盯着"能不能用"了

现在主流依据的还是 GB/T 25000.51-2016《软件产品质量要求和评价标准》，但目前行业实践已经往前走了一步。指标测试核心就四个维度。

1.响应时间，测的是平均响应和峰值响应。2026年有个明显变化——延迟取代吞吐量，成了高并发场景下的核心KPI。以前大家比谁TPS高，现在比谁响应快。

2.吞吐量，也就是每秒处理事务数。现在要求自动化脚本覆盖率必须达到80%以上，纯手工压测的报告基本没人认了。

3.资源占用率，CPU、内存、磁盘IO这些都得盯。2026年特别强调资源利用率的波动情况，波动越小说明系统越稳，光看峰值没意义。

4.稳定性，看的是长时间压测下的表现。72小时压测只是底线，头部机构已经跑到30天连续无故障了。

二、具体怎么操作？

第一步，建基线。 没有基线的性能测试就是瞎蒙。你得先知道正常情况下响应时间多少、TPS多少，才能判断现在是不是出了问题。当下的标准特别强调"真实性"，负载生成要遵循真实性、简洁性、可重复性三个原则，优先用混合负载而不是线性负载，因为真实用户不会排队一个一个点。

第二步，选对工具。 大部分第三方测试机构使用JMeter、Gatling 这类开源工具，同时 New Relic、Grafana、Dynatrace 做实时监控。性能监视器（PerfMon）拿来看CPU、内存这类资源占用最直接。

第三步，出报告。 报告必须包含测试环境配置、结果分析、瓶颈定位、修复建议，缺一不可。而且自动化回归测试率要达到60%以上，否则报告的可信度会被打折扣。

三、合规性测试

合规性测试是大多数人容易翻车的地方，指标测试如果没过，顶多性能差，但是合规没过，那是要被罚款、下架、甚至追责的。合规性测试的本质就一句话：对照法规标准，一条条验证软件有没有踩线。

1.先搞清楚要对标啥？

按优先级排：国家法律（《网络安全法》《数据安全法》《个人信息保护法》）、行业标准（金融看《金融科技产品安全测评规范》和等保2.0（GB/T 30276），医疗看《医疗器械软件注册审查指导原则》，政务看《政府网站与政务新媒体检查指标》）、国际法规（出海的要过 GDPR、CCPA）、合同约定（比如客户要求数据本地留存、适配国产操作系统，这些也算合规要求）。

2.具体测什么？

（1）数据安全这条线，最容易出事

传输加密、存储安全、权限最小化、数据销毁。

（2）身份认证这条线，金融和政务必查

弱口令、无验证码、无二次认证，有一个就不合格；金融APP必须支持生物识别或动态令牌等多因素认证；政务APP要做无障碍访问测试，模拟残疾人、老人操作。

（3）漏洞扫描这条线，别存侥幸心理

SQL注入、XSS、越权访问、API权限控制，这些是常规项。今年还特别强调要测第三方SDK的权限管理，很多APP出事就出在SDK上。

（4）性能合规这条线，很多人忽略了

不是说性能好就行，是必须达到行业规定的最低标准。比如政务APP要求响应时间不超过3秒，金融APP高并发场景下错误率不能超过一定阈值。这些数字不是你自己定的，是标准里写死的。

四、报告怎么写才能过审？

合规性测试报告跟普通测试报告不一样，审核方盯得很细：

1.合规依据必须写清楚：列法规名称、条款编号，不能写"符合相关规定"这种模糊话；

2.数据必须可追溯：漏洞扫描的原始日志、权限测试的截图、加密验证的抓包记录，全部附上；

3.缺陷要分级：致命（违反强制性法规）→ 高危（影响上线验收）→ 中危/低危，修复优先级按这个来；

4.测试机构要有资质：CMA或CNAS认证是基本门槛，没有这个章，报告在政务云采购、金融验收里直接不被采信。

以前是上线前才测，现在是需求阶段就得把合规点拆进去。以前靠人工一个个点，现在自动化脚本覆盖率不到80%你报告都不好意思交。指标测试决定你的软件好不好用，合规测试决定你的软件能不能活。两个都得硬，缺一个都是定时炸弹。

标签：指标测试、合规性测试