下午 2:45，二麻子的 outlook 准时提醒他，还有 15 分钟就要进行用例评审了。

本次需求改动比较大，所以需要到会议室进行面对面评审。

收到提醒，二麻子开始最后 Review 评审用的电脑：
1、完整需求描述都截图好了；
2、用例导图也准备好了；
3、用例涉及界面展示的部分也都准备好了对应的截图；
4、电脑电量充足，其他配置都不会影响演示效果；

最后验收通过，二麻子提前赶到会议室布置环境。

3 点一到，三胖子、五矮子和六顺子几个同事都陆续到场，刚好一切准备就绪，开搞。

“本次需求改动了 3 个文件，分别是 sanpang.exe、wuai.exe 和 liushun.exe，下面是我的测试点。”

“等一下”，三胖子及时打断了二麻子，“顺序搞错了吧，原始需求还没说呢。”

“哦，不好意思，一紧张忘记了。” 二麻子赶紧道歉。

同时脑袋里开始飞快的回想之前讲过的用例评审的步骤：第一步讲原始需求；第二步讲用例格式；第三步讲详细测试点。

“嗯，前几天产品经理通过论坛和卸载反馈收集到的数据，发现用户需要一个命令行版本的简易计算器，这就是本次修改的原始需求是。本次的解决方案是提供一个只支持加减乘除四则运算的命令行版本计算器。具体实现逻辑是写一个 python 脚本，接收两个运算数和一个运算符的参数输入，脚本执行后把运算结果进行输出。”

想起步骤后，二麻子一口气把第一步里面要讲的原始需求、解决方案和具体的实现逻辑都进行了说明，“大家看下这块有什么问题没有？”

这个停顿很是恰当，给其他人足够的时间来质疑需求的合理性和全面性、质疑解决方案的正确性和可靠性，这是需求评审的第一道坎。

“这都 9102 年了，竟然还有人有这样的需求，确定不是产品经理眼花看错了？” 三胖子仍然是第一个积极发言的人。

“这个问题我们已经和产品经理反复确认过了，目前看确实是这样，所以现在的结论是先做个简单的 MVP 发出去看看，再确定下一步的计划。” 二麻子回答的很到位，当前的现状以及后续的数据跟进都考虑到了。

“如果确定要这么做的话，只支持加减乘除是不是太简单了点？” 五矮子终于开口了。

“嗯，是考虑过这个问题，所以前面说这个版本是 MVP 呢，如果做的太复杂，结果发出去没人用，岂不是白白浪费人力物力财力了。”

目前看，需求的合理性和全面性都经受住了质疑，大家都陷于了沉思。

二麻子也并没有急着继续往下讲，他在等着其他人对解决方案的质疑。

“为什么要用 python 写？如果用户电脑没有安装 python 怎么办？实现成命令行方式的话，用户知道怎么用么？就算知道怎么用，会不会有被注入的安全性风险？” 六顺子这是憋了多久呀，一口气提了四个问题。

看起来二麻子并没有被问住，只见他不慌不忙的答道，“用 python 主要是为了快，而且我们使用 pyinstaller 把脚本进行打包处理成一个独立 exe，所以不用担心环境的问题。关于命令行的使用方式，主要还是因为产品想快速出 MVP，会找一些目标用户来进行试用并回收试用结果，所以先这样了，安全性问题我们已经发起安全评审了，目前看功能比较单一，风险可以接受。”

好家伙，二麻子准备的很充分嘛，他看大家再次陷于了沉思，感觉也应该没啥问题，就准备继续了。

“我记得 python 3.4 之后就不支持 winXP 了，咱们用的哪个 python 版本？” 三胖子做了一个总结发言。

“目前用的 3.7，还真没关注这个问题，我下去查一下。” 二麻子心想，竟然还有这么个逻辑，又学到一招。

看起来第一关已经没问题了，二麻子开始继续讲第二步：用例的整体格式。

关于用例格式，每次用例评审大家有关注，并且还有几篇文章进行了汇总整理：
《思维导图写测试点的再补充》
《思维导图写测试点的额外补充》
《用思维导图写测试点的几点说明》
《思维导图编写测试用例的两种格式》

所以总的原则已经都很轻车熟路了。

“我是按功能、性能、安全性、兼容性这么几个大类作为第一层分类，功能部分我又按输入、运算和输出进行了细分，bulabulabula” 只见二麻子按之前的要求逐个说明自己的分类方式，听的几个人都不住的点头。

很明显，这第二关就是送分题，顺利通过。

“没什么问题我继续讲具体的测试点了”，二麻子开始继续第三步的详细测试点的讲解。

“大家看下这块有什么问题或补充的测试点没有？”

“分隔符虽然需求里面没有说明，但应该是隐性需求，还是应该有测试点覆盖。”

“嗯，这个确实是我漏掉了，我回去给补上。”

“测试数据的选取上，你选择了 10，还有 100、1000，这三种应该是同一个测试目的，没必要测试三个吧，有一个应该就能代表了。”

“这么设计主要是不放心，所以就多挑了几个数据，如果从边界值分析的角度看，确实是多余的，我给去掉。”

“……”，大家七嘴八舌的开始从测试用例的全面性和针对性两方面对测试用例进行补充完善。

终于大家都停下来不说话了，二麻子轻轻擦了下额头上的冷汗，悬着的心总算是放下了。

“如果没有其他问题，这次用例评审就先这样，多谢大家的积极参与，谢谢。”

谢幕词说完，大家开始陆续离场，二麻子赶紧把刚才大家提到的问题一一记录上，并且又默默回忆了一下用例评审的步骤，加深下记忆，同时对每个步骤中自己作为主讲人应该准备的内容，也都一一进行了回顾。

这才放心的合上电脑，本次用例评审结束。

以上，我通过一个小故事，把我们用例评审的步骤做了一个简单的介绍，不知道和你理解的是否一致，欢迎留言说说你的意见。

当然，如果你认可我的观点，欢迎分享文章到朋友圈 + 点个「在看」让更多人看到，谢谢。