我们的愿景

我们的愿景

我们希望我们自己的自动化做成啥样？我这边简单总结了四个愿景。

成本低

• 新增Case成本低：我们编写一个新的用户场景，不希望是一个非常复杂的过程；
• 维护Case成本低：低成本，我们主要考虑如何去减少因为业务等变化，带来的自动化case的维护量；

• 使用方便：使用方便我们尽可能使用平台化，通用化的技术，降低学习成本；

  收益高

• 执行时间短：开发提交代码，越早给反馈越好，甚至做到5分钟内给反馈，所以我们希望我们的自动化脚本特别是UI自动化脚本，不要一跑起来要几个小时。

• 使用频率高：我们经常讲，把重复的机械性的工作，用自动化去实现，而且越需要重复运行的case，实现自动化后它带来的收益就越高。我们的自动化测试case，不是一次性的脚本，也不是特定情况下才能运行的脚本，而是希望随时随地都可以运行起来，并快速的获取到反馈，

  场景全

• 覆盖核心用例：这是最基础要求了，不多说，核心用例必须能覆盖。

• 支持复杂测试场景：我们很多场景非常复杂，例如下单场景，咖啡师接单、制作场景，配送等场景等等，我们希望都能自动化实现。

• 支持多环境运行：我们的自动化测试，肯定不能一个环境一套代码，我们需要在不对代码做任何变更的情况下，使我们的自动化用例脚本支持多环境运行。

  稳定性高

• 稳定的执行环境和测试环境：自动化测试不仅仅需要稳定的被测应用环境，也需要稳定跑脚本环境，特别是UI自动化测试，例如通过Selenium Grid 做分发跑脚本，别因为脚本忘了关闭浏览器而照成测试机资源耗尽，无法正常运行脚本。

• 较少Case出现非bug的失败率：这个怎么理解，说白就是自动化用例运行失败了，不要是自己自动化测试脚本问题而造成。 这个我相信做过自动化测试的同学都有这个苦恼，今天跑测试通过，明天跑可能就挂，以为是开发bug，一查，咦。。。自己自动化测试脚本问题。

自动化分层测试思想

ok 我们知道了自动化的愿景，那么我开始讲讲为了达到这些愿景，我们自动化测试需要做哪些努力。
第一 我们需要有自动化测试分层思想，非常明确什么样的自动化我们需要做多，什么样的自动化我们要少做，所以我们看看非常流行的金字塔模型。

分层自动化测试

金字塔模型

以往大家从书上或者从博客文章看到过大多是正的金字塔模型也就是绿色部分，它无非就建议我们多做底层自动化测试，少做顶层的自动化测试。那我们今天我们以自动化测试的愿景为出发点，从成本、收益、场景、稳定性来分析下这个金字塔模型是否真的合理。

成本低

• 越底层，投入的成本越高。只从自动化测试前期投入的成本上看，越底层是越高的，既然前期成本投入高那是不是就得少做底层（蓝色）；
• 越底层，bug修复的成本越低。bug越早发现，修复的成本自然就越低。bug修复成本低，那底层是不是得多做（绿色）；

• 越底层，后期自动化测试脚本维护的成本越低。单元测试用例大多居于一个函数的用例，那底层一个方法的变动，可能只影响一个单元测试用例，但可能影响一片UI自动化测试用例，所以底层是不是得多做（绿色）；

  收益高

• 越底层，执行效率越高。这不用过多介绍吧，UI自动化的执行速度是最慢的，经常需要等待页面元素加载，所以从这点出发是不是就得多做底层（绿色）

• 越底层，执行的频率越频繁。 单元测试可以在服务还未部署前就可以被频繁的运行，用以校验开发的代码逻辑是否准确，所以底层执行最频繁，多做底层（绿色）

  场景全

• 越底层，对多环境的支持越简单，本身开发的业务代码就会配置不同的环境变量等，所以多做底层（绿色）

• 越底层，用例覆盖率越高。 如果我们按代码覆盖率来作为自动化测试覆盖率的统计的话，越底层越容易提高覆盖率。有些分支场景是很难走UI测试能进入的。（绿色）

• 越底层，离真实用户场景越远。除了刚说的单元测试属于代码未部署前的测试，而用户的环境肯定是集成部署后的环境，那从顶层越容易从用户的角度去模拟用户场景。（蓝色）

  高稳定性

