匿名职言 测试工程师的职责

匿名 · 2018年05月25日 · 最后由 匿名 回复于 2018年05月28日 · 2491 次阅读

最近在审核别人测试开发课程的 PPT,9 个 PPT 同样的测试场景几乎用到了各自不同的测试技术,审核过程中我也要不断的查阅资料进行了解。联想到前几天一帖子中的词汇:“技术约架”, 我开始反思测试工程师的职责是什么?

我非常赞同大家多学习技术,这样面对实际问题的时候能够选择最优的方案。理念是一点问题都没有的,但是实际工作中我觉得很多人走偏了,为了技术而技术,为了业绩而写工具,好像没人关注质量本身,更多是我自动化覆盖了多少?用什么框架来做这件事情?我开始有点不理解这个职位上大部分人做的事情是什么? 炫技? 和开发较劲技术?

共收到 25 条回复 时间 点赞

不说什么高大上的事情,所谓炫技也是为了工资有所提高,不然纯手工,能拿多少钱

同样的的疑问

有了技术能够让测试这个手工艺时代进入工业时代,解放繁琐的事去做更多需要脑力的事,从而提高效率,减少人力。人类发展不就是这个样子的嘛。你说的手工能测试出更多 bug,那是因为测试的技术这部分还未研究透彻,导致暂时性的手工测好于自动化。而且你测试的是别人用代码写的逻辑,如果你不懂别人的技术,你怎么从更深层次多维度保证你的质量?你怎么敢说这个软件是合格的?只靠你的点点点嘛?也就是会使用而已哇。如果你是测试的是一辆新的汽车的话,你不懂汽车构造,你说你要手动测试一下,去开几天新车上路试一试,这不是拿您生命开玩笑嘛。测试工程师的职责难道仅仅只是帮助用户体验一下软件好不好用?所以不要开历史的倒车,历史的车轮谁都没法阻止,市场既然需要测试有技术说明这条路是正确的,只是部分人没有看到而已,限于自己的思维围墙里走不出来而已。你所看到的不一定是整个世界

再者,如果你会用自动化工具,你能站在更高的角度思考如何测试,而不是花时间重复劳动,而且技术是相通的,你会用工具甚至能自己制造工具,那么你就知道别人开发时哪里最容易出错,当然也有底气指导开发,知道开发哪里可能会有问题,针对性测试,而不是凭空想象。你说你手工测试是不是只能是隔靴搔痒而已呢,低级错误的预防应该交给开发自测而不是测试去测,测试应该着力发现更深层次的 bug

楼上跑偏了吧,楼主是肯定技术的必要的啊。
楼主是想说不要为了用到什么技术而去造轮子,现有工具是否能支持,对比类似工具有什么有什么优缺点,之后再考虑有没有必要自己写一个

匿名 回复

那就自己写啊,工具不好用自己搞一个啊

一切不以保证质量为目的的测试技术都是耍流氓。
楼主说的一些事情,确实非常常见,很多公司的人都迫于 KPI,OKR 而导致盲目堆积自动化用例,盲目开发一些实际效果欠佳的所谓平台。这些都是不可取的,但是这些都和测试技术本身没有任何关系,出问题的是用这些技术的人。关键就是这些人还自以为是,指点江山,这就非常讨厌了。感觉楼主是不是被指点江山了?

匿名 回复

就是不要拍脑袋就去写,既然工具不好用,对比分析结果怎么样?现有工具可以改造后使用吗?自己写的东西可以评估工具准确性、扩展性等问题吗,这些都考虑过再去想着用什么技术框架去写

匿名 回复

这也许就是测试行业转型的阵痛吧

兄弟你这个文章相当于当年的一张大字报哇

匿名 回复

我是楼主,您说的都对,但的确跑偏了。我不排斥学习技术,我本身是测试开发,也写工具和研究框架。我排斥的是

  1. 开发了框架和工具,就到处虚假宣传。其实没人在用,或者用的是少数, 这样的工作量其实是浪费时间
  2. 好像不使用新技术,就不能体现自己的水平。
  3. 大部分测试开发不了解测试需求,而且看不起手工测试

我所倡导的:

  1. 测试开发是非常好的发展路线,我鼓励每个手工测试都去学习技术。 但是无论是测试,测试开发都是为了质量服务的, 平时的工作应该核心是保证质量。

  2. 手工/自动化只是测试方法而已,我认为测试开发这个职位其实是 中国特色的职位。根源在于测试起步较晚,但整体朝着好的方向发展。

  3. 我很不喜欢,开发鄙视测试技术不行,测试开发鄙视手工技术不行,这样类似的鄙视链。首先,大家都是打工的职责不同而已,其次最重要的就是,都是一群 “低收入” 人群,何必呢?把眼光放得高一点,做好自己。

