看到过有人讨论测开的价值的帖子, 最近面试不少测开也是只是说写自动化脚本, 然后问到自动化脚本的产出是什么, 基本没几个说的清楚, 那我问产品或者接口改动了,你的自动化回归怎么弄, 往往回答说跟着改, 那么反反复复的改投入你一个测开, 价值到底是啥, 我这里只提供一个在项目里的测开的评价角度, 专门做平台的另说.
我一直也在思考这个问题，怎么更好的通过数据衡量贡献
要看稳定程度，自动化也可以很稳定，看你怎么写。。
测试方案优化能否举几个例子呢，一直不懂。。。
陈子昂
回复
想请教一下，您认为的稳定是什么样的？比如说我自己拥有一个通过解析 yaml 文件的测试框架，每次产品需求变动，只需要维护 yaml 文件就行，这样算稳定吗？
pan
回复
主要看维护工作量。
有的测开工具，把大量业务层的东西抽象出来，做到配置、数据文件里。框架是灵活了，但是对业务测试来说，似乎工作量并少不了多少。有的业务测试怼回来：需求变化用你这个框架配置一遍，比自己写一遍代码还累
这样的框架稳定有啥用？
秋草
回复
这就牵涉到另外一个问题了吧，怎样衡量测试用例维护的工作量了吧？或者是怎样减少后期维护成本？冒昧请教下，对于这些你们是怎么解决的？对于我现在的团队就是缺少工具，所以我的思路是先解决工具再解决工作量的问题
已经是智能化时代了，另外比较好奇，楼主如何回答自己提出的问题
简单说就是能 review code,能优化现有方案，还要肯接手工测试的活
你避免了一个严重问题，这个严重问题可能导致公司丢单，或者损失 XX 万。
或者你发现一个很隐蔽的问题，这个问题一旦发布，会带来巨大损失。
老板一看，这测试很不错~
比如有时候造个数据，执行个脚本，需要很复杂的流程，做完一次至少要 5 分钟。你如果写个平台化界面，测试人员只要点击一下，2s 内给出结果，提升了测试效率，节省了测试时间，这也算贡献的
pan
回复
简单来说，测开要定位为服务团队，服务对象就是业务测试。实际需求是方的，你造的轮子再圆也没有用。
很多时候不是缺少工具，而是很多已有工具业务测试不了解不掌握。测开沉到业务测试中，做好工具选型并形成最佳实践，教练好团队使用，远比做一堆重复度极高的框架、工具更为重要。
服务意识往往比技术本身更重要。
有人说，努力提高自己的不可替代性，避免未来被淘汰；然后楼主的帖子又主张尽量把测试的产出规范化，可移交化；这里面有没有矛盾呢？在我看来做测试就像是一个给自己挖坑的过程，完美的测试应该是让产品质量达到一个绝对的高度，无懈可击，然后测试就可以 game over 了，这种程度当然是可望不可及的，但是测试的最终目的不就是这样么
https://testerhome.com/topics/17764 可以参考下这篇帖子
能发现问题的自动化才是好自动化吧
我去催饭
回复
你这个问题还蛮有意思的, 其实看自己定位啦, 我在大公司看到过一哥们水平不怎么样就因为维护一个很老的系统, 这些老技术,老坑就他知道, 所以活的也挺好, 这个人愿意把自己固化在里面,那也可以.
但是对于有追求的人来说,肯定还是把自己能力做成通用的, 现在公司内部把自己的能力平台化,服务化, 做的好就可以横向对其他公司输出方案,就可以创业了, 比如以前做 ES 做的深的做成了日志易, 做探针做的好的做成了听云, 做自动化测试做的牛的做成了云测, 能把自己能力服务化了,也就是边界成本降低了, 也就成了一个好的商业模式了.