• 越底层，越稳定。UI层自动化测试受很多其他因素干扰，如网络，浏览器等。（绿色）

这一看绿色部分的金字塔占有更多好处，这也符合为啥目前更多的敏捷团队主推金字塔分层测试模型思想，多做单元测试，少做UI自动化测试，而且目前我们公司也在强调单元测试的覆盖率。
但我们刚一直拿最底层和最顶层对比，中间的service层好像很悠哉。但不管从成本、收益、稳定性、全场景考虑，Service层都是最突出的，但也都能接受，不是最好的选择但也不是最差的选择，而且在目前测试很难介入做单元测试的情况下，对于测试同学更多的应该关注单元层之上的Service层。所以我们把金字塔模型按覆盖率大小重新画下，就有了橄榄模型。

橄榄模型

这个图大家应该也在我之前的分享中见过，那我这里也不去细讲Service相对于UI层和Unit层的优势，而只是结合金字塔模型和愿景以及目前公司情况给出一个比较合理的覆盖率比率。
UI自动化测试：5%~10%左右的核心流程用例覆盖，这个覆盖率是基于用例库。
Service（API\RPC）层自动化测试：100%API覆盖，100%正向流程覆盖，而如果有更多时间也得考虑更多的异常场景等的覆盖，做到100%的用例场景覆盖。
Unit测试：按公司定的目标是60%代码行覆盖率（现在这个标准不晓得是否有变动）。

那我们了解到了从不同层做不同的自动化测试，去满足我们的自动化场景，那为了完成不同层的自动化，我们需要根据不同层选着不同的技术框架。如

UI自动化测试框架推荐

目前市面上UI自动化测试框架按定位元素控件方式的不同，大体分为三类：

• 基于坐标轴的定位：如monkeyrunner、按键精灵等，最大缺点难多设备运行；
• 基于图片识别的定位：如sikuli、网易的AirTest等，但是对相同控件处理麻烦，比较适用于游戏类应用；
• 基于元素属性的定位方式：如Selenium、Appium等，也是大部分框架采用的定位方式，再结合我们自己的APP大多属于HyBrid类型，并跨Android和IOS两个平台，所以这边给一个我自己的建议。

Web端：Selenium ，是W3C标准是目前Web UI自动化最流行的框架，框架稳定，持续维护，主流浏览器都跟进支持。 然后TestCafe 也提下，这个作为Selenium后起之秀也有非常多的特性，而且是一套完整的自动化测试框架，从case管理到运行等，也是市面上目前我看到除了QTP外，又居于元素属性定位，又同于Selenium原理的一个框架。
IOS和Android端：我都推荐Appium，当然除了Appium还有很多选择，例如阿里macaca、苹果谷歌自家的uiautomation，uiautomator。但是更推荐Appium毕竟该框架支持两个平台，而且两个平台提供的api基本一样，并且Appium的设计和Selenium一样，再会其中一个框架前提下再学另一个框架，这样学习成本就低了。

API自动化测试框架推荐

API(http/https)

针对http\https协议，这里推荐Rest Assured。 推选理由1是Java的，请求加解密可以直接复用开发代码，避免麻烦，同时可以更容易寻求到开发的帮忙，毕竟都是java . 2是比起大多数的支持http、https协议调用的框架，它更适合测试员也非常方便使用，也自身带有强大的json xml等解析器。

RPC(dubbo)

目前RPC框架逐渐转向使用udubbo，所以这块RPC调用推荐的也就只有dubbo了。

当然了不管是UI自动化测试还是API自动化测试的框架选择，不局限PPT上介绍的，市面上还有非常多基于它们二开的非常优秀的自动化测试框架可选，但还是得从是否满足要求，是否使用方便，学习成本是否低，社区是否活跃度等综合去考虑。

常用技术

在推荐完API和UI的自动化测试框架后，我们来具体看看如果我们想做好自动化，实现我们的愿景，我们可以从哪些地方入手。
例如PPT，我根据我们自动化测试的不同阶段，举例说明对应的API或者UI自动化这个阶段我们可以用哪些技术手段。
如用例前置条件或者说用例数据准备阶段，我们如何动态去生成和更好地使用数据；
在用例脚本设计阶段，我们重点讲讲UI自动化重点PageObject设计思想，如何通过PO设计思想来提高我们的UI自动化可维护性等；
结果校验阶段，我们介绍除了常用的对比方式外，我们看看Json的对比和对象对比；
用例运行阶段，主要介绍Jenkins的构建和用例并发以及失败重跑；
最后测试报告的生成。

