这篇关于自动化测试的文章，可能和你看到的大多数自动化的文章有所不同。我不是一位专职的自动化测试工程师，没有开发过自动化的工具或者框架，用的自动化的工具也不多，也没有做过开发，所以我讲不出那些现在很多人很看重的“很深”的东西。我也不想去讲某个流行的自动化的工具要怎么使用什么的，我觉得这些东西并不是我的，而且也是可以很容易获取的。
（测试即服务基本架构）
那么在自动化这个很大的领域来说，我是什么呢？ 我是自动化技术的使用者，要在团队中做自动化，还是脚本的编写者、管理者和运行者。 我想大多数测试朋友和我做的事情是一样的把。我想在这篇文章中，给大家分享一下我这些年实践自动化的经历，特别是那些不是那么成功的经历，希望能够给你带来一些思考和共鸣。
做自动化测试时会遇到以下一些难点：
-
定位元素：自动化测试需要通过代码操作页面上的各种元素，但有时候元素的定位比较困难，可能需要使用多种方法进行尝试和排查。
-
环境配置：自动化测试需要使用特定的工具和技术来实现，需要在不同的操作系统和浏览器中进行测试，因此需要进行一些复杂的环境配置和调试工作。
-
测试用例设计：自动化测试需要编写测试脚本，而测试脚本的编写需要考虑全面的测试场景和用例，需要对被测软件的功能和业务逻辑有深入的了解。
-
维护成本高：自动化测试需要持续维护和更新测试脚本，因为被测软件的变化可能会导致测试脚本失效，需要及时修复和更新测试脚本。这会带来一定的维护成本，尤其是对于大型和复杂的应用程序来说。
-
技术门槛：自动化测试需要掌握一定的编程技能和测试工具的使用，如果没有相关的背景和经验，学习和掌握这些技能可能需要花费较长的时间。
-
无法完全代替手工测试：自动化测试虽然可以提高测试效率，但它无法完全代替手工测试。有些场景和用例需要人工测试才能发现问题，因此需要进行手工测试和自动化测试的结合。
一、测试范围
无论是功能测试，还是自动化或者性能测试，第一步要做的，是明确测试范围和需求指标。对于自动化测试来说，特别是UI自动化，并不是所有的功能点都适合做UI自动化。
根据具体的业务情况和项目稳定程度，选择UI自动化+API自动化结合，选择合适的业务点来进行针对性的自动化测试方案设计，才是最佳方案。
二、系统架构
对大多数功能测试人员来说，系统架构不用太多关注，但对于自动化或者性能测试人员来说，系统架构是前期需求分析、技术方案选型设计的一个重点。
比如系统开发的编程语言，使用的数据库类型，通信服务框架（如果要进行API自动化，那么系统所采用的通信协议是绕不过去的一点），应用服务器的部署等，都是需要考虑的。
PS：我目前就职的这家企业，数据库使用的是微软全家桶套餐里面的SQL server，而我测试脚本开发语言是python，它本身对SQL server和Oracle的支持并不是很好，导致在数据库配置时候，踩了很多坑。
当然，我最后也解决了这个问题。关于数据库的支持问题，只是我遇到的问题里面的一个很小的部分。
熟悉系统架构的另一个原因是：比如系统采用的开发语言是java，自动化测试人员本身使用的脚本开发语言也是java，那么兼容性就是很好的，而且有技术问题，也可以找开发同事帮忙解决，
这样无形中也节省了很多时间，而且对自己的技术提升，也是不小的帮助。
熟悉了系统架构后，针对性的考虑自动化测试方案设计，技术方案选型，才是最好的方式，不要用固有的方式来解决不同的问题，而要用不同的技术方案解决不同的问题。
三、项目情况
关于这点，个人认为应该通过分析沟通来确认系统是否适合自动化测试工作。那么，什么样的系统适合进行自动化测试？
如上图所示，我大概罗列了一些适合进行自动化测试的项目所具备的一些特征，当然，不需要全部具备，只需要满足几点即可以考虑进行自动化测试（红色线条标注部分为基本的条件）。
当然，项目情况不仅仅是这些，还有其他的一些点，也是需要考虑的，比如：
①、文档管理
文档包括需求文档、测试方案、测试用例、测试规范、开发规范、数据库表设计文档、接口文档等。
如果文档不太完善甚至没有对应的文档，那么自动化测试工作，前期的准备工作就需要投入更多的时间和精力。
PS：比如要进行API自动化，但是没有接口文档，没有数据库表设计文档，那么关于API的接口说明，入参出参说明，这将带来很多附带的工作量，而文档数据的统计，又是一件很麻烦的事情。
有时候需要数据库确认接口对数据的影响，对应的数据库表字段，如果没有相关文档说明，那么自己整理以及和DBA沟通熟悉，就需要花费很多的时间和精力。
而很多企业对自动化的认识太片面，认为自动化可以替代人发现很多BUG，且追求短期的明显效果，而如果没有较完善的文档管理，那么自动化测试人员在前期的准备阶段花费的时间将影响
leader对个人能力和工作效率的怀疑，可以说这也是目前国内很多企业存在的弊端。
问题总归是要解决的，如果遇到这种类似的问题，那么在任务拆分和工时预估时候，可以将这些因素考虑进去，计算在个人工时中，并注明原因，在和leader甚至更高层评估中，抛出存在的问题，
推动问题的解决，这也是自动化测试人员的一种价值体现。
②、流程管理
项目的需求迭代是否稳定？从需求评审到开发、测试、发布上线是否有比较规范的流程？
如果需求迭代较快或者不稳定，那么自动化测试的脚本维护工作量将成倍增长；如果没有较好的流程管理，自动化工作的进展总会遇到很多不可描述的坑，沟通成本，变更成本等，还会影响到
测试方案的设计和规划。
在自动化测试中，需要针对性的熟悉了解这些问题点，做好应对的准备。自动化测试过程中，变化是最大的挑战！！！
四、“目标”一致
这里的“目标”，指的是个人对工作的目标设定和leader对自动化工作的期望，站的角度不同，理解不同，因此期望的结果不同。并不是要达成完全的一致，我这里想表达的是沟通的重要性。
个人针对系统情况，技术架构，测试范围的理解，对应的自动化测试方案设计和目标设定，应该与leader不断沟通，不断调整，达成一定程度上的一致，这样也能避免很多后续的麻烦。
当然，目标的设定，也应该根据具体的自动化测试需求，进行任务拆分，评审，不断调整，这是一个持续不断的调整的过程，需要耐心和坚持！
五、运行环境
自动化测试脚本开发，也需要基于不同的环境，而环境的选择，需要考虑不同的情况，下面一一列举说说我个人的思路：
1、SIT环境：
SIT环境，也称为系统集成环境，就是我们常说的测试环境，如果测试脚本是基于SIT环境开发调试，那么就需要SIT环境相对来说比较稳定。
但是大部分时候，SIT环境因为需要多次的提交测试，交叉影响较大，且SIT环境和生产环境还是有一定差异的（至于为什么，相信测试童鞋，都明白其中的痛点）。
2、UAT环境：
UAT环境，就是我们所说的验收环境，当然类似的，也有灰度环境等。UAT环境相对SIT环境来说，是比较稳定且和生产的一致性较高的，很适合进行自动化测试脚本开发和调试，以及日常的测试回归。
但自动化测试的作用又不限于这点，还可以进行发布后的生产冒烟，定时轮询测试等。
3、生产环境：
如果在生产环境进行测试脚本开发和调试，以及测试执行，那么就需要解决以下几点问题：
①、网络问题
一般我们的SIT和UAT环境都是部署在企业内部，网络环境也是走的内网，请求解析和外网有一定区别。在生产环境运行脚本进行回归冒烟的话，需要考虑真实的用户操作环境，不同的网络对测试结果影响。
而且测试脚本中，sleep最好能不用就不用（特别是UI自动化，强制等待容易带来很多不可控的变数）。
②、数据污染问题
生产环境进行自动化测试回归冒烟，需要对测试所产生的数据进行隔离处理，否则会导致业务受到影响，并且对生产的数据造成污染。常用的数据隔离方法如下：
测试白名单账号、网络标记、线程标记、测试数据落入对应的测试库，某些业务还可以使用MOCK对象和挡板。
关于数据隔离这几点，在性能测试中，也是需要考虑的一个重点，当然性能测试中也经常使用这些方法进行数据隔离，避免生产数据污染带来的影响。
六、服务部署
之前的博客做接口测试需要哪些技能有介绍过，自动化测试的核心是持续集成。那么一个独立的不受影响的持续集成环境是必须的。
持续集成环境也叫作CI环境，类似的还有CD环境（持续交付）。
这些应用，在敏捷测试中，应用的比较多，不过目前行业内，我个人了解到，越来越多的企业开始搭建持续集成环境，这样做的好处是很多的，比如：
①、版本迭代提测，可以通过CI服务一键提交，节省时间，提高效率；
②、如果需要造大量的测试数据，可以通过一个小脚本，只需要进行配置，点击启动按钮即可；
③、发布生产环境时候，可以通过CI服务自动化打包部署，避免了人手工打包配置时候的误操作等问题；
④、自动化测试脚本，部署在CI环境后，只需要点击启动，或者设置出发条件，定时任务的形式，来做到生产定时轮询，发布后冒烟等测试工作；
CI环境如何部署？大家可以参考我之前的博客
七、测试策略
这里的策略，可以从下面几个角度来说：
1、任务拆分
确认测试范围和需求指标后，将自动化测试任务进行粒度更小的拆分，将工作内容所需时间精确到人/天的范围，按时完成任务，有问题不断调整；
2、优先级
任务拆分后，对任务进行优先级排序，通过评审沟通，确认先完成哪些任务，然后完成哪些等。
测试方案设计中，可以考虑分为第一期、第二期自动化测试任务，比如第一期实现自动化测试在一定程度上的覆盖率，先实现PC端的自动化测试，第二期可以考虑移动端的自动化测试覆盖，
第三期可以考虑自动化测试平台的开发等等。有目标有计划，根据项目变化和进度不断调整。
自动化任务的优先级排序，可以参考这几点：
①、用户使用频率越高的优先级应该最高；
②、系统基础功能应该排在优先级前列；
③、系统核心功能（比如支付、订单）应该较早的覆盖；
④、历史记录中生产出现问题叫多的功能点，应该考虑尽可能的覆盖；
3、工时预估
前期的准备工作（比如范围确认、需求分析、CI环境部署、测试方案设计、技术框架选型、文档整理等）完成后，需要针对具体的拆分后的任务进行工时预估，以确认工作阶段性的进展，
方便随时调整。工时预估需要考虑以下几点：
①、自动化测试人员个人的技术能力，特点；
②、项目情况、流程管理、系统架构的变化程度；
③、测试方案技术实现的难易程度；
八、解决问题
自动化测试道路上，全是坑！！！
工作中我们会遇到很多问题，有沟通问题、管理问题、技术难点、以及一些不可描述的问题，但只有想办法解决这些问题，我们才能在工作中不断提升，完成工作，获得该有的收获。
不同的企业存在不同的各种各样的问题，没有完美的公司，因此工作中，学会适应环境，融洽沟通，也是工作中必须的一项内容。
工作的本质就是拿钱消灾，解决问题，创造价值！！！
所以，良好的心态，坚持不懈的态度，解决问题的思路，是需要自动化测试童鞋所具备的。。。
以上就是我个人在自动化测试过程中遇到的一些问题，挑战，以及自己的一些思考和解决方法，希望能为看到的童鞋提供一定的思路和帮助，仅供参考。。。
在这里，我想给想进阶的朋友们一点建议：很多时候，很多事情，并不像你想象中的那么简单，千万不要自认为简单而不愿意去做，很多东西只有你亲手去做了之后，才会发现事情并不像你最初想的那么简单。
其实自动化测试的知识点就那么多，面试问来问去还是那么点东西。所以面试没有其他的诀窍，只看你对这些知识点了解的程度。so，出去面试时先看看自己复习到了哪个阶段就好。
另特意为各位同学准备了一份13G的超实用干货自学资源，涉及的内容非常全面，涵盖功能测试、Linux数据库、Python编程语言，接口测试、UI自动化测试、性能测试......包括软件学习路线图，50多天的上课视频、16个突击实战项目（满足你对测试经验的需求），80余个软件测试用软件，37份测试文档，70个软件测试相关问题，40篇测试经验级文章，上千份测试真题分享，还有2023软件测试面试宝典，还有软件测试求职的各类精选简历，希望对大家有所帮助…
