【百度实习总结】百度国际化产品研发中心——mediago服务端测试开发实习-CSDN博客

有一次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 from 
low_quality where time > 'now()-4h' 
group by adv_id having count(adv_id)>=3

当查询的结果不为null的时候，我们就会触发告警，告警信息是：此广告在过去4小时内被连续标记为低质量广告，广告名称是：某某某，请运营同学重新审核此条广告。

mediago平台有哪些功能

功能1：创建投放账户

创建广告的时候，需要选择对应的广告账户。

一个广告主可以创建多个账户，一个账户下面又可以创建多个广告。

功能2：账户绑定公司

每一个账户只能绑定一个公司，但是一个公司可以绑定多个账户；二者的关联关系在一个account_company表当中；这个表里面有两个字段，一个是company_id；另一个是account_id。

功能3：创建广告功能

创建广告的时候，需要选择对应的账户。一个广告主下面可能有多个账户，每一条创建的广告都会对应一个账户。

广告如果开启了投放开关，那么就会产生费用。如果没有开启投放开关，那么创建好的广告也不会被投放出去，只会存在当前账户的广告列表下面。

功能4：审核广告

这一项工作是由运营的人员负责的，当广告投放开关打开的时候，运营人员会审核对应的广告，标记为审核通过/审核不通过。同时对于用户多次反馈的一些低质量广告，可以降低此账户的信誉度。

一个广告一般会包含哪一些内容

基本内容相关：

广告素材名称；

广告素材图片；

这个广告的链接，也就是点击了这个链接之后跳转到哪个网站；

创建广告的账户；

广告定向：

广告类别（平台已经限定死了的：健康，视频，旅行，新闻等等）

广告投放的地区（加拿大，美国，日本等等）

广告推荐的群体（学生，各个职业......)

投放的时间（什么时候展示给用户）

展示的时间（一个时间段，在这个时间段内会展示给用户看）

展示的具体平台（广告展示在哪个媒体平台上面，例如微软等等）

会根据广告主设置的时间，地区产生费用

用户相关：

点击量；

点击率（实际点击广告的人数/总浏览人数）；

定向投放的用户；

投放的地区。

Q4:简历里面提到了自动化测试，讲一下自动化测试有关系的内容

自动化测试的应用场景？实习过程哪些地方用到了自动化测试？接口自动化测试流程

接口自动化测试流程

对于自动化测试，我们这边最常见的应用场景就是用于回归测试。

除了验证新的接口功能以外，我们还会把原来的用例都走一遍，只有把其他的用例都走通，才算测试通过；

当rd改动一个接口的时候（例如改动接口传入的参数，接口的出参，接口的逻辑，或者这个接口可能被其他的模块调用等等业务场景）的时候，我们就需要对于这个接口添加测试用例；

添加完接口测试用例之后，先在本地运行，当全部用例都运行通过之后，再部署到自动执行的用例列表，每天会定时执行。

接口自动化测试怎样编写断言的？

除了要对基本的状态码进行断言，我们也要对sql等内容进行断言；举个例子：当执行一个更新的接口：account，也就是编辑公司的这个接口。

当我们请求这个接口，得到正确的响应状态码之后，还需要在接口测试平台上面编写sql语句查询这个编辑之后的效果是否符合预期，只有符合预期，才可以推进上线；

第一种特殊的情况：参数化

有一个接口是account，新增公司。但是有一条规定：公司的名称不可以重复。那么这个时候，如果把account接口的companyName写死，会引发报错，所以有时候要采用参数化的方式，把公司的名称参数化，然后再编写sql查询对应名字的公司是否新增成功，断言各个字段是否符合预期。

参数化：在平台上面设置参数化规则：我这边设置的规则就是：公司名称+datetime()获得时间戳

第二种特殊的情况：cookie失效问题

当把接口curl下来之后，这个header当中的cookie的有效期只有24小时有效；如果超过24小时，那么这个cookie就会失效，对于这个问题如何解决？

自动化测试的时候，在登录的接口当中获取登录的cookie信息，也就是set-cookie字段的内容；

把这个字段的内容保存到全局cookie当中，然后其他的case勾选：使用全局cookie，然后去掉原有的请求头当中的cookie，这样，每次自动化请求的时候就使用的是最新登录时候的cookie。

第三种特殊的情况：需要借助平台查询db

新增company接口

当我写一个新增company的接口用例的时候，除了会在company表当中新增一个公司实体，也会提交另一个实体log。

{
  "companyName" :"www"
  .....
  log:[
     {
        "email" :...@baidu.com
        "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" :...@baidu.com
        "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对比，如果一样，说明断言正确。

以上步骤，我们需要做到，对于接口返回的每一个字段都需要有断言，断言不可以不写，也不可以漏写，或者断言失败

实习过程编写的自动化测试场景

新增公司-->新增账户-->编辑公司-->查看编辑公司的效果（sql断言）-->编辑账户--> 查看编辑账户的效果(sql断言)。

以上的过程，当rd需要改动某个接口的时候，我们都会把新增的接口用例先运行通过，然后再部署到自动化环境当中。