企业官网建设流程全解析

博客系统功能测试，我这两周的项目就是它。刚拿到任务的时候，有同事跟我说，博客系统有什么好测的？不就是发文章、看文章、留评论吗，功能列表一页纸都写不满。等我把需求文档逐条过完、把前后端代码翻了一遍之后才发现，这种“看起来简单”的内容管理系统，恰恰是测试最容易翻车的类型。内容模型、用户体系、评论互动、富文本编辑器、文件上传、权限控制、搜索检索，任何一个模块单独拎出来都能写一屏测试用例，再加上博客天生就是公网部署、匿名访问、面向全网用户的形态，测漏一个越权或者XSS，上线之后就不是Bug，而是事故。

这篇稿子我就把整个博客系统功能测试的过程完整摊开讲：从需求拆解和测试策略怎么定，到核心功能的用例设计、执行过程中的工具和数据准备，再到我实际踩过的坑和排查思路，最后讲讲测试报告怎么写才能让开发心服口服、让老板敢签字上线。无论你是刚入行的测试新人，还是被临时拉去“支援”博客项目的开发同学，这套思路都可以直接套用。

1. 博客系统测试的整体设计与思路拆解

测试最忌讳拿到系统就埋头写用例。博客系统的功能看起来散，但背后是有几条核心业务链路串着的。我接到任务后的第一件事，不是打开界面点点点，而是把系统拆了一遍。

1.1 功能架构拆解与测试范围划分

我习惯把博客系统分成三块来看：用户前台、管理后台、公共基础能力。这种划分不是拍脑袋，而是每一块的测试目标和风险特征完全不一样。

用户前台面向的是匿名或普通注册用户，核心链路是“浏览-检索-互动”。文章列表、文章详情、分类标签、归档页、全文搜索、评论、点赞、登录注册、RSS订阅、个人主页，这些功能直接影响读者体验，任何一个环节404或者交互失灵，用户立刻就能感知。管理后台面向的是作者和管理员，核心链路是“创作-发布-运维”。文章管理、分类管理、评论审核、用户管理、媒体库、系统设置，这些功能用的人少，但一出问题就是批量事故，比如误删文章、权限穿透。公共基础能力则是两者都要依赖的底座，包括用户鉴权、接口幂等性、分页逻辑、异常兜底、文件上传下载、操作日志，这类问题通常不会在单次操作里暴露，而是要在特定边界条件下才会现形。

我按这个结构画了一张测试范围与优先级对照表，直接把排期和人力往重点模块倾斜：

1.2 测试策略选型：流程优先，边界兜底

定了范围就要定策略。我在这套博客系统上采用的核心思路是八个字：流程优先，边界兜底。

为什么不做“界面全覆盖”？因为博客前台的UI改动频率高、视觉细节主观性强，把大量人天砸在按钮颜色和间距上，投入产出比很低。我要优先保障的是内容生产到消费这条主链路的完整性：作者写一篇文章，保存草稿，预览，发布，前台能看到，分类标签正确，评论能进来，作者能回复审核，这是一个完整的商业闭环。链路中任何一个环节断裂，影响的是整个系统的核心价值。所以我的用例设计顺序是：先把端到端主流程跑通，再逐模块补边界、补异常、补安全。

自动化策略也是同样的逻辑。接口层用脚本覆盖逻辑分支和异常场景，效率高、反馈快；UI层只覆盖三条真正的端到端主流程：登录后发布文章、前台查看文章、后台审核评论。其余的UI细节全部手工过。这样既不重复造轮子，也不会等自动化脚本跑完才发手工测试，两头都兼顾。

这套策略适合什么项目？所有“功能多但不深、用户广但交互简单”的内容类系统都适用。它解决的核心问题是如何在有限排期内把风险最高的链路测透，而不是把时间平均分给每个按钮。如果你手头也是一个博客、论坛、CMS类的项目，建议直接照这个思路来。

2. 核心功能测试用例设计与实操要点

范围定了以后，就要一个一个模块去磨用例了。这里我不打算把几百条用例全部罗列出来，那既啰嗦也没人看。我挑博客系统里最容易出事、也最能体现测试功力的几个模块，讲讲设计用例时脑子里应该琢磨的那些事。

2.1 文章发布与编辑的用例设计

