前言：

最近这几天太肝了，兄弟们，连续写了好几天快有点顶不住了铁汁们，快点赞关注来点动力哦，嘿嘿嘿

 

十、接口自动化

10.1 接口自动化怎么测试

( Python+ requests+pytest版本)

原来我们接口自动化是用 python+ request+ pytest执行

接口自动化其实主要就是接口测试的基础上填加了断言，参数化，动态关联

做接口自动化之前，我们也会划分模块， 告，公共的模块，测试数据，测试 告，主要的目的是为了方便后期的维护

测试数据，一般原来我们就是用的接口测试用例，公共的模块，主要是里面的一些公共的作，比如说用例 excel数据的读取

数据库的连接，还有我们封装的每个接口请求

断言的主要是获取访问接口的值判断，用的是 assert，参数化主要用的比较多是excel表格，就是测试用例数据

还有需要调用登录后的 cookies跟 token的时候，我们就会用到关联

比如说原来我们写的一个申请借款的接口吧

首先我们会编写测试用例，把每个用例数据保存到excel中

再建立一个申请借款的模块

这个时候我们去调用申请借款的功能模块，里面的参数我们是保存在 excel表格中

我们建立发送请求，通过参数化，去读写excel表格中的数据，获取到返回的数据，通过assert去对应返回的数据跟用例中异常的数据。

这个时候也会做数据库断言，去连接数据库去查询数据库中时候存在查询，如果是返回结果

是json数据格式，我们还会转化下格式后，再去断言

这个申请借款模块，也会用到登录的 cookie值 token，我们先建立一个登录的请求，提取

返回的 cookie值 token

excel表格多个用例，我们就用到循环去运行，读取excel中用例总的条数，去循环运行，

这里要注意的是:

就是excel表格数据时是str我们要eval转化成字典格式

把每个接口封装好以后

我们就会调用 pytest框架去运行所有test文件的测试用例

如果只是执行部分用例，也可以通过 pytest框架来指定

然后用 yagmail,在 pytest框架运行完test文件之后，发送邮件到指定邮箱。

接口自动化，我个人觉得，性价比是比较高的。

实现起来简单、维护成本低，容易提高覆盖率等特点

接口是稳定的，最多是增加一个字段或者新增接口之类的

低成本，有了相对的稳定性，不需要大量重新编写脚本，只需要基础维护包括用例的扩充就可以了

执行的快，反馈的速度快

（jmeter版本)

原来我们也做了很多接口自动化，接口自动化这块，其实原来我们也是用 jmeter请求去做的，这个时候，我们也用到一些工具，http代理，主要方便编写接口请求，通过录制就行了，我觉得接口自动化只是在接囗测试中多加了一些参数化、关联、断言参数，主要是函数参数化，自定义变量参数化，文件参数化，主要文件类型csv跟txt，不过原来csv文件用的比较多，还有一些数据库的参数化，断言，主要响应代码断言，响应文档断言。

比方说，原来我们一个登录接口主要是正常场，异常场票这块，正常场景，主要是用户跟密码正确，采用数据参数化，把用户名用随机函数进行参数化，随机长度大一些，用户名不存在的情况，原来是通过文件参数化，设置参数值，密码不正确也是通过文件参数化，接口请求中host地址，目录地址，我们都进行数据化，自定义变量去操作，结果检中，我们主要是用断言来检查，每个请求，

设置了2个断言，一个响应代码断言，一般是200，响应文本断言，登录成功，返回码为1

状态提示成功，检意是否成功，对应异常场景也是，都需要设置断言，去检查结果原来做的申请借款接口，需要登录接口http cookie，我需要建立2个接口，一个登录接口，一个申请借款接口，通过正则表达式去提取登录接口返回 cookie，在申请借款请求接口，设置http cookie时，值为登录接口返回cookie，还有也要考虑原来我们项目，还有 token值，提取登录返回 token，提取，当成申请借款的请求参数，当测试场景的脚本编写完成，执行接口测试用例，我们在察看结果树中，检直，主要是看颜色这块，红色检查哪些地方失败，绿色表示通过

编写完成后，我们会把脚本添加到 jenkins里面持续集成运行

原来我们持续集成是半个月运行一次，当然我们也可以手动构建

1，我们一般把写完的 jmeter的脚本

2，通过svn把写好的脚本检入到svn服务器

3，在 jenkins任务下，选择定时构建，或者手动构建，检查svn上传最新的脚本，去运行

