隐形需求 软件测试,给软件测试员加个buff——“隐形需求”

2023-11-11 13:59

本文主要是介绍隐形需求 软件测试,给软件测试员加个buff——“隐形需求”,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

软件测试员每日必做工作之一就是要了解用户的需求,测试出用户满意的产品是软件测试工作的核心,那么在需求评审过程中,更多的优秀软件测试员更善于对用户“隐形需求”的挖掘,那么,“隐形需求”的重要性体现在哪呢?

ffbda54800be730b8f262ae2f5855d20.png

我们网上冲浪经常会看到“男友求生欲”挂上热搜,很多男生表示,再也不相信女友说的“我没生气”了。很多时候,在对很多矛盾的处理上女生会更在意男生的态度,这就是女生的“隐形需求”,有时候男生执着于对错,解决了问题,却只能收到冷淡的回应。

有的软件测试员表示母胎solo,那么这个例子一定能击中你的心啦!

378bc098269885ca74dbf02810fca33e.png

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

很多人面试可能都会遇到这样关于写测试点的题,我相信大部分人在写功能测试点的时候都能覆盖到三个参数的正常和异常情况,会有一半的人能考虑到参数个数的正常和异常情况,一小半的人应该能考虑到数字参数的最大值情况,而能考虑到参数分隔符的正常和异常情况的就只有非常少的人了。

参数类型、参数个数这些都是需求里面明确写出来的,这些我们可以称为显性需求,所以能考虑到这部分用例的人很多,特别是参数的正常和异常,不管是否知道等价类划分法,都能考虑到。

但是参数个数和数字最大值,又可以算到边界值分析法里面,如果不知道边界值分析,可能不会考虑到参数个数所有异常的覆盖情况,如果不懂编程,可能问不出来数字使用什么类型这样的问题,当然也就不知道所谓的最大值要怎么构造了,所以这个也可以算到隐性需求的范畴。

这里“隐形需求”就是参数分隔符了,这种没有明确说明的地方,有时候开发会按照自己自以为的方式给实现了,比如默认空格分割,但是测试后期发现很多人也会用逗号去分割,修改的话会造成新的修改成本,其实这个地方操作不难,难的是少有人想得到。

b8d4a53bcdf6ab9a460aef915b4626c0.gif

这篇关于隐形需求 软件测试,给软件测试员加个buff——“隐形需求”的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/390534

相关文章

十四、我们应当怎样做需求分析:子用例与扩展用例

用例模型作为UML中4+1视图中非常重要的一员,非常集中地体现了面向对象的分析与设计思想。用例模型将现实世界中连续的一个一个业务流程,按照场景划分到了一个一个的用例中。由于场景的出现,使得用例中的业务流程存在着高度的内聚性,从而成为了日后各种对象的雏形。同时,在用例分析中,又将那些存在于各个用例中的,相同或相近的业务操作提取出来,形成一个一个的子用例或扩展用例,又体现了面向对象设计中的复用性。现在

十三、我们应当怎样做需求分析:查询报表分析

在我以往的用例分析中,使用这样格式的用例模式,对于大多数业务操作流程来说是得心应手的,但对于有些功能来说总感觉不对劲。感觉不对劲的,就是那些查询、汇总与报表功能。对于这部分功能,需要我们描述的不是什么操作流程,而更重要的是那些数据项、数据来源、报表格式、数据链接,以及使用者、使用频率的说明。而这些,在以往的用例说明格式中统统都没有,怎么办呢?俗话说“东西是死的人是活的”,把我们的用例格式改改吧。

九、我们应当怎样做需求分析:功能角色分析与用例图

在我们进行一系列需求调研工作的同时,我们的需求分析工作也开始启动了。需求调研与需求分析工作应当是相辅相伴共同进行的。每次参加完需求调研回到公司,我们就应当对需求调研的成果进行一次需求分析。当下一次开始进行需求调研时,我们应当首先将上次需求分析的结果与客户进行确认,同时对需求分析中提出的疑问交给客户予以解答。这就是一个需求捕获->需求整理->需求验证->再需求捕获的过程。  但是,当我们经

