十九、持续集成

19.1 jenkins + ant + jmeter + svn接口自动化测试?

jenkins + ant + jmeter + svn环境搭建

原来这个环境是我这边搭建的，

主要是几个步骤，

第一Jenkins安装、第二，ant安装、第三，jmeter安装、第四，jmeter与ant连接

第五，Sn安装、第六，任务的构建

首先我们要确定jdk已经安装好了，jdk安装，可以下载jdk包，配置环境变量就行

再jenkins搭建，原来我们是用yum安装命令， yum install -y jenkins安装 jelkins

如果yum安装不能进行，yum仓库添加 jenkins连接信息

或者就用下载安装包进行安装

ant安装，我们可以百度去下载，

像原来我们这边一般会把常见安装包文件执行，我都会保存一个安装文档，

当下载ant安装包以后，只需要解压，并且配置环境就可以了

jmeter安装，也是先下载安装包，把安装包导入到linux服务器，解压，配置环境变量就ok了

jmeter跟ant连接，主要是配置 build.xml的文件，

文件目录放在jmeter目录下，build文件主要是配置,

jmeter的路径，保存生成html跟jtl报告的路径，还运行jmx脚本的路径

把jmeter文件 ant-jmeter-1.1.1.jar放在ant目录下

把jmeter-results-shanhe-me.xsl上传至 jmeter安装目录的 extras文件夹下

也要配置jmeter.properties文件把输出结果由csv修改成xml

配置完成后，我们可以用ant run运行调试下，能否运行脚本成功

svn服务器安装，原来已经安装好

安装，通过yum安装到服务器里面，建立资源库，配置里面配置文件，添加用户，修改权限，再通过,

svnserve -d -r /data/svn/启动服务器，同时我们要考虑防火墙是否允许访问或者关闭防火墙

jenkins任务的构建

在jmeter系统配置中，先要添加环境变量，主要是jdk的路径，ant的路径(linux服务器里面的路径)

添加2个插件，一个 html publisher pulin主要生成HTML报告，一个 performance

pgn运行 jmeter脚本生成jtl报告

再构建一个任务，

在任务中

丢弃旧的构建，

再源码管理，配置svn服务器路径，导出文件位置，还有svn用户与密码

配置生成jtl报告的位置

配置生成html报告的位置

配置定时构建，原来我们设置设置半个月跑一次

还配置邮件发送( jenkins，系统配置，配置邮件服务器地址)

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

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

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

3，在 jenkins任务下，选择定时构建，或者手动构建，检出svn上传最新脚本，去运行一般我们项目在修改新的功能模块，上线，转测之前，都会自动去运行脚本。

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

19.2 jenkins如何使用?

原来我们主要是用来，持续构建环境还有我们的自动化脚本的运行

比如说：jmeter接口自动化脚本

原来我们jmeter脚本运行，在 jenkins里面，首先先建立一个任务，再从svn服务器中导出jmx脚本，设置定时器，原来我们都是早上B点钟自动运行，构建 ant run运行，后面添加生成的html根告跟jtl报告，运行完成后，我们进行邮件提醒，我们只需要查看邮件，直看运行结果就ok，出现了问题，我再去找开发修复问题。

后续我们编写完成的接口自动化脚本，只需要通过svn检入到svn服务器即可，就会每天定时去运行，查看结果就好。

比如说：pytest框架自动化脚本

也是构建一个任务，设置源码管理，从svn导出源码，原来我们都是手工构建，没有建立定时任务，执行shell命令python pytest -m测试用例的路径，

设置生成allure报告，建立邮件提醒，后面的工作当中，如果要运行 pytest框架编写脚本

只需要通过svn把代码导入到svn服务器，手工构建，运行完成后，发送邮件提醒运行结束，如果有错误，可以在jenkins平台里面去查看allure报告。

搭建环境这块，原来不是我做的，大概的流程。

原来我们构建测试环境，先建一个任务，源码管理，从svn服务器导出源码进行构建，运行she令，包的解压跟替换，重启服务，建立一个邮件提醒。后期每次需要提测或者转测的时候，只需要去手动构建这个任务即可。里面还有一些，dev环境，部署，线上环境部署，但是一般我们测试就没有怎么操作，但是原理都是一样。

二十、场景问题

20.1 有没有抓过包，为什么要抓包，具体怎么做的?

抓包这块，其实我们在工作用得是比较多的，一般我们都在测试过程碰到问题，我们有的候通过抓包去看一下前端与后台的数据交互，通过分析这个数据，来定位到底是前端问题，还是后台问题。

