- 综合排序
- 最热优先
- 最新优先
- 来自专栏测试开发社区
接口用例设计
背景说明 一个系统可为其他系统提供能力或者直接为UI层提供数据，在设计系统测试方案时应考虑上游调用的各种场景，不仅考虑顺利且正向思维操作的场景，还应逆向的场景。 换句话来说，使用契约式设计的方式，运行前条件必须满足，参数不正确不可运行；运行中内部状态必须不变；运行后结果必须保持一致。 在设计接口用例设计时，除实现功能外，应关注：幂等性、空校验、流程节点限制、异常校验。 ? 01 幂等性 何为幂等性？ 幂等为一数学概念，指使用相同参数重复执行，能获取相同结果。 试想没有幂等性校验会怎样，还以创建支付单为例，当上游一个单子L准备创建支付单，第一次调用创建成功支付单P1，当触发再次调用时： 如果数据表已建立唯一索引，则会插入数据失败，接口抛出异常，上游可能更是一脸懵逼 当然，首先需明白业务逻辑，从而进行用例设计。尤其对于参数复杂的接口，当某一条调用规则下 某些非空参数就需要作为必传了。 03 流程节点限制 流程节点限制，即需严格遵守流程流转。
2.1K31发布于 2020-04-26 - 来自专栏大飞的部落阁
HttpRunner-7-用例分层
何为用例分层？ 在自动化测试领域，自动化测试用例的可维护性是极其重要的因素，直接关系到自动化测试能否持续有效地在项目中开展。 概括来说，测试用例分层机制的核心是将接口定义、测试步骤、测试用例、测试场景进行分离，单独进行描述和维护，从而尽可能地减少自动化测试用例的维护成本。 几个核心概念 测试用例（testcase）应该是完整且独立的，每条测试用例应该是都可以独立运行的 测试用例是测试步骤（teststep）的 有序 集合，每一个测试步骤对应一个 API 的请求描述 测试用例集 引用测试用例 即在用例中引用用例。 测试用例集（testsuite）是测试用例的 无序 集合，依赖关系在在测试用例中完成处理。
51020编辑于 2022-06-17 - 来自专栏全栈程序员必看
软件测试的用例设计方法_测试用例设计
：从测试管理的角度，测试用例的通过率和软件缺陷的数目是软件产品质量好坏的测试标准 可管理性：从测试管理的角度，测试用例的通过率和软件缺陷的数目是软件产品质量好坏的测试标准 3、测试用例的八大要素 用例编号 用例标题 项目/模块 优先级 前置条件 测试步骤 测试数据 预期结果 项目_模块_编号 预期结果（测试点） 用例所属模块 P0~P4(P0最高) 前置条件：执行当前测试用例的前提条件，前置条件如果不满足 ，对系统业务功能影响不大的模块或功能的测试用例 p2、P3：重要程度介于P0和P4之间 其他要素： 用例的设计者，用例设计日期，对应的开发人员，测试结果（pass，fail，block），测试类型（ 功能，性能，压力等） 4、测试用例的设计原则 （1）明确性：测试人员要尽量避免测试用例存在含糊的因素，在测试过程中，测试用例的测试结果是唯一的 （2）代表性：尽量将具有相似功能的测试用例抽象合并，功能相似的用例要合并 非6~8位，为空 12345，为空 qq号 类型 自然数 / 非自然数 123456A qq号 规则 不以0开头 / 0开头 0123456 6、设计方法：边界值分析法 7、设计方法：因果图法
1.4K20编辑于 2022-11-04 - 来自专栏后台技术底层理解
7 种单例模式设计
饿汉式的问题是 instance 在被 ClassLoader加载后很长时间才能在使用，如果类中的资源是重资源，那么就必须使用懒汉式
32110发布于 2020-08-04 - 来自专栏软件测试经验与教训
用例设计工具-PICT
PICT 可以有效地按照两两测试的原理，进行测试用例设计。在使用PICT时，需要输入与测试用例相关的所有参数，以达到全面覆盖的效果。 可见成对组合覆盖是一种非常有效的测试用例设计方法。 但是实际工作过程中有成对组合量太大，PICT就很好的解决了这一难题。 01 假如现在有一个网站后台需要测试工程师进行测试用例设计。 用常规的方法将参数列出： 帐户名: 空,不存在,超长,超短,正常 密码: 空,超长,超短,不匹配,正常 验证码: 空,超长,超短,不匹配,正常 会话: 保存一个月,保存三个月,保存一年,不保存 按钮 用PICT的话就非常方便，测试用例的数量将大大降低；同时，也可保证很高的测试覆盖率。 02 下载安装pict33.msi，安装完后找到文件pict.exe所在目录。
1.5K50发布于 2018-05-15 - 来自专栏编程
深度解析用例设计方法
许多测试类书籍中都有大幅的篇章介绍用例的设计方法，如等价类划分，边界值，错误推断，因果图等。 有时我们只有依靠以前项目的用例编写经验(或习惯)，希望能在这一个项目中更加规范，但多数情况下我们规范的只是“书写的规范”，在用例设计上以前存在的问题现在依旧。 当好不容易用例基本完成，我们却发现面对随之而来的众多地区特性和新增需求，测试用例突然处于一种十分尴尬的境地 下面是用例设计后出现的较为常见的问题： 从此几乎很少被执行 执行用例发现的bug很少 根本没有时间为新的功能需求增补用例 事实上我们在测试用例编写和设计上遇到的一系列问题只是一种表面的呈现，究其原因有如下几点： 1、没有适合的规范 “适合的规范”或称“本地化的规范”。 我们希望数据能做到通用和共享，最理想的情况就是建立一个“数据库”，每个业务用例都从“数据库”中取得输入数据和预期结果，这个数据只是针对业务入口和出口的，当程序内部设计变更时，保留的数据不会因此而作废。
74150发布于 2018-01-17 - 来自专栏自动化、性能测试
Pytest系列（7） - skip、skipif跳过用例
否则pytest会跳过运行该测试用例 实际常见场景：跳过非Windows平台上的仅Windows测试，或者跳过依赖于当前不可用的外部资源（例如数据库）的测试 @pytest.mark.skip 跳过执行测试用例 ") @pytest.mark.skip(reason="不执行该用例！！ 知识点 可以加在函数上，类上，类方法上 @pytest.mark.skip 如果加在类上面，类里面的所有测试用例都不会执行 以上小案例都是针对：整个测试用例方法跳过执行，如果想在测试用例执行期间跳过不继续往下执行呢 n = 1 while True: print(f"这是我第{n}条用例") n += 1 if n == 5: pytest.skip 或 skipif ，可以用一个单独的文件去管理这些通用标记，然后适用于整个测试用例集 skip # 标记 skipmark = pytest.mark.skip(reason="不能在window上运行
1.1K10发布于 2020-06-09 - 来自专栏AllTests软件测试
用例设计方法（思维导图）
用例设计方法（思维导图） 目录 1、等价类 1.1、等价 1.2、等价类划分 1.3、等价类划分规则 1.4、进行用例设计 1.5、等价类四则运算法 2、边界值 2.1、边界值三点 2.2、边界值应用场景 2.3、边界值方法应用步骤 3、判定表 3.1、判定表定义 3.2、重要概念 3.3、判定表应用步骤 4、因果图 5、正交试验 6、状态迁移 7、流程分析 7.1、场景设计法（三个流程） 7.2、使用方法 1、等价类 1.1、等价 1.2、等价类划分 1.3、等价类划分规则 1.4、进行用例设计 1.5、等价类四则运算法 2、边界值 2.1、边界值三点 2.2、边界值应用场景 2.3、边界值方法应用步骤 3、判定表 3.1、判定表定义 3.2、重要概念 3.3、判定表应用步骤 4、因果图 5、正交试验 6、状态迁移 7、流程分析 7.1、场景设计法（三个流程） 7.2、使用方法
58820编辑于 2022-07-26 - 来自专栏吾非同
接口测试流程及用例设计
接口测试流程： 类似于功能测试流程，一个完整的接口测试流程如下： 分析接口文档和需求文档 编写接口测试计划 编写接口测试用例并评审 接口测试执行 输出接口测试报告 一般接口用例设计依据的就是开发提供的接口文档和产品提供的需求文档 接口测试的原理就是用工具或代码模拟客户端向服务器发送请求报文，服务器接收请求报文后，对相应的报文做处理并将处理的结果返回给客户端，所以测试用例的设计要不仅要对单接口参数进行校验，还要对整个业务需求的功能点进行验证 接口用例设计基本原则如下： ? 一般接口用例要包含如下部分： 用例编号、模块名称、接口名称、用例标题、请求方法、请求URL、请求参数（包括请求头、请求体）、预期结果、实际结果等。 每个公司的要求不一样，不一定所有的字段都需要，下面是一个实际的用例模板： ?
1.3K10发布于 2020-10-13 - 来自专栏测试开发干货
【deepseek用例生成平台-24】十几种黑盒用例设计方法思维
#风格特点： 严谨务实的工程师思维模式 回复必须用列表数组 注重测试覆盖率与可执行性平衡 不做需求之外的事，让分解需求就只分解需求不生成用例，让生成用例就只生成用例 #输出要求： ✧ 使用数组列表来呈现分解后的需求功能点或测试用例 ✧ 每条用例都包含且只包含[测试标题][测试步骤][输入数据][预期结果] ✧ 单条用例不超过50字（中文） #能力限制： × 分解需求时不生成测试用例 × 生成用例时不直接执行测试用例 × 生成用例时按照指定方法生成 不同的黑盒用例设计方案，需要有不同的需求来对应。我举一个例子。 而让AI模型去生成测试用例的过程中，我们也要反复强调全面，甚至多次让AI补充用例，尽量减少遗漏用例，多了不怕，反正后面有去重，就怕有漏掉的。 而上面这种设计方案，也会对减少用例漏掉起到好处，比如等价类漏掉的结果判定表中生成了。 相比较之前那些直接把需求扔给aI让其生成用例来说，生成的测试用例数量要全的多的多。但是成本肯定也是成几倍的增长。
39110编辑于 2025-04-05 - 来自专栏从零开始学自动化测试
pytest + yaml 框架 -7.用例分层机制
pip 安装插件 pip install pytest-yaml-yoyo 用例分层功能在 v1.0.5 版本上实现 用例分层 我这里只分2层：API 层 和 Test case 用例层 API 层: 描述接口request请求，可以带上validate 基本的校验 Test case 用例层: 用例层多个步骤按顺序引用API API 层示例 API 层只做接口的描述，一般放到项目根目录api目录下 ，那么可以使用变量 ${username} 需注意的是，API 层不支持单独运行，因为它只是用例的一个部分，不能当成用例去执行，用例执行需使用 test_*.yml 命名 TestCase 层 用例层通过 pytest 运行 pytest testcase 关于变量 API 层可以引用变量，引用变量的值都是从用例目录的variables 加载的变量，目前只支持config 设置用例全局变量 config ，是用例的一部分，导入过去相当于复制request 请求到用例步骤里面。
49520编辑于 2023-01-03 - 来自专栏啄木鸟软件测试
用例设计方法及其覆盖率
绿色圈表明测试用例覆盖到的范围： 区域1：是重合部分，即使期望行为，也是实现的行为 区域7：是无效用例 2 黑盒测试vs白盒测试 2.1 基于规格说明的测试 基于规格说明的测试最初叫做功能测试的原因是 如上图所示，基于规格说明用不5通方法生成的用例集1和用例集2，只能覆盖到规格说明所规定的行为，测不到部分程序的实现行为（程序实现了未规定的行为，如木马病毒） 2.2 基于代码的测试 优点： 通过路径覆盖指标，解决功能测试漏洞与冗余的问题 缺点： 不能测到规定行为未实现的区域，遗漏故障 3 黑盒测试设计方法[1] 3.1 边界值测试 边界值分析 健壮性分析 最坏情况分析 3.2 等价类测试 弱一般等价类 强一般等价类 弱健壮等价类 强健壮等价类 等价类测试的原则 可以和边界类结合使用 强类型程序设计语言无需健壮测试（强类型的无效值会抛出RuntimeException DD路径这个名称指一个语句序列，用Miller的话说，是从一条判断语句的“出口”开始，到下一个判断语句的“入口”结束。
1.3K30发布于 2019-12-11 AI生成功能设计用例
AI编写用例流程图AI编写用例架构图三、设计核心介绍本部分介绍如何使用AI辅助生成功能用例，详细讲解了从PRD文档->测试点->测试用例->Xmind用例->使用采纳，整条链路的核心设计与实现。 RAG提取架构设计核心代码逻辑模型设计测试点生成器测试点生成器为AI生成用例的核心，实现PRD到测试点的转换。 核心结构如下：结构组成设计实现方案详情模型设计测试用例生成器测试用例生成器为AI用例生成器，负责将AI测试点转换为Xmind测试用例，主要实现两个功能，第一步将AI测试点转换为markdown结构的测试用例 实现方案详情※ 测试点解析生成markdown格式用例：生成markdown格式用例解析结果※ AI markdown格式转换为Xmind结构用例转换Xmind结构生成结果模型设计知识库搭建LLM大模型有通用的推荐能力 可以一定程度上提升用户编写用例效率。
46810编辑于 2025-08-28- 来自专栏CodeGuide | 程序员编码指南
重学 Java 设计模式：实战单例模式「7种单例模式案例例模式」
掌握了的知识才是自己的 在本次编写的重学 Java 设计模式的编写中尽可能多的用各种场景案例还介绍设计的使用，包括我们已经使用过的场景；各种类型奖品发放、多套Redis缓存集群升级、装修公司报价清单和百份考卷题目与答案乱序 书不是看的是用的 在这里还是想强调一下学习方法，总有很多小伙伴对学习知识有疑惑，明明看了、看的时候也懂了，但到了实际使用的时候却用不上。 refactoringguru.cn] 单例模式可以说是整个设计中最简单的模式之一，而且这种方式即使在没有看设计模式相关资料也会常用在编码开发中。 五、7种单例模式实现 单例模式的实现方式比较多，主要在实现上是否支持懒汉模式、是否线程安全中运用各项技巧。 7.
82300发布于 2020-06-27 - 来自专栏啄木鸟软件测试
关于测试用例设计、评审及用例质量评估的思考
测试用例设计、评审是每个测试人员进行的关键测试活动之一，如何做好测试用例设计？如何进行测试用例评审？如何评估测试用例的质量？是我们必须考虑的问题。 一. 如何做好测试用例设计？ 做好测试用例设计，需要考虑以下因素： · 明确输入。进行测试用例设计时，需要依赖产品相关的多项文档材料，包括需求文档、系统概要设计、系统详细设计文档、相关的标准与规范文档，测试经验知识库等。 做好测试用例设计，除了关注被测对象的功能外，也需要关注被测功能与其他功能模块之间的交互。 · 采用合适的设计技术与方法。有了测试用例设计的输入和交互分析后，采用合适的测试用例设计技术和方法，有助于做好测试用例设计。 进行测试设计时，可以考虑以下内容，以解决测试设计中面临的问题。 小结 以上根据前人的经验及自身实践的经验，对测试用例设计、评审和用例质量评估等问题进行了总结与记录，旨在更好的指导自己开展测试工作。
2.1K10发布于 2020-03-04 - 来自专栏啄木鸟软件测试
软件测试基础---流程和用例设计方法
测试设计阶段：主要是编写测试用例，会参考需求文档（原型图），概要设计，详细设计等文档，用例编写完成之后会进行评审。 测试结果输出：出测试报告，确认是否可以上线 详细测试流程：了解用户需求-->参考需求规格说明书-->测试计划-->编写测试用例-->评审用例-->搭建环境-->冒烟测试-->执行测试用例-->bug 跟踪处理-->测试报告输出-->版本上线-->上线验证-->面向用户 二、测试用例设计方法 软件测试用例的基本要素包括测试用例编号、测试标题、重要级别、测试输入、操作步骤、预期结果 测试用例设计常用的 7种方法：等价类、边界值、场景设计法、判定表、因果图、正交法、错误猜测法。 基本流：是经过用例的最简单的路径（无任何差错，程序从开始直接执行到结束） 备选流：一个备选流可能从基本流开始，在某个特定条件下执行，然后重新加入基本流中，也可以起源于另一个备选流，或终止用例，不在加入到基本流中
4K12发布于 2020-09-23 - 来自专栏测试开发干货
【deepseek用例生成平台-26】用例对应的后台数据设计和前端实现。
上节课我们设计了一个弹层，用来设置不同用例设计方法对应的需求功能点细分等。 这不，现在就要给填上不同用例的设计方案了。 这里我们有俩种方案来设计这个表。 1. 每个用例设计方法做一个字段，共13条，以后也会增多，但增多必须修改底层数据库增加新字段，何况项目以后还有很多其他重要字段，字段太多会很乱。所以不推荐。 2. 所有用例设计方法做一个列表，放在一个大文本字段中存储。以后增删改都比较方便，也不用修改底层数据库，所以我们采用这个办法。 于是，改成如下： 大家可以关注到，默认为空列表。 直接在函数中写上最初的列表和内部13个用例方法的键值对，就可以。那我们之前新建的这些项目就都算是脏数据了，可以删除，重新创建新项目来继续之后的开发。
22800编辑于 2025-04-13 - 来自专栏啄木鸟软件测试
Robot Framework测试框架用例脚本设计方法
Robot Framework框架用例脚本设计方法 Robot Framework框架中，一般将测试层分为三层：Test Project、TestSuit、Test Case。 测试用例可以描述成各种的业务工作流，这样的工作流可以用关键字驱动或者行为驱动方式来编写。 如下图所示，采用测试用例模块化设计，OS是一级模块，Test是二级模块，在Test二模块下设置测试用例Run，Resources_valable.html作为OS模块的公有资源变量；登录也可作为独立模块 ，登录模块下有两个用测试用例；Resources目录作为全局的公有资源文件，该资源文件下有全局资源文件和全局资源变量文件，这些全局资源文件能提供给所有模块用例调用接口。 用高级别的关键字—user keyword完成测试用例，隐藏了实际的测试工作流。用于测试执行步骤相同，输入数据输出结果不同的测试用例。例如常见的登录进行异常测试，需要用到不同的数据传参。
3.8K30发布于 2020-08-11 - 来自专栏全栈程序员必看
等价类划分法用例设计「建议收藏」
（4）等价类划分法设计测试用例步骤 确立了等价类后，需要建立等价类表，列出所有划分出的等价类，用以设计测试用例。 ①为每个等价类规定一个唯一的编号。 ②设计一个新的测试用例，使其尽可能多地覆盖尚未覆盖的有效等价类。重复这一步，最后使得所有有效等价类均被测试用例所覆盖。 ③设计一个新的测试用例，使其只覆盖一个无效等价类。 有效等价类三个数相等，a=b=c 建立等价类表后，下一步就可以设计测试用例了。 设计测试用例的原则是，对于有效等价类，要可能多地覆盖尚未覆盖的有效等价类; 对于无效等价类，一次只能覆盖一个。 有效等价类测试用例见表 无效等价类测试用例见表 其实这里是为了输出一般三角形和等腰三角形，设计了3条测试用例，如果严格按照标准，只需要Test3这条测试用例就可以了，因为Test3这条已经覆盖了所有的有效等价类 测试用例的设计可以把有效等价类和无效等价类分开设计; 也可以合并到一张表中设计，实际工作中，可以根据规模和需要进行选择。 版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。
3.9K71编辑于 2022-11-02 - 来自专栏测试人生
测试人员必须掌握的【用例设计思路】
7、方便回归测试，复查BUG是否还会出现 回归测试时可以根据一轮测试的结果，重点复测出问题的用例以及功能，从而避免无序、无重点的回归测试。 用例作为测试人员的核心输出，也是测试人员对产品知识的。 三、如何进行测试用例设计 测试用例设计分析是一个发散的过程，我们要考虑各种各样的场景、数据。 测试用例编写是一个收敛的过程，我们要把发散的思维转化为一条一条可执行的用例。 为了避免用例冗余、多、乱、无效、重复等问题，通常遵循以下原则进行用例设计。 面对一个需求或一个全新的功能模块，在进行用例设计时，为了避免测试对象丢失，用例设计混乱无序，我们遵从“从左到右，由上而下”的原则。 依次对看到的测试对象进行用例设计，测试点发散，最终输出完整的测试用例。 按照上述原则编写的用例，覆盖所有可测对象，基本不会出现测试对象缺失，遗漏等现象。
72020编辑于 2022-12-05
腾讯云开发者
Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 
粤公网安备44030502008569号
腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号