Last year, I wrote two blogs, one is about UI automation testing and one is about interface automation testing , both of which are the content of some basic methodology. This year, I transferred to specialize in automated testing, and I have made many new discoveries. Of course, I also encountered Lots of challenges.
Then I reopened a blog to talk about some recent challenges in automated testing, as well as my own solutions and some thoughts. . .
1. Test Scope
Whether it is functional testing, automation or performance testing, the first step is to clarify the test scope and requirements indicators. For automated testing, especially UI automation, not all function points are suitable for UI automation.
According to the specific business situation and the degree of project stability , it is the best solution to choose the combination of UI automation + API automation , and select the appropriate business point to design the targeted automation test scheme.
For what projects are suitable for UI automation, I have already analyzed it in the previous blog on UI automation testing . Here are a few points that I personally think are more suitable for UI automation:
①. The frequency of use is high, there are many abnormal judgments, and the most basic functions, such as user registration and login;
②. The core functions of the client, such as order center and member center;
③. Promotional activity pages, information display pages, etc.;
The concept of layered testing has also been introduced before. The layered testing pyramid is as follows:
In terms of effect, unit automation is the most profitable, but unit automation is too difficult for most automated testing beginners.
And at present, most of the small and medium-sized enterprises in China are not doing well in the development specifications and management of their own development. The probability of unit automation and realization is not optimistic in the short term.
Interface automation is currently the most cost-effective option.
The input-output ratio of UI automation is the lowest among the three models, but for increasingly complex and large-scale systems, UI automation can also reduce the workload of post-release smoke testing in some aspects.
2. System Architecture
For most functional testers, the system architecture does not need to be paid too much attention, but for automation or performance testers, the system architecture is a key point in the preliminary requirement analysis and technical solution selection and design.
For example, the programming language for system development, the type of database used, the communication service framework (if API automation is to be performed, the communication protocol used by the system cannot be bypassed), the deployment of application servers, etc., all need to be considered.
PS: In the company I am currently working for, the database uses the SQL server in the Microsoft Family Bucket Package, and my test script development language is python, which itself does not support SQL server and Oracle very well, resulting in the configuration of the database. At that time, I stepped on a lot of pits.
Of course, I finally solved this problem too. Regarding database support, it is only a small part of the problems I have encountered.
Another reason to be familiar with the system architecture is: for example, the development language used by the system is java, and the script development language used by the automated testers is also java, so the compatibility is very good, and if there are technical problems, you can also ask development colleagues to help solve them ,
In this way, it also saves a lot of time, and it is also a lot of help for your own technical improvement.
After being familiar with the system architecture, it is the best way to consider the design of automated test solutions and the selection of technical solutions. Do not use inherent methods to solve different problems, but use different technical solutions to solve different problems .
Attachment: python: use the pymmsql module to operate the SQL server database
3. Project situation
In this regard, I personally think that the analysis and communication should be used to confirm whether the system is suitable for automated testing. So, what kind of system is suitable for automated testing?
As shown in the figure above, I have roughly listed some characteristics of some projects suitable for automated testing. Of course, you do not need to have all of them. You only need to meet a few points before you can consider automated testing (the red line marked part is the basic condition) .
Of course, the project situation is not only these, there are other points that need to be considered, such as:
①, document management
Documents include requirements documents, test plans, test cases, test specifications, development specifications, database table design documents, interface documents, etc.
If the documentation is not perfect or even there is no corresponding documentation, then the automated testing work and the preparatory work need to invest more time and energy.
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环境如何部署？大家可以参考我之前的博客：linux环境：持续集成服务部署系列
七、测试策略
这里的策略，可以从下面几个角度来说：
1、任务拆分
确认测试范围和需求指标后，将自动化测试任务进行粒度更小的拆分，将工作内容所需时间精确到人/天的范围，按时完成任务，有问题不断调整；
2、优先级
任务拆分后，对任务进行优先级排序，通过评审沟通，确认先完成哪些任务，然后完成哪些等。
测试方案设计中，可以考虑分为第一期、第二期自动化测试任务，比如第一期实现自动化测试在一定程度上的覆盖率，先实现PC端的自动化测试，第二期可以考虑移动端的自动化测试覆盖，
第三期可以考虑自动化测试平台的开发等等。有目标有计划，根据项目变化和进度不断调整。
自动化任务的优先级排序，可以参考这几点：
①、用户使用频率越高的优先级应该最高；
②、系统基础功能应该排在优先级前列；
③、系统核心功能（比如支付、订单）应该较早的覆盖；
④、历史记录中生产出现问题叫多的功能点，应该考虑尽可能的覆盖；
3、工时预估
前期的准备工作（比如范围确认、需求分析、CI环境部署、测试方案设计、技术框架选型、文档整理等）完成后，需要针对具体的拆分后的任务进行工时预估，以确认工作阶段性的进展，
方便随时调整。工时预估需要考虑以下几点：
①、自动化测试人员个人的技术能力，特点；
②、项目情况、流程管理、系统架构的变化程度；
③、测试方案技术实现的难易程度；
八、解决问题
自动化测试道路上，全是坑！！！
工作中我们会遇到很多问题，有沟通问题、管理问题、技术难点、以及一些不可描述的问题，但只有想办法解决这些问题，我们才能在工作中不断提升，完成工作，获得该有的收获。
不同的企业存在不同的各种各样的问题，没有完美的公司，因此工作中，学会适应环境，融洽沟通，也是工作中必须的一项内容。
工作的本质就是拿钱消灾，解决问题，创造价值！！！
所以，良好的心态，坚持不懈的态度，解决问题的思路，是需要自动化测试童鞋所具备的。。。
以上就是我个人在自动化测试过程中遇到的一些问题，挑战，以及自己的一些思考和解决方法，希望能为看到的童鞋提供一定的思路和帮助，仅供参考。。。
当然，其中很多内容，拿出来单独说，也有很多值得探讨的地方，限于篇幅这里就不一一分析，后续会不断更新。。。