日常中经常遇到测试会说很忙，没有时间做其他看似高深的技术，然后当真的要做些看似高深的东西是比如写些脚本，有时会说这个不能马上解决问题，不能马上变成全自动实现，这个脚本就是没用的，这个脚本就是麻烦的。感觉是不是太现实了，难道只有全自动化才叫提高效率吗？效率当然是一点点提高的，就像滚雪球，越滚越大，一点点脚本的积累，一点点效率的提高，才是现实情况，指望一下子解决所有的问题，可能吗？而且对自己有什么好处，宁愿加班到 12 点，也不愿学些脚本，来完成一些非常简单的脚本 10 分钟搞定的事情。头脑里面都是大名词，什么 BDD，什么 CI／CD，什么云，什么。。。。。。。。，然后写个简单脚本确说没时间。。。。。。。，反思呀。。。。。。。。。
加班，有时是无法避免，但是没有日常简单的积累，一步一步的改善自己，加班不会改善的，抱怨开发不给你讲实现之类的，可以人家讲了，你真的就是完全懂吗？
日常工作中，有太多的东西可以联系自动化，从 python 到 java，只要有心很多都可以，最怕就是光说不练。。。。。。。
说的不错！
只有自动化测试、自动化运维，没听说过有自动化产品经理、自动化开发、自动化项目经理、自动化运营、自动化风控的。
这一点说明测试领域和运维领域的前人水准不够，胡乱起名字。你看开发，哪个开发是自己写二进制的，不都是编译器帮他 “自动化开发” 的吗？开发的前人聪明的地方在于，把人做的那部分编码工作定义为 “开发"，把机器自动化做的开发起了个名字叫 “编译”。
同理，测试领域内，首先应该把定义改一下，只有人做的测试才叫测试，机器做的可以叫 “检查” 或者 “校验”。压根就没有什么鬼的全自动化，顶多做一个自动化校验，那根本不叫测试。自动化校验只是测试的一部分，就像编译是开发的一部分一样。人做的那部分才是测试。
所以我极度反感自动化测试一词，综上，我是来支持半自动化测试的，并且提出，我们应该用新名词来定义测试。
自动化，还得看是测试什么内容、业务以及复杂程度。我任务简单、重复、长时间、都可以自动化执行的。太复杂的逻辑思维还是需要人工的干预。
#9 楼 @anonymous 能够预估自动化的工作量，以及完成后对效率的提升有多高。能力提高一般不算入投入产出比。
从公司角度，你个人能力的提高如果不能带来价值，那么也没啥卵用。
如果做了才能评估，那就没啥意义了。
说实话投入产出比起其实挺扯的，没做你怎么评估？不同的人不同的能力，做了之后能力的提高算在投入产出比吗？
测试的价值是场景设计和分析，跟具体的实施策略是手工还是自动化关系不大。手工测试还是自动化，需要考虑的问题只是投入产出比。
自动化都是从半自动化开始的，半自动化就是一个个点，有了一定的点之后，面才慢慢出来
顶半自动化，自动化不能约束业务测试同学。
顶
#4 楼 @anonymous 没有，只是工作久了，形成了一些思路。。。。你也会的
—— 来自 TesterHome 官方 安卓客户端
你好厉害哦
没时间写脚本的人，其实是不会写。。。。哈哈哈哈
—— 来自 TesterHome 官方 安卓客户端
其实，行家都知道，最有效的测试是有人工参与的半自动化。既能兼顾效率，又能保证质量。坚持自己认为对的就是了。自动化只是测试途径。测试本身才是重点。
—— 来自 TesterHome 官方 安卓客户端
滚雪球我吃过