1. 为什么测试用例是软件测试的基石做测试这一行越久越能体会一件事测试用例不是写文档而是把测试思维固化下来的唯一载体。很多刚入行的朋友问我测试的核心技能到底是什么我的回答通常很简单——就是你把一个功能拆成多少种场景、每种场景怎么验证、验证到什么程度算通过。这个拆解和验证的过程最终都要落到测试用例上。软件测试的定义、目的与基本原则在教科书里写得很清楚测试是为了发现错误而执行程序的过程目的是以尽可能少的代价找出尽可能多的缺陷。但真正到了项目里你会发现测试用例才是这个过程的地基。没有用例测试就是想到哪测到哪今天记得测登录明天可能就忘了校验密码长度没有用例新人接手项目只能对着需求文档发呆没有用例开发提测之后你甚至说不清楚这次到底覆盖了哪些功能、哪些没测。从实际工程角度看测试用例的价值至少体现在四个层面。第一它是测试执行的依据保证测试活动可重复、可追溯第二它是测试覆盖度的度量标准能明确回答测了多少、还剩多少第三它是回归测试的基础版本迭代时靠用例集快速验证旧功能没有受影响第四它是团队经验的沉淀一个项目积累下来的用例集就是这个项目最宝贵的知识库之一。这里顺便说一句测试用例在面试里也是高频考点。不管是功能测试、自动化测试还是测试开发岗面试官几乎必问测试用例怎么设计给你一个登录页面你怎么写用例。原因很简单用例设计能力直接反映一个人的测试思维是否系统、是否严谨。一个只会按正常流程点点点的测试和一个能熟练运用等价类、边界值、场景法的测试写出来的用例质量天差地别。2. 测试用例的核心组成一条合格用例必备的字段写测试用例不是随便记几个步骤就行。我在实际工作中见过太多半成品用例——只有操作步骤和预期结果前置条件不写、优先级不标、用例编号乱起结果执行一轮下来人都懵了。一条合格的测试用例字段设计是有讲究的。2.1 必填字段与作用一个标准的测试用例至少应该包含以下字段字段说明为什么必须用例编号唯一标识如 TC-LOGIN-001追溯缺陷、关联需求和执行记录所属模块功能模块名称如登录模块便于统计各模块覆盖率和缺陷分布用例标题一句话描述验证点快速识别用例意图如验证密码错误时提示正确前置条件执行该用例前需要满足的状态保证用例可重复、可独立执行测试步骤具体的操作步骤执行者无需猜测按步骤操作即可测试数据输入的数据值明确数据保证可复现预期结果操作后系统应有的表现与实际结果对比判断通过与否优先级P0/P1/P2/P3决定测试执行的先后顺序和回归范围实际结果执行后系统真实表现留痕方便缺陷分析和回归确认用例状态通过、失败、阻塞、未执行实时掌握测试进度很多人会忽略前置条件和测试数据这两个字段。举例来说测试用户首次登录强制修改密码这个功能前置条件就要写清楚用户已注册、账号状态正常、首次登录、密码策略已配置。如果不写前置条件执行的人可能拿一个改过密码的账号去验证永远复现不出强制修改的弹窗还以为是BUG。2.2 用例编号规范用例编号看起来是小事实际影响很大。我推荐用模块缩写-功能编号-序号的三段式结构。比如LOGIN-001-001表示登录模块第一个功能的第1条用例。这样在缺陷跟踪系统里关联BUG时直接引用编号就能快速定位到对应用例不用翻文档。大型项目还可以细分到四级编号比如TC-AUTH-LOGIN-001TC代表TestCaseAUTH代表权限子模块LOGIN代表登录功能001是序号。项目组里统一编号规则后用例管理、统计、追溯的效率会高很多。2.3 测试数据设计显式与隐形测试数据是新手最容易偷懒的地方。很多人写输入用户名密码看起来没错但执行时每个人用的数据都不一样结果就很难统一复现。正确的做法是写出具体的值比如输入已注册用户名zhangsan、密码123456。同时要注意区分显式数据和隐形前置数据——除了界面上输入的数据后台配置的数据如用户角色权限、系统参数设置也属于测试数据的一部分同样要写明。举个真实项目里的例子我们测过一个审批流程用例里只写了提交人提交申请但忘了写明提交人的角色是普通员工还是部门经理结果执行时用了经理账号直接跳过了审批环节用例结果完全失真。从那以后凡是涉及角色权限的用例我一定在前置条件里写清账号角色。3. 测试用例设计的六大经典方法原理与实例测试用例设计方法是软件测试知识点里最核心的一块。等价类、边界值、场景法、判定表、因果图、正交实验——我把这六种方法的原理和实战用法逐一拆开讲。3.1 等价类划分法把无限的输入分成有限类等价类划分的核心思想是把输入域划分成若干等价类每一类中的数据对测试而言是等效的测一个代表数据即可推断整类正确与否。这样能用最小的用例数覆盖最大的输入范围。等价类分为有效等价类和无效等价类。有效等价类是符合需求、合理的输入数据集合无效等价类则是不符合需求、非法的输入数据集合。设计用例时两者必须兼顾——很多BUG恰恰藏在无效输入的处理上。以经典的手机号注册为例需求规定11位数字以1开头。那么有效等价类就是11位以1开头的数字串无效等价类至少包括非数字字符、不足11位、超过11位、不以1开头、空值。每个无效等价类都要单独设计用例因为不同无效类的错误处理逻辑可能不同——有的是格式校验拦截有的是长度判断拦截必须逐一验证。实际应用时有个经验每个无效等价类尽量单独测不要一次塞多个无效条件。如果同时输入空值和11位数字系统提示的可能是手机号为空而不是手机号格式错误这样你无法确定系统对格式校验是否真的生效。3.2 边界值分析法缺陷最密集的地带边界值分析法是对等价类的补充专门关注输入域边界附近的取值。经验表明大量缺陷集中在边界取值上因为开发在写判断条件时最容易在大于、大于等于、小于、小于等于之间搞混。边界值分析的经典原则取边界值、边界值加一、边界值减一。以密码长度为6-16位为例需要覆盖的边界值有5位下边界减一、6位下边界、7位下边界加一、15位上边界减一、16位上边界、17位上边界加一。再加上等价类里的正常值如8位和非法值空、超长文本这个输入域就能覆盖得很全面。为什么边界值这么重要因为程序里的判断条件比如if(len 6 len 16)在6和16这两个点最容易写错成len 6或者len 16。用边界值用例一测问题立刻暴露。我在实际项目中测过一个小程序需求是金额范围0.01-10000元开发写的判断条件是amount 0.01 amount 10000看着没问题但浮点数比较在0.01这个点上有精度问题用0.01去测偶尔会返回金额不在范围内。这种坑只有真正跑到边界值才会现形。3.3 场景法从用户操作路径设计用例场景法基于一个朴素的事实用户不会按单个功能点去使用软件而是按照某个业务场景、某条操作路径在使用。场景法关注的是用户做了什么、系统如何响应的整个流程它把用例从验证一个输入框提升到验证一段业务流程。场景法设计的核心是识别基本流和备选流。基本流是正常的、满足用户主要需求的路径备选流是异常情况下的分支路径比如用户取消操作、系统校验失败、网络超时等。以用户下单支付为例基本流是选商品→加购物车→结算→确认订单→支付→支付成功→生成订单。备选流至少包括购物车为空时结算、支付超时、支付失败重试、库存不足、优惠券过期等。每个备选流都对应一条或一组用例。场景法特别适合端到端的业务流程测试、回归测试和冒烟测试。我在敏捷项目里习惯把场景法用例作为冒烟测试集每次提测先跑基本流场景基本流挂了就直接打回不再浪费时间做细粒度测试。3.4 判定表法多条件组合的逻辑利器当被测功能由多个条件共同决定输出结果时判定表法是最直观的工具。判定表由条件桩、动作桩、条件项、动作项四部分组成能系统地列出所有条件组合及对应的动作。经典的判定表案例是登录状态与会员等级决定折扣两个条件是是否登录是/否和会员等级普通/VIP动作是折扣率。4种组合逐一列出哪些组合有效、哪些组合非法如未登录但按VIP处理一目了然。判定表最大的价值是防止条件组合的遗漏——人脑很容易漏掉未登录且VIP这种组合但判定表会强制你列出全部。用判定表法要注意一个度。条件超过4个时组合数会爆炸2的n次方全量列举不现实。这时可以先用等价类对每个条件缩减取值再结合正交实验法抽样。实际项目中判定表最适合用在规则性强的功能上比如优惠计算、权限判定、审核流程分支等。3.5 因果图法追根溯源的逻辑推导工具因果图法用于分析输入条件原因与输出结果结果之间的逻辑关系再据此设计用例。它的核心是梳理什么条件下产生什么结果和判定表的目标一致但更偏重逻辑推导过程。因果图涉及四种基本关系恒等原因出现则结果出现、非原因不出现则结果出现、或任一原因出现则结果出现、与所有原因出现则结果出现。约束关系还包括唯一、要求、强制等。实际工程中我很少单独画因果图通常是直接用因果分析出所有原因和结果的对应关系然后转成判定表来设计和编写用例。但因果图这个思维过程很值得训练——它能逼着你把为什么会有这个结果想透彻而不是拿到需求就凭感觉写用例。3.6 正交实验法多因素多水平的降维方案当测试涉及的因子和水平都比较多时全量组合根本测不完正交实验法就是用来解决这个问题的。它的原理是从全量组合中挑选出有代表性的组合进行测试这些组合具备均匀分散、齐整可比的特点用少量用例覆盖大部分组合场景。以测一个搜索功能为例影响因素的因子可能是关键词类型3种、搜索范围4种、排序方式3种、是否筛选2种全量组合是3×4×3×272种。用正交表L16(4^5)设计16条用例就能覆盖主要组合。实际中我常用在线正交表生成工具输入因子和水平数直接生成测试组合然后再补充几条关键边界组合兼顾覆盖和效率。需要提醒的是正交实验法适合因子多、彼此相对独立的场景如果因子之间有明显业务关联比如支付方式和支付金额范围存在强约束正交表可能生成不合法的组合需要人工剔除。处理方法是先把强约束因子分组组内用判定表组间用正交表两种方法配合使用效果更好。4. 测试用例怎么写从需求到用例的完整流程很多初学者拿到一个需求文档盯着屏幕半天下不了笔。这里分享一套我自己反复验证过的从需求到用例的标准操作流程。4.1 第一步拆解需求提取测试点写用例之前先不急着写步骤。第一件事是把需求文档中的功能点逐条拆解成测试点。拆解时重点关注功能输入是什么、处理逻辑是什么、输出结果是什么、有没有异常分支、对应哪些业务规则。以用户注册为例需求可能是几十字的一句话但拆解出的测试点至少包括页面元素完整性、字段合法性校验用户名格式、密码强度、手机号格式、邮箱格式、唯一性校验用户名已存在、协议勾选校验、发送验证码、验证码正确与错误、注册成功跳转、注册失败提示等。这一步产生的测试点清单就是后续用例设计的地图。这里要特别建议新手测试点清单和测试用例分开写先有测试点再细化为用例。测试点用来和开发、产品对齐需求理解用例用来实际执行。直接写用例容易漏测试点直接列测试点又没法执行——两者配合才是完整的。4.2 第二步选择设计方法组合使用拆解出测试点后对每个测试点选择合适的设计方法。我的习惯是先对每个输入项做等价类和边界值分析再对流程性功能做场景分析对规则性功能做判定表分析多因子组合场景用正交表抽样。六种方法不是互相排斥的而是配合使用。比如用户注册这个功能用户名输入框用等价类边界值验证码流程用场景法正常获取、60秒重发、错误输入、过期处理注册协议用判定表勾选/不勾选×点击注册/不点击不同输入项之间的组合再抽几条正交用例。一套用例下来覆盖度很完整。4.3 第三步套用模板逐条编写测试点和方法确定后套用用例模板逐条编写。编写时注意几点标题要言简意赅地说明验证点步骤要具体到点了什么按钮、输入了什么值预期结果要精确到系统出现什么提示、跳转到什么页面、数据库有什么变化。预期结果写得好不好直接决定用例能否被他人准确执行和判定。4.4 第四步用例评审用例写完后必须评审。评审参与方一般是测试、开发、产品。评审的重点是需求理解是否一致、测试点是否遗漏、预期结果是否和需求一致、优先级是否合理。我在评审时最喜欢问开发和产品的一句话是这条用例的预期结果和你们理解的需求一致吗经常能发现需求描述模糊、开发和产品理解不一致的情况——这种问题在测试执行阶段发现的话成本会高很多。5. 测试用例的优先级设计P0-P3怎么定测试用例不是每条分量都一样的。资源有限、时间有限必须按优先级安排执行顺序和回归范围。测试用例的常规优先级定义如下优先级定义适用场景P0核心功能、重要流程若失败则版本不可发布登录、支付、主流程、数据安全P1主要功能一般场景失败会影响部分用户核心页面展示、常用操作、中等异常处理P2次要功能、异常场景、兼容性边界值、UI细节、较少路径P3体验类、极低概率场景、非功能性文案措辞、风格展示、极端输入优先级设计最大的用处是应对时间不够。版本迭代遇到周五必须发版但用例还没跑完怎么办我的做法是P0全跑P1至少跑80%P2抽样跑P3记录待后续版本覆盖。另外回归测试也是一个道理——版本迭代后回归集只保留P0P1能在有限时间内最大化降低回归风险。这里有个容易踩的坑优先级定得太高。一个页面所有用例都标P0等于没有优先级。我的经验是P0用例量控制在总用例的10%-15%左右超过这个比例说明你对核心的定义还不够聚焦。宁可少而精不要多而滥。6. 测试用例的维护、复用与管理多迭代场景下的实战经验测试用例不是写完就完事的静态文档它在整个软件生命周期里需要持续维护。尤其是不同项目组、多迭代的复杂需求背景下测试用例的管理复用和维护直接关系到一个测试团队的执行效率和质量稳定性。6.1 用例维护的触发时机至少在这几种情况下必须更新用例需求变更、功能新增、缺陷修复、执行中发现用例本身有问题。最容易被忽视的是缺陷修复后更新用例这一步。测出一个BUG开发修完测试验证通过然后呢如果这个场景之前没有对应的测试用例那这次发现问题的场景就应该补成用例否则下个迭代这个BUG很可能回归重现。我在团队里立了一条规矩线上缺陷必须反查测试用例没有用例覆盖的场景一律补写并加入回归集。6.2 用例复用的三种层次第一层是同一项目迭代间的复用。上一迭代的用例集在下个迭代里大部分场景仍然适用直接复用并增量补充新功能用例。这是最常见也最基础的复用。第二层是跨项目间的复用。同类型项目比如公司里多个项目都有支付模块、都有登录模块用例在项目之间可以复用。前提是项目规模、技术栈、业务规则足够相近。我的做法是建立公共用例库把各项目的通用模块用例沉淀进去新项目启动时直接从公共库拉取基础用例再补充自身特色场景。第三层是自动化测试脚本里的复用。自动化测试的前提就是用例的稳定沉淀。把高频回归的P0/P1用例转为自动化脚本每次版本迭代自动执行能极大释放人力。这里要特别强调自动化脚本的基础是用例设计得好不是脚本写得好。用例本身不稳定、预期结果模糊的强行自动化的结果就是一堆误报。6.3 多迭代复杂需求下的用例管理策略遇到复杂迭代需求分期上线、多团队并行开发用例管理容易失控。我建议从三方面入手第一用例按模块和需求版本做双维度管理。按模块维度方便统计覆盖率和定位缺陷按需求版本维度方便追溯每个版本到底改了哪些功能、对应更新了哪些用例。工具上用TestLink、禅道、Jira的Zephyr插件或者PingCode这类专业测试管理工具都能实现双维度关联。第二建立基线用例集概念。每个发布版本对应的用例集打一个基线标签。后续迭代在基线基础上增量维护出问题可以清晰对比哪些基线用例失败了。没有基线概念用例越来越多最终改到谁都不知道当前用例集对应什么状态。第三用例评审纳入迭代流程。每次迭代的用例变更新增、修改、删除都要在迭代评审会上过一遍由测试负责人确认变更合理性。避免每个人按自己想法随意改用例导致用例集逐步腐败。6.4 常见维护误区和避坑经验误区一用例只增不删。需求删了一个功能用例也跟着删才对但很多人懒得清理导致用例集里残留大量失效用例执行时浪费大量时间跑不存在的功能。误区二用例越写越细最后变成操作说明书。用例的详细程度应以执行者能准确操作、准确判断结果为准过细会极度增加维护成本。步骤里写点击登录按钮就够了不需要写将鼠标移动到屏幕中央的蓝色按钮上按下左键。误区三不关注用例间的依赖关系。用例A依赖用例B的执行结果这不是好设计。好的用例尽量保持独立每条用例的前置条件自己都具备。万一用例B失败阻塞了A也跟着没法执行整个测试进度就会被动。设计用例时尽量让前置条件能通过测试数据准备或环境预置满足而不是依赖前面某条用例的执行结果。7. 从用例设计到自动化测试的进阶衔接现在越来越多的测试团队在推行自动化测试AI生成测试用例也逐渐成为热门话题。但对大多数团队来说从手工用例过渡到自动化用例是一条必经之路这里面的衔接逻辑值得单独说一说。7.1 哪些用例适合自动化不是所有用例都适合转自动化。我筛选的标准有三条执行频率高、结果判定明确、场景稳定不频繁变动。最典型的就是登录、注册、搜索、购物车这类核心功能回归用例。反过来说界面布局类、视觉体验类、偶发性异常场景自动化价值不大保留手工执行更合理。7.2 手工用例转自动化的改造要点手工用例转自动化不是把步骤直接翻译成脚本而是要做几个改造。步骤要更原子化每一步对应一个清晰的页面状态或接口调用测试数据要从硬编码改为参数化方便脚本在环境间切换预期结果要改成可自动断言的形式比如某个元素是否存在、某个接口返回码是否等于200、数据库某个字段值是否符合预期。举例来说手工用例写输入用户名zhangsan、密码123456点击登录验证跳转到首页转自动化时用户名的数据要放到配置里登录的按钮定位要用稳定的id或data-testid跳转要断言首页的URL或某个特征元素。我在项目中见过太多团队直接拿手工用例步骤去套自动化框架结果每轮迭代都因为元素定位变更而大批量报错最后自动化用例成了摆设。7.3 关于AI生成测试用例的看法最近很多人在聊基于AIGC的测试用例自动生成技术。我的看法是AI生成用例对补充边界场景、大幅扩充覆盖率确实有帮助我自己也会用一些工具做辅助生成。但AI生成的内容不能直接作为最终用例使用它最大的问题是缺乏对业务规则和用户场景的深度理解容易生成逻辑上合法但业务上无意义的用例。正确的姿势是人机协同——AI批量生成候选用例测试人员筛选、修改、补充业务上下文后再入库。把它当作提效工具而不是替代品。8. 项目实战以用户登录审批流程为例设计一套完整用例前面讲的都是方法和理论这里拿一个实际场景完整走一遍流程。这个例子结合了最常见的登录功能和审批流程功能也是面试里常被问到的综合性功能。8.1 功能需求简述系统需要实现一个带角色权限的登录功能以及审批流程功能。登录需求用户名/手机号/邮箱任选其一登录密码验证连续输错5次锁定账号30分钟支持记住登录状态。审批流程需求员工提交请假申请部门经理审批HR备案涉及多级审批时任一节点驳回则流程回到申请人修改后可重新提交。8.2 登录功能的测试点拆解与方法选择登录功能的测试点可以从以下维度拆登录方式切换用户名登录、手机号登录、邮箱登录三种方式都能正常切换与登录字段校验输入内容为空、格式错误、长度边界密码验证正确密码、错误密码、密码含空格、密码复制粘贴锁定策略连续4次错误、第5次错误、锁定后正确密码登录、锁定期间不断尝试记住登录状态勾选与不勾选、过期时间安全场景登录跳转、退出登录、异地登录设计方法上字段校验用等价类边界值锁定策略用边界值场景法登录方式逻辑用判定表。8.3 审批流程的功能测试点拆解审批流程是场景法的主场。基本流是登录系统→填写申请单→提交→部门经理审批通过→HR备案→流程结束。备选流包括填写时表单校验失败、提交后经理驳回、驳回后员工修改重提、经理审批超时、HR备案失败、多级审批中第二级驳回、申请人撤回申请。特别注意测试时角色切换是必需的前置条件。申请人、部门经理、HR是三类不同角色的账号用例的前置条件必须写清楚当前登录的账号角色否则流程根本走不起来。8.4 用例落地示例下面给出两条涵盖不同方法的用例示例。示例一边界值登录锁定用例编号: TC-LOGIN-002 所属模块: 登录模块 用例标题: 验证密码连续输错5次后账号被锁定 前置条件: 已注册账号zhangsan账号未被锁定密码为123456 测试步骤: 1. 打开登录页面输入zhangsan和错误密码点击登录 2. 重复第1步操作4次共输错5次 3. 输入正确密码123456点击登录 预期结果: 1-2. 前4次提示用户名或密码错误第5次提示账号已锁定请30分钟后再试 3. 提示账号已锁定无法登录 优先级: P1示例二场景法多级审批用例编号: TC-APPROVE-004 所属模块: 审批流程 用例标题: 验证第二级审批驳回后流程回到申请人 前置条件: 1. 申请人账号zhangsan部门经理账号manager01HR账号hr01 2. 已配置两级审批规则部门经理→HR 测试步骤: 1. 使用zhangsan登录填写请假单提交 2. 使用manager01登录审批通过 3. 使用hr01登录审批驳回填写驳回意见请假天数超出政策范围 4. 返回zhangsan账号查看申请状态 预期结果: 1. 提交成功流程流转到部门经理待审批 2. 流程流转到HR待审批 3. 流程状态变为已驳回显示驳回意见 4. zhangsan可见申请单状态为已驳回并可点击修改后重新提交 优先级: P1这两条用例的字段完整性、前置条件清晰度和预期结果的精确度都可以作为模板参考。9. 测试用例设计的常见误区和避坑经验多年带项目、带新人我发现测试用例设计中有几个反复出现的共性问题在这里集中梳理一下。9.1 只测有效等价类忽略无效等价类这是最普遍的问题。新手写用例习惯性只测正常输入、正常流程对非法输入、异常流程重视不够。但测试的价值恰恰在于发现异常——异常场景往往才是缺陷的高发区。任何一个输入框至少要有正常值、边界值、非法值、空值四类用例的意识。9.2 预期结果写得太笼统系统出现提示页面正常显示这种预期结果等于没写。预期结果必须可观察、可判定提示的具体文案是什么弹窗还是页内提示跳转的具体地址是什么数据库的对应记录状态变成了什么只有预期结果精确用例执行才能客观判定通过与失败否则每个人的判断标准都不一样测试结果就失去可信度。9.3 用例之间的耦合太强用例A依赖用例B执行成功B崩了A也跟着阻塞这是设计问题。正确做法是尽量通过前置条件或测试数据准备让每条用例独立可执行。比如需要已登录状态可以在前置条件里写已登录账号zhangsan而不是依赖另一条登录用例的执行结果。9.4 用例数量越多越好不是我见过一个项目200条功能的用例写了4000多条看起来覆盖度感人实际执行时一大半在跑重复场景。用例贵精不贵多关键在于每条用例是否有独立验证价值。如果两条用例验证的是同一逻辑点的不同输入值把它们合并成一条带多组测试数据的用例可能更合理。9.5 忽略了非功能性测试用例很多人写用例只关心功能不关心性能、兼容性、安全性。一个登录功能除了正常登录还要考虑高频请求下是否会被锁定或拒绝服务、不同浏览器下页面是否正常、密码传输是否加密、是否存在SQL注入风险。这些非功能性场景在用例设计时就该纳入而不是上线后被用户或安全扫描工具打脸。9.6 用例没有及时同步需求变更需求变了用例没跟着改执行时照着旧用例跑结果自然全错。维护用例是测试人员的基本功需求评审时就要同步评估用例变更影响需求变更确认后第一时间更新对应用例。这是测试团队执行效率的生命线。10. 资源推荐与最后的个人体会软件测试的学习路径很多人问过。我的建议是先系统学完测试理论和用例设计方法打好基本功再学自动化工具和编程能力最后在项目实战中不断打磨。入门书籍方面《软件测试的艺术》和《如何有效管理软件测试》是经典中的经典在线的课程和文档CSDN、知乎、博客园上有大量高质量测试用例设计实战文章工具方面先从TestLink或禅道开始学用例管理再接触JiraZephyr最后了解PingCode这类新平台。回想起我自己刚入行时写的第一批测试用例被导师批得体无完肤——预期结果模糊、用例间依赖严重、无效等价类基本没覆盖。后来在一次次版本迭代中慢慢体会到用例设计其实是一种结构化思维的训练它逼着你把模糊的需求变成明确的验证点把庞大的功能拆成一个一个可执行的步骤把我觉得应该没问题变成我有证据证明没问题。这种思维不仅适用于测试做任何需要严谨性和条理性的工作都用得上。现在每到一个新项目我做的第一件事永远是先梳理测试点清单再设计用例。这个习惯帮我避免了无数个“上线后才发现漏测”的尴尬时刻。如果你想在软件测试这条路上走得更远从把每条用例写扎实开始绝对是最值得投入的一件事。