数据准备（API\UI自动化测试）

造数据

我们平时造数据常用的无非这4种方式。

• 特定随机数生成：例如通过手机号码创建用户，每次手机号码不能重复，那么我们可以通过一定规则例如时间戳等去生成11位不重复我数字，这种数据生成往往非常方便，但使用场景有限，例如我需要制作咖啡，我就需要一个真实的咖啡订单，而这个订单号是没办法用随机数来取代的。
• 通过UI造数：同样上面这个场景，需要一个咖啡订单ID，这时我们可以通过走UI的自动化方式去生成订单，然后获取到我们要的订单ID，但是分层测试的金字塔模型也介绍过，UI自动化稳定性差，效率低。
• 操作数据库：那不走UI，我们是不是可以往数据库插入一条数据来解决。表面上很完美，确实可以，而且稳定性高、效率高，但是容易产生脏数据。特别测试员在对数据库不熟悉的情况下，业务业务的一个订单需要涉及好几个库好几个表，我们容易漏了某些表的数据，这样你的数据可能对别人的测试会照成误导。
• 调用API造数：所调用的API分两种类型，一种是开发提供的API，一种是测试自己封装的API。调用开发的API好理解，例如调用下单和支付api我们完成下单的操作。调用测试自己封装的API，我们一会讲数据中心时会再讲。 所以不管从适用场景还是稳定性、效率、数据完整性上看调用API都是比较优的方法，所以我们也推荐通过该方式来生成你需要的自动化测试数据

  数据驱动（DDT）

  
  上个PPT我们讲了测试数据的生成方式，这个PPT我们讲讲，当我们生成数据后如何更好的使用。
  我们来看一个登录测试的场景，我们根据用例设计的等价类划分方法可以简单些两个用例场景如下：

1. 正确的账号、错误的密码登录
2. 错误的账号、正确的密码登录

如果不考虑数据驱动，这时我们可能得写两个测试用例，分别用不同的账号测试，但是如果使用数据驱动的概念，我们可以把数据抽出去用一个方法去管理作为数据源，然后写一个用例去去逐条获取数据，并逐条运行。
当然这个数据源的封装和读取数据源大多数测试框架都支持，例如PPT我是以TestNG测试框架为案例。
通过在data()方法上添加 @DataProvider 注解来让data方法成为一个数据源，data()方法并返回数据源数据。

用例脚本编写上，我们也只需要添加 dataProvider ，并根据数据源个数和类型编写脚本入参个数和类型。

这样当这个用例被运行时，就会逐条的去读取数据源的数据，并逐条运行，所以运行后的结果我们可以到如图跑了三次，3次的参数值都不一样。

这样1个case代码就完成3个案例场景，不仅减少了代码量，对后期用例的维护也方便很多，假设哪天需求变更，添加了验证码，我们只需要数据源添加验证码并在这1个用测试脚本用例上添加验证码的步骤便可。

数据分离

数据驱动帮我们把数据和业务逻辑做了分离，提高了代码的可读性和减低后期的维护量，但如果我们一些特殊场景需要用到的数据量很大，那都放在一个方法里面明显不是很合理，也不方便修改。
例如我以前有个场景，我需要从A系统拿到一份数据每天都有上千条数据，然后去逐条校验这些数据录入到另一个系统，然后校验结果。
这时我们除了要数据驱动外，还得做数据分离，把数据和代码做分离，把这大量的数据放到外部文件去管理，如excel、text、DB等。然后数据源从这些文件中读取数据，最后用例引用数据源。
例如PPT中案例我把数据放到Excel去维护，然后再做数据驱动。
（可以细看代码）我先通过POI去读取Excel的数据，然后构造出数据源，最后用例运行逐行读取数据源。

数据中心

造数中提到我们推荐通过调用API的方式来实现造数的过程，其中一种是调用开发提供的API还一种是测试自己封装的API，也就是我现在要提的测试中心的概念。
为啥要测试中心呢？
目前我们通过介绍的4种方式来造数还是存在一些痛点的：

