关键词：
借用前辈经验，作下记录，后续丰富：
摘要：
关于用例评审，你是否了解用例评审前的准备工作有哪些 ？
需要几轮评审 ？
需要哪些人参加 ？
评审时长 ？
评审形式 ？
评审结束后，还需要做哪些 ？
关于用例评审，多数团队都有这个流程，很多书籍上也有提过，网上充斥着各种文章；那么，各企业团队实际的执行流程是怎样的？如何落地的 ？
今天一起来看看这篇文章。
如下是正文：
作者：木木
首先明确两个概念。
什么是用例评审？
用例评审主要是产品、开发和测试人员，针对测试用例能否用于项目的测试而做的工作。
用例评审的目的
为了减少测试人员执行阶段做无效工作（执行无效case，提交无效问题）
为了避免三方需求理解不一致；
为了每个测试人员的质量标准与项目要求标准达成一致。
测试用例评审加入测试流程规范并试用2个多月了，期间根据各方人员的反馈，及为了提高用例评审的效率，特制定以下用例评审规范：
一、评审前需要做哪些准备工作
1、需求评审结束后，就可以着手把需求拆分为功能点 。
工具：建议用XMind，需包含预期结果和测试结果，Android和iOS测试结果可用标签区分标注。
优点：用画思维导图的方式，逻辑清楚，便于评审人员（产品和开发人员）快速查看，评审效率高。
这里需要说明的是，很多测试者喜欢用Excel设计用例，我也不例外，但是根据一段时间的试验，和开发产品沟通后，大家都觉得用XMind写思维导图的方式更好，看起来更便捷。
所以具体用什么工具方法，大家可依个人爱好而定，不过目标是一样的，让用例评审高效快捷的开展，并产生价值。
2、把功能点再分解为具体的测试用例 。
这里需在思维导图上补全预期结果和实际测试结果，便于测试结果跟进。
3、用例写完后，自己先做好自检，自检中，针对有疑问的点罗列出来，可事先跟产品开发讨论，确定结果后完善用例，仍有疑问的可先做标记，评审会上抛出一起讨论。
4、和评审人员（开发和产品）确定好具体的评审时间并提前把测试用例发给参会人员查看。
二、用例评审参加人员
主要是产品、开发（客户端和后端）、测试、项目负责人、运营。
注：以上人员为必须参加人员，其他和项目质量、进度有关人员，根据实际情况可邀请参加。
三、用例评审时间
对于敏捷开发项目，建议控制在半小时以内。
如果你认为需求复杂，功能点太多，半小时讲不完，那么建议你对功能点划分优先级，优先评审优先级高的用例，再针对疑问多的用例评审，最后对于功能简单的用例可简单带过。时刻记住我们用例的评审目标，不能流于形式。
四、用例评审的形式
1、对照测试用例，从上而下，从左到右，逐条念。
这是目前很多公司的做法，如果你也这么做过，相信你并不一定喜欢这种方式，因为它费时，不分主次，参会人员的热情与注意力逐渐降低，整个用例评审效率低，作为主持人也讲的口干舌燥，事倍功半。
2、先对功能复杂，优先级高，疑问多的用例进行评审，再评审功能简单，优先级低的功能点。
对于评审过程中，一时半会没有结论的问题，可以记录下来，作为会后讨论跟进的重点。
这种做法，有很多优点，评审刚开始的一段时间，大家注意力集中，参与激情高，这段时间讨论有难度有疑问的问题，效率高。最重要的事最先做。
另外，整个评审会主次分明，有高潮有缓点，可以更高效的达到我们评审的目的。
五、正式评审
正式评审过程中需要注意几个细节，如果你都做到了，那么可以说整个评审是成功的，有价值的。
1、评审要按用例的优先级，功能的复杂程度进行；
2、评审过程中尽量做到，思路清晰，用最简洁的语言阐述每一个功能点；
3、超过5分钟无法确定结果的问题留作会后讨论跟进。
六、评审结束后需要做些什么事？
不是说评审会结束了，就完事了，其实对于整个用例评审，这才做了一半。
评审结束后，第一时间整理测试用例，把修正的内容重新整理补全。
会上未确定的内容，会后继续跟进，直到确定结果。
没有任何有疑问的地方了，再做个简单的用例评审会议总结（如修正了哪些功能点，补全了哪些？哪些模块功能有变动？哪些功能推迟到下一期做？等），
这个总结是给自己整个用例评审工作总结，同时需同步给项目组其他成员，做好信息共享，这点很重要。
好了，整个完整的用例评审及需要注意的地方大概就是这些，希望测试组人员认真去看，并落实到具体的工作中。
个别地方根据项目实际情况可灵活变动。
最后，有问题欢迎随时交流沟通。
End ，正文结束。
2021软件测试用例评审
当需求基线确定后，测试工程师即开始设计测试计划、测试方案和编写测试用例，测试用例设计完成后，是否代表该测试用例已经达到要求了呢?不管从研发流程还是从软件质量控制角度来说，此时的测试用例都不... 查看详情
测试用例评审
转载：http://www.cnblogs.com/wuxiaoxia/p/5496261.html测试用例的评审能够使用例的结构更清晰，覆盖的用户场景更全面；对于测试工程师来说也是一个快速提高用例设计能力的过程。1、需要评审的原因测试用例是软件测试的准则，但它并... 查看详情
漫谈测试成长之探索——测试用例评审
在分享测试用例评审的内容之前，我们可以先思考下为什么要组织测试用例评审会议呢？一、评审目的一般来说，参加测试用例评审的人员包括对应项目的产品人员、设计人员、开发人员和测试人员。测试用例评审会... 查看详情
测试用例评审流程
功能评审定义：由研发经理主推，测试协助推进由研发经理和测试负责人定义，相关测试人员负责推进小功能由研发和测试自行定义人员研发人员测试人员研发经理需求人员时间由测试人员编写完测试用例和思路后，进行评审，... 查看详情
如何高效开展测试用例评审？附用例评审检查清单及用例评审报告模板
在一个完整的测试流程中，测试用例是很核心的一个产出物。一份优秀的测试用例，能确保软件产品质量的可控。但由于每个人思维局限性，对产品背景、需求、功能实现逻辑等理解深度不一致，编写的测试用例或多或少存在一... 查看详情
测试用例如何评审，看完这篇就会了(代码片段)
众所周知，对于测试同学来说，在软件研发流程中有两个重要的会议，一个是需求评审会议，另一个是用例评审会议。不知道大家把“用例评审”放在了什么样的“地位”。在我看来，用例评审是测试流程中... 查看详情
如何高效开展测试用例评审？附用例评审检查清单及用例评审报告模板
一、前言 在一个完整的测试流程中，测试用例是很核心的一个产出物。一份优秀的测试用例，能确保软件产品质量的可控。但由于每个人思维局限性，对产品背景、需求、功能实现逻辑等理解深度不一... 查看详情
《软件测试常见面试题四》
1.简述软件测试的基本过程a、测试人员进行测试需求分析b、测试负责人编写测试计划c、测试人员根据测试需求分机设计和编写测试用例d、测试人员搭建测试环境，创建测试数据，执行测试用例，提交缺陷报告并进行跟踪、记录... 查看详情
《软件测试常见面试题四》
1.简述软件测试的基本过程a、测试人员进行测试需求分析b、测试负责人编写测试计划c、测试人员根据测试需求分机设计和编写测试用例d、测试人员搭建测试环境，创建测试数据，执行测试用例，提交缺陷报告并进行跟踪、记录... 查看详情
漫谈测试成长之探索——测试用例评审(代码片段)
在分享测试用例评审的内容之前，我们可以先思考下为什么要组织测试用例评审会议呢？一、评审目的一般来说，参加测试用例评审的人员包括对应项目的产品人员、设计人员、开发人员和测试人员。 图1-1测试用例... 查看详情
5.为什么要做设计评审和测试用例评审
敏捷开发系列文章目录 设计评审和测试用例评审我们都是迭代的第二天做，一般会给开发人员半天的时间思考一下他自己故事的设计，然后抽出1-2个小时进行设计评审，设计评审完后就做测试用例评审。设计评审就... 查看详情
测试用例评审流程
功能评审定义：由研发经理主推，测试协助推进由研发经理和测试负责人定义，相关测试人员负责推进小功能由研发和测试自行定义人员研发人员测试人员研发经理需求人员时间由测试人员编写完测试用例和思路后，进行评审，... 查看详情
测试用例评审关注点
测试用例评审关注点1、用例设计是否清晰、合理、简洁；2、用例是否高效对需求进行覆盖，是否覆盖测试需求上的所有功能点；3、优先级是否合理；4、用例是否有很好的可执行性（例如用例的“执行步骤”、“期待结果”是... 查看详情
腾讯优测优分享|这样做测试用例评审更高效
腾讯优测是专业的移动云测试平台，提供多维度的自动化测试服务，让测试更简单！最近的用例评审让我感受颇深，以下是我对于测试用例评审的一些感受，发出来供大家讨论学习。听听大家对测试用例评审... 查看详情
腾讯优测优分享|这样做测试用例评审更高效
腾讯优测是专业的移动云测试平台，提供多维度的自动化测试服务，让测试更简单！最近的用例评审让我感受颇深，以下是我对于测试用例评审的一些感受，发出来供大家讨论学习。听听大家对测试用例评审... 查看详情
全程软件测试_测试过程工作分解表
...含字段的具体描述）1.2需求规格说明书评审1.3编写/修改测试需求1.4Demo的查看和评审1.5开发计划查看和评审2.测试计划2.1确定测试目标（功能性需求和非功能性需求）2.2确定测试范围2.3确定测试资源和进度2.4测试计划写作2.5测试... 查看详情
测试管理工具都有哪些？
我们一直使用日事清来进行测试流程和测试用例库的测试管理工具平台，它可以帮助您：测试用例的过程管理，对测试需求过程、测试用例设计过程、业务组件设计实现过程等整个测试过程进行管理。测试管理平台是构建测试流... 查看详情
测试用例评审的旁观记录
2022年05月24日下午旁观了客户的测试用例评审。参与的角色：项目经理、研发经理、技术架构师、效能经理、前端技术负责人、业务架构师、测试人员、开发人员、外部咨询顾问。人数：共计11人。时长：70分钟。需要... 查看详情