《Web测试囧事》——第2章 功能测试:测试覆盖篇 2.1 设计测试时对需求分析不透彻导致给予用户错误的折扣

第2章

功能测试:测试覆盖篇

第1章我们已经介绍了在功能测试中最常出现的由于代码实现的技术手段所导致的问题,其实还有不少Bug是由于我们在测试过程中测试覆盖率不够造成的。

现在让我们来一起看看测试覆盖率不足会造成什么样的问题,以及如何有效地设计测试用例避免出现这些问题。

2.1 设计测试时对需求分析不透彻导致给予用户错误的折扣

网站最开始上线时就具备了类似“竞价排名”的功能——“优先显示”,可以帮助客户把自己的商品更靠前地显示给用户,增加商品的曝光率。这一功能分为4个级别:金牌用户(每年100 000元,1000件商品展示)、银牌用户(每年80 000元,600件商品展示)、铜牌用户(每年50 000元,300件商品展示)以及标准用户(单件商品收取200元展示费)。用户默认是标准用户,只有付费之后才能升级到不同的级别,而不同级别用户的商品,其展示方式和优先级也是不一样的:金牌用户的商品会显示在银牌用户的商品之前,银牌用户的商品会显示在铜牌用户的商品之前,依此类推;金牌用户的商品也会显示得更明显、更突出,其次是银牌用户的商品,再次是铜牌用户的商品,最后是标准用户的商品(见图2-1)。

上线之后不少用户反馈会员收费比较贵,业务方针对这一情况,决定当非标准用户次年续费的时候,给用户打75折。而且针对金牌用户这种大客户,当展示的商品超过1000件,可以享受8折优惠。

小蔡在测试这部分新增功能的时候,首先就遇到了需求不明确的情况:对于金牌用户超过1000件商品享受8折的基准费用,究竟是75折后的价格,还是以单件商品对于会费的均价,抑或是标准展示费用?她觉得应该是按75折的计算,因为这样对用户有利,用户会因为价格更优惠而进行多次购买;而开发人员则认为是以标准展示费用为基准费用,因为会费和超量展示费用中的所有数值都不是固定值, 而是拿参数计算出来的。如果基准是标准展示费用,就能大大简化计算逻辑。

在相持不下时,老牛建议她们去找业务方确认,最后得到的答复竟然是双方都没有选择的——以单件商品对于会费的均价的8折计算,也就是100 000/1000×80%=80元。

确定了需求之后,小蔡又发现在一种特殊场景下,优惠的计算是错误的:当用户第1年是银牌或者铜牌用户,觉得商品展示数量不够用,所以第2年升级到金牌用户,并且展示的商品超过了1000件时,用户得到的8折优惠是基于银牌用户或者铜牌用户的单价展示价格。

与此类似,如果用户第1年是金牌用户,但是第2年变成了银牌或者铜牌用户,超出600/300件商品的折扣却是基于金牌用户价格来计算的;更有甚者,即使变成了标准用户,但其所有商品的展示价格仍然都是基于金牌用户展示价格来计算的。

小蔡认为这个问题在于计算逻辑的复杂,所以就使用了正交试验设计法、边界值分析、等价类划分等测试用例设计方法,列出了所有测试数据和期待结果,然后把下面这些测试场景交给开发人员和业务方,希望避免出现更多的问题或者遗漏问题。

1)标准用户,第1年,100件商品,收费20 000元。
2)铜牌用户,第1年,0~300件商品,收费50 000元。
3)铜牌用户,第1年,n件(n>300)商品,收费50 000 + 50 000/300×(n - 300)元。
4)银牌用户,第1年,0~600件商品,收费80 000元。
5)银牌用户,第1年,n件(n>600)商品,收费80 000 + 80 000/600×(n - 600)元。
6)金牌用户,第1年,0~1000件商品,收费100 000元。
7)金牌用户,第1年,n件(n>1000)商品,收费100 000 + 100 000/1000×(n -
1000)元。
8)铜牌用户,连续两年为铜牌用户,0~300件商品,收费50 000×75%=
37 500元。
9)铜牌用户,连续两年为铜牌用户,n件(n>300)商品,收费37 500 +
50 000/300×(n-300)元。
10)银牌用户,连续两年为银牌用户,0~600件商品,收费80 000×75%=
60 000元。
11)银牌用户,连续两年为银牌用户,n件(n>600)商品,收费60 000 +
80 000/600×(n - 600)元。
12)金牌用户,连续两年为金牌用户,0~1000件商品,收费100 000×75%=
75 000元。
13)金牌用户,连续两年为金牌用户,n件(n>1000)商品,收费75 000 +100 000/1000×80%×(n - 1000)元。

