- 综合排序
- 最热优先
- 最新优先
- 来自专栏软件测试经验与教训
如何评审测试用例
用例评审一直做，但没有多大效果？ 2. 用例评审时按着用例一条条讲，讲到最后自己都不知道该说什么了，好像大家都挺懵逼的？ 3. 用例评审开发人员不愿意参与？ 4. 评审时，外部人员提了好多用例的问题，他们怎么做到的？ 我们今天来聊一下评审用例的话题。 用 例 评 审 标 准 区分是测试组内的评审还是项目组内的评审。内部评审和外部评审在内容方面会有不同。 测 试 组 内 评 审 1、用例描述是否清晰：比如看到用例标题就能明白这条用例测试的是什么（而不是直到看到期望结果才明白这条用例的目的）， 执行步骤和期望输出是否有歧义。 3、是否考虑到测试用例的编写效率：即复用性要强。例如，可将重复度高的步骤或过程抽取出来定义为一些可复用标准步骤。否则写用例和执行时阅读用例都会花费很多时间。 6、异常测试点：可以从测试思维框架（群里有）和以前的bug中找找看。 7、其他，比如是否优先级安排是否合理；二次评审时是否修改/删除了之前说过的问题。
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测试用例以及压测结果
6、如果 Twemproxy 的后端节点数量发生变化，Twemproxy 相同算法的前提下，原来的数据必须重新处理分布，否则会存在找不到key值的情况。 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对话中，输入要求： 根据需求文档，用生成测试用例，需要覆盖正向、逆向、 准备需求文档 测试用例生成SKILL开发好之后，接下来，需要测试验证这个技能能否按预期工作，因此，可以准备一份需求文档。 执行完成后，同时输出了三种格式的用例，根据自己的需求自取： 打开xlsx格式，看一下效果（还不错，挺详细，还提供测试数据、测试步骤、预期结果等测试用例关键信息）： 4. 在日常工作中，你可以把需要生成的 Excel 测试用例模板、接口文档模板、报告规范格式等，通过 Markdown 形式整理后，放在 examples 目录下，让 AI 直接复用规范结构，大幅减少调整成本
1.5K21编辑于 2026-04-02 - 来自专栏全栈程序员必看
测试用例_测试用例编写
PIN 有误 备选流5 – 帐户不存在/帐户类型有误 备选流6 – 帐面金额不足 对于这7个场景中的每一个场景都需要确定测试用例。 测试用例的评审和变更 测试用例并非一成不变。如果软件修改之后发生变化，或者需求发生变更，那么测试用例便不再满足当前版本软件的测试需求，由此需要进行修改和变更操作。 测试用例的评审能够使用例的结构更清晰，覆盖的用户场景更全面对于测试工程师来说也是一个快速提高用例设计能力的过程。 1、需要评审的原因 测试用例是软件测试的准则，但它并不是一经编制完成就成为准则。 4)用例是否具有很好可执行性。例如用例的前提条件、执行步骤、输入数据和期待结果是否清晰、正确期待结果是否有明显的验证方法。 5)是否已经删除了冗余的用例。 6)是否包含充分的反面测试用例。 6、评审结束标准 在评审活动中会收集到用例的反馈信息，在此基础上进行用例更新，直到通过评审。
6.5K41编辑于 2022-09-20 - 来自专栏漫谈测试
聊聊测试用例评审会议失控测试负责人处理策略
作为测试管理者，可能正面临这样的困境：每次评审会议都严重超时，团队抱怨连连，但关键用例又不得不评。 管理者应该对测试用例评审会议时间失控，采用 「预防-干预-兜底」三维控时策略，结合硬性规则与柔性技巧。一、 会前预防：构建时间防护网1. 精密计算时间容量执行原则：「90分钟铁律」：超时自动熔断 → 剩余用例转入异步评审2. 动态用例分级机制工具支持：JIRA插件自动标色Confluence看板按色块聚合3. 实时数据威慑大屏显示⏰ 已用时间：82分钟 | 剩余：8分钟 超时风险：HIGH 完成进度：23/30条（76%） 当前阻塞：#45用例争论（已持续6分钟）三、 熔断兜底：失控场景应急预案1 时间敏感度训练用例评审模拟战：规则： - 每组评审10条用例 - 总时长严格限定12分钟 - 超时扣100%分数 奖励：用时最短且缺陷发现率＞80%团队获胜2. 时间银行机制3.
22720编辑于 2025-07-30 - 来自专栏全栈程序员必看
6种常见的测试用例设计方法及应用_测试用例设计的方法
我们要熟知的测试流程： 总结一下：在测试流程中，有6个部分，其中3个部分涉及到了用例，可见写好用例的重要性。 6种常见的测试用例设计方法 1. 错误推测法 基于经验和直觉推测程序中所有可能存在的各种错误, 从而有针对性的设计测试用例的方法. 正交表分析法 有时候，可能因为大量的参数的组合而引起测试用例数量上的激增，同时，这些测试用例并没有明显的优先级上的差距，而测试人员又无法完成这么多数量的测试，就可以通过正交表来进行缩减一些用例，从而达到尽量少的用例覆盖尽量大的范围的可能性 白盒测试用例设计的关键是以较少的用例覆盖尽可能多的内部程序逻辑结果 黑盒法用例设计的关键同样也是以较少的用例覆盖模块输出和输入接口。 项目经理通过和客户的交流，完成需求文档，由开发人员和测试人员共同完成需求文档的评审，评审的内容包括：需求描述不清楚的地方和可能有明显冲突或者无法实现的功能 版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人
1.6K10编辑于 2022-11-07 - 来自专栏全栈程序员必看
Mock测试用例_测试用例库
近期在重构一些旧项目，看到之前同事编写的测试用例是使用注入SpringJUnit4ClassRunner 直接注册实现层然后测试需要操作的方法是否可运行。虽然这样说是可以达到测试的想法。 因此引入mock来进行改造该测试用例，以业务控制层为切入点，断言预判是否符合结果。这样就达到测试的效果了。
2.3K40编辑于 2022-09-19 - 来自专栏全栈程序员必看
python执行测试用例_平台测试用例
前言 通常我们认为每个测试用例都是相互独立的，因此需要保证测试结果不依赖于测试顺序，以不同的顺序运行测试用例，可以得到相同的结果。 pytest默认运行用例的顺序是按模块和用例命名的 ASCII 编码顺序执行的，这就意味着每次运行用例的顺序都是一样的。 那么我们在写pytest用例的时候，既然每个用例都是相互独立的， 那就可以打乱用例的顺序随机执行，用到 pytest 的插件 pytest-random-order 可以实现此目的，github 地址 print("用例4") def test_5(): print("用例5") def test_6(): print("用例6") 执行命令 pytest -s -- 2(self): print("用例2") def test_3(self): print("用例3") 这样在执行的时候，TestRandom里面的用例顺序就是
3K32编辑于 2022-09-19 - 来自专栏全栈测试
巧用Kimi生成测试用例，只需5步，亲测好用！
1、提供用例模板 2、用例模块划分 3、生成测试用例 4、完善补充用例 5、验证和优化用例 6、迭代和维护用例 下面一一介绍详细操作步骤，供参考。 在对话框输入用例列表字段内容，如下： # 测试用例包含字段 1.模块名称 2.用例编号 3.功能项 4.标题 5.前置条件 6.步骤 7.期望结果 8.优先级 9.类型 10.编写人 11.执行人 12 这是测试用例模板框架，以后生成测试用例，都是按照这些内容生成。你记住了吗？ 6、迭代和维护用例 根据测试结果和反馈，不断迭代和完善AI模型，提高测试用例的准确性和相关性。 定期更新功能点和测试用例模板，以适应系统的变化和新的需求。 三、总结 测试用例生成过程包括提供用例模板、用例模块划分、生成测试用例、完善补充用例、验证和优化用例、迭代和维护用例这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
腾讯云开发者
Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 
粤公网安备44030502008569号
腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号