- 综合排序
- 最热优先
- 最新优先
- 来自专栏软件测试经验与教训
如何评审测试用例
用例评审一直做，但没有多大效果？ 2. 用例评审时按着用例一条条讲，讲到最后自己都不知道该说什么了，好像大家都挺懵逼的？ 3. 用例评审开发人员不愿意参与？ 4. 评审时，外部人员提了好多用例的问题，他们怎么做到的？ 我们今天来聊一下评审用例的话题。 用 例 评 审 标 准 区分是测试组内的评审还是项目组内的评审。内部评审和外部评审在内容方面会有不同。 测 试 组 内 评 审 1、用例描述是否清晰：比如看到用例标题就能明白这条用例测试的是什么（而不是直到看到期望结果才明白这条用例的目的）， 执行步骤和期望输出是否有歧义。 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 做好测试用例分级，并不是所有的测试用例都需要上评审会，或者说有些用例是需要自己内部消化的。 02 如何更好的开展测试用例评审呢？ 要注意测试用例的颗粒度，在评审时，不需要逐条过，评审测试思路即可。 本质上测试用例也是一个测试思维可视化的过程，除非你们的测试团队特别年轻（例如第一类的测试用例，不太适合进行大范围的评审） 03 不要用例评审当做一个负担，做好事前事中的准备，利用好这个机会，再一次方对齐需求理解的机会
50830编辑于 2023-02-01 - 来自专栏漫谈测试
聊一聊测试用例评审注意事项
去年梳理了一篇测试用例评审流程文章，文章可以点击蓝色字体查看详情。 聊聊测试用例评审流程今天主要聊一下测试用例在评审的时候需要注意哪些事项，对于从业多年的测试者来说，那是“手到擒来”，对于初入职场的人员来说，为了避免踩坑，有必要了解一下。 首先，我得回忆一下测试用例评审的基本流程和常见问题。评审前的准备工作很重要，比如用例的编写规范是否统一，测试目标是否明确，相关文档是否齐全。 测试用例评审是确保测试用例质量的重要环节，目的是发现用例设计中的遗漏、冗余或不合理之处，从而提高测试覆盖率和有效性。 通过规范的评审流程和清晰的关注点，可以有效提升测试用例的可靠性，降低测试执行阶段的遗漏风险。阅读后若有收获，不吝关注，分享等操作！
44310编辑于 2025-03-13 - 来自专栏漫谈测试
聊聊测试用例评审流于形式如何破解
参与者心不在焉，提出的意见浮于表面，会后用例质量依然没有实质性提升。追求100%用例评审覆盖率导致的结果耗时2周评审800条用例，核心场景仅占20%。 作为测试管理者，要避免用例评审流于形式，需从根本上解决 「参与被动、反馈肤浅、决策模糊、闭环缺失」 四大症结。 二、 破局四步法：构建深度评审机制STEP 1：前置狙击——建立评审准入标准（守门人机制）用例进入正式评审的硬性条件：1. [必选] 关联需求ID覆盖率 ≥100% （工具自动检查）2. AI深度辅助四、 避坑指南：测试管理者的关键决策点拒绝「全员评审」陷阱错误做法：200条用例召集15人评审4小时正确策略：警惕「虚假共识」信号 所有用例评审耗时均匀（真实评审必然存在热点聚焦） 争议问题数为零 （除非是重复功能） 修改建议全是格式调整打破「流程枷锁」创新对CRUD功能采用 「用例模板公投」：团队投票通过即免评审核心链路实施 「穿透测试」：评审后立即抽1条用例全链路执行阿里内部实践：双11大促用例采用
22600编辑于 2025-07-28 - 来自专栏爱测角的专栏
漫谈测试成长之探索——测试用例评审
在分享测试用例评审的内容之前，我们可以先思考下为什么要组织测试用例评审会议呢？一、评审目的一般来说，参加测试用例评审的人员包括对应项目的产品人员、设计人员、开发人员和测试人员。 二、评审流程当我们明确了测试用例评审的目的后，我们就可以从评审前、评审过程和评审后三个时间去思考如何更好地开展测试用例评审。评审前，我们要新建项目工作群，将需要参会的人员拉进群。 评审过程中，我们并不需要过每一条的测试用例，我们可以通过脑图的方式介绍测试用例的整体内容和思路。评审过程中，我们要重点评审测试用例中提前标记的疑问点和可能存在风险的内容。 关于测试用例评审，还有哪些是我们可以改进的地方？欢迎大家一起补充。作者简介：Chaofan，爱测角成员之一，专注探索和分享软件质量保障。 文章首发于微信公众号爱测角转载请注明文章来源公众号:爱测角并附原文链接电脑端阅读可浏览：www.iTestCorner.com
52320编辑于 2022-09-20 - 来自专栏啄木鸟软件测试
关于测试用例设计、评审及用例质量评估的思考
测试用例设计、评审是每个测试人员进行的关键测试活动之一，如何做好测试用例设计？如何进行测试用例评审？如何评估测试用例的质量？是我们必须考虑的问题。 一. 如何做好测试用例设计？ 做好测试用例设计，除了关注被测对象的功能外，也需要关注被测功能与其他功能模块之间的交互。 被测对象的逻辑组合和输入数据的组合是非常庞大的，而穷尽测试是不可能的。经典测试设计中的一些技术与方法，在保证测试覆盖率与质量的情况下，对减少测试用例的数目是非常有效的。 · 做好评审。在测试用例设计过程中，组织分析和评审测试点，得到的效率和有效性会更好。 二. 如何做好测试用例评审？ 测试用例是测试人员最重要的输出之一，也是后续开展测试执行与评估的基础。 测试用例评审是保证测试用例质量的一个重要环节。如何做好测试用例的评审，以下是一些思考。 · 选择合适的人参与测试用例的评审。比如，参加评审的人员需要有项目经理、相关开发人员、测试架构师等。
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测试用例以及压测结果
1、前端使用 Twemproxy 做代理，后端的 Redis 数据能基本上根据 key 来进行比较均衡的分布。后端一台 Redis 挂掉后，Twemproxy 能够自动摘除。恢复后，Twemproxy 能够自动识别、恢复并重新加入到 Redis 组中重新使用。
1.6K40发布于 2018-08-22 - 来自专栏测试开发技术
Cursor 生成测试用例实战：一个 Skill，10 分钟产出可评审测试用例！
创建测试用例生成Skill 接下来，我们就挑测试领域其中一个小场景：需求文档自动生成测试用例为例，简单来讲一下（更详细、全面的AI测试保姆级教程，可在「狂师. AI进化社」中进行系统性学习。 打开Cursor设置菜单->选择Rules、Skills、Subagents标签页->点击新建Skill，在弹出来的New Chat对话中，输入要求： 根据需求文档，用生成测试用例，需要覆盖正向、逆向、 准备需求文档 测试用例生成SKILL开发好之后，接下来，需要测试验证这个技能能否按预期工作，因此，可以准备一份需求文档。 执行完成后，同时输出了三种格式的用例，根据自己的需求自取： 打开xlsx格式，看一下效果（还不错，挺详细，还提供测试数据、测试步骤、预期结果等测试用例关键信息）： 4. 在日常工作中，你可以把需要生成的 Excel 测试用例模板、接口文档模板、报告规范格式等，通过 Markdown 形式整理后，放在 examples 目录下，让 AI 直接复用规范结构，大幅减少调整成本
1.5K21编辑于 2026-04-02 - 来自专栏全栈程序员必看
测试用例_测试用例编写
测试用例的评审和变更 测试用例并非一成不变。如果软件修改之后发生变化，或者需求发生变更，那么测试用例便不再满足当前版本软件的测试需求，由此需要进行修改和变更操作。 如果是测试组内部的评审，应该着重于： 1.测试用例本身的描述是否清晰； 2.是否考虑到测试用例的执行效率.往往测试用例中步骤不断重复执行，验证点却不同，而且测试设计的冗(rong)余性，都造成了效率的低下 测试用例的评审能够使用例的结构更清晰，覆盖的用户场景更全面对于测试工程师来说也是一个快速提高用例设计能力的过程。 1、需要评审的原因 测试用例是软件测试的准则，但它并不是一经编制完成就成为准则。 第一，是在用例的初步设计完成之后进行评审第二是在整个详细用例全部完成之后进行二次评审。如果项目时间比较紧张，尽可能保证对用例设计进行评审，提前发现其中的不足之处。 6、评审结束标准 在评审活动中会收集到用例的反馈信息，在此基础上进行用例更新，直到通过评审。
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执行测试用例_平台测试用例
前言 通常我们认为每个测试用例都是相互独立的，因此需要保证测试结果不依赖于测试顺序，以不同的顺序运行测试用例，可以得到相同的结果。 pytest默认运行用例的顺序是按模块和用例命名的 ASCII 编码顺序执行的，这就意味着每次运行用例的顺序都是一样的。 那么我们在写pytest用例的时候，既然每个用例都是相互独立的， 那就可以打乱用例的顺序随机执行，用到 pytest 的插件 pytest-random-order 可以实现此目的，github 地址 ") def test_2(): print("用例2") def test_3(): print("用例3") # test_random2.py def test_4(): print("用例4") def test_5(): print("用例5") def test_6(): print("用例6") 执行命令 pytest -s --
3K32编辑于 2022-09-19 - 来自专栏全栈测试
巧用Kimi生成测试用例，只需5步，亲测好用！
今天分享用国产大模型Kimi生成测试用例，只需5步！ Kimi设计测试用例的 3 大优势： 1)支持图片格式的测试用例上传，功能点的理解和掌握直观。 2)支持Excel文件的测试用例，功能点的分析和应用更加高效。 这是测试用例模板框架，以后生成测试用例，都是按照这些内容生成。你记住了吗？ 主功能流程验证部分测试用例： 不同使用场景验证： 5、验证和优化用例 如果认为某部分测试用例设计不够完善，可以让Kimi按照要求重新补充完善。 三、总结 测试用例生成过程包括提供用例模板、用例模块划分、生成测试用例、完善补充用例、验证和优化用例、迭代和维护用例这6个过程，具体生成完成之后还需要进行优化以及测试执行进行验证。
3K10编辑于 2024-11-23 - 来自专栏程序员阿常
用例评审，如何约会
今天是日更的 92/365 天 上周三公司产品小东哥对 A 项目做了需求交底，我们的测试西西子同学负责该项目，今天她完成了 A 项目的用例编写工作，下一步就是发起用例评审会了，我们来看看西西子是怎么做的吧 【下面是部分群聊信息】 西西子（测试）：A 项目用例已编写完成，已上传至微文档 @所有人 明天下午 2点 - 5点 A项目用例评审 各位有时间参加吗 小东哥（产品）：有有有~~ 卷阿常（测试）：有有有 到这里，A 项目的用例评审约会操作就完成了，给西西子点赞。 最后阿常再总结一下，用例评审如何约会： 1、将需要评审的用例文档共享给相关人员提前查看（主要是产品、研发、测试） 2、在项目沟通群和大家确认参加评审会的时间（给出具体的时间，让大家确认） 3、正式向相关人员 （产品、设计、研发、测试）发起用例评审会议邀请 看完今天的分享对你是不是有所启发呢，有任何想法都欢迎大家后台私信阿常，一起探讨交流
40120编辑于 2022-09-01 - 来自专栏全栈程序员必看
测试用例_因果图_测试用例图
步骤4：明确不同的输入组合会产生的不同的输出结果，画因果图，填判定表（在实际工作中可以只填判定表，不画因果图） 步骤5：编写测试用例 判定表中每一列是一个组合，编写一条测试用例。 【说明】 （1）画因果图只是一种辅助工具，通过分析最终得到判定表，再通过判定表，再通过判定表编写测试用例。但是有时画因果图非常麻烦，影响效率，所以在实际应用中，可以直接写判定表，不画因果图。 编写测试用例能参考什么？ ①需求 ②设计（开发）文档【有可能没有】 ③已经开发出来的被测程序 ④通过跟开发人员、产品部门的人员、客户等沟通、讨论 发布者：全栈程序员栈长，转载请注明出处：https://javaforall.cn
2K30编辑于 2022-09-21 - 来自专栏全栈程序员必看
软件测试用例包括_白盒测试用例
测试用例分层 每个测试用例都有1个或多个测试步骤（List[step]），每个测试步骤对应一个API请求或其他用例的引用。 从上图分析，我们可以看到testsuite中包含了3个测试用例，testcase1中有4个请求和一个步骤teststep12，其中步骤teststep12依赖testcase2，testcase2中的步骤 你可以将API定义为只有一个请求步骤的测试用例。 测试用例的分层思想： 测试用例（testcase）应该是完整且独立的，每条测试用例应该是都可以独立运行的（重要） 测试用例是测试步骤（teststep）的有序集合 测试用例集（testsuite）是测试用例的无序集合 ，集合中的测试用例应该都是相互独立，不存在先后依赖关系的，可以无序执行 RunRequest teststeps = [ Step( RunRequest
1.3K20编辑于 2022-09-19 测试用例
1 测试用例介绍①定义测试用例通常是指对一项特定的软件产品进行测试任务描述的描述，体现测试方案、方法、技术和策略。 简而言之，测试用例就是描述测试点执行的文档（测试输入、执行条件、预期结果等）。②作用精准执行：测试用例提供了明确的指导，使得测试人员能够在规定的步骤和条件下执行测试，从而减少因人为错误造成的偏差。 2 测试用例编写①用例编号：唯一标识每个测试用例，方便管理和追踪。通常采用数字或字母数字组合。 【示例】"TC001"可以表示第一个测试用例，而"TC_LOGIN_01"则可以表示与登录功能相关的第一个用例。②用例标题：简洁明了地描述测试用例的目的。 【示例】“登录成功”可以作为登录功能测试用例的标题。③所属模块：指出该测试用例所对应的软件模块或功能。④测试等级：根据测试的重要性和优先级进行分类，便于资源分配。⑤前置条件：执行测试前需要满足的条件。
88732编辑于 2024-09-25- 来自专栏漫谈测试
测试用例评审过程中出现两极分化如何处理？
我们在进行测试用例评审会议中有可能会出现两个极端问题即开发人员要么沉默不语，要么过度争论技术细节。测试用例评审通常是跨部门协作中最容易卡壳的环节之一，测试管理者需要从技术和管理双维度分析痛点。 测试用例评审它既是需求澄清的最后关口，又是测试覆盖的验收节点。作为测试管理者，解决评审会议中「开发沉默」和「过度争论」的两极分化问题，需从会议设计、流程控制、文化引导三方面切入。 文化引导行动设立“金话筒”奖：每月评选“最佳质量共建开发者”（奖品：优先选择技术任务）开展用例众测活动：“提交一个被采纳的改进用例，抵扣1个Bug修复任务”五、 极端场景应急预案【谷歌实践参考】在Gmail 的评审中采用「30秒沉默规则」——每讨论完一条用例强制沉默30秒，给沉默者思考发言机会。 测试用例的最终目标，将评审会议转化为高质量的信息交换场——开发获得关键业务场景验证、技术风险提前暴露；测试获得技术实现细节、异常处理机制；产品获得需求落地一致性保障。
23320编辑于 2025-07-27
腾讯云开发者
Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 
粤公网安备44030502008569号
腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号