研发部门，仿佛都有一群“被遗忘的技术人”，就是测试工程师。很多人都觉得开发才是业务的推手，才有高技术含量，而测试的入门门槛比较低，工作中用到的技术有限，所做的事情价值体现也相对于没那么明显，甚至会产生一种假象，测试这个岗位能轻松被取代
我在和一些测试负责人聊天的时候，发现在小公司，测试岗位占比相对于开发仅7:1。其中90%的测试都是在做功能测试，对于能力和工资的提升，都是很大的挑战。在大型企业中，测试岗位对比开发比例能达到5:1。但是招聘的时候，企业都会看重测试的技术与潜力，有些公司简单的功能测试都会外包给其他公司。
从小公司到大厂，从传统的功能测试到自动化测试，测试开发、几乎成为所有软件测试人员的职业路径。根据boss直聘、拉勾网大数据分析，更多企业直接只招聘测试开发工程师，企业对测试人员的技术与在企业中的价值期待越来越高。阿里几乎所有软件测试人员都是测试开发岗位，尽早具备企业级的测试开发技术，进入一线大厂，享受高速发展的互联网行业带来的红利，是我辈测试工程人的生涯目标。
自动化测试发展趋势：
自动化测试现在越来越趋向于测试框架搭建、平台化。出发点是是致力于协同测试工作，提高效率，让更多人参与自动化的一个过程
在我看来，测试框架与平台化中，有一个关键点，就是把自动化测试的代码转换成为大家更容易懂的自然语言，才能让更多代码基础薄弱的测试工程师加入进来，才能达到平台化的目的。
做好测试工程师的关键点：
1.功能测试
需求分析能力，包括需求的背景、需求的商业价值
站在用户的角度，开发的角度思考需求的合理性
功能界面测试之前接口测试先行，更早的介入测试
2. 自动化测试
做好功能测试后我们需要编写自动化脚本来提高测试效率。但是自动化不能盲目的去做，先确定实际产品的需求
根据业务特点，选择自动化测试方案。产品是前后端分离的吗？业务比较注重用户交互还是数据完整性？
根据业务侧重点，确认自动化覆盖范围和粒度。要根据业务重点来确认。哪些业务流程是核心，必须覆盖?
根据自动化测试用例范围，选择实现框架和语言。
根据用例用途，选择执行策略。根据用途，是做上线前回归，还是触发式回归？需不需要做监控?
3. 搭建测试框架
自动化测试脚本编写完成后， 我们可以考虑搭建一套完整的框架，框架主要的作用就是帮助我们编写更加简单而且好维护的用例,让我们把主要精力放在测试用例的设计上，一个功能点如何去设计测试用例，尽可能的覆盖更多场景。
测试框架搭建技术架构：
Python+unittest+Yaml+PyMysql+Logging+Request+Selenium+appium+selenium+Allure+Pytest+jenkins+Docker搭建一套接口与UI自动化一体化测试框架
一站式实现单接口、关联接口、业务流接口自动化测试,POM模式、关键字驱动、数据驱动UI自动化测试、移动设备集群服务搭建、自动生成美观测试报告，集成jenkins持续集成，docker容器
一套好的测试框架，可以让团队其他同事不需要有很强的代码基础，就能编写自动化测试用例，维护测试用例，执行自动化用例，利于团队协作，起到提质保效的作用
传统功能测试人员转型到自动化和测试开发时都会遇到这些问题：
自学没有方向，迷茫，确定了方向也不知道如何突破
网上的文章、视频零散，碎片化的学习，没有系统的回到知识框架体系学习
代码基础薄弱，不理解代码的原理，设计思路，更不知道如何扩展，封装
没有自动化测试项目实战，没有大量的实战练习，学习效率低
简历没有特点点，面试的时候不自信，回答技术问题吞吞吐吐最多说了解
最后：
欢迎大家关注公众号程序员一凡，免费领取软件测试学习资源。还有我往期的大厂面试题视频精讲
