设计测试用例的方法等价类边界值场景法文章目录设计测试用例的方法等价类边界值场景法1. 基于需求的设计方法1.1 明确需求中的功能点1.2 结合万能公式设计测试用例2. 具体的设计方法2.1 等价类生活案例理解应用到注册邮箱等价类分类等价类划分的缺点2.2 边界值确定边界值例子 1闭区间 [615]例子 2开区间 (615)其他例子边界值 等价类 结合使用2.3 正交法了解即可可以不掌握工作中基本不用正交表正交表的性质如何设计正交表2.4 判定表法了解即可可以不掌握工作中基本不用判定表判定表法设计测试用例的步骤1. 确认需求中输入条件和输出条件2. 找出输入条件和输出条件之间的关系3. 画判定表4. 根据判定表编写测试用例2.5 错误猜测法2.6 场景法根据场景法设计测试用例的步骤案例练习邮箱注册接口3. 更多测试用例练习命令行程序很少会见到3.1 功能测试3.2 界面测试3.3 性能测试3.4 兼容性测试3.5 易用性测试3.6 安全性测试4. 更多测试用例练习web程序接口4.1 接口测试用例设计思路1. 不同的请求方式2. 参数组合如果接口需要拼参数的情况下3. 不同的参数格式4. 接口性能5. Postman 接口测试工具使用教程6. 总结这篇博客是从这篇博客的内容中分离出来的用来介绍测试用例的。上一篇博客测试(9) - 测试用例篇如果你没有看过上一篇博客推荐看到上一篇博客中这篇博客的链接后再点击那个链接进来看这篇博客。实际在工作中设计测试用例的步骤是基于需求的设计方法采用具体的设计方法1. 基于需求的设计方法基于需求的设计方法也是总体设计测试用例的方法在工作中我们需要参考需求文档/产品规格说明书来设计测试用例。测试人员接到需求之后要对需求进行分析和验证从合理的需求中进一步分析细化需求从细化的需求中找出测试点根据这些测试点再去设计测试用例。这流程就是接到需求 → 分析和验证 → 细化需求 → 找出测试点 → 设计测试用例以该注册邮箱账号需求为例我们来设计测试用例。这是注册邮箱账号的需求文档1.1 明确需求中的功能点从上述需求文档的描述中功能点有两个邮箱账号注册邮箱账号登录1.2 结合万能公式设计测试用例这是依据 万能公式6个测试思维方向设计的测试用例万能公式针对这 6 个方面功能测试性能测试界面测试兼容性测试易用性测试安全测试2. 具体的设计方法具体的设计方法介绍 6 个等价类边界值正交法判定表法错误猜测法场景法其中这 6 给设计方法在实际工作中也是有使用频率的用的最多的频繁使用的等价类 边界值用的频率正常的错误猜测法 场景法工作中几乎不会的正交法 判定表法其中等价类 边界值是真真切切的设计方法错误猜测法 场景法是设计测试用例的一种思维能帮助你设计更多的测试用例。正交法 判定表法是一种设计方法但工作中完全几乎完全不会用但是对以后设计测试用例会有潜移默化的影响提升测试思维能力。2.1 等价类上述注册邮箱账号的测试用例还存在用例未完全设计完成的情况以 “姓名必填6~15 位字符类型” 这一具体需求为例我们该如何设计测试用例测试时如果采用穷举法逐一验证6 位、7 位、8 位……14 位、15 位是否测试通过这种方式能否满足测试要求若此时将长度范围从 “6 ~ 15 位” 修改为 “6 ~ 150 位”可以想象仅这一个简单测试点就需要耗费大量测试时间显然不符合企业实际的测试要求。而等价类法的出现恰好解决了穷举法无法解决的问题。等价类的思想依据需求将输入特殊情况下会考虑输出划分为若干个等价类从若干等价类中选取一个测试用例。若该测试用例测试通过则认为其所代表的整个等价类均测试通过。这样就可以用较少的测试用例实现尽可能多的功能覆盖解决了无法进行穷举测试的问题。生活案例理解假如你学校的图书馆在某一个楼层这里就假设在图书馆二楼有一个大型的图书存储室提供了很多座椅让学生随时拿书出来坐在椅子上看书。其中书分成了很多类的书这里以专业为例进行分类计算机类图书机械类图书会计图书教育类图书等。如果没有按照等价类的思想你要找一本计算机类的图书一本一本的找要找很久。如果图书馆按照区域分类图书前提条件比如你要找一本计算机网络的书只要在一块区域中找到一本计算机类的图书就可以只在这部分区域中找就行明确该区域是计算机类图书所在区域而不用一本一本的所有区域都找一遍了。应用到注册邮箱以 “姓名必填6 ~ 15 位字符类型” 这一具体需求为例我们可以将 6~15 位字符类型划分出多个 等价类等价类1等价类2等价类3……那么测试人员只需要从每个等价类中选取一个测试用例。若该测试用例测试通过则认为其所代表的整个等价类均测试通过。这样就可以用较少的测试用例实现尽可能多的功能覆盖大大减少了测试需要耗费的时间。等价类分类有效等价类针对 程序规格说明书需求文档 而言由合理、有意义的输入数据构成的集合用于验证程序是否实现了 程序规格说明书需求文档中规定的功能与性能。无效等价类根据需求说明书需求文档不满足需求的输入数据所构成的集合。根据等价类设计测试用例的步骤确定有效等价类和无效等价类编写测试用例设计具体测试数据例如6~15 位字符类型我们可以设计等价类有效等价类6~15位合理的不符合姓名格式要求的有意义的输入数据无效等价类6位15位不符合姓名格式要求的不满足需求的输入数据对于 6~15位我们测试一个 10位 的案例测试用例通过就说明这个等价类中其他的测试用例也都没有问题。对于 6位我们测试一个 1位 的案例测试用例通过就说明这个等价类中其他的测试用例也都没有问题。对于 15位我们测试一个 20位 的案例测试用例通过就说明这个等价类中其他的测试用例也都没有问题。上述也符合我们设计测试用例的思想测试用例的设计不仅要覆盖有效、可预期的输入场景还必须充分考虑无效、异常及不可预期的输入情况。等价类划分的缺点等价类划分只看单个输入项把输入分成有效、无效等价类。比如账号输入框、密码输入框我们分别给账号划分等价类、给密码划分等价类。问题它不考虑多个输入之间互相搭配组合的情况。举个例子登录功能两个输入框账号、密码账号有效、无效密码有效、无效等价类只会单独测账号有效密码有效账号无效密码有效账号有效密码无效但是等价类不会主动去测「账号无效 密码无效」这种组合场景。这就是它的短板只单独看每个输入忽略输入之间组合带来的 bug。2.2 边界值边界值分析法是对输入或输出的边界值开展测试的黑盒测试方法一般作为等价类划分法的补充。它的测试用例选取等价类划分得到的输入区间的边界点。日常语言中的 “边界” 漏洞示例考完试下发成绩老师布置寒假作业超过 60 分的所有题目抄写 1 遍低于 60 分的所有题目抄写 3 遍。那么小明写作业要抄几次因为他刚好考了 60 分。边界值取值包含边界值 次边界值边界值次边界值是相对的那我们如何确定 边界值次边界值边界值找区间的左右端点然后确定是否是有效的等价类次边界值离点紧挨着端点的相邻数字根据边界值是否是有效的等价类再确定应该是左端点的左边还是左端点的右边是右端点的左边还是右端点的右边确定边界值例子 1闭区间 [615]含义取值范围包含 6 和 156~15 之间都合法。边界值区间端点6、156、15 在区间内部属于有效等价类。次边界值离点5、165 在 6 的左侧16 在 15 的右侧都超出区间范围属于无效等价类。总结闭区间端点是有效端点往外紧邻的数字是无效。例子 2开区间 (615)含义取值范围不包含 6 和 15必须大于 6、小于 15 才合法。边界值区间端点6、156、15 不在区间内属于无效等价类。次边界值离点7、147 是 6 右边第一个数14 是 15 左边第一个数落在区间内部属于有效等价类。总结开区间端点是无效端点往区间内部紧邻的数字是有效。其他例子输入框长度为 1~11 位闭区间 [1,11]取边界值0、1、11、12运动员参赛项目为 1~3 项闭区间 [1,3]取边界值0 项、1 项、3 项、4 项边界值 等价类 结合使用还是拿上面的例子6~15 位字符类型我们可以设计等价类有效等价类6~15位无效等价类6位、15位前面的例子中我们已经选取了三个案例进行测试对于6~15位我们测试一个 10位 的案例测试用例通过就说明这个等价类中其他的测试用例也都没有问题。对于6位我们测试一个 1位 的案例测试用例通过就说明这个等价类中其他的测试用例也都没有问题。对于15位我们测试一个 20位 的案例测试用例通过就说明这个等价类中其他的测试用例也都没有问题。现在**加上 边界值615次边界值516 ** 进行测试。那么这些测试用例也是可以优化的把之前选取的 11020 这三个测试用例删除就行。2.3 正交法了解即可可以不掌握工作中基本不用通过等价类和边界值方法我们已完成了部分测试用例的补充。当前仍有一个场景的用例未补充完成即 “只填写部分选项”这里究竟需要设计多少个测试用例呢通常来说为了保证系统的测试覆盖率我们首先会想到采用排列组合的方式。若有两个选项 A 和 B可设计出都填写、都不填写、填写 A、填写 B共 4 个测试用例2²。若有三个选项 A、B、C可设计出 8 个测试用例2³。……当前可选的选项有 5 个分别是姓名、电子邮箱、密码、确认密码、验证码。若按照排列组合方式设计将得到 32 个测试用例。✅ 正交法的核心目的是减少测试用例数量通过最少的用例覆盖输入条件的两两组合。正交试验设计Orthogonal experimental design是研究多因素、多水平的一种设计方法。它根据正交性从试验因素的全部水平组合中挑选出部分有代表性的点进行试验通过对这部分试验结果的分析了解全面试验的情况从而找出最优的水平组合。正交试验设计是一种基于正交表、高效率、快速、经济的试验方法。正交表通过正交表挑选出部分有代表性的点。如图最简单的正交表是 L4(23)因素对指标的影响条件通常是正交表中的⼀列。如姓名、电子邮箱、密码、确认密码、验证码水平每一个因素对应的可选项。如姓名有 2 种可选项填写不填写。选 1 为填写选 2 为不填写。正交表的性质正交表的性质每一列中不同数字出现的次数相等。任意两列中数字的排列方式齐全且均衡。根据正交表的这些性质一般人很难通过手动方式设计出正交表。对于计算机专业的同学很难画出来对于数学专业的同学也很难画出来。如何设计正交表确定因素和水平使用 allpairs 工具生成正交表a. 将因素和水平录入 Excel 表格b. 在 allpairs 目录下新建文本文件 new.txt将 Excel 中的因素和水平复制粘贴到文件中保存并关闭c. 执行 allpairs 命令生成正交表allpairs.exe new.txt zhengjiao.txt根据正交表编写测试用例补充遗漏的重要测试用例继续以邮箱注册为例采用正交法补全剩余测试用例确定因素和水平因素姓名、电子邮箱、密码、确认密码、验证码水平填写、不填写使用 allpairs 工具生成正交表a. 将因素和水平录入 Excel 表格b. 在 allpairs 目录下新建文本文件 0714.txt将 Excel 中的因素和水平复制粘贴到文件中保存并关闭c. 执行 allpairs 命令生成正交表allpairs.exe 0714.txt 0714jg.txt生成的正交表数据存入 0714jg.txt 文件根据正交表编写测试用例补充遗漏的重要测试用例注意使用 allpairs 生成的正交表可能与预期存在出入但不影响我们据此设计测试用例。这里介绍的很粗糙你可以点击这两篇博客去看看。正交测试用例自动生成工具—Allpairs下载和使用偏向安装如何使用allpairs工具生成正交表超详细版偏向使用这是别人写的博客写的很好。2.4 判定表法了解即可可以不掌握工作中基本不用通过具体的方法可以让测试用例设计得更加完整与规范。需求中会存在各种各样的业务场景现将需求修改为如下要求用户输入的账号中包含admin字符或者通过内部链接进入注册页面提交注册按钮后即为管理员身份反之则不具备管理员身份。从这个需求可以看出不同的条件组合会对应不同的输出结果。这类场景无法使用正交法解决而正交法原本适用于只需考虑输入之间组合关系、对应不同结果的场景。判定表判定表是一种表达逻辑判断的工具形如通过该图可以清晰地展示所有条件对应的结果。我们需要借助这张表清晰地编写测试用例。判定表法设计测试用例的步骤确认需求中的输入条件与输出条件梳理输入条件与输出条件之间的逻辑关系绘制判定表根据判定表编写测试用例根据如下要求设计测试用例用户输入的账号中包含admin字符或者通过内部链接进入注册页面提交注册按钮后即为管理员身份反之则不具备管理员身份。1. 确认需求中输入条件和输出条件输入条件包含 admin 字符、内部链接进入、提交注册按钮输出条件管理员角色、非管理员角色2. 找出输入条件和输出条件之间的关系我们通过字符 abc数字 12 表示各种输入条件和输出结果输入条件包含 admin 字符a、内部链接进入b、提交注册按钮c输出条件管理员角色1、非管理员角色2输入条件的组合ac ab bc abc a b c 非 abc对应的输出结果1 2 1 1 2 2 2 23. 画判定表4. 根据判定表编写测试用例1包含 admin 字符不是从内部链接进入提交注册按钮成为管理员账号2不包含 admin 字符内部链接进入提交注册按钮成为管理员账号3不包含 admin 字符不是从内部链接进入只提交注册按钮不会成为管理员账号4包含 admin 字符从内部链接进入提交注册按钮成为管理员账号5不包含 admin 字符不是从内部链接进入未提交注册按钮不会成为管理员账号6包含 admin 字符不是从内部链接进入未提交注册按钮不会成为管理员账号7不包含 admin 字符内部链接进入未提交注册按钮不会成为管理员账号8不包含 admin 字符不是从内部链接进入提交注册按钮不会成为管理员账号2.5 错误猜测法错误猜测法是基于对被测软件的设计理解、过往测试经验与个人直觉推测软件可能存在的缺陷并针对性设计测试用例的方法。该方法重点依赖对软件需求的理解、对设计与实现细节的把握以及测试人员的经验积累和直觉判断。例如我们说到使用字符拼接形成 SQL语句有经验的测试人员就会想到 SQL注入 的风险。错误猜测法与当下主流的探索式测试思想基本一致这类方法在敏捷开发模式下投入产出比高是测试工作中被广泛应用的实用技巧。这个方法的缺点是难以系统化并且过度依赖个人能力。2.6 场景法现在的软件大多采用事件触发来控制流程事件触发时的情境构成场景同一事件不同的触发顺序和处理结果则形成事件流。场景法是通过运用场景来描述系统功能点或业务流程从而提升测试效果的一种方法。使用场景法测试需求是指模拟特定场景边界发生的事件通过事件触发相应动作观察最终结果以此发现需求中存在的问题。通常先从正常用例场景开始分析再逐步扩展到其他场景。场景法一般包含基本流和备用流从一个流程起始按执行经过的路径确定过程通过遍历所有基本流和备用流完成整个场景的覆盖。场景主要分为四类正常用例场景备选用例场景异常用例场景假定推测场景很多人初次接触这些概念会觉得抽象简单理解场景法就是在一个常规流程里考虑某些环节可能出现的各种意外或分支情况 ——常规流程就是基本流从各环节中延伸出的不同情况就是备选流。场景法非常考验测试人员的发散思维。下面以逛街买衣服为例用生活化的方式讲解场景法的使用。该方法能够生动地描绘出事件触发时的业务场景便于测试设计者设计测试用例让测试用例更易理解、更易执行。其典型应用是通过业务流将各个孤立的功能点串联起来帮助测试人员建立完整的业务认知避免陷入单一功能细节而忽略整体业务流程要点的问题。根据场景法设计测试用例的步骤确定基本流分析并确定备选流结合备选流组合补充测试场景与测试用例编写完整、可执行的测试用例案例练习邮箱注册接口根据场景法设计测试用例的步骤确定基本流分析并确定备选流结合备选流组合补充测试场景与测试用例编写完整、可执行的测试用例输入正确的账号密码点击注册后系统发出确认邮件并在 24H 内确认注册成功。不输入账号密码点击注册提示重新输入只输入账号不输入密码点击注册提示重新输入……剩余部分自己补充3. 更多测试用例练习命令行程序很少会见到上面已经介绍了测试用例的设计方法并讲解了Web场景法用例设计。接下来我们来看这么一种特殊情况命令行程序。针对命令行中可使用zip/unzip命令进行文件解压缩的功能测试用例设计如下3.1 功能测试对不同文件类型与场景进行验证普通 txt 文件可正常生成 zip 压缩包图片、视频、已存在的 zip 文件可正常生成 zip 压缩包多个不同类型文件混合文件可正常生成 zip 压缩包空文件夹可正常生成 zip 压缩包错误命令的校验如重复输入 zip、未指定压缩包文件名、未指定源文件等其他命令参数的功能验证3.2 界面测试文件压缩成功时命令行提示信息是否清晰规范文件压缩报错时命令行提示信息是否友好易懂3.3 性能测试文件大小超过 1G时是否可正常完成压缩文件大小超过 1G时压缩耗时是否在合理范围内3.4 兼容性测试验证 zip 工具可在 Windows、Linux、Mac 等多系统上正常使用3.5 易用性测试验证 zip 命令提供帮助说明如执行zip --help可展示使用方法3.6 安全性测试使用 zip 命令过程中不会泄露文件内容4. 更多测试用例练习web程序接口这一部分属于是接口测试的内容我们这里仅作测试用例的编写不介绍接口测试的知识点。4.1 接口测试用例设计思路以一个博客详情页接口为例接口地址http://192.168.47.135:8080/blog_system/blog?blogId10在命令行中接口请求示例如下curl命令为我们提供了在命令行中快速请求并验证接口的能力。在此基础上我们应如何为当前接口设计出完备的测试用例呢1. 不同的请求方式以GET 方式请求接口是否可以返回预期的响应数据以POST 方式请求接口是否可以返回预期的响应数据2. 参数组合如果接口需要拼参数的情况下空参数多参数少参数参数对应的值为空 / 过长 / 特殊字符……3. 不同的参数格式URL 拼参form-data 格式raw 格式等等4. 接口性能千万个请求同时发起是否能够返回响应并发情况下响应时间是否在大众接受范围内5. Postman 接口测试工具使用教程在对接口进行测试时使用curl命令进行接口测试在操作上并不理想。实际工作中我们常常使用接口测试工具来提升测试的质量和效率常见的接口测试工具有Postman。具体教程可以看这篇博客Postman 接口测试工具使用教程6. 总结这篇博客介绍了 设计测试用例的方法基于需求的设计方法明确需求中的功能点结合万能公式的思想设计测试用例万能公式功能测试性能测试界面测试兼容性测试易用性测试安全测试具体的设计方法等价类边界值正交表法判定表法错误猜测法场景法其中用得比较多的是等价类划分边界值场景法其他场景下测试用例的编写方式命令行程序web程序接口……Postman接口测试工具使用教程回到上一篇博客测试(9) - 测试用例篇最后如果这篇博客能帮到你的请你点点赞有写错了写的不好的欢迎评论指出谢谢 测试用例篇 - 设计测试用例的方法（等价类，边界值，场景法）
设计测试用例的方法等价类边界值场景法文章目录设计测试用例的方法等价类边界值场景法1. 基于需求的设计方法1.1 明确需求中的功能点1.2 结合万能公式设计测试用例2. 具体的设计方法2.1 等价类生活案例理解应用到注册邮箱等价类分类等价类划分的缺点2.2 边界值确定边界值例子 1闭区间 [615]例子 2开区间 (615)其他例子边界值 等价类 结合使用2.3 正交法了解即可可以不掌握工作中基本不用正交表正交表的性质如何设计正交表2.4 判定表法了解即可可以不掌握工作中基本不用判定表判定表法设计测试用例的步骤1. 确认需求中输入条件和输出条件2. 找出输入条件和输出条件之间的关系3. 画判定表4. 根据判定表编写测试用例2.5 错误猜测法2.6 场景法根据场景法设计测试用例的步骤案例练习邮箱注册接口3. 更多测试用例练习命令行程序很少会见到3.1 功能测试3.2 界面测试3.3 性能测试3.4 兼容性测试3.5 易用性测试3.6 安全性测试4. 更多测试用例练习web程序接口4.1 接口测试用例设计思路1. 不同的请求方式2. 参数组合如果接口需要拼参数的情况下3. 不同的参数格式4. 接口性能5. Postman 接口测试工具使用教程6. 总结这篇博客是从这篇博客的内容中分离出来的用来介绍测试用例的。上一篇博客测试(9) - 测试用例篇如果你没有看过上一篇博客推荐看到上一篇博客中这篇博客的链接后再点击那个链接进来看这篇博客。实际在工作中设计测试用例的步骤是基于需求的设计方法采用具体的设计方法1. 基于需求的设计方法基于需求的设计方法也是总体设计测试用例的方法在工作中我们需要参考需求文档/产品规格说明书来设计测试用例。测试人员接到需求之后要对需求进行分析和验证从合理的需求中进一步分析细化需求从细化的需求中找出测试点根据这些测试点再去设计测试用例。这流程就是接到需求 → 分析和验证 → 细化需求 → 找出测试点 → 设计测试用例以该注册邮箱账号需求为例我们来设计测试用例。这是注册邮箱账号的需求文档1.1 明确需求中的功能点从上述需求文档的描述中功能点有两个邮箱账号注册邮箱账号登录1.2 结合万能公式设计测试用例这是依据 万能公式6个测试思维方向设计的测试用例万能公式针对这 6 个方面功能测试性能测试界面测试兼容性测试易用性测试安全测试2. 具体的设计方法具体的设计方法介绍 6 个等价类边界值正交法判定表法错误猜测法场景法其中这 6 给设计方法在实际工作中也是有使用频率的用的最多的频繁使用的等价类 边界值用的频率正常的错误猜测法 场景法工作中几乎不会的正交法 判定表法其中等价类 边界值是真真切切的设计方法错误猜测法 场景法是设计测试用例的一种思维能帮助你设计更多的测试用例。正交法 判定表法是一种设计方法但工作中完全几乎完全不会用但是对以后设计测试用例会有潜移默化的影响提升测试思维能力。2.1 等价类上述注册邮箱账号的测试用例还存在用例未完全设计完成的情况以 “姓名必填6~15 位字符类型” 这一具体需求为例我们该如何设计测试用例测试时如果采用穷举法逐一验证6 位、7 位、8 位……14 位、15 位是否测试通过这种方式能否满足测试要求若此时将长度范围从 “6 ~ 15 位” 修改为 “6 ~ 150 位”可以想象仅这一个简单测试点就需要耗费大量测试时间显然不符合企业实际的测试要求。而等价类法的出现恰好解决了穷举法无法解决的问题。等价类的思想依据需求将输入特殊情况下会考虑输出划分为若干个等价类从若干等价类中选取一个测试用例。若该测试用例测试通过则认为其所代表的整个等价类均测试通过。这样就可以用较少的测试用例实现尽可能多的功能覆盖解决了无法进行穷举测试的问题。生活案例理解假如你学校的图书馆在某一个楼层这里就假设在图书馆二楼有一个大型的图书存储室提供了很多座椅让学生随时拿书出来坐在椅子上看书。其中书分成了很多类的书这里以专业为例进行分类计算机类图书机械类图书会计图书教育类图书等。如果没有按照等价类的思想你要找一本计算机类的图书一本一本的找要找很久。如果图书馆按照区域分类图书前提条件比如你要找一本计算机网络的书只要在一块区域中找到一本计算机类的图书就可以只在这部分区域中找就行明确该区域是计算机类图书所在区域而不用一本一本的所有区域都找一遍了。应用到注册邮箱以 “姓名必填6 ~ 15 位字符类型” 这一具体需求为例我们可以将 6~15 位字符类型划分出多个 等价类等价类1等价类2等价类3……那么测试人员只需要从每个等价类中选取一个测试用例。若该测试用例测试通过则认为其所代表的整个等价类均测试通过。这样就可以用较少的测试用例实现尽可能多的功能覆盖大大减少了测试需要耗费的时间。等价类分类有效等价类针对 程序规格说明书需求文档 而言由合理、有意义的输入数据构成的集合用于验证程序是否实现了 程序规格说明书需求文档中规定的功能与性能。无效等价类根据需求说明书需求文档不满足需求的输入数据所构成的集合。根据等价类设计测试用例的步骤确定有效等价类和无效等价类编写测试用例设计具体测试数据例如6~15 位字符类型我们可以设计等价类有效等价类6~15位合理的不符合姓名格式要求的有意义的输入数据无效等价类6位15位不符合姓名格式要求的不满足需求的输入数据对于 6~15位我们测试一个 10位 的案例测试用例通过就说明这个等价类中其他的测试用例也都没有问题。对于 6位我们测试一个 1位 的案例测试用例通过就说明这个等价类中其他的测试用例也都没有问题。对于 15位我们测试一个 20位 的案例测试用例通过就说明这个等价类中其他的测试用例也都没有问题。上述也符合我们设计测试用例的思想测试用例的设计不仅要覆盖有效、可预期的输入场景还必须充分考虑无效、异常及不可预期的输入情况。等价类划分的缺点等价类划分只看单个输入项把输入分成有效、无效等价类。比如账号输入框、密码输入框我们分别给账号划分等价类、给密码划分等价类。问题它不考虑多个输入之间互相搭配组合的情况。举个例子登录功能两个输入框账号、密码账号有效、无效密码有效、无效等价类只会单独测账号有效密码有效账号无效密码有效账号有效密码无效但是等价类不会主动去测「账号无效 密码无效」这种组合场景。这就是它的短板只单独看每个输入忽略输入之间组合带来的 bug。2.2 边界值边界值分析法是对输入或输出的边界值开展测试的黑盒测试方法一般作为等价类划分法的补充。它的测试用例选取等价类划分得到的输入区间的边界点。日常语言中的 “边界” 漏洞示例考完试下发成绩老师布置寒假作业超过 60 分的所有题目抄写 1 遍低于 60 分的所有题目抄写 3 遍。那么小明写作业要抄几次因为他刚好考了 60 分。边界值取值包含边界值 次边界值边界值次边界值是相对的那我们如何确定 边界值次边界值边界值找区间的左右端点然后确定是否是有效的等价类次边界值离点紧挨着端点的相邻数字根据边界值是否是有效的等价类再确定应该是左端点的左边还是左端点的右边是右端点的左边还是右端点的右边确定边界值例子 1闭区间 [615]含义取值范围包含 6 和 156~15 之间都合法。边界值区间端点6、156、15 在区间内部属于有效等价类。次边界值离点5、165 在 6 的左侧16 在 15 的右侧都超出区间范围属于无效等价类。总结闭区间端点是有效端点往外紧邻的数字是无效。例子 2开区间 (615)含义取值范围不包含 6 和 15必须大于 6、小于 15 才合法。边界值区间端点6、156、15 不在区间内属于无效等价类。次边界值离点7、147 是 6 右边第一个数14 是 15 左边第一个数落在区间内部属于有效等价类。总结开区间端点是无效端点往区间内部紧邻的数字是有效。其他例子输入框长度为 1~11 位闭区间 [1,11]取边界值0、1、11、12运动员参赛项目为 1~3 项闭区间 [1,3]取边界值0 项、1 项、3 项、4 项边界值 等价类 结合使用还是拿上面的例子6~15 位字符类型我们可以设计等价类有效等价类6~15位无效等价类6位、15位前面的例子中我们已经选取了三个案例进行测试对于6~15位我们测试一个 10位 的案例测试用例通过就说明这个等价类中其他的测试用例也都没有问题。对于6位我们测试一个 1位 的案例测试用例通过就说明这个等价类中其他的测试用例也都没有问题。对于15位我们测试一个 20位 的案例测试用例通过就说明这个等价类中其他的测试用例也都没有问题。现在**加上 边界值615次边界值516 ** 进行测试。那么这些测试用例也是可以优化的把之前选取的 11020 这三个测试用例删除就行。2.3 正交法了解即可可以不掌握工作中基本不用通过等价类和边界值方法我们已完成了部分测试用例的补充。当前仍有一个场景的用例未补充完成即 “只填写部分选项”这里究竟需要设计多少个测试用例呢通常来说为了保证系统的测试覆盖率我们首先会想到采用排列组合的方式。若有两个选项 A 和 B可设计出都填写、都不填写、填写 A、填写 B共 4 个测试用例2²。若有三个选项 A、B、C可设计出 8 个测试用例2³。……当前可选的选项有 5 个分别是姓名、电子邮箱、密码、确认密码、验证码。若按照排列组合方式设计将得到 32 个测试用例。✅ 正交法的核心目的是减少测试用例数量通过最少的用例覆盖输入条件的两两组合。正交试验设计Orthogonal experimental design是研究多因素、多水平的一种设计方法。它根据正交性从试验因素的全部水平组合中挑选出部分有代表性的点进行试验通过对这部分试验结果的分析了解全面试验的情况从而找出最优的水平组合。正交试验设计是一种基于正交表、高效率、快速、经济的试验方法。正交表通过正交表挑选出部分有代表性的点。如图最简单的正交表是 L4(23)因素对指标的影响条件通常是正交表中的⼀列。如姓名、电子邮箱、密码、确认密码、验证码水平每一个因素对应的可选项。如姓名有 2 种可选项填写不填写。选 1 为填写选 2 为不填写。正交表的性质正交表的性质每一列中不同数字出现的次数相等。任意两列中数字的排列方式齐全且均衡。根据正交表的这些性质一般人很难通过手动方式设计出正交表。对于计算机专业的同学很难画出来对于数学专业的同学也很难画出来。如何设计正交表确定因素和水平使用 allpairs 工具生成正交表a. 将因素和水平录入 Excel 表格b. 在 allpairs 目录下新建文本文件 new.txt将 Excel 中的因素和水平复制粘贴到文件中保存并关闭c. 执行 allpairs 命令生成正交表allpairs.exe new.txt zhengjiao.txt根据正交表编写测试用例补充遗漏的重要测试用例继续以邮箱注册为例采用正交法补全剩余测试用例确定因素和水平因素姓名、电子邮箱、密码、确认密码、验证码水平填写、不填写使用 allpairs 工具生成正交表a. 将因素和水平录入 Excel 表格b. 在 allpairs 目录下新建文本文件 0714.txt将 Excel 中的因素和水平复制粘贴到文件中保存并关闭c. 执行 allpairs 命令生成正交表allpairs.exe 0714.txt 0714jg.txt生成的正交表数据存入 0714jg.txt 文件根据正交表编写测试用例补充遗漏的重要测试用例注意使用 allpairs 生成的正交表可能与预期存在出入但不影响我们据此设计测试用例。这里介绍的很粗糙你可以点击这两篇博客去看看。正交测试用例自动生成工具—Allpairs下载和使用偏向安装如何使用allpairs工具生成正交表超详细版偏向使用这是别人写的博客写的很好。2.4 判定表法了解即可可以不掌握工作中基本不用通过具体的方法可以让测试用例设计得更加完整与规范。需求中会存在各种各样的业务场景现将需求修改为如下要求用户输入的账号中包含admin字符或者通过内部链接进入注册页面提交注册按钮后即为管理员身份反之则不具备管理员身份。从这个需求可以看出不同的条件组合会对应不同的输出结果。这类场景无法使用正交法解决而正交法原本适用于只需考虑输入之间组合关系、对应不同结果的场景。判定表判定表是一种表达逻辑判断的工具形如通过该图可以清晰地展示所有条件对应的结果。我们需要借助这张表清晰地编写测试用例。判定表法设计测试用例的步骤确认需求中的输入条件与输出条件梳理输入条件与输出条件之间的逻辑关系绘制判定表根据判定表编写测试用例根据如下要求设计测试用例用户输入的账号中包含admin字符或者通过内部链接进入注册页面提交注册按钮后即为管理员身份反之则不具备管理员身份。1. 确认需求中输入条件和输出条件输入条件包含 admin 字符、内部链接进入、提交注册按钮输出条件管理员角色、非管理员角色2. 找出输入条件和输出条件之间的关系我们通过字符 abc数字 12 表示各种输入条件和输出结果输入条件包含 admin 字符a、内部链接进入b、提交注册按钮c输出条件管理员角色1、非管理员角色2输入条件的组合ac ab bc abc a b c 非 abc对应的输出结果1 2 1 1 2 2 2 23. 画判定表4. 根据判定表编写测试用例1包含 admin 字符不是从内部链接进入提交注册按钮成为管理员账号2不包含 admin 字符内部链接进入提交注册按钮成为管理员账号3不包含 admin 字符不是从内部链接进入只提交注册按钮不会成为管理员账号4包含 admin 字符从内部链接进入提交注册按钮成为管理员账号5不包含 admin 字符不是从内部链接进入未提交注册按钮不会成为管理员账号6包含 admin 字符不是从内部链接进入未提交注册按钮不会成为管理员账号7不包含 admin 字符内部链接进入未提交注册按钮不会成为管理员账号8不包含 admin 字符不是从内部链接进入提交注册按钮不会成为管理员账号2.5 错误猜测法错误猜测法是基于对被测软件的设计理解、过往测试经验与个人直觉推测软件可能存在的缺陷并针对性设计测试用例的方法。该方法重点依赖对软件需求的理解、对设计与实现细节的把握以及测试人员的经验积累和直觉判断。例如我们说到使用字符拼接形成 SQL语句有经验的测试人员就会想到 SQL注入 的风险。错误猜测法与当下主流的探索式测试思想基本一致这类方法在敏捷开发模式下投入产出比高是测试工作中被广泛应用的实用技巧。这个方法的缺点是难以系统化并且过度依赖个人能力。2.6 场景法现在的软件大多采用事件触发来控制流程事件触发时的情境构成场景同一事件不同的触发顺序和处理结果则形成事件流。场景法是通过运用场景来描述系统功能点或业务流程从而提升测试效果的一种方法。使用场景法测试需求是指模拟特定场景边界发生的事件通过事件触发相应动作观察最终结果以此发现需求中存在的问题。通常先从正常用例场景开始分析再逐步扩展到其他场景。场景法一般包含基本流和备用流从一个流程起始按执行经过的路径确定过程通过遍历所有基本流和备用流完成整个场景的覆盖。场景主要分为四类正常用例场景备选用例场景异常用例场景假定推测场景很多人初次接触这些概念会觉得抽象简单理解场景法就是在一个常规流程里考虑某些环节可能出现的各种意外或分支情况 ——常规流程就是基本流从各环节中延伸出的不同情况就是备选流。场景法非常考验测试人员的发散思维。下面以逛街买衣服为例用生活化的方式讲解场景法的使用。该方法能够生动地描绘出事件触发时的业务场景便于测试设计者设计测试用例让测试用例更易理解、更易执行。其典型应用是通过业务流将各个孤立的功能点串联起来帮助测试人员建立完整的业务认知避免陷入单一功能细节而忽略整体业务流程要点的问题。根据场景法设计测试用例的步骤确定基本流分析并确定备选流结合备选流组合补充测试场景与测试用例编写完整、可执行的测试用例案例练习邮箱注册接口根据场景法设计测试用例的步骤确定基本流分析并确定备选流结合备选流组合补充测试场景与测试用例编写完整、可执行的测试用例输入正确的账号密码点击注册后系统发出确认邮件并在 24H 内确认注册成功。不输入账号密码点击注册提示重新输入只输入账号不输入密码点击注册提示重新输入……剩余部分自己补充3. 更多测试用例练习命令行程序很少会见到上面已经介绍了测试用例的设计方法并讲解了Web场景法用例设计。接下来我们来看这么一种特殊情况命令行程序。针对命令行中可使用zip/unzip命令进行文件解压缩的功能测试用例设计如下3.1 功能测试对不同文件类型与场景进行验证普通 txt 文件可正常生成 zip 压缩包图片、视频、已存在的 zip 文件可正常生成 zip 压缩包多个不同类型文件混合文件可正常生成 zip 压缩包空文件夹可正常生成 zip 压缩包错误命令的校验如重复输入 zip、未指定压缩包文件名、未指定源文件等其他命令参数的功能验证3.2 界面测试文件压缩成功时命令行提示信息是否清晰规范文件压缩报错时命令行提示信息是否友好易懂3.3 性能测试文件大小超过 1G时是否可正常完成压缩文件大小超过 1G时压缩耗时是否在合理范围内3.4 兼容性测试验证 zip 工具可在 Windows、Linux、Mac 等多系统上正常使用3.5 易用性测试验证 zip 命令提供帮助说明如执行zip --help可展示使用方法3.6 安全性测试使用 zip 命令过程中不会泄露文件内容4. 更多测试用例练习web程序接口这一部分属于是接口测试的内容我们这里仅作测试用例的编写不介绍接口测试的知识点。4.1 接口测试用例设计思路以一个博客详情页接口为例接口地址http://192.168.47.135:8080/blog_system/blog?blogId10在命令行中接口请求示例如下curl命令为我们提供了在命令行中快速请求并验证接口的能力。在此基础上我们应如何为当前接口设计出完备的测试用例呢1. 不同的请求方式以GET 方式请求接口是否可以返回预期的响应数据以POST 方式请求接口是否可以返回预期的响应数据2. 参数组合如果接口需要拼参数的情况下空参数多参数少参数参数对应的值为空 / 过长 / 特殊字符……3. 不同的参数格式URL 拼参form-data 格式raw 格式等等4. 接口性能千万个请求同时发起是否能够返回响应并发情况下响应时间是否在大众接受范围内5. Postman 接口测试工具使用教程在对接口进行测试时使用curl命令进行接口测试在操作上并不理想。实际工作中我们常常使用接口测试工具来提升测试的质量和效率常见的接口测试工具有Postman。具体教程可以看这篇博客Postman 接口测试工具使用教程6. 总结这篇博客介绍了 设计测试用例的方法基于需求的设计方法明确需求中的功能点结合万能公式的思想设计测试用例万能公式功能测试性能测试界面测试兼容性测试易用性测试安全测试具体的设计方法等价类边界值正交表法判定表法错误猜测法场景法其中用得比较多的是等价类划分边界值场景法其他场景下测试用例的编写方式命令行程序web程序接口……Postman接口测试工具使用教程回到上一篇博客测试(9) - 测试用例篇最后如果这篇博客能帮到你的请你点点赞有写错了写的不好的欢迎评论指出谢谢