干测试这一行最怕的不是bug藏得深而是需求还没搞明白就被催着写用例、提计划。我见过太多新同事拿到一个需求文档第一反应是打开Excel开始列用例结果列到一半发现业务逻辑理解错了全部推翻重来。这种情况一次两次是粗心次数多了就是在消耗团队的信任。我在测试这条路上走了快十年从功能测试做到测试负责人从手动点点点到搭建自动化测试体系总结下来有一个始终没换过的核心骨架拿到新需求按5步走。这套方法不只是我自己用我带团队时也要求新人照着走一遍效果非常稳定。不管你是做Web测试、App测试、嵌入式测试还是刚入行的测试小白这套思路都适用。接下来我把这5步拆开讲每一步该做什么、为什么要这么做、常见的坑在哪一次性说清楚。1. 先别急着动手把需求榨干到最后一滴1.1 需求分析不是在读文档是在“找漏洞”很多测试工程师拿到需求的第一步是打开PRD从头到尾读一遍读完觉得“嗯我懂了”然后就开始写用例。但等你真正写完用例、甚至执行到一半才发现自己对业务的理解和产品经理的预期根本不在一个频道上。问题就出在你把“读文档”当成了“理解需求”。需求分析的核心目标只有一句话找到所有可能导致理解偏差的模糊点并在动手之前把它们全部消除。具体到动作上我习惯拆成三步第一步通读需求文档两遍。第一遍不划线、不记录只看整条业务链路是什么样解决什么问题面向哪类用户。第二遍才开始划线凡是没有明确写清楚的、前后矛盾的、依赖外部系统的全部标注出来。第二步把标注出来的疑问整理成清单约产品经理开一次需求澄清会。注意不是开一个半小时的大会而是带着清单逐条确认确认一条、记录一条、关闭一条。第三步把确认后的业务逻辑画成流程图或状态图画图的过程其实就是在检验你对业务的理解是否闭环。很多测试同学说自己不会画图其实不需要多专业只要能画清楚“用户从哪进来、经过哪些操作、最终落到什么结果、异常情况怎么走”这张图就是你后续写用例的底稿。1.2 需求澄清的灵魂三问我每次开需求澄清会不管需求大还是小都会固定问三个问题这三个问题基本能覆盖90%的模糊地带这个功能的核心用户是谁他要解决什么问题用户从哪个入口进来完整的操作路径是什么中间如果断了一步系统该怎么表现异常场景下的预期结果是什么比如超时、失败、重复提交、权限不足、数据为空。举一个最常见的例子“忘记密码”功能。PRD上通常只写一句“用户可以通过手机验证码重置密码”看起来很简单对吧但你细问下去全是问题验证码几分钟内有效每天最多发几次发送失败后提示什么用户输入错误验证码5次后是否需要锁定重置成功后原token是否立即失效这些细节如果没有在需求阶段确认清楚到了测试执行阶段就是一遍遍找产品确认然后改用例、补数据效率极低。更可怕的是有些细节连产品都没想过等上线了用户一操作才发现问题那时候再改代价就大了。还有一类容易被忽略的需求是“非功能需求”。接口响应时间、并发用户数、数据保留时长、日志记录要求这些通常不会写在PRD的功能描述里但却是上线后最容易出事故的地方。需求澄清时候一定要顺带问一句“这个接口有没有性能要求数据要保留多久”2. 测试计划不是写文档是排兵布阵2.1 别一上来就追求“全量回归”需求澄清完之后很多测试同学急着把所有功能点都列进测试范围然后排一个看起来非常“全面”的测试计划。但实际执行时你会发现自己根本忙不过来最后要么加班赶进度要么偷偷砍用例。真正合理的做法是先做影响分析再做风险分级最后才定测试范围。影响分析就是看这个需求到底动了哪些代码模块、哪些数据库表、哪些接口影响面有多大。这一步如果团队里有开发配合最好没有的话就靠经验判断一个只改了文案的H5页面和一个改了支付流程的接口测试深度完全不是一个级别。我把测试范围分成三个层级核心链路涉及主业务流程、支付、登录、数据一致性等功能需要全量用例执行必要时补一轮自动化回归和基础性能测试。次要功能涉及展示层、辅助功能执行冒烟测试加主流程验证即可。纯展示改动比如按钮颜色、文案调整做一次视觉走查和基础回归就可以了不需要占用大量资源。这样分级的好处是你的时间和精力能花在刀刃上。上线前最怕的不是“没测到某个冷门功能”而是“支付链路出了重大bug”后者才是真正致命的。2.2 一页纸计划排期估算技巧很多测试团队还在用几十页的测试计划书模板说实话对于敏捷开发节奏来说完全没必要。我现在带团队做测试计划只用一页纸包含六个要素测试范围、环境要求、数据准备、人员分工、时间排期、风险与依赖。内容精简但信息密度高谁拿到手都知道自己该干什么。排期估算是测试计划里最容易翻车的地方。很多新人拍脑袋报一个时间结果执行到一半发现用例比想象中多得多。我的经验是总耗时 用例数量 × 单条用例平均执行时间 × 1.5缓冲系数 回归测试时间 环境准备时间。举个例子一个中型的后台管理系统需求涉及30个接口、15个页面设计出200条用例。单条用例平均执行时间按8分钟算包含验证数据和截图记录那就是200×81600分钟大约26.7小时。乘上1.5的缓冲系数是40小时也就是一个人5个工作日。再加上回归测试2天、环境准备0.5天整个测试周期排8个工作日左右相对合理。缓冲系数不是偷懒而是给“意外”留出空间测试环境不稳定、开发延期交付、过程中发现需求变更这些都是常态。把缓冲留足才能真正保证交付质量而不是用加班来填坑。3. 测试用例从“穷举”到“精准打击”3.1 用例设计不是写得越多越好很多测试新人有一个误区用例写得越多越显得自己认真。我曾经见过一个同事给一个“用户昵称修改”功能写了80条用例把每种字符组合都列了一遍看起来很全面但实际上大量是冗余的真正有价值的边界场景反而漏掉了。用例设计的核心是“用最少的高质量用例覆盖最多的有效场景”。这需要方法支撑常用的有等价类划分、边界值分析、场景法、判定表法、正交试验法和错误猜测法。不同方法对应不同场景输入框、下拉框、日期选择器这类有明确输入范围的用等价类和边界值。比如金额字段有效等价类是0.01到999999.99无效等价类是负数、零、超上限、非数字。边界值则要重点测0、0.01、999999.99、1000000.00这样的临界点。业务流程类的需求用场景法。把用户从进入到完成操作拆成基本流和备选流基本流是正常路径备选流是异常、取消、中断、回退等路径每条流都是一组用例。多个条件组合影响结果的用判定表或正交试验。比如优惠券系统是否登录、是否领券、是否满足使用门槛、商品是否在适用范围内四个条件组合出16种情况用判定表可以系统化梳理不会漏。错误猜测法则完全靠经验积累。我每次都会在用例里预留一部分“拍脑袋用例”把过去项目中出过高频bug的地方再测一遍列表为空、并发重复点击、弱网环境、页面长时间停留后操作、权限变更后旧token是否失效。3.2 用例评审不是走流程是拉齐认知用例写完之后很多人习惯直接提交评审然后会上照着用例一条条念大家昏昏欲睡最后说“没问题”就过了。这种评审等于没评。真正有效的用例评审重点不是念用例而是让开发和产品看你“怎么理解这个业务”。我会在评审前把用例按业务模块分组每组挑出最核心的场景讲清楚三个问题这个场景的输入是什么、操作路径是什么、预期结果是什么。如果开发或产品对预期结果有异议当场讨论、当场修订。我印象最深的一次评审是测一个订单拆分功能。我按PRD的理解设计了用例评审时开发说“拆单逻辑后端不是这么实现的是按商品品类拆不是按金额上限拆”产品在旁边一听也愣了说“按品类拆是我最初的想法后来改成金额上限拆了但PRD可能没更新”。如果没有这次评审这批用例上线前铁定暴雷。另外现在AI辅助用例生成已经比较成熟了我团队里也会用LLM工具把需求文档丢给它让它生成初版用例草稿然后再人工审校补充。工具能帮你省掉60%的机械整理工作但业务理解、场景深挖、异常判断这些还是得靠自己千万别直接拿AI生成的用例就跑执行。我在实际使用中能让用例覆盖度提升不少但那种“看起来没毛病、一执行就发现业务理解歪了”的情况也碰到了好几次。4. 执行与缺陷管理真正考验体力和心力的阶段4.1 执行顺序怎么安排决定了你加不加班用例执行不是拿到就闷头跑。我习惯按冒烟测试、主流程、异常场景、回归测试这个顺序推进。开发提测之后先跑冒烟测试。冒烟测试不需要覆盖全部用例只验证核心链路是否走通比如登录、主页面加载、核心接口返回正常。如果冒烟都不通过直接退回开发说明代码质量根本不具备测试条件。这时候别心软也别自己去改代码调通否则后面全是坑。冒烟通过后优先执行主流程用例确保业务主干是通着的。主干通了再去做异常、分支场景。这样即使时间被严重压缩你也能保证“核心功能可用”这个底线。回归测试的选择是另一个容易出问题的地方。很多团队的做法是全量回归如果项目周期长、用例量大全量回归一次要花好几天。我更倾向于精准回归改动点涉及的功能、改动点关联的上下游模块、历史上该模块的高频缺陷点这三类优先回归剩余的功能做冒烟级验证即可。如果团队有自动化用例沉淀把回归集中的高频模块用自动化跑能省出大量人力做新功能探索。4.2 写缺陷报告的核心是“让人能复现”可以说缺陷管理平台里10条bug有3条是别人看不懂的这不是夸张。比如“点击按钮后页面报错”“数据不对”“功能不能用”这种描述提交上去开发第一反应就是“复现不了打回”。我把一个合格缺陷报告的要素总结成六项标题、前置条件、操作步骤、实际结果、期望结果、辅助信息。辅助信息包含截图、日志、接口返回、版本号、测试环境、测试数据。其中操作步骤一定要精确到“第几步点了什么按钮、输入了什么内容”不要跳步。前置条件也一样是登录状态、特定角色、特定数据量还是特定网络环境写清楚。我自己的习惯是提交一条bug之前先按自己写的步骤原样走一遍确认能复现再提交。这一个动作其实只需要多花2分钟但能避免大量“无效bug”被开发打回来反复拉扯。严重等级和建议优先级也要分开功能不可用、主流程阻断、数据丢失是P0必须当天修复非核心模块的功能异常是P1样式错位、文案错误是P2优化建议是P3。跟开发沟通时给“建议优先级”而不是命令通常配合度会高很多。5. 复盘与交付让每一次测试都有积累5.1 上线不是终点交付报告要写“风险”而不是“流水账”测试执行的最后一步不是“所有用例跑完”而是把测试结果转化为可理解的交付结论。很多测试报告写得像流水账共执行用例300条通过280条失败20条上线通过。这纯粹是记录员干的事对决策没有任何帮助。一份有价值的测试报告至少要点出三件事已知风险这个版本还有哪些问题没有解决影响面多大是否可以接受建议结论建议正常上线、有条件上线、还是必须修复后上线有条件上线时条件是什么后续关注点上线后哪些功能需要重点盯线上日志、哪些指标异常需要警惕。比如我之前测过一个订单导出功能发现大批量导出时偶发超时但触发概率很低、影响面可控。我在报告里标注了“有条件上线建议放宽导出超时时间并增加异步队列”产品看了之后认可开发紧急优化后上线。这种风险提示才是测试报告的真正价值所在。5.2 复盘不是开会念PPT是把经验固化下来项目上线后很多团队会开复盘会但大部分复盘会开着开着就变成了“追责会”最后大家不欢而散。我比较推荐的复盘方式是不问“谁的锅”只问“流程哪里断了”。复盘会重点关注四个问题需求阶段有没有模糊点导致返工设计阶段有没有漏掉的异常场景执行阶段有没有资源不到位、阻塞时间过长交付阶段有没有风险未及时暴露每一个问题都要落到一个具体的改进动作上否则复盘就是浪费时间。另外复盘的产物要沉淀下来做成测试资产库。用例里新增的场景、踩过的坑、好用的测试数据、常用的模拟工具都归档到团队的共享文档里。下次再遇到类似需求可以直接复用而不是从零开始重新设计用例。资产库越厚后续项目的测试效率就越高。说到这我想起来之前带了一个刚转行的新人刚开始拿到需求就会焦虑天天问我“这个功能要测什么”。后来我让他严格按这5步走每一步都留痕一个月之后他已经能独立负责一个中型模块的测试了。所以说到底这5步不是什么高深的理论而是一套帮你在复杂信息中建立秩序的工作方法。测试这个职业越到后面越拼的不是技术而是你对质量风险的判断力和推进事情的能力这套5步法就是帮你练这个的。 干测试这一行最怕的不是bug藏得深而是需求还没搞明白就被催着写用例、提计划。我见过太多新同事拿到一个需求文档第一反应是打开Excel开始列用例结果列到一半发现业务逻辑理解错了全部推翻重来。这种情况一次两次是粗心次数多了就是在消耗团队的信任。我在测试这条路上走了快十年从功能测试做到测试负责人从手动点点点到搭建自动化测试体系总结下来有一个始终没换过的核心骨架拿到新需求按5步走。这套方法不只是我自己用我带团队时也要求新人照着走一遍效果非常稳定。不管你是做Web测试、App测试、嵌入式测试还是刚入行的测试小白这套思路都适用。接下来我把这5步拆开讲每一步该做什么、为什么要这么做、常见的坑在哪一次性说清楚。1. 先别急着动手把需求榨干到最后一滴1.1 需求分析不是在读文档是在“找漏洞”很多测试工程师拿到需求的第一步是打开PRD从头到尾读一遍读完觉得“嗯我懂了”然后就开始写用例。但等你真正写完用例、甚至执行到一半才发现自己对业务的理解和产品经理的预期根本不在一个频道上。问题就出在你把“读文档”当成了“理解需求”。需求分析的核心目标只有一句话找到所有可能导致理解偏差的模糊点并在动手之前把它们全部消除。具体到动作上我习惯拆成三步第一步通读需求文档两遍。第一遍不划线、不记录只看整条业务链路是什么样解决什么问题面向哪类用户。第二遍才开始划线凡是没有明确写清楚的、前后矛盾的、依赖外部系统的全部标注出来。第二步把标注出来的疑问整理成清单约产品经理开一次需求澄清会。注意不是开一个半小时的大会而是带着清单逐条确认确认一条、记录一条、关闭一条。第三步把确认后的业务逻辑画成流程图或状态图画图的过程其实就是在检验你对业务的理解是否闭环。很多测试同学说自己不会画图其实不需要多专业只要能画清楚“用户从哪进来、经过哪些操作、最终落到什么结果、异常情况怎么走”这张图就是你后续写用例的底稿。1.2 需求澄清的灵魂三问我每次开需求澄清会不管需求大还是小都会固定问三个问题这三个问题基本能覆盖90%的模糊地带这个功能的核心用户是谁他要解决什么问题用户从哪个入口进来完整的操作路径是什么中间如果断了一步系统该怎么表现异常场景下的预期结果是什么比如超时、失败、重复提交、权限不足、数据为空。举一个最常见的例子“忘记密码”功能。PRD上通常只写一句“用户可以通过手机验证码重置密码”看起来很简单对吧但你细问下去全是问题验证码几分钟内有效每天最多发几次发送失败后提示什么用户输入错误验证码5次后是否需要锁定重置成功后原token是否立即失效这些细节如果没有在需求阶段确认清楚到了测试执行阶段就是一遍遍找产品确认然后改用例、补数据效率极低。更可怕的是有些细节连产品都没想过等上线了用户一操作才发现问题那时候再改代价就大了。还有一类容易被忽略的需求是“非功能需求”。接口响应时间、并发用户数、数据保留时长、日志记录要求这些通常不会写在PRD的功能描述里但却是上线后最容易出事故的地方。需求澄清时候一定要顺带问一句“这个接口有没有性能要求数据要保留多久”2. 测试计划不是写文档是排兵布阵2.1 别一上来就追求“全量回归”需求澄清完之后很多测试同学急着把所有功能点都列进测试范围然后排一个看起来非常“全面”的测试计划。但实际执行时你会发现自己根本忙不过来最后要么加班赶进度要么偷偷砍用例。真正合理的做法是先做影响分析再做风险分级最后才定测试范围。影响分析就是看这个需求到底动了哪些代码模块、哪些数据库表、哪些接口影响面有多大。这一步如果团队里有开发配合最好没有的话就靠经验判断一个只改了文案的H5页面和一个改了支付流程的接口测试深度完全不是一个级别。我把测试范围分成三个层级核心链路涉及主业务流程、支付、登录、数据一致性等功能需要全量用例执行必要时补一轮自动化回归和基础性能测试。次要功能涉及展示层、辅助功能执行冒烟测试加主流程验证即可。纯展示改动比如按钮颜色、文案调整做一次视觉走查和基础回归就可以了不需要占用大量资源。这样分级的好处是你的时间和精力能花在刀刃上。上线前最怕的不是“没测到某个冷门功能”而是“支付链路出了重大bug”后者才是真正致命的。2.2 一页纸计划排期估算技巧很多测试团队还在用几十页的测试计划书模板说实话对于敏捷开发节奏来说完全没必要。我现在带团队做测试计划只用一页纸包含六个要素测试范围、环境要求、数据准备、人员分工、时间排期、风险与依赖。内容精简但信息密度高谁拿到手都知道自己该干什么。排期估算是测试计划里最容易翻车的地方。很多新人拍脑袋报一个时间结果执行到一半发现用例比想象中多得多。我的经验是总耗时 用例数量 × 单条用例平均执行时间 × 1.5缓冲系数 回归测试时间 环境准备时间。举个例子一个中型的后台管理系统需求涉及30个接口、15个页面设计出200条用例。单条用例平均执行时间按8分钟算包含验证数据和截图记录那就是200×81600分钟大约26.7小时。乘上1.5的缓冲系数是40小时也就是一个人5个工作日。再加上回归测试2天、环境准备0.5天整个测试周期排8个工作日左右相对合理。缓冲系数不是偷懒而是给“意外”留出空间测试环境不稳定、开发延期交付、过程中发现需求变更这些都是常态。把缓冲留足才能真正保证交付质量而不是用加班来填坑。3. 测试用例从“穷举”到“精准打击”3.1 用例设计不是写得越多越好很多测试新人有一个误区用例写得越多越显得自己认真。我曾经见过一个同事给一个“用户昵称修改”功能写了80条用例把每种字符组合都列了一遍看起来很全面但实际上大量是冗余的真正有价值的边界场景反而漏掉了。用例设计的核心是“用最少的高质量用例覆盖最多的有效场景”。这需要方法支撑常用的有等价类划分、边界值分析、场景法、判定表法、正交试验法和错误猜测法。不同方法对应不同场景输入框、下拉框、日期选择器这类有明确输入范围的用等价类和边界值。比如金额字段有效等价类是0.01到999999.99无效等价类是负数、零、超上限、非数字。边界值则要重点测0、0.01、999999.99、1000000.00这样的临界点。业务流程类的需求用场景法。把用户从进入到完成操作拆成基本流和备选流基本流是正常路径备选流是异常、取消、中断、回退等路径每条流都是一组用例。多个条件组合影响结果的用判定表或正交试验。比如优惠券系统是否登录、是否领券、是否满足使用门槛、商品是否在适用范围内四个条件组合出16种情况用判定表可以系统化梳理不会漏。错误猜测法则完全靠经验积累。我每次都会在用例里预留一部分“拍脑袋用例”把过去项目中出过高频bug的地方再测一遍列表为空、并发重复点击、弱网环境、页面长时间停留后操作、权限变更后旧token是否失效。3.2 用例评审不是走流程是拉齐认知用例写完之后很多人习惯直接提交评审然后会上照着用例一条条念大家昏昏欲睡最后说“没问题”就过了。这种评审等于没评。真正有效的用例评审重点不是念用例而是让开发和产品看你“怎么理解这个业务”。我会在评审前把用例按业务模块分组每组挑出最核心的场景讲清楚三个问题这个场景的输入是什么、操作路径是什么、预期结果是什么。如果开发或产品对预期结果有异议当场讨论、当场修订。我印象最深的一次评审是测一个订单拆分功能。我按PRD的理解设计了用例评审时开发说“拆单逻辑后端不是这么实现的是按商品品类拆不是按金额上限拆”产品在旁边一听也愣了说“按品类拆是我最初的想法后来改成金额上限拆了但PRD可能没更新”。如果没有这次评审这批用例上线前铁定暴雷。另外现在AI辅助用例生成已经比较成熟了我团队里也会用LLM工具把需求文档丢给它让它生成初版用例草稿然后再人工审校补充。工具能帮你省掉60%的机械整理工作但业务理解、场景深挖、异常判断这些还是得靠自己千万别直接拿AI生成的用例就跑执行。我在实际使用中能让用例覆盖度提升不少但那种“看起来没毛病、一执行就发现业务理解歪了”的情况也碰到了好几次。4. 执行与缺陷管理真正考验体力和心力的阶段4.1 执行顺序怎么安排决定了你加不加班用例执行不是拿到就闷头跑。我习惯按冒烟测试、主流程、异常场景、回归测试这个顺序推进。开发提测之后先跑冒烟测试。冒烟测试不需要覆盖全部用例只验证核心链路是否走通比如登录、主页面加载、核心接口返回正常。如果冒烟都不通过直接退回开发说明代码质量根本不具备测试条件。这时候别心软也别自己去改代码调通否则后面全是坑。冒烟通过后优先执行主流程用例确保业务主干是通着的。主干通了再去做异常、分支场景。这样即使时间被严重压缩你也能保证“核心功能可用”这个底线。回归测试的选择是另一个容易出问题的地方。很多团队的做法是全量回归如果项目周期长、用例量大全量回归一次要花好几天。我更倾向于精准回归改动点涉及的功能、改动点关联的上下游模块、历史上该模块的高频缺陷点这三类优先回归剩余的功能做冒烟级验证即可。如果团队有自动化用例沉淀把回归集中的高频模块用自动化跑能省出大量人力做新功能探索。4.2 写缺陷报告的核心是“让人能复现”可以说缺陷管理平台里10条bug有3条是别人看不懂的这不是夸张。比如“点击按钮后页面报错”“数据不对”“功能不能用”这种描述提交上去开发第一反应就是“复现不了打回”。我把一个合格缺陷报告的要素总结成六项标题、前置条件、操作步骤、实际结果、期望结果、辅助信息。辅助信息包含截图、日志、接口返回、版本号、测试环境、测试数据。其中操作步骤一定要精确到“第几步点了什么按钮、输入了什么内容”不要跳步。前置条件也一样是登录状态、特定角色、特定数据量还是特定网络环境写清楚。我自己的习惯是提交一条bug之前先按自己写的步骤原样走一遍确认能复现再提交。这一个动作其实只需要多花2分钟但能避免大量“无效bug”被开发打回来反复拉扯。严重等级和建议优先级也要分开功能不可用、主流程阻断、数据丢失是P0必须当天修复非核心模块的功能异常是P1样式错位、文案错误是P2优化建议是P3。跟开发沟通时给“建议优先级”而不是命令通常配合度会高很多。5. 复盘与交付让每一次测试都有积累5.1 上线不是终点交付报告要写“风险”而不是“流水账”测试执行的最后一步不是“所有用例跑完”而是把测试结果转化为可理解的交付结论。很多测试报告写得像流水账共执行用例300条通过280条失败20条上线通过。这纯粹是记录员干的事对决策没有任何帮助。一份有价值的测试报告至少要点出三件事已知风险这个版本还有哪些问题没有解决影响面多大是否可以接受建议结论建议正常上线、有条件上线、还是必须修复后上线有条件上线时条件是什么后续关注点上线后哪些功能需要重点盯线上日志、哪些指标异常需要警惕。比如我之前测过一个订单导出功能发现大批量导出时偶发超时但触发概率很低、影响面可控。我在报告里标注了“有条件上线建议放宽导出超时时间并增加异步队列”产品看了之后认可开发紧急优化后上线。这种风险提示才是测试报告的真正价值所在。5.2 复盘不是开会念PPT是把经验固化下来项目上线后很多团队会开复盘会但大部分复盘会开着开着就变成了“追责会”最后大家不欢而散。我比较推荐的复盘方式是不问“谁的锅”只问“流程哪里断了”。复盘会重点关注四个问题需求阶段有没有模糊点导致返工设计阶段有没有漏掉的异常场景执行阶段有没有资源不到位、阻塞时间过长交付阶段有没有风险未及时暴露每一个问题都要落到一个具体的改进动作上否则复盘就是浪费时间。另外复盘的产物要沉淀下来做成测试资产库。用例里新增的场景、踩过的坑、好用的测试数据、常用的模拟工具都归档到团队的共享文档里。下次再遇到类似需求可以直接复用而不是从零开始重新设计用例。资产库越厚后续项目的测试效率就越高。说到这我想起来之前带了一个刚转行的新人刚开始拿到需求就会焦虑天天问我“这个功能要测什么”。后来我让他严格按这5步走每一步都留痕一个月之后他已经能独立负责一个中型模块的测试了。所以说到底这5步不是什么高深的理论而是一套帮你在复杂信息中建立秩序的工作方法。测试这个职业越到后面越拼的不是技术而是你对质量风险的判断力和推进事情的能力这套5步法就是帮你练这个的。