文章发布是博客的心脏，也是用例设计的重头戏。它涉及的字段多、状态多、组合也多，不能用最朴素的“填完表单点提交”来cover。我的经验是把字段、状态、数据特征三个维度拆开，再相互组合。

字段维度上，标题、正文、封面图、分类、标签、摘要、置顶开关、可见性（公开/私密/加密）、定时发布时间，每个字段都至少要有一组正常值和一组边界值。比如业务约定标题最大80个字符，那么80字符是正常边界，81个字符是异常边界，0字符即空标题要断言是否拦截，标题如果允许特殊字符如引号、尖括号，还要额外检查渲染层有没有被转译。正文空内容能不能发布、封面图不传能不能发布、定时发布时间设为昨天会发生什么，这些都属于发布逻辑中用户很容易误触的场景，要重点验证系统是给了友好提示还是抛了一个500。

状态维度上，草稿保存后不丢失、草稿转发布、发布后编辑、编辑后回显、下线后前台隐藏、删除后走回收站、回收站恢复，这一串状态流转要形成闭环。特别要提醒的是并发编辑场景：A和B两个作者同时打开同一篇文章，A先保存，B再保存，第二个人的提交是覆盖了A的内容还是系统给出了冲突提示？很多博客系统在这一点上没做乐观锁，功能测试如果不写这个用例，上线后就是编辑互相覆盖的真实事故。

数据维度上，我特别建议用脚本批量构造数据来测。比如文章列表分页每页10条，我直接往库里插入37篇文章，再从前台翻页，看第4页是7条还是3条，最后一页有没有异常空页。这种数据量靠手工点点点要花十分钟，写个循环插入SQL十秒钟就搞定。用工具构造数据不是偷懒，而是把测试重点从“能不能点”转移到“数据边界下逻辑是否正确”。

2.2 评论、点赞与用户交互的边界条件

互动模块是博客区别于普通静态站的核心，也是安全问题高发区。评论的用例我建议从身份、内容、频次、审核状态四个维度来设计。

身份维度上，未登录能不能直接评论、登录后才能评论、第三方登录账号的昵称头像拉取是否正常、评论显示的是昵称还是账号名，这些都要各跑一遍。内容维度上，空评论、纯空格评论、几个字符的超短评论、上千字的长评论、带链接的评论、带emoji的评论、带HTML标签的评论，每条都要验证提交是否成功、前台展示是否正常、恶意脚本是否被转义或拦截。这里必须说一个新手容易忽略的点：带HTML的评论不能只在浏览器里看弹窗出没出现，要用curl或者浏览器看源码，确认标签是被原样输出还是被编码了。很多XSS是藏在属性值里的，比如图片标签的onerror事件，界面上根本看不出异常，只有源码会暴露问题。

频次维度上，同一IP短时间连续评论、同一账号并发点赞、点赞后取消再赞，这些操作测试的就是后端有没有做防刷和幂等。审核维度上要验证待审核评论前台是否不可见、作者审核通过后前台是否可见、作者删除一条评论后它下面的回复如何处理、被删除评论的用户是否会收到通知，等等。

越权测试是互动模块里绝对不能漏的一项。普通用户能不能删除别人的评论、普通用户能不能修改别人的个人资料、普通用户能不能进入后台接口。这些用例在界面上往往没有入口，需要登录两个不同权限的账号，用低权限账号去请求高权限的接口路径来验证。我常用的做法是：浏览器登录管理员账号抓一个修改评论的请求，把token换成普通用户的token再重放一遍，如果接口返回成功，那这就是一个实打实的越权漏洞。

2.3 搜索、分页与列表过滤的“隐形Bug”

搜索和分页属于那种“不在主流程上，一上线就有人用，一用就发现问题”的功能。它们的特点是逻辑藏在后端，界面反馈不直观，Bug也特别容易在测试阶段滑过去。

搜索用例要覆盖的关键词类型包括：正常词、中文词、英文词、大小写混合、带空格、带引号、带百分号和下划线这类SQL特殊字符、带反斜杠、emoji、超长关键词。为什么要覆盖这些？因为很多搜索引擎后端是拼接SQL或者普通索引匹配，遇到特殊字符就报错，遇到超长关键词会超时，遇到中文分词不规范就回忆不出结果。还有排序问题：按相关度、按时间、按阅读量排序，搜索命中后翻页，搜索结果为空时界面的空态提示是否友好，这些都要挨个过。

