第6章 测试&上线流程

第6章 测试&上线流程

6.1 测试相关

6.1.1 公司有多少台测试服务器？

测试服务器一般三台。

6.1.2 测试服务器配置？

有钱的公司和生产环境电脑配置一样。

一般公司测试环境的配置是生产的一半。

6.1.3 测试数据哪来的？

一部分自己写Java程序自己造（更灵活），一部分从生产环境上取一部分（更真实）。

6.1.4 如何保证写的SQL正确性（重点）

先在MySQL的业务库里面把结果计算出来；在给你在ads层计算的结果进行比较；

需要造一些特定的测试数据，测试。

从生产环境抓取一部分数据，数据有多少你是知道的，运算完毕应该符合你的预期。

离线数据和实时数据分析的结果比较。（日活1万  实时10100），倾向取离线。

算法异构

6.1.5 测试之后如何上线？

大公司：上线的时候，将脚本打包，提交git。先发邮件抄送经理和总监，运维。运维负责上线。

小公司：跟项目经理说一下，项目经理技术把关，项目经理通过了就可以上线了。风险意识。

所谓的上线就是编写脚本，并在DolphinScheduler中进行作业调度。

6.1.6 A/B测试了解

1）什么是 A/B 测试？

A / B测试本质上是一种实验，即随机向用户显示变量的两个或多个版本，并使用统计分析来确定哪个变量更适合给定的转化目标。

2）为什么要做A/B测试？

举例：字节跳动有一款中视频产品叫西瓜视频，最早它叫做头条视频。为了提升产品的品牌辨识度，团队想给它起个更好的名字。经过一些内部调研和头脑风暴，征集到了西瓜视频、奇妙视频、筷子视频、阳光视频4个名字，于是团队就针对一共5个APP 名称进行了A/B实验。

这个实验中唯一改变的是应用市场里该产品的名称和对应的logo，实验目的是为了验证哪一个应用名称能更好地提升“头条视频”APP在应用商店的点击率。最后西瓜视频和奇妙视频的点击率位列前二，但差距不显著，结合用户调性等因素的综合考量，最终决定头条视频正式更名为西瓜视频。

通过这个案例可以看到，A/B测试可以帮助业务做最终决策。结合案例的直观感受，我们可以这样来定义A/B 测试：在同一时间对目标受众做科学抽样、分组测试以评估效果。

以上图图示为例，假设我们有100万用户要进行A/B测试：

先选定目标受众，比如一线城市的用户。A/B测试不可能对所有用户都进行实验，所以要进行科学抽样，选择小部分流量进行实验。

1. 抽样之后需要对样本进行分组，比如A组保持现状，B组的某一个因素有所改变。
2. 分组之后在同一时间进行实验，就可以看到改变变量后用户行为的变化。
3. 再根据对应实验目标的指标，比如点击率的高低，来评估实验的结果。

做A/B测试的主要原因有3点：

（1）风险控制：小流量实验可以避免直接上线效果不好造成损失。其次，实验迭代的过程中，决策都是有科学依据的，可以避免系统性的偏差。

（2）因果推断：我们相信A/B实验中的优化和改变最终能影响到线上数据以及用户的行为。在这个前提下，A/B测试就是最好的因果推断工具。

（3）复利效应：A/B测试是可以持续不断进行的实验，即使一次实验提升的效果不大，但是长期下来复利效应的积累会产生很大的变化和回报。

3）哪个首页新UI版本更受欢迎

今日头条UI整体风格偏大龄被诟病已久，不利于年轻和女性用户泛化，历史上几次红头改灰头实验都对大盘数据显著负向。因此团队设计了A/B实验，目标是在可接受的负向范围内，改一版用户评价更好的UI。通过控制变量法，对以下变量分别开展数次A/B实验：

头部色值饱和度、字号、字重、上下间距、左右间距、底部 tab icon。

结合用户调研（结果显示：年轻用户和女性用户对新 UI 更偏好）。

综合来看，效果最好的 UI 版本如下图所示，全量上线。

