简介《测试用例编写指南》是一份面向测试设计人员、技术管理团队成员及需要规范用例编写流程的从业者的docx文档针对凭惯性设计、颗粒度不一、可读性和覆盖度不足等问题提供可循的编写依据。压缩包共1个docx文件约494KB篇幅精炼便于检索和团队内共享。已有553人学习。文档从目的、适用范围和测试设计依据讲起依次梳理需求分析、业务流程分析、系统设计分析、用例编写与完善五个步骤并说明用例路径、前置条件、操作步骤、预期结果、优先级、用例类型、属性和测试方式等要素。内容还涉及测试需求与用例划分原则、编写要求、常见测试类型、等价类划分、边界值分析、状态迁移等设计方法以及用例维护和生产问题回溯思路。读者可据此统一模板与粒度补充异常、边界和回归检查点提升测试设计的规范性与投产质量。1. 一份测试用例编写指南能补上什么从“凭惯性思考”到末级检查点上一轮迭代的用例评审两个测试同学为一条用例该不该拆争了二十分钟最后发现争的不是拆法是各自心里那套用例编写注意点根本不一样一个人按页面拆一个人按检查点拆。这类分歧在小团队里很常见落到投产就是覆盖不全、回归跑不动、缺陷复盘时说不清是漏测还是没写。测试用例编写指南这类文档的价值就在这里——它不教你怎么想它把需求分析到用例完善切成固定几步把用例要素的字段口径固定下来再用一张对照表告诉你不同测试对象该拆到什么颗粒度。下面按文档骨架走一遍重点放在能直接搬进项目的那部分适合测试负责人和刚接手用例设计的新人照抄。2. 五步法拆开看需求分析到用例完善各自的输入输出文档把编写过程切成五步每一步都明确写了输入、处理、输出三段。这个写法本身就值钱——它迫使你在每一步结束时交出一个可检查的产物而不是“我感觉想清楚了”。很多团队的用例质量问题追到根上不是写得不细是中间步骤没有产物直接从需求文档跳到了用例表格跳过了业务流程和系统设计两层分析结果用例只覆盖了需求文档字面上写了的那部分。先把五步的骨架摆出来后面几节逐条展开。步骤输入处理输出需求分析业务需求说明书按流程或功能分类测试需求需求细节逐条列为检查点业务流程分析业务背景知识、被测系统/模块流程梳理主流程、备选流程、数据流向、关键判断条件、非必要条件补充需求文档未提及但需覆盖的检查点系统设计分析概要设计、详细设计、接口设计、数据库设计分析改动点及影响范围改动功能涉及的全部逻辑、影响范围的回归检查点用例编写测试需求覆盖生产上所有业务流程场景与系统逻辑分支正向之外关注边界、异常功能正确性、边界、异常、接口、信息安全等类型用例用例完善评审意见、变更、执行反馈、生产问题按触发条件更新维护修订后的用例集这张表我一般会打印出来贴在工位上写完一批用例回头看一眼哪一步的产物是空的基本就能定位到漏测出在哪一层。下面是每一步的实际做法。2.1 需求分析把业务需求拆成可数的检查点这一步的产出不是用例是检查点清单。常见做法是把需求文档里带“应当”“可以”“支持”“不允许”的句子逐句圈出来一句至少对应一个检查点候选。举个虚构的例子某跨平台系统的“消息发送”需求文档一句话里含单条发送、批量创建、定时任务三种形态那就至少拆出三个一级需求每个下面再挂检查点。分类维度只有两条按流程分按功能分。按流程适用于一条业务链路跨多个功能模块的情况比如从任务创建到审批到执行按功能适用于单个菜单或单个接口的情况。分类做完需求路径基本就定下来了形如“/项目名称/一级需求/二级需求/……/N级需求”。这一步别急着写用例描述先把需求名称和检查点列全因为后面所有用例都挂在这棵树下面树歪了后面全歪。有个容易忽略的点需求分析阶段的输出是“测试需求”不是“测试用例”两者在文档里是分开定义的。测试需求只回答“要验什么”用例才回答“怎么验”。把这两件事混在一步做写出来的东西往往描述含糊因为脑子里同时在处理“验什么”和“怎么验”两个问题。2.2 业务流程分析补需求文档没写的那部分需求文档写的是系统应该做什么不写用户实际会怎么走。业务流程分析这一步就是补这个缺口。输入是业务背景知识和被测系统/模块的业务流程处理时要把主流程、备选流程、数据流向、关键判断条件以及完成该操作的非必要条件全部整理出来。主流程和备选流程的差别在实际项目里非常具体。拿一个虚构的审批场景说需求文档只写了“审批通过/拒绝”两种结果业务流程分析会补出“支行经办-分行审核拒绝”“支行经办-分行审核通过-总行审核通过”这类组合路径以及每条路径上审批人角色不同带来的权限差异。这些组合在需求文档里通常不会逐条列但不测就是漏。数据流向决定你要准备几份数据。完成某个操作的必要条件里往往藏着前置数据的要求比如账户状态必须先处于某个值、某张关联表必须先有记录。把这些整理出来前置条件字段就有内容可写了。非必要条件指的是缺了它流程也能走通、但结果会不同的东西比如某开关打开和关闭走的是两条分支这类也必须作为检查点列出来。这一步的输出形态是“补充检查点”明确标注它不属于需求文档原文。这样做的好处是评审时能分清哪些是需求本身要求的、哪些是测试自己补的需求变更时回填也有依据。2.3 系统设计分析改动点与影响范围怎么圈系统设计分析是用例最容易漏的一步也是新人最不愿意做的一步因为要读设计文档。输入是系统设计、接口设计及数据库设计文档处理时针对系统为实现业务需求所做的主要改动点和影响范围做全面分析。我的习惯是拿两份东西对照设计文档里的改动清单和数据库变更脚本。逐个改动点问一句“谁调用了它”。改一个字段类型可能牵动三张表、两个对外接口、一个报表统计口径改一个接口的返回结构可能让上游三个调用方全部受影响。这些调用关系不会自己出现在需求文档里只能从设计文档和代码依赖里挖。这一步的输出有两类检查点一是改动功能支持的全部逻辑分支二是影响范围的回归检查点。第二类最容易被砍因为看上去跟本次需求无关但恰恰是生产事故的高发区。关联性测试和回归测试的检查点基本都从这一步产生。项目时间紧的时候可以砍执行轮次但不建议砍这一层的检查点设计砍设计等于把风险藏起来了。2.4 用例编写与完善五个必须回头的触发条件用例编写这一步的输入是测试需求处理要求是尽量覆盖生产上所有业务流程场景和系统逻辑分支正向之外加强对边界、异常的覆盖。输出覆盖功能正确性、边界、异常、接口、信息安全等类型。注意这里的措辞是“生产上的所有业务流程场景”不是“需求文档里的所有场景”。这两者的差距就是前面两步补出来的内容。很多用例集看上去条数不少但一跑生产就出问题原因往往是用例是照着需求文档逐句翻译的没有业务流程和系统设计两层输入。用例完善这一步写的是触发条件一共五条评审过程中发现用例存在问题系统新增功能或需求变更测试过程中发现设计时考虑不周、存在遗漏点系统出现生产问题经分析判定为测试泄漏。第四条最值钱也最少被真正执行。多数团队处理生产问题的流程是定位、修复、验证、关闭。用例库不动。结果同一个位置第二次出问题还是同一批人重新想一遍。我的做法是每出一条生产缺陷先在用例库里按模块搜有没有对应用例有就补操作步骤或补预期结果的检查点没有就新建一条并把缺陷编号记在备注里。这条规则坚持两个迭代用例库才会随着系统一起变厚而不是每次迭代都从零开始。3. 用例要素与字段定义一张表管住路径、步骤与预期结果要素这块文档给了两份清单测试需求五个字段测试用例十二个字段。字段本身不难难在几个字段的填写口径会直接决定用例能不能被复用、能不能被自动化脚本接、能不能在半年后还有人看得懂。这一章把字段逐个过一遍重点讲口径而不是定义。3.1 路径字段用例库的索引怎么定需求路径指的是需求所属的结构目录形式是“/项目名称/一级需求/二级需求/……/N级需求”。用例路径是在需求路径基础上再加一层需求名称即“/项目名称/一级需求/……/N级需求/需求名称/”。两条规则看着简单实际填的时候有几种常见分歧。第一种路径里要不要带版本号。我的建议是不带。版本用其他字段区分路径只管层级。路径一旦掺进版本跨版本统计覆盖率就没法做了因为同一个功能在不同版本下路径不同聚合时报表全是散的。第二种同一功能多个入口怎么处理。文档给的做法是合并编写一个需求路径只到功能层入口差异放在用例的操作步骤里体现。比如某功能既有列表页入口又有详情页入口需求层面是一个用例层面可以按入口拆成两条但路径相同。第三种层级多深合适。我一般控制在五级以内。超过五级说明这个需求本身该拆了而不是继续往路径里加层。路径过深的直接后果是筛选和统计变麻烦间接后果是没人愿意维护这棵目录树最后变成一堆平铺的需求名。3.2 名称、前置条件、步骤、预期结果的写法口径这四个字段是评审时被挑毛病最多的地方也是最能体现编写水平的地方。文档对每个字段都给了明确的正反要求整理成下表更好对照。字段应该写成什么常见反面写法测试名称简洁能直接识别测试对象和检查点如“放款失败-合同冻结”把操作步骤塞进名称如“点击放款按钮后检查合同状态为冻结并查看日志”前置条件特殊账号权限要求、数据准备、前置操作完整列出描述的是系统当前状态写成“先执行用例XXX”形成用例之间的依赖链操作步骤入口、与测试点相关的输入要素、按钮、运行的任务、操作顺序步骤里出现“检查”“确认”“验证”字样预期结果检查点完整列出含页面显示、提示信息、后台数据存储、前后端数据一致性预期结果里写“点击某按钮”这类操作动作关于预期结果还有几条细化要求值得单独说。前端操作成功或失败检查点要覆盖页面显示、提示信息、后台数据存储、前后端数据一致性四层只写“提示成功”是不够的提示文案的关键内容也要写明。涉及后台数据存储或变更的要明确具体数据表和关键字段的取值变化写“数据正确保存”等于没写因为执行的人不知道去哪张表看哪个字段。后台系统测试和涉及信息安全的前端操作测试必须包含输出日志、后台数据存储结果的检查。这一条在实操中经常被简化掉理由是查日志麻烦。但恰恰是这类检查点在出问题时提供了唯一可回溯的证据少了它缺陷复盘就只能靠猜。提示信息要明确关键检查内容比如“系统提示分类名称已存在添加失败”而不是“系统提示错误”。文案在迭代中会改写成关键内容而不是逐字照抄可以降低维护成本但关键语义不能丢。3.3 步骤与预期结果的三种映射关系文档花了较大篇幅讲操作步骤和预期结果分支的对应关系因为这是实际编写中最容易写乱的地方。三种关系如下。映射类型形态处理方式一对一一种操作对应一个预期结果分支直接编号对应即可多对一多种操作对应一个预期结果分支每种操作单独列步骤共同指向同一预期结果多对多多种操作对应多个预期结果分支通过相同编号反映对应关系或按预期结果分支拆成多条用例一对一最干净写起来也最快。多对一的典型场景是几种不同操作都能触发同一个结果比如删除一级分类目录、删除多级分类根目录、删除多级分类子目录三种操作都指向“可成功删除未挂用例的测试执行集”那就并列三步、共用一个预期结果。多对多在文档里的态度是明确的不建议使用尽量按预期结果分支拆开。实在拆不开时用编号把步骤和预期结果一一挂钩比如步骤标 1、2、3预期结果也标 1、2、3。另外两条硬规则要记住操作步骤和预期结果分支原则上不允许出现一对多一个预期结果分支如果含多个步骤可以先把步骤按序列出再把检查点和它的前置依赖步骤通过编号关联。这两条规则看起来是格式问题实际影响的是执行效率——执行人照着写不清的映射关系跑很容易漏掉某个分支。3.4 优先级与其他四个字段优先级的划分方式文档是按执行顺序分的不是按业务重要性分的这一点要在团队里说清楚否则新人会把用户最关心的功能全标成高。级别含义典型用例高优先执行系统基本功能及关键路径正常流程、页面元素正常输入中次级执行确保功能完善异常流程、页面元素异常输入低最后执行体验与辅助功能页面元素显示剩下的字段里用例类型分为流程类、功能点类、报表统计类、界面类、报文接口类、批处理、其他类用例属性分正常、异常测试方式分手动、自动化执行次数记录该用例被执行过的次数。执行次数这个字段最容易被当成摆设实际上它是回归轮次统计的依据也是判断一条用例是否还有存在价值的参考——连续多个版本执行次数为零的用例要么是覆盖了废弃功能要么是被人为跳过了两种都该处理。4. 划分原则落地颗粒度控制到“一条用例一个检查点”颗粒度是评审会上最容易吵起来的话题。粗了漏测细了维护成本高而且不同人对“粗”和“细”的直觉差异很大。文档给的做法是先按测试对象分类每一类给出明确的划分依据和划分方式再用示例锚定。这一章按这个思路把七类对象过一遍。4.1 测试需求划分七类对象的划分依据测试需求这一层的划分核心是按层级往下走一级需求、二级需求、三级需求逐层细化。不同测试对象的划分路径不一样对照表如下。测试对象分类划分依据划分方式前端功能新增/修改菜单上级目录名称、菜单名称、功能名称流程类全业务流程流程名称、步骤名称后台功能新增/修改单功能/接口接口名称、校验类型批处理批处理节点节点名称后台流程全流程/场景流程名称、步骤分解数据埋点埋点类型新增埋点检查、原有埋点检查、兼容性兼容性测试维度兼容性测试举两个示例帮助理解。前端功能类路径大概是“公共设置/系统设置/用户管理/用户注册”一级是上级目录二级是菜单三级是功能点。流程类路径是“贷后业务流程/合同登记”这种形态一级是流程名二级是步骤名。后台接口类路径是“登陆接口/入参校验”或“登陆接口/系统逻辑检查”一级是接口名二级是校验类型。划分依据统一之后需求树的结构就稳定了后面做覆盖率统计、做需求追溯都能按同一套维度聚合。4.2 需求描述的检查点写法需求描述这个字段要列出针对末级需求的所有检查点不是写一段说明文字。文档给了六条补充规则实操价值都很高。同一项目需要区分多系统或多需求测试时把系统名称或需求名称作为一级需求上面那套划分方式作为它的子需求。这条规则解决的是一棵树上挂多个系统的冲突问题。检查点数量较多时把末级需求做进一步细分而不是在一个需求描述里堆一长串检查点。堆在一起的后果是执行和统计都没法按检查点追踪。同一功能不同入口合并编写一个需求。入口差异在用例层面处理需求层面不拆。一个功能的正常流程对应一个检查点。这条是基准线不是上限。一个功能中包含多个正常场景或异常流程分别列出多个检查点。比如某操作既有成功路径又有三种失败原因那就是四个检查点不是一个。同一功能需要准备多份不同数据时原则上分别列出多个检查点如果是针对同一操作需要同时对多份数据进行处理可以单独列一个组合检查点。这个区分很细但会影响后面用例的拆分方式。4.3 测试用例划分按对象给对照用例层面的划分原则是“一个测试需求检查点对应一条用例”但不同测试对象有各自的调整方式。前端功能类的调整最灵活页面要素检查一条列表查询、分页、删除功能各一条表单新增或修改的输入项检查视表单输入项数量而定可以按输入项或输入分区拆。输入项超过十个的表单全塞一条用例里执行时会很难受因为任何一项出错都要重新走一遍。业务流程类坚持一条检查点一条用例全流程和工作流分别列。全流程是端到端的完整路径工作流是审批环节的组合两者的失败模式不一样。后台功能类给了合并空间原则上一个检查点一条用例但入参有效性检查这类可以合并成一条把多个非法输入放在同一条用例的不同步骤里。这样处理的前提是预期结果足够清晰每个非法输入对应的提示要写明白。批处理、后台流程、数据埋点都是严格的一检查点一用例。数据埋点类按页面划分每个页面对应一条用例。兼容性类的划分按维度走按移动端操作系统维度可以分成两条按机型维度机型有多少种就有多少条按浏览器维度同理。维度选哪个取决于项目实际的风险面不是都测一遍才叫全。还有一条容易忽略的说明同一个功能的自自动化用例和功能用例应当匹配如果自动化用例不能完全覆盖功能用例就把两者拆成互补的用例集。这条规则避免的是重复覆盖和覆盖空档同时存在——自动化跑的那些手工再跑一遍是浪费自动化没覆盖的手工也没写就是漏洞。4.4 合并与拆分的三条界线颗粒度控制到最后落到三个判断上。同一个需求检查点对应多种操作步骤时可以合并编写一条用例用例里详细列出所有操作步骤。判断依据是这些操作指向的预期结果是否相同。同一个预期结果含多个检查点、且这些检查点由多个不同操作产生时不建议合并尽量按预期结果分支拆开。多个预期结果中含多个检查点的组合是最难执行也最难维护的形态。一组操作对应一个预期结果、且需要重复验证的场景可以写成一条用例但要在前置条件和预期结果里写清楚每次验证的共同判定标准。5. 常见问题排查五类翻车现场与修法规范写在文档里是一回事落到每个人的手上是另一回事。下面这五类问题在我见过的用例集里出现频率最高按现象、原因、解决三段写对照着改比较快。5.1 前置条件写成相互依赖链现象用例 A 的前置条件写“先执行用例 B”用例 B 又写“依赖用例 C”单独抽一条出来跑不了回归时想删又不敢删。原因把“系统当前应处于什么状态”写成了“前一步做什么操作”。前者是状态描述后者是流程描述混在一起就形成了依赖。解决前置条件只写状态、权限和数据准备。比如“指定用户具备所选项目的测试负责人权限指定项目的测试执行集中有已创建的测试轮次和分类目录其中含未挂用例的分类目录”。状态怎么来的交给环境初始化或数据准备不写进用例。这条改完之后用例之间就能任意组合成执行集回归时可以按风险挑着跑。5.2 操作步骤里混进检查结果现象步骤里写“点击删除检查提示删除成功”预期结果里又写一遍“提示删除成功”。执行时不知道该在哪一步做判断。原因边写边验的习惯带到了文档里。写的时候手上有环境顺手就验了顺手就记在步骤里了。解决步骤只写动作和输入判断全部留在预期结果。自查方法很简单把每条步骤读一遍凡出现“检查”“确认”“验证”“查看”字样一律挪到预期结果。这个动作花不了几分钟但能显著降低执行时的歧义。反过来预期结果里出现“点击某按钮”“输入某值”这类动作描述也要挪回步骤。5.3 颗粒度两极化现象一条用例覆盖一个模块的所有输入框执行一次要半小时另一条用例只写“页面显示正常”执行时全靠执行人自己发挥。原因没有对照划分原则按个人手感写。写的人觉得细的那条太啰嗦粗的那条反正也不会出错。解决先按测试对象分类确定用哪套划分方式再按类里的规则落。前端功能按页面要素、列表查询分页删除、表单输入项三个区拆表单输入项多的时候按输入项或输入分区再拆。下限是一条用例一个检查点上限是执行一条用例不超过十分钟。超过上限就说明该拆了低于下限说明检查点没列全。5.4 设计方法用成摆设现象文档列了功能正确性、异常、边界值、等价划分、错误推测、因果图六种设计方法实际用例集里只有正向流程异常和边界几乎为零。原因方法只出现在培训里没有落到字段上。写用例时脑子里想的是功能怎么用不是数据怎么坏。解决让用例属性字段和设计方法对应起来标“异常”的用例必须能说出用的是哪种方法。异常测试的标准动作是模拟一名不了解产品的客户执行任意操作把所有输入框按条件位输入特殊字符、超长字符串重点检查前端限制长度与数据库字段长度不一致的情况这个不一致是历史缺陷的高发点。边界值取刚刚小于、稍小于、等于、刚刚大于、稍大于五个点不要只取等于。错误推测拿历史缺陷清单对照同类系统出过的问题在本次系统上重验一遍。因果图适合输入条件有组合约束的场景比如登录页的验证码、身份证姓名密码联合校验条件组合多且互相约束时用因果图能把组合情况列全。5.5 用例写完就冻结现象需求变更后用例没动执行时临时改步骤改完不写回用例库。下一轮回归还是老样子。原因维护没有触发条件靠自觉。而自觉在排期紧的时候最先被牺牲。解决把五条触发条件写进流程节点——评审发现问题、新增功能或需求变更、测试过程发现设计遗漏、生产问题判定为测试泄漏。前三条好执行第四条要变成硬规则每条生产缺陷关闭前必须确认用例库里有对应覆盖没有就补。这条规则真正落地的团队不多但落地的那些下一轮同类问题的复发率会明显下降。6. 用例集反向自检三个能在半小时内跑完的验证动作用例写完不等于覆盖到位。我习惯在提交评审前做三轮反向自检不增加用例条数只查已有用例集的窟窿通常半小时内能跑完。第一轮查缺陷库。把近两个版本的生产缺陷按模块过一遍逐条问当前用例集里有没有一条用例能在测试阶段抓到它。抓得到但当时没执行是执行策略问题抓不到是用例设计问题当场补检查点。这个动作的价值在于它用的是真实故障分布比任何设计方法都贴近实际风险。虚拟项目里我做过一次统计三十条缺陷里有九条在用例集里找不到对应覆盖补完之后下一个版本的同类问题降了一半。第二轮查设计文档改动清单。把本次迭代的接口变更、表结构变更逐条列出来每条问两个问题改动功能自身的逻辑分支覆盖了没有调用它的上游受影响的功能有没有回归检查点。第二问最容易被跳过因为上游功能的用例看上去跟本次需求无关但它们挂在同一棵需求树上改动一碰就出事。第三轮查字段长度和边界值的交叉一致性。前端限制长度、接口校验长度、数据库字段长度这三个值在多数系统里并不一致而不一致的位置就是边界测试该落的地方。具体做法是把表单类用例里涉及输入项的字段拉一张表三列分别是前端限制、接口校验、数据库长度逐个比对取最小值作为有效边界、取三者的边界分别作为测试点。自检项查什么不合格信号缺陷库反查近两版生产缺陷是否都有对应用例连续两条缺陷找不到覆盖设计改动反查改动点的上游调用方是否有回归检查点改动清单里有、用例集里无边界交叉核对前端、接口、数据库三处长度限制是否一致三值不一致且无对应用例这三轮里第一轮最容易被省略因为缺陷已经修完了感觉事情结束了。但用例库的厚度就是靠这一轮一轮垫起来的。从那以后我每次提交用例评审前都会强制走一遍缺陷库反查和边界交叉核对哪怕只花二十分钟也比我事后在生产上解释为什么没测到要轻松得多。希望帮到你。本文还有配套的精品资源点击获取
简介《测试用例编写指南》是一份面向测试设计人员、技术管理团队成员及需要规范用例编写流程的从业者的docx文档针对凭惯性设计、颗粒度不一、可读性和覆盖度不足等问题提供可循的编写依据。压缩包共1个docx文件约494KB篇幅精炼便于检索和团队内共享。已有553人学习。文档从目的、适用范围和测试设计依据讲起依次梳理需求分析、业务流程分析、系统设计分析、用例编写与完善五个步骤并说明用例路径、前置条件、操作步骤、预期结果、优先级、用例类型、属性和测试方式等要素。内容还涉及测试需求与用例划分原则、编写要求、常见测试类型、等价类划分、边界值分析、状态迁移等设计方法以及用例维护和生产问题回溯思路。读者可据此统一模板与粒度补充异常、边界和回归检查点提升测试设计的规范性与投产质量。1. 一份测试用例编写指南能补上什么从“凭惯性思考”到末级检查点上一轮迭代的用例评审两个测试同学为一条用例该不该拆争了二十分钟最后发现争的不是拆法是各自心里那套用例编写注意点根本不一样一个人按页面拆一个人按检查点拆。这类分歧在小团队里很常见落到投产就是覆盖不全、回归跑不动、缺陷复盘时说不清是漏测还是没写。测试用例编写指南这类文档的价值就在这里——它不教你怎么想它把需求分析到用例完善切成固定几步把用例要素的字段口径固定下来再用一张对照表告诉你不同测试对象该拆到什么颗粒度。下面按文档骨架走一遍重点放在能直接搬进项目的那部分适合测试负责人和刚接手用例设计的新人照抄。2. 五步法拆开看需求分析到用例完善各自的输入输出文档把编写过程切成五步每一步都明确写了输入、处理、输出三段。这个写法本身就值钱——它迫使你在每一步结束时交出一个可检查的产物而不是“我感觉想清楚了”。很多团队的用例质量问题追到根上不是写得不细是中间步骤没有产物直接从需求文档跳到了用例表格跳过了业务流程和系统设计两层分析结果用例只覆盖了需求文档字面上写了的那部分。先把五步的骨架摆出来后面几节逐条展开。步骤输入处理输出需求分析业务需求说明书按流程或功能分类测试需求需求细节逐条列为检查点业务流程分析业务背景知识、被测系统/模块流程梳理主流程、备选流程、数据流向、关键判断条件、非必要条件补充需求文档未提及但需覆盖的检查点系统设计分析概要设计、详细设计、接口设计、数据库设计分析改动点及影响范围改动功能涉及的全部逻辑、影响范围的回归检查点用例编写测试需求覆盖生产上所有业务流程场景与系统逻辑分支正向之外关注边界、异常功能正确性、边界、异常、接口、信息安全等类型用例用例完善评审意见、变更、执行反馈、生产问题按触发条件更新维护修订后的用例集这张表我一般会打印出来贴在工位上写完一批用例回头看一眼哪一步的产物是空的基本就能定位到漏测出在哪一层。下面是每一步的实际做法。2.1 需求分析把业务需求拆成可数的检查点这一步的产出不是用例是检查点清单。常见做法是把需求文档里带“应当”“可以”“支持”“不允许”的句子逐句圈出来一句至少对应一个检查点候选。举个虚构的例子某跨平台系统的“消息发送”需求文档一句话里含单条发送、批量创建、定时任务三种形态那就至少拆出三个一级需求每个下面再挂检查点。分类维度只有两条按流程分按功能分。按流程适用于一条业务链路跨多个功能模块的情况比如从任务创建到审批到执行按功能适用于单个菜单或单个接口的情况。分类做完需求路径基本就定下来了形如“/项目名称/一级需求/二级需求/……/N级需求”。这一步别急着写用例描述先把需求名称和检查点列全因为后面所有用例都挂在这棵树下面树歪了后面全歪。有个容易忽略的点需求分析阶段的输出是“测试需求”不是“测试用例”两者在文档里是分开定义的。测试需求只回答“要验什么”用例才回答“怎么验”。把这两件事混在一步做写出来的东西往往描述含糊因为脑子里同时在处理“验什么”和“怎么验”两个问题。2.2 业务流程分析补需求文档没写的那部分需求文档写的是系统应该做什么不写用户实际会怎么走。业务流程分析这一步就是补这个缺口。输入是业务背景知识和被测系统/模块的业务流程处理时要把主流程、备选流程、数据流向、关键判断条件以及完成该操作的非必要条件全部整理出来。主流程和备选流程的差别在实际项目里非常具体。拿一个虚构的审批场景说需求文档只写了“审批通过/拒绝”两种结果业务流程分析会补出“支行经办-分行审核拒绝”“支行经办-分行审核通过-总行审核通过”这类组合路径以及每条路径上审批人角色不同带来的权限差异。这些组合在需求文档里通常不会逐条列但不测就是漏。数据流向决定你要准备几份数据。完成某个操作的必要条件里往往藏着前置数据的要求比如账户状态必须先处于某个值、某张关联表必须先有记录。把这些整理出来前置条件字段就有内容可写了。非必要条件指的是缺了它流程也能走通、但结果会不同的东西比如某开关打开和关闭走的是两条分支这类也必须作为检查点列出来。这一步的输出形态是“补充检查点”明确标注它不属于需求文档原文。这样做的好处是评审时能分清哪些是需求本身要求的、哪些是测试自己补的需求变更时回填也有依据。2.3 系统设计分析改动点与影响范围怎么圈系统设计分析是用例最容易漏的一步也是新人最不愿意做的一步因为要读设计文档。输入是系统设计、接口设计及数据库设计文档处理时针对系统为实现业务需求所做的主要改动点和影响范围做全面分析。我的习惯是拿两份东西对照设计文档里的改动清单和数据库变更脚本。逐个改动点问一句“谁调用了它”。改一个字段类型可能牵动三张表、两个对外接口、一个报表统计口径改一个接口的返回结构可能让上游三个调用方全部受影响。这些调用关系不会自己出现在需求文档里只能从设计文档和代码依赖里挖。这一步的输出有两类检查点一是改动功能支持的全部逻辑分支二是影响范围的回归检查点。第二类最容易被砍因为看上去跟本次需求无关但恰恰是生产事故的高发区。关联性测试和回归测试的检查点基本都从这一步产生。项目时间紧的时候可以砍执行轮次但不建议砍这一层的检查点设计砍设计等于把风险藏起来了。2.4 用例编写与完善五个必须回头的触发条件用例编写这一步的输入是测试需求处理要求是尽量覆盖生产上所有业务流程场景和系统逻辑分支正向之外加强对边界、异常的覆盖。输出覆盖功能正确性、边界、异常、接口、信息安全等类型。注意这里的措辞是“生产上的所有业务流程场景”不是“需求文档里的所有场景”。这两者的差距就是前面两步补出来的内容。很多用例集看上去条数不少但一跑生产就出问题原因往往是用例是照着需求文档逐句翻译的没有业务流程和系统设计两层输入。用例完善这一步写的是触发条件一共五条评审过程中发现用例存在问题系统新增功能或需求变更测试过程中发现设计时考虑不周、存在遗漏点系统出现生产问题经分析判定为测试泄漏。第四条最值钱也最少被真正执行。多数团队处理生产问题的流程是定位、修复、验证、关闭。用例库不动。结果同一个位置第二次出问题还是同一批人重新想一遍。我的做法是每出一条生产缺陷先在用例库里按模块搜有没有对应用例有就补操作步骤或补预期结果的检查点没有就新建一条并把缺陷编号记在备注里。这条规则坚持两个迭代用例库才会随着系统一起变厚而不是每次迭代都从零开始。3. 用例要素与字段定义一张表管住路径、步骤与预期结果要素这块文档给了两份清单测试需求五个字段测试用例十二个字段。字段本身不难难在几个字段的填写口径会直接决定用例能不能被复用、能不能被自动化脚本接、能不能在半年后还有人看得懂。这一章把字段逐个过一遍重点讲口径而不是定义。3.1 路径字段用例库的索引怎么定需求路径指的是需求所属的结构目录形式是“/项目名称/一级需求/二级需求/……/N级需求”。用例路径是在需求路径基础上再加一层需求名称即“/项目名称/一级需求/……/N级需求/需求名称/”。两条规则看着简单实际填的时候有几种常见分歧。第一种路径里要不要带版本号。我的建议是不带。版本用其他字段区分路径只管层级。路径一旦掺进版本跨版本统计覆盖率就没法做了因为同一个功能在不同版本下路径不同聚合时报表全是散的。第二种同一功能多个入口怎么处理。文档给的做法是合并编写一个需求路径只到功能层入口差异放在用例的操作步骤里体现。比如某功能既有列表页入口又有详情页入口需求层面是一个用例层面可以按入口拆成两条但路径相同。第三种层级多深合适。我一般控制在五级以内。超过五级说明这个需求本身该拆了而不是继续往路径里加层。路径过深的直接后果是筛选和统计变麻烦间接后果是没人愿意维护这棵目录树最后变成一堆平铺的需求名。3.2 名称、前置条件、步骤、预期结果的写法口径这四个字段是评审时被挑毛病最多的地方也是最能体现编写水平的地方。文档对每个字段都给了明确的正反要求整理成下表更好对照。字段应该写成什么常见反面写法测试名称简洁能直接识别测试对象和检查点如“放款失败-合同冻结”把操作步骤塞进名称如“点击放款按钮后检查合同状态为冻结并查看日志”前置条件特殊账号权限要求、数据准备、前置操作完整列出描述的是系统当前状态写成“先执行用例XXX”形成用例之间的依赖链操作步骤入口、与测试点相关的输入要素、按钮、运行的任务、操作顺序步骤里出现“检查”“确认”“验证”字样预期结果检查点完整列出含页面显示、提示信息、后台数据存储、前后端数据一致性预期结果里写“点击某按钮”这类操作动作关于预期结果还有几条细化要求值得单独说。前端操作成功或失败检查点要覆盖页面显示、提示信息、后台数据存储、前后端数据一致性四层只写“提示成功”是不够的提示文案的关键内容也要写明。涉及后台数据存储或变更的要明确具体数据表和关键字段的取值变化写“数据正确保存”等于没写因为执行的人不知道去哪张表看哪个字段。后台系统测试和涉及信息安全的前端操作测试必须包含输出日志、后台数据存储结果的检查。这一条在实操中经常被简化掉理由是查日志麻烦。但恰恰是这类检查点在出问题时提供了唯一可回溯的证据少了它缺陷复盘就只能靠猜。提示信息要明确关键检查内容比如“系统提示分类名称已存在添加失败”而不是“系统提示错误”。文案在迭代中会改写成关键内容而不是逐字照抄可以降低维护成本但关键语义不能丢。3.3 步骤与预期结果的三种映射关系文档花了较大篇幅讲操作步骤和预期结果分支的对应关系因为这是实际编写中最容易写乱的地方。三种关系如下。映射类型形态处理方式一对一一种操作对应一个预期结果分支直接编号对应即可多对一多种操作对应一个预期结果分支每种操作单独列步骤共同指向同一预期结果多对多多种操作对应多个预期结果分支通过相同编号反映对应关系或按预期结果分支拆成多条用例一对一最干净写起来也最快。多对一的典型场景是几种不同操作都能触发同一个结果比如删除一级分类目录、删除多级分类根目录、删除多级分类子目录三种操作都指向“可成功删除未挂用例的测试执行集”那就并列三步、共用一个预期结果。多对多在文档里的态度是明确的不建议使用尽量按预期结果分支拆开。实在拆不开时用编号把步骤和预期结果一一挂钩比如步骤标 1、2、3预期结果也标 1、2、3。另外两条硬规则要记住操作步骤和预期结果分支原则上不允许出现一对多一个预期结果分支如果含多个步骤可以先把步骤按序列出再把检查点和它的前置依赖步骤通过编号关联。这两条规则看起来是格式问题实际影响的是执行效率——执行人照着写不清的映射关系跑很容易漏掉某个分支。3.4 优先级与其他四个字段优先级的划分方式文档是按执行顺序分的不是按业务重要性分的这一点要在团队里说清楚否则新人会把用户最关心的功能全标成高。级别含义典型用例高优先执行系统基本功能及关键路径正常流程、页面元素正常输入中次级执行确保功能完善异常流程、页面元素异常输入低最后执行体验与辅助功能页面元素显示剩下的字段里用例类型分为流程类、功能点类、报表统计类、界面类、报文接口类、批处理、其他类用例属性分正常、异常测试方式分手动、自动化执行次数记录该用例被执行过的次数。执行次数这个字段最容易被当成摆设实际上它是回归轮次统计的依据也是判断一条用例是否还有存在价值的参考——连续多个版本执行次数为零的用例要么是覆盖了废弃功能要么是被人为跳过了两种都该处理。4. 划分原则落地颗粒度控制到“一条用例一个检查点”颗粒度是评审会上最容易吵起来的话题。粗了漏测细了维护成本高而且不同人对“粗”和“细”的直觉差异很大。文档给的做法是先按测试对象分类每一类给出明确的划分依据和划分方式再用示例锚定。这一章按这个思路把七类对象过一遍。4.1 测试需求划分七类对象的划分依据测试需求这一层的划分核心是按层级往下走一级需求、二级需求、三级需求逐层细化。不同测试对象的划分路径不一样对照表如下。测试对象分类划分依据划分方式前端功能新增/修改菜单上级目录名称、菜单名称、功能名称流程类全业务流程流程名称、步骤名称后台功能新增/修改单功能/接口接口名称、校验类型批处理批处理节点节点名称后台流程全流程/场景流程名称、步骤分解数据埋点埋点类型新增埋点检查、原有埋点检查、兼容性兼容性测试维度兼容性测试举两个示例帮助理解。前端功能类路径大概是“公共设置/系统设置/用户管理/用户注册”一级是上级目录二级是菜单三级是功能点。流程类路径是“贷后业务流程/合同登记”这种形态一级是流程名二级是步骤名。后台接口类路径是“登陆接口/入参校验”或“登陆接口/系统逻辑检查”一级是接口名二级是校验类型。划分依据统一之后需求树的结构就稳定了后面做覆盖率统计、做需求追溯都能按同一套维度聚合。4.2 需求描述的检查点写法需求描述这个字段要列出针对末级需求的所有检查点不是写一段说明文字。文档给了六条补充规则实操价值都很高。同一项目需要区分多系统或多需求测试时把系统名称或需求名称作为一级需求上面那套划分方式作为它的子需求。这条规则解决的是一棵树上挂多个系统的冲突问题。检查点数量较多时把末级需求做进一步细分而不是在一个需求描述里堆一长串检查点。堆在一起的后果是执行和统计都没法按检查点追踪。同一功能不同入口合并编写一个需求。入口差异在用例层面处理需求层面不拆。一个功能的正常流程对应一个检查点。这条是基准线不是上限。一个功能中包含多个正常场景或异常流程分别列出多个检查点。比如某操作既有成功路径又有三种失败原因那就是四个检查点不是一个。同一功能需要准备多份不同数据时原则上分别列出多个检查点如果是针对同一操作需要同时对多份数据进行处理可以单独列一个组合检查点。这个区分很细但会影响后面用例的拆分方式。4.3 测试用例划分按对象给对照用例层面的划分原则是“一个测试需求检查点对应一条用例”但不同测试对象有各自的调整方式。前端功能类的调整最灵活页面要素检查一条列表查询、分页、删除功能各一条表单新增或修改的输入项检查视表单输入项数量而定可以按输入项或输入分区拆。输入项超过十个的表单全塞一条用例里执行时会很难受因为任何一项出错都要重新走一遍。业务流程类坚持一条检查点一条用例全流程和工作流分别列。全流程是端到端的完整路径工作流是审批环节的组合两者的失败模式不一样。后台功能类给了合并空间原则上一个检查点一条用例但入参有效性检查这类可以合并成一条把多个非法输入放在同一条用例的不同步骤里。这样处理的前提是预期结果足够清晰每个非法输入对应的提示要写明白。批处理、后台流程、数据埋点都是严格的一检查点一用例。数据埋点类按页面划分每个页面对应一条用例。兼容性类的划分按维度走按移动端操作系统维度可以分成两条按机型维度机型有多少种就有多少条按浏览器维度同理。维度选哪个取决于项目实际的风险面不是都测一遍才叫全。还有一条容易忽略的说明同一个功能的自自动化用例和功能用例应当匹配如果自动化用例不能完全覆盖功能用例就把两者拆成互补的用例集。这条规则避免的是重复覆盖和覆盖空档同时存在——自动化跑的那些手工再跑一遍是浪费自动化没覆盖的手工也没写就是漏洞。4.4 合并与拆分的三条界线颗粒度控制到最后落到三个判断上。同一个需求检查点对应多种操作步骤时可以合并编写一条用例用例里详细列出所有操作步骤。判断依据是这些操作指向的预期结果是否相同。同一个预期结果含多个检查点、且这些检查点由多个不同操作产生时不建议合并尽量按预期结果分支拆开。多个预期结果中含多个检查点的组合是最难执行也最难维护的形态。一组操作对应一个预期结果、且需要重复验证的场景可以写成一条用例但要在前置条件和预期结果里写清楚每次验证的共同判定标准。5. 常见问题排查五类翻车现场与修法规范写在文档里是一回事落到每个人的手上是另一回事。下面这五类问题在我见过的用例集里出现频率最高按现象、原因、解决三段写对照着改比较快。5.1 前置条件写成相互依赖链现象用例 A 的前置条件写“先执行用例 B”用例 B 又写“依赖用例 C”单独抽一条出来跑不了回归时想删又不敢删。原因把“系统当前应处于什么状态”写成了“前一步做什么操作”。前者是状态描述后者是流程描述混在一起就形成了依赖。解决前置条件只写状态、权限和数据准备。比如“指定用户具备所选项目的测试负责人权限指定项目的测试执行集中有已创建的测试轮次和分类目录其中含未挂用例的分类目录”。状态怎么来的交给环境初始化或数据准备不写进用例。这条改完之后用例之间就能任意组合成执行集回归时可以按风险挑着跑。5.2 操作步骤里混进检查结果现象步骤里写“点击删除检查提示删除成功”预期结果里又写一遍“提示删除成功”。执行时不知道该在哪一步做判断。原因边写边验的习惯带到了文档里。写的时候手上有环境顺手就验了顺手就记在步骤里了。解决步骤只写动作和输入判断全部留在预期结果。自查方法很简单把每条步骤读一遍凡出现“检查”“确认”“验证”“查看”字样一律挪到预期结果。这个动作花不了几分钟但能显著降低执行时的歧义。反过来预期结果里出现“点击某按钮”“输入某值”这类动作描述也要挪回步骤。5.3 颗粒度两极化现象一条用例覆盖一个模块的所有输入框执行一次要半小时另一条用例只写“页面显示正常”执行时全靠执行人自己发挥。原因没有对照划分原则按个人手感写。写的人觉得细的那条太啰嗦粗的那条反正也不会出错。解决先按测试对象分类确定用哪套划分方式再按类里的规则落。前端功能按页面要素、列表查询分页删除、表单输入项三个区拆表单输入项多的时候按输入项或输入分区再拆。下限是一条用例一个检查点上限是执行一条用例不超过十分钟。超过上限就说明该拆了低于下限说明检查点没列全。5.4 设计方法用成摆设现象文档列了功能正确性、异常、边界值、等价划分、错误推测、因果图六种设计方法实际用例集里只有正向流程异常和边界几乎为零。原因方法只出现在培训里没有落到字段上。写用例时脑子里想的是功能怎么用不是数据怎么坏。解决让用例属性字段和设计方法对应起来标“异常”的用例必须能说出用的是哪种方法。异常测试的标准动作是模拟一名不了解产品的客户执行任意操作把所有输入框按条件位输入特殊字符、超长字符串重点检查前端限制长度与数据库字段长度不一致的情况这个不一致是历史缺陷的高发点。边界值取刚刚小于、稍小于、等于、刚刚大于、稍大于五个点不要只取等于。错误推测拿历史缺陷清单对照同类系统出过的问题在本次系统上重验一遍。因果图适合输入条件有组合约束的场景比如登录页的验证码、身份证姓名密码联合校验条件组合多且互相约束时用因果图能把组合情况列全。5.5 用例写完就冻结现象需求变更后用例没动执行时临时改步骤改完不写回用例库。下一轮回归还是老样子。原因维护没有触发条件靠自觉。而自觉在排期紧的时候最先被牺牲。解决把五条触发条件写进流程节点——评审发现问题、新增功能或需求变更、测试过程发现设计遗漏、生产问题判定为测试泄漏。前三条好执行第四条要变成硬规则每条生产缺陷关闭前必须确认用例库里有对应覆盖没有就补。这条规则真正落地的团队不多但落地的那些下一轮同类问题的复发率会明显下降。6. 用例集反向自检三个能在半小时内跑完的验证动作用例写完不等于覆盖到位。我习惯在提交评审前做三轮反向自检不增加用例条数只查已有用例集的窟窿通常半小时内能跑完。第一轮查缺陷库。把近两个版本的生产缺陷按模块过一遍逐条问当前用例集里有没有一条用例能在测试阶段抓到它。抓得到但当时没执行是执行策略问题抓不到是用例设计问题当场补检查点。这个动作的价值在于它用的是真实故障分布比任何设计方法都贴近实际风险。虚拟项目里我做过一次统计三十条缺陷里有九条在用例集里找不到对应覆盖补完之后下一个版本的同类问题降了一半。第二轮查设计文档改动清单。把本次迭代的接口变更、表结构变更逐条列出来每条问两个问题改动功能自身的逻辑分支覆盖了没有调用它的上游受影响的功能有没有回归检查点。第二问最容易被跳过因为上游功能的用例看上去跟本次需求无关但它们挂在同一棵需求树上改动一碰就出事。第三轮查字段长度和边界值的交叉一致性。前端限制长度、接口校验长度、数据库字段长度这三个值在多数系统里并不一致而不一致的位置就是边界测试该落的地方。具体做法是把表单类用例里涉及输入项的字段拉一张表三列分别是前端限制、接口校验、数据库长度逐个比对取最小值作为有效边界、取三者的边界分别作为测试点。自检项查什么不合格信号缺陷库反查近两版生产缺陷是否都有对应用例连续两条缺陷找不到覆盖设计改动反查改动点的上游调用方是否有回归检查点改动清单里有、用例集里无边界交叉核对前端、接口、数据库三处长度限制是否一致三值不一致且无对应用例这三轮里第一轮最容易被省略因为缺陷已经修完了感觉事情结束了。但用例库的厚度就是靠这一轮一轮垫起来的。从那以后我每次提交用例评审前都会强制走一遍缺陷库反查和边界交叉核对哪怕只花二十分钟也比我事后在生产上解释为什么没测到要轻松得多。希望帮到你。本文还有配套的精品资源点击获取
