有没有试过解决完一个问题或走过一个难关时会突然顿悟，原来是这样的——以前怎么没想到呢。然后再发现，自己好不容易顿悟出来的，却是别人的认知基础。

复盘下在技术工作上几个认知变化阶段：

第一阶段：对接口测试懵懂

1、工作第一、二年，做纯黑盒功能测试，对接口测试有种莫名的崇拜感，觉得是件很历害的事情
而且做接口测试肯定很难吧

慢慢熟悉业务下来，学会用了charles、postman工具辅助测试，原来接口测试其实也是功能测试
只是更关注后端的内容，关注数据流等，熟悉接口则可以辅助设计更全、效率更高的测试用例

第二阶段：对质量平台、测试开发 神圣化

2、工作第二、三年，对质量管理平台、测试开发感到很开阔眼界，在测试圈子里会代码，会脚本，是我向往但又不可达的。
因此在公司推行质量管理平台时，作为使用方很积极主动地参与进去了，还经常提出使用建议，和测开一起讨论平台上的功能设计等~最后平台搭建起来了，从接口文档API、接口用例设计、测试集、测试任务、生产拨测等，整套流程跑下来，质量平台其实也并没有想像中那么完美，使用成本 、调试成本 、协调沟通成本都在前期要投入较大的人力成本，并且测开脱离业务的话，就是一个纯开发了，并没有测试思维在的。

顿悟：质量平台也是一个服务于业务功能的一个测试工具，测开也要贴合实际业务才可打磨出适合公司的平台，才可达到提效的目的。而且在质量平台上做接口测试、测试集，也是做业务测试的一种，只是目前市场上对质量平台 、测试开发比较受欢迎，有相关经验的还可以获得加分。质量平台，除了能做自动化的工作，也是可以有度量数据生成或统计数据时地把测试工作可视化、可量化、可向管理层展示质量数据的平台。

第三阶段 对性能测试、脚本测试未知的恐惧

3、工作第四年，对脚本自动化测试、性能测试等也有种莫名的好奇和崇拜。
没做过脚本自动化测试，对自动化有感叹，脚本是什么，脚本怎么写的；
没做过性能测试 ，对性能也一知半解，做性能测试肯定很复杂

因为要换工作，虽然有质量平台的使用和推动设计经验能在简历上加分，但从来没用代码写过脚本，找自动化相关层面的工作时，不好找
然后去琢磨现在市场上使用的脚本框架，httprunner，python+request等，琢磨后发现在底层逻辑上，其实也是调起一个http请求，有header、url、requestbody、response、httpcode等几大组成，脚本的话也是一个工具，我要学和熟练的是这个工具里面的方法、函数、语法，然后用这些来调起我的请求~实现我接口测试的目的。
性能测试也如此，若先做个简单的接口性能测试，调通接口，给接口阶级加压，通过观察 TPS吞吐量、CPU使用率、响应时间找出最优点、施压最大点（压力最高点）。但跟随着业务的复杂度越高，性能方案、指标观察的难度也随之加大的。但首先先不要把性能测试过于神圣化，若要做性能测试，也可先了解性能测试相关工具、指标等，去做去找资料，起码先开始，遇到问题或不懂的学习调整，不断优化，结果应该也不会太差，不要被自己对未知的恐惧击退了。

顿悟：工具只是工具，不要为了用工具而用工具，更多的是考虑需要达到什么业务场景 ，达到这个业务场景需要哪些方面的考虑，然后再挑选一个适合的工具去琢磨，用的工具不重要，最终达到目的即可。

比如3~5人的团队，选用maven+jmeter 这个就可以达到接口测试自动化的目标的同时，也不影响正常的迭代业务测试，上手成本也低，先不用花太多精力去学习各种语言语法等~ 先把重复的手工测试场景用自动化先跑起来，省下的时间再去研究别的~

现阶段 不给自己设限，不妄自菲薄。

往前看的同时，要认清自身能力，低头做事
通过这几年在测试岗位上的熟悉，虽没有其他人那么优秀，但终于也知道了自己现阶段要提升和要做的是什么了，技术基础不可丢，要踏实扎根下去学，借助IDO老徐创建的21天打卡平台 把基础补上来，保持学习的习惯才更重要。

最后

从固化思维转变为目标思维，对技术保持敬畏心、谦卑学习的同时，也不过于神圣化，不对未接触过的技术抗拒，而更应该主动去研究、琢磨是否对提升自己工作效率有帮助。

共勉~~