分页的坑就更多了。我整理了一套常见的分页边界：第一页显示正确、中间页显示正确、最后一页显示条数正确、总页数计算正确、页码传0、页码传负数、页码传字符串、页码超大、每页条数改为0、删除当前页的最后一条数据后页码越界。最后一种情况特别经典：用户在第3页看到最后一条，删掉它，页面刷新后第3页变成空页，是应该自动跳到第2页还是显示“暂无数据”？很多系统在这里直接抛404。这种细节不做针对性设计，手工测试很难覆盖到，等用户遇到就是一条线上反馈。

2.4 后台管理功能的多角色权限验证

后台管理测试的核心不是功能，而是权限。文章管理的增删改查在不同角色下的可见可操作性要设计一张矩阵表：超级管理员、编辑、作者、访客各能做什么，不能做什么，越权操作的返回值是403还是302重定向到登录页。尤其要注意的是“水平越权”和“垂直越权”要分开测，普通用户能不能操作管理员的接口是垂直越权，作者A能不能操作作者B的文章是水平越权，两者都可能出现在同一个接口里。

媒体库的上传功能也有讲究。文件类型限制是否只在前端做了校验、上传超大文件服务端是否拒绝、上传一个改成.jpg后缀的脚本文件能否绕过校验、上传文件名包含中文和特殊字符是否正常、上传后的访问路径是否可控。这些用例不复杂，但每一个都可能演化成安全问题，必须专门设计。

3. 测试执行过程与关键环节实现

用例设计完了，接下来就是真正下场跑测试。这一章我讲一些执行层面的细节：环境怎么搭、数据怎么造、接口自动化怎么和手工测试打配合、兼容性和性能冒烟怎么评估。这些都是实际测试中天天要面对的问题。

3.1 测试环境准备与数据构造

测试环境的准备第一条铁律：独立数据库，绝对不能用生产库，也尽量不要跟开发共用一套库。我经历过测试环境数据被开发本地调试污染、导致整个回归结果无效的情况，从那以后我接手项目的第一件事就是确认环境隔离。博客系统数据量小，SQL文件导入导出非常方便，测试前重置数据成本极低，所以每次执行一轮完整测试前都建议做一次数据初始化。

数据构造要讲究“典型数据代表性”。我通常会准备六类文章：标题超长但仍合法的文章、无封面图只有正文的文章、含Markdown代码块和图片链接的富文本文章、状态为私密的文章、定时发布时间在30分钟后的文章、包含中文长文本和英文混合的文章。评论数据则准备一条带链接的、一条带脚本标签的、一条超过2000字的、一条多级嵌套回复链。这些数据不是随机造的，而是每一条都对应着一组后续要验证的特殊逻辑。把它们提前insert到库里，手工测试时就能直接访问到这些边界状态，不用临时去界面费劲构造。

我还有个习惯：用SQL脚本备份一份“测试基线数据”。每次开始测试前导入一份，测到一半发现数据被污染了，就重新导入恢复。比如测完一遍分页后，我之前插入的37篇文章可能被删掉了，再测列表空态就得重新造数据。有基线数据在手，这些操作都是一条命令的事。

3.2 接口自动化用例与UI主流程的结合

接口自动化我用的是Python加requests，没有引入特别重的测试框架。因为博客系统后端是标准的RESTful接口，用脚本直连接口测逻辑分支，比UI自动化稳定得多，而且执行速度快，非常适合回归。这里分享一个我实际使用的接口用例脚本的简化版本，覆盖文章从创建到删除的完整生命周期：

import requests BASE_URL = "http://test-blog.example.com/api" def test_article_lifecycle(): # 登录获取token resp = requests.post( f"{BASE_URL}/auth/login", json={"username": "test_author", "password": "Test@123"} ) assert resp.status_code == 200, f"登录失败: {resp.text}" token = resp.json()["data"]["token"] headers = {"Authorization": f"Bearer {token}"} # 创建文章 create_data = { "title": "接口自动化测试文章", "content": "这篇是用requests创建的正文内容", "category_id": 2, "tags": ["自动化", "博客测试"], "status": "published" } resp = requests.post(f"{BASE_URL}/articles", json=create_data, headers=headers) assert resp.status_code == 201, f"创建失败: {resp.text}" article_id = resp.json()["data"]["id"] # 查询文章详情，校验标题字段 resp = requests.get(f"{BASE_URL}/articles/{article_id}") assert resp.status_code == 200 assert resp.json()["data"]["title"] == "接口自动化测试文章" # 更新文章，改成草稿状态 resp = requests.put( f"{BASE_URL}/articles/{article_id}", json={"status": "draft"}, headers=headers ) assert resp.status_code == 200 assert resp.json()["data"]["status"] == "draft" # 删除文章 resp = requests.delete(f"{BASE_URL}/articles/{article_id}", headers=headers) assert resp.status_code == 204 # 删除后再查，预期404 resp = requests.get(f"{BASE_URL}/articles/{article_id}") assert resp.status_code == 404 print("文章生命周期接口用例通过") if __name__ == "__main__": test_article_lifecycle()

