【原创】需求评审之实战演练

一

我在面试时，经常会出一道简易计算器需求的编程题，完了之后再让写一下这个需求的用例，题目看起来很简单，但是几乎可以把我想了解到的基础测试理论全部都涵盖了。

今天我还拿这个例子来实操下在《测试人员参与需求评审的价值是什么？》中提到的需求评审关注点。

比如我现在是产品的角色，我给的需求描述是这样的：

现在有一个 PC 客户端的命令行工具，这个工具可以接收三个命令行参数，其中，前两个是数字，最后一个是运算符，运算符只支持加减乘除四种，工具的功能就是把前两个数字使用运算符做下运算，然后输出运算结果。

下面是模拟针对这个需求的需求评审。

二

先是需求合理性的讨论。

测试：「命令行的计算器，干嘛用的，为啥不用系统自带的计算器？」
产品：「恩，目前是演示环节，先不用考虑使用者，请忽略这个问题。」
测试：「为啥是命令行工具？命令行的可控性太差，建议改成 GUI 实现。」
产品：「本次针对的是特定的 Geek 群体，习惯于命令行操作，而且市面上已经有很多 GUI 的实现工具了。」
测试：「前面两个是数字，最后是运算符，不太符合操作习惯，建议把运算符放中间。」
产品：「恩，这个我们回去考虑下。」
测试：「确定只需要支持加减乘除么？是不是功能太弱了？」
产品：「这是第一版迭代，后面会根据用户需求再酌情扩展，所以这地方开发记得别写死了。」

只是做了下简单的需求合理性讨论，就变更了一次需求—参数位置的问题，同时让开发在功能实现时提前考虑了可扩展性，这些问题如果是在测试阶段提出来，大部分的可能是先不动了，不然又得改代码，如果真的改，开发和测试的工作量都会相应增加，如果不改就会增加下次迭代时候的工作量，总之，早提出需求合理性讨论，有百利而无一害。

三

接着是需求全面性的讨论。

测试：「最大支持的运算数是多少？」
产品：「浮点型的最大值就行。」（懂技术的产品都是好产品。）
测试：「工具是每次运行后只做一次运算，还是一次运算结束可以继续接收新的参数输入？」
产品：「