做测试这行，大部分人觉得只有大平台、大系统才值得认认真真写一份测试报告，像博客系统这种“小而美”的项目随便点点、能发文章就算过了。但实际情况恰恰相反，博客系统虽然功能量不大，却非常容易因为“没人较真”而在上线后翻车。我最近完整跟完一个博客系统的测试项目，从登录功能、文章管理、Markdown渲染到评论搜索全过了一遍，还顺手把自动化测试的结果统一整理成了正式的报告。这篇内容就是把整个过程还原出来：测试范围怎么切、登录模块的用例怎么设计、报告里的每个栏目到底放什么数据、自动化脚本怎么产出报告，以及我在执行过程中踩过的那些坑。
文章适合测试工程师、博客系统维护者，以及所有“手头有个小系统，却不知道该怎么测出质量”的人。看完整篇，你至少能照着里面的用例表、模板和脚本，立刻动手给自己的项目写出一份拿得出手的测试报告。
1. 先别急着写报告：博客系统测试的范围到底怎么切
1.1 博客系统测试和普通业务系统测试的差别
很多人拿到博客系统第一反应是“这有什么好测的”，但真正拆开之后会发现，博客系统虽然业务逻辑不复杂，它同样是完整的用户体系、内容生产、内容消费、互动反馈四层结构。它跟电商后台这类业务系统的最大区别在于：电商系统重交易链路，流程一旦断掉，钱和货就对不上；博客系统重内容展示链路，作者发布一篇带格式、带代码、带图片的文章，读者用不同的浏览器和设备打开时，如果渲染乱了、图片裂了、评论不显示，用户直接流失。
另一个容易被忽视的差别是，博客系统的界面相对固定，技术上可能已经“有点年头”。有些博客连框架版本都停留在老一代，换过几个开发者，做过一堆主题定制，也就是热搜词里常说的“小修系统博客”。这类系统最怕的不是核心逻辑崩掉，而是主题样式改动后，老的插件、广告位、文章列表全部跟着错位。测试时如果只看功能不看样式，报告写得再漂亮，交付出去还是会被用户骂。
所以博客系统测试报告不能照搬大项目的模板，也不能只写“用例全部通过”。它的核心价值在于：用尽可能少的测试成本，覆盖住内容生产与消费这条主干，同时把样式兼容、安全风险这类小系统容易忽略的东西补上。
1.2 功能清单与优先级排序
动手写测试用例之前，我习惯先做一个功能盘点，把系统的能力边界画清楚。下面是我在这个博客项目里梳理出的功能清单，按测试优先级排了序：
| 优先级 | 功能模块 | 测试关注点 |
|---|---|---|
| P0 | 登录/权限 | 登录成功、失败、锁定、会话保持、密码找回、第三方登录 |
| P0 | 文章管理 | 新建、编辑、保存草稿、发布、删除、文章列表分页 |
| P0 | Markdown渲染 | 代码块、引用、图片、超链接、XSS注入、特殊符号 |
| P1 | 评论系统 | 评论发表、嵌套回复、敏感词过滤、防重复提交 |
| P1 | 分类/标签 | 创建、修改、合并、文章计数 |
| P1 | 搜索 | 关键字命中、搜索结果高亮、分页、空结果 |
| P2 | 附件上传 | 图片格式、大小限制、压缩、失败清理 |
| P2 | RSS订阅 | 输出格式、中文编码、文章更新后是否及时刷新 |
| P2 | 广告位/统计 | 广告代码加载顺序、异步加载对首屏的影响 |
P0 是无论如何都要保住的核心闭环：作者能登录、能写文章、文章能在前台正确展示。这个链路断掉任何一个环节，系统就算彻底不可用。P1 属于主流体验，评论、标签、搜索是博客区别于“静态页面集合”的地方，也是用户活跃度的来源。P2 属于锦上添花，有测试时间就测，没时间至少要保证不回归。
这里要说一个实操经验：优先级排序一定要跟产品方、开发方一起过一遍，不要自己拍脑袋。曾经我接手一个博客项目时，开发觉得 RSS 订阅很简单不用测，结果博客上线后很多老读者是用 RSS 阅读器订阅的，XML 里中文乱码，负面反馈直接爆了。优先级排错了，测试报告里写再多“风险可控”也没用。
1.3 测试策略：哪些必须人工、哪些适合自动化
范围定了之后，下一个问题是测试策略。我不赞同“凡是有功能就自动化”的做法，尤其博客这种小体量系统，自动化投入太多反而拖累发布节奏。我的分配思路是这样的：
必须人工测试的部分，集中在视觉效果和内容体验上。Markdown 渲染的样式漂移、富文本编辑器里拖拽图片的交互、长文章滑动的流畅度、广告位插入后首屏布局是否被挤乱，这些靠肉眼判断比脚本断言高效得多。还有一类是“暴力输入”场景，比如往标题框里粘贴一大段 HTML、连续点击发布按钮、在评论框输入超长文本，自动化脚本很难模拟出真实的用户手滑操作。
适合自动化的部分是主流程回归和登录状态链路。博客系统的界面逻辑相对固定，文章增删改查、登录后跳转、权限拦截这些行为一旦稳定下来，很适合写端到端脚本，每次发版前跑一遍，用机器保证老功能没有被改坏。此外，接口级别的基础校验也适合自动化，比如未登录状态下访问后台接口必须返回 302 或 401，这类断言又简单又稳定。
一句话总结：小系统测试，人工聚焦体验与安全，自动化聚焦回归与权限。两条线最后汇总到一份报告里，数据才有说服力。
2. 登录模块是最容易翻车的地方
2.1 正常路径与异常路径的用例设计
热搜词里有“博客系统 - 登录功能”这个词，我一点也不意外。登录功能是博客系统的入口，也是安全风险最集中的地方，但它往往因为“看起来简单”被测得最草率。很多测试报告里登录就只有两条用例：输入正确账号密码能登录、输入错误密码会报错。这远远不够。
我给这个项目设计的登录用例，至少覆盖了下面这些场景：
| 用例编号 | 场景 | 前置条件 | 操作步骤 | 预期结果 |
|---|---|---|---|---|
| TC-LOGIN-001 | 正常登录 | 已注册用户 | 输入正确账号密码，点击登录 | 登录成功，跳转后台首页 |
| TC-LOGIN-002 | 密码错误 | 已注册用户 | 输入正确账号+错误密码 | 提示账号或密码错误 |
| TC-LOGIN-003 | 账号不存在 | 无该账号 | 输入不存在的账号 | 提示账号或密码错误，而不是“账号不存在” |
| TC-LOGIN-004 | 连续失败锁定 | 已注册用户 | 连续输错5次密码 | 第6次尝试时提示账号锁定，锁定时间后恢复 |
| TC-LOGIN-005 | 禁用账号 | 账号被管理员禁用 | 输入正确账号密码 | 登录失败并提示无权限 |
| TC-LOGIN-006 | 大小写敏感 | 账号含大写字母 | 切换大小写输入 | 必须严格匹配，不能自动忽略大小写 |
| TC-LOGIN-007 | 回车提交 | 登录页 | 输入内容后按Enter | 正常提交，不触发重复提交 |
这里面每一个场景背后都有原因。比如“账号不存在”和“密码错误”的提示必须保持一致，因为如果提示“账号不存在”，等于告诉攻击者这个邮箱/用户名已经注册过，等同于变相泄露用户信息。连续失败锁定是防止暴力破解的基本手段，但它有个副作用：如果博客的忠实用户连续输错几次，他会被锁在哪里？锁定时间是多长？这些在设计用例时都要一并确认，否则上线后用户会跑来骂客服。
我还在登录测试里追加了一个移动端场景：在手机浏览器上登录，键盘弹起时页面会不会错位，输入框会不会被遮挡，登录按钮能不能点击。很多小博客系统后端用的还是老框架，对移动端适配做得很糟糕，登录框被弹出键盘顶飞的情况我见过太多次了。
2.2 会话保持与会话过期的边界测试
登录成功只是第一步，真正考验测试功力的是会话保持和会话过期。博客用户有个显著特点：喜欢开着一个编辑器页面慢慢写，写一会儿去查资料，回来接着写。如果会话过期时间设置得太短，用户写一篇长文，提交的时候发现已经掉线，写了一小时的内容全没了，这种体验几乎是毁灭性的。
针对会话，我重点测了三件事。第一是默认会话时长。系统里设的是 30 分钟无操作过期，那么我要验证：第 25 分钟时随便点一下页面，会话是否会自动续期；第 31 分钟时再操作，是否被强制踢出并跳转登录页。第二是“记住我”功能。勾选之后关闭浏览器再打开，登录态是否还保持；不勾选的话，关闭浏览器再打开是否必须重新登录。第三是会话的并发逻辑：同一账号在 Chrome 和 Firefox 同时登录，两边是否互相踢掉，还是允许并存，这个行为必须在报告里写清楚，因为它直接影响用户体验。
还有一个很容易翻车的点：Ajax 请求与会话过期。很多博客后台的侧边栏、通知列表是通过异步接口拉取的，用户停留时间长了以后，页面看似还开着，但背后的接口已经返回 401。如果前端代码没有做全局的登录过期处理，用户以为一切正常，点保存文章的时候才突然被弹回登录页。这个场景我强烈建议专门测，而且要在测试报告里明确写结论：是否已做全局会话过期拦截。
2.3 第三方登录与忘记密码的联动用例
现在很多博客系统都会接入第三方登录，省去用户注册的麻烦。这块的测试用例绝不能只停留在“点一下第三方图标能跳转授权页”这种深度。
我实现的用例还覆盖了这些情况：
- 第三方登录首次授权后，是否要求用户绑定本站账号或补充用户名；
- 同一个第三方账号如果已经绑定过本站账号，再次点击时应该直接登录；如果没有绑定，则不能自动创建一个新账号；
- 用户取消授权后，页面是否正确回到登录页而不是停留在白屏；
- 第三方登录回调地址是否固定，能否被伪造，回调参数非法时会怎样。
忘记密码也要形成联动用例：发送重置邮件或短信后，验证码或重置链接的有效期是多久；重置链接是否只能使用一次，用第二次是否报错；新密码是否不能与最近使用的密码相同；重置完成后，旧密码是否立即失效，其他端登录态是否被踢出。这些细节很多开发根本没考虑，而测试报告里一旦写了“已覆盖”，说服力会非常强。
3. 内容核心链路：发文章、改文章、删文章背后的坑
3.1 编辑器与 Markdown 渲染的联动测试
博客系统的核心资产就是文章，所以内容链路的测试一定要做深做透。整个链路里最容易出问题的有两处：一是编辑器本身，二是 Markdown 渲染到 HTML 的转换。
编辑器测试，我建议准备一份“魔鬼输入样本”。这份样本里要包含：嵌套的 Markdown 语法、高亮的代码块、超长英文不换行字符串、多级引用、表格、脚注、数学公式、内嵌 iframe、原始 HTML 代码、特殊符号如<script>、javascript:、以及各种全角半角标点。把这些内容粘进编辑器，再从预览、保存、前台展示三个角度去检查，很多隐藏问题马上会暴露。
Markdown 渲染部分，最核心的是一个安全断言：任何用户输入的内容，都不应该以未转义的形式变成 HTML 输出。我专门写过一个用例，在文章标题里插入<script>alert('xss')</script>，发布后去后台列表页和前台文章页分别检查。如果前台能正常显示的标题被浏览器直接解析执行了脚本，说明渲染层没有做转义或过滤，这就是严重级别的安全漏洞，必须阻断发布。代码块的显示也是一个高频问题：高亮插件如果和 Markdown 解析器兼容性不足，会出现整段代码被吞、行号错位、特殊字符被错误转义，这些都要慢慢磨。
还要重点提一下“编辑器预览”和“前台最终展示”的一致性。很多 Markdown 编辑器是“所见即所得”的，但预览渲染器和前台渲染器如果不是同一套引擎，可能出现预览正常、发布后格式全乱的情况。这种问题在测试报告里一定要作为专项记录下来。
3.2 附件上传与图片引用的边界条件
写博客的人不可能不用图片，所以附件上传模块我也花了大量时间测。先列一下我会执行的基础用例：
- 只允许的图片格式，上传非图片文件是否被拒绝；
- 超大文件是否有限制，超过限制后的提示是否友好；
- 文件名包含中文、空格、特殊字符时，上传后 URL 是否正确编码；
- 传完图片后插入到文章里，切换文章草稿再打开，图片路径是否依然有效；
- 存储层失败时，前端有没有给用户明确报错，数据库有没有残留脏数据。
图片这块还有一个 Web 开发里常见的“历史遗留”问题：很多博客系统上传图片后生成的是绝对路径，一旦域名或端口变化，文章里的图片全部裂掉。我在测试时就专门把整个博客从 localhost 切到测试域名，再把文章里的图片逐个打开检查，发现至少有三分之一的图片还在指向旧地址。这种问题用脚本很难自动发现，必须人工回归，测试报告里也要给出结论：迁移域名之前有哪些隐藏图片路径需要处理。
3.3 评论、标签、搜索的交叉场景
文章本身没问题了，不代表内容消费链路就完美了，评论、标签、搜索这些交叉模块也要过一遍。
评论系统要注意防重复提交。用户双击发表按钮，或者网络慢的时候连点多次，会不会生成多条一模一样的内容？我常用一层 JS 防抖加后端幂等判断来要求开发修复，测试时要用脚本快速连点模拟。评论里的敏感词过滤也要专门测，有些实现只过滤了正文、没过滤昵称，测试时得两条线都翻一遍。
标签模块看起来不起眼，但很容易在“合并标签”这个功能上翻车。两个标签合并之后，每篇文章的标签计数是否一致？按标签筛选文章时文章数量是否正确？后台标签列表里显示的文章数是否更新？我以前的博客项目还出过一个奇葩 Bug：删除标签后，文章页面仍然残留标签链接，点进去是空页面。这类小细节非常影响体验，写着写着就容易漏测。
搜索模块的坑更多。常见的是搜索范围不对，比如只搜了文章标题，没搜正文，用户明明记得正文里有什么词却搜不到。还有搜索结果里的关键字高亮，如果直接替换成<mark>标签而没有做转义，遇到用户搜索<script>这种内容，页面结构直接被打乱。搜索分页也要测，从第 2 页返回第 1 页时搜索条件是否被保留。这些交叉场景我全部录进了测试报告，作为 P1 级别的用例输出。
4. 测试报告该写什么，才算一份合格的报告
4.1 测试报告的基本栏目与逻辑顺序
前面说了这么多用例设计，最终都要在测试报告里沉淀下来。我见过很多测试报告，通篇贴截图、写“功能正常”，虎头蛇尾，审阅的人根本没法判断系统能不能上线。
一份合格的测试报告，不论你是做博客系统还是做别的，栏目顺序一定要遵循“让一个没参与测试的人，五分钟内做出上线决策”这个目标。我常用的结构是：
| 栏目 | 核心作用 |
|---|---|
| 测试概述 | 交代被测系统版本、测试时间、测试人员、测试目的 |
| 测试范围 | 明确哪些功能测了、哪些没测，避免事后背锅 |
| 测试环境 | 列出操作系统、浏览器、移动设备、后端版本、数据状态 |
| 执行情况 | 用例总数、通过数、失败数、阻塞数、自动化执行结果 |
| 缺陷分析 | 缺陷总数、按严重级别分布、按模块分布、缺陷趋势 |
| 风险评估 | 当前未修复缺陷的影响范围、规避建议 |
| 测试结论 | 能不能上线，什么条件下可以上线 |
这个顺序背后是有逻辑的：概述给背景，范围划边界，环境保证可复现，执行情况用数据说话，缺陷分析解释质量问题，风险评估给出剩余隐患，结论一拍板。缺任何一环，报告都是不完整的。
有人会问，跟硬件类的测试报告，比如 EMC 测试报告有什么区别？我个人的理解是，EMC 这类报告核心价值在“指标”，参数曲线和实测值必须对上标准；软件测试报告核心价值则在“证据”，你的用例步骤、日志和截图要能支撑你的结论。博客系统测试报告里不需要堆砌一堆术语，但必须有可追溯的证据，这是它存在的根本意义。
4.2 缺陷数据怎么统计才有说服力
测试报告里光写“发现 Bug 18 个，已修复 15 个”是远远不够的，缺陷数据一定要拆分到能定位问题的粒度。我通常从以下角度拆：
| 统计维度 | 具体拆分 |
|---|---|
| 缺陷总数 | 整个测试周期内的累计值 |
| 按模块分布 | 登录模块、文章编辑、渲染、评论、搜索、上传等各自多少个 |
| 按严重级别 | 致命、严重、一般、建议（或P0/P1/P2/P3） |
| 按状态 | 待修复、修复中、已验证关闭、重新打开、延迟处理 |
| 按引入原因 | 功能缺失、逻辑错误、兼容性问题、安全问题、文案问题 |
这样一拆就能看出问题了。比如这个博客项目总共报了 22 个缺陷，其中 10 个集中在 Markdown 渲染模块，那就能说明渲染引擎不稳定，需要重点盯；如果致命级别缺陷还挂着 2 个没修，那测试结论就绝对不能写“可上线”。必要时我还会画一个缺陷趋势图，反映每天新增了多少、关闭了多少，这能看出开发修复速度是否跟得上测试进度，上线前曲线如果一直不收敛，就要警惕了。
缺陷数据分析还有一个很容易被忽略的点：用例通过率要和缺陷数据配合着看。用例通过率高不一定质量好，可能只是用例写得不够狠；用例通过率低也不一定不能上线，要看失败的用例集中在哪个模块。所以测试报告里我会同时给出“计划用例数、实际执行数、通过数、失败数、阻塞数”这几个数字，算出一个总通过率，再跟缺陷数据互相印证。
4.3 一份可以直接抄作业的测试报告模板
最后给大家一份我实际用的博客系统测试报告模板，结构清晰，所有栏目都留了说明，你拿去把数据换成自己的就能用。
# 博客系统测试报告 ## 1. 测试概述 被测系统：博客系统 v1.4.2 测试时间：2024-xx-xx 至 2024-xx-xx 测试人员：张三 测试目的：验证本次版本核心功能与回归项质量，评估是否具备上线条件 ## 2. 测试范围 本次测试覆盖范围： - 登录/权限、文章管理、Markdown渲染、评论、标签、搜索、附件上传、RSS - 回归测试：文章列表分页、编辑器保存草稿、后台菜单权限控制 不覆盖范围： - 性能压测（未配置压测环境） - 低版本 IE 浏览器兼容 - 垃圾评论 AI 过滤算法效果 ## 3. 测试环境 Web服务器：Nginx 1.24 / 后端 PHP 8.1 / 数据库 MySQL 5.7 浏览器：Chrome 120、Firefox 120、Safari 17、Edge 120 移动端：iPhone 13（iOS 17）、小米13（Android 14） 测试数据：空库初始化 + 导入演示数据 50 篇文章 ## 4. 测试执行情况 用例总数：156 执行用例：152（4条因第三方登录未配置回调地址阻塞） 通过：136 失败：12 阻塞：4 通过率：89.5% ## 5. 缺陷分析 缺陷总数：22 - P0致命：0 P1严重：3 P2一般：12 P3建议：7 按模块分布：登录 4、Markdown渲染 6、附件上传 4、评论 3、搜索 3、其他 2 未关闭缺陷：2（均为P2一般级别） ## 6. 风险及建议 - Markdown渲染模块存在3个P1缺陷，已修复验证通过，但渲染引擎本身存在历史遗留风险，建议上线后持续观察 - 附件上传暂未处理超大图片自动压缩，可能造成页面卡顿，建议在后续迭代优化 ## 7. 测试结论 通过（有条件上线）。P0无未关闭缺陷，P1缺陷全部闭环，遗留2个P2一般缺陷不影响核心流程。建议在部署到生产环境后三天内完成一次线上冒烟回归。这份模板不需要多花哨，但它能让所有参与者在同一频道上对齐信息。写报告的时候记住一个原则：每个结论都要能被报告里的数据或证据解释，不要写“运行稳定”这种摸不着边的话，要写“XX用例 N 条全部通过，未发现严重缺陷”这种能自查的话。
5. 自动化测试怎么落地，才不会沦为摆设
5.1 工具选型：Selenium 还是 Playwright
博客系统这种前后端一体的小项目，最适合用轻量级的端到端测试工具做回归。选型上我之前在两个阵营之间纠结过：Selenium 和 Playwright，现在我的结论非常明确，新项目直接用 Playwright。
不是说 Selenium 不好，它生态成熟、支持的语言多，但在博客系统这个场景里，Playwright 有几个非常舒服的点：安装简单，一条命令搞定 Chromium；自动等待机制比 Selenium 的隐式等待智能，很少出现那种“元素明明出现了却找不到”的随机失败；自带截图和录屏，失败用例可以直接保存案发现场；API 设计也更现代，代码写起来像在读自然语言。
Selenium 唯一的优势在于团队已经有成熟的 Selenium Grid 基础设施，或者需要跑大规模浏览端矩阵。如果只是给一个小型博客系统做回归，我真心不建议为此搭一套 Grid。工具这东西，够用就好，别为了技术炫技把测试成本拉高。
5.2 登录态、测试数据和用例隔离的处理
自动化脚本最怕两件事：一是用例之间互相依赖，二是测试数据不干净。博客系统里最典型的就是“登录态”。如果一个用例先登录，退出，另一个用例再来登录，中间任何一步失败，后面的用例全挂，整个回归结果惨不忍睹。
我的做法是用 Playwright 的 storageState 做登录态持久化。先在测试环境跑一次真正的登录，把登录后的 Cookie 和本地存储导出来存成 state.json；之后每条用例创建 context 的时候直接加载这个文件，界面跳过了重复登录过程，速度更快，稳定性也更好。代码大概长这样：
from playwright.sync_api import sync_playwright with sync_playwright() as p: browser = p.chromium.launch() context = browser.new_context(storage_state="state.json") page = context.new_page() page.goto("http://localhost:8080/admin/") # 此时已经是登录状态，可以直接开始断言后台元素 assert page.locator("text=写文章").is_visible() browser.close()第一次生成 state.json 得写一段真正的登录脚本，以后日常回归全部复用这个状态文件。不过要注意：如果系统会话过期机制生效，隔了一晚上再跑，这个 state.json 可能失效，所以我会在测试框架最前面加一个校验步骤，发现跳到登录页就重新登录刷新状态文件。
测试数据隔离也很关键。我规定每个用例必须自己创建自己的测试文章，比如用时间戳做标题AutoTest_Article_1712345678，断言完成后清理掉；绝对不允许所有用例共用一个测试文章。否则就会出现 A 用例把标题改成了“测试数据1”，B 用例断言标题是“测试数据2”，互相打架，你怎么查都查不清。评论、标签、附件这些数据同理，各用各的，跑完就删，数据库保持干净，重跑结果才稳定。
5.3 自动化结果如何输出测试报告
自动化脚本运行完，一定要有可视化的结果输出，不然脚本写得再好，别人也无法知道这次回归到底通过了没有。我常用的是 Allure 报告，配合 pytest 使用，命令非常简单：
pytest --alluredir=./allure-results --clean-alluredir allure generate ./allure-results -o ./allure-report --clean生成出来的 HTML 报告里有完整的用例列表、执行时间、失败日志、截图信息。我更看重的是它能把每个用例的历史运行趋势展示出来，如果某个用例最近五次跑挂了三次，那多半不是环境抖动，而是产品逻辑真的有问题，需要开发介入。这就是自动化输出的“过程数据”，也是最终人工博客系统测试报告的“证据来源”。
说到这里，我要强调一个很容易走入的误区：自动化报告的通过率，不能直接当作测试报告的最终结论。很多人把 pytest 输出“all passed”就当成“系统没问题”，这是不对的。像 AdSense 广告代码的加载顺序、移动端字体渲染、Markdown 排版这类问题，自动化脚本很难覆盖到，所以最终报告里，自动化结论只是“回归证据”的一部分，还要有人工测试、缺陷分析、风险评估这些维度综合判断。这跟热搜词里“uds自动化测试输出测试报告”的逻辑是一样的：自动化负责把执行过程和结果标准化地记录下来，但报告里的语义化结论仍然需要测试负责人去归纳。
6. 实际执行中踩过的坑和排查思路
6.1 验证码与自动化脚本的相爱相杀
博客后台登录页如果接入了图形验证码，那自动化脚本基本就瘫痪了。我第一次跑定时回归脚本时，每天早上看到的结果都是红色失败，全卡在验证码识别这一步，排查起来非常浪费时间。
我的处理方案是分环境区别对待。在测试环境里，后台加一个配置开关，专门把验证码关掉；自动化用例里就完全不处理验证码逻辑。但验证码本身是安全机制，不能因为测试方便就取消了，所以我又单独留了一组人工测试用例，专门在有验证码的真实环境上执行，覆盖验证码正确、错误、过期、刷新这几种场景。对自动化来说，我们不在 UI 层跟验证码死磕，这是性价比最高的做法。
如果你非要让自动化脚本通过验证码，我建议也不要去做图像识别，那是过度工程化。要么开发提供万能验证码或白名单账号，要么走接口层直接绕过验证码登录后，再测试页面功能。我是见过团队用机器学习做验证码识别，投入了两周人力，最后准确率还不到 80%，那完全是在给自己挖坑。
6.2 Markdown 内容注入与 XSS 的边界
博客系统是内容型系统，天然面临一个很麻烦的安全问题：用户写 Markdown 时可能会插入原始 HTML。Markdown 解析器如果允许内嵌 HTML，又不过滤危险标签，XSS 漏洞几乎必现。
我在测试时最喜欢用这样的用例：在文章里写一段链接[点这里](javascript:alert('xss'))，或者插入一张图片<img src=x onerror=alert('xss')>。如果前端展示时直接执行了 JavaScript，那问题就严重了。还有一种是“双转义”遗漏：编辑器预览时安全，但后台列表页直接把文章标题插入到页面里没转义，导致整个后台被恶意脚本控制。我测试时会把文章标题、文章摘要、标签名、评论内容这些“用户可写字段”全用恶意脚本填充一遍，再从前台、后台两个角度分别断言是否安全。
这类问题测试报告里要定性为安全风险，严重级别至少是 P1。博客系统只要被插入一个 XSS 脚本，攻击者就可能拿到管理员的 Cookie，进而控制整个站点，这不是危言耸听，是我真实遇到过的线上事故。
6.3 会话过期导致写好的文章丢失
这个坑我在 2.2 节提过，但在这里一定要再说一次，因为它太容易被测试忽略了。我当时遇到的复现场景是：用户打开写文章页面，写了大概四十分钟，中间一直在看参考资料，没有对页面做任何操作，等回来写完正文点发布，系统直接跳到登录页，所有内容全部丢失。
这就暴露了三个问题：会话时间设置不合理、前端没有做自动保存草稿、后端没有对已登录用户做操作续期。我当时的处理是要求开发在这三处都做了改进：会话过期前弹出续期提示；编辑器内容实时存 localStorage，刷新页面或重新登录后可以恢复草稿；提交文章时如果发现 401，先把内容保存在本地再引导登录。测试报告里我把这类问题归为“关键用户体验缺陷”，因为对博客产品来说，内容创作是全部价值的来源，内容丢失比功能报错更伤用户。
6.4 缺陷记录不规范，报告写不下去
很多测试报告写得烂，根源不在模板，在缺陷记录本身。团队里如果每个人报缺陷都是“后台有问题”“文章发布不了”“登录出错了”，最后汇总报告时完全没有依据，只能一个一个去问，效率极低。
我在项目中强制约定了一个缺陷标题格式，简单有效：[模块] 具体操作 + 具体现象 + 环境/浏览器。举例：[Markdown渲染] 文章包含嵌套代码块时前台展示错位，Chrome 120 稳定复现。另外每条缺陷必须附上：复现步骤、预期结果、实际结果、截图或日志、严重级别。这样做的好处非常直接，测试报告里的缺陷清单基本就是从缺陷管理工具导出后稍加整理得到的，不用再二次加工。
我再多分享一个小技巧：缺陷状态在报告中一定要写准确，“已验证关闭”和“已修复”是两个概念，有些开发说“改好了”，但测试还没有来得及回归验证，那就只能算“待验证”，绝不能写进“已关闭”。我在报告中吃过一次亏，后来就把这个规则写进团队的缺陷管理约定里了。
7. 最后说点我对博客系统测试的体会
项目做完后，我最大的感受是：小系统测试报告的含金量，不在篇幅有多长，而在你敢不敢在报告里写清楚“什么没测、什么有风险”。很多测试人员害怕写遗留问题和未覆盖范围，担心老板看了觉得质量不行，但恰恰是这些内容，才能体现出你对项目的真实把握。
登录功能永远值得反复测，因为它是系统的门户；内容链路必须测出安全底线，因为一次 XSS 或一次内容丢失，都足以毁掉用户信任；报告里的每个结论都要能被数据解释，不然它只是一堆空话。
如果后面你也在给博客系统或者类似的小型内容系统写测试报告，我个人的建议是：先切范围，再补用例，然后尽快把自动化回归跑起来，最后留出时间认认真真整理缺陷数据与风险结论。整个过程做完，你手里那份测试报告，才是真正能给团队决策用的东西，而不是一个形式主义的文档。