• 执行效率慢：特别是通过UI造数据时尤其明显
• 造数据过程复杂：就拿我们想通过调用接口的方式实现下一个外卖订单为例。那么我们可能需要调用的几个接口，第一个接口商品接口，获取要下单商品的一些商品属性，第二个用户外卖地址信息接口，这两个接口拿到的数据给提交订单接口作为入参，所以第三个要调用的接口是提交订单接口，最后还要调用支付接口我们才完成一个外卖订单。也就是我们为了下一个外卖订单我们至少要调用4个接口，而且很多接口的入参是非常复杂的例如提交订单接口的入参。
• 无法提供统一服务：自动化测试需要准备测试数据，功能测试，性能测试等都需要准备测试数据，现在每个测试都自己准备并没提供一个统一标准和服务。
• 批量造数据成本高：例如要测试门店端的压单，一下几百个订单的，通过手工是基本不可能的，而自动化代码要做也得去改动一些脚本。
• 等等

所以既然痛点那么多，而且大家都需要准备数据，那为啥我们不考虑平台化。把多个开发的API封装成1个测试用的API，简化入参等，最后提供统一web界面和接口。例如PPT中的一键下单给功能，对于手工测试可以一键下单，给自动化测试可以调用平台提供的接口，只需要传入门店ID、订单类型变可以下一个订单，大大简化了调用链，也简化了入参。如果我再完善下，提供下单数量，后台默默的帮忙创建对应数量的订单，这样性能的造数也可以通过这个平台完成。
这样对于功能测试、自动化测试、性能测试统一了平台，简化操作，甚至还可以做成空闲预先造一些基础数据等等，总归对造数据就有了无限的遐想，而且更多人共同来维护数据平台。

用例脚本设计（UI自动化PO思想）

糟糕的用例

讲PO前我们先来看个用例，这是一个UI自动化测试编写的用例，大概用例场景就是输入邮箱、密码，点击登陆获取提示语校验是否是账号或密码错误。这个用例运行没问题对吧，操作和校验都有。但我觉得它是一个非常糟糕的自动化测试脚本用例。为啥？我们来讲讲这段自动化脚本的几个槽点。

1. 数据不分离：这个刚提到过了，同类的用例肯定还有，那你的测试账号密码是不是应该分离下，用上数据驱动等思想，不要每一组都写这一坨代码，后期维护麻烦
2. 定位元素不分离：因为有些伙伴可能没做过UI自动化，不懂什么是定位元素，我这边简单说下。做UI自动化最重要的两件事就是定位元素和操作元素。而定位元素就是通过控件元素的某些属性值，而查找到该控件元素，如例子中通过name=email 找到邮箱文本框，并最后在文本框输入“test”。那定位元素不分离有什么问题？假设我有2个自动化用例中操作了邮箱文本框的输入，那么因为产品不停迭代更新，也可能前端重构等，这时我们邮箱这个文本框的name属性可能变了，不再叫”email”了，那这时我们的UI自动化代码是不是得对2个自动化用例都去维护，2个还好，要是10个case用到这个定位和操作呢，不得改10个地方，而且改的地方要越多就越容易漏改，所以槽点后期维护麻烦。
3. 逻辑和用例描述不分离：我们功能用例一般这么描述一个登录场景，我用账号A，密码B做登录，那么登录成功什么的。而例子中我们的自动化脚本要把输入A，输入B，点击登录一步一步去编写，那这样有什么问题？假设我们现在10个case都需要登录，那如果我们每个caes都写这么一个复杂的登录操作，某天需求变跟登录添加一个验证码，那么我们是不是的10个用例逐个修改。
4. 用了固定的等待时间，代码中用了sleep()30秒，这个设计出发点肯定是为了提高脚本的稳定性，毕竟你点击登录后，前端向后端发起一个登录请求，后端处理再返回前端展示出来是有一个时间差，而脚本执行速度很快，如果不等待则脚本运行就会出现元素找不到的情况。出发点是对的，但是方式是错误的。 sleep 时间写短了，网络延时下可能你还是找不到元素，等待时间写长了那可能元素早就显示了，而线程瞎等待，这大大降低执行效率，所以这块需要考虑的智能等待，例如每1S去判断一次元素是否加载，超过若干秒还是未加载就自动化失败，若已经加载则继续往下执行。当然这个问题跟我们下去要讲的PO思想没啥关系就是了，它也是槽点我们也就顺便简单聊下。

