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