★ FEATURED ARTICLE 第一次做软件测试基础培训的时候有个新人问我一个特别典型的问题“测试是不是就是照着用例点点点点完了没发现bug就算OK”我当时跟他说如果你只用这个思路做测试做三年跟做三个月没区别。软件测试基础这门功课表面上学的是“怎么测”实际上是在建立一套“如何用有限资源发现高价值风险”的思维方式。这篇内容我打算从头讲一遍把我带新人时反复强调的东西、踩过的坑、沉淀下来的方法都写出来适合刚入行或者想系统打一遍基础的测试工程师阅读。1. 先把测试的“世界观”摆正这不是找茬是控制风险1.1 你不可能证明“没有bug”这是测试行业最经典的一个悖论程序的行为空间是无限的而测试用例是有限的。任何一个功能输入组合、运行状态、数据环境、用户操作顺序叠加起来可能出现的情况几乎是天文数字。你永远不可能用例穷举的方式证明“这个软件没有bug”。那测试的意义在哪里答案是控制风险。测试真正回答的问题不是“软件有没有bug”而是“当前版本的质量风险是否已经降到可接受的范围”。这个认知是所有测试方法的地基。明白了这一点你就不会去追求“测遍所有情况”而会去思考“哪些情况最可能出问题、出了问题影响最大”。我面试的时候经常问一个问题给你一个登录功能你怎么设计测试用例很多人开口就说“正确的账号密码能登录、错误的密码报错”。这个答案没有错但停留在“点几下”的层面。真正的测试视角会先拆解登录逻辑涉及哪些数据规则哪些分支会导致系统状态变化哪些异常场景是用户高频遇到的这就是“测试思维”和“操作执行”的差别。1.2 一个真实的工作场景从“填表单”到“拆系统”我带过一个新人A同学接手一个注册功能的测试任务。他的第一版用例是这样的输入手机号、输入验证码、输入密码、提交、看是否注册成功。列了十来条看起来挺勤快但覆盖得很浅。我让他换一个思路不要从上往下操作流程而是把这个功能拆成四块——“前置条件”、“交互路径”、“数据规则”、“异常反馈”。拆完之后他发现问题多了很多前置条件里如果用户已经注册过再次提交会怎样数据规则里密码长度是6到20位那5位和21位分别应该提示什么异常反馈里验证码过期之后提交系统是报错还是静默刷新这些点不一定每个都会出bug但不拆开想一遍你根本不知道风险藏在哪。这就是“软件测试基础”里最重要的一个转变从“功能点执行者”变成“功能逻辑分析者”。测试用例不是操作步骤的记录而是你对系统行为预期的一种显性化表达。你写得越细、越有逻辑就等于你对这个系统理解得越深。1.3 测试从来不是测试组自己的事还有一个新人时期很容易踩的坑觉得测出bug就是测试的功劳修bug是开发的事改需求是产品的事自己只管提交缺陷单。这种“流水线心态”会让你的测试基础永远停留在执行层。质量是一个团队共同控制的结果。测试人员最有价值的位置不是坐在流程下游等着别人把东西丢过来而是往上游走半步。需求评审的时候测试能提出“这个规则边界有没有定义清楚”开发设计的时候测试能反问“这个异常分支有没有处理方案”。这一步很微妙不需要你做开发或产品的工作但你必须对业务逻辑足够敏感才能在最早的阶段把风险问出来。基础扎实的测试一定会被团队当成“质量风险探测器”而不是“点按钮的工具人”。2. 设计测试用例你以为在写步骤其实在做实验设计2.1 需求文档里最容易被忽略的四类信息用例设计的输入是需求但很多人看需求只看“正常流程怎么走”忽略掉了真正决定用例质量的细节。我一般会提醒新人重点找四类信息第一功能描述也就是这个功能到底要解决用户什么问题通常写得很显眼大家都看得到。第二规则约束比如字段长度、取值范围、数据格式、状态流转条件这类信息经常藏在说明文档或产品嘴里不仔细问就漏了。第三数据边界什么样的情况下数据是合法的跨过哪条线就变成非法这部分是最容易产生bug的区域。第四异常场景用户操作出错、系统超时、数据冲突、重复提交需求文档里往往一笔带过甚至不提但真实用户天天在触发。举个例子当时我测过一个满减活动满200减30。需求文档里主流程写得清清楚楚但实际落地的时候问题全在规则约束上——满200是按商品原价算还是实付价算运费算不算入200活动商品和普通商品能不能混在一起结算优惠券能不能叠加这些问题需求评审的时候不搞清楚用例就写不到位bug就会在上线后被真实用户帮我们测出来。2.2 等价类划分和边界值分析最经典的组合拳说到用例设计方法必然绕不开等价类划分和边界值分析。这两个方法看似简单但很多人只会背概念不会用。等价类划分的核心逻辑是一个输入域里很多数据对程序来说“是同一类”测其中一个代表值就够了没必要每个都测。比如用户名要求6到18位字母或数字那“abcdef”和“abc123”对程序来说处理逻辑是一样的选一个代表即可。把有效输入和无效输入各分几个类每个类选一个代表性数据这就能用很少的用例覆盖很大的输入空间。边界值分析则是在等价类的“边界”上做文章。实践经验是程序员写代码时最容易错的就是边界判断——用还是允许还是拒绝经常差一位出错。所以如果规则是6到18位那6、18要测5、7、17、19也要测重点关注“刚好合法和刚好非法”这两根线。我还想专门提醒一个实际教训很多人喜欢把所有有效等价类的数据凑在一起测一次登录成功就觉得万事大吉。问题在于一旦整体流程挂了你很难定位是谁的锅——是用户名规则的问题、密码校验的问题还是两个条件组合的问题建议的做法是单个规则用单变量去验证组合场景再单独设计组合用例。这样出了问题能快速缩小范围这也是为后续提Bug单做准备。2.3 场景法把用例串成一条“用户故事线”等价类和边界值解决的是“单个输入值”的问题但真实用户的操作从来不是单一的输入而是一连串动作的组合。这时候需要场景法。场景法的思路是先梳理出一个业务的基本流——用户完成一个核心任务的主路径再梳理备选流——各种分支和异常情况下系统怎么走。还是拿购物说基本流是“搜索商品→加入购物车→提交订单→支付→查订单状态”。备选流有库存不足、优惠券失效、支付超时、订单重复提交、支付成功但回调失败。每一条备选流都要设计对应用例而且要把它们编排成一个完整的“故事线”而不是一个个孤立的检查点。场景法还有一个隐性价值它能帮你模拟真实用户的使用节奏。比如在支付超时的用例里用户很可能再点一次“重新支付”这时候系统会不会生成两笔订单这种问题靠等价类划分根本看不出来只有把场景连起来才会暴露。2.4 用例模板的字段与写作技巧用例模板本身不复杂核心字段就那些用例编号、所属模块、前置条件、测试数据、操作步骤、预期结果。难点从来在于怎么写“预期结果”。很多新人的预期结果写得特别虚比如“页面显示正常”“弹窗提示错误”“登录成功”。这种写法开发看到会很崩溃因为“正常”是什么“错误”是什么全凭猜。合格的预期结果应该是可验证的、具体的比如“系统提示‘用户名或密码错误’输入框边框变红停留当前页面不跳转”或者“订单列表按下单时间倒序排列每页固定显示20条顶部显示订单总金额”。关于前置条件也不要只觉得“打开页面就行”。前置条件要写清楚数据环境是已登录状态还是未登录账号有没有绑定手机号数据库里有没有历史订单这些因素会直接影响用例执行结果。凡是前置条件写不清楚的用例执行起来十有八九会被环境问题打断。3. 缺陷管理一条Bug单要写到开发和产品都服气3.1 一条Bug从被发现到关闭的一生缺陷管理的起点是“发现”终点是“验证关闭”中间会经历一系列状态流转。不同公司的叫法略有差异但基本逻辑是一致的新提交New→ 开发确认Open→ 修复中Fixed→ 测试验证Verified→ 关闭Closed中间可能插入“重新打开Reopen”和“延期Deferred”。这个流程看起来简单实际执行中混乱的地方特别多。最常见的乱象是开发改了一版代码直接在IM上说你测测然后随时等着你回复“好了”。这种非正式的沟通短期效率挺高但一旦版本多了、人员换了问题就全丢了。我的建议是即时沟通可以做但必须在缺陷管理平台留一条“可追踪”的记录。Bug什么时候提的、谁处理的、改了哪些文件、在哪个版本验证通过这些信息都是项目的无形资产。测试人员作为缺陷流程的“看门人”要坚持一条原则状态流转必须通过正式渠道完成任何口头承诺都应当及时落到系统里。3.2 缺陷单的核心字段怎么写才算“好”一条高质量的缺陷单需要的字段不超过8个但每一个都得经得起推敲。标题是最重要的。不要写“XX页面报错”要写“未登录状态下访问XX页面点击查询按钮后系统返回500”。一个好的标题 模块 前置条件 操作 具体结果让人一眼看出问题范围和严重程度。前置条件和复现步骤要连起来看别人拿着你的单子能不能按步骤走一遍就复现如果还需要某个特定账号、特定数据一定要写在前面不能藏在最后。实际结果和期望结果要对比记录实际是什么现象、期望是什么现象。最后附件涉及到的截图、日志、接口返回报文能贴就贴。我就吃过不少亏。当年在某支付项目里我提了一个“支付成功后订单状态未更新”的单标题写了“支付回调异常”。开发打开一看目录就觉得是我环境的问题因为代码里这块逻辑他自测过好多次。后来我把完整的请求报文、支付平台返回的回调记录、数据库订单表的前后状态对比截图全部打包贴在单子里开发闭嘴了两小时定位到是回调幂等性处理漏了一种状态。所以每次有人问我“为什么我提的bug开发总是不认”我都会先反问一句“你的单子有没有写到‘开发不用问第二句话’的程度”这个标准听起来苛刻但确实能让你的工作顺畅很多。补一个总结表格字段写作要点反例正例标题模块前置操作结果登录报错未注册手机号登录时提示“账号不存在”而非引导注册前置条件数据、环境、状态打开页面使用已绑定手机号且未设置密码的账号网络切为2G复现步骤每步可操作随便点点就报错1. 进入登录页 2. 输入... 3. 点击... 4. 观察...实际结果具体现象系统异常页面弹出红色提示“系统繁忙”按钮持续loading期望结果可验证标准应该正常登录成功后2秒内跳转首页右上角显示用户昵称附件截图、日志、报文无抓包请求正文响应状态码截图3.3 开发说“本地复现不了”怎么排查这是所有测试都会遇到的老大难。开发那句话一出来很容易把问题引向“是不是你操作不对”的争论。但如果你自己的复现步骤足够严谨大部分“复现不了”其实是有规律可循的。从我的经验来看复现不了的常见原因无非四类第一类环境差异。开发本地连的数据库、中间件配置、依赖服务版本可能跟测试环境不一样。特别是有缓存、有异步任务、有定时调度的系统环境不同行为就会不同。第二类数据依赖。你的前置条件里没写清楚某个关键数据比如账号是否绑卡、订单是否处于已发货状态、历史数据是否包含退款记录。开发随手拿了一个干净账号去试自然复现不了。第三类操作时序。真实复现路径需要先做A操作、再迅速做B操作中间间隔不能太长。你手动点的时候无所谓开发自己点的时候动作慢了时序就断了。第四类步骤写得不够精确。比如你只写了“点击保存按钮”但没写点击前是否修改了某个字段、是否先触发了某个联动事件。没有精确步骤等于没有复现路径。当年某支付项目的那个bug就是这个套路。开发看完步骤后在自己环境里试了三遍全都正常。我把数据显示给他该账号在测试环境绑定过银行卡并且本地缓存保留了绑卡状态而开发用的新账号没有这个缓存数据所以走了不同分支。开发加了缓存清理操作之后一次就复现了。所以当开发说“复现不了”的时候先别急着争辩按上面四类原因逐项自查环境、数据、时序、步骤精确度。自己排查过一次之后你会发现自己写题的时候会主动规避这些问题缺陷单质量反而跟着提升。3.4 严重程度和优先级别傻傻分不清新手最容易混的两个字段就是严重程度Severity和优先级Priority。严重程度说的是这个bug对系统的破坏力偏技术层面优先级说的是这个bug要什么时候改偏项目管理层面。举个例子某个冷门页面文字标点符号错误严重程度很低但明天下班前必须上线对外展示那优先级就可能很高。反过来某个只在特定作弊场景下才会触发的数据完整性问题影响了一部分核心数据准确性那严重程度可能到P0但优先级取决于是否已有真实用户受影响。我见过不少团队在这两个字段上吵得不可开交本质是拿“严重程度很高”来证明“必须马上改”其实这混淆了两件事。测试提缺陷单的时候应当先客观评价严重程度再结合业务、节点、影响面判断优先级。如果有分歧拉上产品或项目经理一起拍板而不是自己拍脑袋。级别严重程度典型示例P0系统崩溃、数据丢失、核心流程不可用支付成功后订单状态不更新库存扣减异常P1主要功能出现错误但有临时绕过方案注册接口响应超时重试可成功P2次要功能受影响或局部体验异常列表页筛选条件偶尔丢失P3界面、文案、交互等轻微问题按钮文字错别字提示语不统一4. 从手工到自动化金字塔是方向但得从脚下走起4.1 为什么每个人都该理解“测试金字塔”做了一段时间手工测试之后很多人都会冒出同一个念头要不要转自动化这是个好念头但心态要摆正。自动化不是手工测试的“升级版”而是整体测试策略中的一部分。这里就不得不提经典的测试金字塔理念。金字塔从下往上分别是单元测试、接口服务测试、UI端到端测试。底层的单元测试数量最多运行最快、成本最低、定位问题最精准顶层的UI测试数量最少因为最慢、最脆、维护成本最高。这个模型想表达的核心思想是尽量把测试重心放在稳定、快速、低成本的层级把UI自动化作为补充验证手段而不是把所有希望都压在界面上。如果你是刚接触自动化的测试人员我建议先从接口层入手。原因很简单接口相对稳定不受页面改版影响执行速度快断言逻辑清晰而且能覆盖到很多UI层面测不到的服务端逻辑。而UI自动化对元素定位、环境稳定性要求高新人一上来就搞通常会被“一行代码改得整个套件挂掉”的体验劝退。不是说UI自动化不能做而是应该排在接口层之后。4.2 什么样的项目值得先做自动化不是所有项目都适合一上来就自动化。判断的依据就三条是否高频回归、是否核心稳定、是否有人力成本去维护。适合做自动化的典型场景是核心业务接口有明确且稳定的输入输出每轮发版都要回归一遍人工反复执行太耗时或者接口数量多、依赖关系复杂手工测一遍需要半天自动化脚本十几分钟就能跑完。这种情况下自动化带来的收益是无争议的。不适合做自动化的场景同样明显一次性活动页面、频繁改版的原型阶段、UI样式天天动的模块这种做自动化等于天天修脚本。我见过最夸张的案例一个活动页每两天改一次按钮文案自动化用例光定位器就维护了三个版本最后团队忍痛把该模块的用例全部降级为手工执行。自动化不是KPI不能用它来证明自己技术多好它只是为质量服务的工具。综合来看我第一次带团队做接口自动化的时候选的切入点是“订单查询”和“物流状态查询”两个模块因为这两个接口调用方多、参数组合多、每次版本都要回归而且接口协议很稳定。先把这两个模块跑顺了积累了处理数据清理、断言规范、环境切换的经验再往其他模块推广阻力会小很多。这个从简单到复杂、从局部到全局的推进节奏比一口气铺开所有接口要靠谱得多。4.3 从手工到自动化的落地路径建议如果真的决定开始做自动化我建议按下面这个路径来走顺序很重要第一步先梳理场景清单。把手工回归里最耗时的、重复度最高的、最容易出错的核心流程列出来按“回归频率×重要程度”排序选出第一批自动化范围。第二步把这些场景做成数据规范明确接口的请求参数、预期响应、依赖数据怎么准备、执行完数据怎么清理。第三步再考虑用哪套工具或框架去实现——这一步反倒不用太纠结市面上成熟的选择很多关键是先跑通一条最小链路。第四步把自动化的执行纳入到日常流程里比如每次发版前跑一遍跑挂了第一时间看日志。很多团队做自动化失败不是工具选错了而是前面两步没做扎实。场景没梳理清楚就急着写脚本写出来的东西往往跟手工用例重复数据准备和清理不做规范跑第二次就各种脏数据断言写得太弱脚本“绿了”但实际功能其实已经坏了。我自己的体会是自动化真正改变的不是测试的执行方式而是测试的思考方式。写完一个接口脚本你需要想清楚这条用例要验证什么、哪些字段是这次改动影响的、哪些参数是稳定的、哪些数据必须隔离。这个过程推动着你把功能逻辑梳理得更细反过来对手工测试用例的设计也有很大帮助。而自动化省下来的执行时间不是让你闲着的是用来做探索性测试的——那部分永远无法被脚本替代。5. 测试思维的养成从“执行者”到“质量守望者”5.1 熟悉业务比熟悉工具重要得多到了这个阶段我特别想强调一件事测试思维的核心不只是技术更不是工具而是对业务的理解。同样一个“查询订单”功能电商、金融、物流对它的数据一致性和状态流转要求是完全不同的。你越懂业务就越知道哪里值得往深处测。怎么才算熟悉业务不是把需求文档背下来而是能回答“这个功能为什么存在”“这个规则是怎么想出来的”“用户最在意的是什么”。当时我做财务系统的支付模块测试刚开始只关注功能是否跑通后来跟着业务方聊了几轮才知道这个模块最核心的诉求不是功能丰富而是每一笔账都可追溯、可对平。从那以后我的用例重点开始往“账务流水一致性”偏移自己都明显感觉到测试做得更有方向感了。5.2 用例库要持续维护不能写完就“躺平”用例写完之后不是放进测试管理平台就完了。需求变更了用例要不要更新上线后发现了线上bug反推一下是不是用例有漏测开发重构了底层逻辑之前那些“不会出错”的边界条件要不要重新验证这些都是用例维护的日常。我在实际工作中养成了一个固定动作每次版本上线之后把线上发现的bug拿出来跟用例库对照一遍看是“有bug但是我们没测到”还是“根本就没设计这条用例”。如果是后者就说明用例设计有缺口我把这类bug归入一个叫“漏测分析”的清单每季度回顾一次看看自己的用例设计和测试思路在哪个环节系统性不足。这个方法很土但效率非常高比我单独讲一百遍“要好好设计用例”都管用。5.3 两个非常值得坚持的小习惯最后分享两个我一直在用的习惯对测试思维的成长帮助很大。第一个是Bug复盘。每周抽半小时把本周最典型的3个bug拉出来不看修复方案先自己分析这个bug为什么会在测试阶段漏掉是需求理解偏差、用例覆盖缺失、环境因素还是时间不够每一步追问往下挖比盲目加用例有效得多。复盘的目的不是追责而是找到“下次如何更快发现同类问题”的方法。第二个是交叉测试。有机会的时候让不同的测试人员互相测对方负责的模块。每个人对系统的理解、操作习惯、思维盲区都不一样交叉测试经常能发现“本模块负责人怎么都想不到”的场景。第一次做交叉测试的时候另一个同事用“先下单不支付再去取消未支付订单然后又对同一订单发起支付”这种极端组合测出了我的盲区——我按正常用户思维根本不会这么做但真实的高阶用户完全有可能。这类发现恰恰是基础方法论之外、最有“测试嗅觉”价值的部分。我自己带人的经验也印证了这两点的作用。很多刚入行的新人一开始都在追工具、追框架觉得会用几个自动化工具就算测试基础扎实了。但半年到一年之后真正拉开差距的不是工具熟练度而是能不能把系统拆得足够细致、把用例设计得足够有层次、把缺陷描述得足够清晰、把风险判断得足够准确。软件测试基础这套东西学起来不难难的是愿意在这些“看起来很基础”的事情上持续花功夫。把这些基本功磨扎实了后面碰到的任何新工具、新平台、新方法都会变成顺手的延伸而不是重新学一遍。
阅读完成 · 觉得有帮助？
