目录
Q1:觉得这一段实习跟百度网盘服务端的有什么区别？
移动端和pc端
测试方式的不同
百度网盘：
mediago：
觉得两种测试方式哪种更加好？
移动端和pc端测试的其他区别：
平台和环境：
功能测试：
使用场景和操作方式：
Q2:讲一下印象深刻的BUG
Q3:讲一下线上的监控脚本这个是干什么的？可以讲一个具体的监控的case吗
监控脚本的代码结构：
监控的编写流程：
当遇到报警的时候，我们怎样处理：
一个报警的具体案例可以讲一下吗？
低质量广告监控案例：
什么情况下监控的case会下线
mediago平台有哪些功能
功能1：创建投放账户
功能2：账户绑定公司
功能3：创建广告功能
功能4：审核广告
一个广告一般会包含哪一些内容
基本内容相关：
广告定向：
用户相关：
Q4:简历里面提到了自动化测试，讲一下自动化测试有关系的内容
自动化测试的应用场景？实习过程哪些地方用到了自动化测试？接口自动化测试流程
接口自动化测试流程
接口自动化测试怎样编写断言的？
第一种特殊的情况：参数化
参数化的其他应用场景：
如何监控接口的断言：
如果开发对代码进行了改动，这种情况怎么办：
接口自动化的过程，发现了什么bug？
第二种特殊的情况：cookie失效问题
第三种特殊的情况：需要借助平台查询db
新增company接口
companyList接口
编写断言的操作：在新增company这个接口处，添加两个后置操作：
第一个后置操作：获取公司的companyID
第二个后置操作：获取跟这个companyID绑定在一起的logID
第三步：比较环境变量和接口返回值的差别
Q1:觉得这一段实习跟百度网盘服务端的有什么区别？
移动端和pc端
在这一段实习当中，我主要负责的是出海广告投放平台mediago的服务端测试。本段实习当中，测试的流程与百度网盘实习的最大区别在于：mediago系统没有移动端，呈现给使用的用户的是一个pc端的应用程序。也就是因为存在这样的差异，所以我们测试的时候也有一定的区别：
测试方式的不同
百度网盘：
在百度网盘的时候，rd同学提测会发来一个提测报告，上面写明改动的代码是什么，以及本次改动代码涉及到哪些接口。测试的时候，更加关注的是后端白盒代码的测试。主要是白盒测试。
mediago：
前后端一起测试：一个需求的改动可能涉及到前端代码和后端代码的改动。测试的时候，直接站在用户的角度进行测试。有的时候为了构造一些特定的业务场景，可能会在数据库当中构造数据来进行测试。这边的测试更加偏向于灰盒测试。无需关注代码的具体实现。
觉得两种测试方式哪种更加好？
这个问题等同于提问：灰盒测试和白盒测试有什么不同，哪种测试方式更加优胜？
回答：两种测试方式各自有各自的优点：
白盒测试可能更加关注代码的执行逻辑，覆盖率比较高。但是灰盒测试或者黑盒测试站在用户的角度体验，功能可能更加全面。
同时：当一个需求改动代码特别多的时候，可能更加倾向于灰盒测试或者黑盒测试。
因为白盒测试所编写的case数量如果想覆盖到全部的功能，可能难度比较大而且容易遗漏。因此当改动代码量比较大的时候，可以选择使用灰盒测试来代替白盒测试，关注执行的结果即可。
移动端和pc端测试的其他区别：
平台和环境：
移动端测试主要针对的是在移动设备上运行的应用程序，需要考虑不同的操作系统（如iOS、Android等）、设备型号和屏幕分辨率。而PC端测试则针对在个人计算机上运行的应用程序，需要考虑的主要是不同的操作系统和硬件配置。
功能测试：
移动应用可能需要测试一些特定的功能，如手势操作、传感器的使用等，而PC端测试则可能需要关注如文件管理、网络连接等功能。这些不同的功能需求使得移动端和PC端在功能测试方面存在明显的差异。
使用场景和操作方式：
移动端的使用场景比PC端更复杂，包括户外、公交地铁、办公室等多种环境，且操作方式主要是触屏传感器。而PC端的使用场景则相对固定，主要依赖鼠标、键盘等外设进行操作。
Q2:讲一下印象深刻的BUG
在mediago系统测试的时候，给我的体验就是，每一个pm提出来的需求，都有一个对应使用的角色。例如，有的需求是提供给超级管理员使用的，有的是提供给广告主使用的。所以，在测试之前，一定要使用对应权限的测试账号来测试，否则容易出现越权的问题；
有一次PM同学提出来一个需求，这个需求是提供给超级管理员使用的，这个需求是超级管理员可以增加一项权限：他可以调整对应注册客户的一个属性的值——当月广告投放的最大金额。然后这个客户旗下对应的广告主的金额也会跟着修改。这一项权限是只有超级管理员才有的，普通的广告主没有这一项权限。我测试的时候是使用普通超级管理员的角色来测试的。但是测试完这个需求之后，我使用普通广告主的测试账号登录，发现也可以修改。
在发现了这个问题之后，及时跟rd和PM同学确认，后面就修复了这个bug，改为：只有超级管理员才有权限调用这个接口，普通的广告主没有这一项权限。
Q3:讲一下线上的监控脚本这个是干什么的？可以讲一个具体的监控的case吗
监控脚本的代码结构：
这一块脚本的代码主要分为两部分：一部分是执行的case命名，放到一个sql_monitor_hourly文件当中（每一小时执行一次）。另一部分是case的具体实现；
其中还有一个文件是存放case命名的，这个文件是：sql_monitor_10_minute（每十分钟执行一次）。
在这两个文件当中定义case的方法。方法的入参就是报警的对象，例如：wangjiaxin09等等。
我们后面查看报警信息，就是在一个监控群里面查看，他报警的时候会@对用的人。
监控的编写流程：
当rd同学需要编写某一个监控的sql的时候，他会先确定好编写sql的内容，以及断言的条件是什么，也就是报警的条件是什么，以及这个报警是多久执行一次（10分钟一次或者一个小时一次）
然后报警的内容是什么。
当确定好这些内容之后，我们QA同学就会把case写到对用的代码当中，方法入参填写报警的对象，方法体填写报警的逻辑（例如当sql查询出来>0的时候报警等等）
编写好之后，先在本地测试一下效果，然后再部署上线。
当遇到报警的时候，我们怎样处理：
当遇到报警的时候，我们这边一般习惯的除磷方式是，对于某一个case，如果连续3次以上报警，那么我们就要查看一下是不是出了一些问题。连续三次以内的报警一般可以忽略掉。
一个报警的具体案例可以讲一下吗？
低质量广告监控案例：
当有一些广告呈现给用户看的时候，有一个按钮就是“对该广告不感兴趣”。如果用户点击了这个按钮，那么此条广告就不会呈现给用户看，同时也往一个低质量表当中插入一条数据；这条数据包含：此广告的id，广告的名称，用户点击低质量广告的时间。
在某段时间内，运营告诉我们低质量广告在最近数量增加有点多，于是我们加了一个监控，监控的规则就是：当4个小时内，如果有某个广告被标记了3次以上低质量，那么我们就会把这个低质量的广告反馈给运营，让他们调整这个广告的信誉度；
查询的sql语句如下：
select adv_name ,count(id) as counted from
low_quality where time > 'now()-4h'
group by adv_id having counted>=3
当查询的结果不为null的时候，我们就会触发告警，告警信息是：此广告在过去4小时内被连续标记为低质量广告，广告名称是：某某某，请运营同学重新审核此条广告。
什么情况下监控的case会下线
我们加一个监控，说明这个监控的对象是我们需要关注的内容。当case下线的时候，说明这个问题已经解决了。
在上述的案例当中，如果运营审核人员负责的部份新增了一个内容，就是对于低质量广告的审核平台，运营人员可以定时查看这个低质量平台审核的广告内容，说明不再需要监控了，可以下线。
mediago平台有哪些功能
功能1：创建投放账户
创建广告的时候，需要选择对应的广告账户。
一个广告主可以创建多个账户，一个账户下面又可以创建多个广告。
功能2：账户绑定公司
每一个账户只能绑定一个公司，但是一个公司可以绑定多个账户；二者的关联关系在一个account_company表当中；这个表里面有两个字段，一个是company_id；另一个是account_id。
功能3：创建广告功能
创建广告的时候，需要选择对应的账户。一个广告主下面可能有多个账户，每一条创建的广告都会对应一个账户。
广告如果开启了投放开关，那么就会产生费用。如果没有开启投放开关，那么创建好的广告也不会被投放出去，只会存在当前账户的广告列表下面。
功能4：审核广告
这一项工作是由运营的人员负责的，当广告投放开关打开的时候，运营人员会审核对应的广告，标记为审核通过/审核不通过。同时对于用户多次反馈的一些低质量广告，可以降低此账户的信誉度。
一个广告一般会包含哪一些内容
基本内容相关：
广告素材名称；
广告素材图片；
这个广告的链接，也就是点击了这个链接之后跳转到哪个网站；
创建广告的账户；
广告定向：
广告类别（平台已经限定死了的：健康，视频，旅行，新闻等等）
广告投放的地区（加拿大，美国，日本等等）
广告推荐的群体（学生，各个职业......)
投放的时间（什么时候展示给用户）
展示的时间（一个时间段，在这个时间段内会展示给用户看）
展示的具体平台（广告展示在哪个媒体平台上面，例如微软等等）
会根据广告主设置的时间，地区产生费用
用户相关：
点击量；
点击率（实际点击广告的人数/总浏览人数）；
定向投放的用户；
投放的地区。
Q4:简历里面提到了自动化测试，讲一下自动化测试有关系的内容
自动化测试的应用场景？实习过程哪些地方用到了自动化测试？接口自动化测试流程
接口自动化测试流程
对于自动化测试，我们这边最常见的应用场景就是用于回归测试。
除了验证新的接口功能以外，我们还会把原来的用例都走一遍，只有把其他的用例都走通，才算测试通过；
当rd改动一个接口的时候（例如改动接口传入的参数，接口的出参，接口的逻辑，或者这个接口可能被其他的模块调用等等业务场景）的时候，我们就需要对于这个接口添加测试用例；
添加完接口测试用例之后，先在本地运行，当全部用例都运行通过之后，再部署到自动执行的用例列表，每天会定时执行。
接口自动化测试怎样编写断言的？
除了要对基本的状态码进行断言，我们也要对sql等内容进行断言；举个例子：当执行一个更新的接口：account，也就是编辑公司的这个接口。
当我们请求这个接口，得到正确的响应状态码之后，还需要在接口测试平台上面编写sql语句查询这个编辑之后的效果是否符合预期，只有符合预期，才可以推进上线；
第一种特殊的情况：参数化
有一个接口是account，新增公司。但是有一条规定：公司的名称不可以重复。那么这个时候，如果把account接口的companyName写死，会引发报错，所以有时候要采用参数化的方式，把公司的名称参数化，然后再编写sql查询对应名字的公司是否新增成功，断言各个字段是否符合预期。
参数化：在平台上面设置参数化规则：我这边设置的规则就是：公司名称+datetime()获得时间戳.
参数化的其他应用场景：
例如：当我想获取某个实时更新的数据表格，这个时候，必须要查询最新的日期，那么就需要把这个查询的日期做成参数化：比如：now(date() -1 day)这样的。
如何监控接口的断言：
编写好测试的接口case之后，就会生成一个链接；点击这个任务链接之后，相当于运行一次。运行一次之后，就会生成一个测试报告。
如果开发对代码进行了改动，这种情况怎么办：
我们这边有一个测试流水线的步骤：
第一步，开发提测，会经过自动化测试的这一个步骤；
第二步，到了自动化测试这个时候：选择以下的内容：
①：在这个流水线上面设置执行的时间（也就是每隔多久执行一次）；
②：添加执行的任务链接；
③：添加告警的对象，可以是个人，也可以是群聊；如果是个人，会往一个公众号里面发送消息；如果是一个群聊，那么就会在群里发送消息；
④发送的消息就是输出的测试报告的内容。
在第二步骤当中，相当于在一个服务器上面定时执行上述的任务：
流水线的好处就在于，只要其中的第一个步骤发生了改变，那么后面的步骤也需要跟着改变。
所以开发如果更改了代码库，那么第一步就会被破坏，需要重新部署这个流水线。那么这个时候我们就可以在工具平台上面更改执行内容（iapi上面更新，然后重新部署）。
接口自动化的过程，发现了什么bug？
在接口自动化测试的过程当中，我比较印象深刻的就是一个。
大致需求的背景是这样的：
有一个接口新增了一个字段，公司新增字段（直客，代理商）；其他有关的属性没有改变过。
改动的接口为：新增company，编辑company
然后我们本地就抓取到编辑company这个接口的curl；为了提高功能的覆盖率，编辑company这个接口的每一个字段我们在编辑之后都设置了新的值。
但是在后面执行编辑company接口的时候，我添加了数据库的断言，断言是否编辑成功的效果；
就发现：有一个字段虽然我传入了新的值，但是实际在数据库当中查询出来的结果不是那一个。也就是数据库断言失败了
关于这个bug，如果没有添加这种回归的用例，确实比较难发现。所以自动化测试最大的用处：回归测试由此可以见得。
第二种特殊的情况：cookie失效问题
当把接口curl下来之后，这个header当中的cookie的有效期只有24小时有效；如果超过24小时，那么这个cookie就会失效，对于这个问题如何解决？
自动化测试的时候，在登录的接口当中获取登录的cookie信息，也就是set-cookie字段的内容；
把这个字段的内容保存到全局cookie当中，然后其他的case勾选：使用全局cookie，然后去掉原有的请求头当中的cookie，这样，每次自动化请求的时候就使用的是最新登录时候的cookie。
第三种特殊的情况：需要借助平台查询db
新增company接口
当我写一个新增company的接口用例的时候，除了会在company表当中新增一个公司实体，也会提交另一个实体log。
{
"companyName" :"www"
.....
log:[
{
"email" :...@
"time" : dateTime()
}
]
}同时也会往一个日志表（log）当中插入一条数据，插入的数据是：操作人的百度邮箱，操作的时间，以及新增company的主键id。
新增成功之后，会在返回值当中包含一个companyID，但是不会包含logID。
{
"code" :0
"companyID" :111
"msg":success
}companyList接口
当请求companyList接口查询company列表的时候，前端也不会展示出对应的log信息；但是在list接口当中会返回一个log实体；
{
{
"companyID" :1
"companyName" :"www"
.....
log:
[
{
"logID" : 1111
"companyID" :111
"email" :...@
"time" : dateTime()
}
]
}
}对于返回的log实体当中，可以看到多了一个字段：logID。
如果想断言这个logID字段的值，那么就需要借助平台的读取db的功能了。
因为新增log的时候，没有传入logID，但是返回的实体当中却有这个字段，这个logID是数据库当中自动生成的。
编写断言的操作：在新增company这个接口处，添加两个后置操作：
第一个后置操作：获取公司的companyID
由于新增company接口返回的字段当中包含一个companyID字段
因此需要把这个companyID保存为环境变量，提取这个companyID的值；
第二个后置操作：获取跟这个companyID绑定在一起的logID
添加数据库断言，查询log表，传入保存为环境变量的companyID
select* from log where companyID={{companyID}}查询之后，提取这个log字段的值，继续把这个logID保存为环境变量。
第三步：比较环境变量和接口返回值的差别
在companyList接口当中，为这个logID编写断言的时候，让接口返回的字段的值和环境变量当中的logID对比，如果一样，说明断言正确。
以上步骤，我们需要做到，对于接口返回的每一个字段都需要有断言，断言不可以不写，也不可以漏写，或者断言失败
实习期间有没有遇到什么棘手的问题，怎样解决
有：当针对单个进行接口测试case维护的时候。当新增的接口测试case在原有的基础上面时候，如果原有的case数量比较多，需要保证新的case和老的case兼容。
方案一：完善接口文档，对于接口的主要功能有一个大致描述。
方案二：代码覆盖率查看：借助覆盖率看板，查看一次执行接口测试覆盖了多少代码。
方案三：查看以往测试报告，以往测试报告当中，有没有哪些执行没有通过的断言
方案四：增量模型：新增的case对应新增的代码，有没有覆盖到