从“ceshi”项目看软件测试：用例设计、环境治理与回归实战

“ceshi”这个名字看起来有点潦草其实是我早年一个内部项目的代号。当时团队急着赶版本谁也没心思给项目起个正经名字随手就打上了“测试”的拼音。但这个随手命名的项目最后却成了我梳理整套测试流程的起点。做测试这件事很多人觉得就是“点一点、看看有没有报错”可真把一个测试项目从头做到尾你会发现它远比想象中复杂——要拆需求、设计用例、搭环境、做回归、写报告任何一个环节偷懒上线之后都会用事故的方式还回来。这篇文章我想用“ceshi”这个项目作为例子完整讲讲我是怎么做测试的怎么把需求拆成可验证的用例怎么设计正常流、异常流和边界流怎么保证测试环境不坑人以及我踩过的那些“测了跟没测一样”的坑。不管你是刚入行的测试新人、身兼数职的开发还是被迫兼职测试的产品经理这套思路应该都能直接用上。1. 测试这件事到底在测什么1.1 测试不是找bug而是建立信心很多人对测试的第一反应是“找bug”这话对了一半。找bug只是手段测试真正的目的是建立信心——让团队有底气说“这个功能在真实场景下能正常工作”。我在“ceshi”项目里最深刻的一个体会是如果测试只是为了证明“有bug”那测完只会收获一堆问题清单但如果你带着“用户这么操作会不会挂”的视角去测收获的会是一张可以放心上线的通行证。这两种心态差别很大。前者容易让人陷入“为了提bug而提bug”的怪圈测出来的问题又多又碎开发看了只想摔键盘后者则要求你先理解业务、理解用户、理解系统边界然后设计出真正有杀伤力的用例。同样是测一个登录功能前者可能只是“输入正确账号密码能不能登录”后者会追问“密码错误五次会不会锁定”“验证码过期了再提交会怎样”“跨设备登录要不要踢掉旧会话”。这些追问才是测试价值的来源。“ceshi”项目当时是一个后台管理系统功能不算复杂但权限模型很绕。我一开始也犯过傻拿着功能列表一个个点测了半天自我感觉良好结果一冒烟测试就翻车——有个角色的菜单权限配错了我压根没覆盖到那条路径。从那之后我意识到测试的核心不是“点得够不够多”而是“有没有系统性地想清楚测什么、为什么这么测”。1.2 五个测试层级功能、边界、异常、性能、回归我习惯把测试拆成五个层级每个层级解决一类问题。这个框架不是教科书里抄来的是我在项目里反复被坑之后总结出来的分别对应“功能对不对”“边界稳不稳”“异常顶不顶”“扛不扛得住”“改了会不会坏”五个问题。测试层级核心问题典型场景我的建议功能测试功能对不对登录、增删改查、流程流转先保证主流程跑通再补分支边界测试边界稳不稳最大字符数、最大条数、空值、超长值最容易暴露隐藏缺陷别偷懒异常测试异常顶不顶断网、超时、重复提交、权限不足模拟用户乱操作和系统级故障性能测试扛不扛得住并发登录、大列表加载、大量数据导出不一定要压测平台脚本也能跑回归测试改了会不会坏新功能上线后检查老功能优先级高的核心用例固定回归这五个层级不是每次都要做全套。小改动、小迭代功能加回归就够了涉及到核心链路、大版本升级五个层级都得过一遍。“ceshi”项目每次发版前我都有个固定动作把五层测试的checklist拉出来逐项确认哪些做、哪些不做、为什么不做的理由是什么。这个动作看着笨但能避免很多“我以为不用测”的事故。1.3 为什么很多项目“测了跟没测一样”说实话我在“ceshi”项目里最常听到的一句话就是“测了呀但没发现这个问题”。测了跟没测一样原因通常逃不出这三个。第一个是用例设计太粗糙只会照着需求文档写正向步骤文档说“输入用户名密码点击登录”用例就只写这一条完全没考虑用户不会按你的剧本走。第二个是环境不一致开发在自己电脑上测的是本地库测试在测试环境测的是另一套数据两边结果对不上出了问题谁也说不清。第三个是回归不充分新功能测得很仔细老功能直接跳过结果新代码一改旧接口悄悄挂了。这三个问题的根源都指向同一个词系统性。“ceshi”项目后期我把用例管理、环境规范、回归清单都固化成了文档和模板从那之后“测了跟没测一样”的情况明显少了很多。测试最怕的不是测出bug而是稀里糊涂地测完完全不知道哪里没测。2. 动手之前先把测试用例设计清楚2.1 需求拆解从功能描述里挖出隐藏条件测试用例的质量七成取决于需求拆解做没做透。一个功能描述往往藏着一堆隐藏条件这些条件才是测试的重点。“ceshi”项目里有个“角色权限分配”的功能需求文档就写了一句“管理员可为用户分配角色”听起来很简单对吧但拆解之后能挖出至少八条隐藏规则管理员能不能给自己分配角色角色被分配后已登录用户要不要立即生效同一个用户能不能同时配多个角色被删掉的角色挂在用户身上怎么办权限变更后用户已经打开的页面要不要强制刷新拆解需求的方法是逐词审查。拿到一句话把里面的名词、动词、限定词一个个抠出来问“管理员”是谁普通用户行不行“分配”是一次性操作还是可反复修改“角色”有哪些状态启用、禁用、删除分别怎么处理我习惯做一张需求拆解表左边是原始描述中间是拆出的隐藏条件右边是每条条件对应的用例编号。这张表既是测试设计的依据也是和开发、产品对齐需求理解的工具。很多时候我拿着拆解表去找产品确认对方会愣一下说“这个场景我没想过”然后我们就一起补进需求里——这种协作比单纯提bug有价值得多。2.2 用例设计三件套正常流、异常流、边界流用例设计我从来不照着模板硬写因为模板容易把脑子填满却不告诉你哪些场景值得测。我用的是一个很朴素的三件套思路正常流、异常流、边界流。正常流保证功能能跑通异常流保证功能在用户乱操作时不会出洋相边界流保证功能在极限输入下不会崩。打个比方测一个“上传Excel文件”的功能。正常流是“选一个格式正确的Excel点上传提示成功”异常流包括“上传一个jpg图片”“上传一个空文件”“上传超过10MB的文件”“网络断开时点击上传”边界流则是“文件名含特殊字符”“文件恰好10MB整”“工作表名字超长”“一万行数据的Excel”。我见过很多测试只写正常流异常流靠临场发挥边界流直接放弃这是很危险的。异常流和边界流恰恰是线上事故的高发区——用户不会照着操作手册用你的产品他们会上传奇怪的文件、输入超长的文字、连点十次提交按钮。三件套里后两件才是区分“会用测试”和“不会用测试”的分水岭。2.3 一个实际用例表的写法示例理论讲再多不如直接看一张用例表。下面是我在“ceshi”项目里写过的“用户登录”用例表字段不多但每条用例都能直接执行、直接追溯需求格式上可以做参考。用例编号用例名称前置条件测试步骤预期结果优先级LOGIN_001正确凭证登录成功测试账号已创建输入正确账号密码点击登录登录成功跳转首页高LOGIN_002密码错误提示明确无输入正确账号、错误密码点击登录提示“用户名或密码错误”不跳转高LOGIN_003账号不存在提示明确无输入未注册账号、任意密码提示“用户名或密码错误”不暴露账号是否注册高LOGIN_004密码连续错误5次锁定无连续输入错误密码5次第5次后账号锁定提示联系管理员高LOGIN_005锁定账号无法登录已通过LOGIN_004锁定账号输入正确账号密码提示“账号已锁定”拒绝登录高LOGIN_006空值校验无账号或密码为空点击登录按钮置灰或提示“请输入账号/密码”中LOGIN_007超长账号输入处理无输入超过50位的账号输入框限制长度或提交后明确报错中LOGIN_008登录接口并发重复请求无使用脚本并发发送10次登录请求仅第一次成功其余返回重复提交或排队处理低这个例子里LOGIN_004、LOGIN_005属于典型的状态流转测试因为锁定状态会影响后续登录行为LOGIN_007是边界流LOGIN_008是异常流里偏性能的用例。写用例表的关键不是追求数量而是每条都有独立价值写完自己问一句“这条用例测挂了改动代码的人能立刻明白是哪里出问题吗”如果答案是否定的说明用例写得还不够清楚。3. 一次完整测试实操记录3.1 准备测试环境环境一致性怎么保证很多人觉得测试环境不就是“装个软件连个库”嘛错了。环境不一致是“测了跟没测一样”的头号元凶。“ceshi”项目早期就栽过开发在本地库测得好好的测试环境一跑就报错折腾半天发现测试环境的数据库表结构和代码版本对不上白费了一下午。我后来立了三条规矩照着做基本不会再被环境坑到。第一条测试环境必须和代码版本严格对应每次部署前核对代码分支、构建号、数据库版本号记录在部署文档里防止“代码是最新的、库是老旧的”这种错位。第二条测试数据要可复用、可重置准备一套标准的测试账号和数据每个轮回开始前把库恢复到初始状态确保用例可以重复执行。第三条环境配置要文档化涉及的环境变量、外部服务地址、端口号、mock开关都落到文档里换个人也能把环境搭起来。保持环境干净的另一个细节是数据隔离。不要让测试数据和真实数据混在一起尤其是有定时任务、报表统计的功能测试数据一旦混进去跑出来的报表就会很奇怪而且很难查清楚。我在“ceshi”项目里专门用一个标识字段标记测试数据所有查询、统计类功能测试都用这套带标识的数据测完一键清理。3.2 执行测试抓bug要记录哪些信息进入执行阶段最大的考验不是“发现了bug”而是“把bug描述清楚”。说了你都不信见过太多“点了一下就报错了你们自己看看”这种bug描述开发收到这种反馈连环境都复现不了只能干瞪眼。我在“ceshi”项目里要求每条bug至少包含六个信息操作步骤、实际结果、预期结果、环境信息、数据信息、复现概率。缺一个开发就有理由把bug打回来。操作步骤要一步步写清楚最好精确到“点了哪个按钮、输入了什么值、停留了几秒”不要省略“中间等了一会儿”这种看似无关的动作实际结果要写现象报错截图、接口返回、页面表现都行预期结果写“本来应该怎么样”环境信息写浏览器版本、系统版本、代码版本数据信息写当时用的账号和测试数据复现概率写“必现”还是“偶现”偶现的还要记录当时的大概状态比如是内存占用高的时候还是首次加载的时候。这里插一句责任心比技巧更重要。发现bug之后我一般会先自己复现一遍再想办法缩小触发条件。有一次我为了定位一个偶现的白屏问题反复刷新了几十次最后发现是每次都先快速切换两次菜单再进入某个页面才触发。这种复现路径写在bug单里开发修起来效率极高对我的信任也一下子建立起来了。3.3 回归测试改一处可能坏一片回归测试是测试流程里最容易被压缩、也最不该被压缩的环节。项目越到后期功能之间的耦合越深“改一处坏一片”不是段子是每天都会发生的事。“ceshi”项目里有一次开发只是改了“用户列表”的查询SQL结果“导出用户数据”功能跟着报错因为导出模块复用了同一段查询逻辑。我的做法是维护一张核心回归用例清单这张清单不追求全但覆盖所有重要的主流程和核心链路数量控制在几十条以内确保每次发版前能在半小时内手工跑完。清单用优先级标记用例P0级是“不做就出事”的用例比如登录、支付、数据保存P1级是“出错会造成较大影响”的用例比如报表查询、权限变更P0和P1优先保证P2视时间安排。回归测试还有个容易被忽略的重点不仅仅是点一遍就完事。“ceshi”项目里我会把本次发版涉及改动模块的关联用例单独加强执行比如改动权限模块就用例把“不同角色登录后看到的菜单”“同一个操作不同角色的权限表现”这种关联场景重新过一遍。光靠手动点击做回归很累一旦出现频繁发版建议尽快把P0用例自动化虽然前期投入大但后面每次发版节省的时间远超出投入。4. 常见问题与排查技巧实录4.1 “怎么我测不出来bug”的四个原因经常有新人问我“我按用例测了为什么还是没发现问题”这个问题我太有共鸣了因为我也是在“测不出bug”这件事上栽过跟头的人。后来我总结出四个最常见的原因每一条都对应一种思维转变。第一个是只测happy path照着需求文档一步步走所有操作都按照产品预设的正常路径来这样测出来的当然是好的系统。第二个是边界值用得太保守比如输入框限制50个字你填了49个觉得差不多了但其实真正该测的是50个、51个、空值、纯空格、超长中文字符。第三个是状态变化没测透很多bug出在“先后顺序”上比如先做了A操作再做B操作和先做B再做A结果完全不同只测一种顺序就发现不了。第四个是缺乏怀疑精神看到页面显示成功就以为真的成功了没有去数据库确认数据到底有没有写进去也没有验证返回的接口是不是真的符合预期。我记得有一回测“批量删除”功能界面上确实提示“删除成功”但一刷新数据又回来了——问题出在后端根本没执行删除只返回了一个成功标志。如果只看页面这就是一条怎么测都测不出来的bug。从那以后我多了个习惯页面验证永远只是第一层数据层面、接口层面的验证才能给出确凿答案。4.2 测试环境与生产环境不一致怎么办环境不一致是测试领域最经典的老大难问题。我遇到过的情况包括测试环境的数据库里少了一张新表导致功能直接白屏生产环境用的是CDN缓存测试环境没有导致某些静态资源加载效果完全不同还有连接的外部服务在测试环境是mock的生产环境却是真实的mock时一切正常一上线就暴露出超时和异常处理问题。碰到这种问题我的第一原则是“尽早承认环境差异并在测试计划里写明哪些差异是已知的、接受的风险是什么”。你不可能把测试环境做到和生产100%一致但你可以尽量逼近同时明确剩下的差异。比如数据库表结构严格保持一致外部服务除了下游权限受限的其余都尽量走真实调用只在必须mock的地方mock并且把mock行为和真实行为的潜在差异标识出来。另外推荐一个低成本高收益的办法做一次上线前的生产环境冒烟测试。在流量比较低的时候挑核心链路在生产环境跑一遍关键用例时间控制在十几分钟以内既不会影响真实用户又能提前发现“测试环境一切正常、生产环境一跑就挂”的问题。“ceshi”项目上线前团队靠这个动作拦下过两个很隐蔽的配置问题价值远大于花在冒烟测试上的那点时间。4.3 用例遗漏的补救方法无论用例设计得多完善总有漏掉的情况。漏掉本身不可怕可怕的是漏掉之后不知道怎么补救、也不知道怎么防止再漏。“ceshi”项目里我常用的补救方法有三个都挺实用。第一个是跟着bug清单反查用例。每个线上反馈的bug、每个测试中发现的漏网bug都回头看看用例集里是否缺少对应的用例缺了就补进去形成“发现一个、补一个、固化一个”的闭环。第二个是请旁观者来做一次测试。我会邀请不太熟悉这个模块的同事拿着需求文档自己走一遍因为旁观者没有我脑子里那些“这个功能应该是这样”的先入为主更容易发现我从没想过要测的场景。第三个是复盘线上事故。每一次线上事故都是最珍贵的用例素材来源把这些场景写进回归清单下次就不会再犯。我还会周期性对整个测试集做“冗余审查”有些用例写完之后可能随着需求变更已经失去意义或者和其他用例重复了这种情况留着既浪费执行时间又干扰重点及时删掉才能保持用例集的高信噪比。维护用例集和程序员重构代码很像——不断删除无效表达留下来的才都是精华。4.4 问题速查表常用排查思路最后把我常用的排查思路做成一个速查表遇到问题可以先按图索骥不用每次都从头开始折腾。现象优先排查方向具体动作我的经验备注功能报错或白屏前端控制台报错打开浏览器开发者工具看Console和Network先分清前端报错还是后端接口报错接口返回异常后端日志查看请求参数、返回体、服务端日志堆栈带token或身份的请求先确认凭据是否有效数据不对数据库核对用同一个操作对应的SQL查询库里数据加筛选条件防止测试数据混入报表偶现问题复现路径记录操作顺序、间隔时间、当时数据量多复现几次缩小触发条件范围部署后新增功能异常版本一致性核对代码分支、构建号、数据库迁移脚本最常见的是库没跑迁移脚本慢或者超时性能分析观察接口耗时、数据库慢查询、外部调用时长先确定瓶颈在外部接口还是内部逻辑这个表不是万能的但它能在你脑子里一片空白的时候给你递一个抓手。遇到问题先按表排查排查不出来再说——大部分问题到不了“排查不出来”那一步多的是在第二步就已经定位了。做测试这些年我最深的体会是测试不是一个把功能“点一遍”的任务而是一整套系统性的思考方式。从需求拆解到用例设计从环境准备到bug描述每个环节都有它的方法论和坑。回到“ceshi”这个随手命名的项目它让我明白了一件事——给项目起什么名字不重要重要的是你有没有真的把它当成一个需要认真对待的测试过程。你把测试当回事它就会在你上线的那一刻回报你你不把测试当回事它就会在用户的手上报复你。