这套脚本我大概写了三十多条，覆盖文章、评论、用户、分类几大模块的正常与异常分支。UI自动化我只留了三条Selenium主流程脚本：登录后台发布一篇文章、前台浏览文章并翻到第二页、后台审核一条待审评论。剩下的全手工慢跑。这样组合下来，发现Bug的数量和效率都不差，而且回归时接口那部分几乎是零成本执行。

3.3 兼容性测试与性能冒烟

兼容性测试在博客系统上主要是浏览器和终端适配的验证。前端技术栈是Vue加一个基于CodeMirror的Markdown编辑器，所以我的验证矩阵是Chrome最新版、Edge最新版、Firefox最新版、Safari移动端。重点盯三处：富文本编辑器能否正常唤起、上传封面组件能否正常选择文件、列表页的分页组件左右箭头是否显示异常。其他页面只要主流程能走通就不逐页过，这是排期有限下的合理取舍。

性能这块我做的不是压测，而是“性能冒烟”。我会关注几个关键接口的响应时间：首页文章列表、文章详情、搜索接口、登录接口。方法很简单，用curl加上time统计请求时长，连发20次看平均值和最大值。如果均值超过800毫秒就要警惕了。我当时测出搜索接口平均响应时间到了1.4秒，查下去发现是搜索的SQL没有命中索引，like前面的通配符导致全表扫描。加了一个全文索引之后，响应降到200毫秒以内。这个例子说明，功能测试阶段顺手做一下响应时间检查，能提前拦截很多线上性能问题。

并发场景我不建议用复杂工具，简单用ab或者Python的多线程发几个请求就够了。重点看两类接口：一是点赞和阅读数这类计数器接口，并发下数字是否准确、是否出现负数；二是评论提交接口，同一用户并发提交多条，是否有重复或者丢失。

3.4 数据一致性验证

这一节我想专门拿出来说，因为博客系统这种内容管理应用，最容易出现“界面能看，数据是脏的”的情况。我在测试中特意设计了一批数据一致性场景：发布一篇文章后前台标题和后台编辑页标题完全一致，不能有转义差异；评论通过审核后，审核状态字段、前台可见性、评论计数三个数据同步更新；删除一篇带封面图的文章时，封面图文件是否从存储中一并清除，还是留下孤儿文件；修改文章分类时，旧的分类计数和新分类计数是否正确调整。

这些场景容易出Bug，根源在前后端数据状态不同步。我的验证方法也很笨但很有效：操作完界面后，直接查数据库对应表的数据，一条条比对字段。比如前台评论计数显示5，数据库里该文章的评论数字段就应该是5，这两个数字对不上就说明数据链路有断点。测试人员养成查库的习惯，能比开发更早发现这类深层问题。

4. 常见问题与排查技巧实录

测试执行过程中，我踩了不少坑，也积累了不少排查经验。这一章我挑最有代表性的几个问题写出来，每一个都是真实发生过的，建议直接收进你的问题速查手册。

4.1 典型Bug实录：字符集、XSS、越权

第一个经典Bug是中文乱码。现象是后台发布一篇中文标题的文章，前台页面标题显示成“????”或者一串乱码。第一反应是数据库字符集问题，查下去发现MySQL表是utf8mb4，连接串也配了utf8，后台表单也声明了UTF-8，那问题出在哪？最后定位到是后端接口返回的HTTP响应头里没有显式带charset=utf-8，而前端页面声明的编码和接口实际返回的编码不一致，浏览器就按默认解码导致乱码。这个Bug排查起来很绕，因为三个环节单独看都是对的，组合在一起就是错的。

