职业经验 在项目里的测开贡献值衡量问题

Martin · 2019年06月21日 · 最后由 Martin 回复于 2019年07月26日 · 2026 次阅读

看到过有人讨论测开的价值的帖子, 最近面试不少测开也是只是说写自动化脚本, 然后问到自动化脚本的产出是什么, 基本没几个说的清楚, 那我问产品或者接口改动了,你的自动化回归怎么弄, 往往回答说跟着改, 那么反反复复的改投入你一个测开, 价值到底是啥, 我这里只提供一个在项目里的测开的评价角度, 专门做平台的另说.

共收到 15 条回复 时间 点赞

简单说就是能 review code,能优化现有方案,还要肯接手工测试的活👍

我一直也在思考这个问题,怎么更好的通过数据衡量贡献

要看稳定程度,自动化也可以很稳定,看你怎么写。。

已经是智能化时代了,另外比较好奇,楼主如何回答自己提出的问题

pan 回复

主要看维护工作量。
有的测开工具,把大量业务层的东西抽象出来,做到配置、数据文件里。框架是灵活了,但是对业务测试来说,似乎工作量并少不了多少。有的业务测试怼回来:需求变化用你这个框架配置一遍,比自己写一遍代码还累
这样的框架稳定有啥用?

秋草 回复

这就牵涉到另外一个问题了吧,怎样衡量测试用例维护的工作量了吧?或者是怎样减少后期维护成本?冒昧请教下,对于这些你们是怎么解决的?对于我现在的团队就是缺少工具,所以我的思路是先解决工具再解决工作量的问题

陈子昂 回复

想请教一下,您认为的稳定是什么样的?比如说我自己拥有一个通过解析 yaml 文件的测试框架,每次产品需求变动,只需要维护 yaml 文件就行,这样算稳定吗?

你避免了一个严重问题,这个严重问题可能导致公司丢单,或者损失 XX 万。
或者你发现一个很隐蔽的问题,这个问题一旦发布,会带来巨大损失。
老板一看,这测试很不错~

比如有时候造个数据,执行个脚本,需要很复杂的流程,做完一次至少要 5 分钟。你如果写个平台化界面,测试人员只要点击一下,2s 内给出结果,提升了测试效率,节省了测试时间,这也算贡献的

pan 回复

简单来说,测开要定位为服务团队,服务对象就是业务测试。实际需求是方的,你造的轮子再圆也没有用。
很多时候不是缺少工具,而是很多已有工具业务测试不了解不掌握。测开沉到业务测试中,做好工具选型并形成最佳实践,教练好团队使用,远比做一堆重复度极高的框架、工具更为重要。

服务意识往往比技术本身更重要。

有人说,努力提高自己的不可替代性,避免未来被淘汰;然后楼主的帖子又主张尽量把测试的产出规范化,可移交化;这里面有没有矛盾呢?在我看来做测试就像是一个给自己挖坑的过程,完美的测试应该是让产品质量达到一个绝对的高度,无懈可击,然后测试就可以 game over 了,这种程度当然是可望不可及的,但是测试的最终目的不就是这样么😂

能发现问题的自动化才是好自动化吧

Martin #15 · 2019年07月26日 Author
我去催饭 回复

你这个问题还蛮有意思的, 其实看自己定位啦, 我在大公司看到过一哥们水平不怎么样就因为维护一个很老的系统, 这些老技术,老坑就他知道, 所以活的也挺好, 这个人愿意把自己固化在里面,那也可以.
但是对于有追求的人来说,肯定还是把自己能力做成通用的, 现在公司内部把自己的能力平台化,服务化, 做的好就可以横向对其他公司输出方案,就可以创业了, 比如以前做 ES 做的深的做成了日志易, 做探针做的好的做成了听云, 做自动化测试做的牛的做成了云测, 能把自己能力服务化了,也就是边界成本降低了, 也就成了一个好的商业模式了.

测试方案优化能否举几个例子呢,一直不懂。。。

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