主要用的就是fiddler工具，如果只是抓取Web端数据的话，只要在浏览器上设置代理服务器，指定代理服务器为本地的fiddler这个工具，设置好端口：8888 就可以了，如果要抓取手机端的包，首先需要保证手机与电脑(安装了 fiddler的这个电脑)在同一个网络，在手机上要设置http代理服务器为手动，然后服务器指定为电脑的ip地址，端口设置为8888

例外，如果要抓取https包，可能还需要在电脑上安装证书，手机端这边也要安装证书，差不多这样就可以。

20.2 为什么要进行抓包?具体怎么分析的?

主要是我们在测试过程中，出现Bug的时候，为了定位问题，分析问题，需要抓取前端后台的数据交互过程，通过看数据，从而来分析到底是前端问题还是后台问题

分析这块的话：

1、首先看发的请求是否有问题，请求的接口url是否有错误，参数是否有错误，如果url或传参有问题那就是前端Bug

2、如果请求没有问题，看下后台返回的数据是否有问题，状态码5开头的基本都是后台问题，状态码为200，响应数据与预期不一致，那也是后台Bug，不过这里有可能是数据库问题，也有可以是后台代码问题，这里首先我一般会查看下数据库的数据，如果数据库没有问题，那就需要查看下后台的日志文件，具体分析下看是后台代码哪里出问题了，然后把日志信息信息截图给开发，

3、返回的数据没有问题，请求参数，u也没有问题，那可能是前端代码是否转换有问题，那就是前端Bug

20.3 大概给我讲下抓包的原理?

其实就是把fiddler设置为代理服务器，那么浏览器上发出所有请求都由 fiddler这个工具来代理转发，其实就是说：通过fiddler来拦截客服端与服务端之间的数据交互，这样我们可以拦截到客户端给服务器发了什么数据，服务器给客户端响应了什么数据，然后对数据进行分析。

20.4 给你一个需求，你具体讲下，你怎么测试?

第一点：首先我要熟恶这个需求的背景，这个需要功能，我至少要知道这个需求做的是什么吧，做的是一个什么样的解决方法这个要搞清楚。

第二点：这些搞清楚，看这个需要和其他模块有哪些交互，需不需要关联起来分析，有没有影响到其他模块，或者数据有没有流向其他模块。

第三点：这些都清楚了，那么我会根据熟悉的情况看下工作量，哪个时间点交付，在这个时间点我需要做一个计划给老大说下，如果时间充分，一个人能搞定，那么就一个人搞定，搞不定，我会向老大申请人力。其实接下来也差不多了，分析需求，尽量要评审，在前期就保证好质量，如果没有问题。其他也就是用例实例化，执行啊，bug跟踪啊等，最后出个报告就好了。

基本我做的活，会这么做主要看你在最短时间把需求吃透，做好计划，展开工作。

20.5 给你一个项目，你怎么展开工作，请详细说一下，你具体怎么做的

面试官考的点：进我公司，给你一个项目，你怎么做，看你有没有独立做项目能力

第一点：首先我要熟悉这个项目的背景，我至少要知道这个项目做的是什么吧，做的是一个什么样的解决方法这个要搞清楚

第二点：这些搞清楚，那么必须要清楚这个项目的核心模块和业务，我们给这个模块做一个优先级，先测试哪些核心模块，再做哪些模块

第三点：根据刚刚信息，我会熟悉这个业务，这个业务相关模块，以及写数据前后台交互等

第四点：这些都熟恶了，那么我会根据熟悉的情况看下工作量，哪个时间点交付，在这个时间点我需要做一个测试计划一般需求分析的话，根据我的经验基本2天差不多了，编写用例时间，执行时间，bug修复时间，我会做一个工作量评估，如果还有其他测试，我会把这个计划发给大家，让大家评审这个计划和安排，看安排是否合理，大家能不能在这个计划时间段完成，基本需求分析等多给个2天左右，那么大家要再这个时间段完成，完成后我会安排大家讲解需求，做需求评审和需要讲解，前期时间多投入点，后面风险小一点，这个我主要跟进下进度就行。

第五点：那么接下来，大家按照计划去编写用例，用例在时间点完成后，我会组织大家评审，这个两个我必须把控，减少后面测试风险，前面分析和用例把握到位，后续执行和bug这块不会有太多问题后续的话，那么大家执行就行，我主要跟进这个进度，每天大家bug解决情况，以及测试进度，做成日报，像些问题不好解决的，有问题的，我去协助那么测试完成后，我会收集大家测试数据，做一份测试报告，这个我会评估这个测试有没有风险，没有的话，发送给开发老大，开发所有人，测试所有人。这块评审下，后续组织测试人员安排上线，我基本是这么做的