一名好的测试人员,在工作中,不仅要做到有宽度更要有深度!
何为宽度?测试用例的覆盖面更广更全。
测试人员设计测试用例的时候可以分为这几种类型:
一:将prd的需求描述copy到测试用例。
二:细化prd,让每一个需求更饱满。
三:在二的基数上,根据实际系统业务,关联相关功能,加大覆盖范围
四:在三的基础上,加上经验的积累,丰富我们的测试用例,包括:多端兼容,中断测试,性能测试等等。
举个例子(非淘宝真实prd):淘宝搜索框,增加默认关键词搜索,默认关键词取历史搜索记录,最多3条轮播显示,每条间隔1s。点击搜索支持默认关键词搜索。
这样的prd,如果让你设计测试点,你会包括哪些呢?
一句话需求,新增一个小功能,看似很小。第一种,4个测试点,貌似已经满足需求了,但当你详细列测试点,会发现其实要测试要注意的点,还是很多的。
何为深度?
1:深入了解需求背景
2:挖掘更深层次地业务逻辑
3:出现bug必揪
4:bug产生的原因必跟,尤其是线上
5:灵活使用工具等。
看到这里,你可能会问,为什么我要了解这么多,我只不过是一名测试,高质量的完成测试工作,就可以了呀。其实,我们的身份除了是测试,更多地是站在用户得角度来使用和体验软件功能。所以,角色不同,你要考虑的事情必然不一样。
举个例子:同上
1:深入了解需求背景。
为什么加这个需求?业务痛点是什么?加了之后有没有解决这个痛点?
背景:减少用户二次搜索。加了之后确实解决了这个问题
2:挖掘深层次地业务逻辑
如果用户常用拍照购物,这里的默认关键词怎么显示
3:bug必揪。
不能因为问题偶现,就放置不管,万一上线后,不少用户出现这个问题呢?它能出现必有原因,如果实在无法复现,可以和开发讨论,开发最清楚代码逻辑,也许你说了操作步骤和现象后,你们俩可以商讨尝试出bug的出现原因。
4:线上bug,原因必跟。
线上bug,问题必然很大,影响严重,但是事实已经出现,不要逃避推卸责任,我们应该要做的是复盘,复盘自己为什么没测试出这个问题,到底是漏测,还是场景特殊没考虑到,或者其他什么原因,把它当做一个警钟,在以后的工作中,加大宽度,提高质量,降低风险。
5:灵活使用工具。
在接口测试,修改测试数据或者抓包的时候会用到测试工具,接口一般都是快于页面,优先使用工具postman,jmeter等进行接口测试;测试数据可以借助navicat,dbeaver等数据库工具进行增删改查;比如到账功能,需24小时到账,那么你可以修改时间,快速测试到账金额是否正确,无需傻傻地等待24小时。出现bug,通过fiddler或charles进行抓包,快速定位问题等。如何抓包,请参考软件测试必备技能:抓包(一)