业务?技术?身为测试的你,该如何看待?(上)


想必大家的职业生涯中,多少都遇到过以下问题:

  • 目前就是手动功能测试,没啥提升的,你受不了了,准备跳槽;
  • 翻了下招聘APP,全都是要求自动化/性能/安全/CI/专项,自己只会点点点,很慌;
  • 面试造火箭,自动化/性能/安全/业务/CI,要求无所不能,无所不会;入职拧螺丝,“这些东西我们都没开展起来,目前我们还是手动测试”,开始点点点;
  • 铺天盖地“纯手工测试会被逐渐淘汰”让本身就没啥技术的你感觉更慌了,开始陷入迷茫期……

好吧,不管公司怎么说了,我一定要学点东西!加油!努力!然后又可能会出现以下的几种情况:

看了两篇教程,一看就会,一写就错,嘤嘤嘤好难学不会惹,我还是点业务去算了……

天天对着《Python从入门到放弃》《21天精通删库跑路》printprintprint,写了13print以后烦死惹,三分钟热度过去,又回到了原点……

对着教程终于搞出了两个demo,可把自己牛X坏了,叉会腰,然而并没有解决任何实际问题……

不得不说,相比于开发、运维等有明确定位的技术部门,测试部门显得比较尴尬,甚至会出现个人定位和公司定位偏差较大的情况:

比如,公司不重视质量,认为测试部门只需要解决好业务问题,那么大概率你的日常工作就是点点点,然后各种和业务部门扯皮,业务部门甚至会直接把你扔给客户解答问题;这个时候的测试部门老大,很有可能也是认为业务比较重要,对技术方面则不感冒。如果长时间按照公司要求处理业务问题,同时又没有明确的自我规划的话,这份工作可能也只是多了一年经验,但是实际个人能力提升程度有限。

道理我们都懂,测试的发展无非就是技术、业务和管理三条路,说起来容易,做起来呢?

测试技术:无非就是一定的开发能力、自动化、接口、性能、安全、CI、APP专项等等,每一个部分拿出来说,就算是对技术不敏感的同学也能了解个一二三,用一些成熟的工具进行相关的工作;但是一方面想在技术方面有所建树必须有一定的开发能力,另一方面很多同学都缺少一个明确的学习思路,导致花了很多时间来学,但是无法用来确实解决一些问题;
业务:业务是基础,脱离了业务的测试没有意义。但是很多时候大家眼里的业务,都只包括页面上的功能、用户体验、业务逻辑,以及部分行业比如银行、金融等行业要求的业务知识;但是,业务真的就只包括这些内容?做好业务功能层面的测试,真的只靠页面层面的上的点点点就行??

限于篇幅原因,我们分享分为上篇和下篇,上篇谈谈业务层面的测试,下篇则是分享下如何有目的的规划技术学习,并学以致用,解决一些问题。

我们来看一个场景:

新系统,WEB登陆功能,很常见的账号+密码+验证码登陆,用户信息均通过数据库存储,你如何进行测试分析?

不谈页面上的功能,我们来看一个问题:

预计上线后,用户数量大概在2OOOW量级并不断增长,最终稳定在5000W左右的数量级。

用户相关库表是否需要做分库分表,怎么分?为什么要这么分?怎么保证分表以后,对数据表的操作匹配的库表是准确的?

一种可行的方案是根据UserID进行Hash分表,涉及到用户表的增删改查操作前根据UserID计算Hash值即可匹配到对应的表。测试时,最简单的粗暴的方式可以从每个表取出用户一些登录数据,使用Jmeter进行参数化后,访问登录接口,验证登录是否成功。具体的技术细节和测试方案不是今天的重点,提出这个问题只是想抛砖引玉的说明一些问题。

很多测试同学如果系统设计方面接触的比较少的话,看到这个问题第一反应肯定是懵的,有的测试同学会认为分库分表、落点匹配这种事情都是研发同学该保证的,测试同学只需要去验证就行了。

如果公司对测试的定位就是解决好业务功能问题,极端点测试同学甚至都不知道做了分库分表,登录也只是简单的做登录功能的验证;一旦少数数据落点匹配出现问题,单纯的页面上进行功能测试测试难以发现,那么遗留到线上将会是非常严重的问题。

但是如果测试部门真的对质量有追求的,这部分内容能忽略吗?
相比于通过工具直接遍历验证外,能不能把黑盒子一层层打开,了解这些深层次的逻辑呢?
你想了解程序内部的深层次的逻辑,如果你是妹子,卖个萌让研发给你解释,没问题,如果是你是个汉子怎么办?和研发打一架吗?能不能自己快速的梳理这个逻辑呢?该怎么做?
当看到测试开发大佬拿到项目代码权限后,几个断点,一点日志,10分钟就迅速定位到问题、梳理好了业务逻辑后,而你却要花一个小时给研发卖萌打滚扯皮,如果你会代码呢?

最简单的,通过代码来梳理系统的内部逻辑。并不推荐通过部署架构和页面功能反向梳理内部逻辑,一方面只能知其然不能知道所以然,另一方面就是很容易出现偏差,得到错误的结论。

由此我们可以看到,开发能力属于测试技术的一方面,但是在做业务测试时,合理的运用各种测试技术,不仅可以提升效率,也能提高工作质量。

我们再回过头去看这个问题:

现在答案明显是否定的了,业务层面的测试绝对不仅仅是前端的功能、公司业务层面的处理逻辑,想在业务上做到一定深度,必须要了解数据库表、部署架构、数据交互、代码逻辑、系统组件、代码逻辑等一些深层次的内容。
理清这些深层次的内容,需要技术能力作为支撑,比如数据库、服务器和部署知识、接口测试,甚至是根据代码梳理业务逻辑还需要有一些代码能力,并熟悉一些常见的系统的程序结构,能够迅速定位到要找的代码。

结论:

1、好的业务测试不仅仅局限于页面上的业务功能,更需要把黑盒子一步步打开,了解系统内部的逻辑。

2、有技术支撑能让业务层面的测试做的更加如虎添翼,高效准确。

那么,明确了我们要技术支撑业务测试后,我们也可以以解决实际问题为目标,重新梳理我们的学习思路,有目的的进行学习。

文末分享:这下面有我学习整理出来的自动化测试资料、大厂面试…待你来领取~ 见公众号:【伤心的辣条】愿你我都有所获…

合理利用自己每一分每一秒的时间来学习提升自己,不要再用"没有时间“来掩饰自己思想上的懒惰!趁年轻,使劲拼,给未来的自己一个交代!

我的测试学习交流群:902061117 群里有技术大牛一起交流分享~

原文不易呀,眼睛都留眼泪了!麻烦伸出发财小手点个赞,感谢您的支持,你的点赞是我持续更新的动力。

  • 1
    点赞
  • 2
    收藏
    觉得还不错? 一键收藏
  • 2
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 2
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值