博客系统功能测试我这两周的项目就是它。刚拿到任务的时候有同事跟我说博客系统有什么好测的不就是发文章、看文章、留评论吗功能列表一页纸都写不满。等我把需求文档逐条过完、把前后端代码翻了一遍之后才发现这种“看起来简单”的内容管理系统恰恰是测试最容易翻车的类型。内容模型、用户体系、评论互动、富文本编辑器、文件上传、权限控制、搜索检索任何一个模块单独拎出来都能写一屏测试用例再加上博客天生就是公网部署、匿名访问、面向全网用户的形态测漏一个越权或者XSS上线之后就不是Bug而是事故。这篇稿子我就把整个博客系统功能测试的过程完整摊开讲从需求拆解和测试策略怎么定到核心功能的用例设计、执行过程中的工具和数据准备再到我实际踩过的坑和排查思路最后讲讲测试报告怎么写才能让开发心服口服、让老板敢签字上线。无论你是刚入行的测试新人还是被临时拉去“支援”博客项目的开发同学这套思路都可以直接套用。1. 博客系统测试的整体设计与思路拆解测试最忌讳拿到系统就埋头写用例。博客系统的功能看起来散但背后是有几条核心业务链路串着的。我接到任务后的第一件事不是打开界面点点点而是把系统拆了一遍。1.1 功能架构拆解与测试范围划分我习惯把博客系统分成三块来看用户前台、管理后台、公共基础能力。这种划分不是拍脑袋而是每一块的测试目标和风险特征完全不一样。用户前台面向的是匿名或普通注册用户核心链路是“浏览-检索-互动”。文章列表、文章详情、分类标签、归档页、全文搜索、评论、点赞、登录注册、RSS订阅、个人主页这些功能直接影响读者体验任何一个环节404或者交互失灵用户立刻就能感知。管理后台面向的是作者和管理员核心链路是“创作-发布-运维”。文章管理、分类管理、评论审核、用户管理、媒体库、系统设置这些功能用的人少但一出问题就是批量事故比如误删文章、权限穿透。公共基础能力则是两者都要依赖的底座包括用户鉴权、接口幂等性、分页逻辑、异常兜底、文件上传下载、操作日志这类问题通常不会在单次操作里暴露而是要在特定边界条件下才会现形。我按这个结构画了一张测试范围与优先级对照表直接把排期和人力往重点模块倾斜模块典型功能风险等级测试优先级前台-文章消费列表、详情、分类标签、归档高P0前台-互动评论、点赞、登录注册高P0前台-检索全文搜索、分页高P0后台-创作文章增删改、草稿、定时发布高P0后台-管理用户权限、评论审核、媒体库高P0基础-安全越权、XSS、CSRF高P0基础-兼容浏览器适配、移动端自适应中P1基础-性能接口响应、慢SQL、并发中P11.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: Test123} ) assert resp.status_code 200, f登录失败: {resp.text} token resp.json()[data][token] headers {Authorization: fBearer {token}} # 创建文章 create_data { title: 接口自动化测试文章, content: 这篇是用requests创建的正文内容, category_id: 2, tags: [自动化, 博客测试], status: published } resp requests.post(f{BASE_URL}/articles, jsoncreate_data, headersheaders) 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}, headersheaders ) assert resp.status_code 200 assert resp.json()[data][status] draft # 删除文章 resp requests.delete(f{BASE_URL}/articles/{article_id}, headersheaders) 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响应头里没有显式带charsetutf-8而前端页面声明的编码和接口实际返回的编码不一致浏览器就按默认解码导致乱码。这个Bug排查起来很绕因为三个环节单独看都是对的组合在一起就是错的。排查方法值得记一下。先用curl -I看接口响应头的Content-Type字段再用mysql客户端直接查询库里存的中文数据是否正常最后在浏览器里看页面的meta charset声明。三步走完基本能定位是哪一个环节出了问题。第二个是评论XSS。我提交了一条包含图片标签的评论img srcx onerroralert(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 id123;4.3 回归测试的坑与处理回归测试是整个测试流程里最容易让人心烦的阶段。一个Bug修完开发说“我就改了两行代码”但实际影响面可能有半个系统。我见过太多次“修复了一个Bug引入三个新Bug”的情况。我的回归策略是三层递进。第一层是接口回归三十多条脚本全跑半小时内出结果保证核心逻辑没被改动破坏。第二层是核心手工用例回归登录、发文、前台浏览、评论审核这些主流程全部过一遍这个阶段不需要执行全量用例只跑P0级别。第三层才是针对本次修复的定向验证把修复的Bug单号对应的复现用例重测一遍同时把相邻模块的相关场景也顺带检查。比如开发修改的是文章分页逻辑那我不光要测翻页还要测排序、筛选、搜索这些跟列表数据有关的场景。还有一个特别容易踩的坑是缓存导致的环境问题。前后台通过Redis缓存文章列表我这边在后台把一篇文章改了标题前台刷新还是旧标题。当时差点报一个回归Bug后来查证是Redis key没有及时失效属于缓存一致性问题不是代码逻辑缺陷。这个经历提醒我遇到测试环境和预期不符先排查缓存再怀疑代码。我自己习惯在测试环境的Redis里手动执行flushdb避免缓存数据干扰测试判断。4.4 常见问题速查表我把这一轮测试中遇到的高频问题整理成了速查表新同学接手的时可以直接对照着查问题现象排查入手点常见根因中文乱码响应头、数据库字段、页面charset编码不一致前台和后台数据不一致Redis缓存、数据库字段状态缓存未失效图片上传失败Nginx日志、上传组件报错、文件大小body大小限制评论提交后前台不可见审核状态、缓存、接口返回状态未同步分页删除最后一条报404页码计算逻辑、空页处理缺少越界保护接口返回500后端异常日志、请求Payload参数格式不符搜索结果缺失SQL语句、索引、分词规则索引失效5. 测试报告怎么写才有说服力测试做得再好报告写得稀烂价值也会打折扣。功能测试报告不是简单堆一堆“几个通过几个失败”而是要回答三个核心问题质量怎么样、敢不敢上线、遗留问题怎么办。这一章我讲讲我写报告的思路和结构。5.1 测试报告的核心指标与结构框架我的博客系统测试报告一般分六个段落项目概述、测试范围与执行情况、用例统计、缺陷分析与风险评估、遗留问题清单、测试结论。项目概述部分写清测试对象、测试环境、测试周期、参与人员两三段话交代清楚不要写废话。测试范围和执行情况要和第一部分的需求拆解呼应写明哪些模块测了、哪些模块在本次范围内不做深测、自动化脚本覆盖了多少条接口用例。用例统计部分直接上表格模块用例总数通过失败阻塞文章管理867952评论互动524462用户权限383071搜索分页282062后台管理453951基础安全251780兼容性181530合计292244408表格只是数据重点是表格后面的解读。比如“搜索分页模块用例通过率只有71%原因是分页边界保护未实现集中在页码越界和删除末页数据后跳转异常两个根因”。这种表述比单纯甩一个百分比有说服力得多。5.2 缺陷分析用数据说话而不是形容词缺陷分析是报告里承上启下的部分。我用三个维度来切按模块分布、按严重级别分布、按发现阶段分布。严重级别定义是报告里必须写清楚的东西。我一般分四级致命系统崩溃、数据丢失、越权漏洞、严重核心功能不可用、主流程中断、一般功能可用但结果不符合预期、轻微界面瑕疵、文案错误。这轮的缺陷分布是致命2个、严重8个、一般16个、轻微14个。致命2个全是越权问题这说明权限校验框架层存在系统性风险不是单个接口的偶发缺陷修复之后必须做全接口权限回归。按模块分布最能说明“问题集中在哪”。我报告里写了“评论互动模块缺陷数占总量25%其中防刷机制缺失和状态不同步占该模块缺陷的60%”后面直接对接了遗留风险“若本轮遗留的评论防刷缺陷不作修复上线后可能面临垃圾评论灌入风险建议P1级别修复。”这种写法是把测试发现和业务风险直接挂钩开发看了没法不重视。5.3 上线结论怎么下有数据、有条件、有底线报告的最后要给出上线结论。这一块我特别强调要有条件、有底线不要给模棱两可的“基本通过”。我习惯写“有条件通过”加三个条件致命缺陷全部修复并验证通过严重缺陷完成修复或者给出明确的风险规避措施遗留的一般缺陷登记在案明确修复时间窗口。如果致命缺陷没有全部修复我绝不会签字“通过”。博客系统公网部署越权漏洞意味着任意用户都可以删除他人文章、修改他人资料这种系统上线是拿公司信誉开玩笑。测试人员的底线就是守住这一类上线红线。反过来说轻微的UI瑕疵不应该成为阻塞上线的理由该放手时也要果断放手。5.4 报告中的几个具体技巧报告写作我有几个自己的小技巧。一是结论前置开头一段话先写最终结论和最关键的风险让老板不用翻到最后一页就能知道重点。二是Bug单编号要在报告里关联上每个重要结论后面跟上Bug单号方便开发和运营直接追溯。三是多放截图和数据对比比如修复前后的接口响应时间对比图、缺陷趋势的单日新增和关闭曲线一图顶千言。四是遗留问题清单里每一项都要写明影响范围、触发条件、建议修复优先级和预计修复时间没有修复时间的遗留问题等于没写。提示测试报告是测试人员和开发、产品、管理层沟通的唯一正式交付物。报告里每一条结论都要能从用例记录和Bug单找到出处。含糊其辞的“感觉还行”在报告里没有任何价值既害了项目也伤了自己的专业信誉。结尾写到这里博客系统这轮功能测试的核心内容差不多都讲完了。最后分享一个我印象很深的经历。上线前最后一轮回归凌晨三点左右我按分页边界用例去点“删除当前页最后一条数据”结果页面直接白屏报错。这个场景我前面用例设计时单独列过执行时也因为数据构造麻烦差点跳过。那一刻我特别庆幸自己没偷懒。从那以后凡是列表页涉及数据增删后的行为我都会当成一条独立的用例去测不看界面“看起来正常”就放行。另外再送一个实用小技巧功能测试阶段让开发把后端接口日志级别调到DEBUG线上出问题的时候排查速度会快很多。日志是测试人员最好的朋友但前提是它真的把关键信息打出来了。