这次拿给业务方确认的时候果真又出现了问题:业务方希望更多的非标准用户选择金牌用户,所以对于铜牌和银牌用户(包括金牌用户第1年),超量商品的价格应是标准用户的价格(200元)。所以包含测试数据的场景应该如下。

1)标准用户,第1年,100件商品,收费20 000元。
2)铜牌用户,第1年,0~300件商品,收费50 000元。
3)铜牌用户,第1年,n件(n>300)商品,收费50 000 + 200×(n - 300)元。
4)银牌用户,第1年,0~600件商品,收费80 000元。
5)银牌用户,第1年,n件(n>600)商品,收费80 000 + 200×(n - 600)元。
6)金牌用户,第1年,0~1000件商品,收费100 000元。
7)金牌用户,第1年,n件(n>1000)商品,收费100 000 + 200×(n - 1000)元。
8)铜牌用户,连续两年为铜牌用户,0~300件商品,收费50 000×75% = 37 500元。
9)铜牌用户,连续两年为铜牌用户,n件(n>300)商品,收费37 500 + 200×
(n - 300)元。
10)银牌用户,连续两年为银牌用户,0~600件商品,收费80 000×75% =
60 000元。
11)银牌用户,连续两年为银牌用户,n件(n>600)商品,收费60 000 + 200×
(n - 600)元。
12)金牌用户,连续两年为金牌用户,0~1000件商品,收费100 000×75% =
75 000元。
13)金牌用户,连续两年为金牌用户,n件(n>1000)商品,收费75 000 +
100 000/1000×80%×(n-1000)元。

当业务方确认了所有的测试场景后,小蔡和开发人员终于搞清楚业务需求究竟是怎样的了,也更有信心一次性全面地实现对应的功能,而非之前不断地对新发现的问题修修补补。她还发现,当遇到这种复杂逻辑的时候,必须使用清晰而明确的场景,甚至需要包含数据,才能让所有人对于同样功能的认识达成一致。

小蔡把自己的想法告诉了老牛,老牛告诉她,业界对这种实践已经归纳出一套理论方法,名叫“实例化需求”(Specification By Example,SBE),她可以多了解一下,同时在产品测试中实践。






时间: 2025-01-02 02:42:19

《Web测试囧事》——第2章 功能测试:测试覆盖篇 2.1 设计测试时对需求分析不透彻导致给予用户错误的折扣的相关文章

《Web测试囧事》——导读

前 言 为什么要写这本书 1)人不能像走兽那样活着,应该追求知识和美德.--但丁 2)助人为乐,人生一美德. 我们4个作者加起来年龄过百,而且有着年超半百的工作经验,算起来也是测试领域的老鸟了. 根据上面的1)和2),我们得出一个很重要的结论: 经过这么多年在工作中不断总结经验,时不时与Bug斗智斗勇,最后提炼出来的经验,我们希望能分享给更多的人,更重要的是能抛砖引玉,引发对更优秀的工作方式和实践的思考. 为什么需要看这本书 怎样判断你是否需要这本书?以下场景,如果8条以内你都似曾相识,那么请看

《Web测试囧事》——第1章 功能测试:技术篇 1.1 输入框中输入超过最大允许值造成页面跳转溢出

第1章 功能测试:技术篇 提到测试,大家首先会想到的就是功能性的测试,因为只有保证了产品的基本功能和流程,产品才具备给用户提供使用价值的能力,从而才有可能确定产品的核心竞争力.基于这一点,不仅测试人员和开发人员,还有产品经理.项目经理.业务方对功能完备性和正确性的重视程度也往往都是最高的.这也使得功能测试成为任何测试类型的基础. 在进行功能测试时,我们会使用诸如边界值分析.等价类划分.因果分析.组合测试(Pairwise Testing)等测试方法来设计和规划测试用例,但是这些方法大多都是从书本

《Web测试囧事》——第3章 功能测试:测试实践篇 3.1 修改充值金额范围遗漏的产品Bug

第3章 功能测试:测试实践篇 前两章我们介绍了在功能测试中使用特定的开发和测试技术手段如何避免问题,那除此之外还有没有什么别的方式可以同样起到预防作用呢? 答案是肯定的,例如本章我们介绍的通过引入某些测试实践来避免和预防Bug.现在让我们一起来看看这些故事吧. 3.1 修改充值金额范围遗漏的产品Bug 产品中有一个允许用户自助为自己账户充值的功能(见图3-1).充值金额的范围被设定在5-50元之间,低于或者高于这个金额都会被系统自动变成最接近的允许值:如输入3,因为小于最小值5,则系统自动更新为

