需求评审之实战演练

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

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

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

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

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

先是需求合理性的讨论。

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

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

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

测试:「最大支持的运算数是多少?」
产品:「浮点型的最大值就行。」(懂技术的产品都是好产品。)
测试:「工具是每次运行后只做一次运算,还是一次运算结束可以继续接收新的参数输入?」
产品:「第一版不做太复杂,每次都需要重新执行,只接收直接执行时候的参数传入。」
测试:「三个参数之间用什么分隔?」
产品:「空格或逗号,两个都支持。」
测试:「这个得有个说明吧,不然用户会傻傻分不清。」
产品:「对,如果参数格式错误输出一个使用说明的提示。」
测试:「如果缺少参数提示什么错误信息呢?」
产品:「提示说,你输入的参数个数不正确,请按照 [运算数 运算符 运算数] 的格式输入。」
测试:「如果参数类型错误提示什么错误信息呢?」
产品:「提示说,你输入的参数类型不支持,请重新输入。」
测试:「这个提示不明确吧?参数类型不支持,那具体支持哪些类型呢?用户还是会懵逼呀。」
产品:「那改一下,你输入的参数类型不正确,运算数只支持浮点型,运算符中只支持+-*/,分隔符支持空格和的逗号。」
测试:「如果除数为零,提示什么错误信息呢?」
产品:「提示说,你输入的除数为零,请重新输入。」

除了一个主分支的问题,其他的都属于旁支,旁支是对主分支的补充和完善,也是大家最容易忽视的地方,也是用户环境最容易出现问题的地方。

怎么样?这么简单一个 if 语句就可以搞定的需求,竟然可以提出 12 个有效问题,如果这些是在测试过程中提出,考虑下每个问题从提出到产品确认,然后开发修复,然后测试验证,这过程的损耗有多大,而如果是在需求评审阶段提出的话,开发就可以完全按照既定的需求,提前考虑各种场景的处理,极大的减少了需求变化造成的沟通和返工成本。

然后再罗嗦一句,面试过程中会发现很多人自己写的代码,会被自己之后写的测试用例测的漏洞百出,就比如除数为零的考虑吧,如果我们从测试的角度写用例,很多人都能考虑到,但是写代码呢,99% 的人都没处理,当然不排除一部分人是面试时候的简单实现,但是仍然能说明开发思维和测试思维的差异性,所以我想说的是:

1.作为测试,我们对开发的要求,自己尽量也以身作则,这样才能从开发的角度上更好的和开发沟通;
2.作为开发,20% 的代码做实现,80% 的代码处理异常,是很正常的事,所以请不要等 bug 上来了才去处理异常;
3.作为产品,要考虑到所有可能出现的和用户交互的地方,对于细节的处理,一直都是作为产品功底的体现,这也是为什么彩蛋称之为彩蛋,尽可能不要让它变成臭蛋。

好了,这次是从一个简单的需求着手,说说关于需求评审的两个关注点,可以想象一下,如果是比较大的需求,测试要提出的问题会很多,那么就需要考虑一些策略的问题了,比如分批次进行评审,每一次评审确定下合理的颗粒度,方便大家聚焦,但是不管怎么说,测试参与需求评审的作用是很大的。

别看上面的例子简单,可能也还有我没考虑到的点呢,如果你有补充的内容,欢迎给我留言。

本文首发于公众号「sylan215」,十年测试老兵的原创干货,关注我,涨姿势!

原创文章,作者:kepupublish,如若转载,请注明出处:https://blog.ytso.com/193343.html

(0)
上一篇 2021年11月15日
下一篇 2021年11月15日

相关推荐

发表回复

登录后才能评论