1、入行测试已经 5 年,目前还是点工,主要是做业务流程测试。随着项目的发展,业务功能越来越多,整个系统也越来越复杂,从最开始由 tomcat 部署的 7、8 个服务,升级到现在的几十个微服务,感觉自己的测试思维跟不上项目发展的脚步了,怎么办?
2、为什么出现这种想法呢?最近由研发自己发现的 bug 数量明显比之前多,测试也能发现 bug,但总感觉发现的不是很深的 bug,这种我们要怎么改进?
3、还有性能测试,除了 OOM 这种很容易复现的问题,其他性能相关的问题很难发现,要怎么改进?
思考,复盘,总结,如此循环
功能测试可以沉淀出各种方法论啊,比如
业务复杂性的价值:在微服务架构下,业务逻辑的理解比技术工具更重要。
缺陷发现的本质:发现深层次 bug 依赖对业务的理解深度,绝非技术手段。
3,性能问题的真相:性能瓶颈也常源于业务场景,而非纯技术问题。
注: 大多数企业根本活不到技术开花结果的那天,在资本收缩周期,企业更需要能守住业务底线的"测试守门员",而非追逐技术潮流的"测试杂技演员",其实你改不改进都大差不差,还不如多留意下公司的盈利情况,随时做好自己的容裁条件
以 TesterHome 的评论功能为例,说明发现深层次 Bug 依赖于对业务的深度理解:
1, 常规能想到的测试点:验证评论能否正常发布、显示、删除,检查字符限制、表情/代码块支持、敏感词等基础功能。
2, 你这边需要深度理解:评论功能在技术社区场景下的特殊规则、用户行为、关联系统(如审核、通知、权限)等。
举个栗子,测评论审核机制时,你需要理解的角度
从社区需求上,得知道技术社区的核心是 “高效技术交流”,因此审核太严会卡住讨论(比如发个报错日志都触发敏感词),太松又会有广告党/喷子/恨 G 档
从管理成本上想,如果全靠人工审核,团队根本忙不过来,必须依赖自动过滤 + 人工抽查的平衡。
不过一切还得看项目的性质,像社区是非盈利项目,大多数需求的实现肯定以保平安和省事为主,很多功能都不需要想那么深,能用就行
谢谢,我最近刚开始复盘,复盘测过的场景以及测试过程中出现的问题和解决方法。总结不知道以什么维度总结
学到了,谢谢,我后面尝试在这几个方面进行总结
可是现在招聘越来越卷开发技术怎么办?
对开发技术要求很高的岗位,不是必需岗,也就是要招不招的岗位 一个真正内部缺人的岗位,恰恰是业务测试的优先