广告平台服务端实习

有一次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(*) from 
low_quality where time > 'now()-4h' 
group by adv_name having count(*)>=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" :...@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对比，如果一样，说明断言正确。

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

实习期间有没有遇到什么棘手的问题，怎样解决

有：当针对单个进行接口测试case维护的时候。当新增的接口测试case在原有的基础上面时候，如果原有的case数量比较多，需要保证新的case和老的case兼容。

方案一：完善接口文档，对于接口的主要功能有一个大致描述。

方案二：代码覆盖率查看：借助覆盖率看板，查看一次执行接口测试覆盖了多少代码。

方案三：查看以往测试报告，以往测试报告当中，有没有哪些执行没有通过的断言

方案四：增量模型：新增的case对应新增的代码，有没有覆盖到

Q5：mediago的主要业务相关

5.1广告平台的主要流程

1. 公司注册与认证(广告主通常和公司是同一个主体)

公司注册：广告主首先需要在平台上注册公司信息，包括公司名称、地址、联系方式等。
资质认证：平台会对公司进行资质审核，确保其合法性和真实性。可能需要提交营业执照、税务登记证等文件。

2. 广告主账户创建(一个账户只可以绑定一个公司)

账户创建：通过认证的公司可以创建广告主账户，设置登录信息、联系方式和支付方式。
权限管理：广告主可以为团队成员分配不同权限，如管理员、操作员等。

3. 广告账户管理

账户创建：广告主可以在广告主账户下创建多个广告账户，用于不同广告活动或品牌。
预算设置：为每个广告账户设置预算，控制广告投放的总支出。

4. 广告实体创建(广告实体必须绑定一个广告账户，一个广告账户下可以有多个广告)

广告计划：广告主在广告账户下创建广告计划，设定目标、预算、投放时间等。
广告组：在广告计划下创建广告组，定义受众、投放位置、出价策略等。
广告创意：为广告组设计广告素材，包括文案、图片、视频等。

5. 广告审核

内容审核：平台会对广告创意进行审核，确保符合政策和法规。
技术审核：检查广告素材的技术规格，确保正常展示。

6. 广告投放

投放启动：审核通过后，广告主可以启动投放，广告将根据设定的策略展示给目标受众。
实时监控：广告主可以实时监控广告效果，如点击率、转化率等。

7. 数据统计与分析(选)

数据收集：平台收集广告投放数据，包括展示次数、点击次数、转化次数等。
数据分析：广告主可以通过平台的分析工具评估广告效果，优化投放策略。

8. 结算与支付(选)

费用结算：平台根据广告投放情况生成账单，广告主需按时支付。
发票管理：广告主可以在平台上下载发票，用于财务报销。

5.2整个广告系统的盈利体系是怎样的

公司付钱给谁

广告主(公司)付钱给广告平台，广告平台再把部分收入分给媒体渠道(展示广告的媒体)

具体流程：

广告主支付广告费：
广告主根据广告的计费方式（如CPM、CPC、CPA）向广告平台支付费用。

广告平台分配收入：
广告平台将部分收入分给媒体渠道（如网站、APP），因为这些渠道提供了广告展示的流量。

媒体渠道获得分成：
媒体渠道通过展示广告获得收入分成。

举例：

广告主支付100元给广告平台，广告平台将其中70元分给媒体渠道，自己保留30元作为服务费。

5.3广告主赚的是谁的钱

广告主赚的是最终用户（消费者）的钱。广告主通过广告吸引用户完成特定行为（如购买商品、注册服务），从而从用户身上获得收入。

具体流程

广告主投放广告：
广告主在广告平台上创建广告，设定目标受众和预算。

用户看到广告：
广告通过平台展示给目标用户。

用户完成行为：
用户点击广告后，可能会购买商品、注册服务或完成其他目标行为。

广告主获得收入：
用户的行为直接或间接为广告主带来收入（如商品销售、服务订阅）。

举例：

一个电商广告主在广告平台上投放广告，用户点击广告后购买商品，广告主从用户的购买行为中赚取利润。

5.4用户点击广告之后谁赚钱了？

具体流程：

用户点击广告

用户看到广告并点击，进入广告主的落地页。

广告主支付费用

用户看到广告并点击，进入广告主的落地页。

用户完成行为

如果用户完成购买、注册等行为，广告主从用户身上赚取收入

广告平台获得收入

广告平台从广告主的支付中获取收入（如点击费用、展示费用）。

举例：

用户点击广告后，广告主支付1元给广告平台（CPC模式）。
用户购买商品，广告主赚取50元利润。

5.5广告平台的收益来源

广告平台的收益主要来自以下几个方面：

(1) 广告投放收入

计费模式：

广告平台根据广告主的计费方式（如CPM、CPC、CPA）收取费用。

收入规模：

广告投放收入是广告平台最主要的收益来源。

(2) 技术服务费

高级功能：

广告平台可能对精准定向、数据分析等高级功能收取额外费用。

API接入：

广告主通过API接入广告平台时，可能需要支付技术服务费。

(3) 数据服务收入

数据分析：

广告平台提供详细的数据分析报告，帮助广告主优化广告投放策略，并收取数据服务费。

用户画像：

广告平台通过分析用户行为数据，生成用户画像，并向广告主出售这些数据。

(4) 增值服务收入

创意设计：

广告平台提供广告创意设计服务，帮助广告主制作高质量的广告素材。

代运营服务：

广告平台为广告主提供广告代运营服务，收取服务费。

5.5 资金流动总结

以下是广告系统中资金流动的简化示意图：

广告主：

支付广告费给广告平台。

从用户身上赚取收入（如商品销售、服务订阅）。

广告平台：

从广告主处收取广告费。

将部分收入分给媒体渠道。

通过数据服务、增值服务等获取额外收入。

媒体渠道：

从广告平台处获得收入分成。

用户：

通过购买商品或使用服务，为广告主创造收入。

举例说明

假设一个电商广告主在广告平台上投放广告：

广告主支付100元给广告平台（CPC模式，每次点击1元，预计100次点击）。

广告平台将70元分给媒体渠道（如网站、APP），自己保留30元。

用户点击广告后购买商品，广告主从用户身上赚取50元利润。

广告平台通过数据分析和增值服务，额外赚取20元。

总结

广告主赚的是用户的钱，通过广告吸引用户完成购买、注册等行为。

广告主支付广告费给广告平台，广告平台将部分收入分给媒体渠道。

广告平台的收益主要来自广告投放收入、技术服务费、数据服务收入和增值服务收入。

用户通过点击广告和完成行为，为广告主和广告平台创造价值。