OK所以槽点那么多，这个案例脚本在实际工程中我们肯定是说NO的。那我们看看PO思想引入如何来解决这些槽点。

PO设计思想

首先我们先来看看什么是PageObject思想：
PO(PageObject) 见名思意，就是页面对象。就是把页面元素定位和页面元素操作分开。还有个页面工厂PF思想跟这个一样，只是实现形式有所区别。
PO思想既然吧页面元素定位和元素操作分开，在实际工程中我们还可以把一类通用操作抽取出来放到逻辑层，最后才到我们真正的用例业务层，如果这个用例业务层还有很多的数据，我们还可以把数据也抽取出去形成数据层。所以最终我们的PO设计思想可以大体分为三层或者四层。
三层：

四层：

当然这 2 3 4层都是我几年前给它取的名字，并不一定很贴切。所以我们就干脆直接把刚那个槽点满满的用例，用PO设计模式做个演示，大家可能会更清楚。因为我们没太多的数据，所以我就以三层分法为例。

• 对象层

我把页面元素的定位单独抽取到一个类去管理，如邮箱输入框的定位，密码输入框等位等。并编写了这些元素空间的操作方法，如sendKeysEmail()输入邮箱

• 逻辑层

因为登录这个操作可能被很多case引用，所以我也提取成一个公共方法，形成逻辑层，方法里面实现具体的登录过程。

• 业务层（测试用例）

最后就是我们的测试用例业务层，我的功能测试用例描述我用账号A，密码B登录。那它对应的业务层里面的代码就是loginMail.login(“xxx”,”xxx”)一行。

所以这样分层后，我们再来看看槽点用例时我们举的痛点。

1. 页面元素变化：我们只需要找到对应的页面对象类，修改便可。
2. 业务流程变化：新增验证码，我们只需要在逻辑层中的login方法，添加验证码输入便可。

所以我也简单归纳下PO设计思想的几个好处，便于维护页面对象，便于维护流程的变化，提高业务层代码的可读性。

用例结果校验（API结果校验）

讲完用例的设计，我再往下讲讲结果的校验，这个结果的校验主要以API自动化测试为主，因为UI自动化的结果校验能玩的花样不多，常规校验便可。

糟糕的结果校验

我们看到很多API自动化测试，不管是通过类似Postman的工具、还是平台甚至代码实现，很多结果校验就只校验到接口的返回状态码=200或者meg=success。
这够吗？
肯定是NO的对吧。例如我们的很多API，结果返回主要内容都是放在 content 字段里面，例如某个API里面调用了RPC，很多时候RPC挂了，结果contentl里面给报错了，而同级的code、msg可能都是通过的。 再例如获取商品详情接口，可能的入参是A商品，出参给你的是B商品，而你制作200校验和success校验这个case还是通过的，实际却是bug。 所以接口校验要怎么做？要做啥？要做啥好办，你接口功能测试用例，要求测啥，验啥，你的自动化脚本就得测啥，验啥。而具体验证，除了常用的逐个json解析校验，我们还有比较常用的2种校验方式。

结果校验

我们要做详尽的校验，如果还是靠逐个json字段解析有点麻烦，这时我们应该多考虑考虑是否可以Json对比和对象对比。
例如刚提到的商品接口返回一个商品信息是一个json，我们从数据库拿出这个商品对象转成json，两个json对比是不是更快。 接口返回的json转数据库的对象和数据库商品对象对比，是不是也快很多。
PPT 我Json 和对象对比分别给了一个案例，我们也简单看下。
Json对比，json1 和 json 2 不仅字段顺序不一样，字段b的值也不一样。那假设b字段刚好不是我们需要判断的，那么我们可以简单assert json1 jsono2 ,并把b排除。Java中Json的对比可以看看json-unit。
对象的对比，例子中接口返回json转成OverviewRe对象跟数据库对比。 Java中大多数的测试框架如TestNG 的equal方法都支持对象的对比。

用例运行（API\UI自动化）

case结果校验完成，基本上就算用例已经写完了，下面我讲caes写完后的运行。

并发执行