《Web测试囧事》——1.5 过长的控件名称造成其他元素显示错位

1.5 过长的控件名称造成其他元素显示错位 小蔡接到一个公司内部在线表单项目的测试任务,这个项目中有3个独立的角色:管理员A负责编辑和布局表单控件,用户B负责填写表单中控件的内容,而审核员C只能查看B操作后的结果. 这个需求看上去不难,小蔡快速分析并且记录了以下几个测试点,开始了测试工作. 1)A可以正常添加不同类型控件(文本框.富文本框.下拉列表.多选框.单选框等)到页面中. 2)B可以正常在这些控件中输入数据. 3)C可以正常查看B所有的操作内容. 4)针对各个角色所具有的不同的操作权限进行

《Web测试囧事》——2.2 页面字段依赖导致表单提交时出错

2.2 页面字段依赖导致表单提交时出错 小蔡最近在测试中碰到一个有意思的问题,就是在提交表单时,如果不按表单设定好的由上到下的顺序一个个填写表单内容,那么在提交时就会出现提交失败的错误. 小蔡感觉到很奇怪,表单顺序的填写居然也会影响到功能?那就随着小蔡看看这个问题是怎么发现的,以及是什么原因引起的吧. 小蔡在测试用户注册账户页面时发现,注册页面内容很多而且表单很长,所以她就使用鼠标滚动,没想到滚动得过快导致有些选项并没有填写/选择,最后等到她提交表单时才发现这一点.她只好重新滚动到漏填/选的字段

《Web测试囧事》——2.5 异常场景处理不全面导致功能缺陷

2.5 异常场景处理不全面导致功能缺陷 很多测试人员在面试时会被问到如何针对特定产品测试,需要考虑哪些方面时,思路都会从两方面发散:正常场景.非正常/异常场景开始回答.从思维模式来说,测试人员就不同于开发人员比较习惯的正向思维,而是更多地从异常场景.用户场景等出发,全面地考虑使用产品时会出现的各种可能性,并通过给这些场景分配优先级来指导测试的执行. 但是测试人员并不是无所不能的,有很多异常场景光了解功能性需求是不够的,还需要了解一些架构与部署等非功能性需求.所以在设计测试场景,尤其是异常的测试场

《Web测试囧事》——3.3 前后台分离测试时需要注意测试隔离

3.3 前后台分离测试时需要注意测试隔离 小蔡测试的产品最近需要更新前后台.对于前台来说,要从之前的JavaScript转换成Angular等新技术,显示样式也要从前几年的拟物化风格转换为扁平化风格:对于后台来说,要从之前和公司内部其他产品通用的6套后台模块系统架构,转换成只包含数据库和后端服务器的2套模块系统架构,而且后台技术要用Node.js重写,如图3-5所示. 基本上这个前后台替换的任务,把整个系统都进行了替换,只是仍然保留了之前的功能.进行前后台替换的任务时间紧,所以整个项目组的开发人

《Web测试囧事》——3.4 账号关联过的手机号会一直收到短信验证码

3.4 账号关联过的手机号会一直收到短信验证码 就像现在很多注重用户安全的公司一样,小蔡的公司也决定对用户的账户增加一个强制的功能,就是需要用户绑定手机,这样能让用户第一时间得到异常登录的信息,还可以通过手机安全登录码进行二次验证,然后才能登录网站,如图3-8所示. 添加了绑定手机的功能,就意味着还需要添加修改绑定手机的功能,因为不能限制用户只使用同一个手机号. 在测试添加和修改绑定手机号的过程中,小蔡发现了一个有意思的问题:当用户第一次使用手机号绑定时,系统不会出错:如果这个手机号之前被绑定过

《Web测试囧事》——1.3 测试Web Service能否正常提供JSON数据

1.3 测试Web Service能否正常提供JSON数据 某一天,小蔡所在的项目组刚开发完成一个Web Service,服务的功能是,通过在客户端调用时指定的一个ID,可以从后台数据库中读取对应的房产信息,还有与这个房产关联的一到多个房东信息.一到多个图片信息,以及地址信息等.Web Service最终把这些信息组合成JSON格式的数据返回给调用方,调用方可以通过界面来展示相关信息,也可以通过其他方式去使用这些信息.但是,调用方具体如何使用这些信息与Web Service服务本身的测试关系不大