一个健身经验超十年的胖子,喜欢看到自己的力量素质进步,也喜欢玩变形玩具并立志要拍玩具分享视频。生活中是一个经常口吐芬芳的 “C 语言” 大师,间歇性踌躇满志,但不至于持续性混吃等死。
热衷分享但货不太多,巭孬嫑浪。欢迎加微信 zingphoy(备注 TesterHome),聊技术/测试/人生/训练反正啥都行~
个人博客,很长草了:https://zingphoy.github.io/
我的理解很简单:
故,由于领域知识和技能熟练度的区别,会产生的工作效率和工作质量的问题。一个测试开发去做业务开发,一定程度上会大量浪费自身的质量知识沉淀,同时又要花大量时间去熟悉领域开发知识和技能。相当于放弃优势拿短板和别人比较。
不是 XXX 干不起,而是 XXX 更有性价比的问题。
招聘 2,报名 3,这是什么岗位被大家这么嫌弃
如果不知道要做什么,那就分析业务实际数据去找痛点,常规性的东西做得差不多,接下来就 case by case 看问题
如果你摸鱼摸得有些高度,也能拿别人的东西过来包装成自己的东西,前提是你对别人的事情了解全面细致,不然被问到就很崩盘。否则就真的不建议写,说一说就好了
感觉得看具体业务场景,D 有可能单独拎出去做性能测试,不一定要和 ABC 串联绑定在一起。
假设 D 是因为任务的量大且单个任务耗时长,背后使用队列来做异步消费,那考虑的是任务堆积的情况下 D 接口的响应会不会有什么问题。
假设 D 就是一个简单的任务状态查询接口,查一下库里任务的 status,那可以单独测 D 能扛多少读压力,能否满足业务诉求。
总结来说就是按具体业务场景去考虑,要结合技术实现去看。
从面试官角度给一些建议:
“熟悉 xxx 业务流程,有功能、性能、稳定性等测试经验” 改成 “熟悉 xxx 业务流程,能够从功能、性能、稳定性等维度把控业务的质量风险”
当然不是黑话越多越好,但是在某些场合上说说黑话容易给人一种你懂的更多的感觉。
不要把 “亮点” 挖掘局限在技术性事情上:不是每个测试同学都适合搞技术,测试岗位也不是一个技术好就能做得好的岗位,它更多的是一个综合性质岗位。所以不会搞自动化、不会搞框架不代表没有其他优点。比如有敏锐的问题感知能力,很熟悉业务的上下游架构和流程,线上线下有问题你甚至可以脱离研发独立定位到,或者对研发定位给予关键的作用,有实际案例的话都是很不错的优点。
有些事情看起来简单但是做起来很难,能做得成也是亮点:比如业务经历了快速发展,一堆历史质量债务,包括但不仅限于代码基础质量差、业务兜底未考虑、线上监控缺失等等各种回头补起来很痛苦的事情,你通过系统的数据分析找到问题,通过项目管理和里程碑拆,牵头带大家把整个事情一点点做好了,有不错的业务结果,也是值得肯定的事情。毕竟有些事情的难度大家都懂。
大学毕业前夕自己啃完了《Orange'S : 一个操作系统的实现》,前大半都有跟着写代码去跑。实话说现在已经完全记不住书里的内容了,也很难想得起来一些什么技术细节。
我觉得这种东西其实就是一个思维训练。技术很久不用自然会忘记,但只要你曾经真正的理解过,重新再翻看时很多东西马上能回忆起来,重新学习的效率很高。假如某一天你真的遇到了应用场景,那会是很大的优势吧。
同理,算法,编译器,图形学在我眼里也都是一种计算机学科的思维素养训练。
一把好椅子的重要性,就如同趁手的键鼠和高配的电脑一样。现在出租屋里用的椅子是 800 块的,用了 5 年了,开始感觉不太好使了,尤其是靠背倾斜角度无法调节导致脖子很难受。
7 楼的确太假了,本来想来删掉突然发现没了,可能是他自己删了或者被其他管理员删了
一个健身经验超十年的胖子,喜欢看到自己的力量素质进步,也喜欢玩变形玩具并立志要拍玩具分享视频。生活中是一个经常口吐芬芳的 “C 语言” 大师,间歇性踌躇满志,但不至于持续性混吃等死。
热衷分享但货不太多,巭孬嫑浪。欢迎加微信 zingphoy(备注 TesterHome),聊技术/测试/人生/训练反正啥都行~
个人博客,很长草了:https://zingphoy.github.io/