一般我们项目在修改新的功能模块，上线，转测之前，都会自动去运行脚本

4，运行完成，我们再 jenkins下，查看脚本运行结果

 

10.2 为什么做接口自动化/strong>

接口自动化，我个人觉得，性价比是比较高的

实现起来简单，维护成本低，容易提高覆盖率等特点

接口是稳定的，最多是增加一个字段或者新增接口之类的

低成本，有了相对的稳定性，不需要大量重新编写脚本，只需要基础维护包括用例的扩充就

可以了执行的快，反馈的速度快

10.3 假如公司想要做自动化，让你去做，你会从那些方面考虑入手/strong>

1.测试范围 2.时间进度 3.人员安排 4.框架确定

5.环境的搭建 6.准备好测试数据 数据驱动 7.工程的管理后期的维护

10.4 你写了多少接口自动化用例

自动化用例，也没有具体数过，当时我负责的所有模块的接口的自动用例都是我这边独立完成的，

有模块的用例会多一点，有些会少一点，这具体看接口的参数有多少，参数多限制条件多的，

一般用例会比较多一点，我负责的模块大概有100多条用例是有的!

10.5 比如说你接口的请求参数需要加密处理的，你们用的是什么加密方式，你加密怎么处理的/strong>

这个是有做过的，就拿当我们那个项目的登录接口来讲吧，那个登录的密码是需要进行加密

加密之后再进行传输。这里需要问开发要加密算法，我们会把它封装成一个函数，调用这个加密函数对密码加密，之后再进行传递。我们公司的加密算法，大部分用的都是MD5的加密算法(base64)

10.6 你查询出来返回结果是密文，密文你怎么测试

这里首先要搞清楚用的是什么加密算法，问开发要解密算法，对返回的数据进行解密

解密完成之后在与预期结果对比，去进行断言

10.7  http如何进行代理录制接口

Web端

1，浏览器设置代理就可以录制，默认ip为 localhost，端口8888

手机端

1，手机设置代理就可以录制

默认ip为pc机器的ip地址，端口8888

10.8  jmeter如何进行参数化，参数化类型包含哪些

用户参数自定义变量文件参数化，csv文件或者txt文件

函数助手随机函数，csvread函数数据库参数化

10.9  jmeter中对于json数据如何提取信息

正则表达式提取或者 JSON Extractor提取

10.10  jmeter中如何跨线程组传输参数

正则表达式或者边界值提取器或者JSON Extractor提取的值

后置处理器- beanshell处理器

定义成全局变量

${_setProperty(newtoken,${access_token},)}

其他线程组，引入变量值

${_P(newtoken,)}或者${_property(newtoken,)}

10.11  jmeter如何进行断言

1，响应断言

添加响应断言：添加-》断言-》响应断言

apply to:是应用范围，设定匹配的范围

Main sample and sub-samples:匹配范围为当前父取样器，及子取样器

Main sample only:仅当前父取样器

Sub samples only:仅子取样器

Meter Variable:变量值进行匹配

要测试的响应文字:针对响应数据不同部分进行匹配

(1)响应文本：响应服务器返回的文本内容，http协议排除 header部分

(2)响应代码：匹配响应代码，比如http请求中200代表成功

(3)响应信息：匹配响应信息，处理成功返回成功”或者“ok”字样

(4) Response Header匹配响应头中的信息

匹配规则:

包括：响应内容包括需要匹配的内容就算成功

匹配：响应内容要完全匹配内容，不区分大小写

equals：完全相等，区分大小写

substring：响应内容包括匹配内容即为成功

可以通过添加断言结果来查看断言的执行情况

执行结果：

如果接口响应数据可以与断言匹配上，则测试用例通过，否则不通过

可以通过断言结果，查看断言执行情况。

2，大小断言

3，持续时间断言

10.12  jmeter如间在cmd命令下运行

Jmeter -n -t文件路径fw-zhuce.jmx -l result.jtl -e -o E:resultreport

讲解：非GUI界面，压测参数讲解

-h帮助

-n非GUl模式

-l记录结果的文件每次运行之前，(要确保之前没有运行过即xxx.jtl不存在，不然 错)

-r Jmter.properties文件中指定的所有远程服务器

-e脚本运行结束后生成html 告

-o用于存放html 告的目录(目录要为空，不然 错)

-R表示选择执行=远程启动

XXX.XXX. XXX. XXX：5174 ，XXX. XXX. XXX. XXX：5172

