首先要对自动化测试形成正确的认知：自动化测试的目的不单纯是为了减少或者替代手工测试，而是为了测试人员能够做更多更有意义的测试（也包含手工测试）。如何围绕产品质量提高测试效率，不仅仅是把手工用例转变为自动化用例这么片面，其中包含了自动化测试实施策略、框架的选型、自动化的可维护性、可扩展性、可持续性等等方面的诸多考虑，比如，如何有效解决自动化代码量随着用例数量的增加而增长的问题？一个难以维护、扩展的自动化测试实践，是失败的，或者软件产品生命周期的不同阶段，自动化测试实施的策略有何不同？“围绕产品质量，提升测试效率，通过不断的技术创新、应用，不断提高测试整体流程能力（单位时间能够提供多少服务）。
如何进行前端自动化测试？
首先来说，前端自动化测试在实际应用中还是较少的！为什么这样讲呢？我们得先了解自动化测试是为了解决什么问题的，以及自动化测试的局限性。自动化测试的目的很简单，就是解放人力，将一些重复性核验工作交给程序自动去检测。但问题来了，对于一般后端功能来说，自动化测试是比较容易实施的。但对于前端来说，自动化的应用场景还是较少的。
我们知道，如果是测试人员对前端页面进行测试，主要测试点有：界面排版布局是否和效果图一致；在不同浏览器下的兼容性；交互效果是否达到预期；页面性能分析等。从上面来看，界面布局和兼容性人工测试都比较难，自动化实施起来复杂度也很高。从另外一方面来看，前端页面改动的可能性较大，所以UED方面的确不适合实施自动化测试，成本太高！那是不是说前端领域就真的没法实施自动化测试了呢？其实也不是，比如我们将一些偏底层性的核验交给程序来自动化测试。
比如用程序来实现：监测前端页面是否存在死链；监测前端页面图片尺寸是否过大，需要裁剪；监测前端页面是否抛出了JS错误等 ...前端自动化需要了解 Selenium ，同时你需要掌握一种编程语言，如Java、Python等。利用Selenium可以实现以下功能：操作浏览器，它可以按照脚本代码对页面做输入、点击、验证提交等操作，和真实用户操作流程一样；可以对页面DOM进行操作；可以执行JS；如果有兴趣，可以去GitHub上搜索一下：checkConsoleError 、check404 ，这两个小工具是我用Selenium写的前端自动化测试小工具。
如何提高自动化测试的稳定性和可维护性？
大致如果现在已经有了自动化测试所应用的框架或者用例，遇到了稳定性或可维护性的问题，这个优化成本相对很高，因为此时考虑这个问题有些滞后了，要想提高稳定性和可维护性的建议，需要提供更详细的信息，比如现有的自动化测试框架设计及系统业务大致场景，否则不知从何说起。若此时还没有开展自动化测试，或者准备开展自动化测试，这里可以提一些建议，题主可视情况采纳。
首先要对自动化测试形成正确的认知：自动化测试的目的不单纯是为了减少或者替代手工测试，而是为了测试人员能够做更多更有意义的测试（也包含手工测试）。自动化测试是用来验证以前能够正常工作的功能是否依旧可以正常工作。不是为了自动化而自动化，而是为了实现一套解决方案来解决问题从而开展某种自动化 ，肯定是解决某些测试过程中的问题而引入自动化测试。
其次需要考虑系统或业务功能是否适合开展自动化测试IT行业甚至其它行业的产品都是能够做到自动化的，所以是否自动化不是能与不能的问题，而是是否存在合适的时间或阶段以及合适方式去做的问题，实施自动化测试之前需要对产品开发过程进行分析，通常需要同时满足以下条件：软件需求变动不频繁(超过10%的变动是频繁变动，当然10%不是一个定值)项目周期足够长自动化测试用例可重复使用目前主流的自动化测试框架或工具首先我们需要明白自动化测试框架更倾向于一种设计思想 ，这种思想指导工具的使用或者自研开发，并且不是只能使用仅仅一种框架，结合被测系统本身特性一般是选择多种测试框架的组合，来满足测试和设计需求(开发、维护角度)。
录制回放测试框架录制回放测试框架所采用的原理是通过录制应用程序产生的线性脚本进行回放从而达到自动化测试的目的。优点：对测试人员测试开发能力要求最低，通过录制就可以得到所需脚本。缺点：一般不具有逻辑判断的能力 ，可维护性差 ，效率低。适应场景：不推荐，传统的UI自动化测试逐步弱化。关于U自动化，一定要清楚 被测系统是否满足开展自动化的条件，在被测系统变动频繁的项目中，开展UI自动化无疑是挖了一个很大的坑，其后期维护工作足以让大心疲惫，被迫放弃自动化测试。
测试库构架框架(The Test Library Architecture Framework )测试库构架框架的核心思想可以概括为系统功能操作和业务逻辑的解耦。将所有的针对测试系统支持的功能操作封装在测试库中，测试脚本调用测试库的同时传递外部的测试数据，测试库的编写由自动化测试发工程编写(可以不懂业务)，负责控件的变更和维护， 测试脚本的编写可由对业务比较掌握的自动化测试开发工程编写，负责业务逻辑、测试数据的变更和维护。
优点：被测试系统无论是哪层发生变化(代码层或业务层等)，只需要相应的人员进行变更维护即可。缺点：变更引起的维护工作同时附加在自动化测试开发工程师与业务测试人员身上，维护代码建级大。适应场景：基于各种自动化开展方式(基于工具如Jemet或不基于工具的自研研发 持续集成)一般都会应用该框架。数据驱动的自动化测试框架( The Data-Driven Testing Framework )数据驱动的核心思想可以概括为数据(测试数据、配置数据)与代码解耦。
该种框架的原理是采用了数据驱动脚本进行测试，数据驱动脚本是将数据输入存储在独立的数据文件中，脚本只存代码，运行时脚本的输入直接从文件中读取，如此相同的脚本(代码模版)可以运行于不同的测试用例中，实现了代码与数据的分离。优点：对于业务人员由面向代码的开发转换为面向配置的设计(参数组合设计)， 降低了开发难度与开发成本，同时提高了测试用例的易扩展性，可以快速扩展相似测试，实现了自动化代码不随用例的增长而增缺点：测试脚本的维护由自动化测试开发工程师负责，要求懂自动化编程和业务逻辑，初始测试脚本设计成本较大，具有一定局限性 (针对相同的测试内容并具有相同的测试逻辑).适用场景：更适应于测试内容测试逻相重复度高，被测对象对测试用例易扩展性、可复用性要求较高的场景。
关键字或表驱动的自动化测试框架(The Keyword-Driven or Table-Driven Testing Framework )关键字驱动是对数据驱动的逻相扩展，它的核心思想可以概括为数据代码流程(逻辑)解耦，同时完成了代码与测试描述(针对被测对象的测试描述)的映射。该框架的原理是基于数据驱动的基础上，完成了对被测对象的拆分、抽象、 封装使之映射成个个“关键词” (测试描述)，编写测试用例时，仅需要对关键词进行组合 ，即可完成不同场景的测试用例开发。
优点:对于业务手工测试人员，由面向代码或配置的开发转化为面向自然语言(测试描述)的开发，最大程度的降低了开发难度与维护成本，同时提高了测试用例的易扩展性、易组织性，实现了自动化代码不随用例的增长而增多。缺点:对测试人员的测试开发能力以及业务了解程度要求很高。适用场景:被测对象包含复杂业务流程(逻辑)，当然复杂的能做简单的更ok。
测试框架选择仅仅从实现上讲，很多种自动化测试框架(或工具)都可以开展自动化，或者说任意一种也不是很勉强， 所以在自动化框架(或工具)的选择上，不是人为核心的(我会什么， 或有哪种框架比较好掌握)，而是以被测对象为本来选择自动化框架(或工具)。两个场景：场景一:多维度的查询功能，类似于某宝商品的筛选查询。
场景二:较为复杂的业务流程，类似于某逐级审批流程系统。思考:关于这两种场景，我们如何选择自动化测试框架(或工具) ?场景一特点:类似于某宝WEB端， 不同关键词(衣服、足球)的多维度(品牌、发货地)组合查询，查询逻辑单一、复用性强。推荐使用:测试库架构框架 数据驱动框架。场景二特点:类似于审批申请流程，包含复杂的业务逻辑和多用户角色。
推荐使用:测试库构架框架 数据驱动框架(配置解耦） 关键词驱动框架测试用例开发两个注意规范性和契合性：开发规范性以及开发过程一定要与其自动化测试框架思想相契合，比加选择测试库构架框架，那么在用倒编写的时候，发现还有需要进行封装的功能操作时，需要在测试库中开发，在用例中调用，而不是随手在用例中进行开发。
开发成本和维护成本：开发设计一定要考虑开发成本和维护成本问题，开发成本决定效率，维护成本决定这个自动化能否长明有效的运行下去，同时注意关于成本问题的解决思路是在对被则对象进行有效覆盖的前提下，通过框架设计和优化方案来降低成本，而不是靠少做一些做的粗一些来降低成本。在自动化测试开展的过程中若注意上述的内容并加以实施，自动化测试的稳定性、可扩展性、可维护性可以得到进一步的保障。
软件测试中手工测试重要还是自动化测试重要？
这个问题好像好多人都问过。手工测试、自动化测试哪个更重要❓ 答：都重要，不存在孰轻孰重的问题。感觉可以考虑，不同场景或阶段下选择哪种方式当时更适合？手工测试和自动化测试都基于对用户需求、功能需求的正确理解，对测试对象进行充分测试设计的基础上开展的。按照测试阶段或者功能稳定程度来划分，手工测试更适合软件模块、集成测试阶段或者功能稳定性低（缺陷多、变动快等），如果这个时候开展自动化会引入过多的自动化开发、维护成本。
自动化测试更适合在产品迭代后期或者功能相对稳定的时候开展，通常应用于回归测试场景下（关注我后续的文章，会有关于自动化前移的探讨）。按照不同的测试对象来划分，如测试百万级的元数据迁移、汇聚处理时，由于数据的多样性，很难通过用手工测试保障质量，自然而然需要考虑自动化的方式提高测试效率，进而保障测试质量。时间有限的情况下，使用自动化尽可能覆盖重复性高的操作。
同时自动化并不是生搬硬套，根据不同的业务场景选择合适的自动化框架十分重要，可以有效的提高测试开发效率和降低维护成本。如，对于一个含有强流程的业务模块，采用关键字驱动测试框架更利于用例的组织和维护。通常常用的自动化框架还包含数据驱动测试框架、模块化测试框架。自动化测试的类型也要因地制宜，如ui自动化、接口自动化等等，也需要结合业务特点、底层架构选择合适的类型开展。
之前一直是做功能测试，现在离职找工作发现都是自动化测试，手动测试是被淘汰了吗？
之前写过的一篇文章，希望对你有所帮助。 软件测试行业供需现状 随着敏捷、devops等模式的引入以及数据治理、人工智能应用的发展，软件交付周期逐渐缩短，技术复杂度不断提升对测试人员提出了越来越高的要求。因此，近些年对校招、社招人员的要求也是在不断提高的，一方面响应基础功能需求的手工测试人员基本饱和，另一方面懂测试的测试开发岗位面试达标者比例过低。
通过近两年校招来看，本科应届生中通过参加机构培训来提高测试能力的比例逐渐上升，但由于机构培训内容全面性和深度以及技术的时效性与行业实际要求匹配度较低。硕士应届生中女生应聘者较多，对于社招相当一部分人员只是在公司参与测试工具、平台部分代码开发工作，重复开发情况居多，或者仅仅是基于现有测试平台、框架进行使用（外包公司），同时并不关注当前行业内测试技术的发展，对测试开发的价值体现也并不清晰，几乎二三十名应聘者中，一般只有一两个达标。
基于当前现状，进行一定的周期入职培训是有必要的，旨在提高测试人员基础水平，统一测试的基准认知，主要面向校招人员，提供相关专项测试技术的岗前培训。 软件测试行业的发展现状之前写过《2018年度软件测试行业现状报告》的解读以及对软件测试左移与右移思考的文章，其中总结了以下几点： 测试人员对需求分析的投入在逐渐增大，同时测试人员逐渐开始注重客户问题的分析，更关注用户体验和用户反馈。
敏捷和类敏捷型项目已经占到了已经极高的百分比，而DevOps模式的使用已经持续数年稳定增长，DevOps正在成为软件交付的最佳模式 ， 同时我们发现瀑布或类瀑布开发模式比重逐渐降低。 较去年，自动化测试技术比例基本保持稳定且处在一个高占比的状态。不了解、不使用自动化的越来越少。同时令人兴奋的是，发现越来越多的测试人员将自动化技术应用于日志和数据分析、综合监测，质量运营。
敏捷及DevOps模式的应用，对测试人员提出了不同于以往的要求（以前测试基本上都在开发阶段之后和产品上线之前完成），使得测试人员在开发阶段之前加大了对需求分析等测试分析和设计（测试左移）、同时不断提高自动化测试技术的投入和应用、促使测试技术多样化（如，日志和数据分析、综合质量运营监测）发展（测试右移）。
同时，敏捷一直强调“团队为质量负责”，测试不再是测试人员的专属，这里我们需要重新思考下，质量由整个团队负责，那么测试的价值如何更好的体现——如何提高测试效率。 DevOps模式更是对测试、尤其是自动化测试、编码能力提出了更高的要求。功能测试人员发展的局限性 从实习算起，大概做了将近两年的功能测试，一方面功能测试的深度、广度的潜在延伸性很强，另一方面想突破传统功能测试思维的确很难。
在软件测试左移的思想中，测试人员对需求分析的投入在逐渐增大，这里的难点就是如何突破传统认知的测试设计深度、广度问题。大多数功能测试人员，半年工作经验可以基本的了解软件测试相关流程，但因专注于功能需求的分析、验证、容易出现忽略功能需求背后的业务需求、用户需求的情况，对产品整体的质量把握不到位，容易出现得此失彼的问题，也能难将功能测试做成一个闭环。
功能测试的深度和广度的延伸性不仅仅体现了功能需求本身，还包括产品架构设计、开发技术栈、服务内容与模式、用户群体等等。自动化测试方向认知的片面性谈到自动化测试，很多人认为这是测试人员职业发展的一个方向，但对这个方向的认识并不都是充分的，比如，当面试的时候问到自己设计的自动化测试用例的优缺点，自动化测试框架选择的合理性体现在哪里时，很难有清晰的回答。
这些情况在现在的面试过程中很常见，而如果仅仅是这样的话，只是依赖一些现成的工具、框架来进行用例的转化，这还无法说明具备自动化测试能力，只能说明会使用了某些工具。如何围绕产品质量提高测试效率，不仅仅是把手工用例转变为自动化用例这么片面，其中还包含了自动化测试实施策略、框架的选型、自动化的可维护性、可扩展性、可持续性等等方面的诸多考虑，比如，如何有效解决自动化代码量随着用例数量的增加而增长的问题？一个难以维护、扩展的自动化测试实践，是失败的，或者软件产品生命周期的不同阶段，自动化测试实施的策略有何不同？“围绕产品质量，提升测试效率，通过不断的技术创新、应用，不断提高测试整体流程能力（单位时间能够提供多少服务）。
”这是我之前对测试开发岗位的描述，其中自动化测试工程师作为其中一角色同样适用，那么关于效率提升的目的是什么呢？假如一个测试团队的人数相对固定、测试时间充足，他提升效率的目的又是什么呢？从这种角度来思考，个人认为测试效率提升的根本意义在于： 做更多的有价值的测试（更深入的需求分析、测试设计或者对测试右移的投入） 实现真正的缩减成本（减少或抽调人力投入） 拥抱变化，适应开发模式的转变，比如类敏捷、devops模式下的频繁迭代/持续部署。
除此之外，测试人员具备代码能力，的确是目前未来测试行业的基础要求。资深测试专家、测试架构师稀缺 测试能力分层建设，旨在培养专项的测试技术人才，不断扩展专项测试技术的深度。这是很多公司人员组织架构或人员培养的一种方式，我们部门也在尝试测试能力分层建设。这种建设的背后还有另一个隐藏的原因：一专多能的测试技术人才稀缺或者培养一专多能的测试人才成本非常高。
文章TAG：手工测试和自动化测试如何进行有效的结合 如何将手工测试和自动化测试相互结合
