软件测试需要学什么？
自动化是一个老生常谈的话题，也是一个软件领域非常有技术广度和技术深度的活动，特别是在大型软件的生命周期上。
个人觉得开展自动化测试的难度不亚于传统意义上的软件开发。
从产品角度来看：质量领域本身要求从业人员要全面了解产品、有全局风险意识，例如：产品需求/设计阶段能否发现设计缺陷、产品测试阶段能否发现深层次的bug、产品运维阶段能否制定良好的灰度策略、快速发现、定位线上问题，甚至如何做好新/老系统线上过渡切换等等，这里面都有自动化测试可发挥的空间。
从技术的广度和深度来看：
- 从技术广度来说，不同的技术领域的质量保障需要使用不同的技术（这些技术领域都有一些代表性的工具，但不一定能完全满足实际的项目自动化测试需求），例如有做JUnit接口测试的、有做Web/App/桌面客户端 UI测试的、有做性能测试的、有做用户体验测试的、有做AI算法测试的、有做IoT的、有做压测的、有做各种专项（如兼容性、安全、多媒体、网络）测试的等等，实在太多了......。如果考虑到测试工具本身的可用性、系统性，除知道使用工具以外，可能还需要掌握一些基础开发技能，例如：JAVA/Node/Python后台、React/H5前端、或者Android/IOS客户端；
- 从技术深度来说，想通过开发软件去测试另一个软件是否正常，本身就是一个很具挑战的事情，特别是在黑盒的状态下，举个例子，试想你能否开发一款自动化测试工具能够模拟人的意识形态，它能够对当前多如牛毛的App开展自动化测试，很多人此时想起了Monkey、Appium、AirTest或者Applitools，其实这远远不够，因为目前并不具备解决场景构建甚至自我发现缺陷的能力，简单来说，还不具备“认知”App的能力。这个想法不是天方夜谭，事实上很多人正在往这个方向努力ing。自动化测试远远不只是在一个已有的工具上开发自己的脚本，达到所谓的一个通过率或覆盖率，更核心是思考如何在软件生命周期各个阶段提升产品研发效能及稳定性甚至用户体验。
技术新人如何学习自动化测试
首先简单了解下QA在软件研发迭代过程中的定位
传统软件使用较多的是瀑布模型。测试人员的活动区域是有限的，活动的时间区域主要是提测至上线前。
传统瀑布模型中，QA发挥的空间比较有限，质量压力都集中在测试阶段。随着软件规模的扩大、部门职能的划分、敏捷迭代模式的发展，互联网或者大型软件项目绝大部分演变成了DevOps：
DevOps是软件文化上的一次飞跃，它强调产品、开发、测试、交付、运维各个环节的沟通合作，将敏捷的方式延伸到整个产品。从QA的角度也有了测试左移和测试右移的概念。
测试左移：
测试左移的思想是需求阶段、开发架构设计阶段或是未到系统测试或集成测试前就进行测试，目标是降低时间成本、减少风险，从用户角度描述产品行为、从技术角度建立好开发与产品需求的连接，防止产品设计上的雷或缺陷。这有利于减少无效代码的开发、以投入更好的时间在正确的产品上。也可以在代码编写阶段进行单元测试或覆盖率统计。
日常工作中，QA都期望只对修改的代码或受连带影响功能/需求进行测试，从而减少重复回归的工作量，即“精准测试”。但是实际上，往往得到开发同学的回复要么是“最好全回归或者核心流程全回归”，要么“是没关系的，就回归下A功能就好”（实际可能已经带雷上线了）。设想如果能够有个工具能够帮我们将需求与相关的代码调用栈联系起来，在相关代码依赖变动时都能够自动评估有效回归范围，可能是“精准测试”实现的一个方向（我相信业界应该已经有人在做了）。
测试右移：
测试右移简单来说是指产品上线以后开展的一系列质量活动。事实证明，在快速迭代以及产品复杂化、多样化的今天，几乎不可能做到0缺陷上线，当然，对硬件产品或涉及资金的产品而言，存在缺陷可能意味着产品召回或是资损，会给公司带来巨大损失，对于某些互联网产品而言，由于产品发布的天然优势，一般具备热修复、热发布能力，因此在时间和产品质量维度，可能会更强调快速上线，比如facebook就提倡灰度快速上线。因而如何监控产品的稳定性、第一时间发现线上用户问题、用户反馈并使问题及时得到解决、如何了解更好的用户需求（如AB测试）变成了QA在测试右移活动中的关注点。期间也有大量自动化测试可发挥的空间。
由此可见，QA发挥的空间是在整个软件的生命周期的，DevOps的理念也强调流程自动化，我理解的在各个阶段能够代替人工工作、提升测试效率的都可以称之为自动化测试。这也反过来要求QA具备更高的软件产品流程/风险意识以及更强的自动化理念、编码落地实践能力。
QA做自动化测试应该掌握哪些技术？
说到具体的技术，其它回复也有提到，感觉整体太散了，初学者可能有点摸不到边，不知从哪里开始，个人建议顺序是这样的：
那让我们先修炼下最基本的内功吧！
软件工程&测试理论基础
各个公司产品形态迥异，因此也制定了不同的软件研发流程。大多数大公司都设置有运营、产品、视觉/交互、开发、测试、运维、技术支持、客服等岗位，应当明白各个角色的职责，以及了解整个产品运转的逻辑。至少应该了解所在公司的研发流程以及当前主流的研发流程（如敏捷开发Scrum），并在项目过程中积极思考，形成自身的软件意识与理念。在校的同学可以多在网上找找资料，有个大概了解。个人理解，软件工程本身是一个浩大的工程，也在日新月异不断地向前发展，它需要长期积累、不断修炼内功，并在实际项目中实践驱动，从业2年、5年、10年、20年都会有不同层次/深度的理解，自动化测试亦是如此。
关于测试理论基础这里不赘述了，网上资料一大把，搜白盒/黑盒、等价类、边界值等关键字就可以找到。
通用计算机基础（其实就是计算机专业相关的大学课程）
建议至少掌握一门编程语言（C/C++/Java/Python，推荐Python，学习成本相对更简单一些）。相比于特定需求/领域的开发人员来说，测试人员对编码技术要求相对会弱化一些（当然并不意味着不需要极客精神、架构思想）。涉及到Web、桌面GUI、Android/iOS的可以到具体应用再学习相应的框架。
- 掌握基本的数据结构以及在具体程序语言中的应用，例如：list、map。
- 掌握面向对象程序设计的基本思想。
- 掌握一种代码管理工具，如git、svn。
- 掌握linux的使用及基本命令使用，如：cp、grep、vi/vim等。
- 掌握关系数据库的基本理论和关系数据库（如MySQL）SQL基本使用、NoSQL（如redis）的基本使用。
- 掌握基础的计算机网络理论，如TCP/UDP协议、IP划分。
接下来，我们就需要站在巨人的肩膀上了。这部分可以根据实际需要进行学习，涉及的内容实在太多了，我这里主要从App自动化测试的角度给出一些工具使用、方向学习建议，大家搜关键字应该都能找到一些资料。
服务端：
- 白盒单元测试：Junit(Java)、unittest(Python)、gtest(C++)
- http接口测试：Postman
- 抓包工具：Charles、Wireshark
- 压测：Jmeter，在大厂里面都会有特定的一些写好的工具可以使用。
- 链路依赖分析：梳理应用间的依赖关系，提供压测模型，大厂里面也有一些工具可以使用。
- 监控&日志分析：应用稳定性监控，如qps、rt，服务器负载、cpu监控等。日志分析这块可以做一些基于规则的错误日志监控、甚至基于AI的方式（如：机器学习）对日志大数据进行聚类、问题分析/定位。
客户端（Android/iOS/H5）：
事实上，即使非常熟练掌握了以上工具，也无法达到完全释放人力的目的，甚至在自动化实践过程中会存在各种各样的问题（例如如何针对具体的场景设计自动化用例、提升覆盖率、如何维护/构造测试数据、如何进行精确校验、如何提高执行稳定性、如何缩短执行时长、如何监控线上问题等等）。
这就需要我们更加深度的去了解产品形态、在已有工具解决不了问题时，怎么去用创新的思维看待各个阶段面临的问题、甚至创造工具，这已经不仅仅只是技术本身的问题了，而是如何去挖掘、思考问题、如何去运用技术的问题了。实际上自动化测试可以归纳为如下几个阶段，这也是近2年智能化测试的研究方向：
另外，个人觉得目前市面上对自动化测试其实是存在的一些误区的：
- 认为自动化测试无所不能，只要有自动化，人工可以完全释放。对于复杂产品，目前来看，这几乎是不可能的。因此，目前市面上并没有类似“统一宇宙理论”的自动化测试工具。
- 自动化测试没技术含量（测试没开发有前途），如果仅仅是对工具使用，没有创造力，那确实没有什么太高的技术含量。但是如果是在DevOps各个阶段发挥最大价值，个人认为比传统意义的开发岗位难度更高，并且可发挥空间更大。举个例子，能否创造一种工具，能够根据视觉稿或者App UI自动生成测试用例（啊？怎么可能，试想下人是怎么设计用例的，得益于AI技术的发展，这完全有可能，目前也有一些根据视觉稿生成前端代码的工具了）。我不觉得这是一个没技术含量或没有价值的自动化测试。近些年，质量领域的大会越来越多，大家也可以关注关注。例如QCon、MTSC、TICA、Tid等等。
- 自动化覆盖率至高无上。这部分往往来自人们对自动化测试过高的期望，为了提升覆盖率，未考虑好ROI，以至于南辕北辙，入不敷出。著名的测试金字塔给了最好的解释。
- 人云亦云，泛而不专。相比于开发人员，个人认为QA开展自动化测试需要掌握的技术知识可能会更广泛，例如：开发人员可能专注于Android、iOS或者Java后端，亦或是某类AI算法，即对开发人员的要求是对某一技术掌握的足够深入，对QA来说，精力有限的情况下，可能又要懂点服务端、又要懂点客户端、又要懂点算法等等。再加上各种产品、技术形态不一，也衍生出了形形色色的工具和研究方向，初学者容易受到误导，不知所措。自动化测试和开发角色一样，也是一个逐步积累、实践的过程。
关于自动化测试确实有非常多的内容可以交流、学习，篇幅有限，先写到这里啦。以上内容是个人对自动化测一些理解，当然，如果继续往上走，到管理者，需要掌握的知识也远不止这些了。
