首先介绍一下我们组原本的用例评审流程：
1、通知用例评审会议，大家到会议室集合。

2、用例负责人现场讲解用例，同时记录大家提出的问题。

3、会后用例负责人根据自己记录的问题修改用例。

按照这个流程执行下来，用例评审的效果并不理想，整理了一下存在的问题：

1、评审开始前，用例缺乏预审。如果遇到质量不太理想的用例直接在会议上展示，评审效率会变的很低，甚至出现过一轮评审结束后的结论是“建议回炉重造”。

2、有时评审来的很突然，参加评审的同学可能没有时间充分了解待评审模块，评审时无法充分发现问题，导致评审效果不理想。

3、评审现场，用例负责人讲解自己用例的同时还需要处理其他同学提出的问题。这时候如果花时间做详细记录或者修改用例，那么将会影响会议效率；如果只是草草做一笔记录，会后很可能就忘记当时想记录内容的具体含义，甚至还可能根本找不到那些做了标记的待修改用例。

4、评审现场，可能会有一些同学总是保持沉默，参与评审的积极性不高。

5、评审会后，评审问题会根据一个测试自主任务单跟进，但是单子的描述往往不会涵盖会议提出的所有问题（因为上面提到用例负责人记录问题存在的弊端）。有时可能连单子都忘记开了，整个评审不是闭环流程。

可以看到我们原始的流程存在诸如“评审前准备不充分”，“评审效率不高”，“评审参与不积极”，“评审后问题跟进不闭环”等问题。针对这些问题，逐一分析了背后原因，对评审流程的各个环节做了优化，具体改进措施以及改进原因如下：

评审需要有一个总负责人，主要负责：选取评审内容，会前预定会议室、邀请与会人员，会议中把握会议节奏，注意每个环节都走到，会议后跟进问题处理情况。

我们组内一般是我来担任这个角色，也可以安排其他有经验的QA同学轮流担任。

每次评审用例的体量不易过大，过大的模块建议拆分多次进行评审。当然也可以安排几个体量小的模块在一次会议中评审。

根据经验，每次会议控制在一小时内最好，如果超过一个半小时大家就会很疲惫，专注力明显下降，后面的用例得到的有价值建议数量减少。与其这样不如将模块拆分，或者至少安排一下中场休息。

会议前安排一个QA同学对待评审的用例做预审工作，发现用例中明显的规则、逻辑、格式问题，避免将这类问题带到会议上，提升评审效率。

预审过程中，两人之间可能会出现一些争议，对于这些争议不必深究，可以记录下来放到评审会议中讨论。

建议安排用例负责人的导师来做这个工作，也可以安排相关模块的负责人来做这个工作。

恰好我是组内集中测试负责人，想到可以把用例评审与集中测试相结合。在计划发起某个模块的用例评审时，如果之前没有针对这个模块组织过集中测试，那么可以先安排一次集中测试，让组内的QA同学事先熟悉一下这个模块。这么做可以避免出现部分同学在用例评审会议上才第一次接触这个模块，导致大家因为不熟悉模块而无话可说。

安排用例负责人之外的另一个QA同学作为会议记录员，专门负责记录大家提出的问题。

记录员可以安排负责预审的QA同学、导师、徒弟或者往常提问不积极的同学来做。

这样做的好处：

1、用例负责人就可以专心讲解用例，不再会因为需要记录问题而耽误评审流程。

2、问题可以被详细记录下来，会后过很久也可以被很好的理解。

3、评审记录员是一个很好的机会，可以观察学习其他同学的评审技巧。

根据实际情况，我们会选择邀请策划/程序同学来参加用例评审，这么做的好处有：

1、原本需要会后确认的设计问题或者代码逻辑问题可以在会上就得到确认，提升效率。

2、策划/程序同学往往会从不同于QA的角度给出评审建议。

3、可以让策划/程序同学更好的了解QA日常都是从哪些角度进行测试，他们在日后工作中也会更加注意这些方面，减少设计/开发阶段的问题。（虽然效果不一定会立竿见影，但是确实有帮助。）

4、可以消除职能间的隔阂，有一些策划/程序同学在参加用例评审后，会发现我们的QA同学其实非常专业，会增加对产品测试质量的信心。

决定邀请哪些策划和程序同学后，要事先通知评审时间和地点。评审结束后，我们还会对他们贡献建议表示感谢（不用很正式，轻松愉快一些就好）。这都有助于下次的再邀请他们来参加评审。

评审效率低不仅耽误时间，而且过长的评审时间会让大家专注力下降，影响评审效果。对比多次用例评审，我发现体量与完成度差不多的两份用例分别由不同的QA同学讲解，会议效率并不相同。用例负责人奖需要掌握一些讲解技巧来提升评审效率，详见3.1。

