如果你接到一个博客系统的测试任务最怕的不是用例写不完整而是测了半天没抓到重点最后报告写得像流水账。最近我完整测了一套从零搭建的博客系统从用户登录、文章发布、评论互动到并发压测、浏览器兼容和基础安全扫描前后跑了两周中间踩了不少坑也摸出一些规律。这篇更像是一份实战复盘把测试范围怎么划、用例怎么设计、bug怎么定位、报告怎么组织这些事串起来讲适合同样在测Web系统的朋友参考。1. 开工之前先画地图测试范围与环境准备很多人拿到测试任务第一步就埋头写用例这是最容易翻车的做法。博客系统听起来简单但实际拆开之后涉及前台展示、后台管理、用户认证、评论互动、搜索分页、文件上传这些模块随便一列就是几十个功能点。如果一开始不把范围和优先级定清楚测试过程中很容易被边缘功能带跑核心链路反而没测透。1.1 被测系统概况与功能模块梳理我测的这套博客系统前端是Vue后端是Spring Boot数据存MySQL缓存用了Redis部署在Nginx后面。功能上分成两个大端前台面向普通访客能看文章列表、文章详情、搜索、发表评论后台面向管理员和作者能登录、写文章、传图、管理评论、配置站点信息。测之前我先画了一张功能模块表把每个模块的核心用例数量估了一遍这样心里有底模块重点功能用例数用户认证注册、登录、登出、记住我、token续期22文章管理发布、编辑、草稿、定时发布、删除、标签分类35评论互动发表评论、匿名评论、敏感词过滤、评论审核18内容展示列表分页、文章详情、目录锚点、图片懒加载16搜索关键字搜索、空结果、特殊字符10后台管理用户管理、站点配置、广告位位设置12文件上传图片格式校验、大小限制、上传失败重试8这张表不需要一开始就完美但至少能让你知道工作量分布。我最终用例总数是121条其中功能测试占大头性能、兼容和安全各占一部分。做完这个梳理你会发现博客系统真正的高风险区域其实是三块登录态处理、文章编辑保存、评论内容过滤后面我会逐个讲。1.2 测试环境与测试数据准备博客系统的测试环境我建议单独搭别直接拿线上库测也别跟开发共用一个环境。我这次是在一台4核8G的云服务器上部署了完整的测试包再用Docker起了MySQL和Redis版本跟生产一致。为什么要强调一致因为很多问题都是环境差异导致的比如MySQL的sql_mode配置不一样SQL语句在测试环境能跑上线直接报错。测试数据准备也有讲究。我写了一个造数脚本批量生成2000篇文章和5000条评论用来验证分页性能。账号按角色准备了普通用户、作者、管理员三档另外专门准备了一个测试专用账号密码、邮箱、手机号全是假的专用于越权测试和异常登录测试。造数这个步骤别偷懒后面测分页和搜索的时候数据量太少根本暴露不了问题。2. 功能测试别只点按钮登录、发帖、评论逐项拆解功能测试是这次工作的核心也是最能看到问题的地方。我按用户真实使用路径来组织用例而不是按菜单点一遍就完事。什么意思就是从用户打开首页开始注册、登录、写文章、发评论、退出整条链路模拟一遍同时穿插异常操作。2.1 登录功能与权限边界验证登录功能是热搜词里大家最关注的模块确实也是博客系统最容易出安全问题的入口。我这次重点测了这么几类场景第一是正常登录流程正确用户名密码登录、错误密码提示、密码输错5次后账号锁定、验证码过期、登录后刷新页面状态保持。这些属于最基础的但恰恰有很多系统在最基础的地方翻车。我测的时候发现密码错误提示如果太具体比如“密码错误”和“用户名不存在”分别显示会给攻击者提供枚举用户名的条件这类信息提示问题我在报告里标记成中危。第二是登录态和权限控制。博客系统的权限模型通常有三层匿名用户、登录用户、管理员。测试重点不是正常登录而是越权也就是普通用户能不能访问管理员的接口。这里我做了个测试在普通用户登录态下直接请求后台的/admin/api/articles接口观察返回结果。不出所料这个系统早期版本没做后端鉴权前端只是把按钮藏起来了接口直接裸奔。这个问题属于高危我会在后面缺陷分析里再展开。第三是token处理逻辑。我用Postman抓登录接口的响应拿到token后分别测试了token过期、token被篡改、token在Redis中被删除这三种情况下的行为。过期和篡改都能正确拦截但Redis被删除后系统仍然放行原因是拦截器只校验了JWT签名没有校验token是否存在于缓存中这就是典型的会话注销不彻底。2.2 文章发布与管理流程测试文章管理是博客系统的心脏我把重点放在“内容不能丢”和“权限不能乱”这两件事上。内容不能丢考验的是编辑保存的可靠性。我模拟了四种情况编辑到一半刷新页面、长时间停留后token过期再保存、图片上传成功后文章保存失败、两个账号同时编辑一篇文章。前两种情况基本都能通过草稿自动保存来兜底第三种情况就比较麻烦我在测试中发现图片上传到OSS返回了URL但文章接口保存时报了数据库字段超长错误导致图片变成了孤儿文件。这个属于资源管理缺陷虽然不影响主流程但对用户体验有实际影响。权限不能乱主要看文章状态流转。文章有草稿、已发布、已下线三种状态只有作者本人和管理员能编辑普通用户只能看。我专门做了角色交叉测试作者A能不能编辑作者B的文章管理员能不能转移文章归属已发布文章下线后前台是否立即不可见。测试中发现文章下线后前台列表页立即不可见了但通过旧链接直接访问文章详情页仍然能打开仔细排查后发现详情页做了Redis缓存下线操作只更新了数据库没主动删除缓存。这类“缓存与数据不一致”的问题在博客系统里很常见。定时发布功能我也重点测了。写作时填一个未来时间保存后文章状态应该是“待发布”到点自动变成“已发布”。我踩了一个坑开发用的是Spring的Scheduled定时任务默认是单线程调度我同时创建了3个定时发布任务时间设在同一分钟发现只有1个能准时发布另外两个延迟了将近10分钟。原因是定时任务的线程池被阻塞这种情况在博客访问量上来之前很难暴露。2.3 评论、搜索与广告位功能专项验证评论功能表面简单实际坑很多。第一步是内容安全我准备了一组测试样本包括常规文字、超长文本、HTML标签、JavaScript脚本、表情符号和敏感词。让我意外的是系统的XSS过滤做得比较到位script标签会被转义但用img srcx onerroralert(1)这种写法却绕过了过滤评论框直接弹窗。这类存储型XSS一旦上线危害是所有访问该页面的用户都中招。敏感词过滤有性能隐患。我用包含20个敏感词的评论测试发现接口响应时间从正常的120ms涨到了850ms原因及时没做敏感词库缓存每次评论都全量加载词库做遍历匹配。这种问题在功能上能算通过但性能上不合格。搜索功能的问题集中在搜索词处理上。单个关键字、多个关键字空格分隔、带引号的精确搜索、空搜索、超长搜索词这几种情况我都过了一遍。系统用的是全文索引MySQL的LIKE %关键字%方式实现搜索数据量2000条时响应已经超过1.5秒这让我意识到上线后数据量增长搜索性能肯定扛不住。另外搜索框输入特殊符号如%和_时没有做转义处理可能存在通配符注入问题虽然不至于造成数据泄露但会让搜索结果异常。广告位这块我主要验证了广告位配置修改后前台展示是否实时生效以及广告位位置在不同分辨率下的遮挡情况。这里发现一个适配问题桌面端正常显示的自适应广告在375px宽度的手机屏幕上会遮挡正文内容导致文章开头一大段被广告盖住用户无法关闭也无法阅读。这个问题的根因是广告容器的min-width设置过大触屏设备没有媒体查询适配在后端配置了降低高度后得到缓解。3. 性能、兼容与安全专项光点按钮测不出潜在风险功能正常不等于系统可靠。博客系统一旦上线会遇到多人同时访问、不同浏览器访问、还有各类恶意请求。这一部分测试我用了不少工具也补齐了单纯手工测试看不到的问题。3.1 并发压测与响应时间分析压测我用JMeter做的脚本设计不复杂但场景很关键。我建了三个场景第一个是首页访问模拟100个用户同时打开首页第二个是文章详情页模拟200个用户随机访问不同文章第三个是登录接口模拟50个用户同时登录。为什么分开测因为不同接口的资源消耗模型不同混在一起测很难定位瓶颈。场景并发数TPS平均响应时间95%响应时间错误率首页访问100245380ms640ms0%文章详情2001781020ms2900ms0.4%登录接口5096510ms780ms0%文章详情的瓶颈很快被定位了。压测过程中我盯着服务器监控看到MySQL的CPU直接拉满SQL慢查询日志里出现了一条查询文章详情的语句扫描行数达到5万行。原因是文章详情联查了文章表、作者表、分类表、标签表和评论数统计其中评论数是子查询实时count出来的没有走索引。这个问题的常规解法是加冗余字段或者使用缓存我建议优先把comment_count做成冗余字段由评论新增和删除时事务更新。压测环境要提醒一点尽量在测试环境压不要在本地笔记本上压本机服务那样网络层和真实差异太大测出来的数据没有参考价值。我这次是在服务器本机上用JMeter压测本机Nginx绕开了公网延迟结果聚焦的是应用本身的承载能力。3.2 浏览器兼容与移动端适配测试兼容性测试我跑了一轮主流浏览器矩阵桌面端覆盖Chrome、Edge、Firefox、Safari移动端覆盖iOS Safari、Android Chrome再加一个微信内置浏览器。博客系统的读者很多会通过微信群、朋友圈点击链接打开文章微信内置浏览器基本是必测项。我遇到两个典型问题。第一个是富文本编辑器在Safari下的光标定位错乱在某篇长文章中用户把光标点到第10行编辑器重新渲染后光标跳到第1行。这个属于浏览器对contenteditable的兼容性差异复现概率不低开发最后换了编辑器组件彻底解决。第二个是移动端输入框被软键盘顶起后页面整体上移关闭键盘后回不到原位导致底部工具栏被遮挡。这个问题在iOS Safari上最容易出现我测试时用真机实测关掉键盘后手动滚动才恢复。响应式布局我按照375px、768px、1280px、1920px四档宽度分别检查了首页三栏布局、文章正文排版、图片缩放。375px宽度下文章正文能正常显示但上面提到的广告遮挡问题就是在这一档暴露的。还有一个细节是图片懒加载我检查了快速滚动页面时占位图是否闪烁、图片是否被裁切变形这些都需要真机手势操作复现只用浏览器开发者工具的设备模拟器不够。3.3 安全测试要点注入、越权与接口暴露安全测试我没有用商业扫描器手工验证了几个Web系统最常见的风险点因为博客系统最容易被攻击的面就这几个。SQL注入我在搜索框、登录框、文章ID参数这几个地方分别构造了or 11--、waitfor delay这类测试串。实测下来参数化查询做得比较好均未出现注入成功的情况这属于后端功底扎实。XSS测试在评论功能那里已经发现一个存储型漏洞在搜索页面又发现一个反射型XSS搜索框输入script标签结果页直接把内容渲染进HTML。反射型XSS修复容易但对输出做HTML转义是必须的。越权访问这块是重点。我写了一个小脚本遍历后台接口清单分别用匿名态、普通用户态、管理员态去请求对比返回状态码。结果发现三个管理接口存在匿名访问漏洞其中一个是站点配置接口可以直接读取数据库里的站点密钥信息。这类问题如果只测前端根本发现不了一定要测接口层。用生活类比就像大楼的门锁都换了智能锁但地下车库的偏门还挂着好几年前的老旧挂锁。4. 本次测试最值得说的三个Bug排查过程测试中发现的bug一共18个按严重级别分布是高危3个、中危7个、低危8个。高危三个分别是接口未授权访问、存储型XSS、Redis缓存与数据库不一致。这个环节我挑三个印象最深的排查过程展开讲对测试思路的培养有帮助。4.1 登录态失效却还能访问后台的根因现象是管理员在后台点击退出登录后再直接访问后台首页系统竟然自动登录成功。第一反应是前端没有正确清除token我打开浏览器开发者工具切到Application面板查看LocalStorage和Cookie发现token确实被清空了。于是拿Postman手动请求后台接口不带任何Authorization头结果返回200。这就说明不是前端问题是后端没做登录态强校验。进一步看后端代码拦截器只拦截了/admin/api/**路径但静态资源和部分页面路由没有被拦截而页面路由本身又依赖前端路由守卫控制。前端守卫检查到本地没有token就跳转登录页但攻击者可以绕过前端直接拿接口地址请求数据。根因清楚了后端接口没有做统一的鉴权拦截前端跳转只能限制合法用户限制不了恶意请求。修复方案是加一个全局过滤器对所有非公开接口校验登录态而不是靠前端自觉。这个排查过程给我的启发是遇到“退出了还能进去”这种问题不要只在前端找原因要立刻换接口层验证边界。很多权限问题都出在后端低估了接口暴露面。4.2 文章编辑保存后格式错乱数据库字段长度惹的祸这个bug是我在测长文编辑时发现的。文章内容是一段带代码块的Markdown长度大约3万字符粘贴进入编辑器后点击保存页面提示成功但刷新后文章后半部分被截断了。一开始怀疑是富文本编辑器渲染截断恢复了接口请求报文看了请求体里content字段长度是30000数据库表设计的字段类型是TEXT最大长度65535字节理论上塞得下。再看后端代码发现保存文章时不是直接存Markdown原文而是先经过了一遍HTML转换转换后的体积膨胀了3倍超过TEXT上限数据库报错但被全局异常处理器吞掉了返回了一个假的成功响应。这类“接口显示成功但数据实际没存进去”的问题比直接报错更可怕用户会误以为保存成功直接关掉页面。修复时开发把字段类型改成了MEDIUMTEXT同时把异常处理改成可感知的错误返回我在回归测试里专门用3万字长文、带代码块、带图片链接的长文重新验证了一遍。4.3 并发评论导致楼层号错乱博客系统有个楼层功能每篇文章的评论按1楼、2楼、3楼排下去。我模拟100个用户同时对同一篇文章发评论结束后看数据库发现楼层号出现重复有多个“25楼”。这是因为楼层号是应用层先查出当前最大楼层再加1在高并发下多个请求同时读到同一个最大值产生了竞态条件。我用JMeter跑并发脚本复现得很稳定。排查时先看代码确认是“先查再插”没有走数据库唯一约束也没有使用Redis的原子自增。修复方案是改用Redis的INCR命令为每篇文章维护评论计数或者数据库层用唯一索引兜底。我额外验证了一点楼层号错乱不会造成评论丢失只是顺序和显示问题但这对博客的讨论氛围有直接影响用户看到楼层号重复会产生不信任感。5. 测试报告怎么组织才不白测测试做完输出报告是最后一步也是很多人容易敷衍的一步。我的观点是测试报告不只是给领导交差的文档它是下一个版本迭代的输入也是上线决策的依据。如果一个报告里只有“用例通过率98%”这种笼统结论那这份报告基本没价值。5.1 测试报告的核心模块与统计口径我这次报告的大纲是固定的测试概述、测试环境、测试范围、用例执行统计、缺陷分析、风险项与建议、测试结论。每一块都有固定的填写方式。测试概述里写明白测了什么、覆盖了哪些版本、测试周期测试环境要写清楚部署架构、数据库版本、浏览器矩阵测试范围要明确哪些测了、哪些没测比如我这次没有做完整的发邮件流程测试因为邮件服务用的是第三方这个要主动声明。用例统计需要用真实的数字支撑。我整理了这样一张汇总表测试类别用例总数通过失败阻塞通过率功能测试78726092.3%兼容性测试18153083.3%性能测试15132086.7%安全测试1073070%合计12110714088.4%缺陷分析不能只贴列表要按照严重程度统计分布并且对高危缺陷逐个写根因分析和修复建议。风险项是报告里最值钱的部分要把未修复的问题、已知的绕过方案、工作量预估写清楚让决策者知道上线还差什么。5.2 遗留问题清单与上线建议我整理遗留问题时会明确区分“必须修复后上线”和“可以带病上线”。这次的三个高危缺陷在未验证修复效果之前我不会建议上线。中危缺陷中存在替代方案比如广告遮挡可以先通过后台配置调小广告高度但根治需要前端改造这类可以在下一个迭代排期。测试报告最后的结论我也给了明确态度在三个高危问题修复并回归通过后该版本具备上线条件。这比我直接写“通过”或“不通过”更有参考价值。我遇到过很多测试报告最后结论就一句话“未发现严重问题”但实际上遗留了十几个中低危缺陷这种结论对团队没有指导意义。回归测试时我发现很多开发修复时会引入新问题所以我建议报告中单独列一条“修复验证结果”记录每个缺陷修复后的回归状态防止开发说“改好了”但实际上没改对。举个例子XSS漏洞修复时开发把script标签转义了但我用svg onloadalert(1)再测一遍照样弹窗。测试人员必须有这种对抗心态修复一个漏洞后要立刻想怎么绕过修复。按我的经验博客系统这类内容型Web应用测试时最难的不是把功能跑一遍而是测试范围总被低估。登录功能、文章编辑、评论过滤这些模块看着每个人都会用但深挖下去每个都是一堆边界条件和异常场景。你越是觉得“这功能简单”越要花时间测它的异常路径。最后分享一个小技巧测试过程中每隔半天就把发现的问题维护进缺陷管理表标好严重级别和复现步骤不要攒到最后一口气写否则复现步骤早就忘干净了报告质量也会大打折扣。