题外话:

  1. 回复楼上, 我没有被指手画脚,只是想了很久这样的问题,突然被触动了,哈哈

  2. 大部分技术男,每天关注的都是手机,电脑,和技术。但对大部分人而言,这些不能变现,也是消费的习惯。我也是个屌丝,从今天开始要多关注赚钱的方法,总不能以后让老婆孩子每月守着固定的薪资,不敢买这买那吧?

这些都是心里话,扯远了

匿名 回复

也对, 没毛病。哈哈

哈哈哈哈,楼主说的没毛病。最近超喜欢看 testhome 上的评论,啥帖子都能扯到一大堆英文单词上,看的我都觉得我这几年测试白做了😀
我跟我同事,特别是新人都是这样说:不管啥拽炸天的技术,都是辅助提升质量的手段,不要本末倒置。人工半小时能完成的工作,写脚本做要 1 个小时,那用它干嘛?
衡量测试产出最核心的是产品质量,不是代码量。
当然技术是要学的,但是要把握好度,技术是质量保证的前提条件,要看平台适不适用。好用那是高大上,不好用可就装过头了。

匿名 回复

making the world a better place;

应该是不同公司不同情况,所以用到的不一样吧

对于这个

我跟我同事,特别是新人都是这样说:不管啥拽炸天的技术,都是辅助提升质量的手段,不要本末倒置。人工半小时能完成的工作,写脚本做要 1 个小时,那用它干嘛?

完全不能统一,原因是:
1.第一次 1 一个小时不代表以后每次都是 1 个小时,测试需要练习,代码能力如果不练习你会发现事情大部分都是人工半小时,写代码却要 1 小时

  1. 脚本解决一个问题不管任何语言都需要一个积累的过程,不过是语言相关第三方包都是需要积累,有了积累,写脚本会越来越快
  2. 测试本来练脚本的机会少,有机会不练习,平常更没有机会练习

有机会就要多练习,半小时做完了,再花一个小时把脚本写了,长期积累就会不一样。

另外上面说的英语单词啥的,至少我认为英语很重要,很快的看懂英文文档帮助很大,不要小看英语的力量了。

对于这个

我跟我同事,特别是新人都是这样说:不管啥拽炸天的技术,都是辅助提升质量的手段,不要本末倒置。人工半小时能完成的工作,写脚本做要 1 个小时,那用它干嘛?

完全不能同意,原因是:
1.第一次 1 一个小时不代表以后每次都是 1 个小时,测试需要练习,代码能力如果不练习你会发现事情大部分都是人工半小时,写代码却要 1 小时

  1. 脚本解决一个问题不管任何语言都需要一个积累的过程,不过是语言相关第三方包都是需要积累,有了积累,写脚本会越来越快
  2. 测试本来练脚本的机会少,有机会不练习,平常更没有机会练习

有机会就要多练习,半小时做完了,再花一个小时把脚本写了,长期积累就会不一样。

另外上面说的英语单词啥的,至少我认为英语很重要,很快的看懂英文文档帮助很大,不要小看英语的力量了。

测试的技术差异太大,NB 的技术与 LB 的技术相差十万八千里,我敢说那些为了自动化而搞自动化的人,有多少了解技术的本质?
一句代码搞定的事情,有些人花了一个月去做?大多数 hr、测试经理都不懂最新的技术,1 个了解技术本质的人一个月可以搞定的事情,偏有人花上半年、一年时间去搞!

匿名 回复

好像在抬杠

匿名 回复

完全不能统一
工作派出来,要看具体什么工作.
如果是一次性的,不能保证自己把脚本搞出来或是恐怕要很长时间完成,手工就可以;
但不耽误你在空闲时间用代码再搞一遍
非要占着手工能完成的时间在那练习...,至少没有一个经理愿意听到你上班是为了练手的

22楼 已删除
匿名 回复

工具现在分成了两类

  1. 代替人,比如 ui,接口,自动上线
  2. 没这类工具不成,比如你要测通信协议,搞压力,不上工具,确实只有人没法弄

感觉帖主碰到的解决方案可能都是属于第一类的;大部分测试开发搞出来的工具也是第一类的

第一类工具的问题 确实是搞不出太多的 bug

然后这类人员主要问题是远离实际业务.再加上少部分二逼领导要求你搞出来的工具要是个人就会用,这简直是灾难.

反正不管怎么样,他们比 点点点的挣得多;

还有,人类的发展是时刻都在犯错误,把自己玩坏自食恶果,然后反思,再次玩坏;
早晚把自己玩死

行业间互相鄙视算是挺常见的吧。 我都习惯了。 老在那技术约架,可能是太闲了。

哪儿都有杠精?拜托把自己手上主要的事情做好、做全,技术只是提升自己的辅助方式,也可能是后续的核心竞争力之所在。状态没对,技术再牛掰都白搭。(话说,最近大家真是很漂了,或者来灌水发牢骚的多了?)

匿名 回复

@Lihuazhang 大佬,麻烦看看,这贴能关了不。感觉要引战?

需要 登录 后方可回复, 如果你还没有账号请点击这里 注册