为啥我们需要并发运行？
很简单我们需要更快的拿到测试结果。而金字塔模型中越往顶层走执行的效率就越低，当我们有几百个UIcase时，如果还是通过单进程或单线程运行那估计没一小时也得好几十分钟。所以并发是必须的，特别是UI自动化并发执行用例是必须的。
那并发运行自动化用例我们需要注意什么呢？
其实很简单，不管是功能用例还是自动化测试用例，都需要原子性，独立性，也就是用例和用例直接不要有依赖关系，每个用例都可以独立运行。
如何做并发执行？
这里以TestNG为例，我们通过xml去配置要运行的用例，同时我们也可以xml里面配置要并发的方式和并发的线程数。最后运行就根据配置线程数和方式并发。

失败重跑

因自动化测试存在稳定性问题，可能是被测环境不稳定，也可能是脚本执行环境不稳定，也可能脚本并发互相影响等，都会造成自动化用例执行失败，那为了让最后的测试报告中减少因这类问题引起的非bug类失败，所以我们通常需要做失败重跑。
那何时失败重跑，常用的是执行失败了，立马重跑若干次。也可以在所有的cases执行完后，给出一个失败列表，然后再针对这个列表做重跑。失败重跑大部分框架稍作修改或二开就可以支持，而且很多报告也都可以追溯。

jenkins CI

我们的脚本不能总是本地运行对吧，所以我们需要一个能定时自动和手动触发运行脚本的平台，再没有自建平台下，Jenkins就是一个能完美达到这个目的的平台。
Jenkins 本身有非常丰富的插件，可以满足我们的自动触发和手动触发。
手动触发我就不多讲，就是打开对应的job，手动点击构建或参数化构建。
自动化触发，目前我觉得两种方式可以做：

1. Jenkins上每日定时构建，定时构建jenkins带的功能，只需要定时构建配置下你的定时构建时间便可。 如果你希望每次提交测试代码后也构建也可以采用轮询方式。
2. 结合USOP等平台。 Jenkins 的构建是提供相关的构建API，例如图里面的这个参数化构建job的API。PPT上面还写未做这块，其实现在已经有了，原理也很简单，当USOP要部署项目前，先除非下构建Job的api，变可以达到跟USOP打通的效果，USOP部署一当开始就自动化运行自动化用例。

   报告生成（API\UI自动化）

   报告记录测试步骤和错误截图

   

jenkins 构建完成后，我们需要邮件输出一份测试报告，那这份测试报告除了一些常规信息如测试用例通过与否，通过率，历史记录等外，其实我们还有两个非常重要的信息得写入到测试报告中。

1. 测试步骤
2. 错误截图（UI自动化）

为啥需要这两块？
测试步骤和错误截图其实都是为了我们快速的定位开发问题，和保留错误现场。同时记录测试步骤也可以极大方便自动化测试人员走查自己的代码。
如PPT 接口测试，我记录每一个接口的请求地址，入参和响应报文。 这样我就可以不用查日志的情况下就可以看到跑脚本时这个接口做了什么样的测试场景，给了什么样的结果返回。
当然自动化测试结果的处理除了错误自动截图，测试步骤自动化记录外，当我们脚本跑稳定了，我们也是可以考虑把case脚本执行失败时自动往bug平台提交bug，还有一份测试报告发出后，如果开发修改好了就个bug，我们也希望开发能自测下对吧。 那自测bug是不是已经修复，最快的方法就是从报告中点击下原本错误的case让它重跑一遍对吧，所以我们还可以做从测试报告中去触发单个case的重跑。当然这里我就不去具体演示了，后面有机会我们可以再来细聊，PPT报告那个截图中其实就已经实现了，展开会点击run或者加上你要收到结果的邮箱便可。

回顾愿景

最后我们又来回顾下我们的自动化测试愿景，再看看为了实现这些愿景我们都做了哪些努力。

成本低

我们主要通过减少后期代码维护量入手，讲了数据驱动、数据分离、数据中心的概念，并演示了PO设计模式

收益高

我们从一开始介绍自动化测试的分层思想，通过并发运行提高运行效率，通过Jenkins构建简化构建和提高构建频率。

场景全

我们讲了4种造数，为了达到动态化入参，对多环境的支持，以及更完善和更简便的校验

稳定性高

我们讲了失败重跑，减少环境等的影响，讲了测试步骤记录和结果截图，辅助排查问题也是可以逐渐提高自动化脚本稳定性。

考题