新 UI 上线后，Stay duration 显著负向从-0.38% 降至 -0.24%，图文类时长显著 +1.66%，搜索渗透显著 +1.47%，高频用户（占 71%）已逐渐适应新 UI。

6.2 项目实际工作流程

以下是活跃用户需求的整体开发流程。

产品经理负责收集需求：需求来源与客户反馈、老板的意见。

第1步：确定指标的业务口径

由产品经理主导，找到提出该指标的运营负责人沟通。首先要问清楚指标是怎么定义的，比如活跃用户是指启动过APP的用户。设备id 还是用户id。

产品经理先编写需求文档并画原型图。=》需求不要口头说。

第2步：需求评审

由产品经理主导设计原型，对于活跃主题，我们最终要展示的是最近n天的活跃用户数变化趋势 ，效果如下图所示。此处大数据开发工程师、后端开发工程师、前端开发工程师一同参与，一起说明整个功能的价值和详细的操作流程，确保大家理解的一致。

工期：

接口：数据格式、字段类型、责任人。

第3步：大数据开发

大数据开发工程师，通过数据同步的工具如Flume、Datax、Maxwell等将数据同步到ODS层，然后就是一层一层的通过SQL计算到DWD、DWS层，最后形成可为应用直接服务的数据填充到ADS层。

第4步：后端开发

后端工程师负责，为大数据工程师提供业务数据接口；

同时还负责读取ADS层分析后，写入MySQL中的数据。

第5步：前端开发

前端工程师负责，前端埋点。

对分析后的结果数据进行可视化展示。

第6步：联调

此时大数据开发工程师、前端开发工程师、后端开发工程师都要参与进来。此时会要求大数据开发工程师基于历史的数据执行计算任务，大数据开发工程师承担数据准确性的校验。前后端解决用户操作的相关BUG保证不出现低级的问题完成自测。

第7步：测试

测试工程师对整个大数据系统进行测试。测试的手段包括，边界值、等价类等。

提交测试异常的软件有：禅道（测试人员记录测试问题1.0，输入是什么，结果是什么，跟预期不一样->需要开发人员解释，是一个bug，下一个版本解决1.1->测试人员再测试。测试1.1ok->测试经理关闭bug）

1周开发写代码 =》2周测试时间

第8步：上线

运维工程师会配合我们的前后端开发工程师更新最新的版本到服务器。此时产品经理要找到该指标的负责人长期跟进指标的准确性。重要的指标还要每过一个周期内部再次验证，从而保证数据的准确性。

6.3 项目中实现一个需求大概多长时间

1）刚入职第一个需求大概需要7天左右。对业务熟悉后，平均一天一个需求。

2）影响时间的因素：对业务熟悉、开会讨论需求、表的权限申请、测试等。新员工培训（公司规章制度、代码规范）

6.4 项目当前版本号是多少？多久升级一次版本

敏捷开发（少量需求=>代码编写=>测试=>少量需求=>代码编写=>测试…），又叫小步快跑。

差不多一个月会迭代一次。每月都有节日（元旦、春节、情人节、3.8妇女节、端午节、618、国庆、中秋、1111/6.1/5.1、生日、周末）新产品、新区域。

就产品或我们提出优化需求，然后评估时间。每周我们都会开会做下周计划和本周总结。（日报、周报、月报、季度报、年报）需求1周的时间，周三一定完成。周四周五（帮同事写代码、自己学习工作额外的技术）。

5.1.2

5是大版本号：必须是重大升级

1：一般是核心模块变动

2：一般版本变化

6.5 项目开发中每天做什么事

（1）新需求（活动、优化、新产品、新市场）。  60%

（2）故障分析：数仓的任何步骤出现问题，需要查看问题，比如日活，月活下降或快速上升等。20%

（3）新技术的预言（比如湖仓一体   数据湖   Doris  实时数据质量监控）10%

（4）其临时任务  10%

（5）晨会-》10做操-》讨论中午吃什么-》12点出去吃1点-》睡到2点-》3点茶歇水果-》晚上吃啥-》吃加班餐-》开会-》晚上6点吃饭-》7点开始干活-10点-》11点