排查方法值得记一下。先用curl -I看接口响应头的Content-Type字段，再用mysql客户端直接查询库里存的中文数据是否正常，最后在浏览器里看页面的meta charset声明。三步走完基本能定位是哪一个环节出了问题。

第二个是评论XSS。我提交了一条包含图片标签的评论：

<img src=x onerror=alert(document.cookie)>

浏览器打开评论列表，没有弹出弹窗。但用curl抓详情页HTML源文件，发现这个标签原样输出了，只是onerror事件没有触发。这就说明后端没有对脚本做转义，当前浏览器版本恰好像素错误场景没触发，换一个浏览器或者换个攻击向量就可能被利用。这种Bug必须从源码层面验证，界面看不出来不代表安全。后来开发在输出评论内容的地方加了转义函数，再抓源码标签变成编码后的实体，才彻底关掉这个口子。

第三个是越权漏洞，也是这轮测试里严重级别最高的一个发现。我用作者账号创建一个文章，再用另一个作者账号登录，直接构造PUT请求去更新前一个作者的文章接口，服务端返回200成功。这说明后端在更新文章时只校验了登录状态，没有校验当前用户是否为文章作者。这就是典型的水平越权。这种漏洞在界面上根本无法操作到，因为前台编辑按钮只出现在作者本人看得到的地方，是接口层的直连才测出来的。自查的时候，把这类接口按业务动作列一张清单，然后逐一用低权限账号重放，是最高效的办法。

4.2 排查方法与工具组合

排查测试问题我有一套固定的工具组合。抓包主要用浏览器DevTools和Charles，浏览器看Web请求够用，移动端调试就代理到Charles。日志排查用命令行组合，后端日志定位报错位置，前面再辅助抓包确认参数。

我举一个组合排查的实例。前台某篇文章点击保存后一直转圈，控制台报500。我先在DevTools里看请求的Payload，发现正文内容里有一串很长的Base64图片数据。然后登录服务器grep后端日志，关键字定位到Nginx报413 Request Entity Too Large。再查Nginx配置，默认client_max_body_size是1M，而文章正文提交的数据超过4M。修复方法是调大body大小限制并配合后端检查上传文件大小做双重校验。整个过程十五分钟定位完成。没有日志，这个Bug就只能靠猜。

排查时可以多用几个标准命令：

# 查看接口响应头，确认编码和缓存策略 curl -I http://test-blog.example.com/api/articles/123 # 实时跟踪后端应用日志中的异常关键字 tail -f /var/log/blog-app/error.log | grep -E "ERROR|Exception" # 在MySQL中直接核对数据状态 mysql -u tester -p blog_test -e "SELECT id,title,status FROM articles WHERE id=123;"

4.3 回归测试的坑与处理

回归测试是整个测试流程里最容易让人心烦的阶段。一个Bug修完，开发说“我就改了两行代码”，但实际影响面可能有半个系统。我见过太多次“修复了一个Bug，引入三个新Bug”的情况。

我的回归策略是三层递进。第一层是接口回归，三十多条脚本全跑，半小时内出结果，保证核心逻辑没被改动破坏。第二层是核心手工用例回归，登录、发文、前台浏览、评论审核这些主流程全部过一遍，这个阶段不需要执行全量用例，只跑P0级别。第三层才是针对本次修复的定向验证，把修复的Bug单号对应的复现用例重测一遍，同时把相邻模块的相关场景也顺带检查。比如开发修改的是文章分页逻辑，那我不光要测翻页，还要测排序、筛选、搜索这些跟列表数据有关的场景。

还有一个特别容易踩的坑是缓存导致的环境问题。前后台通过Redis缓存文章列表，我这边在后台把一篇文章改了标题，前台刷新还是旧标题。当时差点报一个回归Bug，后来查证是Redis key没有及时失效，属于缓存一致性问题，不是代码逻辑缺陷。这个经历提醒我，遇到测试环境和预期不符，先排查缓存，再怀疑代码。我自己习惯在测试环境的Redis里手动执行flushdb，避免缓存数据干扰测试判断。

4.4 常见问题速查表

我把这一轮测试中遇到的高频问题整理成了速查表，新同学接手的时可以直接对照着查：

5. 测试报告怎么写才有说服力

测试做得再好，报告写得稀烂，价值也会打折扣。功能测试报告不是简单堆一堆“几个通过几个失败”，而是要回答三个核心问题：质量怎么样、敢不敢上线、遗留问题怎么办。这一章我讲讲我写报告的思路和结构。