官方配置文件地址http：//jmeter.apache.org/usermanual/get-started.html

10.13  imeter运行完成后如何去自动发送邮件/strong>

(1)监听器中添加-邮件观察仪

文件名-运行完成，保存运行结果的位置

from邮件的发送人

isz181xiongmao@126.com

addressee邮件的接收人(多个人用逗 隔开)

success subject运行成功，发送邮件标题 success limit大于运行请求成功的次数

failure subject运行失败，发送邮件标题 failure limit大于运行请求失败的次数

host邮件服务器地址smtp.126cm

login邮件服务器登录用户名密码(授权码)

1、文件名：只需要给出路径和保存的文件名称即可，给定之后将会把测试结果的数据写入到文件中

注：它不会将此文件已附件的形式在邮件中，只是将测试结果写入到了定的此目录文件中，

如果你运行完脚本，直接在此路径下打开此文件就可以看到运行结果

2、 Success Limit与 Failure Limit：当成功数与失败数为几时进行邮件的发送(注意：此处是大于给定的数值，不是等于)，我写的1，则失败2次后将发送邮件通知我，

3、当测试结果100%成功时则不会发送邮件

4、写代码java编写 beanshell后置处理器

10.14  pytest如何做断言/strong>

用 assert断言

1，断言返回的结果

2，进行逻辑检查，检查数据库产生的数据

10.15  patent中如何去调取其他用例中返回的参数/strong>

把返回的值定义成全局变量

global a_id #定义成一个全局变量

a_id = incharge_id

10.16  你们做接口自动化，用例数据是怎么组织，管理的/strong>

用例数据这块，当时公司要求使用 excel表格来进行管理，其实这里主要也是为了实现数据与脚本的分离，提高整个工程后期的维护与优化，这里把数据封装到excel表格之后。

我们在脚本中通过调用封装好的读取 excel表格的数据函数，对excel表格中的用例数据，

我们是这么组织的，会有以下几个字段像用例标题，请求地址，请求方式，请求头，请求参数，响应结果，这个几个部分，对于请求头跟请求参数，因为脚本中发请求都是通过组装成字典的形式来发送的所以这里我们也是通过类似于字典的形式文本格式来进行组织，主要就是方便后期脚本的提取与引用其实我觉得，这样去处理的好处就是，后期如果用例数据有变动，或者需要增加或删除部分

用例直接针对 excel表格数据进行操作就可以了，不需要改动脚本这也就方便整个项目工程的管理与维护了。

10.17  requests中如何进行动态关联

1，如果返回的是 cookies值，可以直接返回接口的 r.cookies

2，返回的是str类型数据，可以导入re模块进行正则表达式提取返回数据格式是json格式，

导入json，把json数据格式转化 python对象

json.dumps	将 Python对象编码成JSON字符串
json.loads	将已编码的JSON字符串解码为 Python对象

10.18   你们 python接口自动化怎么去处理 cookie， session的/strong>

对于 cookie，session的处理一般有三种方式:

第一种就是先获取登录请求的 cookie值，然后发送其他请求的时候，在 requests提供的

两个方法get或post方法中有一个 cookies参数，我们可以通过这个参数来传递 cookies值

第二种就是通过订制请求头，然后把获取到的coookies放在请求头中，通过请求头来进行传递

第三种就是通过创建一个 session会话对象，后期所有的请求发送都通过调用这个 session会话对象来进行发请求，如果是登录请求，它会自动保存 cookies值，然后其他需要用到cookies值的请求，也通过 session对象来发送，它会自动把 cookies发送出去,对于 cookies， session的处理，我们差不多都是通过以上三种方式来实现的

 

十一、 UI自动化

11.1  ui自动化怎么测试

(1)我们做U自动化测试使用 Python+ seleniun+ unittest工具

主要对自动化进行规划，把数据、代码、资源、公共方法进行分离，方便后续维护;

具体是通过元素定位、断言、参数化和封装来实现;

其中元素定位的方法，主要是css定位，也会用一些 xpath定位，还有id、name、 class等

断言，主要是用 Assert来判断实际结果是否与预期结果相符;

参数化，可以用列表、字典、导入excel表格库(xlrd)对数据进行参数化;

对于封装，一般我会对元素还有公共的模块进行封装。

比方说：原来我们有一个申请借款的功能模块

