是否遇到看了几天的需求文档 没有理清楚需求从哪里开始,到哪里结束,需求边界在哪里。
是否曾花了很多时间编写出的用例,到项目中却无法开展测试。
是否刚做完测试,又有新版本过来,来不及看需求,来不及写用例,项目经理就来问测试结果。
每天忙的像个陀螺,节奏越快越没底,对新项目(需求)渐渐有了恐惧,完全不知道从哪里开始。
以上这些,是我的测试路程,我不聪明,也不愿意什么事都请教别人(怪我咯),分配到自己身上的事情再难也会抗,跳过很多坑,背过很多锅。
有人曾说我只有测试经验没有行业经验,我认同。
因为我单看需求文档,只认识文字,组合在一起就是想象不出到底表达了几个意思。
为什么读不懂需求,我一开始认为是没有听产品经理讲解,于是在后来的项目中,产品经理讲解需求时我特意跑去参加,发现听到都清晰,但就是无法将它们转成我能理解的需求(判断标准是能不能写出测试用例)
我没有行业知识去判断产品经理写的这个需求是不是正确的,然而我又无法自动认为已看到的就是正确的。
而测试的第一步,就是判断需求的正确性,我总纠结我看到需求存在的合理性,因我怕这个需求是错的,而我在这个错的需求上做的越多,就错的更多。
我对我听到/看到的需求无法做出它是不是正确需求的判断,我一直思考的是需求本身的正确性,因为无法确定,所以我一直无法写出用例。
在工作中,不管是否理解需求,测试都是要做的,为了减少需求理解不对带来的Bug,在多次尝试后,我找到了自己的笨方法。
为看到的需求设想使用场景,比如:在一个订购的场景中必须要有的元素 用户、产品、价格、产品付费类型(一次、永久、包时段),其他属性优惠/减免,去和需求对应,去和产品经理做确认。
这种方式尝试的次数越多,构思场景的速度越来越快,常常还没到测试执行阶段就能发现问题,我想这也是一种测试方式。
到正式拿到可测项目时,心里对需求已有底。
那么如何快速地进行功能测试呢?
1)找到项目的主流程场景和常用场景。
2)拿以上场景中的字段属性和需求去做对比,对有出入进行修正。
3)边测试边完善场景,写简要的测试用例和步骤(补充异常case)
4)走完第一轮测试,回顾所有场景。
因都是自己大脑思考,回忆一遍很快,也因都在脑海,只要负责过的项目,有什么功能、功能在什么地方,有什么字段属性都是一清二楚的,再也不用翻看厚厚的需求文档。
5)场景测试完成后,对所有功能做个扫测。
确保所有功能无明显异常(页面报错、功能不可用)
如查看功能,点进去看一眼即可(因知道所有属性,也知道属性显示成什么样是对的,一般一眼就能判断出)
6)保持一个习惯,看研发提交日志和代码。
这是一个提升测试正确率的大杀器,可以少走很多弯路,减少大部分工作量。
前提:要有阅读代码的能力。
此方式在代码框架设计的合理情况下都是可靠的,倘若框架设计的烂,如两个毫不相干的模块却共用一个方法、属性,那就死的不能再死啦,因为你根本就是想象不到的,也无法预防的。
每次测试前 我都会仔细阅读研发的提交日志和代码变更,会根据这些去判断哪些需要重点测试,哪些只要看是否有影响即可。
如果发现代码变更和需求变更无法对应上时 会立马找研发当场确认,为什么改动这块代码。
这个时候往往发现有个更大的坑在,如果不看代码变更,那么只有做全部的回归测试才能发现问题啦。
以上6点,就是我快速进行测试的秘诀,分享给大家,望对大家有所帮助,也期望和大家讨论,得到更有效的测试路径。