PG官网

  先看一个常见的场面，一个做连锁零售的客户，会员商城赶在周年庆前上线。开发公司说功能都测过了，压力测试和安全扫描可以等上线后补，先把活动赶上去。客户老板觉得有道理，合同里也没写这两项，就签了上线确认单。

  活动当天上午十点，领券页面开始转圈，付款后订单状态停在处理中。技术团队查了两个小时，发现数据库连接被打满，第二周补做安全扫描，又扫出一个测试账号还在用弱密码。开发公司说扫描报告只是建议，客户问谁来整改，几家供应商互相看了一圈，没人接。

一、要不要做，先看上线后会不会有人集中来、会不会暴露在公网

  功能测试能证明按钮点得通，证明不了人一多还通不通。压力测试看的是峰值，安全扫描看的是外人能不能进。两件事都不在功能验收的清单里，最容易被一句「先上线再说」省掉，等出事再补，能补的只有解释。

  要不要做，不用听销售讲，问三个问题就够。上线后有没有活动、抢购、集中报名这类流量高峰，系统是不是放在公网、用户拿手机就能访问，系统里有没有钱、订单、手机号、身份证这类数据。三个里占一个，这两项就不能省，别拿上线日期去赌。

  小一点的内网工具，可以不请第三方做完整渗透，但基线扫描和一次按真实数据量的压测还是要有，至少把弱密码、测试账号和主流程峰值排一遍。省掉这一步，省下的是几天时间，赔进去的可能是活动当天的订单和用户信任。这笔账不难算，难的是有人愿意在上线前当那个扫兴的人。

  还有一类项目，开发公司自己说测过了，报告却只有一句「功能正常」。这种报告不能作为上线依据，连测试环境、数据量和失败记录都没有，出了事只能靠回忆。压测和安全扫描都要有过程记录，谁测的、怎么测的、测出什么、改没改，后面才说得清。

  甲方要在合同签订时就提，不要等到上线前一周才加。临时加项，开发公司要么报高价，要么草草跑一遍，交上来的东西没人敢信。写进合同和付款节点，测试才会被真正排进计划，而不是挂在项目经理嘴上。

二、压力测试谁来提、测什么、报告给谁

  压力测试该由甲方提，不能等开发公司主动。甲方最清楚活动节奏和业务峰值，开发公司只知道自己那套系统。提要求的时候，把上线后的预估用户量、峰值时段、核心流程说清楚，别只丢一句「给我压一压」。

  测试可以由开发公司做，也可以请第三方。内部系统、预算有限的项目，开发公司自测加甲方旁站就行。涉及大促、支付、政务报名这类扛不住的场景，最好找第三方，报告更中立，甲方也要一起看测试方案，不能只看结尾的结论。

  测什么要提前定，不能到现场随便点几下。至少覆盖登录、首页、核心查询、下单或报名、支付回调这几条主链路，每条链路都要带真实数据量和第三方接口。并发量按平时峰值的两到三倍往上加，一直加到系统出错，再看它在哪个点开始扛不住。

  报告不能只写通过。要写测试环境、数据量、并发曲线、每轮响应时间、错误率、服务器和数据库的瓶颈，还要附上失败请求和日志。报告由测试方出具，谁测谁签字，交给甲方项目负责人和业务负责人，不要只发在开发群里，签字的人至少要能看懂瓶颈那一页。

  标准要落到数字上。比如核心接口 95% 的请求在 3 秒内返回，错误率低于 1%，按峰值连续跑 30 分钟，CPU 和数据库连接不持续打满，这些数字不是行业统一答案，要按自己的业务承受度定，但必须提前写下来，挂进付款节点，报告没交、瓶颈没改，尾款先别付。

三、安全扫描不是跑个工具，整改要有人认领

  安全扫描同样该由甲方提，不能等开发公司说没问题就算了，具体分两层，工具扫描按漏洞库查已知问题，速度快，覆盖广，渗透测试由人模拟攻击，能发现越权、逻辑漏洞、接口裸奔这类工具扫不出来的问题。上线前至少做一层，面向公网和存着个人信息的系统最好两层都做。扫描通过不代表系统安全，只代表这份清单上的已知问题关掉了。

  扫描报告要看三样东西，问题在哪、严重程度、怎么复现。只给一个风险评分，甲方没法安排整改，也没法判断哪个问题该先修。报告要由测试方出具并签字，开发公司自测就由技术负责人签，第三方测就盖公司章，报告里还要写清受影响的域名、接口、账号，别把生产环境地址和测试账号发到大群。

  整改要按资产认领，谁的系统谁改。小程序的问题归小程序公司，接口越权归后端公司，服务器配置归运维，测试账号归开发。多家供应商的项目，让总包或甲方项目经理建一张问题表，一行一个责任人，别在群里喊，群里喊久了通常没人动。

  常见的问题并不高深。测试账号没删、后台地址直接暴露、接口不登录也能查数据、日志里打印了手机号、老组件很久没升级。这些问题修起来不复杂，难的是没人认领，或者改了表面没改根子，复测一跑又原样出来。

  修完不能只在群里回一句好了，要让整改人提交修改说明，测试方按原路径复测，甲方留一份关闭记录。高危问题没关闭，上线日期就要往后排，这条不能松。扫描通过也不等于没有漏洞，只能说明已知问题清掉了，上线后还要有人看日志、管权限、跟补丁。

四、复测到什么标准，验收单上才签字

  复测标准要在测试前写进同一张表，不能等报告出来再商量。压力测试看核心流程在约定峰值下是否稳定，错误率是否在可接受范围，响应时间是否达标。连续跑完整个峰值时段，还要看 CPU、内存和数据库连接有没有一路顶到天花板。

  安全复测看高危是否清零，中危是否修完或者有临时防护和整改期限，低危是否排进版本计划。测试账号、弱密码、默认配置这三类问题必须关掉，不能带到生产环境。高危留一个口子，前面做的扫描基本等于白做。

  复测要用同一套场景和数据，至少保证口径可比。上一次压测用的脚本、数据量、环境变了，第二次的数字就没有意义，报告也没法对比。安全问题按原路径复测，不能只让开发截一张修复后的页面，截图证明不了接口已经拦住。

  验收单上要能查到三份东西，压测报告、安全报告、未闭环问题清单。每份报告有出具方签字，每个未闭环问题有责任人和日期。甲方项目负责人签的是知情和接受，不是替供应商背书，签之前至少把高危和瓶颈两页看完。

  达不到标准怎么办，也提前说清。内部管理系统可以带条件上线，先把低风险问题记进清单，面向公众、涉及支付和个人信息的系统，高危没清零就别上。上线后再补，代价通常比晚几天大，这个底线不用等老板拍板，项目经理在验收表上就该拦住。

  判断这两项要不要做、做没做到位，不用看报告有多厚，问三个问题。上线后有没有集中的流量高峰，系统有没有暴露在公网，报告里高危问题是不是真的清零了。三个问题里有一个答不上来，上线日期就先别定死。