web网站测试报告

上周三凌晨两点，站测我盯着屏幕上一片红色的试报报错，意识到这次改版把登录接口的站测响应时间从300ms拖到了4.7秒。这不是试报段子，是站测真实发生的事。测试报告要是试报晚写三天，运维那边就得先炸锅。站测

很多人以为网站测试就是试报点几下页面，看看能不能打开。站测我最早也这么想。试报直到有次给一个电商站做回归测试，站测首页秒开，试报商品详情页正常，站测下单流程也没毛病——结果用户反馈说“购物车加了两件商品，试报结算时只算一件”。站测查了半天，发现是并发写入时缓存没锁住。这种问题，手工点一百遍都未必能撞上。

测试环境不是“差不多就行”

我见过太多团队拿开发机当测试环境。开发机装了半年前的Node版本，数据库里只有三条假数据，网络延迟忽略不计。然后测试报告写“功能正常”。上线后真实用户一进来，图片加载慢、搜索超时、支付回调丢失，全来了。

真实案例：一个内容管理系统，测试环境用SQLite，生产环境用PostgreSQL。测试时文章发布成功，上线后带特殊字符的标题直接导致插入失败。测试报告里没提数据库差异，因为压根没测过。后来我坚持在测试报告里加一节“环境对比”，把操作系统、中间件版本、数据库类型、网络拓扑列清楚。这不是形式主义，是保命。

性能测试别只看平均值

平均响应时间200ms，听起来不错。但如果有5%的请求花了8秒呢？用户可不会管你平均值。我习惯在报告里放P95和P99。某次API压测，平均180ms，P99却到了6.2秒。追下去发现是某个模糊查询没加索引，数据量一过十万就全表扫描。开发说“平时挺快的”，对，平时就几十条数据。

还有并发用户数。别写“支持1000并发”这种空话。要写清楚：在4核8G的机器上，用JMeter模拟500个线程，持续压10分钟，错误率0.3%，其中超时占80%。数字越具体，开发越没法糊弄。

兼容性测试不是装个Chrome就行

上个月帮朋友看一个后台系统。Chrome下一切正常，Safari里日期选择器直接错位，按钮点不动。原因是用了某个CSS属性，Safari不支持。测试报告里如果只写“主流浏览器通过”，那就是埋雷。

我的做法：列出具体版本。Chrome 118、Firefox 119、Safari 16.4、Edge 118。移动端至少测iOS 16和Android 13各一台真机。模拟器？触控事件和滚动行为跟真机差远了。曾经有个下拉刷新，模拟器正常，真机上拉半天没反应——因为触摸事件被一个透明遮罩拦截了。

安全测试别等上线后再说

SQL注入、XSS、CSRF，这些老生常谈。但我要说一个容易被忽略的：接口越权。用户A能通过改URL里的ID看到用户B的订单。测试时只测了“登录后能看自己的订单”，没测“登录后能不能看别人的”。这种漏洞在测试报告里经常缺失。

我现在的习惯：每个涉及用户数据的接口，至少试三种身份——未登录、普通用户、管理员。用Burp Suite抓包改参数，五分钟的事。有次真发现一个删除接口，普通用户传个admin=1就能删别人文章。开发说“前端隐藏了按钮”，可后端没校验。

报告怎么写才有人看

别写“测试用例执行通过率98%”这种废话。直接列问题。按严重程度分：阻塞级（功能不可用）、严重级（数据错误）、一般级（体验问题）、建议级（优化项）。每个问题附上复现步骤、截图、日志片段、影响范围。

我见过最离谱的报告：写了三十页，最后结论是“基本可用”。什么叫基本可用？登录偶尔失败算不算？支付回调延迟算不算？后来我要求自己：报告第一页必须写清楚——能不能上线，不能上线的话卡在哪几个问题。

测试报告不是交差用的。它是上线前的最后一道闸。写的时候想象一下：凌晨三点，运维拿着你的报告决定要不要回滚。你希望他看到什么？