首先我们先进行自动化框架分类，分成测试数据、需要定位的元素、公共方法(比如说，一些数据的操作、excel操作，我们会封装成一个公共方法)。先采用css定位，把申请借款所对应的元素定位出来，里面有很多内嵌页面，还有下拉框元素的定位操作,对应申请借款的数据，我们都会保存在excel表中，从excel表格中去获取数据。申请完成以后，我们会设置一个断言，还有进行数据库的检查。我们会把元素封装到资源库，还有就是模块的封装,申请借款会用到登录模块，我们首先会封装好登录功能。借款申请完成后，会从数据库中删除相关的数据实现数据闭环，再关闭界面。

运行自动化脚本，我们是用 unittest 框架去运行，编写测试集，一般我们是编写 unittest脚本，

去执行所有测试用例。

我觉得自动化中最难的在于元素的定位、内嵌界面、时间控件，这些需要一些js操作去除元素属性，进行操作。

自动化中发现的问题：

在申请借款中，开发人员写了调试代码的弹出框，没有删除，导致我们自动化脚本跑不通

充值过程中，

添加新的支付方式，开发修改了代码，导致原有充值失败，这些都是我们原来自动化发现的问题。原来也用了一些 Robotframework的自动化测试框架，这个比较简单一些，因为部分关键字、框架已经封装好了，只需要调用就行，但是不好的地方，就是扩展性会差一些。

编写完成以后，可以用 Jenkins持续集成去定时跑自动化测试用例，再去查看运行日志。

总的来说RF( Robot Framework)比较简单方便上手比较快，如果公司对自动化要求不高的话可以选择RF框架来做，如果比较高的话就选用 unittest框架来做。

(2)原来我们自动化测试主要是用的 python+ selenium+ pytest框架做的

主要对自动化进行规划，把数据、代码、资源、公共方法进行分离，方便后续维护;

自动化测试其实主要通过几个方面元素定位，参数化，断言，模块的封装，数据闭环等来实现的

其中元素定位主要是cs定位也会用一些 xpath，id，name，classname,ink等等定位，还有js定位和 jQuery定位都会用到;

参数化主要是用列表、字典、以及导入excel表格库(xlrd)对数据进行参数化;

断言：主要是用 assert断言来判断实际结果是否与预期结果相符;

对于封装，我主要会对界面上的元素，一些公共方法(数据库操作，读取excel数据公共方法等)，还有测试数据(变量，字典，列表exce表等)和一些元素操作，测试用例等等进行封装;

最后闭环的话，就是都要把新增的数据删除，打开的界面都要关闭,就比如原来我们做的自动化测试，有一个申请借款的功能模块,

首先，我们先进行自动化框架模块的分类划分,分成需要定位的元素 page_element，公共模块 common(比如说数据库操作，读取excel数据的操作，都会封装成一个公共模块的)、测试数据data、测试用例、元素操作 element_action、执行用例以及 告文件等等这些模块。

