前言软件测试是保障产品质量的关键环节而测试用例设计则是测试工作的核心。本文从测试用例的基本概念出发系统梳理六种常用用例设计方法并结合命令行、Web 接口等讲解用例落地。下篇文章按测试目标、执行方式、测试方法、测试阶段等维度完整介绍软件测试的分类体系。一、了解测试用例1.1 基本概念测试用例是为实施测试而向被测系统提供的一组集合包含测试环境、操作步骤、测试数据、预期结果等要素。设计用例的原则一每个用例必须定义预期输出或结果。要素说明示例用例编号test-01标题成功注册网易邮箱功能模块注册登陆测试前提系统运行正常邮件服务器已开启测试环境Win10 Chrome 103.0.5060.66测试数据邮箱996402440qq.com密码123456测试步骤打开注册页 → 填写信息 → 点击注册期望结果注册成功使用新账号可正常登录并进入邮箱首页为什么必须写测试用例不写用例直接测试会面临一系列问题不知道是否全面覆盖了所有功能、测试覆盖率无法衡量、新版本回归测试难以实施、大量冗余测试拉低效率。测试用例的出现正是为了解决这些问题此外还能避免测试人员被迫背锅。传统方式用表格编写用例如今大多数企业采用思维导图方式编写日常用例练习也以脑图为主。1.2 设计思路常规 逆向 发散以门锁为例缺乏经验的测试人员往往只想到最基本的两条用例上锁成功、用钥匙能打开。这种思路覆盖远远不够。正确的设计思想是常规思维 逆向思维 发散性思维。设计原则二用例不仅要覆盖有效和预料到的输入也要覆盖无效和未预料到的输入检查程序是否未做其应该做的只是成功的一半另一半是检查是否做了其不应该做的。1.3 万能公式仅靠头脑风暴设计用例面对面试官时能想出的用例寥寥无几。设计测试用例的万能公式功能测试 界面测试 性能测试 兼容性测试 易用性测试 安全测试。维度核心关注点功能测试验证程序与外部规格说明是否一致通常是黑盒操作需求不明确时查相关文档、参加项目会议、评审整理结果、多使用产品、看历史 bug界面测试界面实现与设计图一致控件操作验证有效/无效状态性能测试功能测试检查做了没有性能测试检查做得好不好兼容性测试不同硬件、操作系统、浏览器、机型下能否正确运行优先选 top 级别机型和主流浏览器易用性测试新用户能否快速上手产品是否简单易操作安全测试隐私数据明文显示、SQL 注入、越权操作等常见安全问题以邮箱注册为例结合万能公式设计的测试点思维导图如下除六大维度外弱网测试和安装卸载测试也是常用类型。弱网测试关注页面响应时间超时文案、超时重连、DNS 劫持、大流量风险等关键点通常借助 Fiddler 构造弱网环境。安装卸载测试针对需要部署的软件除功能外还需关注能否成功安装和卸载。二、设计方法2.1 基于需求的设计方法基于需求的设计是总的设计方法测试人员接到需求后从合理需求中细化出测试点再根据测试点设计用例。以邮箱注册需求为例先明确功能点再结合万能公式设计测试点。2.2 等价类穷举法在实际测试中不可行——姓名必填6~15 位字符若逐个测试 6、7、8……15 位范围扩大到 6~150 位时成本无法接受。等价类法解决了穷举问题依据需求将输入划分为若干等价类从每个等价类中选一个测试用例若该用例通过则认为所代表的等价类通过。等价类分为两类有效等价类符合规格说明的、有意义的输入数据集合用于验证功能是否实现。无效等价类不满足需求的输入集合。设计步骤①确定有效等价类和无效等价类②编写测试用例设计具体测试数据。等价类的缺点是只考虑输入域分类未考虑输入域的组合需要其他方法补充。2.3 边界值边界值分析法是对输入或输出的边界值进行测试的黑盒方法通常作为等价类划分的补充测试用例来自等价类的边界。日常语言中的边界漏洞老师说超过 60 分抄 1 遍、低于 60 分抄 3 遍小明刚好 60 分就不用写作业——边界处理不当会导致逻辑漏洞。边界值包含边界值 次边界值常见取法场景边界值取值输入框长度 1-111、11、12、0参赛项目 1-3 项0 项、1 项、3 项、4 项查询 999 行每 50 行一页0 行、1 行、50 行、51 行2.4 正交法当需求中有多个可选项时排列组合会产生 2$${}^{5$$32 个用例。正交法的目的是用尽量少的用例覆盖输入的两两组合。正交试验设计是研究多因素多水平的方法根据正交性从全部水平组合中挑选有代表性的点进行试验。最简单的正交表 L$${}_{4$$(2$${}^{3$$)4 行做 4 次试验、3 列最多 3 个因素、2 种水平1 和 2。正交表的构成因素对指标的影响条件即一列、水平因素对应的可选项、行数试验次数。正交表性质每列中不同数字出现次数相等任意两列中数字的排列方式齐全且均衡。手动设计正交表较难一般使用 allpairs 工具生成。正交法设计步骤①找到因素和水平②用 allpairs 工具生成正交表③根据正交表编写用例④补充遗漏的重要用例。以邮箱注册为例因素为姓名、电子邮箱、密码、确认密码、验证码水平为填写/不填写。2.5 判定表法当需求中不同的输入组合对应不同结果时正交法无法解决需要判定表法。判定表是一种表达逻辑判断的工具能把所有条件对应的结果清晰表达出来。以管理员身份需求为例用户输入的账号包含 admin 字符或者通过内部链接进入注册页面提交注册按钮后成为管理员身份反之无管理员身份。设计步骤①确认输入条件和输出条件②找出输入与输出之间的关系③画判定表④根据判定表编写用例。输入条件账号包含 admina、内部注册链接b、点击注册按钮c输出条件管理员1、无管理员2关系ac→1ab→2bc→1abc→1a→2b→2c→2非abc→2根据判定表可编写 7 条用例覆盖 a/b/c 各种组合下是否为管理员的场景。2.6 场景法现在的软件几乎都用事件触发控制流程事件触发时的情景形成场景同一事件不同触发顺序和处理结果形成事件流。场景法包含基本流和备选流基本流是正常流程备选流是流程中某些阶段出现的异常或分支情况。从一个流程开始通过遍历所有基本流和备选流完成整个场景。场景类型包括正常场景、备选场景、异常场景、假定推测场景。以逛街买衣服为例基本流是逛街→服装店→选衣服→买衣服备选流包括可能出现情况导致不逛街了选了但始终没有合适的价格不满意导致不买了等。每个备选流都对应一条测试用例。2.7 错误猜测法错误猜测法基于对被测软件的理解、过往经验和个人直觉推测软件可能存在的缺陷从而针对性设计用例。该方法强调对需求的理解和设计实现的细节把握与探索式测试基本思想一致在敏捷开发模式下投入产出比高。生活中的例子提到武大郎想到憨厚老实、乐于助人提到张三去卖瓜猜测他可能缺斤少两、瓜被压坏、被惹哭等。以注册为例错误猜测法可以想到特殊字符空格的处理、密码大小写校验、姓名中的特殊字符、密码是否明文发送等。缺点是难以系统化过度依赖个人能力。三、实战场景3.1 命令行程序以命令行 zip 压缩命令为例按万能公式设计用例维度测试点功能txt/图片/视频/zip 文件能否压缩多文件混合压缩空文件夹压缩错误命令界面压缩成功/报错的命令行提示是否友好性能超 1G 文件能否压缩压缩耗时是否合理兼容性Windows、Linux、Mac 多系统可用易用性zip --help 提供使用帮助安全使用 zip 不会泄漏文件内容3.2 Web 接口测试以博客系统详情页接口为例可通过 curl 命令在命令行请求接口并测试接口测试维度请求方式GET 是否返回预期数据POST 是否返回数据参数组合空参数、多参数、少参数、参数值为空/过长/特殊字符参数格式URL 拼参、form-data、raw 等接口性能千万并发请求能否返回响应响应时间是否在接受范围内3.3 Postman 工具使用curl 在操作上不够理想实际工作中常用 Postman 等接口测试工具提升效率。Postman 界面主要区域添加请求方式手动填写或从浏览器开发者工具复制请求导入。导入步骤打开开发者工具选中接口右键复制 URL → Postman 点击 Import选择 Raw text 粘贴 → 点击 Continue → 再次点击 Import接口导入成功。接口管理保存常用接口到 Collections下次直接在对应文件夹下找到接口即可无需重复填写。保存时可自定义接口名称并选择目标文件夹。