此外，评审负责人需要注意每次讲解的情况，遇到问题可以会后与用例负责人单独沟通，便于下次讲解过程更加高效。如果是首次讲解用例的新人，评审负责人也需要在会前将基本技巧传授给新人。

我这边总结一般大家发言积极性不高的原因主要有：“不好意思提出自己的看法”、“缺乏评审技巧”、“对于待评审模块不熟悉”、“专注力下降”这四点。下面逐一介绍一下这些问题的解决建议：

1、 不好意思提出自己的看法——这个情况多出现于新人，如果发现这种情况，会后我会去找他或者安排导师与他单独沟通，提升新人的自信心。新人的可塑性很强，越早发现这个问题，越容易解决。

2、 缺乏评审技巧——这个情况也是多出现于新人。除了会后指导外，还会安排他作为下一次评审会议的记录员，记录员可以更好的观察学习其他同学的评审技巧。3.2中整理了一些基本的评审技巧。

3、 对于待评审模块不熟悉——

a) 像上面说的，尽量在评审前组织一次集中测试，让大家熟悉模块。

b) 评审开始，用例负责人先介绍一下自己设计用例的思路以及用例的大体框架。

c) 负责人可以事先准备一些视频，用于主要玩法的介绍。

d) 需要提升QA同学的用例评审技巧。实际评审过程中发现，有经验的QA同学，对于陌生模块也能很快熟悉，并积极参与到讨论中。

4、 专注力下降——

a) 与会人员自己需要排除干扰，专心听讲。

b) 负责人控制讨论范围，避免无关的发散。

c) 合理安排会议内容，对体量大的模块进行拆分。

d) 提升讲解效率，适当通过发起讨论或播放视频等其他手段引起大家注意。

e) 对于无法拆分，会议时间较长的评审，安排中场休息。

评审负责人可以观察每次评审中每人的提问次数，针对发言较少的同学分析原因，单独沟通。但是需要注意避免让这种方法“强迫”大家提问，无效的评审建议反倒会影响评审效果。目前我们组发言积极性提高了很多，已经不再用这个方法了。

评审结束前，还有一个重要环节，记录员需要逐一展示一下自己记录的问题，与大家进行确认。避免出现记漏记错的情况。

设计了用例评审工具需求，并在雷火MTL同学的支持下，用例管理平台已经支持用例评审功能，可以很方便的记录并跟进评审问题，统计评审数据等。

借助用例管理平台，可以很方便的对每个问题进行跟进，让流程形成闭环。

修改用例——用例负责人，借助用例管理平台，针对记录的问题逐条修改。

验收修改——用例复审员，借助用例管理平台，针对修改的问题，逐条验收。未通过的话，可以打回修改用例阶段。通过的话，就可以进行归档完成整个用例评审流程。

评审负责人需要在每次评审结束后，对本次评审进行复盘：

分析存在的问题——针对本次流程存在的问题，与QA同学沟通或者思考流程改进方法。

评估所做改进的效果——如果本次流程中做了新的优化尝试，那么也需要在会后进行评估，分析方法是否可行，是否需要调整。

上文提到了对于用例评审流程的优化，帮助我们的用例评审工作可以更好的开展。但是归根结底，对于用例的“讲解”与“评审”才是最核心的部分，所以除了优化流程，我们的QA同学也需要掌握一些基本的讲解与评审技巧。

用例评审中，用例负责人的职责并不只是详尽的把自己的用例讲完就够了。讲解效率低，除了会消耗更多的时间外，大家的专注度也会被逐步消耗，随着会议的持续有价值的建议会越来越少，评审效果也会大打折扣。

对比多次用例评审，我发现体量与完成度差不多的两份用例分别由不同的QA同学讲解，会议效率并不相同。这里分享一些简单好上手的讲解技巧：

1、评审开始后，不要匆忙开始，直接就“现在开始给大家讲解我的用例，首先是一个部分……”。在开始之前，可以先简单介绍一下模块基础玩法，模块设计目的，用例设计思路，以及用例框架这些基础信息。简单介绍就好，不用花费太多时间。这么做的好处和会议PPT最开始的目录效果类似：一方面大家会对评审内容有一个初步的概念；另一方面大家可以估计一下会议时长，做好心理准备。

2、不要误解用例评审的目的：

用例评审不是为了介绍模块，琐碎的细节讲解可以简略带过。

用例评审不是为了展示负责人对于自己模块有多么熟悉，用例覆盖有多么全面。对于自己很有把握的部分，可以简略带过。

3、用例评审主要是为了让大家帮忙发现问题，提升用例覆盖率。对于自己不太有把握的部分、涉及核心功能的部分、模块间交叉的部分等，负责人可以多花些时间讲解。还可以抛出问题，引发大家思考与讨论，比如“这个玩法掉落的道具，可能涉及到数值培养与生产制造，相关模块的同学可以看看有我的用例或者你们的用例没有什么要补充的内容？”。

