内容摘要：webload测试教程 凌晨两点，我盯着屏幕上那条鲜红的“响应时间：8.7秒”曲线，差点把咖啡泼在键盘上。这就是webload给我的第一课——它不关心你的代码多优雅，它只在乎用户点下按钮后，服务器能不

webload测试教程

凌晨两点，测程我盯着屏幕上那条鲜红的试教“响应时间：8.7秒”曲线，差点把咖啡泼在键盘上。测程这就是试教webload给我的第一课——它不关心你的代码多优雅，它只在乎用户点下按钮后，测程服务器能不能在三秒内吐出结果。试教

先别急着装工具。测程你得想清楚一个问题：你到底在测什么？试教是登录接口的并发上限，还是测程某个报表页面的吞吐量？我见过太多人打开webload就录脚本，录完就点“开始”，试教结果跑出来一堆没头没脑的测程数据，然后骂工具不好用——这就像拿菜刀拧螺丝，试教拧歪了怪刀不快。测程

安装webload后，试教第一件事不是测程录制，是配置场景。在“Scenario”里，把虚拟用户数设成你业务预估峰值的1.5倍。别贪多，500个并发就能把测试机压垮，数据全废。我记得第一次测一个支付系统，傻乎乎设了2000并发，结果webload自己先崩了，日志里全是“connection reset”，那叫一个尴尬。

录制脚本时，有个细节容易被忽略——think time（思考时间）。默认是0，意味着每个虚拟用户都像机器人一样疯狂点击，这不符合真实人类行为。真实用户会愣一下，会滚动页面，会犹豫两秒再输密码。把think time设成3到5秒的随机值，测出来的响应时间才有参考价值。别嫌慢，慢出来的数据才真实。

跑完测试，别急着看那个“平均响应时间”。平均数是骗子。我见过一个接口，99%的请求都在1秒内返回，但那个1%的慢请求把平均值拉到5秒。这时候要看“90th percentile”（90分位值），意思是最慢的10%请求被剔除后，剩下的最快响应时间。如果90分位值小于3秒，那基本能接受；要是超过5秒，就得查慢SQL或者缓存策略了。

webload的报告里有个“错误率”指标，很多人只盯着它是不是0。但我觉得，错误率在0.5%以内，且错误类型全是“timeout”，那问题不大——可能是网络抖动。但如果出现“HTTP 500”或者“connection refused”，那才是真故障。去年我测一个文件上传接口，错误率才0.2%，但全是500，排查半天发现是Tomcat的maxPostSize设小了，文件一超过10MB就报错。要是只看错误率，这问题就漏过去了。

还有一个土办法，但特别好用——测试时开两个终端，一个跑webload，另一个用`top`命令盯着服务器CPU和内存。如果CPU打满但响应时间还行，说明应用逻辑没问题，是机器算力不够；如果CPU才30%响应时间就飙到10秒，那八成是锁竞争或者IO瓶颈。工具给的是表象，系统指标才是内因。

最后说个反直觉的：webload跑完，如果所有指标都绿得发亮，别高兴太早。那可能意味着你的测试脚本根本没走真实业务逻辑。比如有些登录接口，录脚本时把验证码写死成“1234”，那测出来的并发数再高，也代表不了真实场景。正确做法是录脚本时，把验证码参数化，从预置的测试账号池里随机取——麻烦是麻烦点，但数据能信。

别把webload当神。它就是个工具，能告诉你“系统在压力下会怎样”，但不会告诉你“为什么”。真正的功夫在测试前的场景设计，和测试后的日志分析。我见过最牛的性能测试工程师，一半时间在写脚本，另一半时间在翻服务器日志——webload只是他手里的一把尺子，量完还得自己看哪里不平。

工具装好，脚本录好，场景配好，点下那个绿色的“Start”按钮。然后站起身，去倒杯水。等回来的时候，屏幕上的曲线会告诉你，你的系统是个硬汉，还是个虚胖的纸老虎。