5.1 测试报告的核心指标与结构框架

我的博客系统测试报告一般分六个段落：项目概述、测试范围与执行情况、用例统计、缺陷分析与风险评估、遗留问题清单、测试结论。

项目概述部分写清测试对象、测试环境、测试周期、参与人员，两三段话交代清楚，不要写废话。测试范围和执行情况要和第一部分的需求拆解呼应，写明哪些模块测了、哪些模块在本次范围内不做深测、自动化脚本覆盖了多少条接口用例。用例统计部分直接上表格：

表格只是数据，重点是表格后面的解读。比如“搜索分页模块用例通过率只有71%，原因是分页边界保护未实现，集中在页码越界和删除末页数据后跳转异常两个根因”。这种表述比单纯甩一个百分比有说服力得多。

5.2 缺陷分析：用数据说话，而不是形容词

缺陷分析是报告里承上启下的部分。我用三个维度来切：按模块分布、按严重级别分布、按发现阶段分布。

严重级别定义是报告里必须写清楚的东西。我一般分四级：致命（系统崩溃、数据丢失、越权漏洞）、严重（核心功能不可用、主流程中断）、一般（功能可用但结果不符合预期）、轻微（界面瑕疵、文案错误）。这轮的缺陷分布是致命2个、严重8个、一般16个、轻微14个。致命2个全是越权问题，这说明权限校验框架层存在系统性风险，不是单个接口的偶发缺陷，修复之后必须做全接口权限回归。

按模块分布最能说明“问题集中在哪”。我报告里写了“评论互动模块缺陷数占总量25%，其中防刷机制缺失和状态不同步占该模块缺陷的60%”，后面直接对接了遗留风险：“若本轮遗留的评论防刷缺陷不作修复，上线后可能面临垃圾评论灌入风险，建议P1级别修复。”这种写法是把测试发现和业务风险直接挂钩，开发看了没法不重视。

5.3 上线结论怎么下：有数据、有条件、有底线

报告的最后要给出上线结论。这一块我特别强调要有条件、有底线，不要给模棱两可的“基本通过”。我习惯写“有条件通过”加三个条件：致命缺陷全部修复并验证通过；严重缺陷完成修复或者给出明确的风险规避措施；遗留的一般缺陷登记在案，明确修复时间窗口。

如果致命缺陷没有全部修复，我绝不会签字“通过”。博客系统公网部署，越权漏洞意味着任意用户都可以删除他人文章、修改他人资料，这种系统上线是拿公司信誉开玩笑。测试人员的底线就是守住这一类上线红线。反过来说，轻微的UI瑕疵不应该成为阻塞上线的理由，该放手时也要果断放手。

5.4 报告中的几个具体技巧

报告写作我有几个自己的小技巧。一是结论前置，开头一段话先写最终结论和最关键的风险，让老板不用翻到最后一页就能知道重点。二是Bug单编号要在报告里关联上，每个重要结论后面跟上Bug单号，方便开发和运营直接追溯。三是多放截图和数据对比，比如修复前后的接口响应时间对比图、缺陷趋势的单日新增和关闭曲线，一图顶千言。四是遗留问题清单里每一项都要写明影响范围、触发条件、建议修复优先级和预计修复时间，没有修复时间的遗留问题等于没写。

提示：测试报告是测试人员和开发、产品、管理层沟通的唯一正式交付物。报告里每一条结论都要能从用例记录和Bug单找到出处。含糊其辞的“感觉还行”在报告里没有任何价值，既害了项目也伤了自己的专业信誉。

结尾

写到这里，博客系统这轮功能测试的核心内容差不多都讲完了。最后分享一个我印象很深的经历。上线前最后一轮回归，凌晨三点左右，我按分页边界用例去点“删除当前页最后一条数据”，结果页面直接白屏报错。这个场景我前面用例设计时单独列过，执行时也因为数据构造麻烦差点跳过。那一刻我特别庆幸自己没偷懒。从那以后，凡是列表页涉及数据增删后的行为，我都会当成一条独立的用例去测，不看界面“看起来正常”就放行。另外再送一个实用小技巧：功能测试阶段，让开发把后端接口日志级别调到DEBUG，线上出问题的时候排查速度会快很多。日志是测试人员最好的朋友，但前提是它真的把关键信息打出来了。