软件测试入门：测试用例设计、缺陷管理与实战经验总结

实习笔记二测试基础概念、日常操作与前辈传授的那些经验写这篇笔记的时候我已经在测试岗位上待了几周逐步从前两周的“手足无措”过渡到“知道自己在干什么”。上一篇我整理了入职初期的整体感受这篇重点记录我实际接触到的测试基础概念、日常操作流程以及前辈们在我耳边反复强调、后来事实证明每一条都很有用的经验。这篇笔记适合正在实习、准备入行测试或者刚转岗到测试岗位的朋友们。我写的东西不涉及什么高深理论大部分是最贴近日常工作的东西测试用例到底怎么设计才不算漏Bug单怎么写才能不被开发怼回来回归测试和冒烟测试到底有什么区别以及遇到环境问题如何自己先排查一轮。如果你也处在“什么都会一点、什么都不精”的阶段这篇应该能让你少走一些弯路。1. 测试到底在测什么重新理解“找Bug”这件事1.1 我踩过的第一个坑以为测试就是“点点点”很多人对测试的印象停留在“打开APP到处乱点能找到几个崩溃就说明干得不错”。我入职头两天也差不多是这个状态拿到测试任务就顺着功能路径一个一个点看到页面正常显示就算过。结果第一次提交完带我的前辈看了一眼我的用例清单直接问了一句“你这些用例是想证明系统能用还是想证明系统会出错”这句话让我愣了很久。后来我才慢慢明白测试的核心目标不是“证明它能用”而是“证明它还能在哪些情况下不能用”。顺着正常路径点一遍只能覆盖最幸福的那条业务路线一旦用户输入了边界值、走了异常分支、网络中途断开、权限配置不一致系统可能立刻就崩了。而这些都是测试应该提前发现、提前暴露的问题。后来我把这个想法记到了笔记第一页测试是一个“证伪”过程不是“证实”过程。用例设计的目标是想方设法制造出能推翻系统“正常”假设的输入和环境而不是把用户最常用的操作再重复一遍。1.2 需求文档到底该怎么读读需求是我实习前几周的另一个困惑点。在学校里接触的最多的是课程设计题目功能清楚、边界明确照着做就行。到了真实项目里一份需求文档可能有几十页里面还夹杂着各种啰嗦的历史背景、非功能约束、甚至几版修改记录完全不知道该抓什么。前辈教我一套方法我整理完之后基本就是我的固定阅读流程第一步先把需求文档里出现的主语圈出来也就是这个系统里到底有哪些角色普通用户、管理员、审核员、运营人员各自能看到什么、能做什么。第二步把每个角色对应的核心动作拉成一张操作列表登录、查询、提交、审批、驳回、导出每个动作背后都连着业务规则和状态变化。第三步重点读“如果”“当”“异常”“不允许”这类词后面的句子。比如“当库存不足时提示补充库存”“如果审核不通过则退回填写页”“用户不能重复提交同一申请”这几句话几乎就是测试用例的命脉。我之前很热衷于把需求里所有文字都翻译成用例结果绝大多数都变成了对需求的复述。前辈说这叫“无效覆盖”用例量很大但真正能发现缺陷的没几条。正确的读法是从需求中找到所有“分支场景”和“限制条件”而不是把所有“正常流程”变成用例。这也是为什么同一个功能有些人能设计出三四十条用例有些人只能写七八条差距基本都要追溯到读需求这一步。1.3 也别把质量模型当成八股文大学课程里几乎都讲过软件质量模型功能正确性、可靠性、易用性、性能效率、兼容性、安全性每个维度又拆出一堆子特性。实习之前我觉得这只是考试需要背的东西进了项目才发现它其实是“查漏补缺的检查清单”。举个例子如果你只盯着功能测试很容易忽略兼容性。我们项目里有一个导出Excel的功能开发在本地用最新版环境验证一切正常结果测试时安排在旧版本浏览器上一跑导出的文件直接打不开。这种问题不写兼容性用例根本发现不了。再比如易用性。有次测试一个表单页功能规则全部通过但我自己填的时候总觉得哪里别扭提交按钮在页面底部需要拖动滚动条才能看到。这个不算功能缺陷但用户实际用起来体验很差。测试报告里我顺手提了一条体验类建议没想到产品经理很重视下个迭代就调整了布局。所以我是这么理解的质量模型不只是理论框架它的价值是提醒你从更多角度去看一个功能避免因为“功能能跑通”而忽略了其他会影响用户使用感受的因素。2. 测试用例设计从“想到哪写到哪”到“按套路覆盖”2.1 用例的最基本结构谁、做什么、输入什么、期望什么先说我最早写出来的用例长什么样子。当时拿到需求文档里“用户可以修改个人信息”这句话我唰唰写了好几条用例用户点击编辑按钮系统显示编辑页面用户修改手机号系统提示修改成功写完之后觉得挺完整但前辈看后指出了问题修改手机号要不要验证码手机号格式错误系统怎么提示空着不改直接保存会怎样连续两次提交会不会重复触发验证码你的用例没有一条覆盖这些场景。这个教训几乎每个测试新人都会遇到。用例的基础结构确实是“前置条件 操作步骤 输入数据 预期结果”但真正考验能力的是你在设计步骤时有没有把操作背后的规则和异常往下拆一层。“系统提示修改成功”只是最基础的那条路径真正的用例设计要回答的是“在什么条件下”“操作了什么功能”“给了什么输入”“系统应该给出什么响应”每一步都得落在一个明确、具体的状态上。我习惯把每条用例拆成四个要素来检查前置条件系统处于什么状态数据具备哪些条件操作步骤从哪个入口进入具体做了什么测试数据输入了什么值或选择了哪个选项预期结果界面上出现什么、数据库里变化了什么、下游系统收到什么直到今天我都觉得如果你能把自己的每条用例都写清楚这四个要素你的用例基本上就合格了。缺了任何一个执行的人要么不知道从哪里开始要么不知道结果对不对要么根本不知道这一条在验证什么。2.2 覆盖思路等价类、边界值、场景法是怎么配合用的设计方法大家都知道等价类划分、边界值分析、因果图、场景法、判定表上课时都背过定义。但真正把它们落到用例里我花了不少时间才找到“组合感”。等价类划分解决的是“无穷量怎么变成有限量”的问题。拿年龄输入框举例有效等价类可能是18到60岁无效等价类可能是小于18、大于60、非数字、空值。每类至少选一个代表值去测试这是最基础的做法。边界值分析是补充等价类用不到的“极限场景”。如果规则是18到60岁有效那17、18、60、61这四个值就是必须测的边界。很多Bug都会出现在边界上这几乎是测试行业里最容易出成果、也最容易被忽视的地方。场景法解决的是“多步骤联动”的问题。用户注册、填写资料、上传证件、等待审核、审核通过、收到通知这是一整条业务链路。每两个环节之间都可能产生状态传递比如审核驳回后再修改资料重新提交数据和状态能不能衔接上。只看单个页面是发现不了这种链路问题的。我的执行顺序是这样的先根据需求画出核心业务流程图标出正常路径、分支路径、异常路径然后对每个路径上的输入项做等价类和边界值分析最后把所有限制条件组合成判定表。这样整体覆盖会比较完整不会同一个角度反复测其他角度完全不碰。前辈说这叫“按套路出牌”不是靠灵感和运气去测深以为然。2.3 一次用例评审被问得哑口无言之后再补的功课我们项目上线前会做一轮用例评审产品、开发、测试坐在一起过用例清单。我作为新人也跟着参加了自己负责模块的评审刚开始还挺有信心毕竟用例写了不少每个功能点基本都覆盖到了。结果开发看了一会儿指着我的一条用例问了一个问题“这里你预期结果是‘提示保存成功并返回列表页’但万一保存成功之后接口返回的时候网络断了前端页面会怎么表现你这条用例预期结果只写了正常情况异常情况你打算怎么验证”我确实没想到这个场景。页面提交到一半断网这一步往上抛个报错提示还好说但接口已经在后端执行完了数据到底有没有写进去用户是看到失败提示还是成功提示重新进入页面时数据是否一致这已经不只是前端显示问题还涉及前后端状态一致性和接口幂等性。那次评审给我的收获很大。用例评审不只是“确认一下有没有遗漏”更多时候是开发用他的技术视角补上我对系统机制理解的空白。从前端页面展示到后端接口处理再到数据库状态变化两边的判断经常是不一样的。测试用例里写的“预期结果”如果不考虑系统在异常情况下的实际行为执行的时候基本测不出深层问题。从那以后我设计用例时会特意多问自己一句这个操作如果中途失败了系统会怎样多问这一句很多隐藏的Bug就这样被提前暴露出来。3. 缺陷的生命周期与Bug单实操从提交到关闭的全过程3.1 提交Bug单之前我一定会做的自我检查实习阶段我提交过不少Bug也闹过几次笑话。最典型的一次我提交了一个“登录之后页面空白”的缺陷开发看到就回了一条“日志呢控制台报错了没有网络请求返回了什么”我完全答不上来最后还是前辈带着我重新复现抓了网络请求发现是返回数据格式变了一个字段名导致前端解析失败。从那次以后我每次提交Bug单之前都会先做一遍完整的自查。我总结了一套提交前的检查顺序第一步确认我能稳定复现。只出现过一次的Bug先不要急着提我会多操作几遍确认它是不是固定能出现。如果三次里只能复现一次我会在描述里写清楚出现频率和当时操作环境不能只写“偶尔出现”。第二步把出现Bug前后的操作步骤完整记录下来。从哪个页面进来、点击了什么按钮、上传了什么文件、填写了什么数值每一步都写。哪怕我怀疑某个步骤无关也先写下来让开发自己去判断。第三步截图或录屏存下来并把关键提示信息单独摘出来放在描述最前面。控制台报错、接口返回码、弹窗里的错误文案这些比截图更重要是定位问题最直接的线索。第四步确认版本和环境信息。当前测试环境是哪个环境、测试的版本号是多少、用了什么浏览器或设备。尤其是前端问题设备和浏览器版本几乎成了必填项。曾经有一个样式错乱问题只有在特定浏览器下出现换一个浏览器就正常环境不写清楚开发根本无从下手。做完这些检查我才会去填Bug单。前辈说过一句话我记到现在“测试的职责是把问题描述得让开发能被引导着快速定位而不是丢一句‘这里坏了’就算完事。”我现在每次提Bug都会下意识拿这句话来衡量自己。3.2 缺陷生命周期里的几个关键流转环节缺陷从提交到关闭整个生命周期大致是新建 → 待确认 → 已确认或不复现/设计如此/重复提交→ 处理中 → 待验证 → 已关闭或者重新打开。不同公司的系统叫法可能略有差异但核心流转逻辑差不多。我在实操里遇到最多的几个环节是这样的新建阶段测试提交Bug单并分配给对应的开发。这个阶段最重要的是描述质量和级别判断。我刚开始很容易把所有Bug都标成“严重”后来才知道一个崩溃级的阻断问题和一个文案显示错乱的问题根本不在同一个优先级上。级别标得过高会扰乱整个团队的排期标得过低又可能拖到很久没人处理。合理的做法是完全阻断主流程、数据丢失、系统崩溃的才标严重布局错乱、部分用户看不到内容算中等纯文案显示不统一或体验优化算轻微。开发处理阶段有几种情况很常见。一种是开发看完描述后回复“我这里无法复现”这种情况就需要测试去补充更详细的前置条件或者录屏必要时约开发当面一起看。另一种是开发确认问题但觉得不算Bug、是需求本来就这么定的这种情况一般会转到产品那里确认。还有一种是开发修改完直接说“已修复可以验证”订正后的代码上了测试环境我去验证确认没问题就关闭如果还有问题就重新打开继续跟踪。整个流程走下来我觉得最考验测试耐心的就是“反复重开”。有时候开发认为修复完成但实际场景里另一个分支又带出了新问题或者修复方式不符合需求预期一个Bug来来回回折腾好几天。一开始我会着急后来我学会了在重新打开Bug单的时候把验证过程和失败截图贴上去让开发第一时间知道我验证了什么、产生了什么结果而不是空泛地留一句“还是有问题”这样沟通效率高很多。3.3 一个典型Bug从发现到关闭的完整记录给你们看一个我印象比较深的Bug流转记录正好完整走了一遍生命周期某个页面上传文件后接口返回成功但列表里显示的数据数量对不上缺失了其中一条。我当时在测试环境连续复现了三次每次都出现同样的情况基本排除偶发因素。我在Bug单里写的内容大致是前置条件——测试环境下已登录管理员账号上传包含10条数据的文件文件格式符合模板要求复现步骤——进入批量导入页选择文件并上传等待接口返回成功后进入列表页发现列表只展示9条数据实际结果——列表数据显示9条接口返回成功提示预期结果——列表完整展示10条数据补充信息——测试环境版本号、接口返回码、页面控制台截图、数据请求返回值截图。开发收到后很快定位到了原因是导入接口处理数据时有一条数据因为缺少一个非必填字段走了“校验失败”的逻辑但校验失败的提示没有拼接到最终返回结果里导致接口整体返回成功。从测试角度来看这就是典型的“接口返回成功不代表业务完全成功”问题。修复后我重新上传了同样一份数据列表正常展示了10条再补试了上传空文件和重复文件两个场景确认没问题才把Bug关闭。这个案例给我最大的启发是写Bug单时把接口返回值和页面对应状态分开记录尤其当接口提示成功但页面数据不对的时候这种信息对开发快速定位帮助极大。4. 测试环境与数据准备第一次独立测试就卡在了环境上4.1 环境部署和联调排错的基本功我们组的测试环境有一套自己部署的流程版本更新、配置修改、重启服务这些操作虽然大部分由开发来执行但测试也需要掌握最基础的连通性排查技能。因为很多Bug根本不是代码逻辑问题而是环境问题比如配置没刷、数据库连错、依赖服务没启动。我第一次独立执行测试上来就报告了一个“登录之后调接口报500”的Bug结果开发一查发现是我连的数据库指向了一个旧环境里面的用户数据结构和新版本代码不匹配。这个事情非常典型测试排查时第一反应是“查代码”但环境层面的问题优先级应该更高。我现在遇到类似问题会按这个顺序排查先看服务本身是否正常启动再确认当前环境配置指向哪个数据库、哪个缓存服务接着查看相关依赖服务如订单系统、用户中心是否可达最后才去看接口返回值判断是不是代码逻辑问题。整个排查过程十分钟以内基本能完成能筛掉至少一半的“假Bug”。另外我想强调一下网络请求工具的使用。抓接口返回是测试的基本功不是开发专属技能。打开浏览器的开发者工具切到网络标签页找到对应请求查看返回状态码和响应体这一步在定位问题的时候几乎是必修课。我现在每次提交疑似接口层面的Bug都习惯把请求参数和返回数据一并截图开发几乎都能秒定位。4.2 测试数据准备按业务场景倒推而不是随机造数实习初期我准备测试数据基本是零散的页面需要什么就填什么哪种数据好造先造哪种。后来发现很多场景测不了比如审核流程需要一条“待审核”状态的数据我在页面上怎么都造不出来因为创建成功后默认状态是“已提交”不会自动变成待审核。前辈教我换一种思路准备数据先梳理完整业务链路确定各个环节需要什么状态的数据再逆向准备。比如审批流涉及提交、审核、驳回、通过那我就得准备至少四条不同状态的数据。这四条数据分别从哪里产生每条需要怎样的前置操作这个要提前列清楚。还有一类数据是“边界数据”。测试一个金额字段时正常数据很容易造边界数据就需要专门去构造比如刚好在限额边缘的值、超过限额的值、精度保留到小数点后好几位的情况。这类数据如果测试时没有提前备好执行到一半就卡住了很影响测试效率。我自己的经验是把测试需要的数据按照“正常数据”“边界数据”“异常数据”“业务状态数据”四个维度提前列出来对应好造数方法测试执行会顺畅很多。4.3 冒烟测试和回归测试的区别别再混着说了实习前我总觉得冒烟测试就是“快速测一遍”回归测试就是“再把上轮用例跑一遍”细节上理解得模模糊糊。后来在真实迭代中才体会到这两个概念在节奏和目标上都不一样。冒烟测试是在一个新版本提测之后用最快的时间验证主流程能不能跑通它是一个“准入性”检查。如果登录进不去、主流程走不通后续的用例执行就没有意义。所以冒烟测试用例一定要选最关键、最核心的那几条而不是把所有用例全跑一遍。回归测试是在功能修改完之后验证原有功能没有被破坏。它讲究的是覆盖面和关联性分析这次改动涉及哪些模块哪些历史功能可能受影响这些范围要先去判断再有针对性跑起来。比如改了下游接口的返回字段上游依赖这个字段的页面就可能出问题这种关联模块没有回归到就等于埋了一个雷。我实习过程中遇到过几次类似情况一个看似很小的改动影响了另外几个模块当时没有及时回归上线后用户才发现问题。这也是我为什么越来越重视回归测试的原因——修改某个功能导致另一个功能挂掉这类问题不靠回归测试靠人肉记忆是不可能发现的。5. 前辈们传授的经验那些写在口头、偏不写进文档的干货5.1 测试计划的真实作用把控风险和排期而不是走流程实习之前我以为测试计划就是把测试范围、用例数量、执行时间写进一个文档交给领导看。真正跟完一个迭代后才知道测试计划其实是用来排风险和排人力的。前辈给我讲过一个很现实的问题开发提测晚了两天但上线日期不变那留给测试的时间就少了怎么办这个问题的答案不能是“安排加班”而应该是重新评估测试范围把优先级低的用例挪到下一轮、只保核心功能和新功能或者跟产品商量缩小本次发布范围。这些决策靠的都是测试计划里的风险判断和优先级梳理临时去翻用例根本来不及。所以我现在理解测试计划的核心不是“要测什么”而是“在有限的时间和资源下怎么保证最重要的东西先被测出来”。这可以说是一种“优先级管理”的能力说白了就是会做取舍。5.2 和开发沟通的三条铁律实习生最好奇的问题之一就是测试和开发怎么沟通才不会吵架。我亲眼见过因为一个Bug的描述不清晰开发和测试在群里来回对了十几条消息最后居然是在说两个不同环境的问题。这种信息差带来的沟通成本完全可以通过沟通习惯来降低。我梳理一下前辈们反复强调、我自己也验证过的三条铁律第一条描述问题必须带上环境、版本、账号这些前置信息不要让人猜。我们在群里日常协作时第一句话就会说明“XX测试环境、XX版本、管理员账号”避免出现“我这边是好的啊”这种因为环境不同而无法对齐的情况。第二条先说结论再展开过程。初级测试很容易从头讲起背景和操作说了半天还没有点到重点。开发每天时间碎片化严重一句话没说到问题上他可能就不想再看了。现在我无论写Bug单还是在群里反馈第一句永远是结果比如“批量导入后列表少了一条数据接口返回200”然后再补复现步骤。第三条不确定是Bug的先按“疑似问题”沟通不要直接下结论“你代码错了”。有些情况是数据问题、环境配置问题、需求本身定义就是这样一上来就断定是开发的责任很容易把合作氛围搞僵。探明情况再定性沟通会顺很多。5.3 前辈的口头禅“先看日志别猜问题”这句话几乎贯穿我整个实习过程。每次我描述一个Bug半天找不到原因的时候前辈都会先说一句“看了日志吗先看日志别自己猜。”日志是测试排查问题最直接的证据来源。前端可以看控制台报错后端可以看服务日志和异常堆栈。比如页面操作无反应可能是前端没发请求也可能是后端处理时报了异常如果不看日志用肉眼在页面上胡乱试就是浪费时间。我第一次独立排查一个问题时浪费了将近半小时在页面上反复操作后来前辈帮我翻了后端日志看到一条空指针异常堆栈定位到是某个关联数据为空。文件本身没问题是数据库某条关联记录缺失。从那以后我的排查习惯就改成先看页面反应再抓网络请求再看后端日志三步走完再考虑要不要提Bug给开发。日志这种东西你越熟练越觉得简单但新手经常忽略它。我觉得一个测试如果连基本的日志定位能力都没有工作一半时间都耗在“无法定位”上别人帮不上忙自己也很难成长。5.4 日报周报别写流水账写清楚“判断和结论”实习要求写日报周报一开始我写得很机械“今天测了登录模块发现一个Bug提给了开发”一句话就完了。后来前辈帮我改了表达方式要写清楚我今天测了什么范围、发现了什么风险、验证了什么结论、下一步需要什么支持。这样写的好处是leader一看就知道你在做什么也能快速评估你手里的风险和阻塞项。比如“客户管理模块冒烟测试通过支持进入详细用例执行阶段但导出功能存在数据量过大时接口超时问题已提交Bug并和开发确认修复排期不影响本轮主要功能验收”这比写十句“今天测了XX”有用得多。写周报也是复盘的过程回过头看一眼这一周测试下来哪些模块风险高、哪些用例设计明显不够、哪些Bug和打扰完全可以前置排查下个迭代就能做得更好。这些心得比报告本身更有价值。5.5 测试用例执行之外的自我成长学会建立“缺陷思维”前辈们在我实习一段时间后跟我聊过一个比较深的话题测试这个岗位的长期竞争力不体现在你发现了多少Bug而体现在你多快能建立一个完整的“缺陷思维模式”。所谓缺陷思维就是看到一个功能时大脑自动开始追问这个输入如果是空的呢这个按钮如果被连点呢这个状态如果跳过了呢网络如果断了一下呢用户如果同时做了两个操作呢这种思维不是天生来的是靠大量训练养成的。我实习早期很羡慕前辈一眼就能挑出很多我没注意到的场景后来发现他们也是踩过无数个坑才练出来的。实习这段时间我越来越觉得测试不只是“找茬”而是一种风险控制工作。通过系统性设计、有效执行、清晰提交缺陷帮助团队在发布前发现并解决问题把未知风险变成已知风险把可能崩溃的用户场景扼杀在上线之前这本身就是很有成就感的事。最后再分享一个小习惯我每天实习结束会用十分钟把当天遇到的问题、排查的思路、前辈教的方法简单记在笔记里。很多经验第一次听觉得记住了隔一周就忘了写下来才是自己的。这个习惯比我做的任何用例都值钱。