先导入 selenium包，采用css定位，把申请借款所对应的元素定位出来，里面有一些内嵌界面，需要先进入内嵌界面 –driver.switch_to.frame()，还有下拉框元素的定位操作(定位下拉框的话首先要导入select包，通过 index，value，visible_text进行

选取值： Select(变量). Select_by_value(‘’)把定位到的所有界面元素封装到 page_element模块里面，方便后期维护。

对于申请借款的数据，申请借款的一些标题，利率等等，我们都会保存在excel表中，对于excel表格操作，导入xlrd包把读取数据公共方法，保存到公共模块 common中，方便以后从exell表中获取数据，申请借款成功以后，我们会添加一个断言，获取界面title值，去判断界面的提示，当然也可以获取提示申请成功text内容去判断，也会做数据库断言，检查数据库数据，导入数据库操作包 pymysql，把数据操作，封装到公共方法，

去调用(数据库操作步骤：1打开数据库连接,2建立游标,3执行游标(sql),4返回获取的数据)

申请借款模块需要调用到登录模块，我们先把登录模块封装好，放到元素操作element_action模块中，方便维护,借款申请完成后，我们会从数据库中删除相关数据实现闭环，减低后续维护，再关闭所有打开的界面。

我们运行自动化脚本的时候是用的 pytest框架进行

导入 patent，导入 yamail包

定义一个主函数if _name_=”_main_”，pytest.main()所有的用例脚本，定义生成对应的HTML 告到 report目录下，最后通过 yagma定义发送邮件

定义发送邮箱的登录信息-定义邮件主题，内容，附件位置–发送邮件到测试人员邮箱中

当后续出现错误用例，也会调用 pytest–if来运行失败的测试用例

我觉得自动化中最难的在于

元素的定位、内嵌界面、时间插件，这些需要一些js操作，去除元素属性，进行操作

自动化中发现的问题：

在申请借款中，开发人员写了调试代码的弹出框，没有删除，导致我们自动化脚本跑不通;

充值过程中，添加新的支付方式，开发修改了代码，导致原有充值失败

11.2  什么是自动化测试/strong>

把一些简单，重复的工作，用自动化去实现，减少成本原来手工完成事情，通过自动化脚本去替代

11.3  什么样的项目合适做自动化(至少三个)

功能需求，需求稳定，界面稳定，不会频繁变动，才可以做

版本迭代次数比较多，做出来才有意义

项目周期比较长(大项目)意义

11.4  自动化测试流程是什么/strong>

1、前期项目组会评估项目是否合适做自动化测试，例外就是看下哪些模块需要做自动化，适合做

2、人员安排，分工

3、确定测试框架

4、各自领取自己负责模块（根据功能来进行划分，功能测试的模块）

整理功能模块的用例，把能做自动化的用例提炼出，规整成自动化用例文档，

准备数据，整理数据，管理

资源，环境的准备

5、搭建测试环境

6、脚本开发

11.5  自动化实现的比例，1-2年。

2年以内，把原来手工做的事情15-30%用自动化脚本去替代

2年以上，实现40-70%

手工编写测试用例

把原来手工的测试用例，当成自动化测试用例

11.7  自动化测试的优点与缺点

优点:

1、对程序的回归测试更方便

2、可以运行更多更繁琐的测试

3、提高测试效率和准确性，节约时间成本

4、可以执行一些手工测试困难或不可能进行的测试(例如，对于大量用户的测试，可以通过自动化测试模拟同时有许多用户，从而达到测试的目的)

5、自动化测试不存在执行过程中的疏忽和错误，从而增加软件信任度

缺点:

1、不能取代手工测试

2、手工测试比自动测试发现的缺陷更多

3、对测试质量的依赖性极大

4、由于自动测试比手动测试更胞弱，所以维护会受到制，从而会制约软件的开发

5、工具本身无想像力

11.8  你们自动化覆盖率有多少/strong>

2年以内，把原来手工做的事情30%用自动化脚本去替代

2年以上，实现40-70%

当时覆盖的确实也不是很多，差不多30-40%的样式吧

11.9  自动化测试环境的搭建是怎样的/strong>

1、首先要安装 Python

2、然后安装编写代码工具 pycharm

3、导入 selenium库(pip install seleniun在 pycharm安装 selenium3下载源码包

4、下载浏览器驱动(谷歌.火狐等)，把驱动程序发到 Python根目录下

11.10  seleniun的原理是什么/strong>

我们用的 selenium3x以上的版本，对于 selenium2x以上的版本原理是这样的：

Selenium2.0则是把 selenium1.0中 selenium RC替换为了 WebDriver

WebDriver利用浏览器原生的API，封装成一套更加面向对象的 SeleniumWeb Driver API

直接操作浏览器页面里的元素，甚至操作浏器本身(截屏，回口大小，启动，关闭，安装插件，配置证书之类的)，由于使用的是浏览器原生的API速度大大提高，而且调用的稳定性交给了浏览器厂商本身，显然是更加科学，然而带来的一些副作用就是，不同的浏器厂商，对Web元素的操作和呈现多少会有一些差异，这就直接导致了 SeleniumWebDriver要分浏览器厂商不同，而提供不同的实现，例如 Firefox就有专门的 FirefoxDriver，

Chrome就有专门的 ChromeDriver等等

 

11.11  Selenium2与 Selenium1的区别是什么/strong>

Selenium1.0使用的是 Javascript注入技术与浏览器打交道，需要 Selenium启动一个 Server，将操作Web元素的AP调用转化为一段段 Javascript，在 Selenium内核启动浏览器之后注入这段 Javascript，开发过Web应用的人都知道， Javascript可以获取并调用页面的任何元素，自如的进行操作，由此才实现了 Selenium的目的：自动化Web操作，这种 Javascript注入技术的缺点是速度不理想，而且稳定性大大依赖于 Selenium内核,对API翻译成的 Javascript 质量高低

Selenium2.0则是把 selenium1.0中 selenium RC替换为了 Web Driver

WebDriver利用浏览器原生的API，封装成一套更加面向对象的 SeleniumWebDriverAPI