随着自动化测试的风靡，测试同学们越来越觉得自动化就是全部，自动化就是自己的方向。
这些本身没有太大问题，但是如果认为自动化测试就是终极技术，那么我觉得这是一个很大的陷阱。
为什么？个人觉得大部分的测试把自动化和技术都定义的太狭小了,技术和自动化都是非常宽泛的定义,下面是我自己问自己的两个问题:
为什么先问这个问题，因为很多同学一开始没有接触过自动化，后来写了一些自动化用例之后，要么觉得高人一等，要么觉得一会就觉得没意思了，原因何在？因为写过自动化测试用例之后，要么觉得我技术很厉害了，基本可以把所有问题都解决了；要么马上一个疑问是这有技术含量吗？ 大量重复的代码，差不多的验证点，没有比设计测试用例和执行用例高级到多少,然后就有一种深深的幻灭的感觉？路在何方的问题又来了.
其实什么都可以是自动化,把原来重复做的事情用代码实现是自动化的一种；把类似的事情用代码实现也是自动化的一种；把
日常工作用代码实现也是自动化；这些自动化都是在做了一次之后再用代码去实现，如果用时髦一点的时候 machine learning/ai 去把
没做过的事情自动实现了,也是自动化. 我甚至可以说，社会生产力的进步都是每一个自动化的结果。
如果从这个角度看的，那么自动化能做的事情太多了，自动化测试也好，测试自动化也好，你可以做的事情有很多很多，多到你无法想像，问题是你有
能力做吗？ 那些写接口自动化，web ui 自动化的技能足够你去做更多的自动化吗？
自动化的目的大致就是为了不让人去做差不多的事情，减少重复劳动。用一样的方法做一样的事情是重复劳动，用不一样的方法重新再做一遍一样的事情也是重复劳动；如果目标是减少重复劳动，那么自动化测试就不能停在把测试自动化这一步，还有很多很多的事情可以做。但是坦白说，有哪些事情，我也说不出来，但是我觉得用代码再去实现一遍测试过用例，也是一种重复劳动，只是还没有能力把这件事情不重复做，但是相信一定有一些办法，有一些方面是可以解决的。
如果从上面的角度说，自动化的范围太广了，能做的事情太多了，会了接口自动化，UI 自动化算什么呢？
个人觉得技术包括的范围也很广，不止是写代码，不仅仅是测试用例代码化，这些都只是技术的一块。讨论起代码来兴致很高，觉得技术含量很高，讨论起业务来，没有一点情绪。但是如果仔细想想，像一个会计问题，一个交易问题，一个合规问题，这些是业务，但是不也是技术吗？这些只要是专业问题，这些就也是技术的一种，就像你专业写代码，这些不能理解为计算机科学的业务吗？如果是这样的话，那有什么非要区分业务和技术的？放在现实中来说，业务就是处理实际问题的技术，代码就是解决计算机如何运行的技术，不是吗？既然是这样的化，那么问问自己业务了解的透彻了，各个流程节点了解透彻了吗？技术实现和业务的匹配对应关系了解透彻了？代码说到底只是一个产品成功的一部分，还有很多很多其他问题需要解决,如果非要说代码能占到产品上线或者成功的多少比例？或许 50% 都不到. 代码本身不是目的，实际业务问题才是。不用非要拘泥与代码，各种方式解决了业务问题，也是很有技术含量的。
自动化测试只是测试的一种技术, 决定你有没有价值的不是你用了什么技术手段，是你解决了什么问题。代码，自动化测试也只是测试的一个侧面，想想日常工作中有多少事情要处理，如果眼里只有自动化测试，那么是不是失去了很多其他方面的锻炼和成长。问问自己把问题说清楚了吗，问问自己
做到了有效沟通吗，问问自己了解业务吗，问问自己能快速了解需求吗？自动化测试只是那么一小块，需要做的事情还有很多。
不过自动化测试如果你完全不会，那么现在的行情你肯定是不容易拿到高工资的；但是如果认为只有自动化测试，那么天花板也放在那边,也算给自己的一个提醒吧。