More Related Content Similar to work@baidu 2014
Similar to work@baidu 2014 (20) 10. 技术卓越与创新 | 跨部门合作
元芳平台对接MSD
- 为MSD团队提供元芳服务
- 元芳的数据量高于其他外部舆情工具
- 完成MSD提出的新需求并整合到元芳平台
元芳平台对接众测
- 双方都刚刚开始做API开发，及时沟通，2天完成联调
- 2次线上问题，1天内定位解决
- 每日吞吐1.5w标注数据
- 每日数据在3小时内返回，并在元芳平台展现
- 标注准确性提升到97%
10
元芳平台对接风控团队
- 为风控团队提供定向的舆情抓取
- 发布元芳数据访问接口
- 保证风控团队的舆情日历按时上线
15. 跨职能合作与推动 | 我的贡献
Good Coder 之路
QA CMC 第一个通过Good Coder 认证
作为二审向Code Master迈进
参与4人的Good Coder评审
团队建设
面试
技术帮助
新人培训
其他
15
Editor's Notes Agenda
项目测试与贡献
产品和用户导向
技术卓越与创新
跨职能合作与推动
技术卓越与创新（微博抓取）
起因：
UDW断流
过程：
登录、结构：调研spider平台无法满足
量大：日均千万级别
改进：
改为搜索结果抓取
编写登录模块
多线程抓取
成果：
日均9万结果，3小时
正在改造以提供更多服务
另外之前我们是从UDW获取的新浪微博数据，但是去年正在元芳还没接入贴吧数据时，微博的合作到期了，导致数据断流。我们通过调研，发现我厂的各个spider平台，在功能上无法满足新浪微博的抓取需求，最终使得我们开发了自有的新浪微博抓取平台。
之所以其它平台无法满足需求，是因为新浪微博几个限制：第一，需要登录账号、记住cookie才能完整访问，不然只能访问前5条，而且访问页面时有一次http重定向、一次js重定向；第二，较严格的反抓取策略，单账号大约要在1min+才能抓取一次，还时不时出来验证码页面；第三，微博量大，一天数千万的记录数，其实有用的才几万条，这点我们最终也是改变策略，改为抓取微博搜索页面拿到的。基本上，通用的抓取平台容易卡在第一点和第四点，fats则卡在第二点和第三点上。
针对这些，我们设计了一套微博抓取服务，当前只服务于元芳平台，所以是以关键字为抓取目标的。
整个平台设计分为三块：一块是url生成器，与关键词绑定，通过关键词和时间段生成url列表，并负责解析抓取页面的内容；一块是client，和微博账号绑定，拿到url后进行抓取；最后一块是manager，负责merge各待抓取的url列表并分发给可用的client上，并且有监控机制，定时检查client的可用性，将这个client上未抓取的url重新分发给其它client，最后manager还会将结果保存至文件。
这个抓取平台的特点有：支持多产品并行抓取；支持多spider提升抓取速度；自动错误检查；可断点续抓。当前在单机情况下，3小时抓取完元芳所需的一天的微博数据约10万。并且利用富余的抓取能力，为销售监察部提供监控数据。
将来这一块会接口化，对外提供新浪微博关键字内容抓取能力；同时，内部代码结构也会持续调整，便于为其它难搞定的数据源，提供抓取服务。
技术卓越与创新（微博抓取）
起因：
UDW断流
过程：
登录、结构：调研spider平台无法满足
量大：日均千万级别
改进：
改为搜索结果抓取
编写登录模块
多线程抓取
成果：
日均9万结果，3小时
正在改造以提供更多服务
另外之前我们是从UDW获取的新浪微博数据，但是去年正在元芳还没接入贴吧数据时，微博的合作到期了，导致数据断流。我们通过调研，发现我厂的各个spider平台，在功能上无法满足新浪微博的抓取需求，最终使得我们开发了自有的新浪微博抓取平台。
之所以其它平台无法满足需求，是因为新浪微博几个限制：第一，需要登录账号、记住cookie才能完整访问，不然只能访问前5条，而且访问页面时有一次http重定向、一次js重定向；第二，较严格的反抓取策略，单账号大约要在1min+才能抓取一次，还时不时出来验证码页面；第三，微博量大，一天数千万的记录数，其实有用的才几万条，这点我们最终也是改变策略，改为抓取微博搜索页面拿到的。基本上，通用的抓取平台容易卡在第一点和第四点，fats则卡在第二点和第三点上。
针对这些，我们设计了一套微博抓取服务，当前只服务于元芳平台，所以是以关键字为抓取目标的。
整个平台设计分为三块：一块是url生成器，与关键词绑定，通过关键词和时间段生成url列表，并负责解析抓取页面的内容；一块是client，和微博账号绑定，拿到url后进行抓取；最后一块是manager，负责merge各待抓取的url列表并分发给可用的client上，并且有监控机制，定时检查client的可用性，将这个client上未抓取的url重新分发给其它client，最后manager还会将结果保存至文件。
这个抓取平台的特点有：支持多产品并行抓取；支持多spider提升抓取速度；自动错误检查；可断点续抓。当前在单机情况下，3小时抓取完元芳所需的一天的微博数据约10万。并且利用富余的抓取能力，为销售监察部提供监控数据。
将来这一块会接口化，对外提供新浪微博关键字内容抓取能力；同时，内部代码结构也会持续调整，便于为其它难搞定的数据源，提供抓取服务。
技术卓越与创新（微博抓取）
起因：
UDW断流
过程：
登录、结构：调研spider平台无法满足
量大：日均千万级别
改进：
改为搜索结果抓取
编写登录模块
多线程抓取
成果：
日均9万结果，3小时
正在改造以提供更多服务
另外之前我们是从UDW获取的新浪微博数据，但是去年正在元芳还没接入贴吧数据时，微博的合作到期了，导致数据断流。我们通过调研，发现我厂的各个spider平台，在功能上无法满足新浪微博的抓取需求，最终使得我们开发了自有的新浪微博抓取平台。
之所以其它平台无法满足需求，是因为新浪微博几个限制：第一，需要登录账号、记住cookie才能完整访问，不然只能访问前5条，而且访问页面时有一次http重定向、一次js重定向；第二，较严格的反抓取策略，单账号大约要在1min+才能抓取一次，还时不时出来验证码页面；第三，微博量大，一天数千万的记录数，其实有用的才几万条，这点我们最终也是改变策略，改为抓取微博搜索页面拿到的。基本上，通用的抓取平台容易卡在第一点和第四点，fats则卡在第二点和第三点上。
针对这些，我们设计了一套微博抓取服务，当前只服务于元芳平台，所以是以关键字为抓取目标的。
整个平台设计分为三块：一块是url生成器，与关键词绑定，通过关键词和时间段生成url列表，并负责解析抓取页面的内容；一块是client，和微博账号绑定，拿到url后进行抓取；最后一块是manager，负责merge各待抓取的url列表并分发给可用的client上，并且有监控机制，定时检查client的可用性，将这个client上未抓取的url重新分发给其它client，最后manager还会将结果保存至文件。
这个抓取平台的特点有：支持多产品并行抓取；支持多spider提升抓取速度；自动错误检查；可断点续抓。当前在单机情况下，3小时抓取完元芳所需的一天的微博数据约10万。并且利用富余的抓取能力，为销售监察部提供监控数据。
将来这一块会接口化，对外提供新浪微博关键字内容抓取能力；同时，内部代码结构也会持续调整，便于为其它难搞定的数据源，提供抓取服务。
技术卓越与创新（微博抓取）
起因：
UDW断流
过程：
登录、结构：调研spider平台无法满足
量大：日均千万级别
改进：
改为搜索结果抓取
编写登录模块
多线程抓取
成果：
日均9万结果，3小时
正在改造以提供更多服务
另外之前我们是从UDW获取的新浪微博数据，但是去年正在元芳还没接入贴吧数据时，微博的合作到期了，导致数据断流。我们通过调研，发现我厂的各个spider平台，在功能上无法满足新浪微博的抓取需求，最终使得我们开发了自有的新浪微博抓取平台。
之所以其它平台无法满足需求，是因为新浪微博几个限制：第一，需要登录账号、记住cookie才能完整访问，不然只能访问前5条，而且访问页面时有一次http重定向、一次js重定向；第二，较严格的反抓取策略，单账号大约要在1min+才能抓取一次，还时不时出来验证码页面；第三，微博量大，一天数千万的记录数，其实有用的才几万条，这点我们最终也是改变策略，改为抓取微博搜索页面拿到的。基本上，通用的抓取平台容易卡在第一点和第四点，fats则卡在第二点和第三点上。
针对这些，我们设计了一套微博抓取服务，当前只服务于元芳平台，所以是以关键字为抓取目标的。
整个平台设计分为三块：一块是url生成器，与关键词绑定，通过关键词和时间段生成url列表，并负责解析抓取页面的内容；一块是client，和微博账号绑定，拿到url后进行抓取；最后一块是manager，负责merge各待抓取的url列表并分发给可用的client上，并且有监控机制，定时检查client的可用性，将这个client上未抓取的url重新分发给其它client，最后manager还会将结果保存至文件。
这个抓取平台的特点有：支持多产品并行抓取；支持多spider提升抓取速度；自动错误检查；可断点续抓。当前在单机情况下，3小时抓取完元芳所需的一天的微博数据约10万。并且利用富余的抓取能力，为销售监察部提供监控数据。
将来这一块会接口化，对外提供新浪微博关键字内容抓取能力；同时，内部代码结构也会持续调整，便于为其它难搞定的数据源，提供抓取服务。
改进：
改为搜索结果抓取
编写登录模块
多线程抓取
成果：
日均9万结果，3小时
正在改造以提供更多服务
之前工作
性能优化
提升百度统计的前端页面展现性能
无线数据整理 项目测试与贡献（介绍）
司南产品组：
负责司南（专业版）、司南代言人、司南舆情、精算四个产品
简单介绍
难点：
人力比约1:8，且自测
自动化复杂度高，数据耦合严重
Story较多，实际工作量较大
共xxx个story，上线yyy次，
项目测试与贡献（贡献部分）
提早接入，改进送测质量：从MRD、RD评审等开始展现QA能力，改进xxx处
改造、丰富自动化lib库，实现代码xxx行，部署时间从1天降至0.5小时，新功能测试从3天降至1天
推进测试用例前置，改进测试质量，提出bugxxx个
CR改善提测质量
这其中，司南专业版在接手前刚刚经历了一次重大改版，产品代码几乎重写，测试用例几乎全失效；精算也新增两个大功能点；再加上两个1.0的项目，其中还有一个是百度大会展示产品。在人力比长期1:10+的情况下，还长期存在架构的不合理、自测程度低的问题。
改进的点主要有两个：
第一是 提升测试质量，在人力紧张的情况下仍然主动参与MRD评审和详设评审，从前期保证设计质量；同时，广泛采用送测时showcase的方式，从RD处保证送测质量；同时每个story也会由一位QA进行测试用例设计或测试脑图设计后由其它人review，也保证了测试过程质量。另外坚持CR、坚持可自动化测试部分的100%功能覆盖也是保证质量的一部分。
第二是 提升测试效率，一方面是完善测试所需的自动化部署脚本、进一步封装请求脚本，这里相对复杂的后端部署，从10小时降低至1小时，数据准备从无法同步更新优化至同步更新，后端story测试也平均从3人天降低至1人天。另一方面也推进非主要功能的RD自测，周边模块的搭建也拉入RD进行部署，降低工作量，更能focus在主要功能的测试上。 项目测试与贡献（介绍）
司南产品组：
负责司南（专业版）、司南代言人、司南舆情、精算四个产品
简单介绍
难点：
人力比约1:8，且自测
自动化复杂度高，数据耦合严重
Story较多，实际工作量较大
共xxx个story，上线yyy次，
项目测试与贡献（贡献部分）
提早接入，改进送测质量：从MRD、RD评审等开始展现QA能力，改进xxx处
改造、丰富自动化lib库，实现代码xxx行，部署时间从1天降至0.5小时，新功能测试从3天降至1天
推进测试用例前置，改进测试质量，提出bugxxx个
CR改善提测质量
这其中，司南专业版在接手前刚刚经历了一次重大改版，产品代码几乎重写，测试用例几乎全失效；精算也新增两个大功能点；再加上两个1.0的项目，其中还有一个是百度大会展示产品。在人力比长期1:10+的情况下，还长期存在架构的不合理、自测程度低的问题。
改进的点主要有两个：
第一是 提升测试质量，在人力紧张的情况下仍然主动参与MRD评审和详设评审，从前期保证设计质量；同时，广泛采用送测时showcase的方式，从RD处保证送测质量；同时每个story也会由一位QA进行测试用例设计或测试脑图设计后由其它人review，也保证了测试过程质量。另外坚持CR、坚持可自动化测试部分的100%功能覆盖也是保证质量的一部分。
第二是 提升测试效率，一方面是完善测试所需的自动化部署脚本、进一步封装请求脚本，这里相对复杂的后端部署，从10小时降低至1小时，数据准备从无法同步更新优化至同步更新，后端story测试也平均从3人天降低至1人天。另一方面也推进非主要功能的RD自测，周边模块的搭建也拉入RD进行部署，降低工作量，更能focus在主要功能的测试上。 项目测试与贡献（介绍）
我是BDG下holmes QA 周迎凤，在holmes组已经两年了。
Holmes的对应的产品线有3大块，一块是统计系，包括百度统计、百度移动统计和duair；一块是司南系，包括司南专业版、百度精算、百度代言人和百度舆情用户版，之前还有过百度预测；另一块是百度推荐。
这其中我参与过百度统计的后端测试，后来逐步调整到整个司南产品系列，包括前后端。
简单说下，司南是一个面向广告主和代理商的产品，是以cookie为键值打通百度各个产品的数据，分析某个产品的人群、某个目标人群会关注哪些关键词、会常上哪些网站、在哪些地区会有更高的比例；
精算是一个查看广告效果的产品，能统计在某个网站上某个广告位，看过多少次、点击过多少次，并且还能结合大搜数据统计出回搜的比例。
百度代言人和百度舆情都是1.0的项目，前者是帮各个品牌分析哪个娱乐明星、哪个体育明星适合做代言，后者是将抓取各个电商和专业论坛的信息后聚类出网友们对某个产品的评论。 项目测试与贡献（介绍）
我是BDG下holmes QA 周迎凤，在holmes组已经两年了。
Holmes的对应的产品线有3大块，一块是统计系，包括百度统计、百度移动统计和duair；一块是司南系，包括司南专业版、百度精算、百度代言人和百度舆情用户版，之前还有过百度预测；另一块是百度推荐。
这其中我参与过百度统计的后端测试，后来逐步调整到整个司南产品系列，包括前后端。
简单说下，司南是一个面向广告主和代理商的产品，是以cookie为键值打通百度各个产品的数据，分析某个产品的人群、某个目标人群会关注哪些关键词、会常上哪些网站、在哪些地区会有更高的比例；
精算是一个查看广告效果的产品，能统计在某个网站上某个广告位，看过多少次、点击过多少次，并且还能结合大搜数据统计出回搜的比例。
百度代言人和百度舆情都是1.0的项目，前者是帮各个品牌分析哪个娱乐明星、哪个体育明星适合做代言，后者是将抓取各个电商和专业论坛的信息后聚类出网友们对某个产品的评论。 之前工作
性能优化
提升百度统计的前端页面展现性能
无线数据整理 跨职能合作与推动
Good coder通过
多次联调
3. 协助组内几个topic
