- 综合排序
- 最热优先
- 最新优先
- 来自专栏软件测试经验与教训
如何评审测试用例
用例评审一直做，但没有多大效果？ 2. 用例评审时按着用例一条条讲，讲到最后自己都不知道该说什么了，好像大家都挺懵逼的？ 3. 用例评审开发人员不愿意参与？ 4. 测 试 组 内 评 审 1、用例描述是否清晰：比如看到用例标题就能明白这条用例测试的是什么（而不是直到看到期望结果才明白这条用例的目的）， 执行步骤和期望输出是否有歧义。 2、操作步骤是否有可执行性： 其他人读完你的操作步骤，是否明白如何去操作； 一条用例多个测试点，这可能导致其他人执行你的用例时产生遗漏； 测试点是否有连贯性，是否贴近测试执行时的步骤。 3、是否考虑到测试用例的编写效率：即复用性要强。例如，可将重复度高的步骤或过程抽取出来定义为一些可复用标准步骤。否则写用例和执行时阅读用例都会花费很多时间。 项 目 组 内 评 审 外部评审涉及协调外部资源，需要注意： 1、确定参会人：一般情况下我们会跟产品、开发一起评审，但并非所有情况下都是如此； 2、提前约时间：在外部的人看来，用例评审并不是本职工作
1.4K10发布于 2018-07-24 - 来自专栏优测Utest
优测优分享 | 这样做测试用例评审更高效
最近的用例评审让我感受颇深，以下是我对于测试用例评审的一些感受，发出来供大家讨论学习。 听听大家对测试用例评审的吐槽？ “测试用例设计是测试的事情，为什么评审要我们参加？” 开发可以从实现层面评审用例，补充测试用例中，由于测试人员不了解实现过程导致的测试用例缺失的情况。 项目经理： 通过用例评审不但可以评审测试用例是否足够覆盖所有需求逻辑，还可以通过评审的的手段来评估测试的工作量。如果100个用例可以用2个人1天进行，那么可以根据测试用例的数量可以安排测试的时间。 2、评审的流程 测试人员确定评审日期和参与评审人员 评审前2天，测试用例发给所有评审人员 评审人员记录测试用例问题 评审会议，测试用例编写人员讲解用例，参与人员提出评审 会议结束，修改用例，并邮件输出 3、评审的内容 1、描述是否清晰，是否存在二义性 2、内容是否完整,是否清楚包含输入条件和预期输出结果并无争议点 3、是否覆盖了所有场景、逻辑分支、限制条件等 4、是否哪些需求不可测：无法准备环境、可测试性达不到等等原因
1.9K00发布于 2020-01-07 - 来自专栏CKL的思考空间
测试用例评审如何开展
测试用例评审是测试活动中的一个重要环节，做好测试用例评审，可以有效的发现用例中的不足，并更好的补充，以免测试场景遗漏或者出现业务逻辑理解不一致。那么，如何做好测试用例评审呢？ 01 做好测试用例分级，并不是所有的测试用例都需要上评审会，或者说有些用例是需要自己内部消化的。 上游数据修改是否会影响到本系统等）2是自己系统异常对上下游系统的影响。 02 如何更好的开展测试用例评审呢？ 要注意测试用例的颗粒度，在评审时，不需要逐条过，评审测试思路即可。
50830编辑于 2023-02-01 - 来自专栏漫谈测试
聊一聊测试用例评审注意事项
去年梳理了一篇测试用例评审流程文章，文章可以点击蓝色字体查看详情。 聊聊测试用例评审流程今天主要聊一下测试用例在评审的时候需要注意哪些事项，对于从业多年的测试者来说，那是“手到擒来”，对于初入职场的人员来说，为了避免踩坑，有必要了解一下。 首先，我得回忆一下测试用例评审的基本流程和常见问题。评审前的准备工作很重要，比如用例的编写规范是否统一，测试目标是否明确，相关文档是否齐全。 用例有效性可执行性：步骤是否清晰、可操作，是否依赖未实现的工具或环境。预期结果：是否明确且可验证，避免模糊描述（如“系统正常响应”）。优先级：是否根据业务风险划分用例优先级（如P0/P1/P2）。 测试用例评审是确保测试用例质量的重要环节，目的是发现用例设计中的遗漏、冗余或不合理之处，从而提高测试覆盖率和有效性。
44310编辑于 2025-03-13 - 来自专栏漫谈测试
聊聊测试用例评审流于形式如何破解
参与者心不在焉，提出的意见浮于表面，会后用例质量依然没有实质性提升。追求100%用例评审覆盖率导致的结果耗时2周评审800条用例，核心场景仅占20%。 二、 破局四步法：构建深度评审机制STEP 1：前置狙击——建立评审准入标准（守门人机制）用例进入正式评审的硬性条件：1. [必选] 关联需求ID覆盖率 ≥100% （工具自动检查）2. [可选] AI辅助检查通过（冗余步骤<10%）执行要点：测试经理在会议前1天核查，未达标会议自动取消（发送预警邮件抄送项目总监）STEP 2：过程再造——采用「对抗式评审」模式规则设计：开发角色：必须至少提出 实时透明化工具链大屏投射：会议现场实时展示，数据落后小组标红警示2. AI深度辅助四、 避坑指南：测试管理者的关键决策点拒绝「全员评审」陷阱错误做法：200条用例召集15人评审4小时正确策略：警惕「虚假共识」信号 所有用例评审耗时均匀（真实评审必然存在热点聚焦） 争议问题数为零
22600编辑于 2025-07-28 - 来自专栏爱测角的专栏
漫谈测试成长之探索——测试用例评审
在分享测试用例评审的内容之前，我们可以先思考下为什么要组织测试用例评审会议呢？一、评审目的一般来说，参加测试用例评审的人员包括对应项目的产品人员、设计人员、开发人员和测试人员。 总结来说，如图1-2所示，测试用例评审的目的可以概括为三点：明确不确定因素，提高测试用例覆盖面和促进各方理解一致。 评审过程中，我们并不需要过每一条的测试用例，我们可以通过脑图的方式介绍测试用例的整体内容和思路。评审过程中，我们要重点评审测试用例中提前标记的疑问点和可能存在风险的内容。 关于测试用例评审，还有哪些是我们可以改进的地方？欢迎大家一起补充。作者简介：Chaofan，爱测角成员之一，专注探索和分享软件质量保障。 文章首发于微信公众号爱测角转载请注明文章来源公众号:爱测角并附原文链接电脑端阅读可浏览：www.iTestCorner.com
52320编辑于 2022-09-20 - 来自专栏啄木鸟软件测试
关于测试用例设计、评审及用例质量评估的思考
测试用例设计、评审是每个测试人员进行的关键测试活动之一，如何做好测试用例设计？如何进行测试用例评审？如何评估测试用例的质量？是我们必须考虑的问题。 一. 如何做好测试用例设计？ 做好测试用例设计，除了关注被测对象的功能外，也需要关注被测功能与其他功能模块之间的交互。 以下内容部分引用自《赢在测试2》。 1. 在测试中引入“组合测试”技术。被测对象的逻辑组合和输入数据的组合是非常庞大的，而穷尽测试是不可能的。 经典测试设计中的一些技术与方法，在保证测试覆盖率与质量的情况下，对减少测试用例的数目是非常有效的。同时可以借助业界成熟的工具，比如 微软的 PICT 工具。 2. 如何评估测试用例的质量？ 测试用例质量的评估，可以从以下方面进行考虑。（以下内容部分引用自《赢在测试2》）。
2.1K10发布于 2020-03-04 - 来自专栏AI编程
Cursor 生成测试用例实战：一个 Skill，10 分钟产出可评审测试用例
1.创建测试用例生成Skill接下来，我们就挑测试领域其中一个小场景：需求文档自动生成测试用例为例，简单来讲一下（更详细、全面的AI测试保姆级教程，可在「狂师.AI进化社」中进行系统性学习。 打开Cursor设置菜单->选择Rules、Skills、Subagents标签页->点击新建Skill，在弹出来的NewChat对话中，输入要求：展开代码语言：TXTAI代码解释根据需求文档，用生成测试用例 2.准备需求文档测试用例生成SKILL开发好之后，接下来，需要测试验证这个技能能否按预期工作，因此，可以准备一份需求文档。 执行完成后，同时输出了三种格式的用例，根据自己的需求自取：打开xlsx格式，看一下效果（还不错，挺详细，还提供测试数据、测试步骤、预期结果等测试用例关键信息）：4.关于Skill.md实战经验分享description 在日常工作中，你可以把需要生成的Excel测试用例模板、接口文档模板、报告规范格式等，通过Markdown形式整理后，放在examples目录下，让AI直接复用规范结构，大幅减少调整成本。
1.6K10编辑于 2026-03-27 - 来自专栏微服务生态
Twemproxy测试用例以及压测结果
2、Redis 挂掉后，后端数据是否丢失依据 Redis 本身的策略配置，与 Twemproxy 基本无关。 5、如原来已经有 2 个节点 Redis，后续有增加 2 个 Redis，则数据分布计算与原来的 Redis 分布无关，现有数据如果需要分布均匀的话，需要人工单独处理。 从上面数据可以看出，单台最多也只能达到单个 Redis 的性能；2个节点运行性能增加大概110%左右。4个 server 运行，性能大概增加了123%，6个 server 接入运行160%。 2.前端使用1个 Twemproxy server，后端 Redis 数量分别为2，3，4，5，6来进行压力测试，看测试结果,测试数据如下： ?
1.6K40发布于 2018-08-22 - 来自专栏测试开发技术
Cursor 生成测试用例实战：一个 Skill，10 分钟产出可评审测试用例！
创建测试用例生成Skill 接下来，我们就挑测试领域其中一个小场景：需求文档自动生成测试用例为例，简单来讲一下（更详细、全面的AI测试保姆级教程，可在「狂师. AI进化社」中进行系统性学习。 打开Cursor设置菜单->选择Rules、Skills、Subagents标签页->点击新建Skill，在弹出来的New Chat对话中，输入要求： 根据需求文档，用生成测试用例，需要覆盖正向、逆向、 2. 准备需求文档 测试用例生成SKILL开发好之后，接下来，需要测试验证这个技能能否按预期工作，因此，可以准备一份需求文档。 执行完成后，同时输出了三种格式的用例，根据自己的需求自取： 打开xlsx格式，看一下效果（还不错，挺详细，还提供测试数据、测试步骤、预期结果等测试用例关键信息）： 4. 在日常工作中，你可以把需要生成的 Excel 测试用例模板、接口文档模板、报告规范格式等，通过 Markdown 形式整理后，放在 examples 目录下，让 AI 直接复用规范结构，大幅减少调整成本
1.5K21编辑于 2026-04-02 - 来自专栏进击的程序猿
raft 系列解读(2) 之 测试用例raft 系列解读(2) 之 测试用例
raft 系列解读(2) 之 测试用例 基于mit的6.824课程，github代码地址：https://github.com/zhuanxuhit/distributed-system case1：TestInitialElection {2 20 2}] nextIndex is:[2 2 2 3 3] matchIndex is:[1 1 1 2 0] 2016/10/13 10:44:22 恢复3个server 2016/10 10:44:26 server:4,currentTerm:5,role:leader commitIndex:2,lastApplied:2 log is:[{0 <nil> 0} {2 10 1} {2 20 2}] nextIndex is:[3 3 3 3 3] matchIndex is:[2 2 2 2 0] 看重新选举后，leader4：matchIndex is:[2 2 2 2 0 2 处的日志。
1.5K20发布于 2018-08-23 - 来自专栏全栈程序员必看
测试用例_测试用例编写
2）测试用例是执行的最小实体。 测试用例的特征： 1、有效性：测试用例的能够被使用，且被不同人员使用测试结果一致 2、可重复性：良好的测试用例具有重复使用的功能。 测试用例通常包括以下几个组成元素： 用例编号、测试模块、用例标题、用例级别、测试环境、测试输入、执行操作、预期结果,实际结果…. 1.6测试用例示例: 2. 编写测试用例的基本方法 2.1. 如果是测试组内部的评审，应该着重于： 1.测试用例本身的描述是否清晰； 2.是否考虑到测试用例的执行效率.往往测试用例中步骤不断重复执行，验证点却不同，而且测试设计的冗(rong)余性，都造成了效率的低下 由于用例开发人员的设计经验和对需求理解的深度各不相同，所以用例的质量难免会有不同程度的差异。 2、进行评审的时机 一般会有两个时间点。
6.5K41编辑于 2022-09-20 - 来自专栏漫谈测试
聊聊测试用例评审会议失控测试负责人处理策略
作为测试管理者，可能正面临这样的困境：每次评审会议都严重超时，团队抱怨连连，但关键用例又不得不评。 管理者应该对测试用例评审会议时间失控，采用 「预防-干预-兜底」三维控时策略，结合硬性规则与柔性技巧。一、 会前预防：构建时间防护网1. 精密计算时间容量执行原则：「90分钟铁律」：超时自动熔断 → 剩余用例转入异步评审2. 动态用例分级机制工具支持：JIRA插件自动标色Confluence看板按色块聚合3. 视觉化时间沙漏会议时间分配 “P0用例深度评审” ： 45 “P1用例快速过审” ： 30 “争议决策” ： 10 “缓冲时间” ： 5物理道具：倒计时沙漏/大屏进度条（剩余时间变红自动响铃）2. 时间敏感度训练用例评审模拟战：规则： - 每组评审10条用例 - 总时长严格限定12分钟 - 超时扣100%分数 奖励：用时最短且缺陷发现率＞80%团队获胜2. 时间银行机制3.
22620编辑于 2025-07-30 - 来自专栏全栈程序员必看
Mock测试用例_测试用例库
近期在重构一些旧项目，看到之前同事编写的测试用例是使用注入SpringJUnit4ClassRunner 直接注册实现层然后测试需要操作的方法是否可运行。虽然这样说是可以达到测试的想法。 因此引入mock来进行改造该测试用例，以业务控制层为切入点，断言预判是否符合结果。这样就达到测试的效果了。
2.3K40编辑于 2022-09-19 - 来自专栏全栈程序员必看
python执行测试用例_平台测试用例
前言 通常我们认为每个测试用例都是相互独立的，因此需要保证测试结果不依赖于测试顺序，以不同的顺序运行测试用例，可以得到相同的结果。 ") def test_2(): print("用例2") def test_3(): print("用例3") # test_random2.py def test_4(): ") def test_2(): print("用例2") def test_3(): print("用例3") 类中禁用随机 import pytest class TestRandom ") def test_2(self): print("用例2") def test_3(self): print("用例3") 这样在执行的时候，TestRandom 里面的用例顺序就是test_1，test_2，test_3不会被打乱 重现测试结果：–random-order-seed 随机种子 如果由于重新排序测试而发现测试失败，则可能希望能够以相同的失败顺序重新运行测试
3K32编辑于 2022-09-19 - 来自专栏全栈测试
巧用Kimi生成测试用例，只需5步，亲测好用！
Kimi设计测试用例的 3 大优势： 1)支持图片格式的测试用例上传，功能点的理解和掌握直观。 2)支持Excel文件的测试用例，功能点的分析和应用更加高效。 1、提供用例模板 2、用例模块划分 3、生成测试用例 4、完善补充用例 5、验证和优化用例 6、迭代和维护用例 下面一一介绍详细操作步骤，供参考。 在对话框输入用例列表字段内容，如下： # 测试用例包含字段 1.模块名称 2.用例编号 3.功能项 4.标题 5.前置条件 6.步骤 7.期望结果 8.优先级 9.类型 10.编写人 11.执行人 12 这是测试用例模板框架，以后生成测试用例，都是按照这些内容生成。你记住了吗？ 2、用例模块划分 告知Kimi需要测试什么功能，有哪些模块，参考指令如下： 3、生成测试用例 投喂指令后，Kimi生成的指令如下： 发现Kimi写得不完善，每个模块只写了一条用例。
3K10编辑于 2024-11-23 - 来自专栏程序员阿常
用例评审，如何约会
今天是日更的 92/365 天 上周三公司产品小东哥对 A 项目做了需求交底，我们的测试西西子同学负责该项目，今天她完成了 A 项目的用例编写工作，下一步就是发起用例评审会了，我们来看看西西子是怎么做的吧 第一步，西西子在 A 项目企业微信群 @所有人，告知大家用例编写已完成，询问大家第二天下午 2点～ 5点是否有空参加。 【下面是部分群聊信息】 西西子（测试）：A 项目用例已编写完成，已上传至微文档 @所有人 明天下午 2点 - 5点 A项目用例评审 各位有时间参加吗 小东哥（产品）：有有有~~ 卷阿常（测试）：有有有 到这里，A 项目的用例评审约会操作就完成了，给西西子点赞。 最后阿常再总结一下，用例评审如何约会： 1、将需要评审的用例文档共享给相关人员提前查看（主要是产品、研发、测试） 2、在项目沟通群和大家确认参加评审会的时间（给出具体的时间，让大家确认） 3、正式向相关人员
40120编辑于 2022-09-01 - 来自专栏全栈程序员必看
测试用例_因果图_测试用例图
投币50元 投币100元 充值50元 充值100元 步骤2：找出所有的输出结果（果）。 步骤4：明确不同的输入组合会产生的不同的输出结果，画因果图，填判定表（在实际工作中可以只填判定表，不画因果图） 步骤5：编写测试用例 判定表中每一列是一个组合，编写一条测试用例。 【说明】 （1）画因果图只是一种辅助工具，通过分析最终得到判定表，再通过判定表，再通过判定表编写测试用例。但是有时画因果图非常麻烦，影响效率，所以在实际应用中，可以直接写判定表，不画因果图。 （2）判定表的缺点：限制关系在判定表中不好体现 解决办法：可以在判定表中附加备注信息，将限制关系填写在备注中。 编写测试用例能参考什么？ ①需求 ②设计（开发）文档【有可能没有】 ③已经开发出来的被测程序 ④通过跟开发人员、产品部门的人员、客户等沟通、讨论 发布者：全栈程序员栈长，转载请注明出处：https://javaforall.cn
2K30编辑于 2022-09-21 - 来自专栏全栈程序员必看
软件测试用例包括_白盒测试用例
测试用例分层 每个测试用例都有1个或多个测试步骤（List[step]），每个测试步骤对应一个API请求或其他用例的引用。 从上图分析，我们可以看到testsuite中包含了3个测试用例，testcase1中有4个请求和一个步骤teststep12，其中步骤teststep12依赖testcase2，testcase2中的步骤 举例说明：模仿上面的用例，我们也写3个用例 testcase1：以最便宜的价格购买一瓶可口可乐（testcase1中的其中一个步骤需要调用testcase2） testcase2：查询价格最低的250ml 你可以将API定义为只有一个请求步骤的测试用例。 测试用例的分层思想： 测试用例（testcase）应该是完整且独立的，每条测试用例应该是都可以独立运行的（重要） 测试用例是测试步骤（teststep）的有序集合 测试用例集（testsuite）是测试用例的无序集合
1.3K20编辑于 2022-09-19 测试用例
1 测试用例介绍①定义测试用例通常是指对一项特定的软件产品进行测试任务描述的描述，体现测试方案、方法、技术和策略。 简而言之，测试用例就是描述测试点执行的文档（测试输入、执行条件、预期结果等）。②作用精准执行：测试用例提供了明确的指导，使得测试人员能够在规定的步骤和条件下执行测试，从而减少因人为错误造成的偏差。 2 测试用例编写①用例编号：唯一标识每个测试用例，方便管理和追踪。通常采用数字或字母数字组合。 【示例】"TC001"可以表示第一个测试用例，而"TC_LOGIN_01"则可以表示与登录功能相关的第一个用例。②用例标题：简洁明了地描述测试用例的目的。 【示例】“登录成功”可以作为登录功能测试用例的标题。③所属模块：指出该测试用例所对应的软件模块或功能。④测试等级：根据测试的重要性和优先级进行分类，便于资源分配。⑤前置条件：执行测试前需要满足的条件。
88732编辑于 2024-09-25
腾讯云开发者
Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 
粤公网安备44030502008569号
腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号