八、我们应当怎样做需求调研:需求捕获(下)

前面我们讨论了,需求分析工作是一个迭代的过程:需求捕获->需求整理->需求验证->再需求捕获······需求捕获是这个迭代过程的开始,也是整个需求分析工作中最重要的部分。没有捕获哪来后面的整理与验证工作?但是,非常遗憾,按照我以往的经验,需求捕获是我们最薄弱的环节。前面我提到的许许多多项目开发的问题都可以归结为需求分析的问题,而许许多多需求分析的问题又都可以归结为需求捕获不完整的问题。需求捕获是整

七、我们应当怎样做需求调研:需求捕获(上)

前面我们讨论了,需求分析工作是一个迭代的过程:需求捕获->需求整理->需求验证->再需求捕获······需求捕获是这个迭代过程的开始,也是整个需求分析工作中最重要的部分。没有捕获哪来后面的整理与验证工作?但是,非常遗憾,按照我以往的经验,需求捕获是我们最薄弱的环节。前面我提到的许许多多项目开发的问题都可以归结为需求分析的问题,而许许多多需求分析的问题又都可以归结为需求捕获不完整的问题。需求捕获是整

六、我们应当怎样做需求调研:迭代

前面我一直在反复强调这样一个观点,需求分析不是一蹴而就的,是一个反复迭代的过程。它将从第一次需求分析开始,一直持续到整个项目生命周期。为什么这样说呢?让我们一起来分析分析。  在第一次的需求分析阶段,我们在一段时期内需要与客户进行反复地讨论,这个过程往往是这样一个反复循环的过程:需求捕获->需求整理->需求验证->再需求捕获••••••  需求捕获,就是我们与客户在一起开研讨会

五、我们应当怎样做需求调研:需求研讨

前面我们探讨了业务研讨会应当怎样组织,下面我们再具体讨论一下我们应当怎样与客户讨论业务需求。如果说组织业务研讨会是项目经理的功底,那么讨论业务需求就是需求分析人员的功底。  以往我们常常认为,需求分析是一件最简单的事情。客户说他们需要做一个什么软件,有些什么功能,我们照着做就可以了,所谓的需求分析员就是需求的记录员。我要说,这是一个极大的错误,许多失败的软件项目,或者说软件项目中的需求问

软件测试之压力测试知识总结

软件测试之压力测试知识总结 一、压力测试概述 压力测试(Stress Testing)是软件测试中的一种重要手段,用于验证软件应用程序在极端负载条件下的稳定性和可靠性。其主要目的是在软件承受极高负载时,测量其健壮性、错误处理能力和恢复能力,确保软件在危急情况下不会崩溃或表现异常。压力测试也被称为耐力测试,在软件工程中占有举足轻重的地位。 1.1 压力测试的目的 压力测试的主要目的包括:

软件测试中常用的linux命令总结

1、修改ssh登陆密码命令:passwd 2、新建一个名字为dbuser的Linux新用户:(sudo adduser dbuser) 4、./frps -c ./frps.ini(FRP启动命令) 5、lsof -i:7500(监听端口) 6、sh reload.sh master(文件后缀为sh时,nginx启动命令);( 文件为执行文件启动命令:./nginx -s reload) 7、sh

软件测试永远的家——银行测试,YYDS

为什么做金融类软件测试举个栗子,银行里的软件测试工程师。横向跟互联网公司里的测试来说,薪资相对稳定,加班少甚至基本没有,业务稳定。实在是测试类岗位中的香饽饽! 一、什么是金融行业 金融业是指经营金融商品的特殊行业,它包括银行业、保险业、信托业、证券业和租赁业 往往涉及证券、银行、基金、信托、保险、投行、期货等领域 二、金融行业的业务特点 随着金融行业的业务不断增加,金融交易模式的不断变化,