加V:19841731,领 MTSC 大会历届 PPT

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

上一篇 / 下一篇  2018-09-21 20:09:05 / 个人分类:测试基础

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

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

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

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

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

先是需求合理性的讨论。

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

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

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

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

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

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

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

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

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

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

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


TAG:

sylan215的软件测试技术学习 引用 删除 sylan215   /   2019-05-16 10:09:08
复盘->总结->实践,形成正循环才可以,没有一个一劳永逸的办法
引用 删除 JINjin,   /   2019-05-15 16:36:39
现在公司也增加了需求评审一环
作为测试人员的我,会发现有些时候 在评审期间仍会遗漏些提问,在进入测试计划或用例的时候才会发现这些
应如何避免呢?有什么好的策略 粒度划分来解决吗
谢谢
引用 删除 JINjin,   /   2019-05-15 16:34:17
5
sylan215的软件测试技术学习 引用 删除 sylan215   /   2019-03-13 23:06:51
原帖由libingyu135于2019-03-13 10:43:23发表
确实涨姿势了

libingyu135的个人空间 引用 删除 libingyu135   /   2019-03-13 10:43:23
确实涨姿势了
 

评分:0

我来说两句

sylan215

sylan215

加V「19841731」,领 MTSC 大会历届 PPT。

日历

« 2024-03-25  
     12
3456789
10111213141516
17181920212223
24252627282930
31      

数据统计

  • 访问量: 109069
  • 日志数: 91
  • 图片数: 1
  • 建立时间: 2018-07-03
  • 更新时间: 2021-11-11

RSS订阅

Open Toolbar