- 综合排序
- 最热优先
- 最新优先
- 来自专栏软件测试经验与教训
如何评审测试用例
用例评审一直做，但没有多大效果？ 2. 用例评审时按着用例一条条讲，讲到最后自己都不知道该说什么了，好像大家都挺懵逼的？ 3. 用例评审开发人员不愿意参与？ 4. 评审时，外部人员提了好多用例的问题，他们怎么做到的？ 我们今天来聊一下评审用例的话题。 用 例 评 审 标 准 区分是测试组内的评审还是项目组内的评审。内部评审和外部评审在内容方面会有不同。 测 试 组 内 评 审 1、用例描述是否清晰：比如看到用例标题就能明白这条用例测试的是什么（而不是直到看到期望结果才明白这条用例的目的）， 执行步骤和期望输出是否有歧义。 3、是否考虑到测试用例的编写效率：即复用性要强。例如，可将重复度高的步骤或过程抽取出来定义为一些可复用标准步骤。否则写用例和执行时阅读用例都会花费很多时间。 5、是否覆盖了所有的软件需求？测试人员对需求的理解是否透彻？期望结果是否与需求一致？ 6、异常测试点：可以从测试思维框架（群里有）和以前的bug中找找看。
1.4K10发布于 2018-07-24 - 来自专栏优测Utest
优测优分享 | 这样做测试用例评审更高效
最近的用例评审让我感受颇深，以下是我对于测试用例评审的一些感受，发出来供大家讨论学习。 听听大家对测试用例评审的吐槽？ “测试用例设计是测试的事情，为什么评审要我们参加？” 开发可以从实现层面评审用例，补充测试用例中，由于测试人员不了解实现过程导致的测试用例缺失的情况。 2、评审的流程 测试人员确定评审日期和参与评审人员 评审前2天，测试用例发给所有评审人员 评审人员记录测试用例问题 评审会议，测试用例编写人员讲解用例，参与人员提出评审 会议结束，修改用例，并邮件输出 3、评审的内容 1、描述是否清晰，是否存在二义性 2、内容是否完整,是否清楚包含输入条件和预期输出结果并无争议点 3、是否覆盖了所有场景、逻辑分支、限制条件等 4、是否哪些需求不可测：无法准备环境、可测试性达不到等等原因 5、是否考虑到测试用例的执行效率（冗余的用例） 4、最后啰嗦几句 在用例评审过程中往往出现一个现象，参与评审用例的评审人员参与度不高，用例评审的效果较差。
1.9K00发布于 2020-01-07 - 来自专栏CKL的思考空间
测试用例评审如何开展
测试用例评审是测试活动中的一个重要环节，做好测试用例评审，可以有效的发现用例中的不足，并更好的补充，以免测试场景遗漏或者出现业务逻辑理解不一致。那么，如何做好测试用例评审呢？ 01 做好测试用例分级，并不是所有的测试用例都需要上评审会，或者说有些用例是需要自己内部消化的。 02 如何更好的开展测试用例评审呢？ 要注意测试用例的颗粒度，在评审时，不需要逐条过，评审测试思路即可。 本质上测试用例也是一个测试思维可视化的过程，除非你们的测试团队特别年轻（例如第一类的测试用例，不太适合进行大范围的评审） 03 不要用例评审当做一个负担，做好事前事中的准备，利用好这个机会，再一次方对齐需求理解的机会
50830编辑于 2023-02-01 - 来自专栏全栈测试
巧用Kimi生成测试用例，只需5步，亲测好用！
今天分享用国产大模型Kimi生成测试用例，只需5步！ 二、Kimi生成测试用例 根据实际演练的过程，总结标准过程可以按照以下5个步骤进行。 1、提供用例模板 2、用例模块划分 3、生成测试用例 4、完善补充用例 5、验证和优化用例 6、迭代和维护用例 下面一一介绍详细操作步骤，供参考。 在对话框输入用例列表字段内容，如下： # 测试用例包含字段 1.模块名称 2.用例编号 3.功能项 4.标题 5.前置条件 6.步骤 7.期望结果 8.优先级 9.类型 10.编写人 11.执行人 12 主功能流程验证部分测试用例： 不同使用场景验证： 5、验证和优化用例 如果认为某部分测试用例设计不够完善，可以让Kimi按照要求重新补充完善。
3K10编辑于 2024-11-23 - 来自专栏漫谈测试
聊一聊测试用例评审注意事项
去年梳理了一篇测试用例评审流程文章，文章可以点击蓝色字体查看详情。 聊聊测试用例评审流程今天主要聊一下测试用例在评审的时候需要注意哪些事项，对于从业多年的测试者来说，那是“手到擒来”，对于初入职场的人员来说，为了避免踩坑，有必要了解一下。 首先，我得回忆一下测试用例评审的基本流程和常见问题。评审前的准备工作很重要，比如用例的编写规范是否统一，测试目标是否明确，相关文档是否齐全。 测试用例评审是确保测试用例质量的重要环节，目的是发现用例设计中的遗漏、冗余或不合理之处，从而提高测试覆盖率和有效性。 通过规范的评审流程和清晰的关注点，可以有效提升测试用例的可靠性，降低测试执行阶段的遗漏风险。阅读后若有收获，不吝关注，分享等操作！
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测试用例以及压测结果
5、如原来已经有 2 个节点 Redis，后续有增加 2 个 Redis，则数据分布计算与原来的 Redis 分布无关，现有数据如果需要分布均匀的话，需要人工单独处理。 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 - 来自专栏全栈程序员必看
httprunner（5）编写测试用例
编写测试用例 HttpRunner v3.x支持三种测试用例格式pytest，YAML和JSON。 官方强烈建议以pytest格式而不是以前的YAML/JSON格式编写和维护测试用例 格式关系如下图所示： 图文解析： 1.postman收集的用例，curl命令行、抓包工具charles/fiddler config：配置测试用例，包含 base_url, verify, variables, export teststeps：测试步骤的列表，每个步骤都对应一个API请求或调用另一个测试用例，此外还支持 variables/extract/validate/hooks创建极其复杂的测试用例 链式调用 HttpRunner v3.x最重要的功能之一就是支持链式调用，使用链式调用，不需要记住任何测试用例的信息 ，在IDE中编写测试用例时就可以智能完成 发布者：全栈程序员栈长，转载请注明出处：https://javaforall.cn/166223.html原文链接：https://javaforall.cn
36320编辑于 2022-09-16 - 来自专栏全栈程序员必看
测试用例_测试用例编写
5、可维护性：由于软件开发过程中需求变更等原因的影响，常常对测试用例进行修改、增加、删除等，以便测试用符合相应测试要求。 1.3. 编写测试用例的好处： 1.1.3. PIN 有误 备选流5 – 帐户不存在/帐户类型有误 备选流6 – 帐面金额不足 对于这7个场景中的每一个场景都需要确定测试用例。 测试用例的评审能够使用例的结构更清晰，覆盖的用户场景更全面对于测试工程师来说也是一个快速提高用例设计能力的过程。 1、需要评审的原因 测试用例是软件测试的准则，但它并不是一经编制完成就成为准则。 4)用例是否具有很好可执行性。例如用例的前提条件、执行步骤、输入数据和期待结果是否清晰、正确期待结果是否有明显的验证方法。 5)是否已经删除了冗余的用例。 6)是否包含充分的反面测试用例。 5、评审的方式 1)召开评审会议。与会者在设计人员讲解之后给出意见和建议，同时进行详细的评审记录。
6.5K41编辑于 2022-09-20 - 来自专栏漫谈测试
聊聊测试用例评审会议失控测试负责人处理策略
作为测试管理者，可能正面临这样的困境：每次评审会议都严重超时，团队抱怨连连，但关键用例又不得不评。 管理者应该对测试用例评审会议时间失控，采用 「预防-干预-兜底」三维控时策略，结合硬性规则与柔性技巧。一、 会前预防：构建时间防护网1. 视觉化时间沙漏会议时间分配 “P0用例深度评审” ： 45 “P1用例快速过审” ： 30 “争议决策” ： 10 “缓冲时间” ： 5物理道具：倒计时沙漏/大屏进度条（剩余时间变红自动响铃）2. 决策加速引擎注：三巨头需在5分钟内举牌表决（红/黄/绿）5. 时间敏感度训练用例评审模拟战：规则： - 每组评审10条用例 - 总时长严格限定12分钟 - 超时扣100%分数 奖励：用时最短且缺陷发现率＞80%团队获胜2. 时间银行机制3.
22620编辑于 2025-07-30 - 来自专栏全栈程序员必看
httprunner（5）编写测试用例「建议收藏」
编写测试用例 HttpRunner v3.x支持三种测试用例格式pytest，YAML和JSON。 官方强烈建议以pytest格式而不是以前的YAML/JSON格式编写和维护测试用例 格式关系如下图所示： 图文解析： 1.postman收集的用例，curl命令行、抓包工具charles/fiddler config：配置测试用例，包含 base_url, verify, variables, export teststeps：测试步骤的列表，每个步骤都对应一个API请求或调用另一个测试用例，此外还支持 variables/extract/validate/hooks创建极其复杂的测试用例 链式调用 HttpRunner v3.x最重要的功能之一就是支持链式调用，使用链式调用，不需要记住任何测试用例的信息 ，在IDE中编写测试用例时就可以智能完成 发布者：全栈程序员栈长，转载请注明出处：https://javaforall.cn/164980.html原文链接：https://javaforall.cn
54920编辑于 2022-09-19 - 来自专栏全栈程序员必看
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 -- case/random_case/test_random2.py::test_5 ✓
3K32编辑于 2022-09-19 - 来自专栏程序员阿常
用例评审，如何约会
今天是日更的 92/365 天 上周三公司产品小东哥对 A 项目做了需求交底，我们的测试西西子同学负责该项目，今天她完成了 A 项目的用例编写工作，下一步就是发起用例评审会了，我们来看看西西子是怎么做的吧 第一步，西西子在 A 项目企业微信群 @所有人，告知大家用例编写已完成，询问大家第二天下午 2点～ 5点是否有空参加。 【下面是部分群聊信息】 西西子（测试）：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
腾讯云开发者
Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 
粤公网安备44030502008569号
腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号