一
我在面试时，经常会出一道简易计算器需求的编程题，完了之后再让写一下这个需求的用例，题目看起来很简单，但是几乎可以把我想了解到的基础测试理论全部都涵盖了。
今天我还拿这个例子来实操下在《测试人员参与需求评审的价值是什么？》中提到的需求评审关注点。
比如我现在是产品的角色，我给的需求描述是这样的：
现在有一个 PC 客户端的命令行工具，这个工具可以接收三个命令行参数，其中，前两个是数字，最后一个是运算符，运算符只支持加减乘除四种，工具的功能就是把前两个数字使用运算符做下运算，然后输出运算结果。
下面是模拟针对这个需求的需求评审。
二
先是需求合理性的讨论。
测试：「命令行的计算器，干嘛用的，为啥不用系统自带的计算器？」
产品：「恩，目前是演示环节，先不用考虑使用者，请忽略这个问题。」
测试：「为啥是命令行工具？命令行的可控性太差，建议改成 GUI 实现。」
产品：「本次针对的是特定的 Geek 群体，习惯于命令行操作，而且市面上已经有很多 GUI 的实现工具了。」
测试：「前面两个是数字，最后是运算符，不太符合操作习惯，建议把运算符放中间。」
产品：「恩，这个我们回去考虑下。」
测试：「确定只需要支持加减乘除么？是不是功能太弱了？」
产品：「这是第一版迭代，后面会根据用户需求再酌情扩展，所以这地方开发记得别写死了。」
只是做了下简单的需求合理性讨论，就变更了一次需求---参数位置的问题，同时让开发在功能实现时提前考虑了可扩展性，这些问题如果是在测试阶段提出来，大部分的可能是先不动了，不然又得改代码，如果真的改，开发和测试的工作量都会相应增加，如果不改就会增加下次迭代时候的工作量，总之，早提出需求合理性讨论，有百利而无一害。
三
接着是需求全面性的讨论。
测试：「最大支持的运算数是多少？」
产品：「浮点型的最大值就行。」（懂技术的产品都是好产品。）
测试：「工具是每次运行后只做一次运算，还是一次运算结束可以继续接收新的参数输入？」
产品：「第一版不做太复杂，每次都需要重新执行，只接收直接执行时候的参数传入。」
测试：「三个参数之间用什么分隔？」
产品：「空格或逗号，两个都支持。」
测试：「这个得有个说明吧，不然用户会傻傻分不清。」
产品：「对，如果参数格式错误输出一个使用说明的提示。」
测试：「如果缺少参数提示什么错误信息呢？」
产品：「提示说，你输入的参数个数不正确，请按照 [运算数 运算符 运算数] 的格式输入。」
测试：「如果参数类型错误提示什么错误信息呢？」
产品：「提示说，你输入的参数类型不支持，请重新输入。」
测试：「这个提示不明确吧？参数类型不支持，那具体支持哪些类型呢？用户还是会懵逼呀。」
产品：「那改一下，你输入的参数类型不正确，运算数只支持浮点型，运算符中只支持+-*/，分隔符支持空格和的逗号。」
测试：「如果除数为零，提示什么错误信息呢？」
产品：「提示说，你输入的除数为零，请重新输入。」
除了一个主分支的问题，其他的都属于旁支，旁支是对主分支的补充和完善，也是大家最容易忽视的地方，也是用户环境最容易出现问题的地方。
四
怎么样？这么简单一个 if 语句就可以搞定的需求，竟然可以提出 12 个有效问题，如果这些是在测试过程中提出，考虑下每个问题从提出到产品确认，然后开发修复，然后测试验证，这过程的损耗有多大，而如果是在需求评审阶段提出的话，开发就可以完全按照既定的需求，提前考虑各种场景的处理，极大的减少了需求变化造成的沟通和返工成本。
然后再罗嗦一句，面试过程中会发现很多人自己写的代码，会被自己之后写的测试用例测的漏洞百出，就比如除数为零的考虑吧，如果我们从测试的角度写用例，很多人都能考虑到，但是写代码呢，99% 的人都没处理，当然不排除一部分人是面试时候的简单实现，但是仍然能说明开发思维和测试思维的差异性，所以我想说的是：
1.作为测试，我们对开发的要求，自己尽量也以身作则，这样才能从开发的角度上更好的和开发沟通；
2.作为开发，20% 的代码做实现，80% 的代码处理异常，是很正常的事，所以请不要等 bug 上来了才去处理异常；
3.作为产品，要考虑到所有可能出现的和用户交互的地方，对于细节的处理，一直都是作为产品功底的体现，这也是为什么彩蛋称之为彩蛋，尽可能不要让它变成臭蛋。
五
好了，这次是从一个简单的需求着手，说说关于需求评审的两个关注点，可以想象一下，如果是比较大的需求，测试要提出的问题会很多，那么就需要考虑一些策略的问题了，比如分批次进行评审，每一次评审确定下合理的颗粒度，方便大家聚焦，但是不管怎么说，测试参与需求评审的作用是很大的。
别看上面的例子简单，可能也还有我没考虑到的点呢，如果你有补充的内容，欢迎给我留言。
本文首发于公众号「sylan215」，十年测试老兵的原创干货，关注我，涨姿势！
原文地址：http://blog.51cto.com/sylan215/2286850