4、就像开始说的，会议持续时间越久，大家专注度下降越多。所以重点部分无需作为压轴节目放在最后，在不影响逻辑的前提下，可以不按照用例结构顺序讲解，将重点部分放在前面讲。

5、可以事先准备一些视频用来辅助展示玩法内容（用例管理平台支持上传多种格式的视频文件）。视频表现能力强，效果往往会胜过口头表达或者图片展示。而且视频可以很好引起听众的注意力，恢复对会议的专注度。

控制视频的时长与数量，针对重要流程准备一下就好了。

非必要情况，不是很推荐真机展示，事先准备不充分的话，可能会受到环境或者BUG的影响阻碍展示，导致评审中断，需要重新恢复评审氛围。

用例评审不是用例负责人的独角戏，各位参与者提出的评审建议的价值与数量，直接决定了评审会议的效果。各位参与者需要在会前先熟悉一下模块内容，在会上保持专注，积极参与讨论，贡献有价值的建议。下面主要介绍一些常用的评审角度，除了评审时可以用于提出有价值的建议，日常自己做测试设计时也可以用到：

2.1 针对用例覆盖：

1、 根据我的经验，待评审用例覆盖率最低的是模块之间交叉的部分，这也是召集大家在一起评审用例最希望补充的内容。所以各位评审同学针对待评审模块，首先需要思考：

a) 与其他模块，尤其是自己负责的模块之间是否有可能发生交叉？如，抽卡与战斗模块，立刻装备新抽到的卡用于战斗。

b) 这些发生交叉的可能是否会引入风险？如，玩家战斗时更换时装。

c) 如果无法与自己负责模块发生关联是否也是问题？如，生产制造需要使用材料A，需要确保采集玩法可以获得材料A。

2、 遇到数值/数量相关内容，需要关注各类边界情况。如，拾取物品超过堆叠数量，发送空消息，刷新时间跨月跨年，奖励领取次数达到上限等。

3、 穷举玩法触发条件的各种可能，确保这些触发条件可用，且无逻辑问题。如，活动副本可以通过活动宣传页面进入，可以通过常规副本面板进入，可以与NPC交互进入等。

4、 尝试重复相同操作。如，连续点击UI，副本续杯功能等。

5、 检查数值是否合理。如，技能伤害，奖励投放等。

6、 尝试在主流程中加入新的操作。如，工会战期间被踢出公会等。

7、 记得考虑手机操作。如，锁屏、多指操作、分辨率等情况。

8、 考虑删号、断线重连、重启服务器、更换设备顶号等情况。

2.2 针对用例规则

1、 除了考虑用例覆盖是否有不足，还要考虑用例是否冗余，是否可以被执行。如，“零点前操作”，“零点整操作”与“零点后操作”这三条用例中，“零点整操作”本身就不具备可执行性，通常来说只能让操作无限接近零点。

2、 注意用例是否方便执行。如，“抽卡抽到某张ssr”，虽然这条用例是可以执行的，但是执行时比较考验QA同学的欧气，建议可以附上调整概率的操作，让用例更容易执行。

3、 用例结构是否合理，是否符合逻辑，可以提升用例执行效率。

4、 用例中描述用词与游戏内正式包装保持一致。

5、 注意用例格式，用例分级是否合适。

最后，从人员分工的维度，再对整个用例评审流程做一下回顾：

用例负责同学：写好用例后发起用例评审申请；修改预审阶段发现的问题；掌握用例讲解技巧，提高会议效率；会后及时处理评审问题，完善用例。

用例评审同学：会前熟悉待评审模块；会上保持专注，积极参加讨论；掌握评审技巧，贡献有价值的建议。

用例预审同学：会前预审用例，发现用例设计中明显的规则、逻辑、格式问题；记录下预审中存在争议的部分，评审会议上进行讨论。

会议记录同学：负责记录现场提出的评审建议；会议结束前回顾记录的问题。

用例复审同学：会后用例负责人修改完用例后，负责确保问题完全解决。

用例评审负责人：如果组内预约不积极，可以主动出击，寻找适合安排评审的模块；评估用例体量，考虑是否拆分两次评审；安排会议时间，通知与会人员；根据实际情况提前安排集中测试；会议中把控会议节奏，防止讨论过分发散，适当插入中场休息；会后分析评审效果，进行改进。

下面是流程图：

用例评审流程图

以上是我对组内用例评审流程优化过程的总结，希望能给大家带来帮助。当然用例评审也不一定需要局限于会议形式，以文档或者结对互审等其他形式也是可以的，如果各位朋友有什么想法也欢迎一起讨论，谢谢。