创新项目 获奖者姓名 链接
大搜索 Bad Case 系统性挖掘分析
分级发布服务
无线广告评测服务
Test DataWarehouse(TDW)
创新项目 获奖者姓名 链接
先知平台
基于 ec 集成测试的一套 lib 库预发布体系
fet-js 组件测试方案
检索满意度评估平台
IM 分布式系统级测试平台
线下 Ecom 管理与监控系统
分布式异常测试框架 DIFI
Flash 安全扫描器
Bug Assistant
基于关键字自动生成测试用例的方法及工具实现
创新项目 获奖者姓名 链接
基于 yii 的测试代码自动生成框架——iphp
基于可见文本的页面元素智能定位系统
测试系统健康状况自动评估平台
经典 bug 在线积累和竞赛平台
图片信息库数据测试方案
公交效果评测平台
image 时效性监控
后端数据 lib 库
资源 badcase 挖掘系统
http 引流适配器
搜索类产品竞品对比通用工具
hudson 机器资源优化解决方案
XTS case 自动选择
分析函数调用关系
针对日志的变异型数据模糊工具
一种关于精确模拟网络异常的自动化解决方案
数据库准入测试 DAT
zcache 集群心电图
易平台 story 提测流程
PHP 分支覆盖率解决方案
多设备并行测试的调研与实现
用户体验测试方法、流程及辅助工具
一键初始化环境工具
轻量级 http 性能测试工具
我将会对每个创新奖做一个分析
稳定环健康指数评估平台
这个平台主要是通过分析流量和 log 来判断有么有出错。类似于运维的监控。思路不错。
不过做的太浅了。还有进一步挖掘的空间。而且设计上也可以做更好的改良。比如可以通过 proxy 来度量流量数据,这样更精准。
另外流量的变化,也可能跟业务有关。只能通过设定经验值来评判。总体感觉还不够实用。
基于可见文本的页面元素智能定位系统
这个系统的设计跟我以前的想法很类似。通过模糊方式来定位元素。原理是借助元素周围的描述信息来定位自己要找的元素。缺点是只能针对可见元素。
其实还可以进一步扩充,比如要点击某个按钮,可能那个所谓的按钮,只有一个图片。可以通过猜测最有可能希望被点击的对象,来确定自己的定位。
当然缺点是明显的。
元素定位最好跟研发一起合作才可以。
经典 bug 在线积累和竞赛平台
这个的作用和原理就不用说了。一看就知道。想法很好,这个业界也需要这样的平台。
不过最关键的,还是模型和数据,做一个 web 平台作用不大。
比如对于 c++,java,死锁有几种类型,代码是如何写的,如何避免,这些将来都可以拿出来给研发和 qa 做培训。这种公益性的事情,估计也只有专门的测试类公司做才能做到最好,在大公司里面做这个的人很难坚持下去。没有业界的力量,也做不太好。
建议以开源方式运作
图片信息库数据测试方案
这个方案主要是针对评测的优化,目前对图片的评测是 PM 对小样本做的调研。实际上是不够的。也存在问题。他的这个方案通过反向挖掘来补充效果。比如通过分析目前网上的现有图片数据,从中提取关键词,然后再回到系统中评估这些战线是否合理。
赞下这个想法,虽然这个想法用在了他们这个领域,实际上方法是通用的。可以扩展到其他的测试领域。通过真实的数据来反馈功能的正确性,不止是效果。这也是我一直提倡的。可惜一直没有机会实现出来。。我在百度的一大遗憾。
公交效果评测平台
这个产品做的很优秀,他采用特征分析来发现 badcase,而且还创新的采用了竞品分析的技术。比如在百度地图搜索两个地方的公交情况,然后再查询搜狗地图和高德地图,对两个的数据进行对比。分析他们的差异就可以发现很多有意思的数据。
除了对竞品分析外,他自己也定义了一套规则来检查自身的 badcase。如果最快捷的路线比其他的路线长,就认为可能是 badcase 等等。
基于特征分析可以挖掘出很多 bad case。这是个非常好的方法。跟我的用户行为分析理念也很相似。感觉整个百度已经开始从测试,监控迈入到了新的测试领域特征分析和建模了。
image 时效性监控
无连接,无法分析
后端数据 lib 库
无介绍连接,猜测是个数据的集合,用来辅助测试的。
资源 badcase 挖掘系统
应该也是利用特征挖掘技术。无连接,无法分析
http 引流适配器
从线上引流,把 http 协议封装为 udp 发给 http proxy,然后再解包为 http 回放。(很大的疑问,为什么要折腾为 udp 那。。为了省流量,省连接?)
同时支持 log 回放。
感觉没有新意,完全可以通过 tcpcopy 来实现类似的机制。总体感觉可以忽略,没用。
log 回放是有价值的,但是这种方式不通用,已经是新的一个话题了,没必要合并在一起
搜索类产品竞品对比通用工具
估计就是发请求到其他引擎,然后比对结果的工具吧。应该是个工具。无连接,无法分析。
竞品分析是个很重要的测试手段。这个还是推荐业界试用下。是个很好的镜子
hudson 机器资源优化解决方案
无连接,无法分析
XTS case 自动选择
针对如上情况,“XTS case 自动选择” 充分利用覆盖率信息来解决这些问题,使得 ci_quick 运行 case 的时间减少 50% 以上,ci_slow case 成功率由 75% 提高到 98% 以上。在 im 组 xxxxxxxx 等多个模块中使用,并且引入到 nova,在提高 ci 效率和保证产品质量上发挥了积极作用。
“XTS case 自动选择” 根据覆盖率信息,自动选择最重要的 case:代码升级相关的 case,最近新加和修改的 case。经过验证,不仅使得 ci_quick 的时间减少 50% 以上,平均运行的 case 数大大减少,而且因为代码升级导致的失败的回归 case 可以在第一时间被暴露出来。
设计的基本原理是每天晚上 daily 任务运行所有 case,获得每个 case 的覆盖率信息,根据 case 覆盖的函数建立倒排(key: 函数名 value:覆盖该函数的搜有 case)以及 case 全集列表,上传至服务器。本地执行 localbuild 和 ci_quick 时,下载 daily 任务生成的倒排和 case 全集列表,选择需要运行的 case。
这个工具非常不错,对覆盖率做了很深入的分析,这也是我之前研究的 topic,以后前途不错。。业界对覆盖率的使用太水了,里面的价值很大。
分析函数调用关系
用于分析 c 的调用关系,无连接,无法分析
针对日志的变异型数据模糊工具
一个 fuzz 方法和工具。利用现有的 log 数据做结构化的 fuzz,工具也没封装好,易用性差。
这种方法不好,fuzz 不是个好的测试方法,有白盒分析的情况下是不适用的,比较适合纯黑盒测试。
基于特征挖掘的方法比 fuzz 有效多了。再结合覆盖率可以完败 fuzz
一种关于精确模拟网络异常的自动化解决方案
通过 proxy 的方式模拟 mysql 和业务线的异常场景。跟业务结合比较紧密。
思路很好,通过代理来截获中间的请求,然后定制自己的返回。类似于系统级别的 mock,mock 是神器啊。思路不错。我也在写类似的工具。代理的价值还可以进一步挖掘。比如流量保存,回放,代码自动生成等。
数据库准入测试 DAT
基于对 sql 的静态分析和测试环境的作用分析来判断 sql 是否正确。
思路不错。
zcache 集群心电图
无连接。跟之前的其他专利应该类似,就是集群的监控。没新意。
易平台 story 提测流程
提测流程也能获得创新奖??
因为无连接,不做分析。
PHP 分支覆盖率解决方案
核心思路是在 PHP 代码编译为 opcode 之后,对 opcode 中出现的 JMPZ、JMNZ 及其下一行的执行情况进行分析,判断分支执行的真或假,再将状态信息合并更新到指定的覆盖信息 hash 表
该解决方案完善了 xdebug,填补了 PHP 分支覆盖率的业界空白
这个创新奖可以申请专利。赞。一看就知道对 php 和 xdebug 的代码做了深度的分析。。测试领域就缺少这种认真的人。对作者表示敬佩。
多设备并行测试的调研与实现
链接无权限,不做分析
用户体验测试方法、流程及辅助工具
无权限访问,不做分析
一键初始化环境工具
百度 qa 的 blog 有分享。
轻量级 http 性能测试工具
一个 java 写的 http 性能测试工具。
写的不错,不过是重复造轮子,可以使用 jmeter 来代替
level1 的创新奖分析完毕。稍后分析 level2 和 level3 的创新将内容。从这些众多的创新奖中不难看出,百度具备优秀的人才和优秀的人才培养土壤。
大搜索 Bad Case 系统性挖掘分析
大搜索 Bad Csae 系统性挖掘团队从年初成立以来,目标如下:
(1)建立系统、全面和高效的大搜索产品 Bad Case 挖掘机制,有效发现大搜索产品存在的问题和缺陷,夺回 “百度第一 QA” 称号;
(2)基于 “机器学习 + 众测” 的模式,参与建设和完善搜索引擎的数据资源;
也是通过特征分析来挖掘 bad case 的。
很想加入这个团队啊,我也在研究同样的 topic。
他们目前使用的众测流量,其实真实流量和线下体系都是可以利用的。
特征挖掘 + 监控 + 测试建模,这是下一代测试。
测试领域也需要迎接机器学习的时代了。。
分级发布服务
四级发布模型,小流量发布模式。
这个在外部也分享过,改变了百度的发布方式。可以减少损失,在公司内的影响很大。
无线广告评测服务
应该是个平台,连接指向了一个网站,需要注册,不做分析。
Test DataWarehouse(TDW)
一个非常庞大的测试数据管理体系。建立百度测试数据仓库,整合所有测试数据,为所有测试应用提供可靠的数据存储和管理基础架构服务。为开发者提供可靠的大数据存储和处理 SDK。
规模太大了。而且是一个团队负责。。不做分析了。
level1 的分析完成
下面对 Level2 的专利做分析
先知平台
看了说明也没看懂平台的价值,貌似是可以管理多个测试环境,方便的调取数据,研究策略。同时也做了一些监控。各种疑问。。
使用 extjs 设计的一个网站平台,感觉太复杂了。已经脱离了测试的需要了。
基于 ec 集成测试的一套 lib 库预发布体系
这个技术改进的目的是:1.使库模块每次升级都能尽可能快速地被应用方所联编;2. 使库模块每次升级的测试速度尽可能地快。
体系很大,暂不作分析了。
fet-js 组件测试方案
百度目前的 fe 设计是模块化的,基于组件式的,可把这些组件剥离出来进行分析测试,并付诸于自动化测试,提供了一个平台和一个完整的框架。
写的不错。但是不具备通用性,只适合特定的业务线。
检索满意度评估平台
没权限访问,不做分析。
IM 分布式系统级测试平台
分布式系统测试平台。
感觉没必要,只是个 case 分发系统。不过做的倒是很复杂。level1 的创新奖一个个都是巨复杂的系统。这种趋势不太好啊。。
线下 Ecom 管理与监控系统
跟之前的其他系统类似,有一个线下系统 + 监控平台,他们竟然搭建了上百台机器。。。。真有资源,我等小民望尘莫及,之前还为了申请一台服务器而较劲脑子思考理由那。。。
流量监控 + 特增挖掘。。没什么新意。。但是的确能发现不少问题。跟之前的 bad case 挖掘相比,还是差了点。。
分布式异常测试框架 DIFI
通过在每个机器上部署 agent 做一些异常模拟,不过是在现有体系上加了一个分布式的功能。
插件是最后有价值的,可以控制 cpu,mem,disk 等指标的异常情况。
总体还不错。我有个疑问,systemtap 不就可以搞定所有的事情了吗?
Flash 安全扫描器
扫描 flash 的 xss 漏洞的。
Bug Assistant
不做分析
基于关键字自动生成测试用例的方法及工具实现
不做分析
level2 的终于分析完成了。等以后再重点点评里面的个别有前途的项目
接口测试,headless 前端自动化,系统级别 mock,覆盖率细分,特征挖掘,测试建模这些 topic 都很有价值。这些 topic 串在一起,其实就形成了新一代的测试体系。但是整个业界研究这些的人太少了,除了百度跟阿里,其他公司的研究水平都很水,所以我决定公开这个分享,让整个业界开始认识到新的测试模式的到来。
再次 review 了下全部的文章,确信无影响百度公司的保密措施。确定发布出去
盖楼好高啊,呵呵,有时间 一定一个个 看看
基于 yii 的测试代码自动生成框架——iphp 这个有意思!
很好很好啊,有时间好好研究